Architecture

Version 2 by Sébastien Rebiere
on Apr 29, 2013 11:55.

<< Changes from 1 to 2

compared with

Version 3 by Sébastien Rebiere
on Apr 29, 2013 11:56.

Changes from 3 to 4 >>

Key

This line was removed.

This word was removed. This word was added.

This line was added.

Changes (3)

View Page History

h1. Architecture

The following image depicts the main components of SemEUsE architecture: !architecture3.jpg|border=1!

!architecture3.jpg|border=1!

The main components are:
* The service layer, i.e. the PEtALS ESB. PEtALS is mainly an implementation of the JBI standard (Java Business Integration\[[1]\|http://semeuse.org/plugins/editors/tinymce/jscripts/tiny_mce/blank.htm#_ftn1\]) and is open-sourced in OW2\[[2]\|http://semeuse.org/plugins/editors/tinymce/jscripts/tiny_mce/blank.htm#_ftn2\]. It provides, among other things, message routing over the network, communication protocol mapping (for instance from HTTP/SOAP to JMS), load balancing and a certain level of security. Moreover, PEtALS is a distributed ESB, meaning that it can be deployed over multiple nodes over a WAN allowing multiple PEtALS nodes to be seamlessly integrated over a WAN.

...

* The service registry, i.e. Dragon. Dragon is also open-sourced in OW2\[[3]\|http://semeuse.org/plugins/editors/tinymce/jscripts/tiny_mce/blank.htm#_ftn3\] and is a specific database for owning all the data and meta-data on services: end-points, metadata for service categorization and description, organization management, Service Level Agreement (SLA) management and associated tools. As such, Dragon is a first level SOA governance solution. For SemEUsE (and so MICO), Dragon holds functional and non-functional capabilities for services: functional capabilities express what the service does and non-functional capabilities express how it does it. These capabilities are specified as references to the domain ontologies. The main points here are, first, these meta-data are defined outside of the code of the services and applications which allows an easier integration of legacy applications. Second, software services are specified trough domain term using the same ontologies as the other software of MICO easing the understanding by domain experts when, for instance, querying for services in a business process.
* The business process engine is OW2’s Orchestra\[[4]\|http://semeuse.org/plugins/editors/tinymce/jscripts/tiny_mce/blank.htm#_ftn4\]. Orchestra executes business process specified with BPEL2 that is an OASIS standard\[[5]\|http://semeuse.org/plugins/editors/tinymce/jscripts/tiny_mce/blank.htm#_ftn5\] which allows extending the business process language with so-called “extended activities”. SemEUsE uses these extended activities to allow a business process to query services from their semantic specifications (functional and non-functional) and then to invoke them.
* In the semantic layer, the semantic registry component uses Dragon to store and retrieve services based on their semantically defined functional and non-functional capabilities. The language used to define web-services is SA-WSDL which is a W3C standard\[[6]\|http://semeuse.org/plugins/editors/tinymce/jscripts/tiny_mce/blank.htm#_ftn6\]. This component performs effectively also the queries in the dragon database and uses semantic matching in the domain ontology.
* The Semantic QoS-enabled Composition Framework effectively defines the new extended activities and performs the corresponding tasks. The extended activities allow a domain expert to specify its business processes with its own terms: specifying service invocation not through static technical end points but through dynamically resolved functional and non-functional required properties (such as digitization, speed, cost and so forth). Sub-components take care of:
** Keeping a business process within a given quality of service (for instance, if a complete business process must be quicker than 10 minutes, the included services must chosen accordingly based on their real, i.e. measured, performance).
** The service level agreements, i.e. the enforcement the non-functional contract of services that is published in the dragon registry.
** The data adaptation: when a service is dynamically found based on its functional and non-functional capabilities, its technical interfaces have still to be figured out in order to be really invoked.
** The reconfiguration due to a change in dynamic qualities of services and/or new services.
* The monitoring services ensure, through probes, the measure of the qualities of services (performance, CPU, …)

* The security component takes care of the security aspect all along the invocation process.
* The ontology repository stores and retrieves ontology their content. The ontology is defined through the OWL-DL language (W3C standard\[[7]\|http://semeuse.org/plugins/editors/tinymce/jscripts/tiny_mce/blank.htm#_ftn8\]).

\----\[[1]\|http://semeuse.org/plugins/editors/tinymce/jscripts/tiny_mce/blank.htm#_ftnref1\] [http://jcp.org/aboutJava/communityprocess/final/] jsr208/index.html

\[[2]\|http://semeuse.org/plugins/editors/tinymce/jscripts/tiny_mce/blank.htm#_ftnref2\] [http://petals.ow2.org/]

...

Members Area

Architecture

Changes (3)