You are here: Foswiki>Adesa Web>NextSteps>WpStructure>WorkPackage3 (20 Apr 2007, ChristianDoerner)Edit Attach

WorkPackage3: Use of Architectural (Design) Information for Service Discovery and Assembly ( PM)

Objectives:
  • General goal: to generate an executable process from a service assembly defined in the end user design environment
  • Generate an abstract and annotated process description as an enhanced service specification from a service assembly, taking into consideration: user characteristics and non functional requirements (context)
  • Retrieve concrete services able to fulfill the requirements of enhanced service specification from the advanced service registry
  • Service procurement allows negotiating QoS ? and price for selected services
  • Formal verification…
  • Service composition creates an executable process with Optimization, interface mediation, SLA (interacting with procurement), contract generation

T3.1. Develop Assembly Description Language ( UM, PM);

Start date: M3

Objectives:
  • Analyse main topologies of user representations of service assemblies;
  • Group into main architectural styles;
  • Compare with inventory of existing services
  • Develop an Assembly Description Language to formally specify user-driven service assembly

Description of work The assembly description language provides a formal basis for specifying user-oriented designs. The result of the visual design phase is a composition of components understandable at the user level, connected via different types of connectors. This description will be in general at a level of detail lower than the one needed for executable services that are composed in the machine view of the design process. On the other hand, the service assembly should contain all information needed to generate and validate the executable service composition. Several business process models have been proposed in the literature, and mapping tools exist for several formalisms, therefore in this task we will develop a description language containing the most common constructs used in process description languages. A starting point will be UML notations and associated exchange formats like XMI and XPDL. However the characterizing aspect of the proposed language is a rich set of connectors to link components to the user context. In particular, these will be the basis to translate service assemblies into enhanced service specifications, which will be the starting point of the adaptive composition mechanisms at the machine level. The user context will provide information on the semantics of objects being composed, which might be domain dependent, on non functional requirements, quality of service requirements. The context information might which be explicit or derived from a user profile associated to the user, used for several compositions, according to knowledge reuse paradigms defined in WP4 (to be cross checked, user characterization is not explicitly mentioned).

1011

Please clarify the connection between the developed ADL and BPEL/SCA; why shouldn't the ADL be used in T3.2 as well?

The result of this workpackage is the development of a service assembly description language which allows an internal representation of service assemblies defined by the users using methods described in WP4.

Deliverables
  • D3.1 Assembly Description Language

T3.2. Service specification meta-data ( US, UM, PF, PM)

Start date: M9

Objectives:
  • Create a union of enhanced service search specifications for architectural styles, QoS and community and appropriation support
  • Distill into a service specification meta-data

Description of work

The aim of the task is to create a union of enhanced service specifications for architectural styles, QoS as well as the specification of meta-data that represents collaborative information.

There is most likely a fairly large gap between services in the user view and services in the machine view. Most likely services at user level are macroservices, while services within business processes in a SOA are composed at the operation level, generally decomposing and refining the macroservice in a set of operations, linked by control structures and with detailed behavioral properties. The final goal being that of generating executable processes, defined as BPEL processes, methods will be studied to transform service assemblies defined in the language developed in T3.1 to a first internal representation which describes the composed service at an abstract level. This abstract level is the basis for verification and for service composition and procurement. The composed service is described in an Enhanced service specification language. The composition is described using an abstract BPEL process, where to each invoked service and to the whole process (or portions of it), some meta-data are associated. Meta-data include global and local QoS ? constraints in the process, semantic annotations of services, adopting current lightweight standards like SAWSDL and possibly new W3C proposals, expected process characteristics derived from the domain, such the likelihood of a given execution path. User context meta-data will also be associated to the process to express user preferences, such as for instance priorities set on different QoS ? properties. This abstract process description will be formally verified to analyze its dynamic properties and will be the basis for selecting components from the extended UDDI registry with service composition and procurement.

