The Java Developer Connection^SM welcomes Espresso Man and Little Grasshopper whose Q & A sessions have been a long-running feature in Sun publications.

In this session, they discuss the more important implications of the sudden emergence of the eXtensible Markup Language (XML) and the tremendous opportunities this provides to developers of Java^TM applications.

Q. XML? Isn't that an extension to HTML?

A. Well Little Grasshopper, the two languages certainly do have the same "look and feel".

Actually HTML is an application of Standard Generalized Markup Language (SGML) technology to a specific problem space (document presentation), whereas XML is a subset (or simplification) of SGML itself, adopted for the Web. Aside from its obvious document markup capabilities, XML is also fast becoming the standard for specifying business to business (B2B) data interchange across the Internet.

Q. Why XML and not HTML?

A. As a result of sharing a common heritage, both XML and HTML use tag names to "tag" text strings, and both surround these tag names with angle brackets (<...>). However HTML tag names are limited to a predefined set and are primarily used to indicate how the enclosed text data is to be DISPLAYED. The set of XML tag names on the other hand is unbounded, and they are used to indicate what the enclosed data MEANS.

So for example, while a typical HTML tag might be a command to the presentation layer to "display the enclosed data in bold font:"

  <b>John Jones 1234</b>

  <cname>John Jones</cname>

  <cid DataType=int>1234</cid>	

Q. So XML messages are self descriptive! But what good does transmitting a tag name to identify a datafield do, unless the recipient was already expecting to receive this data?

A. You raise an important point. Before a pair of applications can exchange and correctly interpret a set of XML data messages, they must first agree on the type of data that the message will contain, and the tag names used to identify this data. In an exactly analogous manner, two CORBA programs must first agree on the interface to a service before the client can invoke methods on the server object that implements that interface.

In the case of an XML message, transmitter/recipient agreement is achieved via publicizing a message schema, typically defined according to one of two widely recognized standards:

• Document Type Definition (DTD)

• XML Schema

