SOA and Web services

It is very important to view and position SOA as an architectural model that is agnostic to any one technology platform (Figure 3.21). 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. In the current marketplace, the technology platform most associated with the realization of SOA is Web services.

Figure 3.21

Service-oriented solutions can be comprised of services built as Web services, components, or combinations of both.

Web Services Standards

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), and the 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, represent 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-*") provides a rich feature-set far more sophisticated both in technology and in design. An example of a WS-* standard referenced throughout this book is WS-Policy.

Web Services Architecture

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.

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 (additional composition-related roles are explained in Chapter 13). Note also that regular programs, components, and legacy systems can also act as Web service consumers as long as they are able to communicate using Web services standards.

Figure 3.22 introduces the symbols used to illustrate physical representations of Web services in this book. Service-orientation principles can affect the design of all displayed parts.

Figure 3.22

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.

SOA: Principles of Service Design
  Home: Service-oriented computing and SOA: Introduction
  1: Design fundamentals: Design characteristics
  2: Design fundamentals: Design principles
  3:Design fundamentals: Design pattern and design pattern language
  4:Design fundamentals: Design standard
  5:Design fundamentals: Best practices
  6:Introduction to service-oriented computing
  7:Service oriented architecture
  8:Service compositions
  9:Understanding service oriented computing elements
  10:Entity services
  11:Web services and service oriented computing
  12:Service inventory blueprints
  13:Service-oriented analysis and service modeling
  14:Service-oriented design
  15:Goals and benefits of service-oriented computing
  16:Increased intrinsic interoperability
  17:Increased federation
  18:Increased vendor diversification options
  19:Increased business and technology domain alignment
  20:Increased ROI
  21:Increased organizational agility
  22:Case study background