Standards Stack Layers

Standards Stack Layers

As detailed previously, the XML standards stack consists of a few horizontal layers, with each layer dependent on the layer below it, and a few horizontal aspects that can be applied to multiple layers. Even though the aspects can be applied to multiple XML stan-dards stack layers, they too are dependent on at least one layer for their operation and technical completion.

Message-Oriented Protocols Versus

Document-Oriented Specifications

When looking at the XML standards stack, you’ll notice that one thing immediately stands out: Half of the diagram is “sideways.” This can be interpreted in a number of ways, but most important of these is the very nature of how XML is being used.

As you have countless times been informed, XML is just a document format. There is nothing specific about XML that dictates in what context it can be used, how it is to be exchanged, or even how it is to be presented to the user. As a result, there are many uses for XML. In general, the uses for XML fall into two different camps: message-oriented protocols and document-oriented specifications. These two camps differ in their approach toward using XML and the requirements put upon the language.

Message-oriented protocols are focused at facilitating communication between two par-ties. They invariably involve a dialogue that has an initiating party and a responding party. Sometimes these conversations occur in a synchronous manner (parties open and maintain connections that are serviced until completion) or in an asynchronous manner (parties have an ongoing conversation with no real beginning or end). Typically, specifi-cations targeted at meeting messaging needs are called protocols, because they specify a proper means of interaction between systems and users. Protocols also have a distinct set of layers in their architecture. One given protocol might depend on another layer for proper interaction with a system. As such, the message-oriented needs for XML are rep-resented by the layer hierarchy shown at the right side of the diagram.

Document-oriented specifications are a different beast. They consider XML to be a way to represent information that may or may not be transmitted between users. The trans-mission aspect of XML is irrelevant to document-oriented specifications, just as the specifics of document representation are irrelevant to message-oriented protocols. Document-oriented specifications care specifically about how an XML document is rep-resented or the information contained within the document is applied. As a result, docu-ment-oriented specifications can be applied to any XML document—and more specifically to any level of the message-oriented protocol stack. Due to the orthogonal nature of message-oriented protocols, it is represented by vertical bars that span the mes-sage-oriented protocol layers.

Because the XML base architecture forms a basis for all XML documents regardless of intent, and community specifications rely on both message- and document-oriented specifications for their operation, these two portions of the stack cut across both usage domains.

XML Base Architecture

All XML specifications share one thing in common: the use of XML. This seemingly circular reasoning is intended to establish the baseline for all specifications, namely the W3C XML Recommendation. This recommendation forms the base for all XML specifi-cations; therefore, this layer in the XML standards stack is known as the XML Base Architecture layer.

Of course, a layer can’t consist of just a single specification or protocol. First, we must acknowledge that the current release of the XML Recommendation, namely version 1.0, will most likely change and mutate over the course of its existence. As a result, the base won’t consist of just one specification, but perhaps two or more that different specifica-tions at higher levels in the stack may depend on. For example, when version 2.0 is released, perhaps some specifications will make use of it, whereas others will still depend on version 1.0. However, the greater reason for the existence of this layer in the stack is the fact that XML is surrounded by a host of other specifications that extend its reach into different technological areas. Many of these extend the “core” of what XML is and therefore represents additional specifications at this layer. For example, XML Schema, XLink, XPath, and DOM all represent additions to the base XML specification that enrich the language and provide support for the various upper levels of the hierarchy. As such, those are included in this layer.

So, what is the definition for the technologies that are included in this layer? We can define specifications and technologies in the XML Base Architecture layer as “those standards, specifications, protocols, and technologies that form a basis for the representa-tion of XML documents for all parties and uses, regardless of industry, context, or usage.” Therefore, it is clear that XML Schema falls into this layer, whereas XHTML, which is a presentational specification, does not.

XML Transport Layer

Because XML is just a data representation technology, it doesn’t physically go any-where. It needs to be transported from place to place in order for it to provide value to any set of parties in communication with each other—unless of course the XML docu-ments are meant only to be stored and not exchanged. Traditionally and most typically, XML sits at a fairly high level in the OSI network model, usually at the Presentation and Application layers, so it can take advantage of many of the existing network protocols to get from point A to point B. Typically, XML documents are sent via the Hypertext Transfer Protocol (HTTP), Simple Mail Transfer Protocol(SMTP), or the File

Transfer Protocol (FTP).

Despite this, there have been a number of efforts to utilize XML itself as a means for facilitating point-to-point communications, either by replacing some of the aforemen-tioned protocols or by augmenting them for better transfer of XML documents. Because these use XML as their document format, it makes sense for the Transport layer to be above the XML Base Architecture layer, but more appropriately, all message-based pro-tocols rely on a Transport layer for documents to be transmitted between communicating parties. One can simply use XML-based or non-XML-based protocols in the Transport layer, and it will be obvious that non-XML-based protocols don’t depend on XML for their operation.

Some of these XML-based transport efforts include the Blocks Extensible Exchange Protocol (BEEP or BXXP) and Jabber. Both aim to use XML as a means for defining messaging transport protocols or as a framework for exchange of messages in a networked environment.

XML Messaging Layer

