LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
ASP.NET MVC 2 Ships
ASP.NET MVC 2 has shipped.
03/12/2010 10:26 AM EST

Microsoft plans 'open' Silverlight analytics framework
Microsoft is going to announce a multipurpose analytics framework for Silverlight at MIX.
03/11/2010 09:51 AM EST

About CSS processing
Two sites that lead to a startling CSS conclusion.
03/10/2010 02:29 AM EST

 

Events calendar tab
SHARE
3/14/2010 to 3/18/2010
Seattle, Wa.
SHARE

Cloud Connect
3/15/2010 to 3/18/2010
Santa Clara, Calif.
TechWeb

Microsoft MIX10
3/15/2010 to 3/17/2010
Las Vegas
Microsoft

SharePointPro Summit & Expo
3/16/2010 to 3/19/2010
Las Vegas
Penton Media

TheServerSide Java Symposium
3/17/2010 to 3/19/2010
Las Vegas
TechTarget


 
print Printable version 
Most Read Latest News Blog Resources
Even with its success, .NET causes some consternation
Despite its popularity, the developer community believes that .NET isn't being fully serve...

Appcelerator dev environment targets Android, iPhone
This unified development environment compiles JavaScript into Objective-C or Java, and wil...

VMware releases Tomcat-based server for Spring
SpringSource and VMware are moving their platforms closer together with tc Server for Spri...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

David S. Linthicum: Orchestration in the Key of SOA


By David S. Linthicum
September 15, 2007 — 
If there is any confusion in the world of SOA, it’s around the role services play when interacting with orchestration. In general, those who understand orchestration don’t understand services, and those who understand services don’t understand orchestration. Thus, many SOAs are born without process or orchestration layers, or a place where business processes can be changed using a configuration paradigm, rather than reprogramming. That’s architectural agility, and why we do SOA in the first place, so you typically need orchestration and process management.

Orchestration is not that scary when you consider that it’s really about process automation; we are just building on the same notions. Indeed, you’ll hear me talk about orchestration and process integration, process automation, workflow and BPM interchangeably, since the patterns are very common between the technologies and approaches.

The best way to consider both notions of service and orchestration (and process integration, in general) is to think of them as independent layers, where the process layer is a meta application existing on top of the services, calling the services when needed. It’s at the orchestration layer where the services are invoked in certain sequences, and using certain logic, to form the solution. This interaction allows the architect and the developer to place certain things into certain domains.

Orchestration is a necessity, the layer that creates business solutions from the vast array of services and information flows found in new and existing systems. Orchestration layers allow you to change the way your business functions, as needed, and to define or redefine any business process on the fly.

We can define orchestration as a standards-based mechanism that defines how Web services work together. Orchestrations may span a few internal systems, systems between organizations, or both. Moreover, orchestrations are long-running, multistep transactions, almost always controlled by one business party, and are loosely coupled and asynchronous in nature.

Orchestration encapsulates and leverages services, binding them together to form higher-level processes and composite services. Indeed, orchestrations themselves should become services, and may be leveraged as services.

Here are a few things to consider:

• A single instance of orchestration typically spans many instances of service- and information-oriented points of integration, perhaps many domains and even organizations. Thus, you typically have one orchestration for many services.

• Most orchestrations leverage public standards such as BPEL. However, there are a few competing standards, such as for process and workflow, and technology that can do very much the same job—binding services into processes to form solutions.

• Orchestrations may be available to everyone or just the owner, and shared, for supply-chain integration scenarios and other B-to-B activities.

• Orchestrations are usually driven from a single party; they are not always collaborative in nature.

• Orchestrations themselves may become services available for other services or orchestrations (as mentioned above).

• Orchestration defines a meta-application, of sorts, that has visibility into many encapsulated services as well as application information that may be bound to those services.

• Orchestration is independent of the services they are leveraging. Changes can be made to the orchestration without having to force changes to the services.

• Orchestrations may be decomposable down to base processes, and finally services. The hierarchy further provides architectural control to the architect or the developer in support of the business solution they are automating.

• Orchestration, in context to a SOA, is strategic, leveraging business rules to determine how systems should interact and better leverage the business value from each system through a common abstract business model.

Process orchestration is one of those things that SOA really needs so it can provide the agility value. While most developers are content with just building a bunch of Web services and calling it an architecture, the job is not complete without a well-defined process or orchestration layer for defining, and redefining, business solutions. The trouble is that this approach is architecturally complex, and thus often ignored.

A better way to look at it is to consider that orchestration itself is really about creating another layer of services that interact to form solutions, which is what SOA is all about.

David S. Linthicum is the CEO of the Linthicum Group. Reach him at david@linthicumgroup.com.


Share this link: http://www.sdtimes.com/link/31137
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading