Appeared in Component Strategies, October 1998
Component Interoperability with XML
You have probably heard the old expression: "the great thing about standards is that there are so many to choose from." This seems especially true in the exploding market for application servers and middleware. To set the record straight, Im a firm advocate of technology standards and make a concerted effort to follow and apply them whenever possible. However, the myriad of possibilities makes practical systems design a challenging task. If you include the large number of proprietary and quasi-standard vendor offerings, its a wonder that any component interoperability is achieved at the enterprise level.
Within this flurry of activity, its interesting to observe the continued emergence of Web-based standards infiltrating the traditional systems development world. The hypertext transport protocol (HTTP) is quite literally the backbone of the Web. System architects are beginning to use HTTP as a universal, distributed protocol that is often the best choice for penetrating firewalls in business-to-business or extranet applications. In addition, HTTP has the ability to carry any kind of content in its request message or in its response body. These generalities can be exploited to deploy a wide variety of enterprise and inter-enterprise systems.
HTTP was originally conceived as a simple, lightweight request-response protocol for communication between web browsers and servers. An HTTP server supports a small number of simple request actions (referred to as "methods"), e.g. GET, POST, and HEAD. The response "document" returned by the server can be encoded in any standard MIME type, including generic types for text or unidentified binary content. Within this general framework, developers and vendors have invented a wide variety of schemes for encoding application data within the request message body and the response. However, this flexibility produces incompatibility.
The Extensible Markup Language (XML) may provide a partial solution to the standardization of content formats. XML formatted data can be inserted into the body of an HTTP POST request to include relatively complex data that is both human and machine-readable. The server response can include an XML document containing the results of whatever was requested. To make this more concrete, Ill briefly describe three levels of component interoperability that are emerging from this HTTP/XML capability: remote procedure calls, component serialization, and agent communication languages.
XML-based Remote Procedure Calls
At the most primitive level, a protocol and message format are required to send a remote procedure call to a process or object running on another host. The Web originally accomplished this with HTTP and CGI, although it had limited capability. For CORBA based systems, the solution is provided by IIOP and its associated marshalling formats. CORBA also critically depends on shared interface definitions, especially for dynamic invocation of methods on remote objects. There are now several proposals for Web-native standards that make use of URIs for addressing remote objects, HTTP for message transport, and XML for messaging syntax and interface definitions.
The most complete proposal, referred to as the WebBroker, was submitted to the W3C as a basis for discussion; it is not an established W3C working group. See http://www.w3.org/TR/1998/NOTE-webbroker/. The authors sum up one of the notable benefits derived from using XML: "CORBA/IIOP and DCOM do not name data as it goes across the wire. Rather they simply know where data element boundaries are supposed to occur in the byte stream. XML is character based and structurally self-describing so the boundaries of the data elements can simply be represented as XML open and close tags. This is useful for variably sized data."
Table 1 illustrates a simple example from the WebBroker proposal. The objectMethodRequest is sent from the client to the server, embedded within the body of an HTTP POST action. The doSomething method is invoked with two parameters, an integer and a string array. The server replies with the objectMethodResponse as an XML encoded return value. For brevity in this example, Ive omitted the HTTP header information that contains critical data about the address of the target object for this remote call. See the proposal for more detail.
Table 1: WebBroker Message Formats
Although not fully developed in the proposal, WebBroker includes an XML counterpart for CORBAs interface repository, including a standard means for addressing and retrieving interface definitions. Now, if you think about this problem with a Web mindset, you begin to visualize a distributed object application as a hyperlinked set of XML "documents" that encode both the definition and state of the application. The XML linking specifications (XLink and XPointer) provide a rich capability for connecting the application components.
According to a July 10, 1998 InfoWorld story, Microsoft is developing its own support for XML-based RPC: "The Simple Object Access Protocol, or SOAP, enables Remote Procedure Calls (RPCs) to be sent as Extensible Markup Language (XML) syntax across the Web's HTTP architecture." At the time this column was written, there were no public specifications available for review. Perhaps this new effort will clean up some of the confusion about DCOM interoperability.
XML-based Component Serialization
RPC via HTTP and XML provides for low-level object-to-object communication, but does not fully address component-level designs. Ive stumbled across a very early stage prototype that helps to bridge this gap. The "Coins" prototype serializes a JavaBean object as an XML element, enabling JavaBean instances to be exchanged as simple tagged ASCII documents. (In case you didnt get it, a "coin" has two faces: a persistent XML document and a run-time Java object. I guess all of the bean metaphors have been used up.) See http://www.jxml.com/coins/ for further design information and a downloadable prototype.
Coins emphasizes XML as an alternative to Java object serialization, which complements the RPC proposals that describe XML serialization of method invocation messages. Another worthwhile addition, not listed among the Coins current design goals, would be to include the XML Resource Description Framework (RDF). RDF would provide a straightforward approach to capture the counterpart of Java "BeanInfo" metadata within this XML application infrastructure. RDF also standardizes an approach for linking digital signatures with XML data. See http://www.w3.org/TR/WD-rdf-syntax/ for the current specification.
There are additional fundamental differences that need to be ironed out between WebBroker and Coins (e.g., XML representation of primitive data types), however they begin to form a compelling argument. The combination of XML-based RPC and serialized objects, along with RDF, helps to complete the visualization of a complete hyperlinked application state.
XML-based Agent Communication Language
Instead of sending an RPC message from one object to another, an agent communication language (ACL) establishes an inter-agent communication protocol for exchanging information and coordinating multiple autonomous agents. Software agents thus encapsulate a more purposeful, goal-oriented component, as opposed to the smaller units of functionality encapsulated by a typical business object. An ACL must similarly enable a more purposeful conversation among agents, not a basic, low-level message exchange. A survey of agent communication is the subject of a book, not a few paragraphs of a column. The only thing that I can accomplish here is a brief introduction to the role that XML might play in this high level protocol.
One of the most widely recognized agent communication languages is based on the Knowledge Query Manipulation Language (KQML). For more information on this proposed standard, see http://www.cs.umbc.edu/kqml/. In addition, an ACL standard is being developed by the Foundation for Intelligent Physical Agents (FIPA); see http://drogo.cselt.stet.it/fipa/ for the current draft. I have not found any public specifications for an XML rendering of these ACL proposals, however I have seen several statements of intent to produce such a specification. I will update my Web site with these references as I find them, see http://www.ontogenics.com.
Table 2 shows an example of what an XML-based FIPA ACL might look like full credits to Johan Liseborn for posting this example to the Jess mail list. There are several important points to note. First, the <request> element is one of a carefully designed list of ACL "performatives" that define the conversational patterns among agents. Other performatives include: agree, confirm, disconfirm, inform, propose, etc. These form the foundation for agent interoperability and collaboration. Second, the <ontology> element defines the semantics for the message <content>. It appears likely that the XML RDF will be considered for defining these ACL ontologies. The other elements in this message serve to support the communication layer in ACL.
Table 2: XML representation of an Agent Commiunication Language
You may notice that this agent communication language has some overlap with objectives of the RPC proposals, however the specification of their interoperability is not complete. For example, there must be some relationship between the RPC interface definitions and the ACL ontology; both define the objects of communication. Also, the ACL content may refer to other remote objects, which should be consistent with the URI addressing used in the RPC messaging. Agents may either refer to shared object URI references, or they may exchange serialized object instances within their content.
There are many interesting, and challenging, integration issues that must be solved before we can gain the full benefits of a hyperlinked world of agents and objects. I believe that all three of these interoperability levels are necessary, and the respective XML proposals have merit. I look forward to the day when you can send a <subscribe> ACL message to my agent, requesting updates to this columns content!