An SOA timeline (from XML to Web services to SOA)

We begin our timeline by covering the history of key industry developments that have emerged to shape the current SOA platform. We then take a look at how the emancipation of SOA as a contemporary architectural platform in its own right has altered the roles of XML and Web services technologies.

4.1.1. XML: a brief history

Like HTML, the Extensible Markup Language (XML) was a W3C creation derived from the popular Standard Generalized Markup Language (SGML) that has existed since the late 60s. This widely used meta language allowed organizations to add intelligence to raw document data.

XML gained popularity during the eBusiness movement of the late 90s, where server-side scripting languages made conducting business via the Internet viable. Through the use of XML, developers were able to attach meaning and context to any piece of information transmitted across Internet protocols.

Not only was XML used to represent data in a standardized manner, the language itself was used as the basis for a series of additional specifications. The XML Schema Definition Language (XSD) and the XSL Transformation Language (XSLT) were both authored using XML. These specifications, in fact, have become key parts of the core XML technology set.

The XML data representation architecture represents the foundation layer of SOA. Within it, XML establishes the format and structure of messages traveling throughout services. XSD schemas preserve the integrity and validity of message data, and XSLT is employed to enable communication between disparate data representations through schema mapping. In other words, you cannot make a move within SOA without involving XML.

4.1.2. Web services: a brief history

In 2000, the W3C received a submission for the Simple Object Access Protocol (SOAP) specification. This specification was originally designed to unify (and in some cases replace) proprietary RPC communication. The idea was for parameter data transmitted between components to be serialized into XML, transported, and then deserialized back into its native format.

Soon, corporations and software vendors began to see an increasingly large potential for advancing the state of eBusiness technology by building upon the proprietary-free Internet communications framework. This ultimately led to the idea of creating a pure, Web-based, distributed technologyone that could leverage the concept of a standardized communications framework to bridge the enormous disparity that existed between and within organizations. This concept was called Web services.

The most important part of a Web service is its public interface. It is a central piece of information that assigns the service an identity and enables its invocation. Therefore, one of the first initiatives in support of Web services was the Web Service Description Language (WSDL). The W3C received the first submission of the WSDL language in 2001 and has since continued revising this specification.

To further the vision of open interoperability, Web services required an Internet-friendly and XML-compliant communications format that could establish a standardized messaging framework. Although alternatives, such as XML-RPC, were considered, SOAP won out as the industry favorite and remains the foremost messaging standard for use with Web services.

In support of SOAP's new role, the W3C responded by releasing newer versions of the specification to allow for both RPC-style and document-style message types. The latter are used more frequently within SOAs. Eventually, the word "SOAP" was no longer considered an acronym for "Simple Object Access Protocol." As of version 1.2 of the specification, it became a standalone term.

Completing the first generation of the Web services standards family was the UDDI specification. Originally developed by UDDI.org, it was submitted to OASIS, which continued its development in collaboration with UDDI.org. This specification allows for the creation of standardized service description registries both within and outside of organization boundaries. UDDI provides the potential for Web services to be registered in a central location, from where they can be discovered by service requestors. Unlike WSDL and SOAP, UDDI has not yet attained industry-wide acceptance, and remains an optional extension to SOA.

Custom Web services were developed to accommodate a variety of specialized business requirements, and a third-party marketplace emerged promoting various utility services for sale or lease. Existing messaging platforms, such as messaging-oriented middleware (MOM) products, incorporated Web services to support SOAP in addition to other message protocols. Some organizations were also able to immediately incorporate Web services to facilitate B2B data exchange requirementsoften as an alternative to EDI (Electronic Data Interchange).

4.1.3. SOA: a brief history

It wasn't long before organizations began to realize that instead of just accommodating existing distributed applications, Web services could become the basis of a separate architectural platforma platform that could leverage the benefits of the Web services technology set to realize the concept of services in the enterprise. Thus, service-oriented architecture entered the IT mainstream.

