BT

Article: Service Composition

by Stefan Tilkov on Jul 26, 2007 |
In a new InfoQ article, Boris Lublinsky discusses the main approaches to service composition, both from a design and implementation point of view.

In Boris's opinion, the ability to re-use services by composing them into higher-level services is one of the key benefits of SOA. After explaining the difference between hierarchical and conversational  composition, the article explains different topologies, such as mediator and peer-to-peer, that can be used to compose services. Boris also describes a number of different implementation approaches, including a general purpose language, event-based composition, and use of an orchestration engine. In his opinion, the latter approach - use of an orchestration engine - yields the most benefits.

Read the article for more.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Link not working by Tom Kerigan

The link to the article doesn't seem right - is there a correction forthcoming?

Re: Link not working by Stefan Tilkov

Thanks Tom, I've fixed the link.

Orchestration and glue code by Christian Poecher

Hi there,

I wonder what happens, if you use BPEL or any other orchestration technique when you need some glue code inbetween the service calls. Imagine for example a composed service from several navigation services, where some services return a partial route length in miles and some in kilometer. You don't want to introduce a service just for converting length, do you?

I think there is a little mistake in the text ... by Bruno Spinelli

In the part :
"Another possible approach to the implementation of composite services is event-based composition. This composition implementation is based on event-based service interactions: service consumers publish events to the publish/subscribe intermediary, which delivers them to the actual service CONSUMERS (Figure 6)."

Maybe the correct would be :

service consumers publish events to the publish/subscribe intermediary, which delivers them to the actual service PROVIDERS (Figure 6)."

Thanks!

Re: Orchestration and glue code by Boris Lublinsky

A good question. The article is about integration of the business services, not building business services. This is a common poin of confusion. If I understand the question correctly, you are building a business service, that uses multiple integration services (partial length calculation). In this scenario, I would never expose integration services, but only an overall service. Now you need to build the actual business service, that orchestrates partial integration ones. This is a different situation, where glue code might be the right solution. Also, when people talk BPEL, they typically talk macroflows. If you look, for example, at WPS implementation or WWF, the explicitely separate Macro and Microflows. In the latter case, the activity might be either service or SCA component (IBM). Such SCA component can be local java class (same EAR), which impose virtually no invocation overhead, This might be a good approach to building a service.
Hope this helps.

Re: I think there is a little mistake in the text ... by Boris Lublinsky

You are absolutely correct. Stefan, can you, please, fix this

Re: Orchestration and glue code by Paul Beckford

Hi Boris,
I must admit, that I just don't un derstand your answer. I think the question is a good one. Just plugging services together "lego block style" seldom works. There is always a little custom work to do. I agree that a single service view should be exposed to the client, encapsulating the end service, but for me this is nothing other than EAI (enterprise application integration), where I produce a new service that so happens to call out to existing services. Is this what you mean?

Re: Orchestration and glue code by Boris Lublinsky

What I was trying to say is that I differentiate two different scenarios:
Orchestration of business services for building new solutions - topic of this article. In this case I do not care how business service is implemented and the fact that it internally uses multiple integration services is irrelevan at this point.
Implementation of the business service, based on the integrations - the topic of the question.
This two scenarios are quite different and follow different implementation rules.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

8 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT