Rapid Application Development of Middleware Components by Using XML

*Gerd Nusser'i2 'Ralf-Dieter Schimkat'

Wilhelm-Schickard Institute for Computer Science Symbolic Computation Group

University of Tubingen Sand 13, D-72076 Tubingen, Germany

Institute for Applied Research University of Applied Sciences Reutlingen

Alteburgstr. 150, D-72762 Reutlingen, Germany

{ nusser, schimkat} @ informatik.uni-tuebingen.de

Abstract

Towards a general service infrastructure of cooperating services and devices, the gap between different systems and programming languages has to be overcome. As the tremen- dous success of the World Wide Web mainly depends on open standards, it is necessary to create an open standard regarding distributed interacting services. To create system and language independent services the presentation of ser- vices at a meta level is inevitable. The main goal of the pre- sented system is the dynamic creation of system independent XML applications to automatically generate programming language and middleware dependent components.

1 Introduction and motivation

Towards a general service infrastructure of cooperating services and devices [ 131, the gap between different sys- tems and programming languages has to be overcome. Mid- dleware technologies provide facilities to make the devel- opment of distributed software systems easier by provid- ing different kinds of services[l]. They factor out details about different hardware and software platforms by enhanc- ing the level of abstraction. Middleware technologies, like for example CORBA [lo], offer the possibility to develop software systems which are based on different platforms and different programming languages. In CORBA this is

*Supported by the Ministerium fur Wissenschu), Forschung und Kunst

t Supported by T-Systems Document Management Solutions DMS/PP of the state of Baden-Wurttemberg, Germany.

1074-6005'01 $10.00 0 2001 IEEE

done by an uniform description of application interfaces with respect to CORBA's interface definition language and a well defined mapping between different languages and data types defined in these languages [8]. However, there are also some problems regarding distributed systems. Gener- ally, most existing middleware technologies rely on the con- cept of remote procedure calls to abstract away the artifact of remote locations [2].

The kind of middleware architecture, which is used for developing a software system, is a major concern during the development process. Usually the developed system is more or less bound to the chosen middleware architecture. Even worse, from a developers point of view, the choice of a specific middleware architecture dominates the overall ar- chitecture and implementation of software systems. Due to this close coupling of middleware and application design, changes and modifications of the middleware have always direct consequences on the design of applications. Each time a new architecture is introduced software architects and developers have to learn how to integrate their exist- ing applications in these middleware technologies. When- ever a specific middleware changes the developers have to change their applications. Regarding new middleware ar- chitectures, like for example Jini [ 161, this can be a very an- noying process, because of the permanent changes regard- ing the application programmers interfaces. This fact gets even worse if the source code of the application which has to be integrated is not available. The heterogeneity of avail- able platforms is another problem to be concerned with. For example the component object model (COM) [5] is primar- ily available on Microsoft platforms. Of course, there are

116

solutions to integrate COM objects in other middleware ar- chitectures like e.g. CORBA, but whenever a new system is integrated, the same problems, as mentioned before, appear.

As far as embedded systems with only limited resources are concerned, the integration of these systems in common middleware architectures, as for example Jini, takes much effort [7].

The system described in this paper offers the possibil- ity to easily integrate existing applications based on either Java and COM into different Java based middleware archi- tecture.s. This integration process is mainly done by reflec- tion and the representation of application objects with the extensible Markup Language (XML) [ 191. XML serves as a system independent language to represent application objects. In the current system Java and COM objects are supported. The resulting XML files can be used to dynam- ically create the necessary interface to participate in differ- ent middleware architectures and technologies respectively. Currently only the Java based technologies RMI [17] and Jini are supported, but the system can easily be extended to support other middleware architectures.

In the following section the generation of system inde- pendent XML representation out of Java and COM based objects is introduced. Then the process to create middle- ware dependent components is described. Finally the paper concludes with an outlook to future work and a summary.

2 Approach

The core component of the proposed system is based on standardized and generic object and application representa- tions. An object is a code fragment and provides some func- tionality which can be accessed through well defined inter- faces. Usually these interfaces are implemented in a partic- ular programming language. For the representation of ob- jects in a generic way (OML), XML, a subset of SGML, the Standard Generalized Markup Language [4] is used. XML is an ”open, platform independent and vendor independent standard” [9], XML is easy to parse, and there are a lot of tools and APIs which support the XML standard.

The vital approach for rapid application development based on OML consists of two parts, representation and generation, as illustrated in figure 1.

In the first step, OML objects are generated. Program- ming language dependent objects have to provide some sort of reflection capabilities in order to determine object and in- terface definitions dynamically. Then, based on OML, ded- icated middleware components are generated automatically.

The introduction of the concept of OML’s separates the specification and the implementation of objects with re- spect to the kind of the middleware architecture. As shown in figure 1 the described approach offers the possibility to automatically generate a set of different middleware com-

Representation j Generation

Figure 1. General system overview

ponents for a given object. The representation of objects and their respective functionality (services) in XML and the concept of middleware generators based on these XML rep- resentations provide the following benefits:

1.

2 .

3 .

4.

5 .

6.

117

Applications which might not provide any remote ac- cessability capabilities can easily be integrated into a heterogenous and distributed environment, such as the Internet.

The integration process is independent of a proprietary middleware technology. In fact, OML representations provide uniform interface descriptions of application objects.

Objects which have already been integrated with re- spect to OML representations can be reused in differ- ent middleware-related application settings. This leads to more reliable and stable software applications be- cause already integrated and tested objects can be read- ily deployed by middleware technologies which the objects have not been originally designed for.

By making OML representations persistent using database-related technologies, structural query and re- trieval facilities can be applied to OML representa- tions.

The process of generating OML representations and middleware components can be applied automatically which is less error-prone. Furthermore, applications can use and generate middleware components on the fly which serves as the basis for highly dynamic appli- cation environments, such as mobile applications. Ap- plications (e.g. software agents) might search for par- ticular services which are stored in an OML-database (see (4.)). Then, middleware components related to the requested services are generated dynamically at run- time without involving any user or manual interaction.

Due to its inherent relation to XML, OML represen- tations are based on open standards which offer Aexi-

bility and extensibility with respect to future develop- ment trends. Furthermore, a wide range of different tools support the use of XML applications.

7. The overall development and integration of new appli- cations is speed up tremendously due to the abstraction potentials of OML and the automation of the software generation process.

3 Implementation

As mentioned before, the rapid application development based on OML consists of two parts, the general XML ob- ject representation and the generation of middleware depen- dent components, which are discussed in the following sec- tions.

The system basically consists of two parts, reflection and generation. The first part is needed to introspect Java and COM objects. The second part is used to generate middle- ware dependent components.

3.1 XML representation of application objects

The system presented in this paper uses XML and the Java based API JAXP [14] to generate OML representa- tions. The system currently supports Java and COM objects. As Java and COM differ in the way they are represented and stored in the system, there are different techniques to create an OML representation.

Whereas Java supports introspection at the language level, COM uses so called type information stored in sep- arate files or together with the executable. In the following, different techniques of how to determine the behavior of an application object which is specified by their interface, are introduced.

3.1.1

In general, a Java object is a piece of system and machine independent byte code (Java class file), which can either be loaded from the file system or across a network and be executed by a Java Virtual Machine (JVM).

As mentioned before the mapping of Java to XML uses a built-in Java technology called reflection. "Reflection pro- vides the mechanism to detect the available methods" [3] of an object. Through reflection it is possible to determine the constructors and methods of an object along with their pa- rameter types, return types, and exception types. Obviously only the public members of a class file can be retrieved.

To generate an XML description of a Java object an instance of type java.lang.Class with a specified name is created. The class Class supports the concept of re- flection. To retrieve the constructors of an object the

XML representation of Java objects

method Class.getDeclaredConstructors() is used. It re- turns an array of constructors which is then used to re- trieve the name, parameter types, and exception types of each constructor defined by the object. Analogously, the methods of an object are extracted with the method Class.getDeclaredMethods() which returns an array of ob- jects of type java.lang.reject.Method. Then the Class Method is used to retrieve the name, return type, parame- ter types, and exception types of these methods.

With this technique, all the necessary information to rep- resent an object is extracted and stored as an OML represen- tation as shown in figure 2.

< ? m l version=" 1.0" encoding= "UTF- 8 " ? > <!DOCTYPE XmlClass SYSTEM"E:\K2\ml\JavaClass.dtd"> <XmlClass> <Class Name="PerfectTime"/> <Imports/> <Constructors>

</Constructors> <Methods>

<Constructor Name="PerfectTime"/>

<Method Name="get Per f ectTime" ReturnType= " long"> <Exceptions>

</Exceptions> <Exception Name= "e3 I' Type= " j ava . lang. Exception" / >

</Method> </Methods>

</XmlClass>

Figure 2. An OML representation of a simple Java object.

During the extraction process, it is checked whether ex- ternal objects are referenced. Whenever an external object, like for example java.lang.String, is referenced, the corre- sponding package name along with the object type is added to the list of imports and stored in the imports section of the XML representation.

3.1.2

The Component Object Model (COM) [5] "defines a com- mon way to access software services. Every COM object supports one or more interfaces, each of which includes a number of methods" [ 121. These interfaces are typically de- fined using IDL which is further used to create the so called type information (type library).

To access a COM object's type information from inside Java the system uses a slightly modified version of a Java to COM bridge named JCom which is described in [ 181. To browse COM objects it is possible to either use a type li- brary file or to search the Windows registry for a specific key, which leads to a type library stored in the filesystem. For example, to access the Internet Explorer COM object the key InternetExploreKApplication is searched in the reg- istry. If an entry is found, the corresponding class identifier

XML representation of COM objects

118

(CLSID) is used to search for the corresponding type library which belongs to the given COM object.

To access the type information the Java COM bridge class ITypeInfo is used. This class offers methods to extract the name and the objects defined in a given type library. The basic structure of a type library consists mainly of the following parts: Enums, Dispinterfuces, CoClasses, and In- terfaces. For each of these parts the necessary information, i.e. names, methods, and parameters, is extracted. Each of these parts is stored as a separate sub tree in the correspond- ing OML document. Compared to the Java OML , the COM OML usually contains more than one object.

As Java and COM define different data types and the COM objects are used from inside Java, i t is necessary to map the COM types to appropriate Java types [6 ] . In prin- ciple, the mapping can be applied at any time during the generation process, as shown in figure 3 .

3.1.3 XML unification

As mentioned above, currently the XML representation of COM and Java objects are different. This is due to the dif- ferent information retrieval capabilities and internal repre- sentation regarding Java and COM objects. It would be de- sirable to unify the XML presentation of objects, but this will be part of the future work (see section 4). The current implementation does not support unified object representa- tions, which has to be kept in mind for the following sec- tions.

3.2 Generation of middleware components out of OML representations

In this section, the technique to generate middleware de- pendent components is introduced. The XML parsing pro- cess of OML representations to generate middleware com- ponents varies slightly due to the different XML represen- tations of Java and COM objects.

The generated middleware components use Java as the implementation language, and Java technologies like RMI and Jini. From the current implementation point of view, the generation of middleware supports the mapping from Java and COM OML to RMI, and Java OML to Jini. Figure 3 gives an overview on the generation process.

3.2.1

In general RMI is an object based remote procedure call. To support RMI, it is necessary to define a Java interface where the externally accessible functionality of a Java object is de- fined. This interface is later used to register with the RMI registry, the naming service of Java RMI.

To generate a Java interface from Java OML, the respec- tive OML is processed and a Java interface which extends

Java OML to Java RMI

Figure 3. An overview of the generation of middleware components

java.rmi.Remote is created. The name of the interface set to <objectname>Servicel. This interface is stored a class file named <objectname>Servicel.juvu. The in- terface defines the whole set of methods along with their return values and parameters. If RMI is used, i t is neces- sary that each of these methods throws an exception of type java.rmi.RemoteException. To define any external object references the import section of the Java OML is inserted in the Java class file.

To generate an implementation of the interface, a Java source file with the name <objectname>Service.java is created. This file holds a class which extends java. rmi.servel: UnicastRemoteObject and implements the previously mentioned interface. The original object, the one which is used to generate the OML, is inserted as a private member. For each constructor which is defined by the orig-

' inal object, a constructor which throws an exception of type RemoteException is created. Inside these constructors, the corresponding constructor of the original object is called. By this the member variable, mentioned above, is instanti- ated.

The methods as defined in OML and in the gener- ated interface, are inserted as public methods with the method names of the original object including an addi- tional prefix svc-. This different naming is necessary, be- cause it is possible that some methods cannot be overrid- den in java.rmi.Remote0bject which is a superclass of Uni- castRemoteObject. For example, the method hashcode() of Remoteobject cannot be overridden by hashcode() of java.lang.String, which would be necessary if a RMI object of type java.lang.String is built.

Each of the methods throws an exception of type Remo- teException. Inside each method the corresponding method of the object, which have been created in one of the con- structors, is called. If a method throws an exception, this exception is catched and thrown as a new exception of type RemoteException which holds the original exception. In the last step a simple main method is added to the implemen- tation, which creates a new object of the implementation class and registers this object with the RMI registry. In sec- tion 3.2.4, a way to parameterize the generated code for the

is in

119

registration process is shown. 3.2.4 Parameterization of the middleware component creation process

As shown in the previous sections, always the same pro- cess to create middleware dependent components is used and some additional code to participate in a special mid- dleware architecture is added to the components, like for example a simple main method to register objects with their respective naming servers. However in some cases it may be necessary to have more control over the creation process, i.e. it should be possible to set some parameters, which control the process of creation or to set some middleware dependent parameters to interact with the middleware layer in a predefined manner. Therefore, the current system sup- ports the usage of service description files, like depicted in figure 3, which consist of middleware architecture depen- dent parameters. An example of a Jini service description is shown in figure 4.

3.2.2 COM OMLtoJava RMI

The construction process of COM objects which are wrapped in RMI objects is quite similar to the process Java OML to Java RMI (see section 3.2.1). However, before RMI components are built, the COM objects are wrapped inside Java objects. Even though, this step is not neces- sary, it makes life easier and it does not cost to much ef- fort as the wrappers are build automatically using the COM OML generated in section 3.1. For each of the classes (i.e. Enums, CoClusses, and Disputchlnterjfuces) defined in the COM OML , corresponding Java wrappers are generated.

There are two possibilities to create the RMI related mid- dleware components. It is either possible to generate a Java OML out of the generated COM wrapper like described in section 3.1 and to proceed with the generation process as de- scribed in section 3.2 . l or to generate the RMI components out of the COM OML directly, similar to section 3.2.1.

When generating COM objects which are to be used by any middleware architecture, the following issues have to be taken into consideration. In typical client server scenar- ios, where clients and servers do not reside on the same ma- chine, it is unappropriate for COM objects to be serialized and sent over a network, because the needed resources may only exist on the server side. As many COM objects depend on a graphical user interface, a client which uses a remote COM object, can not use the graphical user interface, as the COM object is executed at the server side.

In contrast, it is useful to integrate COM objects with- out any graphical user interface and only local available re- sources like for example devices, which are somehow con- nected to a server. A typical COM object with these prop- erties is for example an OPC-Server [ 1 I], which offers a well-known COM interface to control various devices.

3.2.3 Java OML to Jini

As Jini heavily depends on RMI ' , the process to create the Jini wrapper classes is the same as the process of creating RMI wrapper classes. To register with the Jini naming ser- vice, called Jini lookup service, an appropriate main method is added. For testing purposes, the implementation file ad- ditionally implements the net.jini. fookup.ServiceIDListener interface and therefore has to provide an implementation of the method servicelDNotijjf). When a service is registered with the Jini lookup service, it gets a servicelD for identifi- cation.

'To be more precise, the reference implementation from Sun Microsys- tems is bound to RMI

<?ml version= " 1.0 " encoding= "UTF-8 " ?> <Service type="Jini" version="l. 1"> <SecurityManagement mgr="@SecurityManager" / > <DiscoveryManagement mgr="@DiscoveryManager"/> <LeaseRenewalManagement mgr="null" / > <Proxy name="PerfectTimeService" / > <Entries> <Entry type="Address" entry="@Address', / > <Entry type="Comment" entry="@Comment" / > <Entry type="Location" entry="@Location" / > <Entry type="Name" entry="@Name" / > <Entry type="ServiceInfo" entry="@ServiceInfo" / >

</Entries> <Parameters> <SecurityManager type="RMISecurityManager" / > <DiscoveryManager type="LookupDiscoveryManager" . . / > <Address country= "Germany" locality= "Tuebingen" . . / > <Comment comment="Perfect time" / > <Location building="Sand 1" floor="l" . , / > <Name name= " Service 'I / >

<ServiceInfo manufacturer="WSI" model="wSI" . . / > </Parameters>

</Service>

Figure 4. Example of a Jini service descrip- tion.

If such a file exists, the given parameters are taken in- stead of standard parameters. As far as Jini is concerned, it is possible to register some additional information, e.g. en- tries along with the service itself. As shown in figure 4 it is also possible to setup some managers, and the proxy object which has to be registered with the Jini lookup service.

4 Futurework

The existence of general XML descriptions of objects of- fers the possibility to integrate a wide range of distributed platforms like for example CORBA. The XML description can even be used to create Web applications based on Java Servlets [ 151 or some related technology. The idea is to use

120

XML to automatically generate HTML files and to automat- ically generate servlets, which are able to process HTTP re- quests. Taken this into consideration it would be possible to easily integrate applications and devices into the world wide web.

Currently the entire interface of an object is extracted and the entire interface is integrated in a middleware archi- tecture. Optionally it would be useful to support a graphical user interface to give users the possibility to influence the process of XML representation and component generation.

As the existence of a ’real’ object, which does the work, is not necessary, the creation of middleware components with no working counterpart, a virtual component, is pos- sible. This could be very interesting for testing and man- agement purposes, because some of the functionality could be checked before the integration process.

At the moment, the system provides two different XML representations for different technologies. It would be de- sirable to support only one standardized representation, like for example the XML Metadata Interchange (XMI), which ”in the wider context, can be viewed as a common meta- data interchange format that is independent of middleware technology” [9].

It is possible to store the generated XML representations in databases and search these databases for a specific ser- vice respective component. If such a service is found, i t can be integrated and used to process some dedicated task. For example, an application can search for a possibility to com- press or encrypt some data and dynamically integrate the service which offers this task.

5 Summary

The concept of generic XML object representations (OML) and middleware generators provide a loosely cou- pled integration environment which enables a rapid devel- opment of distributed applications. The overall system is extensible and adaptable. The automated generation of pro- prietary middleware components paves the ground for the deployment of (legacy) applications in a heterogenous and diverse world of interconnected systems.

Our presented system offers the possibility to introspect Java and COM objects and to generate respective XML rep- resentations out of these objects. These XML representa- tions are used to create middleware and programming lan- guage dependent middleware components. Although the system generates Java source it is not dependent to any spe- cific middleware or programming language as XML is used as an intermediate layer between the ’real’ object and the resulting middleware component.

References

P. Bernstein. Middleware: A Model for Distributed System Services. Communications of the ACM, 39(2):86-98, Jul 1996. A. Birell and B. Nelson. Implementing remote procedure calls. ACM Transactions on Computer Systems, 2( l), Feb. 1984. B. Eckel. Thinking in Java 2ndEdition. Prentice Hall, Upper Saddle River, NJ 07458,2000. ISO, http://www.iso.ch/cate/d16387.html. Standard Gener- alized Markup Language (SGML), 1986. Microsoft Corp., http://www.microsoft.com/com. Home Page for Microsoft COM: COM, DCOM, COM+ Technolo- gies. Microsoft Corp., http://www.microsoft.com/javakesource/- java-com2.htm. Technical Information: Using COM Ob- jects from Java. G. Nusser and G. Gruhler. Dynamic Device Management and Access based on Jini and CAN. In Proc. of the 7th In- ternational CAN Conference (ICC ’OO), Amsterdam Nether- lands, Oct 2000. CAN in Automation (CIA). Object Management Goup (OMG), http://www.omg.org/- tec hnology/documents/formal/corba_language_mapping~- specifica.htm. CORBA Language Mappings. Object Management Goup (OMG), http://www.omg.org/. OMG XML Metadata Interchange ( X M I ) Specijcation. Object Management Goup (OMG), http://www.omg.org/. The Common Object Request Broker: Architecture and Specification, Aug. 1997. Revision 2.1. OPC Task Force. OPC Overview. OPC Foundation, http://www.opcfoundation.org, October 1998. Version 1 .O. D. Rogerson. Understanding ActiveX and OLE. Microsoft Press, Redmond, Washington, 1996. R.-D. Schimkat, G. Nusser, and D. Buhler. Scalability and interoperability in service-centric architectures for the web. In Proc. of the 11th Inremational Workshop on Database and Expert Systems Applications (DEXA 2000), London- Greenwich UK, Sep 2000. IEEE Computer Society Press. Sun Microsystems, http://java.sun.com/xml. Java API for XML Parsing. Sun Microsystems, http://java.sun.com/servlet. Java Servler Technology. Sun Microsystems, http://www.sun.com/jini/. JINI Network Technology. Sun Microsystems, http://java.sun.com/products/jdk/l.2/- docs/guide/rmi/spec/rmiTOC.doc. html. Remote Method In- vocation Specification. K. Watanabe. JCom (Java-COM Bridge) Homepage. http://www 1 1 .u-page.so-net.ne.jp/ga2/no-ji/jcom/. World Wide Web Consortium (W3C), http://www.w3.org/- TWREC-xml. Extensible Markup Language (XML) 1.0.

121