Integrated Constraint Violation Handling for Dynamic Service Composition

Abstract

Dynamic service composition is suitable for on-demand business requests. For autonomic computing, service composition needs to deal with runtime environment faults, but also with business constraint violations which result from business requirements. We propose an approach for integrated handling of business constraint violations and runtime environment faults for dynamic service composition. We introduce a loosely coupled implementation architecture to maintain the platform-independent nature.

A Coordination Protocol for User-customisable Cloud Policy Monitoring

“…cloud applications provided to many users, are manageable as long as a one-size-fits-all approach works, but a management scalability problem arises if different users have different requirements (Mietzner et al, 2009). A configurable policy monitoring technique is the proposed solution (Wang et al, 2009). Customisation of policy management requires a fine-granular multi-tenancy model, where end users can configure and enact (remotely) their specific requirements.…”

“…For the process view, mashups (composition) need to address composition of functionality as well as composition of quality aspects and their respective policy specifications. (Wang et al, 2009) to support the policy definition and monitoring approach. 1.…”

Cloud Service Localisation

“…Corresponding assurance levels will need to be set. These techniques can be facilitated for service localisation through process adaptation and instrumentation [26]. An intermediary mediates between several clients (at different locations) and several providers (at different locations) by providing this core process with localisation adaptations [23].…”

“…-Dynamic Generation: for regulatory localisation, aspect-oriented instrumentation can be generated on-demand per defined locale, allowing the user control over locale definition -Configuration Management / Generation: different endpoints (and respective bindings) for different locales are generated for a localised API to which then localisations (translations and mappings) are applied; which of these to use might be dynamically decided -Negotiation and Coordination: exchange and agreement on locale policies through SOAP headers based on [26] for coordination -Architecture: data/information integration layer based on ontologies; service localisation layer based on adaptation (user model) and regulatory and lingual localisation; and management through locale negotiation…”

“…Regulations apply for instance with respect the identification and description of business entities or the way processes are handled [17,26]. Furthermore, regulatory locale aspects like tax, currencies and units need to be addressed [4,24].…”