N-JIS: a System for Web Services Integration in Java RMI Distributed Applications

Transcription

1 N-JIS: a System for Web Services Integration in Java Distributed Applications M. Bianchi Dipartimento di Informatica, Universitá di L Aquila, Via Vetoio L Aquila, Italy. bianchi@netlab.rm.cnr.it C. Gaibisso Netlab, Istituto di Analisi dei Sistemi ed Informatica Antonio Ruberti, Consiglio Nazionale delle Ricerche, V.le Manzoni, Rome, Italy. gaibisso@iasi.rm.cnr.it G. Gambosi Netlab, Istituto di Analisi dei Sistemi ed Informatica Antonio Ruberti, Consiglio Nazionale delle Ricerche, V.le Manzoni, Rome, Italy. Dipartimento di Matematica, Universitá di Roma Tor Vergata, Via della Ricerca Scientifica Rome, Italy. gambosi@mat.uniroma2.it ABSTRACT In this paper we describe the main architectural and implementation aspects of a system, the Netlab Java Integration of distributed applications to access RPC based Web Services in the same way they access Objects. Moreover N-JIS allows to register multiple components, either 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,, 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 [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 (), 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).

2 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 of distributed applications to access RPC based Web Services in the same way they access Objects. Moreover, N-JIS allows to register multiple components, either 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 is not casual. Among the currently available distributed programming technologies, 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, such as DCOM and CORBA. According to our operational model, in order to be accessed by based distributed applications, RPC based Web Services and 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 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 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 Based Distributed Applications Request New N JIS Service Definition Request N JIS 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 and a list of points of access to a set of s providing the same service defined by the Java Remote. The pair (N-JIS Name, Java Remote ), will be referred to as N-JIS Service. An is either an Object or an RPC based Web Service, respectively referred to as Component and in what follows. The point of access to an Component is the absolute address of the component itself. The point of access to a WS Component is the absolute address of an object implementing a mapping between the methods of the Java Remote and those exposed by the. This object, referred to as in what follows, is automatically generated by the system at the time of registering the, and makes it possible to undirectly invoke any method exposed by the by simply invoking the corresponding Java Remote method. An absolute address takes the form rmi:// hostname [: nameservport ]/ servname, where hostname is a name recognised on the local area network or a DNS name on the Internet, and a nameserv- Port 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 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 based distributed applications, only have to specify the N-JIS name associated to the remote interface they are interested in, and

3 N JIS Developers Service Registrator Java Remote Points of Access Java Remote Points of Access Activator Java Remote Points of Access Based Applications Selector Figure 3. content Figure 2. Main N-JIS logic components and their interactions an evaluation criterion to be applied by N-JIS in the selection of RPC components. They need not be aware of any absolute address. N-JIS selects the best RPC component, according to the specified evaluation criterion, among those associated to the specified N-JIS name. s criteria are more deeply treated in [13]. If the component is an object, its absolute address is returned to the application. Otherwise, if the component is a Web Service, N-JIS returns the absolute address of a, i.e. an object implementing a mapping between the methods in the N-JIS Service Remote and those exposed by the Web Service. It is worth noting that, apart from whether the selected RPC component is an or a, N-JIS always returns the address of an object implementing the remote interface associated to the selected N- JIS Name, thus making it possible to refer RPC based Web Services the same way objects are referred. Service Registrator Component Information Component Component Component Component Information Activator 3 N-JIS Software Architecture As shown in figure 2, N-JIS has three main architecture components: a Service Registrator, a Activator and an 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, as shown in figure 3. Inside the Service Registrator the 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 to be registered. In the case of an Component, its absolute address is required. Registering a is a bit more complicated. In fact, the following information must to be supplied: Figure 4. Service Registrator architecture the of a describing the ; the which specifies the mapping between the methods in the Java Remote associated to the N-JIS Name and those exposed by the, described by the WSDL file. Once identified the type of the to be registered, the delegates the registration process either to the Component or to the. The Component, simply adds the absolute address of the component to the list of addresses associated to the N-JIS Name in the. The invokes

