Mediation Service: Heterogenous client handling

Transcription

1 LABORATOIRE D INFORMATIQUE DE L UNIVERSITE DE FRANCHE-COMTE Mediation Service: Heterogenous client handling Yohann Bardin Sylvain Dahan Sylvie Damy Bénédicte Herrmann Rapport de Recherche n RR THÈME 1 21 Octobre 2004 FRE CNRS 2661

2

3 Mediation Service: Heterogenous client handling Yohann Bardin, Sylvain Dahan, Sylvie Damy, Bénédicte Herrmann Thème 1 Distribution et Parallélisme 21 Octobre 2004 Abstract: In the distributed systems domain, sharing services became an important aim. Many software platforms offer tools to allow service providers to advertise their service offers and clients to access to these services. The use of these software platforms to access to a service means some constraints for clients. For example, a client who wants to access to a service, must be in the same software platform as the providers of this service. The service which is presented in this paper, facilitates service access and solves the problem of the client heterogeneity. Indeed, this service deals with the service access for the client and it proposes many access interfaces to allow heterogenous clients to access to services which this service manages. The name of this service is Mediation Service. Keywords: distributed systems, heterogeneity, service access Laboratoire d Informatique de l Université de Franche-Comté, UFR Sciences et Techniques, 16, route de Gray, Besançon Cedex (France) Téléphone : +33 (0) Télécopie : +33 (0)

4

5 Service de Médiation : Prise en charge de l hétérogénéité des clients Résumé : Dans le domaine des systèmes distribués, le partage de services est devenu un enjeu important. De nombreuses plates-formes offrent des outils qui permettent aux fournisseurs de services de publier leurs offres de service et aux clients d accéder à ces services. L utilisation de ces platesformes logicielles pour accéder aux services ne sont pas sans contraintes pour le client. Par exemple, un client qui souhaite accéder à un service, doit être déployé sur la même plate-forme que le fournisseur qui propose le service. Le service présenté dans cet article facilite l accès aux services et résoud le problème de l hétérogénéité du client. En effet, ce service prend en charge l accès aux services pour le compte du client et il propose de nombreuses interfaces d accès qui permettent à des clients hétérogènes d accéder aux services qu il gère. Le nom de ce service est : Service de Médiation. Mots-clés : Systèmes distribués, hétérogénéité, accès aux services Laboratoire d Informatique de l Université de Franche-Comté, UFR Sciences et Techniques, 16, route de Gray, Besançon Cedex (France) Téléphone : +33 (0) Télécopie : +33 (0)

6

7 Service de Médiation 7 1 Introduction Recent years have witnessed a tremendous growth in the use of light clients and network sharing services. It exists many software platforms which enable service advertising and access: CORBA, JINI, RMI... In these software platforms, service access is performed by a client in two steps. The client uses the platform research tool to obtain one or more references of the searched service provider. Next, the client calls one of these providers to obtain the service it wishes for. This scheme of service access means some constraints for the client. These constraints are due to the service call requirements: knowledge of the service interface, the possession of the service driver... These constraints can penalize clients, and specially light clients which have low storage and process capacities. To minimize these constraints and facilitate the service access, we propose a new service: the Mediation Service. The Mediation Service deals with the service access for the client, from the search of service providers, to the call of one of these service providers, including the choice of this provider. Moreover, in its service providers search and choice processing, the Mediation Service takes into account the execution environment of each service provider. The Mediation Service becomes an intermediary between service providers and clients. Besides the constraints due to the service call, the client has a further constraint due to its software platform. Actually, the client is able to access a service only if it is in the same platform as the service provider. By its intermediary position between clients and service providers, the Mediation Service is able to solve this problem. In this paper, we describe the different stages in the service access, in the section two. In the section three, we present the Mediation Service, the notions which are used by the Mediation Service, its interface and its architecture. 2 Service access In the distributed systems domain, client - search tool - service provider interactions are realized according to a triangular scheme: 1. The service provider advertises his service on the search tool. 2. The client uses the search tool to find providers of the wanted service. 3. The client uses call mechanism to access to the service. RR

