It is very important to view and position SOA as an architectural model that is agnostic to any one technology platform. By doing so, an enterprise is given the freedom to continually pursue the strategic goals associated with service-oriented computing by leveraging future technology advancements.
- 1 Services as Web Services
- 2 Service Models and Service Layers
- 3 Service Inventory Blueprints
- 4 Service-Oriented Analysis
- 5 Service-Oriented Design
Services as Web Services
In the current marketplace, the technology platform most associated with the realization of SOA is Web services.
Figure: Service-oriented solutions can be comprised of services built as Web services, components, or combinations of both.
The popularity of Web services preceded that of service-oriented computing. As a result, their initial use was primarily within traditional distributed solutions wherein they were most commonly used to facilitate point-to-point integration channels. As the maturity and adoption of Web services standards increased, so did the scope of their utilization.
With service-oriented computing comes a distinct architectural model that has been positioned by the vendor community as one that can fully leverage the open interoperability potential of Web services, especially when individual services are consistently shaped by service-orientation. For example, when exposing reusable logic as Web services, the reuse potential is significantly increased. Because service logic can now be accessed via a vendor-neutral communications framework, it becomes available to a wider range of service consumer programs.
Additionally, the fact that Web services provide a communications framework based on physically decoupled service contracts allows a service contract to be fully standardized independently from its implementation. This facilitates a potentially high level of service abstraction while providing the opportunity to fully decouple the service from any proprietary implementation details. As explored at www.soaprinciples.com, all of these characteristics are desirable when pursuing key principles, such as Standardized Service Contracts, Service Reusability, Service Loose Coupling, Service Abstraction, and Service Composability.
About Web Services (Part I)
The Web services platform is defined through a number of industry standards that are supported throughout the vendor community. This platform can be partitioned into two clearly identifiable generations, each associated with a collection of standards and specifications:
First-Generation Web Services Platform
The original Web services technology platform is comprised of the following core open technologies and specifications:
– Web Services Description Language (WSDL)
– XML Schema Definition Language (XSD)
– SOAP (formerly the Simple Object Access Protocol)
– UDDI (Universal Description, Discovery, and Integration)
– WS-I Basic Profile
These specifications have been around for some time and have been adopted across the IT industry. However, the platform they collectively represent seriously lacks several of the quality of service features required to deliver mission critical, enterprise-level production functionality.
Second-Generation Web Services Platform (WS-* extensions)
Some of the greatest quality of service-related gaps in the first-generation platform lie in the areas of message-level security, cross-service transactions, and reliable messaging. These, along with many other extensions, are being provided by the second-generation Web services platform.
Consisting of numerous specifications that build upon the fundamental first-generation messaging framework, this set of Web services technologies (generally labeled as “WS-* extensions”) provides a rich feature-set far more complex both in technology and in design.
Some of the notable WS-* specifications include:
– WS-Security (and WS-SX)
– WS-Coordination, WS-AtomicTransaction, WS-BusinessActivity (and WS-TX)
– WS-ReliableMessaging (and WS-RX)
About Web Services (Part II)
A typical Web service is comprised of the following:
– A physically decoupled technical service contract consisting of a WSDL definition, an XML schema definition, and possibly a WS-Policy definition. This service contract exposes public functions (called operations) and is therefore comparable to a traditional application programming interface (API).
– A body of programming logic. This logic may be custom-developed for the Web service, or it may exist as legacy logic that is being wrapped by a Web service in order for its functionality to be made available via Web services communication standards. In the case that logic is custom-developed, it generally is created as components and is referred to as the core service logic (or business logic).
– Message processing logic that exists as a combination of parsers, processors, and service agents. Much of this logic is provided by the runtime environment, but it can also be customized. The programs that carry out message-related processing are primarily event-driven and therefore can intercept a message subsequent to transmission or prior to receipt. It is common for multiple message processing programs to be invoked with every message exchange.
Figure: Three variations of a single Web service showing the different physical parts of its architecture that come into play, depending on the role it assumes at runtime.
A Web service can be associated with temporary roles, depending on its utilization at runtime. For example, it acts as a service provider when it receives and responds to request messages, but can also assume the role of service consumer when it is required to issue request messages to other Web services.
When Web services are positioned within service compositions, it is common for them to transition through service provider and service consumer roles. Note also that regular programs, components, and legacy systems can also act as service consumers as long as they are able to communicate using Web services standards.
Service Models and Service Layers
Regardless of how services are implemented, they are commonly classified into one of the following service models:
– Entity Services
– Task Services (and Orchestrated Task Services)
– Utility Services
Service models help establish functional contexts and a functional boundaries services by providing generic, predefined types that are common to just about any IT enterprise.
Once established, service models can create conceptual service layers (logical groups) that can ease subsequent ownership assignment and overall service governance. Service layers also provide a unique perspective of the services within a given inventory, as most service compositions span multiple service layers.
Figure: Service models classify services and establish logical service layers. Service compositions typically span most service layers.
Service Inventory Blueprints
An ultimate goal of an SOA transition effort is to produce a collection of standardized services that comprise a service inventory. The inventory can be structured into layers according to the service models used, but it is the application of the service-orientation paradigm to all services that positions them as valuable IT assets in full alignment with the strategic goals associated with the SOA project.
However, before any services are actually built, it is desirable to establish a conceptual blueprint of all the planned services for a given inventory. This perspective is documented in the service inventory blueprint.
Figure: A conceptualized service inventory wherein services are organized into logical layers according to their service models.
There are several common business and data models that, if they exist within an organization, can provide valuable input for this specification. Examples include business entity models, logical data models, canonical data and message models, ontologies, and other information architecture models.
A service inventory blueprint is also known as a service enterprise model or a service inventory model.
To effectively deliver standardized services in support of building a service inventory, it is recommended that organizations adopt a methodology specific to SOA and consisting of structured analysis and design processes.
Within SOA projects, these processes are centered around the accurate expression of business logic through technology, which requires that business analysts play a more active role in defining the conceptual design of solution logic. This guarantees a higher degree of alignment between the documented business models and their implementation as services. Agnostic business services especially benefit from hands-on involvement of business subject matter experts, as the improved accuracy of their business representation increases their overall longevity once deployed.
Service-oriented analysis establishes a formal analysis process completed jointly by business analysts and technology architects. Service modeling, a sub-process of service-oriented analysis, produces conceptual service definitions called service candidates. Iterations through the service-oriented analysis and service modeling processes result in the gradual creation of a service inventory blueprint.
Figure: A look at how the collaboration between business analysts and technology architects changes with SOA projects.
While the collaborative relationship between business analysts and architects depicted at the lower half of the above figure may not be unique to an SOA project, the nature and scope of the analysis process is.
The service-oriented design process uses a set of predefined service candidates from the service inventory blueprint as a starting point from which they are shaped into actual physical service contracts.
When carrying out service-oriented design, a clear distinction is made between service candidates and services. The former represents a conceptual service that has not been implemented, whereas the latter refers to a physical service.
As shown in the following figure, the traditional (non-standardized) means by which Web service contracts are generated results in services that continue to express the proprietary nature of what they encapsulate. Creating the Web service contract prior to development allows for standards to be applied so that the federated endpoints established by Web services are consistent and aligned.
Figure: Unlike the popular process of deriving Web service contracts from existing components, SOA advocates a specific approach that encourages us to postpone development until after a custom designed, standardized contract is in place.
This “contract first” approach lies at the heart of service-oriented design and has inspired separate design processes for services based on different service models.