JAVA for HITIS IMPLEMENTATION SOLUTIONS

One of the most frequently asked questions in the hospitality industry is whether bridging technology can be written and used to enable Enterprise Java Beans (EJB's) or applications running on CORBA to talk to DCOM objects if they cannot talk to one another directly in a mixed technology environment. If one of the goals of the HITIS standards is to allow bridging technology to take place, then there must be assurance that programmers write to the HITIS interface in the same way and are able to communicate at some common denominator.

Increasingly, eXtensible Markup Language, (XML) has been suggested to be a solution to the issue of interconnectivity. Since XML is purely platform neutral, it provides a way to facilitate the transfer of information by serializing the data contained in a HITIS object to send it across the wire, with the ability to utilize a multitude of transfer protocols.

HITIS has defined object-oriented specifications, but adhering 100 percent to the object design concept may not work in every environment. When the HITIS standards are mapped to real-world implementations, issues of performance may not allow a pure object model that makes use of pointer and references to remote objects. Especially in the Wide-Area Network (WAN) environment, there is value in being able to pass data 'by value' instead of 'by reference' in order to reduce the amount of round-trip traffic required.

Shipping data by value comes inherently with a Java application deployed on RMI, which sends the whole message as an object. When passing RMI on IIOP the data is normalized and cast into ASCII byte values because a 'pass by value' cannot be done between different programming languages. Thus, XML can be useful when connecting to non-Java applications, or to those systems that cannot support RMI.

The use of XML builds an extra layer that serves as a translator and is a way to marshal large data packets. Another advantage of using XML is that it passes firewalls much easier than RMI. In the absence of using XML, a Java application would need to tunnel through a firewall by using RMI over http or be obligated to buy proprietary software to circumvent the firewall.

XML fits into the Java scenario as a mechanism of transport that is external to an EJB. For example, a reservation taken by one system can be converted into an XML document and shipped to its client or, conversely, the client can be notified to retrieve the document. XML is clear text that can be serialized, mapping the name of a data element to a value and can include embedded binary objects (elements) in it. XML marshals all of the data together to send it to the receiving system; it does not require multiple calls across the wire to resolve pointers. The XML document is converted back to an object at the local system, using the XML object broker as distributed object middleware.

The EJB and the XML environments are not mutually exclusive as XML can be used as a payload or packaging mechanism. In XML, the Document-Type-Definition (DTD) must be passed across the wire, and an EJB can be used to facilitate this. It can be considered a valid way to communicate with 1^st tier clients in a 3-tier architecture. In a system that processes many message formats, the XML server could be connected to a designated port.

The JHIS mapping will define HITIS objects in EJB. The highest efficiency for an EJB solution, when communicating Java to Java, is to use RMI as the means for transport. When a Session Bean interface is implemented in EJB, interoperability is obtained by virtue of the container that the bean is deployed into. When JHIS defines how to export the objects to XML, then a Java application will be able to talk to anyone else using XML, leaving the other side to determine how to convert XML back to an object in a different language. This allows the same EJB solution to communicate directly with another Java element using HITIS messages, and effectively be plug and play with any other environment through XML.

Since the real world may dictate that the complete 'Plug-and-Play' goal is an unattainable unless the client and server are on the same platform, XML could be used as the lowest common denominator, and serve as the vehicle that allows this goal to be attained. If the use of XML becomes universal, it will have value in the interoperability between systems as long as there is a standard way to translate HITIS objects into XML. The JHIS mapping to EJB's does not preclude the use of CORBA, DCOM, or XML. In the absence of any other standards committee, JHIS will investigate defining a Java to XML conversion.

AH&MA has recognized two platform mappings that will initially be needed to implement the HITIS standards: one to the Windows operating system and the other to the Java language. AH&MA has endorsed the Windows® Hospitality Interface Specification (WHIS) and JHIS organizations to provide these mappings. In addition to providing the mechanism by which interconnectivity can exist, the Extensible Markup Language has the potential to become a third direct mapping of the HITIS standards, as a platform-neutral definition situated in the middle between the other two.

Providing a direct mapping of the HITIS standards would require a unique Document Type Definition (DTD). The burden for the creation and compliance of the DTD is not a JHIS function; but is the responsibility of the HITIS project itself. At this point, the HITIS standards do not address the accommodation of XML at all. Therefore, the mapping to XML would need to be hand coded unless XML tools would allow some measure of automation to do so. If HITIS chooses not to do XML definitions, then JHIS may need to provide these as well.

Document Type Definitions (DTD's) are the basis for information transfer in XML. A DTD is a separate file from the main XML document that provides a set of rules for the XML document to which it is attached. DTD's set the instructions for the structure of the XML document and define what elements are going to be used throughout the document, as well as the characteristics of each element type, along with its attributes and content. In addition, it declares the entities, or non-XML coded resource files, such as audio or video files that can be embedded in the document. In XML, the DTD acts as the placeholder for the standard and becomes the standard in lieu of the IDL.

The disadvantage of XML is that it is purely a content standard, possibly mitigating the HITIS operations. There may be a need to define a command-type document to accomplish the operations, and to define message packets between subsystems as completely marshalled, serialized data. Additional operations may also be needed to serialize the data in the HITIS objects for conversion to XML.

In the local environment, XML could potentially slow the network down as it is a payload standard that adds additional byte codes by virtue of the text required for the delineation of tags for every field. XML is not an object-oriented means of transport. It defines a set of messages, not an object with procedures and methods.

Questions remain as to how to invoke the object and get the data in XML, and once the data is transported, how the receiving system on the other side is notified to retrieve the data. Additional issues that remain to be resolved are: 1) references to naming services, and 2) XML parsing or rendering services to be used.

Both the Java and Windows environments share a common vision of business logic for the hospitality industry, and further place that vision in a distributed object model. The initial (and possibly idealistic) goal was to be able to communicate between different operating systems using the HITIS standards. That would mean any middleware, in any programming language, would have complete plug-and-play capability.

To reach that goal, the value of XML to the HITIS and JHIS mapping efforts is for use as the transport mechanism between systems, and a way to imbed an object outside of the purely EJB framework. And in addition to serving as middleware for distributed objects, XML should be considered a candidate for a purely non-denominational mapping.