The Messaging layer of the XML standards stack is where much of the work happens in packaging XML documents for transmission between communicating parties. Although the Transport layer takes care of the actual message transmission, information is first needed to determine who is to receive the message, how it should be handled, and what to do in the eventuality of transmission failures. Many specification efforts call this layer the Transport, Routing, and Packaging (TRP) layer, although they aren’t really specify-ing the transport mechanism per se but rather all the requirements needed by a transport protocol to handle the job effectively.

There are many components to the Messaging layer and issues that need to be taken into account when packaging and routing messages. Think of the Messaging layer as an enve-lope that surrounds the content to be transported. On a mail envelope, there are a few key features: a delivery address, a return address, postage, a postmark, and a physical enve-lope that keeps the contents away from prying eyes. These metaphors are quite relevant in the Messaging layer.

In the same manner that an envelope has a sending address and a return address, the Messaging layer specifies who is to receive the given content and who originated the content. This allows messages to be routed from place to place in a predictable fashion. However, the Messaging layer is more complex than the postal mail analogy in that many messaging specifications allow users to also specify intermediaries that can store and forward messages. Regardless of the technology used, this addressing or routing information is extremely important in the Messaging layer.

Postal mail also contains postage and a postmark. The direct analogy to this in the Messaging layer is the ability to specify transaction and nonrepudiation rules. Transaction rules dictate in what order the given message is to be processed, dependen-cies on other messages for processing, and timeouts for attempting to transmit to the receiving parties. This ensures that only the appropriate number of messages are processed in the correct order by the recipient. Nonrepudiation rules help ensure that a given message was in fact received by the other communicating party. Without a way of knowing whether the message was received and processed, it would be impossible to determine whether it just disappeared into the “ether.” These features of transaction con-trol and nonrepudiation help to ensure that message delivery is a reliable affair.

Finally, there is the issue of the envelope itself. The envelope serves two major purposes: to package the contents for delivery and to protect the contents from unauthorized access. Without the envelope, XML documents are just a loose assortment of metadata tags. The envelope provides a means for collecting and identifying these tags as a distinct data entity. In addition, the envelope can encrypt or otherwise restrict access to the con-tents contained within, in much the same way postal mail security envelopes protect their content from prying eyes.

Examples of XML messaging specifications include the Simple Object Access Protocol (SOAP), ebXML’s Transport, Routing, and Packaging (TRP) layer, and the RosettaNet Implementation Framework (RNIF). The W3C is also working on a specification, called the XML Protocol, that will extend concepts provided in SOAP. Each of these Message layer protocols solve the aforementioned problems, but in their own way. This difference in implementation can cause problems in interoperability. For example, if we all wrote our addresses in different ways on an envelope, the Postal Service would be unable to deliver our mail. The same can be said for different Message layer specifications. It is important to consider the interoperability of these specifications as they come into more widespread use.

Services Layer

Once we have addressed the issues of transporting and packaging XML documents for shipment across a network, the next layer involves ascribing some functionality to these various intersystem communications. This is where the Services layer fits. The term ser-vices, in this context, describes a set of exposed application functionalities that can be accessed by machines in a distributed manner. Such functionality can take the form of actual application code or simply messages communicated between systems in the process of accomplishing some task. In either case, the Services layer addresses the spec-ifications needed to accomplish these tasks.

The most common phrase heard nowadays with regard to services is loosely coupled. Systems that communicate using XML and Messaging layer protocols can exchange information without having to know too much about how the other system plans to process that information. Such systems are known as loosely coupled systems.

The word coupled denotes that the two systems are connected to each other in some fashion, whereas the term loosely means that they are connected in the least restrictive of manners.

Services layer specifications accomplish this goal of providing loosely coupled systems by encapsulating system functionality in a manner that exposes required inputs and out-puts while abstracting processing methodology. The best example of Services layer func-tionality is the Web Services Description Language (WSDL). WSDL forms a core component of the overall Web Services architecture that leverages SOAP as its routing and packaging layer. Because Services layer specifications expose application functional-ity while masking application processes, it is important for systems to understand the inputs and outputs required by the specific Services layer component. Protocols such as WSDL specify these things while also helping systems understand the data requirements of these inputs and outputs, error processing requirements, and general data handling.

Process Layer

Once application logic and functionality has been encapsulated and defined in the Services layer, turning that functionality into coordinated action is the responsibility of specifications in the Process layer. Process layer specifications concentrate on organizing individual functionality components into larger applications that aim to solve an overall business problem or meet a usage goal. In the same manner that software applications are a sum of their objects and program components, XML-based applications are the sum of their Service layer components.

Some of the key parts of turning functionality into action include the ability to wire ser-vice components together with workflow and logic. Process layer specifications aim to provide a mechanism to identify when certain pieces of functionality should be executed, the proper branching for evaluation of functionality results, and when various processes begin and end. The workflow behind an application helps to tie these disparate compo-nents into a cohesive system that embeds the logic of human-based systems into a machine-based exchange. Workflows also allow human interaction to occur at various points in the machine-to-machine dialogue.

Speaking of dialogue, the main goal of Process layer specifications is to organize these transactions into larger dialogues that represent an actual business function, rather than an application function. For example, a Process layer may embody a “Purchase Goods” process, which in turn actuality consists of many individual transaction-based functions such as “Request Product Availability,” “Place Product Order,” “Submit Purchase Order,” and “Process Invoice.”

Process layer specifications include RosettaNet Partner Interface Processes (PIPs), the Business Process Markup Language (BPML), and various workflow specifications.