The Internet Protocol Journal - Volume 9, Number 4

Boosting the SOA with XML Networking

by Silvano Da Ros

In the 1990s, the widespread adoption of object-oriented programming (OOP) and advancing network technologies fostered the development of distributed object technologies, including Object Management Group's (OMG's) Common Object Request Broker Architecture (CORBA) and Microsoft's Distributed Common Object Model (DCOM). Both CORBA and DCOM follow the OOP consumer-producer service model, where applications locally instantiate any number of objects and execute methods for the objects to obtain a service. However, with distributed object technologies, a local application can request a service from a remote application by instantiating a remote object and executing the methods of the object using Remote Procedure Call (RPC) over the network. The local application executes the methods of the remote object as if the object were an inherent part of the local application.

To push toward a simpler consumer-producer service model than distributed objects, the Service-Oriented Architecture (SOA) was created as a worldwide standards-based application interoperability initiative [1]. SOA differs from distributed object technologies, because you no longer deal with object instantiation and method invocation to provide services between your applications [2]. Instead, you can create Extensible Markup Language (XML)-based standard Web services to exchange XML documents between your applications using Internet-based application layer protocols, such as Hyper Text Transfer Protocol (HTTP) and the Simple Mail Transfer Protocol (SMTP).

This is where XML networking comes into the picture. This article shows how to use SOA at the network edge, in conjunction with XML within the network, to help with the work required for enabling interoperability between your applications. The problem with SOA on its own is that to scale applications, hardware and software upgrades are required on the servers where your business logic resides. Because application integration using XML is CPU-intensive, it benefits from XML hardware built specifically for XML computations. However, the applications servers that run your business logic are effectively independent of the underlying XML processing. Therefore, to accelerate the SOA at the network level transparently to the application, XML networking technologies can be used. XML networking can provide SOA acceleration using a special middleware-enabled network layer, which this article explains. This special network layer also provides additional benefits to your applications that SOA alone cannot provide at the edge, such as dynamic message routing and transformation.

To help in the understanding of SOA acceleration with XML networking, the following section discusses SOA and its constituent technologies. Further sections explore the specifics of XML and XML-based network processing.

A Brief History of SOA

Traditionally, hand-coding proprietary interfaces were required to interoperate between your applications, as Figure 1 illustrates. This task is a trivial one if you have only a few applications, but if you have numerous disparate applications, all requiring interfaces into one another, the result is a complex, many-to-many web of connections between them. In the 1980s, Electronic Data Interchange (EDI) was developed to standardize the message formats that trading partners use to exchange text-based transaction data residing on mainframes, making it an early predecessor to SOA.

Figure 1: The Proprietary Messaging Layer

Figure 1: The Proprietary Messaging Layer

In the mid-1990s, standard middleware (or integration brokers) became available, such as CORBA and DCOM mentioned previously, to integrate advanced client-server applications. Figure 2 shows how integration brokers allow you to perform the translations between end systems over a standard messaging layer without creating application-specific interfaces between each system. During the same time, numerous software vendors, such as IBM WebSphere and TIBCO, also developed standard messaging layer protocols, which required adding vendor-specific adapters within the common integration brokers. Additionally, with newer application development environments being adopted, such as Java 2 Sun Enterprise Edition (J2EE) and Microsoft .NET, even more programming complexity is required when considering application interoperability without using the SOA. Fortunately, these new platforms currently support the SOA, allowing an application developed in one platform to tap into the data supplied by an application developed in the other.

Figure 2: The Standard Messaging Layer

Figure 2: The Standard Messaging Layer

Figures 1 and 2 illustrate how the proprietary and standard messaging layers sit above the network stack—at best, a traditional network device can operate only up to and including the transport layer. For example, by tracking TCP connection state information, a firewall device allows you to configure security services for your applications. Some firewalls can inspect the context of the application, but only to ensure the application behavior is RFC-compliant and not performing some sort of malicious activity. Additionally, at the next layer down the stack, you can configure Layer 3 Quality of Service (QoS) functions, such as IP Precedence, Differentiated Services (DiffServ), traffic shaping, and resource reservation, to ensure delivery of traffic to your critical applications. Although the network layers can provide these intelligent network services to your applications, they do not add any value toward accelerating your SOA.

Notice how the middleware portion in the proprietary messaging layer in Figure 1 takes up a larger portion of the application stack than the standard messaging layer from Figure 2. This situation occurs because the list of available messages that your standard messaging layer applications support is now much smaller—the broker takes care of the interfacing complexity on behalf of your applications. A reduced number of messages requires that you maintain much less middleware programming code on your applications than if every application in your network had to account for the messages of every other application.

Optimizing the SOA

Now that you understand SOA, you can better understand where XML networking fits into the scheme of things. Figure 3 illustrates how network equipment vendors can add specialized "application-aware" intelligence into Layers 5 through 7 of the OSI model.

You can start by contrasting XML networking with traditional content networking technologies [3]. As you can see in Figure 3, by incorporating content networking services into the network, such as Server Load Balancing (SLB), caching, and Secure Sockets Layer (SSL) acceleration, network vendors give you the ability to transparently accelerate your applications without the need of application hardware upgrades. However, by residing only within the OSI model, content networking services and protocols provide a "network-oriented" way to accelerate your applications. In order to achieve full application awareness, you must look not only into the application headers, but also into the application payload. Although the content networking protocols can inspect into the packet payload, they are meant for providing network layer services but not application integration services. For example, Network-Based Application Recognition (NBAR) allows you to mark the IP DiffServ field in packets containing high-priority application traffic by first detecting the behavior of the application. However, like the network layers, the content networking layers cannot fulfill SOA acceleration requirements either.

In contrast, XML networking provides integration services by inspecting the full context of the application transaction and adding XML standards-based intelligence on top of the TCP/IP stack. An XML-enabled network provides you greater control, flexibility, and efficiency for integrating your applications than integration brokers. Figure 3 shows how you can inspect the XML-based "Web services" layer to accelerate your applications developed within an SOA model without the need of an integration broker.

The most popular Web services protocol is Simple Object Access Protocol (SOAP) [4]. With SOAP, your applications can request services from one another with XML-based requests and receive responses as data formatted with XML. Because SOAP uses XML, its Web services are self-descriptive and very simple to use.

You define your SOAP Web services with the XML-based Web Services Description Language (WSDL) [5]. The WSDL binds the SOAP messages to the Web services layer, as discussed later in this article. You can then transport your SOAP messages over standard application layer protocols, such as HTTP and HTTPS, between your client-server applications.

Figure 3: The Web Services Layer

Figure 3: The Web Services Layer

Similar to content networking technologies, XML networking can transparently add value to your applications within the network. When the XML network device receives the standard XML document from the Web services layer, you can configure the device to perform application-oriented services on the document. But because XML networking operates at the middleware layer and uses standard documents to integrate your applications, it provides you with fully standard functions using languages for:

  • Message Verification: You can develop World Wide Web Consortium (W3C) XML Schema Definitions (XSDs) that your XML network can use to verify the syntax of your XML documents [6].
  • XML Translation: Using XML Stylesheet Language Transformations (XSLT), you can translate XML documents to other non-XML formats, and conversely, directly within your network [7].
  • Context-Based Routing: Use XML Path (XPATH) to route messages based on data stored within XML documents [8]. A popular example is to route stock exchange quotes to a desired location when the value of the stock drops below a certain threshold.
  • High Availability: Messages containing specific content can be load balanced across numerous identical origin servers.
  • Data Security: You can accelerate XML encryption computations using either hardware or software XML-accelerated devices.
  • Compression and Caching: You can cache frequently requested XML documents and compress XML documents to reduce network bandwidth. Like XML encryption, XML caching and compression can be performed using either hardware or software XML-accelerated devices.
  • Application-Layer Request Translation: You can use XML networking to convert non-Web service requests into standard Web service requests. As with integration brokers, vendor-specific adapters are required to translate between WebSphere MQ, TIBCO, and SOA Web services. For example, Figure 4 shows how you can use network-level XML intelligence to translate between Websphere or TIBCO messages and Web services layer XML-based messages.
Figure 4: Intelligent Protocol Switching

Figure 4: Intelligent Protocol Switching

Introducing XML Service Languages

Now that you have a general understanding of both SOA and XML networking, you can examine the specific XML technologies used for application interoperability, including:

  • XML is used to format application data for storage and transmission.
  • XSLT is used to translate between one XML format to another.
  • XSD is used to describe, control, and verify an XML document format.
  • XPath is a way to address items in an XML document hierarchy.
  • SOAP is a messaging protocol used to encode information in Web service request and response messages before sending them over a network.

XML has its roots in the late 1960s from the Generalized Markup Language (GML), which was used to organize IBM's mainframe-based legal documents into a searchable form. The Standard Generalized Markup Language (SGML) was officially standardized in 1986 as an ISO international norm (ISO 8879). Since then, XML has become the predominant markup language for describing content. XML differs from HTML because it is not concerned with presenting or formatting content; instead, XML is used for describing the data using tags and attributes that you define yourself. Figure 5 is a sample XML document that organizes a police department's traffic ticket information.