At this point an SOA was frequently classified in different ways, often depending on the implementation technology used to build services. An early model, mostly inspired by the initial set of Web services standards, defined SOA as an architecture modeled around three basic components: the service requestor, the service provider, and the service registry (Figure 4.1).

Figure 4.1. An early incarnation of SOA.

First-generation Web services standards fulfilled this model as follows:

• WSDL described the service.
• SOAP provided the messaging format used by the service and its requestor.
• UDDI provided the standardized service registry format.

From a physical architecture perspective, this first variation of a Web services-based SOA actually goes beyond the primitive SOA model we established in Chapter 3. You may recall that our primitive SOA did not require the use of a service registry. Instead, discoverability is classified as one of the contemporary SOA characteristics and is promoted, on a service-level, through service orientation priciples.

Our primitive SOA model is easily attained today, as it is supported by all major vendor development and runtime platforms. These same vendors have big plans for SOA, many of which are manifesting themselves right now. Numerous of the contemporary SOA characteristics we introduced in Chapter 3 are the result of aggressive development and collaborative initiatives which have produced a series of extensions to the first-generation Web services platform. Known as the "second-generation" or "WS-*" specifications, these extensions address specific areas of functionality with the overall goal of elevating the Web services technology platform to an enterprise level.

Complementing the WS-* landscape was also an interest in applying service-orientation concepts to the world of business analysis. Through service-orientation, business logic can be cleanly encapsulated and abstracted from the underlying automation technology. This vision has been further supported by the rise of business process definition languages, most notably WS-BPEL. These not only allowed for the decomposition of traditional Business Process Management (BPM) models into a series of services, they further bridged the gap between analysis and implementation by providing a language capable of fully expressing business logic in a concrete and executable format.

These and other industry influences have broadened the scope and potential of SOA. As more contemporary characteristics are added, it is likely that what we classify as a contemporary SOA today will form the basis for a primitive SOA in the future.

SOA is truly an evolution. Its prominence today is the result of numerous interrelated initiatives driven by a variety of standards organizations and software vendors. Through a volatile environment fueled by a mixture of collaboration and competition, extensions are being strategically positioned, each defining a specific part of what we are calling the contemporary SOA technology platform. In section 4.2 we take a closer look at the standards development processes.

4.1.4. How SOA is re-shaping XML and Web services

As with any architecture, SOA introduces boundaries and rules. Though contemporary SOA is made possible by the XML and Web services technology platforms, these platforms are required to undergo a number of changes in order for their respective technologies to be properly positioned and utilized within the confines of service-oriented architectures.

Traditional distributed application environments that use XML or Web services are therefore in for some rewiring as service-oriented design principles require a change in both technology and mindset. Following are some examples of potential issues you may be faced with when having to retrofit existing implementations.

• SOA requires that data representation and service modeling standards now be kept in alignment. This rather vague requirement has many implications and is fundamental to fostering intrinsic interoperability.

  Note

  A number of these issues are explored in more detail in the Considerations for positioning core SOA standards section of Chapter 14.

• SOA relies on SOAP messaging for all inter-service communication. As a result, any place that XML needs to go, SOAP messages are generally there, taking care of transportation, interim processing and routing, and the ultimate delivery. XML documents and associated XSD schemas now constantly need to be modeled with SOAP messaging in mind.
• SOA standardizes the use of a document-style messaging. The shift from RPC-style to document-style messages imposes change on the design of service descriptions. Specifically, interface characteristics need to be expressed in more generic terms, and the overall operation granularity increases.
• Due to this emphasis on document-style SOAP messages, SOA promotes a content and intelligence-heavy messaging model. This supports service statelessness and autonomy, and minimizes the frequency of message transmissions. Whereas previously RPC-style approaches supported the transmission of granular XML documents with targeted data, XML documents within SOAs often need to represent bundled data related to more than one data context.
• Until the advanced messaging capabilities of WS-* extensions become commonplace, many applications will need to be outfitted with custom SOAP headers to implement interim solutions to manage complex message exchanges. Some of the more pressing requirements include context management and correlation. These interim designs effectively establish transition models that need to be designed in such a manner that they are easily migrated to industry-standard implementations.