8 8 Y. Bardin, S. Dahan, S. Damy, B.Herrmann Presently, many software platforms exist which allow service advertisement and access. Each of them proposes one or more search tools and call mechanisms. 2.1 Service advertisement Every service providers advertises its services on the search tool of the software platform. For example, the CORBA platform proposes Naming Service and Trading Services, JINI proposes Lookup Service, Java-RMI platform proposes JNDI Java Naming Directory Interface, etc. These search tools can be classified in two categories : name servers and traders. The name servers category gathers tools like the Naming Service [1] of CORBAor the JNDI [2] of Java-RMI. These tools allow client to establish relationship between a service provider name and its reference. The traders category gathers tools like Trading Service of CORBA [3], Lookup service of JINI [4] or Salutation Manager [5] of the Salutation Project. These tools allow service providers to describe their services using properties. 2.2 Service search To search service provider, a client uses a search tool which can be either a name server or a trader, it depends on the client s knowledge. If the client knows the name of the service provider then it will use a name server. If the client does not know the name of the service provider then it will use a trader. In this case, to search service providers, the client uses the name and the properties of the wanted service. The client searches service providers using the name of the service and its properties. 2.3 Service Invocation Finding a service provider is only the first step of the process. A way to send a request to the service is needed. It exists several protocols with various features to do it. Five of them which can be put together in two groups. The first group is made up of remote method invocation protocols of distributed object middleware. These protocols are developed to run on several platforms and to make the deployment of distributed application on heterogeneous hardware easer. The Java Remote Method Invocation (RMI ) is an example of them. RMI enables objects in one Java Virtual Machine to seamlessly invoke methods on objects in a remote Virtual Machine [6]. The Internet Inter-ORB Protocol specifications (IIOP) of CORBA is another LIFC

9 Service de Médiation 9 example of it. The IIOP[7] specification defines a set of data formatting rules which is tailored to the data types supported in the CORBA Interface Definition Language (IDL). It also defines a set of message types that support all of the Object Request Broker semantics on the Internet Protocol. These two technologies help the programmer to connect two distant objects as if they are local objects by concealed the communication task. The second group is made of remote message forwarding protocol for the Web Services. In the Web Services environment, it is crucial to send some messages that can bypass the firewall and that two softwares using different technologies are able to communicate. For this reason, some new technologies emerge. They are usually based on the Hypertext Transport Protocol (HTTP) and the Extensible Markup Language (XML). The use of the HTTP allows the messages to bypass the firewall by using the HTTP proxy already installed on the network. The XML is specified to create a standard interprocess format. SOAP[8], XML-RPC [9] and WSFL [10] are three examples of them. The drawback of them is that the use of HTTP and XML is not efficient and the performances are poor compared to IIOP or Java RMI. 2.4 Result To access to a service, a client has to find one or more references of providers which propose it. Next, if needed, client has to choose the provider which matches up to its requirements. Finally, it invokes the chosen provider to access to the service. This scheme of service access in three steps means some constraints for the clients. To access to a service, a client has to know the service interface. It must have or download the stub or the driver which allows the use of the service. And it has handle the service call and the errors. Some software platforms allow client to access to a service without having the service stub or driver. The software platforms Java-RMI and CORBA make dynamic call mechanisms available to the clients. But these call mechanisms are more complicated than static ones. The software platforms JINI and Salutation make drivers and stubs download service available to the client. When a client does not have the stub or the driver of the service, it can download it from the download service of these platforms. Like that, the client can access to the service it wishes for. Using search tools like Trader, a client obtains a providers list with their properties. If the client wishes obtain the same service once more, it will not have to call the Trader another time, it will be able to reuse the providers list he obtained previously. But the properties of providers of this list may RR

