Emerging Technologies

Everything we've discussed up to this point is commonly available and widely implemented in one way or another. (The only problem is that there isn't yet a widespread consensus on which of these pieces to use and for which requirements.) I can't close the discussion without giving you at least a preview of a few newer , less mature technologies. It's always hard to predict the future. However, my hunch is that it will be at least a few years before any of these find their way out into the mass market to the extent that EDI has (not that EDI has a big market, but this comparison at least gives us a frame of reference). Major players, both middleware vendors and big application vendors , are making investments in these technologies. Though none are widely implemented yet, it is likely that at least some or all will replace or eclipse some of the technologies discussed above.

Two transport technologies bear watching. The first of these is SOAP (which started out as an acronym for Simple Object Access Protocol but now is just SOAP). This XML-based protocol was originally designed as a mechanism for invoking remote object methods over the Internet in distributed object-oriented systems. The arguments for a method are packaged into a SOAP XML message and sent to a SOAP server. It takes apart the message, passes the arguments to the method, and then passes the results back to the caller in another SOAP message. This is very similar to the model of the familiar UNIX Remote Procedure Call ( RPC ). However, it didn't take people very long to figure out that SOAP could be used as a general method for transporting XML messages. A SOAP message has a header part and a body part. The header part allows for extension elements, which gives people the ability to insert routing and other control information. The body part is usually one complete XML document.

SOAP was developed by Microsoft and IBM. Although it is now being worked on by the W3C XML Protocol ( XMLP ) Working Group as part of the W3C's Web Services Activity, it has not yet been approved as a recommendation. It is, however, gaining a lot of notice as a key component of Web services.

A significant problem with SOAP is that it didn't in the beginning support more than one XML document in a SOAP wrapper. SOAP 1.1 with attachments uses MIME to append one or more XML documents to a SOAP message following the body part. However, the approach of using SOAP 1.1 with attachments has not yet been adopted by the W3C's XMLP group. While the long- term status of this approach is open to question, the number of vendors that support it is increasing.

The other emerging transport approach, the ebXML messaging service, uses SOAP 1.1 with attachments. A few commercial and open source implementations of the ebXML messaging service have appeared. In addition it has been adopted by other bodies such as RosettaNet. However, interest in all of ebXML seems to have been eclipsed in the marketplace by Web services. Only time will tell whether the messaging service or the rest of the ebXML framework gains acceptance. A more detailed discussion and a critical analysis of ebXML is available on my Web site at www.rawlinsecconsulting.com/ebXML.

There are several emerging technologies in the security area, but few yet need monitoring by end users or business application developers. A lot of them have to do with Web services and might be incorporated in middleware layers that few of us need to be concerned with for at least a few years, if ever. Others involve sophisticated and complex security models that go beyond the needs of most common current business practices. However, a few of these technologies do bear watching.

One such security technology is the W3C's XML Signature, sometimes referred to as XML DSIG. This is a way to apply a persistent digital signature to an XML instance document or parts of it (or strictly speaking, to any digital content, whether part of the document with the signature or not). As such, it satisfies various aspects of integrity, providing assurance that the signed object hasn't been tampered with and providing authentication of the signer. DSIG is the recommended digital signature approach in the ebXML messaging service. DSIG was approved in February 2002 and is being supported by an increasing number of vendors and APIs. I've not yet seen it used in customary exchange of common business documents, but I'm sure it will be the preferred method when a persistent signature is required.

The other security technology to watch is XML Encryption. This area has several facets and is covered by more than one W3C Recommendation. XML Encryption provides a standard approach for encrypting part or all of an XML document and representing the resulting cypher text as an XML Element. The XML Encryption Syntax and Processing Recommendation was approved in December 2002. As with XML DSIG, it is being supported by a growing number of APIs and vendors, but I've not seen it used yet. However, as the market matures you can probably expect it to become the preferred method when persistent encryption of XML is required.