Early Aspects for Non-Functional Properties in Service Oriented Business Processes

Abstract

In Service Oriented Architecture, each application is often designed with a set of reusable services and a business process. In order to retain the reusability of services, it is important to separate non-functional properties of applications (e.g., security and reliability) from their functional properties. Currently, non-functional properties are often defined on a per-service basis. In contrast, this paper investigates a new per-process strategy, and proposes an aspect oriented language to separate functional and nonfunctional properties in business processes. Each aspect formally specifies non-functional properties that crosscut among multiple services. The proposed language frees applications developers from manually specifying and validating non-functional properties for services one by one, thereby reducing the burdens/costs of application development and maintenance. This paper describes the design of the proposed language and demonstrates how each aspect (i.e., a set of non-functional properties) is woven to a business process and transformed to application code.

Reflections on the modularity of business process models

“…Although concerned with the implementation of BPs, more specifically with composition, this proposal underlines the business rule perspective as an important modularity issue. Wada et al (2008) propose an AO language to separate functional and non-functional properties in BPs, in order to preserve the reusability of services. Each aspect specifies non-functional properties which crosscut among multiple services, and is woven to a BP and transformed to application code.…”

“…To the best of our knowledge, few researchers have considered the mating of AO concepts at the BP level, but only in preliminary form ([XXX] ;Charfi, 2007;Wada et al, 2008;Park et al, 2007). Approaches addressing this issue at the software requirements level have in common the introduction of a whole new set of abstractions -usually derived directly from AO implementation techniques -thereby increasing the complexity of the conventional requirement abstractions.…”

“…Providing the modularity to tackle these extra functional concepts is believed to improve understanding and evolution of these processes. Other researchers, Kueng and Kawalek (1997), Soffer and Wand (2005), and Wada et al (2008), have mentioned the problem; however, our approach is novel as it proposes the inclusion of a new modularity mechanism at the level of process description. In a review by Recker et al (2009), the issue of modularity is identified as "the cluster systems structured around things" and even BPM notation, the best-evaluated for the cluster, has problems.…”

Realizing Quality Attributes of Service-Based Business Processes: A Model-Driven Approach

“…This profile models security in a low level, defining technical security properties (e.g., algorithms, tokens, timeout) of the system. In Wada et al [28] the original approach is extended, by now starting from a BPMN model (functional) and a Feature model (non-functional) that are weaved to generate the UP-SNFR model. Although defining non-functional properties early, the business and design models share the same abstraction level to define the non-functional aspects.…”

Introducing Security Access Control Policies into Legacy Business Processes

“…Therefore, it is necessary to specify attributes of quality for business processes rather than services, reducing costs and surcharges in the development and application maintenance. Unfortunately, UML, BPMN and BPEL do not support separation of concerns per se [8]. The use of concerns managed by models allows us to adjust service orchestrations in high level of abstraction, so that business processes can be enriched with additional features [9] without major modifications or changes in code-level source.…”