CBDI Web Services Roadmap - Guiding the Transition to Web Service and SOA

Sponsored by

Sponsored Papers

Vendor Web Services Roadmap Report - IBM. IBM's strategy today is centered around "Business On Deman...
more

Many Organizations are now undertaking development of service oriented architectures, but the probab...
more

Whilst investment in Application Integration initiatives over the last decade has undoubtedly improv...
more

Moving to SOA cont'd...

Introduction

First it is useful to differentiate between Service Oriented Architecture (SOA) and Web Services. SOA is the broad set of concepts that enable units of functionality to be provided and consumed as Services. This essentially simple concept can and should be used, not just for Web Services, but also at each tier of the architecture, in order to compartmentalize and provide flexibility.

What some enlightened organizations have been doing over the past year or so is restructuring their application base to expose core services so that they can be reused in a loose coupled manner. By loose coupled we are not necessarily referring to specific protocols or behaviors, but the reduction of dependency and increased separation that allows the core service to be more easily used. And more easily means lower resource, lower cost and faster change.

Whilst WSXX based protocols will naturally be used for publishing Services, various technologies will be utilized in creating the Service Oriented architecture. The really far sighted organizations will be implementing WSDL and a UDDI compliant registry throughout their architecture in order to formalize the publication of Service meta data, and to make reuse easier.

For more on SOA see related CBDI reports¹.

SOA Attribute	Description
Business Level Services	Services are published at a level of abstraction that corresponds to real world activity and recognizable business function. The really compelling aspect of this is the opportunity to implement comprehensive alignment and integration of the service life cycle with the business product and/or process life cycle.
Service Based Collaboration	Although Services are being widely used internally and for integration purposes this technical orientation will change soon enough. Services will increasingly mirror real world business activity, such that data is obtained from the real source in real time, that combinations of Services from collaborating organizations cooperate to provide value added Services. Whilst there will be infrastructural differences covering matters such as security between internal and externally supplied Services, increasingly there will be a common Service model that allows seamless operation of business processes internal and external to the enterprise. Although Services may be simple, they may also be aggregated from different sources, again reflecting real world business activities. There is clearly a real requirement for Service interaction and dependency modeling.
Separation of Interface from Implementation	A core tenet of SOA is that it's the interface (as opposed to the application) that is integrated, in a manner that the consumer has no visibility of the implementation. Some call this "Interface Based Design", a well understood technique from Component Based Development. However this is a rather technical perspective. Services are offered at a business level of abstraction, which renders the interface a business interface, and this generally means a contract, which is expressed in XML.
Contract based integration	The importance of the contract in SOA cannot be overestimated. The formal contract is the device that allows us to create virtual businesses, formalize system and scope boundaries, minimize dependencies and maximize adaptability, use black box testing and have a choice of Services and more easily change supplier. Although there is some work in progress to bring Design by Contract into UML, and a vague intent to formalize contract elements in BPEL, this looks like an area with a lot of outstanding issues.
Separation between Provider and Consumer	Among other things, Service Oriented Architectures must be designed with a view to the ease of management - including supply risk management. If the enterprise is dependent upon a few key service providers, this represents a potential risk to the enterprise. This leads to a design goal of making service specifications as general as possible, which of course brings us directly into conflict with performance objectives.

Table 1 - SOA Attributes

It's About Better Integration

Although Web Services have stolen the limelight, what's actually happening in private, in enlightened companies, behind their enterprise firewalls, is restructuring. Because the business case for restructuring on service lines is obvious - it avoids application rebuild, it reuses what already exists and allows IT organizations to respond much more rapidly to new and changing requirements. That's going to reduce costs.

Many organizations tried to reuse (extend the life of, implement best of breed components) their existing applications by using Enterprise Application Integration (EAI). However most EAI efforts failed to cut it because, the most widely adopted approach was to tightly couple the implementations. For example projects were focused typically focused on application specific objectives such as interfacing Oracle with Seibel, rather than the logical level of creating single instances of collaborating business services. In contrast the Service based architecture establishes a more durable Services layer, where the integration point is the Service specification or the interface, not the implementation. This provides implementation transparency, where multiple implementations may be rationalized, or an older implementation upgraded, with minimal impact on the consumer of the Service. This establishes a loosely coupled architecture of services that have minimum dependencies and maximum platform independence that can be reused with minimum cost overhead.

Creating the Foundation

In the first part of our report series on SOA (reference above) we advise on the importance of using service thinking inside the enterprise.

There is no reason why these should not apply inside enterprise IT as well as outside. The result would be a single kind of interface, using the same technology, for all internal systems that provide a service. Many existing systems would need to be wrapped of course. And performance would have to be considered. However, the potential advantage of a single interface type, that maps to many programming languages, is a huge simplifier for enterprise systems. It's like a common hub - indeed, considering a number of other technologies that go with web services - such as message queuing, it's almost a must - a highly compelling simplifier. And simplification means effort reduction which means cost reduction and/or faster response to business needs.

Note that this also reduces the variety of invocation mechanisms. Each of these has its own programming model, and this is often visible in the applications making the requests. Wrapping all of these mechanisms with web services not only provides simplicity for the application developers, it also separates the communications and messaging infrastructures from applications. This means they can be evolved without impact on applications.

In the report we then discuss the limitations of wrapping. Sometimes it's the only possible way forward, as with the Chernobyl strategy discussed in above. But as with physical buildings, the strongest foundations will be established by a good underlying architecture. And this will be component based.

Best practice OO design suggests that objects should provide a defined service. It's the same with components. We identify two kinds of component - process components, which make use of the services of entity components. These will ideally be arranged according to the mediator pattern, which reduces dependencies. This makes the mediated components more re-usable by other process components. The component assembly is therefore complete in itself, and needs no code to glue the components together - the component middleware effectively does that dynamically at run-time. This is where the Generic Component Realization comes in. A Generic Component Realization is one where the component consists of a declarative specification or script, which is interpreted at run-time by some middleware engine - for example, a workflow engine. Such an engine can be thought of as a generic implementation, modified by the script, for all components that make use of that particular engine. This means that a workflow or B2B collaboration can be developed using many of the same concepts as components destined to be implemented on a J2EE or .NET environment.

In summary, the component concept can be applied to a wide variety of modules, whether built with compiled code, or declaratively scripted. Further, the autonomy characteristic of all components, from design through build into the run-time, means that its internals are opaque to all but the builder. The service oriented architecture is a classic component based architecture, but complemented with many different types of implementation and a service invocation layer.

The Business Service Bus

In the days when middleware was top of the technical architect's toy box, the notion of the transaction bus was very popular. But whilst this is a necessary layer, it's equally if not more important to develop the concept of the Business Service Bus. We first introduced this notion over two years ago, and since then it seems to have gained widespread acceptance because it is inherently simple.

The Business Service Bus is the set of business services for a specific domain that are available for widespread use across an enterprise. The services are published in a UDDI compliant registry which allows them to be reused without manual intervention by the provider. Usage policies are implemented as part of an authentication and approval system, which differs from external services only in relation to being inside the firewall. The services have been implemented using a standardized semantic set that normalizes local application semantics and rules.

One of the reasons for using the Business Service Bus is so that common specifications, policies, etc can be made at the bus level, rather than for each individual service. For example, services on a bus should all follow the same semantic standards, adhere to the same security policy, all point to the same global model of the domain. It also facilitates the implementation of a number of common, lower-level business infrastructure services that can be aggregated into other higher level business services on the same bus (e.g. they all use the same product code validation service).

Many organizations have attempted with mixed success to implement common components by rationalizing their installed application base. In contrast the Business Service Bus is based on the premise that there will be multiple implementations of the same business object, either now or in the future, and the purpose of the bus is to make those implementations transparent from service usage.

The overall objective is by definition, to establish a single logical bus structure. Whilst it might be natural (and politically easier) to implement bus structures that mirror organizational boundaries, the successful organization will see the real value in creating cross organizational services that allow the organization to evolve independently of the information services.