10 10 Y. Bardin, S. Dahan, S. Damy, B.Herrmann be changed, so providers may not be match up to the client s requirements any more. TORBA solves this problem of service evolution by implementing asynchronous trading [11]. To access to a service, the client must use the same software platform as the service provider. On the one hand, it has to be allowed to access to the search tool to find the providers of the service he wishes for. And on the other hand, it has to be allowed to call the service. Some software platforms solve this problem by making compatible their communication protocol. That is the case of Java-RMI which had become compatible with CORBA communication protocol, IIOP, with RMI -IIOP. We propose a new service which minimizes these constraints: the Mediation Service. The Mediation Service facilitates the service access to the client. To do that, the Mediation Service deals with the service access for the client. In other words, the Mediation Service deals with the search for providers of the service wished by the client, the choice of a provider and the provider call, for the client. The Mediation Service becomes an intermediary between clients and services. This position of intermediary allows the Mediation Service to solve a part of the problem of the heterogeneity between clients and service providers. Indeed, the Mediation Service proposes to the client different Mediation Service access interfaces which allow the client to access the Mediation Service from different software platforms. In addition, the Mediation Service intermediary position means other benefits. In the choice of the provider which is used to call the service wanted by the client, the Mediation Service takes service s execution environment into account. On one hand, that allows client to express its needs about the service and the service s execution environment. On the other hand, that allows Mediation Service to collaborate to the load balancing in the network. 3 The Mediation Service The Mediation Service, like an Application Service Provider, deals with a large part of the client s process, for the client. Put differently, the Mediation Service deals with the search for providers of the service wished by the client, the choice of a provider and the provider call. Before describing the Mediation Service, it is important to note that the Mediation Service is implemented with Java. It uses search tool of CORBA platform and dynamic invocation interface to service calls. So, for the moment, the Mediation Service allows clients to only access to the CORBA LIFC

11 Service de Médiation 11 service providers. The principal Mediation Service access interface is an RMI interface. In this section, we define the notions which are used in the Mediation Service processing and its architecture, to make available the services and to process the clients requests. 3.1 The task execution request The object which performs the Mediation function, is called Mediator. When a client wishes access to a service, it sends a request to the Mediator. This request is called : task execution request. To process task execution request, the Mediator manages the description of providers offers and makes the correspondence between these providers offers description and client s needs which are expressed in the task execution request. The client can express its needs not only on the service but also on the service execution environment. Now, we define the notions which allow in the one hand, the client to express its needs, and on the other hand, the Mediator to process task execution requests: the execution environment, the service offer, the task and the task execution request The execution environment: the Mediator takes into account not only the service properties but also the properties of the space where the offer is running. We call this space: the Execution Environment. To do that, the Mediator manages informations about service execution environments. In the Mediator, an execution environment is defined by: the address or the reference of the execution environment, the execution environment state, this property can have for value: "available" or "unavailable"; the state "unavailable" represents the execution environment state when the execution environment is willingly and temporarily switched off by its administrator, a set of static properties, like type of the processor, the memory ressources... a set of dynamic properties which provides the current state of the execution environment, like processor load. RR

12 12 Y. Bardin, S. Dahan, S. Damy, B.Herrmann The set of static and dynamic properties which allows the execution environment administrator to describe its execution environment, is not fixed. It is set up by administrator depending of the Mediator use context. The figure 1 gives an example of a information set which is needed to describe an execution environment. Reference String State {Available, Unavailable} Static Properties CPU Type String Operating System String Dynamic properties Load Double Figure 1: Definition of a execution environment description The service offer: to manage service providers offers, the Mediator uses the notions of service, service type and service offer which are defined in the CORBA s Trading Service specifications. To describe a service, the Mediator uses a service type. A service type is a set of informations which is composed of the service name, its interface and a set of properties. This interface is composed of the set of service methods. This interface describes the functional part of the service. The service type properties set describes the non-functional part of the service. All the Mediator service types must have a property IdSite which is the reference of the providers execution environment. The Mediator uses this property to link service offer and execution environment. For the Mediator, a service offer is the description of a service proposed by a provider. To illustrate these notions, we give an exemple of a service Compilation which offers C compilation functions. Its interface, named CompileC:1.0 is composed of : String[] compilec (File sourcefile) this function compiles the C file sourcefile and returns error and warning messages, File generatebinary (File sourcefile) this function generates the binary file from the C file sourcefile. LIFC

