Formal Approach for the Development of Business Processes in terms of Service-Oriented Architectures using π-ADL

Flavio Oquendo European University of Brittany

University of South Brittany – VALORIA – BP 573 – 56017 Vannes Cedex – France flavio.oquendo@univ-ubs.fr

Abstract Enabling the specification of a dynamic Service-Oriented Architecture (SOA) for supporting a Business Process is a key challenge for an Architecture Description Language (ADL). This paper presents a formal approach for the development of business processes (modeled in BPMN) in terms of dynamic service-oriented architectures. It uses π-ADL for SOA, a novel ADL that has its roots in the ArchWare European Project. It is a formal language specially designed for specifying dynamic architectures based on the typed π-calculus. We introduce the mapping between BPMN and π-ADL for SOA through process patterns and illustrate its application. The π-ADL for SOA toolset and its experimentation are outlined.

1. Introduction

Software architecture has emerged as an important

subdiscipline of software engineering [7][13]. A key aspect of the design of any software system is its architecture, i.e. the fundamental organization of the system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. A software architecture can be characterized according to its evolution at run-time [9]: (i) static architectures: the architecture does not evolve during the execution of the system; (ii) dynamic architectures: the architecture may evolve during its execution, e.g. components are created, discovered, or reconfigured at run-time.

An architecture description specifies an architecture. An architecture can be described according to different viewpoints. Two viewpoints are frequently used: the structural and the behavioral viewpoints.

The structural viewpoint may be specified in terms of: (i) components (units of computation of a system); (ii) connectors (interconnections among components for supporting their interactions); (iii) configurations of

components and connectors. Thereby, from a structural viewpoint, an

architecture description must provide a specification of the architecture in terms of components and connectors and how they are composed together. Further, in the case of a dynamic architecture, it must provide a specification of how its components and connectors can change at run-time.

The behavioral viewpoint may be specified in terms of: (i) actions a system executes or participates in; (ii) relations among actions to specify behaviors; (iii) behaviors of components and connectors, and how they interact.

Architectures are described according to different architectural styles. A mainstream architectural style is Service-Oriented Architecture (SOA). SOA is an architectural style for constructing complex software-intensive systems from a set of universally interconnected and interdependent building blocks, called services, where functionality is grouped around business processes.

Business processes, including orchestrations and choreographies, are defined using business process modeling languages. BPMN (Business Process Modeling Notation) [10] is a standardized visual notation for modeling business processes.

In architectural terms, in a SOA, services (which are provided, can be requested and whose interface descriptions can be published and discovered) are the architectural components, messaging passing connections are the architectural connectors, and orchestration and choreography the architectural configurations of components and connectors.

Designing a Web service-oriented architecture thereby involves different artifacts expressed in different languages (e.g. WSDL, WS-BPEL, WS-CDL), where these languages are semi-formal and possibly overlapping. This is a complex and error-prone task that can lead to poorly-designed architectures and failures in the implementation of systems with the required qualities.

Formal methods are increasingly used for modeling

2008 IEEE International Symposium on Service-Oriented System Engineering

978-0-7695-3499-2/08 $25.00 © 2008 IEEE

DOI 10.1109/SOSE.2008.38

154

software architectures [5]. Their potential advantages have been widely recognized, in particular “to design the system right” by formally describing its structure and behavior enabling to check its correctness with respect to qualities.

Enabling the specification of dynamic Web service-oriented architectures is a key challenge for an Architecture Description Language (ADL). The research challenge is therefore threefold: • To support the description of dynamic service-

oriented architectures. The ADL must be able to describe changing structures and behaviors of services, their discovery, connections and compositions at run-time.

• To support the description of service-oriented architectures where business processes are modeled in visual notations such as BPMN, orchestrations in languages such as WS-BPEL, choreographies in languages such as WS-CDL and interfaces in languages such as WSDL. The ADL must be able to provide a unified foundation for describing the different SOA artifacts: business processes, orchestrations, choreographies, and interfaces.

• To support the description of service-oriented architectures enabling to rigorously reason about and verify their qualities, in particular related to conformance and correctness. The ADL must be formally defined. π-ADL for SOA has been designed to meet this

