You'll hear about issues with BPEL as well as old school and new school SOA.

www.soaexpertpodcast.com

Posted by davel in | Permalink | Comments (0)

It’s funny how things work out. When I first looked at BPEL several years ago I pointed out the limitation of the standard when it came to applicability in the process integration area. Indeed, I did so in my last book. It’s really not a process integration standard, but more of a way that Web services can work and play well together, or the notion of orchestration.

However, today we are just finding this out. As more and more end users attempt to create their first instances of SOA-like solutions, the fact that BPEL is not about process integration or workflow, is now well known. Thus, many are wondering if BPEL’s days are numbered, or if the standard will reinvent itself.

So, what’s the delta between BPEL and process integration. Simply put, business process integration is a set of easily defined and centrally managed processes on top of existing sets of processes contained within a set of enterprise applications. Business process integration or business process management is the science and mechanism of managing the movement of data, and the invocation of processes in the correct and proper order to support the management and execution of common processes that exist in and between applications.

The goal is to bring together relevant processes found in an enterprise or trading community to obtain the maximum amount of value, while supporting the flow of information and control logic between these processes. Business process integration offers a mechanism to bind disparate processes together and to create process-to-process solutions that automate tasks once performed manually.

The problem is that BPEL, for the most part, was not built for process integration. Many vendors are attempting to fill in the missing pieces through proprietary extensions, but that’s never smart. Moreover, the standard is going through the reinvention now. But, you have to ask yourself if it’s in time to save the standard…IT forgives no one. I know many end users that are pushing back on BPEL, instead moving to older business process technology, or other standards such as Choreography. BPEL has certainly hit some rough roads.

Posted by davel in | Permalink | Comments (1)

It’s interesting to think that many of the services we’ll leverage within our enterprises won’t be created by the enterprise itself, meaning services that are hosted by service providers that we employ on demand. There are many of these examples today, including eBay, Salesforce.com, Amazon.com, and even new startups such as StrikeIron, all looking to make money through the delivery of Web services to those that need them. I call this “Outside-in SOA,” and perhaps the most valuable notion of the movement to a more service-oriented world.

For many enterprises this is scary stuff, much like the Internet was scary back in the early 90s. However, as we move to “Web 2.0” we are indeed going to find the value of leveraging application services that we had nothing to do with creating, or incurring the cost or the risk for that matter. Clearly, the days of purchasing or developing software as the default solution are behind us, and we’re moving to a model where we can mix and match services on-demand, for any business purpose. This notion will provide us with the business agility and value we’re finally looking for from IT.

However, the concept of Outside-in SOA needs specific enabling technology, layers of software that are able to manage the interaction with outside services, typically Web services, and the internal systems, including semantic, protocol, and security mediation. To date, most of the work has been concentrated on building a SOA using internal systems, not considering the use of service providers. I’m asserting that the patterns of use are very different, and thus require different approaches and technology.

Moving forward we need to put some science, discipline, and technology with the notion of leveraging and managing external services, with the goal being their transparent use within the enterprise. The technology patterns are very unique with hybrid solutions that are able to manage service-oriented integration, including components that need to exist both inside and outside of the enterprise to properly manage services interactions, and deal with proprietary systems that will never talk Web services, which is the majority of systems out there for the time being.

I think this is a huge area that needs addressing now, both as service providers become more popular, and enterprise can obtain real value by leveraging them. We are clearly at the forefront of this pattern, and future enterprises will accept the use of services existing outside of the enterprise much like we accept information commoditization through Web delivery today. Web 2.0 indeed, will you be prepared? I’m going to make sure I put the proper thought and technology behind this. Follow me.

Posted by davel in | Permalink | Comments (1)

www.soaexpertpodcast.com

Posted by davel in | Permalink | Comments (0)

If anybody was wondering what Microsoft’s take was on delivering software as a service, Bill gates made is clear in this leaked e-mail to his employees. Not a surprise to anybody, really. Well, perhaps some of the vendors who have been dismissing Microsoft in order to clear the way for their technology.

Truth-be-told, the support by Microsoft in this space is very important, and will actually enable SOAs going forward. Microsoft does a good job at marketing notions, as well as technology. Thus, as they move further into this world they will bring along many of those who are reluctant to enter unless the technology is bundled behind a very nice installation wizard. Much in the same way Windows enabled many new types of technology to enter the game, again riding on the Microsoft platform.