13 Service de Médiation 13 The service type CompilationC which represents the service Compilation, is defined in figure 2. Name of the Service Type CompilationC Interface reference CompileC:1.0 Type of property IDSite String CompilerName String CompilerVersion String Figure 2: Definition of the service type: CompilationC The task: The notion of service can be used only by service providers. A client cannot use the notion of service because a service corresponds to an interface. And when a client requests a service access to the Mediator, it must be more specific to allow the Mediator to choose the method of the service interface to invoque. So we introduce the notion of task. A task corresponds to a method of a service interface. When a service type is created, the tasks which correspond to the methods of the service interface, are created too. A task is defined by: the task name, the service type name and the name of a method of the service type interface. The tasks which are derived from a service type interface, inherits of the service type properties. From the CompilationC service type definition, the tasks compilec and generatebinary are defined (figure??). The properties of these tasks are the same as the CompilationC service type properties. Now, we have defined the notions which are used by the Mediator, then we can define the task execution request The task execution request: when a client wishes to access to a service, it sends a request to a Mediator. This request is called the task execution request. With this request, the client expresses its needs. In the task execution request, the client sends to the Mediator, the informations which are needed by the Mediator to process the request: a task name, RR

14 14 Y. Bardin, S. Dahan, S. Damy, B.Herrmann Mediator Processing part of the Mediator Execution Service Provider Environment Component Task Respository Offer Server Environment Server Environment Information Management Component Figure 3: Information Management in the Mediator a set of constraints about the task and the execution environment. A constraint is a property which service offers and execution environments must have to come up the client s expectations. Mediator uses client s constraints to obtain a subset of service offers, from the set of service offers which propose the task wanted by the client. a set of preferences about the task and the execution environment. A preference is a property which service offers and execution environments should have to come up the client s expectations. Mediator uses client s preferences to select from the subset the best service offer to use to execute the task. task parameters. These are the parameters of the method which correspond to the method parameters. 3.2 Making task available to the clients The informations which are required for Mediator working, are managed by the Information Management Component (figure 3). With this aim of view, the Information Management Component has three information components at one s disposal: the Task Repository, the Offer Server and the Environment Server The Task Repository: it manages the informations about the tasks (figure 3). It allows a Mediator to make the correspondence between a task and a service type. It also allows clients, via a graphic interface, to get informations about the available tasks. With this aim in view, the Task Repository manages two data types. One, stored in a table, makes the correspondence between a task, and, a LIFC

15 Service de Médiation 15 service type name and the corresponding method name. The other, stored in XML files, allows client to discover tasks and their utilities. The XML file of each task contains: the description of the action performed by the task, the properties associated to the task which allow a client to refine its task execution request and the number and the type of parameters The Offer Server: it manages the informations about the service offers (figure 3). It allows Mediator to obtain service offers which correspond to the task wanted by the client. It is a CORBATrader The Environment Server: it manages the informations about the execution environments registered at the Mediator (figure 3). During the task executing request processing, the Environment Server gives to the Mediator, informations about execution environments of service offers which are affected by the request processing. To perform its processing, the Environment Server uses Environment Components. The Environment Component (figure 3) is deployed in the execution environment just before the environment registration. The Environment Component has two functions. It helps environment execution administrator to manage its environment execution offer (registration, modifying...). And during the task executing request processing, the Environment Component works out the value of Execution Environment current ressources, and it sends them to the Environment Server. 3.3 The Mediation Service Interface As show before, the mediation service must offer its services to a wide set of clients. But each device uses different communication technologies and no technology can be chosen without to be incompatible with a subset of clients. This is why the mediation service is designed to communicate with the client without particular communication protocol. Instead, it uses a framework which makes abstraction of the communication protocol. This framework uses the proxy programmation model to hide the communication process. It allows the access to a distant object as if it is a local object. In this model, the local process has a proxy which is a local image of a distant object. The role of the proxy is to display the same interface as the distant object and RR

