SOA Engine – Services Compositions Execution in Ubiquitous Environments Luciano Zanuz
Alexsandro Filippetto
Giovane Barcelos
Sergio Crespo C S Pinto
PIPCA / Unisinos Av. Unisinos, 950 – São Leopoldo – RS – Brazil +55 51 3590 8161
PIPCA / Unisinos Av. Unisinos, 950 – São Leopoldo – RS – Brazil +55 51 3590 8161
PIPCA / Unisinos Av. Unisinos, 950 – São Leopoldo – RS – Brazil +55 51 3590 8161
PIPCA / Unisinos Av. Unisinos, 950 – São Leopoldo – RS – Brazil +55 51 3590 8161
lucianozanuz @gmail.com
alexsandrofilippetto @gmail.com
giovanebarcelos @gmail.com
[email protected]
ABSTRACT Because of its features of loose coupling and platform independency, SOA is becoming the preferred and more suitable architectural style for ubiquitous or pervasive computing. On the other hand, with the crescent improvement in hardware and software infrastructure, the ubiquitous computing is gaining prominence and must become an effective reality in a few years from now. This paper presents the U-SOA (Ubiquitous ServiceOriented Architecture), more precisely one of its central components, the engine for services compositions execution in ubiquitous environments.
Categories and Subject Descriptors D.2.11 [Software Engineering]: Software Architectures – domain-specific architectures.
General Terms Design, Experimentation, Languages
Keywords framework; web service; service-oriented architecture; ubiquitous computing; pervasive computing; collaborative environments; Android
1. INTRODUCTION Due to the loose coupling and platform independency offered by services-oriented architectures (SOA), which allows the seamless integration of systems built on different platforms, they are being strongly indicated to be the basis of collaborative systems [6]. In the same way, SOA fits very well to mobile systems, including ubiquitous or pervasive computing [8], which is considered the next computer paradigm [11]. SOA summarizes totally the lower layers of an application, which makes it the ideal candidate among the brand new systems that are being developed and need interaction with other ones. SOA is based on three components: service provider, service consumer and services repository. All the traffic among these components uses XML industry standards, like SOAP. The services, which in the actual approach are implemented usually as web services, are described with WSDL. SOA proposes those services composition into new composite applications, which conceptually are also web services and therefore are described
with WSDL. This composition is done with services composition languages, where the one that is becoming the standard is BPEL [10]. Actually, WSDL describes operations and parameters for web service communication. In other words, the web service is a black-box application which interface is presented by WSDL. As the services composite application is a new web service, also described through WSDL, it is not possible the services identification that are part of it. Of course, the composite application is deployed in an application server that knows, through the BPEL, which and where those services are. However, this information is not visible externally from the server. Thus, it is hard to determine the great variety of services compositions information like, for instance, the impact analysis that the exclusion of a service would cause to the set of an enterprise composite applications. To solve this limitation, it is being proposed a new SOA based architecture, defined by a framework suggested by the group, which has as one of its core components the services compositions execution engine. Some improvements in the currently SOA structure that will be available from the proposed architecture are illustrated in figure 1. The first of them is the possibility of each node of the traditional triangle relationship (provider-repository-consumer) be any device, including small mobile devices. The second is the utilization of a kind of web services composition description language (WSCDL) for compositions publishing. This new describing way must have needful additional information to identify the compositions participant services, allowing the mapping of these services and, consequently, several new capabilities, among them the impact analysis quoted in the preceding paragraph. The WSCDL must be defined based on an ontology that represents the framework that is being proposed. This language, which must support the description of services composition as well as of atomic services, will possibly be OWLS [7], but also it can be created as a WSDL extension. This paper shows an engine running ubiquitous SOA compositions, which is one of the entire framework components. This engine will also allow any mobile device to act with a service provider role, which currently is limited to high-power processing hardware platforms. Beyond this new role, these devices will maintain the newly acquired role of web services and web services composition clients. This new feature of providing services from small mobile devices is essential for collaborative ubiquitous
25 © 2008 Brazilian Computer Society
systems to become reality. [3] says that the development of engines middlewares is an important step toward the long-term goal of bringing groupware to mobile devices.
Above the VM we find the servers or the web services and SOA execution engines. To represent the behavior of these engines, a formal and explicit specification is located in the layer above. In top layer there are all the ubiquitous collaborative applications supported by the framework, implemented as several services, among them the impact analysis services and the new interface framework based on SQLSOA language.
2.1 Architectural Aspects Incoming a little bit inside the architecture, it is possible to identify some specific components, which are illustrated in figure 3 and express the overview of the framework. The framework communicates with the external environment through users interfaces. In those interfaces, the users interact with the system, publishing and consuming a specific web service or a web services composition. The framework must support specific languages for these operations. As quoted, it is necessary some kind of WSCDL, which can be OWL-S.
Figure 1. Ubiquitous service-oriented architecture. Besides the fact that every device or peer involved in a relationship of cooperation based on SOA must have both the role of web service client and provider, to use all the resources that an SOA environment provides, these peers should also be able to compose web services in new applications. Due to the complexity of this kind of system, it is necessary the use of an ontology. It should be formal and explicit specification to represent the involved knowledge. The rest of the paper is divided as follows: section 2 explains in details the engine architecture, how it will be implemented and some experiments already done; in section 3, a related work is presented; and conclusions are argued in section 4.
2. SOA EXECUTION ENGINE In an overview, the entire framework can be seen as technologies stack separated in layers. The layers involved in the architecture contemplate since bottom levels to ubiquitous collaborative applications supported and are illustrated in figure 2.
Figure 3. Architecture overview. From the interface, what we have inside the system are ubiquitous collaborative services, simple or composite. These services must be based on ontology and will be stored in a service repository that must also support the storage of services compositions. The control of these services goes to engines that run them in individual or composite way. In the case of composite application, the composition execution engine accesses the respective repositories and the services execution engines that compose the composition, besides being based on its ontology. The services execution goes down to the architecture lower layers, more specifically to virtual machines, which use the operational system to effectively provide the execution of these services.
2.2 Engine Core Figure 2. Technologies stack separated in layers. The architecture bottom is the operational system, for which we have chosen the Android [1]. The layer above the operational system is a virtual machine (VM), to abstract hardware demands.
The web services compositions execution engine for small mobile devices is the central core of the several architecture proposed and, with the web services execution engine, is responsible for the execution of the functionalities desired for the ubiquitous
26
application, implemented on SOA as web services. The core architecture of this engine, which also can be called SOA engine, is illustrated in figure 4 and explained in larger details as follows.
2.3 Implementation The implementation of the SOA engine needs several software components construction, where some of these components, however, can be obtained from actual solutions or even from these solutions customizations. Therefore, we can consider the SOA engine as a collection of technologies to mobile devices, organized and architected with the goal of running web services composition in them. The first step to build the SOA engine is the platform definition. According to what was previously exposed, the platform was chosen among Java ME, .NET Compact Framework and Android, and we opted for the last one, because we believe that this platform, although recent, may become a standard to mobile computing. As we want to use ontology to represent the framework, the next step is the definition of this ontology. As OWL-S is the main candidate to be chosen as the service composition language, OWL-S would also be used as the framework ontology.
Figure 4. Composition execution engine core architecture. Component of a major architecture, already explained, the SOA engine communicates with other components by requests. The responsible for receiving these requests is called input and output socket, which listens to determined port until receiving some request. The socket is the point of contact of SOA engine with other architecture components. The socket receives as input parameter the services composition description that must be executed and returns the composition response. These input and output parameters are formatted following some XML standard, for instance. Other possibilities are BPEL or SQLSOA, besides that, the XML standard must be ontology based. The socket sends the composition description to the central controller, which is responsible for its conversion into a cleaner format, excluding the several headers of message used for transporting that happens on SOAP. Therefore, the central controller uses the incoming handler component. The same way, the central controller is responsible for the correct mounting of the composition response, that uses the outcoming handler component. The central controller also uses the XML handler for mounting and unmounting the input and output parameters of the SOA engine. The composition manager receives the composition in a clean format, ready for execution. It also uses the XML handler as an assistant component, since it is XML that is traveling in every moment, even internally to the SOA engine's core. The manager composition also utilizes the syntax checker component, which validates the composition description received as SOA engine parameter according to the defined ontology. The composition manager is responsible for the correct execution of each process step. It must be capable of understanding and executing all composition commands, including web services calls, flow control, iterations, etc. The composition manager is the most important component in the SOA engine's core. To web services executions, the composition manager uses the web services executor component, whose task is to make a call to determined web service and return its response to the component manager. The web services executor can access the services repository to locate determined web service.
The incoming and the outcoming handlers will be built by the kSOAP [4] library customization. In the same way, the XML handler will be built from the kXML [5] library customization. However, the main components of the SOA engine will be effectively implemented: input/output socket, central controller, composition manager, and web service executor. The peculiarities of its implementations, however, could be only described after the definition of the platform and ontology to be used in the framework.
2.4 Experimentation Although at this moment we still hadn’t obtained substantial results, as proof of concept we developed some experiments using the Android platform. As a first application, we built a web services provider that we called SOAPServer, which can provide web services in the Android emulator. These web services, in their turn, may be consumed by others Android emulators, desktops or even cell phones.
Figure 5. Experiment 1 – consuming 1-way web service. We deployed two web services in the SOAPServer. The first, illustrated in Figure 5 by a UML sequence diagram, returns the contacts from the server. The second, illustrated in Figure 6 also by a UML sequence diagram, receives the author’s name as parameter from the client and consumes an Amazon web service using the same parameter. The Amazon web service returns to SOAPServer the books information of the author from Amazon Book Store. Hence, the second web service deployed in the SOAPServer returns these information to the client.
27
and allowing compositions creation with them. Sliver allows the communication between services using HTTP or Bluetooth. Sliver is a BPEL workflow process execution engine that supports a large devices variety, from mobile phones to desktops. Its architecture uses hand-made parsers developed using the lightweight kXML and kSOAP packages.
4. CONCLUSION Figure 6. Experiment 2 – consuming 2-way web service. As the proof of concept provided by the above experiment had positive result, we built another Android application towards the final version of SOA engine. This application receives a XML composition description, parses the XML and executes the composition by invoking each web service and by handling their results. Although this application works fine, it confirmed us some issues we have to resolve:
We believe that ubiquitous computing supported by serviceoriented architectures may become actual, not only in the academic world, in a few years. Frameworks to support this kind of applications should continue to be built. In this paper we have presented an engine for services composition execution in ubiquitous environment, also called SOA engine. This middleware is a component of a larger work – a ubiquitous framework – that is being developed by our research team.
5. ACKNOWLEDGMENTS This work is supported by Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES), Brazil.
•
It is hard to work with complex types of web services responses in execution-time without services stubs;
•
Choose between XPath or kSOAP objects;
6. REFERENCES
•
Manage timeouts and keep alive session.
[1] Android. “Android – An Open Handset Alliance Project”. http://code.google.com/android/ (2008).
•
Performance.
These experiments prove the capability of the SOA engine of providing not only a simple web service as well as web services composition on mobile devices, more specifically on Android platform.
3. RELATED WORK A web services architecture using the Peer-to-Peer is presented by [2] as an interesting infrastructure solution for ad-hoc systems without any infrastructure, being more one step towards the ubiquitous and pervasive computing. In this infrastructure, each peer can play one or more functions inside a service-oriented architecture: service provider, service requester, and services broker (repository with information about services). The Mobile Host [9] architecture is an approach for mobile web services provisioning and provides the following features: web server standard HTTP requests support; web service provisioning for clients requests using SOAP over HTTP; concurrent requests handling capacity; execution time service deployment support; and performance analysis support. Mobile Host was developed as a web service handler built on the top of a regular web server. The web service requests sent by HTTP tunneling are diverted and manipulated by a web service handler. At HTTP interface, Mobile Host waits for HTTP GET/POST requests in a server socket. When Mobile Host receives a request, the server socket accepts it, creates a socket for communication and starts a new execution thread, creating a new request handler instance. This extracts the incoming message from the socket input stream and checks for web service requests. If so, the request handler processes them and sends the responses writing in the socket output stream. The Sliver [3] project defines itself as a SOAP and BPEL execution engine for mobile devices. It took the BPEL from large servers to small mobile devices, besides making services available
[2] G. Gehlen and L. Pham. “Mobile Web Services for Peer-toPeer Applications”. In Proceedings of the Consumer Communications and Networking Conference 2005, p. 7, Las Vegas (2005). [3] G. Hackmann, M. Haitjema, C. Gill and G.-C. Roman. “Sliver: A BPEL Workflow Process Execution Engine for Mobile Devices”. In Proceedings of 4th International Conference on Service Oriented Computing ICSOC 2006 (2006). [4] S. Haustein. “kXML 2”. http://www.kxml.org/ (2005). [5] S. Haustein and J. Seigel. “kSOAP 2”. http://www.ksoap.org/ (2006). [6] I. Laso-Ballesteros. “Research perspectives on Collaborative Infrastructures for Collaborative Work Environments”, In Proceedings of the 15th IEEE International Workshops on Enabling Technologies:Infrastructure for Collaborative Enterprises (WETICE'06), , pp. 3-10 (2006). [7] D. Martin (ed). “OWL-S: Semantic Markup for Web Services”. http://www.w3.org/Submission/OWL-S/ (2004). [8] M. Satyanarayanan. “Pervasive Computing: Vision and Challenges”. In IEEE Personal Communications (2001). [9] S. Srirama, M. Jarke and W. Prinz. “Mobile Host: A feasibility analysis of mobile Web Service provisioning”. In Proceedings of the CAISE’06 Workshop on Ubiquitous Mobile Information and Collaboration Systems UMICS’06 (2006). [10] S. Weerawarana and F. Curbera. “Business Process with BPEL4WS: Understanding BPEL4WS”. http://www.ibm.com /developerworks/webservices/library /ws-bpelcol1/ (2002). [11] M. Weiser. “The Computer for the Twenty-First Century”. In Scientific American (1991).
28