The specification of additional meta-data is furthermore based on the scenarios and empirical results of WP1. It is motivated by the focus of supporting social aspects of service assembly in a manner similar to the patterns of collaboration found in OSS development, because such information is currently non existent. Appropriate meta-data in this context are information that enables end users to understand and use services in an easier way. Meta-data, which can increase users’ understanding, are for example the description of a service from users’ point of view, social tags (e.g. demonstrated by Flickr) or the listing of examples. To ease the usage of services, meta-data could provide also a value- or a function-help that can be influenced by users themselves. In connection with the usage of services, it should be considered that services are remote functions, which have no graphical user interface. This leads to the problem that services can’t be presented to end users in an appropriate way. Metadata should therefore contain a possibility to define a generic graphical user interface, allowing users to interact with a service in a familiar way. Furthermore we aim to support the patterns of collaboration, negotiation and delegation which are frequently encountered within user groups and between users and developers. The following collaborative aspects of end-user service assembly are in the focus of these activities: sharing of best practices, the emergence of super-users supporting others, delegation and collaboration with software developers, exchanging service orchestrations and community-based ratings.

Deliverables D3.2 Enhanced service model and language specification, Service Specification meta-data (architectural, QoS and collaborative), possible extensions to the UDDI and WSDL standards (M12)

T3.3. Translation mechanism ( PM, UM)

Start date: M12

Objectives:
  • Develop a mechanism for automatic compilation of user design specification into enhanced service search specification. This may be different for each architectural style.

Partially overlapping with T3.2

Description of work Translation mechanisms will be studied to transform the service assembly into an enhance service specification. The mechanisms will be based on clustering techniques on service assemblies, to identify characteristic patterns for which an enhanced service specification fragment is defined. Several fragments will be derived and composed according to composition rules driven also by context information. We assume that a process registry stores enhance process specification fragments and related meta-data.

Deliverables
  • D3.3. Automatic Translation Mechanism (M24)

T3.4. Formal Verification Mechanism ( PM, UM)

Start date: M12

Objectives:
  • Develop a mechanism for formal verification of service compositions as attempted by the user.

Description of work Web service compositions can be validated by means of different formal means. In these years, there has been an increasing attention to the use of model-checkers for assessing both the static elements, and the possible evolutions of these architectures.

In this project, we aim at proposing a formal framework for the analysis of service specifications translated from ADLs. The proposal will be based on model-checking techniques and on the definition of suitable and special-purpose abstractions for the efficient analysis of these applications. The modularity of modern model-checkers (e.g., Bogor) allows for the ad-hoc tailoring of the state space generation and thus facilitate its analysis. The proposal will also propose graphical notations to formalize the different aspects of the system under analysis, and the properties we want to study, and will propose automatic translations of the models produced with these notations into the language understood by the model-checker.

Deliverables
  • D3.4. Formal Verification Mechanism (M24, extended M36)

T3.5 Service Composition and Procurement ( PM, ??)

Start date: M12

Objectives: Develop algorithms to support service composition and procurement

In this task algorithms for associating concrete executable services to the enhanced service specification will be studied. Four main problems will be studied:
  • service selection, using an advanced UDDI registry, storing WSDL services enhanced with service annotations in SAWSDL and QoS ? policies. Candidate services will be used in the following phases.
  • Process optimization, selecting the best concrete services for the composition. Optimization will be global, considering not only QoS ? constraints as in the current literature, but also service dependencies and granularity
  • Service procurement: methods to define through negotiation an optimal Sla and formulating a service contract to be used for pricing and monitoring will be studied. Negotiation will be based on service characteristics, expressed as policies, and on meta-data in the enhanced service specification.
  • Service adaptation: in case of semantic or syntactic mismatch between service interfaces, a mediator engine will provide mechanisms to automatically transform messages among services. Part of this work will be developed extending methods and
tools developed at POLIMI, in particular: an extended UDDI registry with SAWSDL plug-in (URBE), a mediation engine to adapt services automatically at run time, an optimization tool for QoS ? based on linear programming, and a negotiation tool based on service and user request profiles (see RelatedWork). Question to the consortium: do we want all this completely automated or we allow the intervention of specialistics at the machine view level (eg: interface adaptation for mediation might require some human intervention to disambiguate, for instance- this would be probably too low level to be presented to the user)

Deliverables
  • D3.5.1 (Month 18-revised month 24, 36) Composition model, extended UDDI registry additional functionalities, adaptation of existing algorithms
  • D3.5.2 (Month 24-revised month 36) Extended algorithms for global process optimization, contract generation, adaptation
-- NikolayMehandjiev - 19 Apr 2007
Topic revision: r2 - 20 Apr 2007, ChristianDoerner
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback