Integrating WWW and Middleware

Integrating WWW and Middleware

Ashley Beitz, Email: ashley@dstc.edu.au Home Page: Ashley Beitz [HREF 1]
Renato Iannella, Email: ren@dstc.edu.au Home Page: Renato Iannella [HREF 2]
Andreas Vogel, Email: andreas@dstc.edu.au Home Page: Andreas Vogel [HREF 3]
Zhonghua Yang, Email: yang@dstc.edu.au Home Page: Zhonghua Yang [HREF 4]
all of the CRC for Distributed Systems Technology, DSTC, Level 7, Gehrmann Laboratories, University of Queensland, 4072, Australia,

Tak Woo, Email: t.woo@dstc.edu.au Home Page: Tak Woo [HREF 5] CRC for Distributed Systems Technology, Bond University, School of Information Technology Gold Coast, 4229, Australia

Keywords: World-Wide Web, Middleware, CORBA, DCE

Introduction

The emergence of middleware systems for distributed systems is seen to be an extensible and empowering technology. The World-Wide Web (WWW) [Berners-Lee et al, 1994] can capitalise on this by providing access to distributed system services via this middleware and access of WWW services to distributed systems. The integration of such middleware systems, particularly OSF's DCE (Distributed Computing Environment) [HREF 6, OSF 1993] and OMG's CORBA (Common Object Request Broker Architecture) [HREF 7, OMG 1993], into the WWW will provide the following benefits: The integration of WWW and middleware systems will enable the two-way provision of services: This paper will concentrate on the former scenario. With the proliferation of services on both WWW and middleware, the integration will see the overall enhancement of service provision in distributed environments.

An Architecture for Integrating WWW and Middleware

Figure 1 below illustrates our proposed architecture which enables WWW clients to access and invoke middleware services. In the architecture, the clients interact with the WWW, which in turn interacts with a range of middleware systems which provides access to the distributed system services. The Type Manager and Trader are two important common services and are discussed in the next section. This layered approach, with the combination of middleware gateways, provides the underlying framework for the architecture.

Type Manager

A type manager [Biggs et al 1994] is an object which stores knowledge about types, e.g. their definitions and the relationships between them. At its interface, it provides operations to manipulate this knowledge. In the context of this paper, we are particularly interested in the browsing and selection of service types, and in accessing the corresponding interface type definitions. Interface type definitions are usually expressed in an Interface Definition Language (IDL) such as DCE IDL [OSF 1993] or OMG IDL [OMG 1993].

Trader

A trader [ISO Trader 1994, Beitz and Bearman 1994] stores information about service instances. It gains this knowledge from service providers exporting a description of their respective service. The trader provides potential clients an import operation which returns the interface identifiers for services matching the client's request.

Integration Protocol

To integrate WWW and middleware, there is a need to define the interactions between the various components. Therefore, we introduce the following integration protocol, which is illustrated in Figure 2:
  1. get service type
    WWW client contacts the type manager. The clients browses and eventually selects a service type.
  2. get interface identifier of selected services
    WWW client contacts the trader. It requests services which match the selected service type and additional parameters of the import operation. The user selects (or lets the trader select) one of the matching services. As a result, the client has an interfaces identifier of the selected service.
  3. invocation (WWW)
    To invoke an operation, the user has to select an operation from the ones provided at the interface and to enter values for the operation's parameters. Therefore, an appropriate form (in HTML format) is created from the interface type definition. Once the form has been completed, the user can invoke the operation, i.e. sending a request to the WWW server which provides the gateway to the middleware domain. Besides the operation name and its parameters, the request has to contain the interface identifier of the selected service.
  4. invocation (gateway)
    To provide the gateway, the WWW server has to act as a middleware client. To allow the standard WWW server to facilitate this, it has to invoke the middleware client via the Common Gateway Interface (CGI). Where the appropriate client comes from will be discussed below.
  5. invocation and termination (middleware)
    The middleware client invokes the middleware server. It receives the resulting parameters and hands them over to the gateway. This has to happen via a pipe, eg standard output, and requires a certain format. It seems appropriate that the middleware client should already convert the parameters into HTML format.
  6. termination (gateway)
    The gateway receives the result in a certain format. If the format is not already in HTML, then it converts the result to HTML.
  7. termination (WWW)
    The WWW clients displays the results as received from the gateway.