Figure 5: A Traffic Ticket XML Example

Figure 5: A Traffic Ticket XML Example

The XML in Figure 5 identifies the group of tickets for a police department by the department ID and the department chief's name. This example gives the data for a single traffic ticket as defined by the "ticket" element (or tag); however, you could include as many tickets as you want within the element "dept-tickets." The "ticket" element has two self-explanatory attributes (in dark blue), called "id" and "code," referring to the identification number for the individual ticket and the offense code, respectively. The sub-elements of the "ticket" element are also self-explanatory: "offender," "offence-date," "location," "officer," "description" and "fine."

In order to build a well-formed XML document, you must embrace the data for each element within its respective open and close tags (for example, <ticket>...</ticket>, or <ticket>.../>), properly nest all elements, and make sure all element names are in the proper case. You must also specify the XML version with the "<?xml version="1.0"?>" tag at the beginning of the XML document. HTML is less rigid than XML because it is case-insensitive and most Web browsers will allow you to leave out the close tags of an element. Because XML is very strict about following the correct syntax (that is, by making sure the XML is well-formed), XML processors are much easier to develop than traditional HTML Web browsers.

To verify that your documents are valid XML, you can check them against XSD files, which define the XML elements and their sequence, as discussed later in this article.

Transforming XML Using XSLT

You can use XSLT to translate one XML-based language into another. For example, you can translate standard XML into HTML. To translate the XML from Figure 5 into HTML for online viewing, you can use the XSLT file in Figure 6.

Figure 6: XSLT Translation – From XML to HTML

Figure 6: XSLT Translation – From XML to HTML

