Section: Application Domains

Service Oriented Architectures (SOA)

Service Oriented Architectures aim at the integration of distributed services at the level of the Enterprise, or as proposed recently, of the whole the Internet. The OASIS team seeks solutions to the problems encountered here, with the underlying motivation to demonstrate the usefulness of a large-scale distributed programming approach like ProActive and GCM in this area :

• Deployment of a service on the service infrastructure: as services depend upon other services, deployment and runtime management can be eased if these dependencies are made explicit. Indeed, services required for another service to work can be instantiated or discovered more easily if the dependencies are known. The recently defined Service Component Architecture (SCA) model is gaining popularity. We are conducting research to promote the Grid Component Model as a complement to SCA. Indeed, we think that GCM is by essence well equipped for supporting services that are widely distributed, and may need to be invoked in an asynchronous manner, still participating in a global SCA-based SOA. We thus pursue works to make SCA and GCM become interoperable models.

• Interoperability between services: the uniform usage of web services can provide a simple interoperability between them. GCM components can be exposed as web services [55] , and we have conducted research and development to permit a GCM component to invoke an external web service through a client interface, and thus to have GCM/SCA components be integrated in SCA-based applications relying on SCA bindings configured as web services.

• Large-scale deployment and monitoring of a set of (similar) services on a possibly large set of machines from e.g. a computing grid, a cloud of machines, etc.: such capability will really make SOA ready for the Internet scale, and we are designing some grid services, accessible as web services, in order to leverage the required functionalities for Grid/cloud deployment of components/services and monitoring of the resulting runtime infrastructure.

• Distributed and Scalable service bus: this is needed if services are composed and orchestrated through an Enterprise Service Bus. But, to scale, the ESB must itself be distributed, and must incorporate from design time, the necessary mechamisms to handle large-scale distribution and possibly huge amount of end-user or technical (service discovery, registry, orchestration and monitoring engines, etc) services. Moreover the bus itself should be deployable seamlessly on any heterogeneous combination of host machines. In this wide context, we intend to use GCM components for building the bus itself, giving it the required Internet scale capabilities (this subject is specifically addressed in the context of the SOA4ALL IP FP7 project the team is involved in, taking the OW2 PEtALS ESB from the PEtALS link SME as starting point)

• Peer-to-peer based service registry and service lookup protocols: in an Internet-based world hosting possibly billions of services, the registration and subsequent lookup of services can only be addressed along a semantic-based approach, and should allow a robust and scalable way to store and query for service descriptions. In the context of the SOA4ALL IP FP7 project, we conduct research to contribute to the design of a semantic space where services will be stored and looked upon based on their semantic description. For scalability purposes, the space specification is organised as a peer-to-peer network, further implemented in a distributed, scalable way relying on a grid middleware as the ProActive technology.

• Self-management of the SOA infrastructure and SOA applications: this pertains to autonomic and self-management of the service infrastructure, but also of the component assemblies that constitute the Service Oriented Application. Again the use of GCM components instead of Fractal-RMI components whenever needed can be a solution to the scalability and deployment problems. For service compositions represented as component assemblies, we are exploring the use of control components put in the component membranes, acting as sensors or actuators, that can drive the self-management of composite services, e.g. according to a negotiated Service Level Agreement.

• Distributed and agile workflow enactment: as BPMN and BPEL are the standard ways to define a service orchestration, we are considering how such a composition in time approach can be mapped into an architectural-based view involving (SCA) components. Besides, efficient and secured orchestration of such service compositions can benefit from distribution and parallelism. In this aim, we investigate how GCM can be successfully used to design a parallel, distributed, yet flexible orchestration engine handling a BPEL workflow description previously decomposed into sub-workflows. Deployment and management of the decomposition can also be addressed easily by having the distributed workflow relying on GCM components.