Planning_and_Impleme.. - didier beck weblog
Planning_and_Impleme.. - didier beck weblog
Planning_and_Impleme.. - didier beck weblog
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
www.butlergroup.com<br />
<strong>Planning</strong> <strong>and</strong> <strong>Impleme</strong>nting SOA<br />
The Role of the Registry<br />
One of the problems that arose with early Web services was around service identification, with frequent<br />
stories of services being ‘discovered’ through discussions around the coffee machine or in passing in the<br />
corridor. Services could rapidly become far more popular than anticipated <strong>and</strong> performance may become an<br />
issue. Equally, services could have been created that served no business need,<br />
<strong>and</strong> were therefore not used. It is vital to define a common central store for<br />
information about services – often called a registry. A registry can be used for<br />
much more than simply keeping basic information about services – it can be<br />
used both at design time <strong>and</strong> run-time so that policy-based information can<br />
be dynamically accessed at run-time for detailed control.<br />
The service registry<br />
can support<br />
sophisticated<br />
dependency <strong>and</strong><br />
impact analysis.<br />
The service registry can support sophisticated dependency <strong>and</strong> impact<br />
analysis. Even though a service should be self-contained, it may still impact<br />
another when used in a composite application. In addition, it will be valuable to identify which services<br />
interact with one another when the need to modify a service arises – if too many services might depend on<br />
it, this could be an occasion when it is appropriate to create a new service that has some similar<br />
functionality, rather than create a new version.<br />
An area that will be interesting to watch over the coming months will be what happens in the area of<br />
CMDBs. Today, these are used in the IT service management arena to maintain <strong>and</strong> manage information<br />
about various IT-related assets – <strong>and</strong> services can equally be regarded as assets, just as applications <strong>and</strong><br />
systems are at the moment.<br />
The Service Contract<br />
When two parties agree to do business with one another, it is very wise to set up a contractual agreement<br />
that covers what the provider will deliver, <strong>and</strong> what the consumer expects. The same applies within a SOA;<br />
it is sound practice to define the contract <strong>and</strong> obligations between consumers <strong>and</strong> providers, <strong>and</strong> these will<br />
be interdependent. Often the service definition (as given in the Web Services Definition Language (WSDL)<br />
for a Web service) is regarded as sufficient, but in practice rather more will be necessary. There are a<br />
number of other things that need to be documented about a service’s agreement with its consumers, such<br />
as run-time performance expectations, who to call if the service breaks, charging models (if any), etc.<br />
SOA Lifecycle Management<br />
Within the applications area, we are seeing the emergence of the concept of Application Lifecycle<br />
Management (ALM), which covers the lifecycle of applications from origination through to deployment <strong>and</strong><br />
on to retirement. Services will need a similar degree of control throughout their lifecycle; something will<br />
trigger the creation of a service, <strong>and</strong> eventually it may need to be removed from service as it is no longer<br />
needed. Within ALM, change management is a particularly complex area.<br />
In SOA, version control is a highly contentious issue. Delegates at a recent Butler Group Masterclass on SOA<br />
had some robust discussions on whether a service should be able to have multiple versions or not. The<br />
conclusion of the debate was not unequivocal – most services are likely to change over time, <strong>and</strong> the change<br />
should be reflected by the creation of a new version. However, a service that could be used in a very longrunning<br />
business process might need to be kept stable. The important thing is that the service interface<br />
should not change unless the version changes – minor details of how the service operates could, in theory,<br />
be accommodated without a version change.<br />
Lifecycle management issues cover service development, testing, staging, <strong>and</strong> production. Moving from one<br />
phase to another can be a complicated challenge, <strong>and</strong> the move for mainstream application management<br />
vendors to acquire the more specialist SOA management vendors is likely to prove beneficial here.<br />
Design-time Management <strong>and</strong> Governance<br />
A building relies on having good foundations – no matter how good a quality the bricks, doors, windows,<br />
<strong>and</strong> the construction itself, if the foundation is not sound then there is a risk that the building will collapse<br />
if the strain becomes too great (for example, if there is an earth tremor). The same metaphor can be applied<br />
to services – if a really ‘cool’ service is developed <strong>and</strong> proves highly popular, overuse of that service could<br />
cause the whole infrastructure to grind to a halt. Some of this will be down to the platform but the majority<br />
comes down to good governance <strong>and</strong> management.<br />
December 2006 Section 1: SOA Deployment 15