You must use a namespace to differentiate elements among the XML-based languages that you use in your XML document. As Figure 6 illustrates, the namespace is the string "xslt:", which prefixes all of the XSLT elements. The particular application that parses the document (whether it is your XML device or a standalone XSLT parser [9]) will know what to do with the specific elements based on the prefix. For example, an XSLT parser will look for the specific Universal Resource Indicator (URI) string constant that the W3C assigned to XSLT (that is, http://www.w3.org/1999/XSL/Transform) and perform the intended actions based on the elements in the document.

XML parsers do not use the URI of the namespace to retrieve a schema for the namespace—it is simply a unique identifier within the document. According to W3C, the definition of a namespace simply defines a two-part naming system (for example, "xslt:for-each") and nothing else. After you define the namespace, the XML parser will understand the elements used within the document, such as "for-each" and "value-of" specified in Figure 6. For XSD documents, you must use a different namespace URI (that is, http://www.w3.org/2001/XMLSchema), as the next section discusses.

When you configure an XSLT parser or XML networking device to apply XSLT to an XML document, the parser starts at the top of the XSLT document by matching the root XML element within the source XML file. For example, the <xslt:template match="/"> element in Figure 6 matches the "dept-tickets" root element from the XML file in Figure 5. The XSLT parser then creates the destination XML document (that is, a well-formed HTML file, in this example) and outputs the <html> and <body> tags to the new document. The XSLT parser then outputs the HTML table headers and loops through the XML document "ticket" elements, outputting selected items within the columns of the HTML table. The resulting HTML is given in Figure 7 for three sample tickets.

Figure 7: Resulting HTML Table - Source View

Figure 7: Resulting HTML Table – Source View

Figure 8 illustrates the resultant HTML table that clients would see within a Web browser after the XSLT translation takes place.

Figure 8: Resulting HTML Table - Browser View

Figure 8: Resulting HTML Table – Browser View

Verifying XML Using XSD

Because you can customize the structure and tags within an XML document, you should verify its syntax using XSDs. The XSD file in Figure 9 verifies the XML document given previously in Figure 5.

Figure 9: XSD File for Validating Traffic Ticket XML

Figure 9: XSD File for Validating Traffic Ticket XML

You must define an XSD namespace with the URI "http://www.w3.org/2001/XMLSchema" and prefix all the XSD elements that you use in the XSD file, such as "element," "complex-type," and "attribute," with this namespace. At the top of your XSD file, you must specify the root XML element; the remaining elements within your XML document can be defined within the root element. Using the "complex-type" XSD element, you can specify elements that contain child elements (in contrast, "simple-type" indicates that the element does not contain any child elements). In this example, the "dept-tickets" element may contain a sequence of one or more child elements (as represented by the <xsd:sequence> element), including "deptchief," "dept-id," and any number of element "ticket."

Routing Messages Using XPATH

XPATH was developed primarily to be used with XSLT to transform the XML tags within an XML document based on the path of the data. Previously, in Figure 6, you saw how to select the entire list of tickets using the XSLT "select" attribute:

xsl:value-of select="dept-tickets/ticket"

However, within an XML network, you can also use XPATH to search within an XML document to route XML messages based on the values of the document data. For example, a state government may need the headquarters police department to route unpaid tickets that are within a tolerable threshold amount to the motor vehicle department for processing—there, the driver's license can be suspended until the ticket is paid. However, those unpaid tickets that exceed a maximum threshold amount must be routed to the court service government department for processing. The court may decide to press further charges, depending on the driver's previous driving record. Additionally, severe infractions, such as drunken or reckless driving, must be routed automatically to the court, regardless of whether the ticket is paid or not. The XPATH expression "dept-tickets/ticket" given previously returns the entire list of traffic tickets. Alternatively, if you want only the unpaid tickets with a fine value of greater than $100, you could use the XPATH expression:

dept-tickets/ticket[@paid='no' and fine>100]

The XPATH symbol "@" here indicates that an attribute is being selected, and not an element. To select tickets with codes 309 and 310 (that is, fictitious codes for severe infractions), you can use the following XPATH expression:

dept-tickets/ticket[@code=309 or @code=310]

Using SOAP Web Services

SOAP provides a standard way to send transaction information over TCP/IP application protocols, such as HTTP. For example, you could create a SOAP request-response operation over HTTP for exchanging traffic ticket information between two applications. As Figure 10 illustrates, the requesting client application sends a "getFineRequest" message to the server, which in turn responds with the appropriate fine amount within a "getFineResponse" message.

Figure 10: A Sample SOAP Request-Response Operation

Figure 10: A Sample SOAP Request-Response Operation

You encapsulate each SOAP message within the "Envelope" SOAP element. Within Envelope, you need to prefix the SOAP elements with the SOAP namespace, called "soap:" in this example, which you define as an attribute within Envelope. The "encodingStyle" attribute of the Envelope element defines the data types in the SOAP document. You must also define a custom namespace (that is, "tf," which stands for "ticket-fine"), with which you prefix all the application-specific elements.

To define the structure of the SOAP Web service running within your applications, you can use WSDL, which you develop so that your clients know the exact specification of the services that they can request, the types of responses they should expect to receive, and the protocols (for example, SOAP or HTTP) with which they should send messages.

For example, you can publish the WSDL to your clients, who may not be aware of the messages available within your Web services layer. The clients can retrieve the WSDL file and send the appropriate SOAP messages to the SOAP Web service running on your application. To publish the WSDL file to your clients, you can use a publicly available Universal Description, Discovery and Integration (UDDI) registry, such as XMethods [10], or you could create your own UDDI registry [11].

WSDL uses XSD to define your SOAP application data types. For example, for one application to request a fine amount (of XSD type xs: integer) for a given ticket ID (of XSD type xs:string) from your SOAP Web service called "ticketFineService," you could use the WSDL in Figure 11.

Figure 11: WSDL for SOAP Request-Response Operation

Figure 11: WSDL for SOAP Request-Response Operation

You start your WSDL file by declaring all the required namespaces. In order for the WSDL file to refer to element names that are defined within the same file (for example, "tns:getFineRequest" within the "porttype" element), you must use the "targetNamespace" element to define a custom URI that your custom namespace uses (that is, "tns," meaning "this name space").

You define the WSDL namespace for SOAP-specific elements with xmlns: soap=http://schemas.xmlsoap.org/wsdl/soap. For WSDL-only elements, you can use the default namespace xmlns= http://schemas.xmlsoap.org/wsdl/. Note that elements within the file that do not have a prefix use the default namespace.

After you create the namespaces for the WSDL file, you can then create the two messages for the transaction, "getFineRequest" and "getFineResponse," using WSDL "message" elements. WSDL ports create the request-response transaction flow using the "operation" element, by specifying which message is the request (input) and which is the response (output). After you define the transaction, you must bind it to SOAP with WSDL using the WSDL "binding" element. Additionally, to set the transport to HTTP, you must use the "binding" SOAP-specific element. You then link the operation you created previously within the WSDL "port-type" element to SOAP using the "operation" subelement within the parent "binding" element.

If you set the "use" element to "encoding," you do not need to use an XSD "type" attribute for defining SOAP data types in your SOAP messages. However, you must specify the "encodingStyle" URI to http://www.w3.org/2001/12/soap-encoding, as you learned previously in Figure 10. Otherwise, if you set "use" to "literal," then you would need to use the type="xsd:string" attribute in Figure 10 within the "tn:ticket-id" element when sending a request.

To define the SOAP Web service, you must use the WSDL "service" element. The SOAP element "address" within this element is the location where SOAP clients can send the "getTicketFine" requests, as Figure 10 illustrates.

Hardware vs. Software XML Acceleration

To help you understand the difference between hardware and software XML acceleration, Figure 12 illustrates a typical multilevel computer architecture [12]. The highest level is where you would typically program your applications. When you compile your application, the compiler would typically "assemble" your various objects into assembly language prior to generating the machine-level code. This machine code is what is normally stored in an ".exe" file, which only your operating system can understand. When you execute the ".exe" at run time, the operating system converts the machine-level code into microcode, which the digital logic level within the CPU hardware can execute directly.

Figure 12: A Multilevel Computer Architecture

Figure 12: A Multilevel Computer Architecture

Examples of software-based network applications in the past that have transitioned to hardware acceleration include IP routing, encryption, firewalling, caching, and load balancing. XML networking is also a recent candidate for hardware acceleration; it is available by XML vendors that use XML Application-Specific Integrated Circuits (ASICs) or Field Programmable Gate Arrays (FPGAs) in their products [13]. By programming the digital logic layer with the necessary circuits to perform intensive XML computations such as XSLT transformation, XML encryption, and XML schema validation, you can drastically increase the performance of the hardware platform.

However, some vendors have also found clever ways of accelerating XML computations on general-purpose hardware. Accelerating XML in software requires bypassing the additional machine-level step at run time. By "compiling" XML-based language instructions directly into microcode at the micro-architectural level, you can introduce XML computations to the underlying hardware directly at run time. That is, executing XML microcode at the digital logic level bypasses additional processing at the operating system "machine" level.

Summary

When a technology matures as a software agent running within an application, the need often arises to move the agent's functions to the network. Indeed, this was the case with numerous software-based technologies of the past, such as IP routing, encryption, stateful firewall filtration, and server load balancing.

To facilitate the interoperability of diverse applications, SOA was developed as a prescription to complexity problems faced by commonly used distributed-object technologies. As SOA matures, the need to introduce XML-based functions to the network will grow. In order to streamline the responsibilities of an SOA-based application, you can transition your XML technologies, such as XML translation, validation, and security, from within the application to an XML-enabled network.

For Further Reading

[1] Hao He, "What Is Service-Oriented Architecture?" O'Reilly, September 30, 2003.
http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html

[2] Werner Vogels, "Web Services Are Not Distributed Objects," Computing in Science and Engineering, November-December 2003.
http://computer.org/internet/

[3] Christophe Deleuze, "Content Networks," The Internet Protocol Journal, Volume 7, Number 2, June 2004.

[4] "SOAP Version 1.2 Part 0: Primer," W3C Recommendation, 24 June 2003.
http://www.w3.org/TR/2003/REC-soap12-part0-20030624/

[5] "Web Services Description Language (WSDL) Version 2.0 Part 0: Primer," W3C Working Draft, 3 August 2005.
http://www.w3.org/TR/2005/WD-wsdl20-primer-20050803/

[6] "XML Schema Part 0: Primer Second Edition," W3C Recommendation, 28 October 2004.
http://www.w3.org/TR/xmlschema-0/

[7] "XSL Transformations (XSLT), Version 2.0," W3C Recommendation, 16 November 1999.
http://www.w3.org/TR/xslt

[8] "XML Path Language (XPath) Version 1," W3C Recommendation, 16 November 1999.
http://www.w3.org/TR/xpath

[9] www.xmlspy.com

[10] www.xmethods.net

[11] www.uddi.org

[12] Andrew S. Tanenbaum, Structured Computer Organization, (5th edition), ISBN 978-0131485211, Prentice Hall, 2005.

[13] Michael John Sebastian Smith, Application-Specific Integrated Circuits, ISBN 978-0201500226, Addison-Wesley, June 1997.

SILVANO DA ROS currently works as a networking consultant in Toronto and has worked previously as a Systems Engineer for Cisco Systems. He is the author of Content Networking Fundamentals, published by Cisco Press. He holds a Bachelor of Computer Science and a Masters of Engineering (in Internetworking) from Dalhousie University.
E-mail: sdaros@sympatico.ca