Archive for June, 2009

muSOAing for 6/28/09

June 28, 2009

Over the past couple of months we have focused on the more strategic aspects of SOA. Examining the various aspects that constitute SOA and trends in general. I think we have done enough due diligence for that part. It is now time to start talking about the more tactical aspects of SOA. The part where the rubber meets the road.

Over the next few weeks I will be taking up very specific topics wrt SOA implementation and examining them in detail. This will relate to both the very tactical parts and also a few relating to the strategic aspects such as metadata strategies for a registry implementation, how to implement governance, SOA implementation patterns etc.


muSOAing for 6/27/09

June 27, 2009

So it all started with BPR (Business Process Rationilization) and then we went on different tangents talking about the various types of Process Orchestrations. So have we really answered the question of BPR and where it is needed?

In the world of SaaS when you have implemeted co-location on a single app instance, it is in your interest to provide personalization both at the presentation layer and at the middleware layers. At the presentation layer, any good Portal framework and there are several opensource ones such as Liferay, eXo etc. can do this job. In the middleware layer, you will need a very good Process Orchestration engine to do this job. A good opensource product such as Intalio should fit the bill. There are a lot of other commercial and opensource offerings. There are certain criteria you should list out for this.

muSOAing for 6/20/09

June 20, 2009

Let us focus on BPM for a change. So now the term BPM is now synonymous with orchestration of services. A BPM engine is now a standard SOA offering along with ESB, Registry and Governance Tools.

A BPM offering is similar to a low level process orchestration engine in the sense that it has a design time and a runtime component. The design time component is a visual drag and drop palette that gives the user a view into all the existing services and let’s the user build orchestrations by composing these services that serves to address one of the Business Use Cases such as Order fulfillment or Order Processing.

A BPM tool is tailored for use by Business Analysts. It is a no code zone. It is not an interface for writing new services, that will fall under the domain of a LLPOE (Low Level Process Orchestration Engine).

muSOAing for 6/18/09

June 18, 2009

A quick recap on Process Orchestratoin before we hop onto this new world of Service Orchestration.

The need for Process Orchestration has been in place since the first computer program was written. Be it COBOL, C, 4GLs like PowerBuilder or Java you have implemented Orchestration of some sort. The so called 4GLs were nothing but abstractions that hid the gory details of the Windows SDK or J2EE from you and abstracted them out in the form of widgets and controls like a Datawindow control or a JMS control.

Some of the recent Process Engines like BEA WLI and Oracle BPEL PM incorporate some very sophisticated technologies under the covers such as the ability to spawn multiple instances on demand depending on the load, dynamic in-memory caching and other features that make these highly desirable for enterprise level computing.

The term BPM was tagged on to these technologies though the focus was very much on technology though the processes themselves implemented serious business logic. So then came along web services and several things happened. You had a set of standard interfaces/APIs that the business could avail of. You had the option to expose these functions to your internal business and your trading partners. This level of standardization enabled the easy choreography of these APIs however disparate they did seem from a business perspective.

One point of note is, SOA should be viewed as a top down effort where the thinking should always be Business First. I think the technological building blocks have a) matured sufficiently enough and b) proliferated to such an extent, thanks mainly to opensource efforts, that a tactical effort is hardly necessary to evangelize this technology set.

muSOAing for 6/14/09

June 15, 2009

The term BPM has been around for a while. Earlier on before the advent of services, BPM meant any type of orchestration, a multistep process that had to complete as one atomic transaction. These multiple steps could involve very diverse operations starting from receiving a JMS message to doing XML transformations, calling an external adapter and then shooting of an XML message over HTTP and receipt of an acknowledgement.

All the steps mentioned above are still very relevent in today’s integration world, it is just that these are being performed by engines that have by and large been implemented with a lot of standards in mind as articulated in my earlier post. Standards such as BPEL, XML, Services, Schemas etc. So much so that each orchestration is agnostic and independent of the actual runtime orchestration engine it is mandated to run on.

You can now export a complex orchestratoin designed and developed in a product from Provider A and later down the line import the same into Provider B’s runtime engine and run it as is (provided you have configured all the external touch points of course).

So then what is Service Orchestration then? Stay tuned.

muSOAing for 6/5/09

June 5, 2009

Continuing our talk on Orchestration engines, these have certainly come a long way. While the trend until quite recently was product offerings that were by and large based on open standards but did have proprietary elements built into them to ensure vendor lockin. The good news now is everyone is gravitating towards open standards.

With open standards I mean mainly BPEL and SOA (web services, schemas and xml) with underpinnings of either J2EE or Microsoft technologies. Talking about orchestrations, it is important to point out the disctinctions between process orchestrations and service orchestrations.

Got to run, more in my next muSOAing.