challenge. The remainder of this paper is organized as follows.

Section 2 introduces π-ADL for SOA. Section 3 describes the formal mapping of BPMN in terms of π-ADL for SOA. Section 4 shows how π-ADL for SOA can be used for specifying a business process model in terms of a dynamic service-oriented architecture. Section 5 briefly outlines the π-ADL for SOA toolset and its applications. In section 6 we compare π-ADL for SOA with related work. To conclude we summarize, in section 7, the main contributions of this paper.

2. π-ADL for SOA

For enabling the specification of dynamic Web

service-oriented architectures, meeting the threefold research challenge cited so far, we have designed a service-oriented architecture description language as a new member of the π-Architecture Description Language (π-ADL) [11] family. π-ADL provides a novel and customizable ADL that is general-purpose

and Turing-complete1. It has been designed in the ArchWare2 European Project to be the root of an open family of ADLs where members of the family are embedded domain-specific languages. π-ADL for SOA is, as a result, a service-oriented

architecture description language enabling the formal development of dynamic applications. π-ADL for SOA is: • service-oriented: it provides constructs directly

related to the service-oriented architecture style, including services, binding connections and their compositions by orchestration and choreography;

• formal: it is a formal language based on the typed π-calculus [8]; a verification toolset is provided for automated checking of service-oriented architectural properties;

• practical: it provides user-friendly concrete syntaxes – textual and visual (via a BPMN profile) – hiding the complexity of its formal underpinnings to ease its use by architects and engineers;

• executable: it supports architecture descriptions that specify how the system behaves in terms of SOA concepts; its virtual machine runs SOA descriptions. π-ADL for SOA takes its roots in previous work

concerning the use of π-calculus as semantic foundation for architecture description languages [11][2] and business process management languages [15][16].

Indeed, a natural candidate for expressing (run-time) behavior would be the π-calculus as it is [8], which provides a general model of computation and is Turing-complete. However in π-calculus, even if every computation is possible to express, this expression becomes quite often too complex. In fact, the classical π-calculus is not suitable as an ADL since it does not provide architecture-centric constructs to friendly express architectures in particular with respect to architectural structures and abstractions. Therefore, a language encompassing both structural and behavioral architecture-centric constructs is needed. π-ADL is this encompassing core language. It achieves Turing completeness and high architecture expressiveness with a simple formal notation. π-ADL for SOA is defined as a style-specific extension of the typed π-calculus on top of π-ADL, of which it is an embedded domain-specific language.

But why do architects need a formal Service-Oriented ADL? Of course, ADLs that provide a semi-formal notation helps as the state of the practice today 1 This means that every possible computation can be expressed in π-

ADL. 2 The ArchWare European Project has been partially funded by the

European Commission under contract No. IST-32360 in the IST Framework Program.

155

is mainly to use semi-formal notations for documenting software and service architectures. A semi-formal ADL helps but it is not enough. Indeed, in order to check correctness, a formal ADL encompassing both structural and behavioral constructs is mandatory. π-ADL for SOA is this formal yet practical ADL. It

supports automated verification of service-oriented structural and behavioral properties. In addition to that, it is executable: it is very practical to “run” an architecture description in order to validate its dynamic semantics.

For bridging the gap from business process to composition of services, it provides a BPMN profile that eases its use and fully automates its translation to verifiable, executable specifications. Precisely, π-ADL for SOA supports description of service-oriented architectures from a run-time perspective. In π-ADL for SOA, a service-oriented architecture is described in terms of services, connections and their compositions.

3. From BPMN to π-ADL for SOA

BPMN eases business process modeling by

providing a visual notation. This notation organizes its modeling elements into specific categories. The four basic categories are: flow objects, connecting objects, swimlanes, and artifacts. Flow objects are the main elements to describe the behavior of a business process. There are three kinds of flow objects: events, activities, and gateways. Flow objects are connected to

each other by connecting objects, which are of three kinds: sequence flow, message flow, and association. Modeling elements are grouped through swimlanes, which may be pools and lanes. Artifacts are used to provide input and output information on activities (in particular, on tasks).

