Edwin E. Hastings, Hastings Software
Dilip H. Kumar, Digital Equipment Corporation
Digital Equipment Corporation uses a number of production systems worldwide to run its business. Each country and business unit runs software to meet local needs, with the same function at times being provided by different applications. Providing customers and business partners electronic access to pricing, product availability, order status, and other transactional information is difficult and fragmented. Most often this information is provided by phone or fax with all of the limits and delays that these methods present.
A new approach is being taken using CORBA object technology to provide WWW users direct access to transactional information. This paper will discuss:
The WWW, with its multiplatform readers, is a very attractive solution for presenting the information. This new system aims to provide direct information access, eliminating the extra effort as well as eliminating the errors and mistakes that occur when data is manually entered into a document, spreadsheet, or other application.
We faced several significant challenge of getting the information to the Web server without rewriting the production systems. Our solution, currently under development, is to use a CORBA compliant object system (ObjectBroker) to provide transactional information to the Web. By integrating with HTTPD, ObjectBroker will act as a common CORBA based interface between the Web and Digital's internal applications network.
We are using enhanced meta HTML files which will be processed using data returned from the production systems. These meta HTML files are fully internationalizable and will allow customers worldwide to be supported in their native language.
As new applications are acquired and developed, CORBA functionality will be specified or developed. For existing applications, "wrappers" are being written using existing routines. CORBA also provides dynamic object selection which will support a worldwide user base with information from their local systems without having WWW servers in each country.
The primary requirement of the system was to provide a gateway between Digital's internal production machines and customers using PCs, Macs, workstations, and terminals. Two types of information had to be provided, unstructured published information and structured transactional information. Published information is fairly static and is the same information for all of the users, although not all users may be given access to all the information. Transactional information changes frequently and is different for each user and based on the user's requests. The software had to have a good user interface, handle transactions, and link with many different kinds of production applications worldwide. Finally, the system had to be secure. Security included different access types for different classes of users and protection for information that is private to individual users.
The challenge of designing an interface for integration purposes was formidable. The existing base of applications is large and diverse, ranging from those that are easily integrated, having full application programming interfaces (API), to those that can only be accessed through their default terminal interface. Some applications are very modular, and have a well defined API. These applications are easy to connect to and integrate with any system. The other applications require complex wrappers to communicate with the application. Also in different countries the content of each application can be different for the same transaction.
We wanted to handle all applications in a similar fashion. What was needed was an interface that would serve both extremes, be easy to program to, and still be able to handle complex applications and transactions. Additionally we wanted the ability to update, modify, and internationalize the user interface without any programming on the Web Broker system. This lead us to select an object based system with a uniform well defined interface for each application.
Selecting a network transport for connecting our web server to the production applications came down to three choices:
The Web Broker (WB) is the main switching center for transactions providing a common access point between the outside world of the web and the internal network of production applications. Running under httpd as a "cgi-bin" program WB provides the following functions:
An ObjectBroker object is then created and populated with data from the form. The object is not specific to any one service, its generic nature allows WB to support any number of services without any reprogramming of the WB software. No actions in the Web Broker are hard coded based on the service that is currently selected. For all switching operations the data in the object is opaque to the broker.
Information is transferred between the Web Broker and Object Wrapper Layer (OWL) using arrays of self describing name value pairs:
array[0] name1=value1
array[0] name2=value2
array[0] name3=value3
The service name is passed to the Web Broker by the invoking form. It is then combined with the user's locale and are applied to the object's context. The complete object can now invoke the remote method using ObjectBroker. Here is one of the strengths of using the CORBA based system. The application code does not have to know anything about the remote node being identified or about the mechanics of the transport being used. That is invisible to the application being supplied and managed by ObjectBroker.
The field names need to be coordinated between the forms based fields and the input needed by the Object Wrapper Layer (OWL, see figure 2). The OWL takes the parameters that it needs from the data passed in, formats it correctly for the Application Wrapper Layer (AWL), executes the AWL and then formats the return data before sending it off to the WEB Broker. On the outgoing end the return data field names must be coordinated between the OWL and the META HTML file. META HTML files reside on the same systems as the WEB Broker.
service-name_return-code_locale.METAHTML
These return codes allow the service designer to setup multi-step transactions and have them driven by the production system. The data entered on the production system could drive the user down one of several paths. For example the production system might need more data and want the user to fill out another form, some data might be invalid and need to be reentered, or the user may have completed one step and be ready to proceed to the next one.
Each Meta HTML file is a unique form with different requests for information based on the user requirement. The return code drives the user through the sequence. In PASS, the OWL code can determine what step is in effect by sending a special name/value pair. Again the only coordination needed is between the service specific PASS code and the META HTML files, no changes are needed for the WEB Broker.
A special Meta HTML file, service_ERR_locale.METAHTML, is invoked if there is a network based service unavailability or breakdown. This file should include specific service related information, for example if the application is normally unavailable at certain hours, as well as contact information for the local.
The Meta HTML files reside on the Web Server system. These files contain supersets of HTML information to substitute data returned from the production systems, handle conditional operations based on that data, and implement location specific date, time, and monetary functions. Using the objects name value pairs we isolate the construction of the display from both the production server wrapper and the web broker.
Once the proper META HTML file is selected, it and the results returned by the OWL routine need to be merged. This section describes that process.
An advantage of having the META HTML tags related to the PASS code is flexibility in specifying and adding fields. For example, adding a specific data field of function, that may only be applicable in a certain country, can be done in a straight forward way. The specific fields are added to the OWL for that application and for the specific META HTML file, no coding changes would be necessary for the WEB Broker.
The OWL remote method returns multiple lines, string arrays, of tag/value pairs that contain the results. The tags in the returned data correspond to the META HTML tag names. These are substituted according to the following rules to create the HTML output. This process gives a completely mapping free implementation of the data formats, only the Object Wrapper Server and META HTML routines need to know the tags names.
The first tag in a line has a special property of identifying the entire line. Conditional operations can only be performed on this Line Identifier Tag (LIT). This property allows tags to be grouped into records. For example an order will have multiple lines containing part number, quantity, and price. Each order line will be identified by a LIT value.
$var$ use the value of var
[$var$ :+text] if var is defined and non NULL then
use the string text. Note that
text can contain $var$ and a
substitution should be applied.
[$var$ :-text] if var is undefined and non NULL
then use the string text. Note
that text can contain $var$ and a
substitution should be applied
[time:$var$ :format] output the value of var using the
date and time formating string
format as defined by the
strftime/wcsftime routine. Note
that these routines are locale
sensitive and will give the user
output that is routine to his
country.
[mon:$var$ :format] output the value of var using the
monetary and will give the user
output that is routine to his
country
Existing applications and new applications that do not come with built-in ObjectBroker interfaces need to be "wrapped" with ObjectBroker. This wrapping gives the application a uniform interface to the Web Server System which is invoking the application. There are two layers for the wrapping system:
The design is such that the OWL can take advantage, to the greatest extent possible, of existing access points to the application being integrated into Digital On Line.
Multiple AWL routines can be called by the OWL depending on the data name/value pairs submitted.
On return from the Application Wrapper Layer, the OWL collects the returned data and then marshal it into name/value pairs and then returns the data. Additionally, the OWL sets the method's return code. This return code is used by the WEB Broker (WB) to select the proper META HTML file to use for outputting the program results.
This subsystem consists of 3 components:
Supporting worldwide users was one of the driving business goals. Support is more than just translating the languages that the user sees on the screen. We also needed to handle the face that the some services are provided in different countries by different applications, the solution to this was discussed in the section on using objects.
Since we are presenting a variety of information, including contact information, currencies, and dates we needed a complete approach. This is being handled by using locales. The construct from XPG/4 which identify both the user's language and country. Locales provide information on a users country and language and are a standard defined by the X/Open Portability Guide #4 (XPG 4). Locale information is used to provide translated and country specific information to the user. Every user is assigned a locale as part of their user profile entry.
META HTML files are specified by locale. In a locale the first two characters are the language and the last two characters are the language. The locale allows the META HTML file writer to include information that is important to a specific user based on their language and country. For example the Swiss German (de_CH) and Swiss French (fr_CH) would both include the same contact information for Digital Equipment Switzerland, however the text would be written in French in one and German in the other. However another page could be written, also in German, but with a locale of de_DE this page would reference contacting Digital Germany.
Customary date and monetary formatting are also part of the XPG4 standards and are supported by the META HTML files.
This implementation allows either a single server or a combination of many servers to support users worldwide. It also allows us to add new countries and services by using existing meta HTML files that are similar and using the same language.
The current implementation provides a flexible interface to transactional systems for WWW-based clients. As this is implemented, more functions will be added to it in future. At present, there are 3 areas that we have identified for further work which extend the design.
Enterprise-wide Authentication System - As we implement more services and expand the user base, there will be a need to use a enterprise-wide, open authentication system like kerberos. We are hoping that the next generation of WWW Clients/Servers will have implemented kerberos-based authentication. The current HTTP protocol can support this scheme.
Complex, hierarchical data structures - The current Web Broker essentially uses name/value pairs to communicate with the OWL. This is capable of handling data which does not hierarchical relationships of second degree or higher. But many commercial transactions have data elements which are hierarchically related upto a third or fourth degree. The example below illustrates this:
The interface between the Web Server and the OWL can be extended to handle such data structures while still retaining the name/value nomenclature.
Integration with new client-server transactional systems - As part of the re-engineering effort, Digital is implementing major packages to replace existing systems. A lot of these packages have customized front-ends. There is a need to integrate a public-domain interface to these packages so that external users can access data from these systems. Work to integrate the Web Broker with the SAP R/3 application package is currently underway.
Submitted by
Dilip H. Kumar
Digital Equipment Corporation
dilip@sita.mro.dec.com
Mr. Kumar is a technology consultant in Digital's Applied Information Technology Group. He specializes in designing and implementing electronic commerce systems with an emphasis on high performance transaction processing servers. He holds a Masters of Business Administration from Boston University and a Bachelors of Engineering from Mysore University, Mysore, India.
Edwin Hastings
Hastings Software
hastings@ultranet.com
Mr. Hastings is an independent consultant who specializes in computer networking and multi-platform application architectures and development. He has contributed to efforts at companies including: Digital Equipment, Xerox Corporation, Lawrence Livermore National Labs, Apple Computer, and Teradyne. He holds a Bachelor of Science degree in Computer Science from Rensselaer Polytechnic Institute.