4 Service Registrator Distributed Application Activator JVM Run Request Registry Code Remote Object Remote Object Code Generator WSDL Internet Selector Evaluator Value of Convenience Evaluator Evaluator Selector Value of Convenience Component Component Evaluator List of es Figure 5. Activator architecture Figure 6. Selector architecture the Activator to generate and instantiate a implementing the mapping described by the, receiving back its absolute address. Finally, the WS Component adds this address to the list of addresses associated to the N-JIS Name in the. 3.2 The Activator Component As shown in figure 5, the inputs to the Activator component are a N-JIS Name, a and the of a WSDL file. The Activator is in charge of generating and running a implementing the mapping between the methods of the Remote Java and those listed in the WSDL file according to the mapping coded in the. Inside the Activator, the retrieves the Java Remote associated to the N-JIS Name in the and generates an absolute address for the, which is not yet assigned. The then invokes the Code Generator to generate the code taking into account the absolute address assigned to the, the of the WSDL file, the and the Java Remote. Finally, the runs the on a local JVM and returns the absolute address of the to the Service Registrator. 3.3 The Selector Component As shown in figure 6, the Selector selects the best associated to the specified N-JIS Name, according to the specified evaluation criterion. If the selected is a, the Remote Object Selector returns the absolute address of the corresponding, otherwise returns the absolute address of the selected Component. Inside the Selector, the Selector is the system interface toward the based distributed application. First of all, it retrieves the list of the absolute addresses associated to the N- JIS Name in the. Then, for each address in this list, the RPC Component Selector invokes the Evaluator to evaluate the convenience of the corresponding according to the adopted evaluation criterion. The same component collects all the values of convenience computed by the Evaluator and returns to the application the address corresponding to the

5 best of them. Inside the Evaluator, the Evaluator, depending on the incoming address and the selected evaluation criterion, selects the Object Evaluator or the Web Services Evaluator to use. The Evaluator receives back a value of convenience and returns it to the Remote Object Selector. 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 technologies; the dynamic generation of the has been made possible by the use of the Sun Web Service Developer Pack [14]; the content is distributed in several Lightweight Directory Access Protocol (LDAP) servers [15],[16]. Thus distributing the management of the archive content; the 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 of distributed applications to access RPC based Web Services in the same way they access Objects. Moreover N-JIS allows to register multiple components, either 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 s will be available to developers of distributed applications. For the next future it is our intention to extend N- JIS 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. 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. Java- Soft, May : [2] J. Gosling, H. McGilton: The Java Language Environment. JavaSoft, October : [3] G. Coulouris, J. Dollimore, T. Kindberg, Distributed Systems Concepts and Design ( 2ed., Addison Wesley). [4] The Official CORBA Site: [5] The Official DCOM Site: com/tech/dcom.asp. [6] Java Specification: Sun Microsystems Inc., 1999, [7] -IIOP Programmer s Guide: Sun Microsystems Inc., 1999, 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: [10] W3C, WSDL: [11] Peter Hrastnik, Comparison of Distributed System Technologies for E-Business, Proc. of the ¾ Ò International Interdisciplinary Conference on Electronic Commerce (ECOM-02), Sopot, Poland, November, [12] Fundamentals of : Short Course by jguru, [13] M. Bianchi, C. Gaibisso, M. Vitale A Java Meta- Registry for Remote Service Objects, Proc. of the Communications, Internet and Information Technology (CIIT 2002), St. Thomas, US Virgin Islands, November, [14] Sun Microsystem Co., Java Web Services Developer Pack: [15] LightWeight Directory Access Protocol (v2): RFC 1777, txt. [16] H.Johner, L.Brown, F.S.Hinner, W.Reis, J.Westman, Understanding LDAP: redbooks.ibm.com. Acknowlegments