16 16 Y. Bardin, S. Dahan, S. Damy, B.Herrmann Client Mediator Mediation Component 4 5 MediatorServiceProxy Task Execution Request Receiver 2 Translator Translator Figure 4: Communication architecture between the client and the Mediator forward to it all the method call it received. By this way, all the local objects can access the distant one as it is local via the proxy. An abstract MediatorServiceProxy class has been defined to allow the access to the mediation service by the client. This abstract class does not implement the communication task between the client and the mediation service. Each time a new communication protocol must be integrated into the mediation service, a new class is created. This new class is a child of the MediatorServiceProxy and implements the communication task. In the other side, a task execution request receiver is implemented for each MediatorServiceProxy child created (one by communication protocol). The purpose of each task execution request receiver is to call the same function of the mediation service with the task execution request as argument. So the mediation service will receive the same function call regardless of the communication protocol used to send the request. As show in figure 4, the task execution request is send to the Mediator by following eight steps. To be able to send the request to the Mediator through a defined communication protocol, the task execution request must be written in a way that it can be send with this protocol. This is the first encoding phase 1. Then, the encoded task execution request is send to the task execution request receiver 2. When the task execution request receiver gets a message, it decodes the message 3 to rebuild the original task execution request and sends it to the Mediation Component 4. When the Mediation Component has finished to process the task execution request, it returns the response to the task request receiver 5 which sends the response to the MediatorServiceProxy by following the same steps (encoding 6, transmission 7 and decoding 8 ). At the end, the MediatorServiceProxy returns the response to the client. This abstraction level is useful for the integration of new technologies, but all abstraction have a cost. To measure it, two MediatorServiceProxys have been developed. The first uses the IIOP of CORBA and the second uses XML-RPC as communication protocol. Several task execution requests have been chosen in a way that several kinds and sizes of task execution execution requests could be tested. The task execution requests are send through four LIFC

17 Service de Médiation 17 Mediator 1 8 Execution Mediation 9 Making Component Component Execution Service Provider 2 7 Environment Component 3 Collecting Component 4 5 Decision Making Component 6 Environment Task Repository Offer Server Environnement Server Information Management Component Figure 5: Mediator working configurations: the IIOP MediatorServiceProxy, the XML-RPC one, one which sends the task directly on IIOPwithout using a proxy and the same thing with XML-RPC. Each test is defined by sending task execution request several times between two IBM PC compatible with a Pentium III at 1 GHz and 256 MB of RAM running a Linux 2.4. All the tests show that the architectures using a proxy are always slower that the ones which do not use it. But the overhead of the proxy for sending was never greater than 5 % with an average of 2.7 % of the communication time. 3.4 Task Execution Request Processing Four components perform the task execution request processing. The Mediation Component receives the task execution request and organizes its processing using the three other components. The Collecting Component collects informations required to perform the task execution request processing, using the three information components previously described. The Executing Component calls the service provider to obtain the result of the task wanted by the client. The Decision Making Component performs the order of the service offers. Now we detail the role of each of these components. We do that describing their action during the task execution request processing (the numbers which are in a circle references the numbers in figure 5). RR

18 18 Y. Bardin, S. Dahan, S. Damy, B.Herrmann The Mediation Component: this component receives task execution request from a client or a proxy and sends the task execution result to it 1. In the Mediator point of view, the Mediator Component has a central role. It manages the three other components processing and it sends the needed informations to the corresponding component These informations come from task execution request and other components processing The Collecting Component: this component gathers informations which are required for client task execution request processing. In other words, it must find informations about the service offers 3 4 and their execution environment 5 which are able to come up to the client s expectations. These expectations are given by the client in the constraints. With this aim in view, the Collecting Component uses the three informations components. First, the Collecting Component gets the service type and the method name which are corresponding to the task name from the Task Repository 3. After that, the Collecting Component uses the service type to get the service offers which come up the client s expectations from the Offer Server 4. Next, the Collecting Component makes a list of the environment execution references extracted from informations of each service offer. The Collecting Component sends this references list to the Environment Server 5. Then, the Environment Server checks the execution environment properties match client s constraints and are available. After, it gots their dynamic properties from their Environment Component 6. Then, to reply to the Collecting Component, the Environment Server sends to it, the informations that it gathered about available Execution Environment. Finally, the Collecting Component merges informations about each service offer with informations about its execution environment. The reply sended to Mediation Component 2 is composed of the method name and the list of the service offers which come up to the client s expectations. In other words, these service offers are those one that their properties and the properties of their execution environment match the client s constraints and are available The Decision Making Component: this component receives from Mediation Component the list of the service offers 7 which was obtained previously and the client s preferences. Its role LIFC