Our approach for the formal development of business processes is to enable the visual modeling of business processes using BPMN and then their analysis and refinement using π-ADL for SOA. As BPMN lacks a formal semantics, the explicit mapping from BPMN to π-ADL for SOA explicitly assigns the semantics of a BPMN business process model in terms of the π-calculus through π-ADL. Technically, our approach is to define a denotational semantics for BPMN in terms of π-ADL for SOA. This definition is explicit and may be adapted for taking into account different interpretations of BPMN (as BPMN has been defined semi-formally, there are variations in the possible interpretations of BPMN diagrams). It thereby enables a process modeler to adjust the semantics of BPMN to particular needs.

The mapping from BPMN to π-ADL for SOA is defined in terms of a formal transformation language (not presented in this paper due to lack of space).

Instead of presenting its formal underpinnings, we introduce hereafter the mapping between BPMN and π-ADL for SOA using process patterns (as have been popularized in [17]). In table 1, we will present a subset of these patterns focusing on some core modeling elements of BPMN.

Table 1. Mapping between BPMN Modeling Elements and ADL for SOA

BPMN Construct π-ADL for SOA Expression None Start Event: it starts the flow of the process.

activity Event is abstraction(out : connection[]){ behavior is { via out send } }

Message Start Event: a message m arrives from a participant and triggers the start of the process.

Event

out

msg

activity Event is abstraction(msg : connection[Any], out : connection[]){ behavior is { replicate via msg receive m : Any. via out send } }

None End Event: it ends the flow of the process.

activity Event is abstraction( in : connection[]){ behavior is { replicate via in receive } }

156

Message End Event: it indicates that a message is sent to a participant at the end of the process.

activity Event is abstraction( in : connection[], msg : connection[Any]){ behavior is { value m is any(). replicate via in receive. via out send m } }

None/Service Task: it specifies an atomic activity that is performed in a process (it may invoke a service).

activity Task is abstraction(in, out : connection[]){ behavior is { replicate via in receive. unobservable. via out send } }

Send Task: it sends a message to an external participant of a process and then the task completes.

activity Task is abstraction(in, out : connection[], msg : connection[Any]){ behavior is { value m is any(). replicate via in receive. via msg send m. via out send n } }

Receive Task: it receives a message from an external participant of a process and then the task completes.

activity Task is abstraction(in, out : connection[], msg : connection[Any]){ behavior is { replicate via in receive. via msg receive m : Any. via out send } }

Data-Based Exclusive Gateway: an exclusive-or decision based on a data condition where all conditions are mutually exclusive. Only one choice is possible.

activity Gateway is abstraction( in, out1, out2 : connection[]){ behavior is { replicate via in receive. choose { if c1 do via out1 send or if c2 do via out2 send -- may have n data alternatives } } }

Exclusive Merge Gateway: an exclusive-or gateway used as a merge for alternative sequence flows.

activity Gateway is abstraction( in1, in2, out : connection[]){ behavior is { replicate choose { via in1 receive. via out send or via in2 receive. via out send -- may have n merge alternatives } } }

Pool: it represents a participant in a process. Po

ol

service Pool is abstraction(…){ type is … . -- types are declared port is { … }. -- ports are declared activity is { … }. -- activities are declared behavior is { compose { -- orchestration of activities } } }

Business Process: it describes the whole process.

Pool

Pool

architecture Process is abstraction(…){ type is … . -- types are declared port is { … }. -- ports are declared service is { … }. -- services are declared behavior is { compose { -- choreography of services } } }

4. Case Study: From BPM to SOA

We briefly show hereafter how π-ADL for SOA can

be used for specifying a BPMN business process model in terms of a dynamic service-oriented architecture, including both orchestration and choreography.

Figure 2 shows the description of a purchasing business process in BPMN (as proposed in [16]). There

are three roles – the Customer, the Broker, and the Bank – each one modeled by an orchestration. A choreography models their interactions.

When a customer launches the purchase process, as described in the Customer’s pool, first there is a decision based on the price of the article: if it is lower than a threshold (in that case € 1000), the customer pays cash; however, if it is equal or higher than € 1000, the customer will request the broker to find a bank with a low interest rate at that time. Once the customer gets

157