Step one and two are optional. If a user already knows which service type he/she wants to use, then the get service type step can be skipped. If a user already knows about the interface identifier where the services is provided, then the get interface identifier of selected services step can be discarded.

Middleware Client Generation

The above integration protocol does not specify where the middleware clients are coming from, nor how they work. We have identified the following types of middleware clients:

A DCE Prototype

To demonstrate the integration protocol described above, a DCE CGI gateway has been implemented for a DCE Browser Marco [HREF 8]. Figure 3 illustrates how this works.

Through HTML forms, the DCE CGI gateway invokes the middleware client to query DCE servers for their interface details. A form is then displayed for a user to choose a particular RPC operation in order to obtain more details on it. A dynamic form with fields for filling in the necessary parameters to invoke the selected RPC operation, is then generated.

At the moment, the DCE CGI gateway only uses static middleware clients that already exist at runtime. With slight modifications, the gateway should be able to generate dynamic middleware clients by using the following steps:

  1. The user browses through DCE interfaces (DCE IDL files) from a WWW client
  2. The user selects an interface and invokes the DCE CGI gateway
  3. The DCE CGI gateway uses the IDL file to generate a middleware client at runtime
  4. The gateway uses the dynamically generated middleware client to invoke the DCE RPC and displays the results on the user's WWW client browser.

Technology Issues

In this section we will overview the technology needed to derive HTML forms and DCE client templates from an interface specification. The general idea is that an interface specification is transformed by a parser into an abstract syntax tree. Various back-end tools can be applied to this abstract syntax tree. Figure 3 illustrates this approach.

Within the DSTC we have built parsing and unparsing tools based on the standard utilities lex and yacc, and the compiler generator kimwitu [Eijk and Belinfante 1990]. Kimwitu eases the handling of abstract syntax trees and provides interfaces to lex and yacc, and excellent support for tasks such as unparsing or comparing trees.

Within the DSTC we have already implemented several back-ends, to check equivalence and subtyping relations between two DCE interface specification and to translate a DCE interface specification into a CORBA interface specification. Based on this experience we have a clear view on how to implemented back-ends to derive HTML forms to select an operation and to capture parameters, and to create templates for dynamic DCE clients, as described in the previous section.

Related Work

In related work, the approaches to the integration of the WWW with distributed middleware can be classified as follows:

The intention of the OSF's DCE Web project was to apply state of the art DCE services, particularly the DCE security services, to the WWW. This allows the WWW resources to be accessed in a controlled manner. The technology produced by the DCE Web project is called protocol tunneling. With protocol tunneling, the WWW clients and servers communicate with each other using the existing HTTP protocol, but they use DCE RPC as the underlying transport mechanism. In this approach, the HTTP messages are encapsulated as DCE RPC data, and thus the DCE services such as security and naming are able to be used without having to modify the HTTP protocol.

Instead of choosing DCE as a transport mechanism, Digital's CORBA Web project chose the CORBA-based object system (ObjectBroker) as a transport mechanism for connecting the WWW server to the applications. This project developed a WWW broker as part of the WWW server and an object wrapper to wrap the application data. The communication between the WWW broker and the object wrapper is via CORBA middleware.

The Web* (Web star) project at the CERC (Concurrent Engineering Research Center) has taken a different approach to exploiting the WWW and CORBA. This project is based on CGI. Web* generates a CGI script to access a set of "Layout Pages" which are the HTML files containing TCL (Tool Command Language) commands. The script is able to directly access CORBA distributed services by using CORBA's Dynamic Invocation Interface (DII). The results from the distributed service are sent back to the WWW client. Since the TCL/CORBA script has no idea of what the accessed services are, the user has to supply the correct arguments and object references, and must appropriately decode the results. In most cases, this is an unreasonable requirement for the user.

