Keywords: Service-oriented Architecture, SOA, Web Services, XML
Biography
Thomas Erl is the President and Chief Architect of XMLTC Consulting Inc., a consulting firm in Vancouver specializing in the delivery of service-oriented and XML-centric solutions. He recently authored "Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services" for Prentice Hall/PTR. This book was formally endorsed by IBM and Microsoft, and has being translated into Chinese. Thomas is currently writing "Service-Oriented Architecture: Concepts and Technology", due for release in 2005. Thomas has published over 30 papers, and established an integration framework for XML and Web Services. He also maintains a series of resource Web sites for XML and Web services. For more information, visit his bio site at www.thomaserl.com/technology/.
The realization of SOA through Web services is intrinsically driven by core XML technologies. The emergence of service-oriented design principles, however, is affecting how XML technologies are utilized and positioned within contemporary solutions.
1. Book Excerpt: Service-Oriented Architecture: Concepts and Technology
2. How XML and Web Services have shaped SOA
2.1 XML: a brief history
2.2 Web services: a brief history
2.3 SOA: a brief history
2.4 Summary of key points
3. How SOA is re-shaping XML and Web services
3.1 Summary of key points
The following paper is comprised of an excerpt from the upcoming book "Service-Oriented Architecture: Concepts and Technology" (published by PHPTR, ISBN: 0131858580), scheduled for release in 2005. The excerpt was copied from a draft of the manuscript with the permission of the publisher. The content in this paper is subject to change prior to the release of the book.
For more information about this book, visit: www.serviceoriented.ws.
So far we’ve taken the time to provide some background information to describe how legacy architectures compare with SOA. Continuing with that timeline, we now cover the history of key industry developments that have emerged to shape this renewed platform.
First, we take a look at how XML and its associated family of standards launched a new era of data representation that would become the foundation layer for SOA. Next, we discuss the evolution of the ever-expanding Web services technology platform, that went on to become the foremost implementation technology for physical services. This is followed by an explanation of how the marriage between existing service-oriented principles and XML and Web services-related technology innovations have resulted in what we’ve been referring as contemporary SOA.
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 70’s. This widely used meta language allowed organizations to add intelligence to raw data, and exchange meta-tagged information with partner organizations.
XML was developed in response to the eBusiness movement of the late 90’s, 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 set 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 all authored using XML. These three specifications, in fact, that have become key parts of the core XML technology set.
This 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 an SOA without involving XML.
In 2000, the W3C received a submission for the Simple Object Access Protocol (SOAP) standard. 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, Internet-based, distributed technology. One that was not only designed specifically to function via existing Internet protocols, but one that could leverage the concept of a standardized communications framework to bridge the enormous amount of 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 what assigns the service an identity and enables its invocation. Therefore, one of the first initiatives in support of Web services was the Web Service Definition Language (WSDL). The W3C received the first WSDL specification submission in 2001, and has continued aggressively revising this standard. A WSDL file is the central piece of information that describes a Web service.
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. In support of SOAP’s new role, the W3C responded by releasing newer versions of the standard to support both RPC-centric and document-centric message types. The latter are used almost exclusively within SOAs.
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.
A third-party marketplace emerged promoting various utility services for sale or lease, and custom Web services were developed to accommodate a variety of specialized business requirements. Existing messaging platforms, such as messaging-oriented middleware (MOM) products incorporated Web services to support SOAP in addition to other message protocols, and some organizations were able to immediately incorporate Web services to facilitate B2B data exchange requirements – often as an alternative to EDI solutions.
As the interest in Web services skyrocketed, major software vendors aggressively developed a series of extensions to the first-generation standards. Known as the second-generation or WS-* standards, these specifications addressed specific areas of functionality with the overall goal of elevating the Web services technology platform to an enterprise level.
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 platform. A platform that could realize the concept of partitioning an enterprise into a series of autonomous services. Thus, service-oriented architecture was reborn, rejuvenated with a technology platform truly capable of delivering its original goals.
As stated in previous chapters, 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, standards are being strategically positioned, each defining a specific part of what we are calling the contemporary SOA technology platform. (At the end of this chapter we take a closer look at the standards development processes.)
• The core XML technology set was developed in response to eBusiness requirements for distributed Internet architectures. It now also represents a foundation data representation and management layer for SOA.
• The first-generation Web services architecture grew out of the development of three key standards: WSDL, SOAP, and UDDI. While UDDI is still an optional discovery mechanism for most environments. WSDL and SOAP have become core technologies that build upon the XML layer to define the fundamental communications framework for SOA.
• SOA fully leverages the roads paved by the XML and Web services initiatives. Its marriage of proven concepts with progressive technology has been fully embraced by the global IT community. Its adoption rate will depend on the pace at which WS-* standards can extend the first-generation framework, however its arrival as the next de facto technology architecture seems inevitable.
We’ve established so far that the realization of SOA through Web services is intrinsically driven by core XML technologies. 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.
In Chapter 3 we covered the fundamental principles of service-orientation, and how these principles are implemented within a primitive SOA. This discussion was followed by an extensive list of the common characteristics of contemporary SOA. To support the fulfillment of service-oriented principles, and the realization of the potential available to contemporary SOA, a number of design issues need to be taken into consideration when working with XML and Web services technologies. These relate primarily to aligning XML documents, service definitions, and supporting standards so as to continually promote the many characteristics we discussed previously.
In Chapters 12, 13, and 14 we review each of the primary XML and Web services standards individually, and discuss the details of how they should be applied within the context of SOA. In order to raise an awareness of the range of potential issues you may be faced with when having to retro-fit existing implementations, here’s a glimpse of what’s ahead:
• 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 a fostering intrinsic interoperability. See Chapter 12 for more information.
• 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 now need to be constantly modeled with SOAP messaging in mind. Chapter 12 provides examples for how traditional XML modeling approaches are affected.
• SOA standardizes the use of a document-centric messaging model. The shift from RPC-centric to document-centric messaging requires a significant change in the design of Web service descriptions. Specifically, interface characteristics need to be expressed in more generic terms, and the overall operation granularity increases. See Chapter 13 for more details on how WSDL definitions need to be designed to promote service-orientation.
• Due to the emphasis on document-centric SOAP messages, SOA promotes a content and intelligence-heavy messaging model. This preserves service autonomy and minimizes the frequency of message transmissions. Whereas previously, RPC-centric 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. Chapter 12 covers this complex topic.
• XML schemas associated with SOAP message payloads often need to be designed with some of the more advanced features of the XML Schema Definition Language. Specifically, the use of extensible or redefined schemas may be required when building documents that represent multiple data contexts. The role of XML schema definitions within SOAs is explored further in Chapter 12.
• Further, the use of conditional validation logic is a sometimes requirement for when data models residing in larger-sized XML documents need to represent validation-related business rules that are processed at runtime. This is where XSLT may be incorporated to supplement XSD validation. How XSLT can be utilized to support SOAs is also discussed in Chapter 12.
• Until the advanced messaging capabilities of WS-* standards become commonplace, many solutions will need to be outfitted with custom SOAP headers in order to implement interim solutions to manage complex message exchanges. Some of the more pressing requirements include context management, reliable messaging, and correlation. These interim designs effectively implement transition models that need to be designed in such a manner that they are easily migrated to industry-standard implementations. Chapter 14 covers the primary WS-* standards, as they relate to service-oriented architecture.
Traditional distributed application environments that use XML or Web services are in for some rewiring as service-oriented design principles require a change in both technology and mindset. A good portion of this book is dedicated to discussing the details of this important topic.
• Though contemporary SOA has been shaped by the emergence and industry-wide acceptance of XML and Web services, the arrival of SOA introduces changes to the manner in which XML and Web services have been traditionally applied.
• Many of these changes affect how XML documents should be modeled. In particular, standardized SOAP messaging imposes a transition from RPC-centric to document-centric models.
• Second-generation Web services standards are being positioned to realize enterprise-level SOAs. However, Web services designed for today’s hybrid and service-oriented architectures need to be prepared to assume the many advanced features provided by these standards.
XHTML rendition made possible by SchemaSoft's Document Interpreter™ technology.