the reference of the bank from the broker, s/he will request a credit to that bank. The bank will then make a decision: to accept or reject the requested credit. The customer will handle the reply from the bank. In case the bank accepts, the customer will buy the article using the credit. In case it rejects, s/he declines the purchase.

Figure 2. Purchase process description in BPMN

The architecture of the system supporting the purchase process is dynamic: new banks can be registered with the broker during the execution of the system. Banks are dynamically found by the broker, and are thereby not known at design-time. The customer knows the broker at design-time and only knows the bank at run-time according to what was discovered by the broker. The binding between the customer and the broker is performed at design-time and between the customer and the bank at run-time, possibly with different banks for different purchases.

In terms of the service-oriented architecture style, the architecture is described by orchestrations and choreographies. In each role’s pool, an orchestration describes how different services are consumed to provide a more complex service and a choreography describes how the different roles dynamically interact to provide the overall business service.

For control flows in the orchestration, flow objects (events, activities, gateways), connecting objects (sequence flows, message flows), and swimlanes (pools) are used. For message flows in the choreography, the send and receive constructs are used.

Once the Business Process Model (BPM) is designed, the BPMN constructs used in the description (as shown in Figure 2) are translated to π-ADL for SOA by the recurrent application and composition of the mapping fragments presented in the Table 1. The resulting description is a formal specification of the

purchase process in π-ADL for SOA, which is then used to check its correctness, refine and generate the concrete implementation, e.g. in terms of WS-BPEL and WSDL.

5. Implementation and Experimentation

A major impetus behind developing formal

languages for architectural description is that their formality renders them suitable to be manipulated by software tools. The usefulness of an ADL is thereby directly related to the kinds of tools it provides to support architectural description, but also analysis, refinement, code generation, and evolution [14]. Indeed, π-ADL for SOA is supported by a comprehensive toolset for supporting service-oriented formal development.

By defining π-ADL for SOA as an embedded domain-specific language in π-ADL, it inherits from its core toolset and its customizable tools [14]. All tools supporting π-ADL for SOA are integrated using an XML-based interchange language and web services. This comprehensive toolset is partially available as Open Source Software.

π-ADL has been applied in practice in several software projects in France, Italy, UK, Switzerland, and China. In particular, different features of π-ADL for SOA and its supporting toolset have been applied at Thésame Inc. (France) for architecting and implementing an agile business process for wide-area supply-chain management. It is based on a service-oriented architecture and the web service technology stack, comprising BPMN, WS-BPEL and WSDL.

This experimentation has shown that π-ADL for SOA and its toolset are suitable for formally developing dynamic Web service compositions.

6. Related Work

Different ADLs have been proposed in the literature

[6], including: AADL, ACME/Dynamic-ACME, AESOP, AML, ARMANI, CHAM-ADL, DARWIN, KOALA, META-H/AADL, PADL, PLASTIK, RAPIDE, SADL, σπ-SPACE, UNICON-2, WEAVES, WRIGHT/Dynamic-WRIGHT, and ZETA.

Most of these ADLs assume that architectures are static. Some however supports the description of dynamic features of architectures. They are DARWIN, Dynamic-ACME, Dynamic-WRIGHT, KOALA, PLASTIK, RAPIDE, and WEAVES. But this support is rather limited, and in the case of Dynamic-ACME, PLASTIK and WEAVES, they are not formally defined. Overall, none of these ADLs have the expressive power to describe dynamic service-oriented

158

architectures where connection mobility is needed in order to model the dynamic discovery and invocation of new discovered services.

Unlike these other ADLs, the support provided by π-ADL for SOA is complete with respect to expressiveness of dynamic service-oriented architectures based on its underlying foundation, i.e. the typed π-calculus.

The focus of π-ADL for SOA is on the formal modeling of dynamic service-oriented architectures, and for supporting the computer-aided formal verification and refinement of these models. π-ADL for SOA introduces the notion of service and

service composition as first-class citizens in architecture descriptions, which is not the case of other ADLs. Service compositions in terms of service orchestration and service choreography are formally specified in terms of typed abstractions over behaviors.

7. Concluding Remarks

In this paper, we have presented π-ADL for SOA, a