APM uses an object-oriented approach to integrate the WWW with CORBA. This approach imposes the CORBA distributed object model onto HTTP, and thus the WWW environment becomes a world of distributed CORBA objects. It uses CORBA wrappers to make URLs look like CORBA objects. It uses a CORBA/HTTP interceptor to make HTML located outside the CORBA world accessible as a CORBA object to the CORBA applications, and to make CORBA objects appear as WWW objects to users outside of the CORBA environment.

Conclusion

This paper has presented an architecture for the integration of middleware services and the WWW. The benefits of which will lead to an increase in the number of services available to the end-user. A prototype was developed using this architecture and proved that the integration of such services is possible.

In summary, we see the benefits of the middleware integration to be paramount for the success of future globally distributed systems.

Acknowledgements

The work reported in this paper has been funded in part by the Cooperative Research Centres Program through the Department of the Prime Minister and Cabinet of Australia.

We would also like to acknowledge David Arnold for his work on the DCE Browser.

References

Time Berners-Lee, Robert Cailliau, Ari Luotonen, Henrik Frystyk Nielsen, and Arthur Secret (1994), "The World-Wide Web", Communications of the ACM, 37(8):76-82, August 1994.

A. Beitz and M. Bearman (1994), An ODP Trading Service for DCE. in Proceedings of the First International Workshop on Services in Distributed and Networked Environments (SDNE), pages 42-49. June 27-28, 1994, Prague, Czech.

C.J.Biggs, W. Brookes, and J.Indulska (1994), "Enhancing Interoperability of DCE Applications: A Type Management Approach", in Proceedings of the First International Workshop on Services in Distributed and Networked Environments (SDNE), pages 50-57. June 27-28, 1994, Prague, Czech.

ISO Trader (1994), Rec.X.9tr/Draft ODP Trading Function ISO/IEC 13235: 1994/Draft ODP Trading Function. ISO/IEC JTC1/SC21, N-9122, July, 1994.

OMG (1993), The Common Object Request Broker: Architecture and Specification, Revision 1.2, December 1993, Object Management Group, Cambridge, U.S.A.

OSF (1993), OSF DCE Application Development Guide, Revision 1.0, 1993. Open Software Foundation, Cambridge U.S.A.

P. van Eijk and A. Belinfante (1990), "The Term Processor Kimwitu, Manual and Cookbook." University of Twente Technical Report INF-90-45, 1990.

Hypertext References

HREF 1
http://ftp.dstc.edu.au/AU/staff/ashley-beitz.html, Ashley Beitz's Home Page.
HREF 2
http://ftp.dstc.edu.au/RDU/staff/renato-iannella.html, Renato Iannella's Home Page.
HREF 3
http://ftp.dstc.edu.au/AU/staff/andreas-vogel.html, Andreas Vogel's Home Page.
HREF 4
http://ftp.dstc.edu.au/AU/staff/zhonghua-yang.html, Zhonghua Yang's Home Page.
HREF 5
http://www.dstc.Bond.edu.au:8008/docs/TU/staff/tak.html, Tak Woo's Home Page.
HREF 6
http://www.osf.org:8001/dce/index.html, DCE's Home Page.
HREF 7
http://www.omg.org, OMG's Home Page.
HREF 8
http://www.dstc.edu.au/public/staff/david-arnold/marco.html, Marco's Home Page.
HREF 9
http://www.osf.org:8001/www/dceweb/DCE-Web-Home-Page.html, DCE Web Project.
HREF 10
http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/hastings/hastings.html, Digital's CORBA Web Project.
HREF 11
http://webstar.cerc.wvu.edu/lpi/webice.html, Web* project at West Virginia University.
HREF 12
http://www.ansa.co.uk/phase3-activities/wwwCorba.html, ANSA Web project.

Copyright

© Southern Cross University, 1995. Permission is hereby granted to use this document for personal use and in courses of instruction at educational institutions provided that the article is used in full and this copyright statement is reproduced. Permission is also given to mirror this document on WorldWideWeb servers. Any other usage is expressly prohibited without the express permission of Southern Cross University.
Return to the AusWeb95 Table of Contents

AusWeb95 The First Australian WorldWideWeb Conference