One of the key objectives that drives the development and elaboration of SOA is the notion that bits and pieces of application logic can reside on various servers and other machines on a network, yet work together to provide the data and services that users need. From a less Olympian standpoint, it probably makes sense to point out that relying on third parties to handle funds (e-commerce providers), fulfill product orders (fulfillment houses), ship and track products (shipping service providers), and so forth, enables a wide range of companies and organizations to conduct business online without having to create their own complete, end-to-end business infrastructures.
For such distributed and disjoint architectures to work properly, however, it's essential that companies be able to exchange the right information with those partners they choose to handle their funds, fill orders, ship and track products or even provide customer service. That's where data interchange comes into play, and what explains the incredible panoply of data interchange standards used to enable partners to communicate with one another clearly, unambiguously, securely and in a timely fashion.
Given its explicit, formal, and highly readable structure and syntax, XML has become the technology of choice for represented data when it must pass from some producer of information to some corresponding consumer of information. Of course, the existence of tools galore that can handle the nuts and bolts tasks involved in parsing and interpreting document type definitions based on legacy SGML, as well as those based on more modern document schemas of one kind or another, also helps to explain why XML has become the foundation for data interchange of all kinds nowadays from accounting and authentication to zoology and taxonomies of all kinds.
The Organization for the Advancement of Structured Information Standards, better known as OASIS, makes an excellent case in point. This group houses a service-oriented architecture (SOA) committee that seeks to codify and standardize "best practices principles and patterns related to service-aware, enterprise-level, distributed computing," where such standards efforts "focus on workflows, translation coordination, orchestration, collaboration, loose coupling, business process modeling, and other concepts that support agile computing." A quick look at the technical committee efforts that fall under this umbrella will help to illustrate the kinds of issues that it seeks to address:
- ebSOA (Electronic Business Service Oriented Architecture) operates a wiki that continues work on the ebXML technical architecture to take new releases of the ebXML and other specifications into account, including work from the W3C Web Services Architecture working group.
- FWSI (Framework for Web Services Implementation) has produced a Web service implementation methodology, and is drafting a 2.0 version of its functional elements specification.
- OASIS SEE (Semantic Execution Environment) aims to produce guidelines, justifications, and implementation directives for execution environments for semantic Web services. This is intended to create an infrastructure to enable semantics to be applied to service-oriented systems, along with intelligent mechanisms for consuming Semantic Web services.
- SOA Adoption Blueprints seeks to develop, circulate, maintain, and update example business profiles and "adoption blueprints" to illustrate practical deployment of services using SOA methodology and tools.
- SOA RM (Reference Model) seeks to define a base model for SOA, to encourage continued growth of various SOA implementations but also preserving common, shared understanding of what SOA is and how it should work.
- WSQM (Web Services Quality Model) seeks to create a quality model to operate in situations where parties contract with one another for various Web services, so as to permit their delivery at well-specified and understood levels of service quality. Ultimately, this will go so far as to include the specification of a Web Services Quality Description Language (WS-QDL).
At every step along this path, partners and associates work together using formal data representations to make sure the information they exchange is complete, correct and intelligible. All this incredible infrastructure is supported at all steps along the way by XML and related detailed XML specifications. In future tips in this series, we'll dig into the details to help you understand how these individual components combine to support general-purpose SOA capabilities.
About the author
Ed Tittel is a full-time writer and trainer whose interests include XML and development topics, along with IT Certification and information security topics. Among his many XML projects are XML For Dummies, 4th edition, (Wylie, 2005) and the Shaum's Easy Outline of XML (McGraw-Hill, 2004). E-mail Ed at etittel@techtarget.com with comments, questions or suggested topics or tools for review.
