Enhancing Service-Oriented Computing with Software Mobility Hervé Paulino and Gilberto Camacho CITI / Departamento de Informática Faculdade de Ciências e Tecnologia, Universidade Nova de Lisboa 2829-516 Caparica, Portugal Email:
[email protected]
Abstract. Service-oriented computing has emerged as a consensually accepted paradigm for the implementation and integration of distributed systems in heterogeneous environments. However, its basic request/response interaction model is not always adequate for communicating in both highly dynamic, and low bandwidth, networks. To overcome this limitation, we propose the seamless incorporation of software mobility with service-oriented computing to provide a powerful framework for service-oriented architectures to benefit from the advantages of the mobility paradigm. We instantiate the model as a middleware for the mobility of Java computations in Web service environments, and present some programming examples that illustrate the expressiveness of the proposed API. This middleware is currently being successfully used in the development of other service-oriented architectures, namely in the field of dynamic Web service architectures.
1
Introduction
Service-oriented computing (SOC) has emerged as a consensually accepted paradigm to abstract both software components and network resources. The composition of loosely-bound service-oriented components has been proved to be a good paradigm for the modelling of distributed applications, specially in heterogeneous environments, such as the ones targeted by mobile [8,21], pervasive [12], and grid computing [9,10]. However, the remote request/reply interaction model used in service-oriented architectures is not always adequate for networks with low bandwidth and high error rates. Mobile agent systems, such as [2,13,19] can be used to migrate computations within service-oriented architectures (SOA), enabling local interaction and thus eliminating the need to maintain costly remote sessions. These systems, however, rely in the explicit notion of network node abstraction to express mobility, which burdens the SOA programmer with the management of both service and host identifiers. Moreover, common mobile agent development APIs require programs to specify the location of the resources, be it at development- or run-time, which is too restrictive for the requirements of dynamic environments where the execution context, namely the composition of the network is often not known in
advance [17]. To overcome these limitations, the programmer is usually forced to deploy registries/directories of the available resources. To tackle this problem we propose the seamless combination of the SOC and software mobility paradigms, providing a framework to easily incorporate mobility in service-oriented distributed applications. The seamless adjective emphasizes the fact that the use of mobility is orthogonal to the remainder steps of SOC’s find-bind-execute paradigm, and that mobility is expressed in terms of service identifiers rather than host identifiers. This delegates the discovery of the location of the destination node(s) to the service discovery mechanism, removing it from the programmer’s responsibilities. The advantages of software mobility have been overshadowed by the security concerns it brings [3, 24] and the lack of robust infrastructural support [24]. Nonetheless, it is our opinion that the paradigm can be very useful in many of the environments where SOC plays an important role, namely in middlewares, where the code to migrate can be either known or controlled. To this extent, this paper presents a middleware that instantiates the serviceoriented mobility concept, initially formalized in [18], in Web environments. We rely solely on Web technologies to provide a interoperable framework that permits service-oriented platforms to benefit from the advantages intrinsic to the software mobility paradigm, such as reduced use of network bandwidth, disconnected execution, and low latency interaction [14]. In order to better illustrate the usefulness of the concept consider the following example: – A service-oriented middleware that provides the means to extract information from data-streams (for instance a sensor network virtualised as a Web service), and emit notifications based on the computed results. Mobility can be used to move the computation towards (or closer) to the data source to, with that, reduce the amount of network traffic. Furthermore, assuming that the interface of the middleware supplies only the means to compose operations over streams, the code to migrate does not raise any security concerns, since is a sequence of such operations, and thus completely under the middleware’s control. The remainder of this paper is structured as follows: the next section describes the service-oriented approach to software mobility; Section 3 presents the developed middleware; Section 4 showcases some programming examples and how the platform has been evaluated. Section 5 compares our approach to existing work in the field and, finally; Section 6 presents our conclusions.
2
Service-Oriented Mobility
Service-oriented mobility enhances SOC by combining it with software mobility, making process locality transparent to the programmer by modelling mobility in terms of services: migrate to a provider of service s1 and execute process P1 rather than the usual migrate to node h1 and execute process P1 . The discovery of the location of the destination node(s) is relegated to a service discovery mechanism managed by a middleware layer (Figure 1).
Service registry
s1?
Service registry
s2?
h1
migrate to s1 S
migrate to s2 S
Service registry
s3?
h2
migrate to s3 S
s1
h
h1
h3 s2
s3
S
h2
h3
Fig. 1: Service-oriented software mobility (2) Find a service instance given a contract
Client application Session (7) Return the result
(3) Upload session Middleware
Service registry
(4) Migrate the session towards the service provider Session
(1) Register service contract
Service Provider (5) Execute the session Middleware
Session
(6) Return the result
Fig. 2: Service-oriented session uploading.
Our intention is not to replace the usual interaction models used in SOC, but rather to enrich the existing offer and, to that extent, provide a new alternative that can be used when appropriate. We have incorporated mobility in such a way that it is completely orthogonal to the remainder steps of the find-bindexecute paradigm used in SOC. Figure 2 illustrates how we have incorporated it as a new optional step between the binding and execution stages, enabling the find-bind-migrate-execute variant. The will of the provider to receive incoming sessions can be verified at runtime, allowing for the selection of the mobility paradigm on-the-fly. Moreover, this will can be taken into consideration when negotiating service-level agreements (SLA). 2.1
Session Migration
Central to our model is the notion of session, which delimits the code to be migrated to the target host and interact with the target service provider. The process of migrating such sessions requires a software layer placed between the client application and the service provider. As illustrated in Figure 2, this software layer must be present at both endpoints of the interaction. On the client side it is responsible for: a) building the session’s closure; b) marshalling it; c) constructing the request message; d) establishing the connection to the target host, and; e) sending the message that comprises the session. On the service provider side, its responsibilities include: a) receiving the session message; b) unmarshaling its contents; c) loading the session and its code dependencies (if any); d) launching the session’s execution; e) collecting
the result (if any); f) marshalling it, and g) sending it back to the client or propagating it to a new host (more on this on Subsection 2.3). The loading of code dependencies is necessary when not all the code required by the session is available at the provider side. Asynchronous Upload: the synchronous request-reply communication mechanism maps straightforwardly into the uploading of sessions - the request uploads the session to the server, and the reply returns the result to the client application. However, although there is no communication while the session is being executed, the request-reply communication is connection-oriented and consequently requires active network sessions on both sides until the reply is received and acknowledged. This is sustainable, and even adequate, for short running sessions, but when it comes to long running sessions an asynchronous mechanism based on callbacks is welcomed. The objective is to limit the network session to the migration of the code and to the emission of the result (if any). The drawback is the need for the client to become a server. In a Web service context this means having a Web server listening for incoming result messages, which may not be desirable when accessing the service from a mobile device with energy consumption restrictions. Nested Sessions: service usage is not always disjoint, a session may interact with services other than the one to which it was uploaded to. The use of mobility in this context requires the migration of a session within a session, borrowing the concept of nesting long used in transactions. 2.2
Parallel Upload
The parallel upload consists on migrating one session to a set of hosts simultaneously, following a fork/join pattern. The client acts as the master that spawns as many sessions as available providers and waits for the lists of computed results, one per provider (if the session returns a result). This feature can be useful if there are no data or causal dependencies between multiple executions of a session, allowing it to be uploaded simultaneously to all the target providers, thus enabling parallelism. Application examples include: performing management tasks, such as the installation of a piece of software in a set of hosts; collecting information, such as the patient record collection system of [16], and, performing computation over distinct sets of data, such as a runtime system for a map/reduce framework [5]. 2.3
Workflows
Workflows of Web services, such a BPEL [15], play a important role in the construction of business processes in SOC. In this section we will describe the foundations on how to support workflows of sessions that may migrate to one or more service providers. We want the model to remain session-centric, in other words, for a workflow to be built through session composition. Furthermore, for the sake of code reusability, we want the participation of a session in a workflow to be orthogonal
to its implementation. We do not want to impose any special requirements on a session in order for it to be suitable for workflow integration. Given this, our requirements for building workflows through session composition are: 1. to allow a session to visit one or more instances of a service sequentially; 2. to allow a session to visit more than one instance of a service in parallel, i.e. to incorporate the parallel uploading of sessions in the construction of workflows; 3. to chain instances of items 1 and 2, and; 4. to pass the result computed by a session to another, procedure that we will refer to as bridging. Figure 3 illustrates an example where sessions (a, b and c) travel to three services (S1, S2, and S3, respectively), being that, in the specific case of session b it travels to all the providers of service S2 in parallel. (2) Upload session to a provider of S1
Client application Workflow (6) Return the result
(1) execute workflow Middleware
(5) Migrate back to the source host
S1
(3) Upload session to all providers of S2 S2
S3
S2
(4) Upload session to a provider of S3
Fig. 3: An example of a workflow of sessions
From the mobility perspective, to have a session travelling a set of service providers relates closely to the concept of itinerary [13] widely used in mobile agent systems. A paradigm that does not fit in request-reply communication mechanisms discussed so far. Mobile agent applications typically travel along a set of network nodes, only having contact with their source host in two occasions: before being dispatched to the network and once the work is done. In fact, two of the premises of the mobile agent paradigm are: a) to eliminate network sessions, enabling disconnected execution (the source does not have to be connected to the network in order for the agent to execute), and, b) autonomy - the agent must be able to make choices without the user’s intervention. Our goal, however, is not to implement a new mobile agent system, but rather to enable session composition to provide the means for sessions to interact with a set of providers sequentially or in parallel. For that purpose we need to attend two essential aspects: How to pass the result from a session to another in the workflow? A session in a workflow may return a result that must be handed out to another session placed in a later stage. To define this relationship between sessions we introduce the bridge concept: two sessions are said to be bridged if the result of the execution of one is passed to the other. Listing 2 of Subsection 3.2 illustrates the construction of a workflow. How to store results that do not have to be passed along? For instance, when travelling a set of hosts gathering information - as the session travels, the data it collects must be stored for later retrieval by the client application. For this purpose we define the data-repository concept: a repository of all the results computed by sessions.
3
The Middleware Layer
This section describes a middleware for the mobility of Java code in Web service environments. Due to space restrictions we can only sketch the architecture, implementation and interface. A more detailed description can be found in [4]. 3.1
Architecture and Implementation
The middleware is implemented as a software layer distributed among all the machines willing to upload and/or receive sessions and workflows. From the middleware’s point of view, the itinerary is the basic mobility unit. Workflows are directly mapped into itineraries and the upload of a single session is implemented as an itinerary containing that one session. An itinerary is thus composed by one or more sessions and is globally identifiable within the system. A session, in turn, has an itinerary-wide unique identifier, and comprises its closure (data and code) and its migration pattern: sequential or parallel. Sessions standing at the source end of a bridging operation also store the identifier of their counterpart. As is usual in Java, we are in presence of a weak mobility model, only the session’s code and data state are migrated, not its execution state. The middleware is responsible for managing the life of these itineraries, from the moment they are submitted, until they have completed their trip, and their results have been handed out to the invoking threads. Its general architecture is depicted in Figure 4. Middleware
Client Application
Submit session(s)/ workflow
Itinerary Creator
Closure Builder
Result Manager
Marshaller
Communicator
Return result Session Executor
Web
Result Manager
Bridge Manager
Session Loader
Marshaller
Communicator
Fig. 4: General overview of the architecture Itinerary Upload: The middleware supports both the synchronous and asynchronous upload of itineraries. The process mostly transposes the steps enumerated in Section 2.1 to the context of the mobility of Java code in Web service environments. To these we add the need to associate the itinerary to the submitted asynchronous invocation. This is required to map received results to the rightful threads in asynchronous uploads. Of the several modules that compose the client side of the middleware, the Itinerary Creator constructs the itinerary to store the submitted session or workflow; the Closure Builder collects the itinerary’s closure, and; the Result Manager associates it to the submitted asynchronous invocation. The latter is also responsible for handing received results to the client application. We are targeting Web service environments, hence communication within the middleware adheres to the Web service standards. This requires the existence
of a Web service to handle the reception of both itineraries and results computed by itineraries uploaded asynchronously. The conversion of the itinerary into an array of bytes, suitable for Web service communication, and the construction and emission/reception of the actual SOAP message are performed, respectively, by the Marshaller and Communicator modules, present on both ends of the communication. Session Loading and Execution: on the server side, the reception of a new request causes the itinerary to be unmarshalled, and the next session in line to be selected for execution. The Session Loader loads all the code required by the session into a dedicated Java class loader. Each session has, thus, its own sandbox, which can be garbage collected as the session completes its execution. The Bridge Manager verifies if a bridge with a previous session was established. If such is the case, the previously stored result is retrieved from the datarepository and made available to the current session through the invocation of method void handleBridge(R result) from interface Bridge. This interface must be implemented by every session standing on the receiving end of a bridge. The Session Executor executes the session by placing it in a queue that is consumed by a pool of threads. The pool’s policy is parametrizable, allowing for configurable bounded and unbounded behaviours. Once the execution of the session terminates, the computed result is stored in the data-repository to be retrieved by the client application or for future bridging. Note that each result is labelled with information regarding to which session it relates to, and in which host it was computed on. By default, the data-repository is piggybacked on the itinerary but the middleware provides the means for the programmer to opt for a remote repository, in the form of a Web service. This Web service is available in the middleware’s distribution, but its up to the user to deploy it. 3.2
The API
The interface provided by the middleware to client applications assumes the form of a Java API that instantiates the concepts described in Section 2, namely the upload of sessions and workflows. Session Creation and Uploading: Class Session factorizes the functionalities required to migrate a session: S denotes the type of the service provider and R the type of the session’s result. Listing 1 showcases a trimmed version of the classes’ interface. The code to migrate is defined by providing a concrete implementation of abstract method R run(). The uploading (method upload()) receives as argument an object compliant with interface ServiceProvider, which abstracts the location to where a session can be migrated to. The invocation of upload() may throw an exception when the host running the target service provider does not support service-oriented mobility, in other words, is not running the middleware. To enable remote interaction, the API features method execute(), which runs the session asynchronously in the client machine. The management of whether the session is to be uploaded or locally executed can
be delegated to the middleware - method uploadWP() instructs the middleware to upload the session whenever possible, and execute it locally otherwise. a b s t r a c t c l a s s S e s s i o n { a b s t r a c t R run ( ) ; F u t u r e uploadWP ( S e r v i c e P r o v i d e r s p ) { . . . } F u t u r e u p l o a d ( S e r v i c e P r o v i d e r s p ) throws UploadNotSupportedException { . . . } F u t u r e e x e c u t e ( S e r v i c e P r o v i d e r s p ) { . . . } F u t u r e u p l o a d A l l W P ( L i s t s p L i s t ) { . . . } R e s u l t synchUploadWP ( S e r v i c e P r o v i d e r s p ) { . . . } ... S getServiceProvider () { . . . } }
Listing 1: The interface of class Session The parallel upload/execution of sessions is performed through methods uploadAll(), executeAll(), and uploadAllWP(). All these receive a list of providers and return a list of results of type R. Moreover, there are synchronous variants of each of the previously presented methods, eg synchUploadWP(). Finally, method getServiceProvider() returns the provider to which the session is bound (was uploaded) to. The ServiceProvider interface allows for distinct methods for locating the target host. Currently two are provided: one that locates a service through its URL (much like in the usual mobility systems, where the location of the resource must be provided to the API) and, a second that retrieves from a directory a set (or all) services that respect a given description. Class Result represents a result computed by a session. It features methods to retrieve the actual result (getResult()) and the information regarding where it was computed on (getInfo()). In [6], the authors distinguish between different kinds of resources: free transferable, fixed transferable, and non transferable; and different kinds of bindings to resources: by identifier, by value, or by type. In our work, the state of a session must be composed of serializable objects, otherwise an exception is raised. The default implementation provided by Java handles the copying of the resource, for now the construction of network references (to, for instance, non-transferable resources, such as a printer) must be handled by the programmer. c l a s s Workflow { v o i d add ( S e s s i o n s , S e r v i c e P r o v i d e r s p ) { . . . } v o i d a d d A l l ( S e s s i o n s , S e r v i c e P r o v i d e r s p ) { . . . } v o i d a d d A l l ( S e s s i o n s , L i s t s p L i s t ) { . . . } v o i d b r i d g e ( S e s s i o n s o u r c e , B r i d g e d e s t i n a t i o n } ) { . . . } F u t u r e
