Planning_and_Impleme.. - didier beck weblog

Planning and Implementing SOA
www.butlergroup.com
Governance can be split into design-time governance and run-time. Design-time governance covers service
assets within a registry and/or repository. Such assets can include the service description (WSDL),
documentation, schemas, namespaces, taxonomies, Business Process
Execution Language (BPEL), and so on.
One of the key
aspects of designtime
governance is
the need to control
what is developed,
which should always
be driven by the
business need.
One of the key aspects of design-time governance is the need to control what
is developed, which should always be driven by the business need. One
organisation found that when it identified a particular business-relevant
service, and then investigated what existed that could be mapped to that
service, it found that there were already some 20-odd versions of that service
in existence – requiring significant re-design to consolidate. However, good
governance must not stand in the way of innovation; it should seek to de-risk
it. This will be one of the greatest challenges to the IT function – how to
manage SOA carefully without restricting the organisation.
Run-time management and governance will converge with traditional
systems management.
Standard IT systems management usually covers applications that operate on one platform, although of
course there are already technologies that enable common management across several platforms. However,
as an organisation starts to deploy SOA-based applications, management of an operational SOA will require
additional thought and preparation.
The major challenge for management of SOA is that the services may not all be within the same domain.
Service management consoles are used to monitor and manage performance issues within an organisation’s
infrastructure, but when a service could be running externally to the
organisation, it is necessary to then establish performance metrics about that
service in a standards-based manner.
Run-time governance usually concerns the messages flowing across the
message transport system, and usually relates to SOA policy and security
management. However, run-time governance can also control elements such
as routing and transformation – capabilities that can be performed by an ESB
but could also be carried out by policy management.
Run-time governance
usually concerns the
messages flowing
across the message
transport system, and
usually relates to SOA
policy and security
management.
The run-time management aspects cover logging (auditing), performance
management, monitoring, and alerts. Such run-time management may be
particularly relevant if a service fails to run as expected, allowing a request to
be routed to a back-up or alternative service that is available, but which may have a different cost. An
example of this might be a credit-check service. Usually the organisation might use a low-cost service, but
if this is not available for some reason then it may be appropriate to access a more expensive alternative,
or it may be preferable to wait until the cheaper one is available. Policies may need to be accessed here to
help make the decision.
Routing of messages may be used to perform load-balancing functionality in order to improve performance.
For example, if some services had a very high service level defined, then it may be necessary for the SOA
management infrastructure to hold back services with a lower Service Level Agreement (SLA) to enable
critical services to be performed first in order to meet the required SLA, and also to send alerts if the critical
SLA is breached. Many organisations will require the ability to define quality of service requirements for
individual services, creating a graded service structure.
SOA governance tools usually include the ability to define and maintain policies for service management.
Some products on the market allow different qualities of service to be made available; for example, IONA’s
Artix Enterprise Service Bus can be extended to provide quality of service capability, but is also available
without this if service level monitoring is not required.
One issue that is particularly likely to arise where a service is used by many third parties is the potential
for it to become over-used, and here the SOA management offering will need to have the ability to ‘throttle’
services to restrict them in order to prevent it impacting others adversely.
16 Section 1: SOA Deployment
December 2006