19 Service de Médiation 19 is to match the service offers properties with the client s preferences, to order the service offers. This order takes into account the ressources states of each service offer execution environment. In other words, the first offer of this ordered list is the one which comes to the best compromise between client s expectations and load balancing The Executing Component: this component performs the execution of the task. With this aim in view, it uses the method name, the service offers ordered list and parameters which are sent to it by the Mediation Component 8. Then, the Execution Making Component invokes the service method 9 using the first service offer of the ordered list. If the service call leads to a result, then this result will be sent to the client by the Mediation Component 8 1. Else the Executing Component will try again the invocation with the next service offer of the the ordered list until it leads to a result. 4 Conclusion In the distributed system domain, software platforms allow services advertisment and access. The software platform uses to access services means some constraints for the client due to service invocation. In this paper, we presented the different stages of clients service access using the main software platforms and we show several constraints about the service access using these platforms. After, we presented the Mediation Service and how it minimises these constraints. This service simplifies the service access for a client because on the one hand, the Mediation Service deals with the service access for the client, and on the other hand, with one stub : the Mediation Service stub, a client can access to all services which are managed by the Mediation Service. When offering clients, various interfaces implemented with various software platforms, Mediation Service allows clients to access to services, even if they are not in the same software platform as the service providers. But as we seen in this paper, the Mediation Service only allows client to access to services which are offered by CORBA providers. One of our future work consists in making available access to services which are offered by providers, whatever software platform providers use. RR

20 20 Y. Bardin, S. Dahan, S. Damy, B.Herrmann References [1] Spécifications : Naming Object Service v1.2. Object Management Group. Mai [2] Advanced Java, Development for Enterprise Applications. Suns Microsystems. Sun Microsystems Press, 2nd edition [3] Trading Object Service v1.0. Object Management Group. juin [4] Jini architecture specifications. Sun Microsoft Press [5] Salutation Architecture Specifications v2.0c. Salutation Consortium. juin 1999 [6] Java Remote Method Invocation. Suns Microsystems http : //java.sun.com/marketing/collateral/javarmi.html [7] David Curtis, Christopher Stone and Mike Bradley. IIOP : OMG s Internet Inter-ORB Protocol, a brief description. http : // [8] Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau and Henrick Frystyk Nielsen. SOAP version 1.2 Part 1 : Messaging Framework. May http : // R/2003/P R soap12 part [9] UserLand XML-RPC.com. http : // [10] Web Services Flow Language (WSFL 1.0). IBM Software Group. http : //www 3.ibm.com/sof tware/solutions/webservices/pdf/w SF L.pdf [11] Sylvain Leblanc, Philippe Merle et Jean-Marc Geib. TORBA : Vers des composants de courtage. Actes 6 ieme Conférence Internationale sur les Langages et Modèles à Objets, LMO Montpellier, France, janvier Editions Hermès, Paris, pp LIFC

21 Laboratoire d Informatique de l université de Franche-Comté UFR Sciences et Techniques, 16, route de Gray Besançon Cedex (France) LIFC - Antenne de Belfort : IUT Belfort-Montbéliard, rue Engel Gros, BP Belfort Cedex (France) LIFC - Antenne de Montbéliard : Centre de développement du multimédia, cours Leprince-Ringuet Montbéliard Cedex (France)