Planning_and_Impleme.. - didier beck weblog

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