Understanding the service paradigm
by CBDi Forums Limited
Did you see any of the Wimbledon tennis matches? Can you imagine being in the firing line on the other side of the court from one of the top players? You are waiting nervously to receive service from Leyton Hewitt or Serena Williams; although you might have studied their technique, you don't have time to analyse this in real time; you look for the delivery, the speed and direction of the ball and concentrate on making an effective return.
The service oriented environment is very similar to a game of tennis. There's a clear divide between the service provision and consumption that allows each participant to concentrate exclusively on their own concerns. And it's this separation that makes service oriented architectures different to everything we've done before. Yes, we had separation of concerns with components, but in reality the same person or organization was in control of both end points. In our commentary last week on testing and trust, we made the point that "even" if the provision and consumption of a service is under the control of one organization, it is a major mistake to manage both endpoints collectively, because the clear separation may be compromised. And if this happens, you may lose the flexibility to adapt or upgrade or substitute either endpoint independently of the other. The result is like having tennis players that can only play with opponents they are accustomed to playing.
Although Web services are top of the toy box, (everyone's playing with them) there's more important architectural and process foundations that need to be thoroughly understood, if maximum benefits are to be realized -- and this relates to service orientation. This requires some considerable change in mindset from what we have been doing up to now. For example real separation is just one of the primary principles underlying the service based approach. The difficulty is perhaps that service orientation doesn't alter everything, far from it. Too often we have embraced silver bullets that were expected to revolutionize our technological landscape, and been disappointed. The good news is that service based architectures are evolutionary, not revolutionary. But the really important question to answer is just what needs to change and what doesn't? And how do you communicate that.
A good way to approach this is to go back to first principles. Let's examine a few.
With components, and other forms of reuse, de facto practice was to take copies of code and executables and instantiate them within the new system. Although the component based vision was to reuse a single image, in practice this was and is rarely feasible because the component interface specification is insufficiently precise. With services, the code/executable remains where it is, and is reused by calling it's interface.
User perceived granularity
So what functionality is published as a service, and what remains as a supporting component interface? The answer is simplicity itself. The right level of abstraction to expose as a service will be the unit of functionality that is recognizable and useful to the user of the service. There's no point in publishing data retrieval services when the user wants a list of outstanding orders. If the right level of abstraction has been identified, there is a good justification for formally publishing and making usage agreements.
It sounds easy and trivial, but in practice, as with components the temptation to compromise is huge. Performance, trust, cost and other concerns all create demands for managing services in a conventional manner. This is an even stronger temptation right now when most services are implemented internally. But the formality of hiding the implementation forces the designer to implement true separation and is an essential discipline.
Publish functionality, formalize contracts
Publishing is a significant cost. Right now you are thinking WSDL and UDDI, but there's potentially much more to the publishing task. The specification of a service needs to define not just the interface, but also the service behaviors, which are not necessarily exposed by the interface. In addition there is the question of dependencies, both functional and non-functional. Also trust. Consider the collaborating services that establish that the pre-conditions are in place prior to execution, the business transaction services, and then the services that certify the post conditional state(s) perhaps prior to commit or rollback. Much of this information should have been captured in the service design specification using UML, which would of course make the task much easier. Sadly not many have comprehended this, yet.
Impacts of the service approach
Over the past 18 months we have developed a vast amount of material that documents the impacts of implementing these first principles. Of course much of this is in our analysis reports published in the monthly CBDI Journal. Other material has been developed as presentations which we have been giving in both public and private. Today we are making all this material available to our members as fully scripted presentationware. These materials represent a mature communications vehicle that provides practical guidance on how to architect, design and implement service based applications.
We plan to continue to developing these materials and will be publishing updates on a monthly basis that relate to new published reports, as well as adding new subject specific modules and updating existing modules. The materials inventory can be viewed here by all CBDi Forum members.
Copyright CBDi Forum Limited 2002. The CBDi Forum is an analysis firm and think tank, providing insight on component and web service technologies, processes and practices for the software industry and its customers. To register for the weekly newswire click here.
For More Information:
- Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
- Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
- For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
- Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.
- Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
- Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
- Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.