Benjamin Schmeling

Reliable, Secure, and Transacted Web Service Compositions with AO4BPEL

Web service compositions in BPEL have several nonfunctional requirements such as security, reliable messaging, and transactions. Although many WS-* specifications address such non-functional concerns in the Web service context, they focus only on the messaging-level requirements without addressing the process-level requirements. In this paper, we discuss different non-functional requirements in BPEL workflows and observe that current orchestration engines lack support for the specification and enforcement of such requirements, especially for process-level requirements. To solve this problem, we present a container framework, which introduces an XML-based deployment descriptor to specify the non-functional requirements in a declarative way. To enforce these requirements, a process container intercepts the process execution and calls dedicated middleware Web services. We implemented the process container as a lightweight container using a set of A04BPEL aspects that are automatically generated from the deployment descriptor. In addition, we have implemented BPEL middleware Web services for reliable messaging, security, and transaction

Transactional BPEL Processes with AO4BPEL Aspects

Recently, OASIS approved two standards respectively for Web Service composition and for Web Service transactions. Nevertheless, it is still unclear how WS-BPEL and the WS-TX family of specifications interoperate, i.e., how to use atomic transactions and business activities in the context of BPEL processes. In this paper, we present several transactional requirements in BPEL processes and argue that BPELs compensation mechanism provides only limited support for a few of these requirements, e.g., it cannot cope with atomic transactions with the ACID properties. To support transactional BPEL processes, we use the AO4BPEL process container framework. In this framework, the transaction requirements of the process activities are specified declaratively in a deployment descriptor and an aspectbased container is generated automatically to integrate the process execution with the transaction middleware, which is provided as a transaction Web Service based on Apache Kandula.

An Overview of the Unified Service Description Language

Existing service description languages focus mainly on the technical aspects of automated services, hence all other types of service — namely human and IT supported — and the business aspects of service provision — pricing for instance — are yet to be adequately addressed. This paper introduces the latest version of the Unified Service Description Language (USDL), a domain-independent service description language aimed at all of the above-mentioned types of service, from both a business and a technical perspective. For the latter is already captured by widely adopted service description standards, such as WSDL and WS-BPEL, USDL does leverage those languages. Apart from aggregating technical information, a service provider can use USDL to describe business-related properties, capabilities and non-functional characteristics, enabling consumers to invoke and use business services and intermediaries to repurpose services. USDL has been developed mainly by SAP Research, which is driving its standardization with other stakeholders. This paper gives an overview of the USDL language and presents an editor to define and serialize USDL service descriptions.

Reliable Messaging for BPEL Processes

There are currently two specifications that address reliable messaging in Web services: WS-reliablemessaging and WS-reliability. Both specifications consider the general case of Web services as being black boxes with WSDL interfaces. In this paper, we address the reliable messaging requirements of composite Web wervices in BPEL. In such Web services, the BPEL programmer sees not only the WSDL interface but also the implementation, i.e., the process definition. BPEL processes have several reliable messaging requirements, which cannot be supported by current reliable messaging specifications. The most challenging of those requirements is to support ordered message delivery between many endpoints. Current reliable messaging specifications support only reliable messaging between two endpoints. This paper presents several approaches to support multi-party reliable messaging and introduces a reliable messaging Web service for BPEL that is integrated with a BPEL engine by using a process container framework. This Web service supports the reliable messaging requirements of BPEL processes and its implementation is based on Sandesha, which is an open source implementation of WS-ReliableMessaging

Composing Non-functional Concerns in Composite Web Services

The support for non-functional concerns (NFC) is essential for the success and adoption of web services. However, state of the art works offer only a limited support for these concerns especially when it comes to the composition of multiple non-functional concerns with composite web services. In this paper, we focus on the composition of non-functional actions (NFA) with composite web services whose composition logic is made explicit using languages such as BPMN2 or WS-BPEL (gray box view). In contrast to the black box view where only the interface of the service is visible the gray box view reveals additional information on control flow, data flow, composed services, etc. NFAs can also be composite and constitute complex processes such as secure conversations or transactions which have to be integrated with composite web services. Additionally, the execution order of multiple superimposing NFA has to be declared. In our approach we introduce a model-driven approach for the integrated specification and realization of the different types of NFC composition (NFAs with composite services, execution order of superimposing NFAs and composite NFAs) as well as a set of editors and code generators supporting this approach.

Composing Non-functional Concerns in Web Services

Support for non-functional concerns (NFC) is essential for the success and adoption of web services. This support encompasses two aspects: the specification of NFCs and their realization. However, state-of-the-art works offer only limited support for these aspects. This is especially true for the composition of multiple non-functional concerns with one web service, which is a highly complex task. It is complex because specific knowledge from different domains is required, as well as an understanding of the interdependencies between non-orthogonal NFCs. In this paper, we present an approach and a toolset for the specification and realization of the composition of multiple NFCs in web services. We also present a well-defined process involving different roles and we introduce graphical modeling notations for specifying non-functional requirements, actions realizing the requirements, action compositions and the mapping of actions to web services. These specification models are used for the generation of code that realizes the NFCs.

Non-functional concerns in web services: requirements and state of the art analysis

For the success and adoption of web services it is essential that not only functional concerns (FC) are addressed but also non-functional concerns (NFC) such as security, reliable messaging, performance, and availability. The support for non-functional concerns encompasses two aspects: the specification and the enforcement and we focus thereby on two views: the black box view (only the interface) and the gray box view (the internal process of a composite service). In this paper we identify the most important requirements for the specification and enforcement of NFCs whilst taking the two different views into account. Furthermore, we present a thorough analysis of the state-of-the-art works based on those requirements and identify areas where future work has to be conducted to fulfill all identified requirements.

Using temporal policies for managing changing meta-data of Web Services

Web Services (WS) meta-data is used to formally describe functional and non-functional concerns of web services (such as capabilities, price). Several properties described by meta-data change over time. For example, prices and technical availability may change frequently, but are usually stored in static XML documents. In this paper, we introduce the temporal policy language to facilitate temporal management of structured documents. Temporal aspects can be applied to documents, such as service descriptions, or even properties in structured documents. Validity periods can be added to these properties, such that customers can easily check whether certain properties (e.g., prices) in a document are valid.

Towards conflict-free composition of non-functional concerns

In component-based software development, applications are decomposed, e.g., into functional and non-functional components which have to be composed to a working system. The composition of non-functional behavior from different non-functional domains such as security, reliability, and performance is particularly complex. Finding a valid composition is challenging because there are different types of interdependencies between concerns, e.g. mutual exclusion, conflicts, and ordering restrictions, which should not be violated. In this paper we formalize a set of interdependency types between non-functional actions realizing non-functional behavior. These interdependencies can either be specified explicitly or implicitly by taking action properties into account. This rich set of interdependencies can then be used to ease the task of action composition by validating compositions against interdependency constraints, proposing conflict resolution strategies, and by applying our guided composition procedure. This procedure proposes next valid modeling steps leading to conflict-free compositions.

An aspect-oriented framework for specification and enforcement of non-functional concerns in WS-BPEL

Web Service processes in WS-BPEL have several non-functional requirements such as security and reliable messaging. Although there are many WS-* specifications that address these concerns, their integration with WS-BPEL is still open. In this paper, we discuss these non-functional requirements and present a survey on the current support for their specification and enforcement in WS-BPEL engines. Moreover, we introduce an aspect-oriented container framework that uses a declarative deployment descriptor to specify the non-functional requirements. For the enforcement, aspects in AO4BPEL 2.0 are generated, which intercept the process execution and call dedicated middleware Web Services.