service-oriented architecture description language for the formal development of service-oriented systems.

The use of BPMN as a visual notation for business process modeling assists in filling the gap between semi-formal process diagrams and formal service-oriented architecture descriptions, which can be analyzed and refined, by providing the ability to elaborate the architecture specification.

In addition, π-ADL for SOA can be used to bridge the gap between semi-formal languages such as BPMN and formal calculus of services such as COWS [4], SCC [1], or SOCK [3], themselves based on the π-calculus. The former provides computer support without formal semantics, the later formal semantics without computer support.

Future work is mainly related with the development of a service-oriented formal method built on [12].

References

[1] Boreale M. et al.: SCC: a Service Centered Calculus.

Proceedings of the 3rd International Workshop on Web Services and Formal Methods (WS-FM 2006), LNCS 4184, Springer, Vienna, Austria, September 2006.

[2] Chaudet C., Greenwood M., Oquendo F., Warboys B.: Architecture-Driven Software Engineering: Specifying, Generating, and Evolving Component-Based Software Systems. IEE Journal: Software Engineering, Vol. 147, No. 6, UK, December 2000.

[3] Guidi C., Lucchi R., Gorrieri R., Busi N., Zavattaro G.: SOCK: A Calculus for Service Oriented Computing. Proceedings of the 4th International Conference on Service Oriented Computing (ICSOC'06), LNCS 4294, Springer, Chicago, December 2006.

[4] Lapadula A., Pugliese R., Tiezzi F.: A Calculus for Orchestration of Web Services. Proceedings of the 16th European Symposium on Programming (ESOP'07), LNCS 4421, Springer, Braga, Portugal, March 2007.

[5] Marcos E., Cuesta C.E., Oquendo F. (Eds.): Special Issue: Software Architecture. International Journal of Cooperative Information Systems (IJCIS), Vol. 16, No. 3/4, September/December 2007.

[6] Medvidovic N., Taylor R.: A Framework for Classifying and Comparing Architecture Description Languages. IEEE Transactions on Software Engineering, 2000.

[7] Medvidovic N., Dashofy E., Taylor R.: Moving Architectural Description from Under the Technology Lamppost. Information and Software Technology, Vol. 49, No. 1, 2007.

[8] Milner R.: Communicating and Mobile Systems: The π-Calculus. Cambridge University Press, 1999.

[9] Morrison R., Balasubramaniam D., Oquendo F., Warboys B., Greenwood M.: An Active Architecture Approach to Dynamic Systems Co-evolution. Proceedings of the 1st European Conference on Software Architecture (ECSA’07), Madrid, Spain, September 2007.

[10] OMG: Business Process Modeling Notation Specification, OMG Final Adopted Specification, Ref. dtc/06-02-01, February 2006.

[11] Oquendo F.: π-ADL: An Architecture Description Language based on the Higher Order Typed π-Calculus for Specifying Dynamic and Mobile Software Architectures. ACM SIGSOFT Software Engineering Notes, Vol. 28, No. 8, USA, May 2004.

[12] Oquendo F.: π-Method: A Model-Driven Formal Method for Architecture-Centric Software Engineering. ACM SIGSOFT Software Engineering Notes, Vol. 31, No. 3, May 2006.

[13] Oquendo F.: Software Architectures. Encyclopedia of Computer Science and Information Systems, Vuibert, November 2006 (In French).

[14] Oquendo F., Warboys B., Morrison R., Dindeleux R., Gallo F., Garavel H., Occhipinti C.: ArchWare: Architecting Evolvable Software. LNCS 3047, Springer, May 2004.

[15] Pourraz F.: Diapason: An Architecture-Centric Formal Approach for the Evolutionary Composition of Web Services, PhD Thesis, University of Savoie, France, December 2007 (In French).

[16] Puhlmann F.: On the Application of a Theory for Mobile Systems to Business Process Management. PhD Thesis, University of Potsdam, Germany, 2007.

[17] van der Aalst W.M.P., ter Hofstede A.H.M., Dumas M.: Patterns of Process Modeling. In Process-Aware Information Systems: Bridging People and Software through Process Technology, Wiley & Sons, 2005.

159