|
ASG Service Delivery Lifecycle
The traditional approach for using (Web) services in Service Oriented Computing bases on static binding
of services. During design-time of the application the developer selects proper
services and binds them to the applications. This implicates, that the applications
can only adapt in a very limited manner to changes in the service environment. For
intra-organisational scenarios this deficiency is mostly tolerable, since the service
environment is under full control of an organisation and unplanned changes are
rather infrequently. In contrast to this, static binding of services is problematic
when it comes to inter-organisational scenarios where major parts of the service
environment are not under control of one entity.
Static binding of services suffer from the following drawbacks:
- Poor utilisation of new services: Static service binding enforces a manual adaptation of existing applications to include new, cheaper or better services. This causes additional costs in the maintenance of applications and it limits the timeliness of adaptations.
- Poor reliability: In inter-organisational scenarios services my fail or disappear at any time for a large variety of reasons: communication and network failures, overload, internal failures or simply disappearance of the providing organisation. In all these cases the static binding of services causes a (partly or even total) failure of the depending applications. In situations where it is impossible to simply sit such a failure out (e.g. because of running costs) a time consuming and costly manual adaptation of the applications is needed.
ASG's Service Delivery Lifecycle
ASG proposes and implements an approach which avoids the above mentioned drawbacks by enabling a dynamic binding of services which leads to an adaptive service provision. Instead of simply binding services to applications at design-time ASG proposes a sophisticated and adaptive service delivery lifecycle. The entry or initial point of this delivery lifecycle is a semantic service request. In contrast to a static service binding the semantic service request does consist of a description of what shall be achieved and not which concrete service has to be executed. The semantic service request describes the initial and goal state and consist therefore among other things out of the given data, data types and conditions which are met by the data as well as the desired type of data and desired effects beyond. The data types, conditions and effects are all specified in relation to a common set of concepts, the domain ontology.
The Planning Subcycle is the first step in processing of the semantic service request. At the beginning the ASG platform tries to find a service which perfectly matches the semantic service request. Perfectly matching means in this context that the service is able to process the given data as input, that all pre-conditions for the execution of the service are fullfilled and that the service output fits to the desired type of data and effects. In case of successfull matchmaking the Planning Subcycle is completed. Otherwise the platform tries to find an abstract composition of services which is able to meet the semantic service request. Abstract composition means, that the composition does not directly bind existing services. Rather the services are represented by semantic service specifications which act as placeholders for the real services. This proceeding allows a late binding of services and features a better reusability of service compositions which is useful for performance issues (e.g. by caching of compositions). The composer starts composing from the initial state of the service request. Given this state the composer searches for services which are executable in this state. By taking their results and effects into account the composer searches successively for new executable services until either the goal state of the semantic service request is met or a further composition is not possible or reasonable. In case of successful composition or a perfect matching of an individual service, an abstract service composition representation is created and forwarded to the next subcycle. Otherwise the processing of the semantic service request is aborded.
Abstract service compositions are transformed into enactable service compositions by the Binding Subcycle. This happens by binding the semantic service specifications, which act as placeholders, to concrete services. For each placeholder the platform starts a negotiation on negotiable service properties with all matching services. The platform tries to find a combination of services which fits as good as possible to the desired properties of the semantic service request. It is worth mentioning that the properties of services which are discussed now are not the semantic functionality of the service like the above mentioned input, pre-conditions, output and effects of a service. Rather the properties describe qualities of the service execution like for example the duration or the costs per execution. These properties are limited insofar that they are not allowed to depend on the concrete input data. When an agreement with a particlular service is achieved a digital contract it is set up and signed by both parties. Services do not necessarily need to support negotiation mechanisms. In such cases the platform simply selects services by their given service properties without conducting a negotiation procedure.
The third step in processing of semantic service requests is the Enactment Subcycle. It receives enactable service compositions from the Binding Subcycle and enacts them by successively or (where possible) parallely invoking the scheduled services. The invocation of services is monitored by the platform for two reasons: On the one hand it is monitored to verify if the previously contracted peculiarities of properties are met. On the other hand the monitoring data is passed to a profiler which aggregates the data to a service-specific profile. This profile contains an aggregate of experiences made during past invocations of a service. It contains informations like the average service execution time or reliability in the sense of observed probability of failure. This profile information can be used by the Planning and Agreement Subcycle to avoid unreliable services. After successful enactment of the service composition the result is collected and it is send back to requestor.
Service environments are quite dynamic when inter-organisational scenarios come into play. The ASG service delivery lifecycle includes two mechanisms to handle the dynamics when it comes to explicitly considered or unconsidered failures of services: re-binding and re-planning.
Considered failures are well known failures which might occur during the execution of a service and are therefore explicitely specified as possible (even though not desired and therefore hopefully seldom) results of a service. One example for such an considered failure is the rejection of credit card by a credit card chargement service, which might occur if the credit card data is invalid or expired. An other example is the loss of a package by a package shipping service. Considered failures are handled in ASG platform by conducting re-planning. In case a considered failure occurs during the invocation of a service, the Planning Subcycle is triggered to find a new composition. The composer tries to find a solution which takes the already achived results into account including the specified undesired results of the failure. The new composition is required to reach the goal specified in the original semantic service request notwithstanding the occured failure. Referencing the package shipping service this might mean that a new package is seized and send. Naturally not all considered failures can be handled by re-composition. In case of the credit card chargement service a recovery is not possible and it is even not useful if a credit card is turned out as being invalid.
In contrast to the considered, are the unconsidered failures not explicitly specified for a service. Unconsidered failures are usually low-level issues like network failures which are raised pre or during the invocation of a service. The platform has no detailed information about semantic effects of such failures exept that these failures just happens at a given point in time. For this reason it assumes in such cases of failure, that the according service simply has not been executed and thus its desired results and effects are not achieved. Such unconsidered failures are handled in up to two phases. In the first phase the platform tries to recover the failure by re-binding. This triggers a new pass of the Binding Subcycle. Here a search for an alternative equivalent service to the already invoked and failed service is conducted by negotiation with proper services. If the search is successfull, the new service is invoked as substitution for the old one. Else the second phase is conducted. In this second phase the platform tries to recover the unconsidered failure by re-planning the composition in the Planning Subcycle. Similar to the handling of considered failures a search for a new solution with different services is conducted which nevertheless reaches the specified goal. In case this search is successful the Binding Subcycle is invoked. After the outstanding service placeholders have been bound to concrete services the new composition is enacted in the Enactment Subcycle.
|
