N-JIS: a System for Web Services Integration in Java RMI Distributed Applications M. Bianchi Dipartimento di Informatica, Universit´a di L’Aquila, Via Vetoio - 67010. L’Aquila, Italy. e-mail:
[email protected] C. Gaibisso Netlab, Istituto di Analisi dei Sistemi ed Informatica ”Antonio Ruberti”, Consiglio Nazionale delle Ricerche, V.le Manzoni, 30 - 00185 Rome, Italy. email:
[email protected] G. Gambosi Netlab, Istituto di Analisi dei Sistemi ed Informatica ”Antonio Ruberti”, Consiglio Nazionale delle Ricerche, V.le Manzoni, 30 - 00185 Rome, Italy. Dipartimento di Matematica, Universit´a di Roma ”Tor Vergata”, Via della Ricerca Scientifica - 00133 Rome, Italy. email:
[email protected] ABSTRACT In this paper we describe the main architectural and implementation aspects of a system, the Netlab Java Integration System (N-JIS), which makes it possible to developers of RMI distributed applications to access RPC based Web Services in the same way they access RMI Objects. Moreover N-JIS allows to register multiple components, either RMI Objects or Web Services, providing the same functionalities and is able to perform a run time selection of the best component according to a programmer specified evaluation criterion. KEY WORDS Web Services, Software Reuse, RMI, Distributed Programming Technologies Integration
1 Introduction The last five years have seen the widespread diffusion of object oriented programming languages, in particular Java [1], [2], and of the connectors and components based approach in the design and implementation of distributed systems and applications. At the same time, thanks to the large availability of computer networks, the interest of major software technologies producers has been captured by distributed systems potentiality [3]. This interest resulted in the definition of distributed object oriented software architectures, such as CORBA [4], DCOM [5] and RMI [6],[7], based on the client-server paradigm. These technologies extend traditional object-oriented systems by making it possible to distribute and run objects
on any of the hosts of a computer network. The derived problem of objects interaction is addressed by abstracting and hiding networking issues, thus letting programmers concentrate on the business logic of their applications. The basic idea behind network abstractions, like Remote Procedure Call (RPC), is make it possible for both clients and servers to agree on a local calling convention and thereby be unaware of the details of calling remote implementations or of being remotely called. The concept of interface is crucial in the definition of a calling convention. An interface declares the sets of operations available to the clients to interact with the servers. Each operation is identified by a name and by a signature. The major drawback of currently available distributed architectures is that they are not compatible, i.e. they adopt different conventions for the objects to locate and communicate each other. Web Services technology has been recently introduced to solve this incompatibility. According to a Microsoft definition quoted by [8], ”A Web Service is programmable application logic accessible using standard Internet protocols. Web Services combine the best aspects of component-based development and the Web. Like components, Web Services represent black-box functionality that can be reused without worrying about how the service is implemented. Unlike current component technologies, Web Services are not accessed via object-modelspecific protocols, such as the Distributed Component Object Model (DCOM), Remote Method Invocation (RMI), or Internet Inter-ORB Protocol (IIOP). Instead, Web Services are accessed via ubiquitous Web protocols and data formats, such as Hypertext Transfer Protocol (HTTP) and Extensible Markup Language (XML)”.
SOAP [9] and WSDL [10] have become the facto standards for Web Services messaging and invocation, and description, respectively. WSDL files describe exactly what messages needs to be sent and how to use the various Internet standard messaging protocols and encoding schemes in order to format the messages to be acceptable to the service provider. In addition WDSL files describe where the service is located, or more precisely, to which network address messages must be sent in order to invoke the Web Service [8]. In this paper we describe the main architectural and implementation aspects of a system, the Netlab Java Integration System (N-JIS), which makes it possible to developers of RMI distributed applications to access RPC based Web Services in the same way they access RMI Objects. Moreover, N-JIS allows to register multiple components, either RMI Objects or Web Services, providing the same functionalities and is able to perform a run time selection of the best component according to a programmer specified evaluation criterion. It is worth noting that:
the choice of RMI is not casual. Among the currently available distributed programming technologies, RMI is the less flexible one with respect to the integration with other not-Java based solutions [11]; despite the choice of the particular technological scenario, the proposed architecture is general enough to be easily extended to distributed programming technologies other than RMI, such as DCOM and CORBA. According to our operational model, in order to be accessed by RMI based distributed applications, RPC based Web Services and RMI Objects have to be registered in the system. The whole registration process is automatic, with the only exception, in the case of RPC based Web Services, of the definition of a mapping between the methods of a remote Java interface and those exposed by an RPC based Web Service. This mapping cannot be automatically derived, unless some semantic information concerning the methods signatures is available. Once RMI objects and Web Services have been registered, programmers may identify remote components by specifying the corresponding remote interface and an evaluation criterion to be adopted by N-JIS to perform the selection among the registered components implementing that interface. N-JIS will, independently from the selected component return an RMI absolute address, . The paper is organized as follows: section 2 introduces the N-JIS main functionalities; section 3 describes the main aspects of the N-JIS architecture; section 4 provides some implementation details of a N-JIS prototype; Finally, section 5 summarizes the advantages introduced by the adoption of N-JIS and describes some possible future works.
RPC Component Developer
RPC Component Registration Request
RMI Based Distributed Applications
N−JIS Name Evaluation Criterion
New N−JIS Service Definition Request
N−JIS
RMI Address
Figure 1. Main functionalities offered by N-JIS
2 N-JIS Main Functionalities The main idea underlying N-JIS is to associate a N-JIS Name to a Java Remote Interface and a list of points of access to a set of RPC Components providing the same service defined by the Java Remote Interface. The pair (N-JIS Name, Java Remote Interface), will be referred to as N-JIS Service. An RPC Component is either an RMI Object or an RPC based Web Service, respectively referred to as RMI Component and WS Component in what follows. The point of access to an RMI Component is the RMI absolute address of the component itself. The point of access to a WS Component is the RMI absolute address of an RMI object implementing a mapping between the methods of the Java Remote Interface and those exposed by the WS Component. This RMI object, referred to as Proxy in what follows, is automatically generated by the system at the time of registering the WS Component, and makes it possible to undirectly invoke any method exposed by the WS Component by simply invoking the corresponding Java Remote Interface method. An RMI absolute address takes the form rmi://[:]/, where hostName is a name recognised on the local area network or a DNS name on the Internet, and a nameServPort is required if the naming service is running on a port different from the default one [12]. As shown in figure 1, two main user categories are interested in the services offered by N-JIS:
developers who wants their RPC components to be available to distributed applications programmers; developers of RMI based distributed applications. N-JIS makes it possible for developers of RPC components to define new N-JIS Services and to register RPC Components as new implementations of already existing N-JIS Services. In what follows we will not deal with the problem of defining a new N-JIS Service, since it really does not introduce any significant difficulty with respect to that of registering a new RPC component. In writing their code, developers of RMI based distributed applications, only have to specify the N-JIS name associated to the remote interface they are interested in, and
N−JIS N−JIS Name Java Remote Interface
RPC Component Developers
Service Registrator
N−JIS Name Java Remote Interface N−JIS Name Java Remote Interface
Proxy Activator
RMI Based Applications
Points of Access
Registration Archive
Figure 3. Registration Archive content RMI Component Registration Information
As shown in figure 2, N-JIS has three main architecture components: a Service Registrator, a Proxy Activator and an RPC Component Selector.
3.1 The Service Registrator Component The Service Registrator component processes the registration of new RPC components. It maintains all the information concerning already registered RPC compontents in a Registration Archive, as shown in figure 3. Inside the Service Registrator the Registration Interface collects the information required to successfully complete a registration. Apart from the N-JIS Name, that must be always specified, this information is dependent from the type of the RPC Component to be registered. In the case of an RMI Component, its RMI absolute address is required. Registering a WS Component is a bit more complicated. In fact, the following information must to be supplied:
Service Registrator
Figure 2. Main N-JIS logic components and their interactions
3 N-JIS Software Architecture
Points of Access
Registration Archive
RPC Component Selector
an evaluation criterion to be applied by N-JIS in the selection of RPC components. They need not be aware of any RMI absolute address. N-JIS selects the best RPC component, according to the specified evaluation criterion, among those associated to the specified N-JIS name. Evaluations criteria are more deeply treated in [13]. If the component is an RMI object, its RMI absolute address is returned to the application. Otherwise, if the component is a Web Service, N-JIS returns the RMI absolute address of a Proxy, i.e. an RMI object implementing a mapping between the methods in the N-JIS Service Remote Interface and those exposed by the Web Service. It is worth noting that, apart from whether the selected RPC component is an RMI or a WS Component, N-JIS always returns the address of an RMI object implementing the remote interface associated to the selected NJIS Name, thus making it possible to refer RPC based Web Services the same way RMI objects are referred.
Points of Access
WS Component Registration Information
N−JIS Name
N−JIS Name
RMI Component Address
WSDL File URL Mapping File
Registration Interface
N−JIS Name RMI Component Address
RMI Component Registration Manager RMI Component Address
N−JIS Name WSDL File URL Mapping File
WS Component Registration Manager
Proxy Activator
N−JIS Name WSDL File URL Mapping File Proxy RMI Absolute Address
Proxy RMI Absolute Address
Registration Archive
Figure 4. Service Registrator architecture
the URL of a WSDL File describing the WS Component; the Mapping File which specifies the mapping between the methods in the Java Remote Interface associated to the N-JIS Name and those exposed by the WS Component, described by the WSDL file. Once identified the type of the RPC Component to be registered, the Registration Interface delegates the registration process either to the RMI Component Registration Manager or to the WS Component Registration Manager. The RMI Component Registration Manager, simply adds the RMI absolute address of the RMI component to the list of addresses associated to the N-JIS Name in the Registration Archive. The WS Component Registration Manager invokes
Service Registrator
Proxy Manager
Proxy Code
JVM
Proxy Proxy Proxy RMI Registry
Remote Object Interface
Proxy RMI Absolute Address Remote Object Interface WSDL File URL Mapping File Proxy Code Generator
WSDL File
RMI N−JIS Name Absolute Evaluation Address Criterion
RPC Component Selector Manager
Value of Convenience
RMI Absolute Address Evaluation Criterion
RPC Component Evaluator
Proxy Activator
Proxy Run Request
Proxy RMI Absolute Address
RPC Component Selector
N−JIS Name WSDL File URL Mapping File
Distributed Application
Registration Archive
RPC Component Evaluator Manager
List of RMI Absolute Addresses
Registration Archive
Evaluation Evaluation Value Criterion Criterion of Proxy Convenience RMI RMI Component Absolute Address Address WS Component Evaluator
RMI Component Evaluator
Internet
Figure 6. RPC Component Selector architecture Figure 5. Proxy Activator architecture
the Proxy Activator to generate and instantiate a Proxy implementing the mapping described by the Mapping File, receiving back its RMI absolute address. Finally, the WS Component Registration Manager adds this address to the list of addresses associated to the N-JIS Name in the Registration Archive.
3.2 The Proxy Activator Component As shown in figure 5, the inputs to the Proxy Activator component are a N-JIS Name, a Mapping File and the URL of a WSDL file. The Proxy Activator is in charge of generating and running a Proxy implementing the mapping between the methods of the Remote Java Interface and those listed in the WSDL file according to the mapping coded in theMapping File. Inside the Proxy Activator, the Proxy Manager retrieves the Java Remote Interface associated to the N-JIS Name in the Registration Archive and generates an RMI absolute address for the Proxy, which is not yet assigned. The Proxy Manager then invokes the Proxy Code Generator to generate the Proxy code taking into account the RMI absolute address assigned to the Proxy, the URL of the WSDL file, the Mapping File and the Java Remote Interface.
Finally, the Proxy Manager runs the Proxy on a local JVM and returns the RMI absolute address of the Proxy to the Service Registrator.
3.3 The RPC Component Selector Component As shown in figure 6, the RPC Component Selector selects the best RPC Component associated to the specified N-JIS Name, according to the specified evaluation criterion. If the selected RPC Component is a WS Component, the Remote Object Selector returns the RMI absolute address of the corresponding Proxy, otherwise returns the RMI absolute address of the selected RMI Component. Inside the RPC Component Selector, the RPC Component Selector Manager is the system interface toward the RMI based distributed application. First of all, it retrieves the list of the RMI absolute addresses associated to the NJIS Name in the Registration Archive. Then, for each RMI address in this list, the RPC Component Selector Manager invokes the RPC Component Evaluator to evaluate the convenience of the corresponding RPC Component according to the adopted evaluation criterion. The same component collects all the values of convenience computed by the RPC Component Evaluator and returns to the application the address corresponding to the
best of them. Inside the RPC Component Evaluator, the RPC Component Evaluator Manager, depending on the incoming address and the selected evaluation criterion, selects the RMI Object Evaluator or the Web Services Evaluator to use. The RPC Component Evaluator Manager receives back a value of convenience and returns it to the Remote Object Selector Interface. The structure and functionality of these evaluators are not subjects of this paper.
4 Implementation Notes This section contains some implementation notes concerning the development of a first prototype of N-JIS. The implementation activity has been oriented toward the realization of a first prototype of the N-JIS system by which testing its functional correctness. All adopted solutions have the aim of privileging code reusability and system scalability. More in details:
the prototype is implemented in Java and make massive use of RMI technologies; the dynamic generation of the Proxy has been made possible by the use of the Sun Web Service Developer Pack [14]; the Registration Archive content is distributed in several Lightweight Directory Access Protocol (LDAP) servers [15],[16]. Thus distributing the management of the archive content; the Proxy code generation is accomplished by personaziling a Java Template, which is not dependent by the particular mapping to be implemented.
5 Conclusions and Further Works In this paper we described the main architectural and implementation aspects of a system, the Netlab Java Integratio System (N-JIS), which makes it possible to developers of RMI distributed applications to access RPC based Web Services in the same way they access RMI Objects. Moreover N-JIS allows to register multiple components, either RMI Objects or Web Services, providing the same functionalities and is able to perform a run time selection of the best component according to a programmer specified evaluation criterion. As a consequence, a larger set of RPC Components will be available to developers of RMI distributed applications. For the next future it is our intention to extend NJIS functionalities to support the dynamic discovering and binding of Web Services. Furthermore we would like to generalize our architecture to offer N-JIS functionalities to DCOM and CORBA developers too. Acknowlegments
The authors wish to thank Flavio Lombardi and Maurizio Vitale for their technical support, comments and suggestions.
References [1] D. Kramer: The Java Platform, A White Paper. JavaSoft, May 1996. URL: http://www.javasoft.com. [2] J. Gosling, H. McGilton: The Java Language Environment. JavaSoft, October 1995. URL: http://www.javasoft.com. [3] G. Coulouris, J. Dollimore, T. Kindberg, Distributed Systems Concepts and Design ( 2ed., Addison Wesley). [4] The Official CORBA Site: http://www.corba-org. [5] The Official DCOM Site: http://www.microsoft.com/ com/tech/dcom.asp. [6] Java RMI Specification: Sun Microsystems Inc., 1999, http://java.sun.com/rmi/. [7] RMI-IIOP Programmer’s Guide: Sun Microsystems Inc., 1999, http://java.sun.com/pro ducts/rmiiiop/index.html. [8] S. Graham, S. Simeonov, T. Boubez, and alt. Building Web Services with Java, SAMS Ed., (2002). [9] W3C, SOAP v1.1: http://www.w3.org/TR/SOAP [10] W3C, WSDL: http://www.w3.org/TR/wsdl [11] Peter Hrastnik, Comparison of Distributed System Technologies for E-Business, Proc. of the 2nd International Interdisciplinary Conference on Electronic Commerce (ECOM-02), Sopot, Poland, November, 2002. [12] Fundamentals of RMI: Short Course by jGuru, 1999 http://java.sun.com/rmi/. [13] M. Bianchi, C. Gaibisso, M. Vitale A Java MetaRegistry for Remote Service Objects, Proc. of the Communications, Internet and Information Technology (CIIT 2002), St. Thomas, US Virgin Islands, November, 2002. [14] Sun Microsystem Co., Java Web Services Developer Pack: http://java.sun.com/webservices [15] LightWeight Directory Access Protocol (v2): RFC 1777, http://www.ietf.org/rfc/rfc1777. txt. [16] H.Johner, L.Brown, F.S.Hinner, W.Reis, J.Westman, Understanding LDAP: http://www. redbooks.ibm.com.