I always get a kick out of those that look down on Microsoft, and their technology, yet pull out their laptops and boot Windows XP, get their e-mail via Outlook, surf the Web using Internet Explorer, and show me their non-Microsoft technology using PowerPoint.

I’m not sure Microsoft is going to dominate the SOA marketplace, they seem more interested in selling a million of something than a few sophisticated products. However, their presence in the space will legitimize this technology, and I’m sure many innovative vendors will find a way to grow crops where Microsoft has plowed.

Posted by davel in | Permalink | Comments (2)

I was at the InfoWorld SOA Executive Summit this week and made a few observations. Mainly, that everyone continues to search for that elusive magic bullet in the world of SOA and they are pretty upset when they hear it does not exist.

Personally, I love the magic bullet theory, that would be great, but an ESB won’t save the day neither will a governance system or repository. However, good planning and architecture will. Sorry to be a “buzz kill.” I feel like Mom and Dad just broke up the party.

The truth of the matter, I’m seeing a clear pattern of success in the world of SOA…those that do the right amount of planning, understanding their own requirements, and then selecting the right technology, typically have successful movements towards the notion of a SOA. Counter to this, those that don’t want to do the planning, and believe the hype that a product will get you there, with the exception of a very lucky few, you’re doomed.

“Dave, you’re just mean.” I guess, but I am still running into a number of people who are making critical decisions about technology who don’t understand the process that one needs to go through to get to the right answer. Also, that these same people are surprised when it does not work.

There is a lot of discussion these days about SOA Maturity Models, processes to get to a SOA, and other things that are more about discipline than technology. These types of efforts are steps in the right direction, and I’m hoping that people get on board with these processes and learn how to solve their own problems.

We need to get this right the first time people, don’t make me come after you.

Posted by davel in | Permalink | Comments (1)

Authentication would provide the security element to a service, including who’s authorized to use it, identity management issues, and any special security issues such as the use of encryption.

Dependencies would define any other services encapsulated inside of a service where the calling service is dependent upon. For instance, an inventory control service may leverage a public service to determine the date and time, that needs to be documented as a dependency for obvious reasons (e.g., that service dies so does your service).

Finally, we need to define service levels. In other words, the service levels you can expect from a particular service including standard outages and accessibility issues, such as limited bandwidth. This will allow those creating a composite application around a group of services to determine the service levels of the composite application, which is only as good as the services that make up the composite application.

Clearly we need to go a few more levels of detail down to better define the notion of service description as well as the properties we need to track within each service. Perhaps we can meld this into an existing standard, much in the same way metadata is moving towards a standard (finally). However, I suspect it will still be the Wild West out there for awhile as SOA and service-oriented integration moves out of the playground and into business critical production systems. When that occurs we better have some sense of how to define, share, and leverage service description or it will be a very confusing world.

Posted by davel in | Permalink | Comments (0)

With the advent of Web services, most enterprises that I deal with now have thousands sometimes tens of thousands of services under management. To make matters even more complex, we also have to consider services that are out of our direct control, those found on the open Internet (public services). Clearly, you can count on the number of these services increasing over time, perhaps very quickly over the next few years.

While we do have some interface information about these services, as defined by standards such as WSDL and UDDI, we really need a more complete set of info surrounding the services in order to create a proper SOA. This information should include things such as; the purpose, interfaces, parameters, rules, logic, owner, semantics, included services, and other important data. Let’s call this what it is, a service descriptions.

There are a few dimensions we need to address including: semantics, purpose, authentication, dependencies, and service levels. These by the way, are only basic suggestions, other dimensions and even sub-dimensions are all allowable.

Semantics, is a no brainer and it’s been known for awhile that semantics are a weak point of Web services. Today we are attempting to solve this problem with new standards such as The Semantic Web, or more often through proprietary mechanisms, so I really don’t need to sell this dimension. This is a pain point for most service-oriented integration architects.

Purpose means that we have a common notion of the purpose of the service, such as a service that’s written to update cash in an accounting system, or a service that controls a large inventory system. Here we should document the uses of the service, examples, and any calling information needed.

Off to bed. I'll continue with this tomorrow.

Posted by davel in | Permalink | Comments (0)