In the case of DTD's for example, the following lines would specify the presence of the XML tag names above:

  <!ELEMENT cname (#PCDATA)>
  <!ELEMENT cid   (#PCDATA)>
  <!ATTLIST cid
	DataType CDATA #REQUIRED>

• Unlike a DTD, an XML Schema is itself an XML document. This allows creation of "meta" XML Schema specifications (which define other XML Schemas rather than XML messages).

• An XML Schema allows enclosed text to represent simple data types other than strings (example: integer customer IDs). These can then be automatically interpreted and verified for the message recipient, whereas with DTDs, such verification must be explicitly provided by the recipient code.

Q. Sounds confusing! You have to have separate schemas defined for each kind of XML message exchanged by two applications, and the schemas can be scattered all over the web. Is this really useful?

A. Extremely useful, oh dubious one! Such a collection of schemas might define the complete set of messages exchanged by subsystems within a typical application space (example: Retail, Education, Hospitality), and thus constitute an XML standard for an entire industry. Rather than being scattered therefore, the entire collection of message schemas are usually gathered together and then published and maintained on a web site owned by the industry trade group that developed the standard.

There are two other places such a standard might be published:

1. www.biztalk.org

   Biztalk is a Microsoft hosted website that imposes several proprietary constraints on all submitted XML message schemas. These include the requirement to first replace all DTD or XML Schema message specifications with a nonstandard, Biztalk-only equivalent (XML-Data).

2. www.xml.org

   Thus site is hosted by the OASIS organization, a non profit consortium whose membership list includes Sun, IBM, Oracle, SAP and Microsoft.

   xml.org registers and publicizes both DTDs and XML Schema message specifications as a way to promote standardization of non proprietary XML applications in electronic commerce.

A. Ah ... it's not quite that simple. While an XML message is universally interpretable, taken by itself it doesn't guarantee a "platform-neutral" wire. To do that, XML needs to be coupled with a platform-neutral transport protocol, for the same reason that HTML has to be coupled with HTTP before it can be received and interpreted by any browser connected to the Internet.

Q. A "platform-neutral wire"?

A. A platform-neutral wire is one that does not impose proprietary restrictions on those applications that use it to intercommunicate. To create such a wire, an industry XML standard must specify that:

• All data is exchanged via a set of predefined XML messages.

• The underlying transport protocol is non proprietary and widely supported.

This in turn guarantees end users who deploy such standard-conformant applications across a "platform-neutral wire", that they:

• Retain the freedom to select "best of breed" hardware, operating system and middleware, without having these choices mandated by a requirement to first deploy a vendor-specific transport protocol.

• Can integrate any of these solutions directly into their enterprise, layered on top of their existing legacy software and hardware platforms.

A. There are actually several candidates for such a protocol. As we shall see, while each has its strengths and weaknesses, one clear choice does emerge.

1. IIOP

Requiring all XML messages to be sent over IIOP will create a level playing field for competing system suppliers, thereby increasing the end-user's choice of suppliers.

IIOP is however an object transport protocol and as such, imposes a fair amount of design conformance between communicating applications. In addition, IIOP suffers from the following restrictions:

• It is designed more for a LAN than the Internet, and as a result does not easily operate across institutional firewalls.

• Most legacy applications are message rather than object based, and as a result, will not easily adopt to support an object protocol.

2. Proprietary Message Service (MOM)

However such a solution suffers from the following restrictions:

• As with IIOP, MOM products are designed more for a Corporate network than the Internet, and as a result do not easily operate across institutional firewalls.

• They are also proprietary in the sense that the functionality provided by MOM products is often achieved through a private lower-level protocol that is owned and controlled by a single company, and which is often difficult if not impossible for other vendors to connect to.

Such a situation sets the stage for the fragmentation of the market between conformant (but incompatible) solutions based around different message-service providers. This is EXACTLY what most XML industry standards are designed to prevent!

3. HTTP/HTTPS

• Both O/S and language independent

• The transport layer over which the vast majority of Internet messages are conveyed today. It can leap most corporate firewalls at a single bound!

• Currently supported by every existing Web Browser and Web Server

• Used (and understood) by a wide range of existing applications.

• Available in a "secure (encrypted) session" version (HTTPS)

Q. But doesn't HTTP provide a "lower level" protocol than either of the other two? How is the missing functionality supplied?

A. It is true that such messaging features as encryption, guaranteed error-free delivery, authentication, event publish/subscribe, automatic message queueing, and support for disconnected operations are all important to provide for an XML-based standard, and an application developer should be shielded from as much of the detail as possible.

When HTTP/HTTPS is used as the underlying XML transport, it must either provide these features directly or they must somehow be supplied by data fields within the XML, usually in a "header" placed in front of all messages defined by the standard.

The following functionality can be provided by HTTPS:

• Message encryption (the ability of two communicating applications to prevent outside parties from correctly interpreting any of the data they are exchanging).

• Guaranteed error-free delivery. This requires use of HTTPS's "Post" message, which conveys back success or failure within the same HTTPS connection as the original message.

As an example, the single XML element:

 <Authentication Type=X.509> Shhhhhh 
 
</Authentication> 

• Authentication (Is sender who she claims to be?)

• Authorization (Is sender allowed to do what she requested?)

• Data Integrity (Has any part of this message been altered?)

Q. So XML over HTTP/HTTPS can provide a feature rich platform-neutral wire. But you are Espresso Man! How can we have made our way through an entire "Ask Espresso Man" column without once mentioning "Java?"

A. We can't and we won't. But prior to explaining why the Java^TM platform is the best one on which to implement XML, we had to provide some background on XML first.

Now consider how far we have come. We have demonstrated how defining an industry XML standard around a platform-neutral wire (XML/HTTP) allows for any two compliant subsystems to interconnect despite the OS and messaging middleware they use. Now let's consider the advantages from the developer's viewpoint.

Implementing such a subsystem using Visual Basic or C++ components constricts the eventual product deployment to a single OS and a single messaging service.

Writing an equivalent set of components in the Java programming language provides the ability to deploy the resulting product on any OS. Further, by conforming to the Java Messaging Service (JMS) API, these components will be able to transparently utilize a wide range of existing MOM products, providing a major competitive advantage for the Java-based products. See: Vendors

Finally, packaging these Java components as Enterprise JavaBeans^TM (EJBs) enables the developer to reduce complexity by simplifying most multi-threaded, transactional and persistence issues. So an additional benefit for the EJB developer is a reduction in "time to market".

Q.What about the end user? What's the value proposition there?

A. The end user gets to deploy simplified platform-neutral EJB components across a platform-neutral wire. This represents the first true realization of "plug & play" components for Business to Business (B2B) Internet applications, and is the ONLY way to deliver on XML's promise of universal interoperability.

Therefore you can expect to see such EJB components appearing soon, for use in a variety of vertical industries. Several industries. Very soon.

Table 1:

Application Interaction Standards: Objects vs. Methods
Comparitor	CORBA / COM+ (Object-Based)	XML(Message-Based)
Data Source:	Client	Transmitter - Publisher
Data Destination:	Service	Receiver - Subscriber
On-the-wire Data:	Object method to invoke & method arguments	Document - Event
Schema:	Interface definition language (IDL)	Document Type Definition(DTD), XML Schema
Standards Organization:	OMG (CORBA) Microsoft (COM+)	W3C
Schema Registration:	OMG (CORBA) Microsoft (COM+)	OASIS (xml.org) Microsoft (biztalk.org)
Application Coupling:	Close	Loose
Transport Layer:	IIOP (CORBA) DCOM (COM+)	HTTP/HTTPS or (MOM) Message-oriented middleware
Typical Topology:	Intranet	Intranet / Extranet / Internet
Typical Deployment:	Corporate "internal"	Business to business (B2B)
Enables:	Distributed enterprise	Distributed trading partners

Table 2:

XML Transport Protocol
Comparitor	Microsoft MOM(MSMQ)	CORBA based MOM (JMQ, MQSeries, ...)	HTTP
Standards Org	None (Microsoft)	OMG	IETF
Application API	MSMQ (Microsoft)	Java Messaging Service (JMS)	HTTP
Operating System Neutrality	No	Yes	Yes
Message Server Neutrality	No	Limited	Yes
Web Server Availability	Some	Some	All
Internet Capabilities	Limited	Limited	Complete
Naming Service Interface	Active Directory	JNDI (LDAP, DNS,NDS, NIS, ...)	DNS
Message Security	Provided	Provided	External
Supplier	Microsoft only	Multiple MOM vendors	Any vendor

About the Author

Ron Kleinman is the Chief Technical Evangelist for Sun Developer Relations, and serves as Sun's representative on multiple industry-wide Java and XML standards committees. He has extensive experience consulting with developers who are trying to "java-tize" their existing applications. He has prepared and delivered numerous presentations on Java technologies both in the U.S and overseas. His particular areas of expertise include Java on the Server (EJBs and server-side APIs), Jini, Java-based device access control and management, and more recently, XML.

Reader Feedback