Quite often we hear of service composition as one of the key benefits of the service oriented style of architecture. With service composition, we are referring to the creation of new services from wiring up of existing services in new ways to deliver new value.
According to the standard reading material, service composition is best achieved through orchestration. This is usually achieved through the use of middleware such as an ESB or integration broker. A workflow orchestrates the invocations of a number of services in order to achieve some particular outcome.
As such, we find that a service may comprise some of its own logic (including the orchestration logic), as well as a number of lower level services.
This concept of service composition is central to the Layered Service Model where lower level task and entity services are composed into higher level process services. As you will have gleaned from my previous posts on the topic, I'm not a supporter of the Layered Service Model approach. One of the issues of this approach is that lower level services are reused by many higher level services, resulting in high coupling between those higher level services.
In the past, I have highly recommended that people pursue what I call a Self-Contained Process-Centric Service Model. Here, services are centred around autonomous business functions such as Sales, Marketing and Billing. What I probably didn't emphasise about this approach however is that it refers only to the top-level service model. Each business service may be composed of lower level services.
Note that these lower level services are not business services. They are services that serve a particular function in support of the business service. They are an implementation detail of the business service. In fact, they are actually really just distributed components or integration points. However if the means of communication with the distributed component or integration point is the exchange of messages via endpoints in conformance with a service contract, then we technically have a service by the strict definition of SOA.
In a green fields implementation where the software supporting each business service is built from scratch, there may be no lower level services involved. That is, there is no service composition. Alternatively, the service software may be implemented with a smart client application that interacts with some back end components via the exchange of messages in conformance to a service contract. Thus, those back end components technically expose a service to the smart client application.
Say in support of this business service, the back end components also interact with a Web service provided by another organisation. Now we have another service added to the mix. Here we can see services being composed in support of the larger business service.
Where a business service is supported by a number of legacy applications we see even more composition. When the business service receives a message, it must invoke one or more of these legacy applications appropriately. This may be achieved by invoking Web services exposed by these applications, thus constituting further service composition.
So we see that services certainly can be composed in support of larger services. However I would hesitate to name this as a benefit of the SOA style of architecture. It is merely an implementation choice of any given service. Service composition has only come to be viewed by many as a key benefit of SOA due to the reuse promised (falsely in my opinion) by the Layered Service Model approach.
Friday, September 12, 2008
Service Composition
Labels:
service composition,
SOA
Subscribe to:
Post Comments (Atom)
8 comments:
Hey Bill,
Nice topic. Got a couple of questions though.
1) Are we talking about an analogous Composition to Gang-of-Four Composite pattern? That is can we define, lets say in a .NET world, service attributes that will act as contracts into the composition services? So that instantiating a service with attribute [PersistentService] will, by way of inversion of control or whatever, provide that service with an opaque way to access the composite services that perform that duty.
Ofcourse we really want to make something like that hetrogenous.
Or am I way off the track?
2)Can we call it SOAComposite? :)
Cheers,
Miguel de Sousa
Hi Miguel,
Very good question! In fact the comparison between composition in the SOA world and Component Oriented Programming world is rather enlightening.
I've written a post about this point here.
To get back to your point about composing services in a .NET world through application of an attribute such as [PersistentService], service composition in SOA is far more explicit than that. Lower level services are explicitly consumed by higher level services.
Cheers,
Bill
Congratulations Admin! Thank you so much for taking the time to share this exciting information.
coiffeuse montreal
website design in poole-We are Top Web Design Company in Bournemouth. We offer Website Design in Poole, Bournemouth & Hampshire. Visit us for cheap website design services.
Dedicated Server Web Hosting-Ultimate solution for all your server- related issues. Virtual Dedicated Server Hosting, Dedicated Virtual Server, Bandwidth Solutions, Acquires Server Intellect.
B2B Email Marketing Software-We at Techno Data Group, offer you with the B2B marketing solutions, with cloud-based software and lead -data services which are especially designed to stimulate conversions from the inbound, outbound, and database marketing drives.
Thanks for your info.
Get best service all time..Watech Computer Services..
alpha services llc
WaTech’s commitment for 100% customer satisfaction, reliability and high performing
bandwidth solutions have helped improve customer efficiency since 1997.
Contact us today to discuss your business’s ,bandwidth solutions , Telecom, and IT computer service needs.
Post a Comment