12.5 Future Directions

  Previous section   Next section

In this section we look at the future directions of relevant technologies.

12.5.1 XSLT

One of the technologies related to XML that has become a powerful comple mentary tool to use along with XML is the eXtensible Stylesheet Language (XSL). XSL is a language for transforming XML documents and consists of three parts: the XSL language specification itself, XSL Transformations (XSLT), and XML Path (XPath). The combination of XSLT and XPath provides a powerful tree-oriented language for transforming XML documents into other forms including HTML, XML, and PDF. Future versions of the OAI need to provide the client the ability to dynamically select a subset of the fields returned through a query, instead of the full set, which is what is currently returned. The Query Service currently returns query results in the form of an XML document. By processing the user's request to obtain the subset of the selected fields, we can generate the style sheet that can then be used to transform the XML document that includes the full set of fields from the query into an XML document that only includes the client-specified subset. XSLT simplifies the task of transforming the returned document without having to first parse it and regenerate it. This approach is not the most efficient solution for the dynamic field selection problem. It would be more efficient to submit a subset of the original query to obtain the required fields. Our short-term goal is to be able to cache these fixed queries, so that we can at least gain some performance advantage. XSLT in the short run fits our needs best, although we are exploring approaches to efficiently generate dynamically generated queries based on the client-specified fields.

12.5.2 Web Services

Another technology that we plan to explore and possibly utilize in the future is the umbrella of technologies referred to as Web Services. Web Services provide the capability of exporting services to the Web that can be located and accessed by any type of client regardless of their programming language or platform. A Web Service can be as simple as a single method call (such as get the stock price for a given symbol) or a complicated business process. The current set of technologies that form Web Services consists of SOAP, XML Schema, WSDL, and UDDI. The Simple Object Access Protocol (SOAP) is an XML-based protocol for making Remote Procedure Calls (RPCs). The Web Services Description Language (WSDL) is used to describe the service and how to invoke it, and serves a similar purpose as the IDL for a CORBA service. Universal Discovery Description Integration (UDDI) is a standard-based service for exporting Web Services by the service provider and for locating them for the clients.

Using Web Services fits very nicely with some of the requirements of OAI. The platform and language-independence features of Web Services will resolve our requirement of having to support multiple heterogeneous clients. The ability to export services across the Internet will help us meet the requirement of having to support the exchange of image data across repositories in a secure way.

12.5.3 Mass Transfer Capability

A future enhancement of OAI will require for the mass transfer of JEDMICS data between sites and/or external applications. Importing/exporting complete engineering drawings and collections, including all cross-reference associations and the image data itself from remote OAI sites is of major importance to the JEDMICS community. JEMDICS sites need to be able to easily share their data.

Currently, JEDMICS provides several tools to allow the bulk transfer of information (both index data and image files) between JEDMICS sites. However, the current tools are intended for use by the JEDMICS system administrative staff and require the user to run several different applications to define, assemble, export, and finally import the data from the remote JEDMICS site into the local JEDMICS site. It is because of these limitations that a new, consolidated approach is needed for the end users and system administrators. Defining the JEDMICS data as XML documents provides for a platform- and language-independent means of transferring this data. The XML document is easily read and understood and is parsable by any client application. Without the use of XML, OAI would need to develop a proprietary data interchange format, which would not be easily manipulated by external clients.

12.5.4 Messaging

Messaging is a method of communication between software components or applications. Messaging enables distributed communication that is loosely coupled, which means that the sender and receiver do not need to know about each other. A messaging system makes the best effort to deliver messages asynchronously and reliably. Reliability means that messages are delivered to the client once and only once. Asynchronous means that the provider can deliver messages to the client as they arrive, and the client does not have to request messages in order to receive them. It also means that both clients and providers do not need to wait until messages are received, processed, or sent. Clients can continue with other tasks while the message request is processed in the background. This is very useful, especially when the client needs only to make sure that the request will be processed and not necessarily when the request has been processed.

It would be useful for the future release of OAI to incorporate messaging capability into the system. One such use may be applied to the printing bean, where sometimes a print job is associated with many images (and therefore involves many data files), and where delays might be associated with the print queue. Therefore, it makes sense for the clients to be able to submit print jobs once and be assured that they will get printed, without having to wait. The current JEDMICS system already has the capability to query and produce reports on print jobs submitted, and this capability will still be in use when the messaging is utilized.

There are two ways by which messaging can be done in the context of the OAI system:

  1. Using JMS.

    JMS stands for Java Messaging System, which is an API that J2EE 1.3 platforms were required to implement to allow components (i.e., EJBs) to send or synchronously receive messages. The J2EE 1.3 platform also provides a new message-drive bean, which enables the asynchronous consumption of messages. In addition to that, message sends and receives can be coupled with the Java Transaction API. Since OAI already does use J2EE as its middleware technology, the use of the JMS API should be directly applicable to the printing bean (rewriting it as a message-driven bean) and be used by the three different OAI clients (Java, Web, and CORBA).

  2. JAXM.

    JAXM (Java API for XML Messaging) is an XML-based lightweight messaging Java API for the development of XML-based applications. JAXM message exchange may be synchronous or asynchronous, but it has to be document centric. JAXM providers must support the HTTP protocol, although they may also choose to implement other standard networking protocols, such as FTP and SMTP. In all cases, JAXM assumes SOAP messages are being transported. JAXM presents a more flexible way of sending messages for the reasons stated previously. However, since JAXM only supports SOAP messages, this option cannot be realized until OAI exports its current services in the form of Web Services. JAXM would be a good candidate to facilitate the mass data transfer capability between JEDMICS sites that was mentioned in an earlier section.


Part IV: Applications of XML