Modeling of Service-Oriented Architecture: Integration of...

Modeling of Service-Oriented Architecture: Integrationof Business Process and Service Modeling

Petr Weiss∗

Department of Information SystemsFaculty of Information Technology

Brno University of TechnologyBožetechova 2, 612 66 Brno, Czech Republic

[email protected]

AbstractThis article addresses issues of the Service-Oriented Ar-chitecture Modeling (SOAM). SOAM comprises gather-ing requirements, analyzing the requirements to identifyservices and business processes, and finally implementingthe services and processes. It is a heterogeneous approachthat combines a number of well-established practices. Thekey question in SOAM is how to integrate these practicesto model a true service-oriented system with all its bene-fits and requirements.

The approach presented in this paper is a way to the inte-gration of Business Process Modeling and Service Model-ing. It is achieved by using a transformation method thattransforms business processes diagrams into services dia-grams. The generated service diagrams describe how theprocess is realized using services. Particularly, the methodtransforms diagrams modeled by means of the BusinessProcess Modeling Notation into a set of UML diagrams.Furthermore, the formal description of the transforma-tion is presented in this proposal. The principle of thetransformation method is demonstrated in a case study.

Categories and Subject DescriptorsH.1 [Models and Principles]: Miscellaneous; D.2.11[Software Engineering]: Software Architectures—Service-oriented architecture (SOA)

KeywordsService, Service-Oriented Architecture, Service-OrientedArchitecture Modeling, Business Process Modeling, Busi-ness/IT alignment, Business-to-IT Integration

∗Recommended by thesis supervisor:Assoc. Prof. Jaroslav ZendulkaDefended at Faculty of Information Technology, BrnoUniversity of Technology on December 13, 2010.

c© Copyright 2010. All rights reserved. Permission to make digitalor hard copies of part or all of this work for personal or classroom useis granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies show this notice onthe first page or initial screen of a display along with the full citation.Copyrights for components of this work owned by others than ACMmust be honored. Abstracting with credit is permitted. To copy other-wise, to republish, to post on servers, to redistribute to lists, or to useany component of this work in other works requires prior specific per-mission and/or a fee. Permissions may be requested from STU Press,Vazovova 5, 811 07 Bratislava, Slovakia.Weiss, P. Modeling of Service-Oriented Architecture: Integration. In-formation Sciences and Technologies Bulletin of the ACM Slovakia,Vol. 2, No. 2 (2010) 79-92

1. IntroductionNowadays, if a company wants to be profitable and suc-cessfully meet competition, it must effectively cooperatewith its business partners and it should be able to quicklyadapt to changes in the market. To follow this, it is nec-essary to have a well-designed infrastructure. More thanusually, a modern information system plays a significantrole in a particular company’s infrastructure.

Among modern information systems, Service-Oriented Ar-chitecture (SOA) is a complex solution for analysis, de-sign, maintaining and integration of enterprise applica-tions that are based on services. Services are autonomousplatform-independent entities that provide one or morefunctional capabilities via their interfaces. In other words,SOA is an architectural style for aligning business andIT architectures. It offers a framework for flexible andagile business processes while reducing the cost of appli-cation development and maintenance. For this reason,a number of well-known companies (e.g. IBM, HP, Ora-cle, Microsoft) have included SOA-based solutions to theirportfolio of offered products.

1.1 Objectives of this articleIt is obvious that services are the basic elements in theconcept of SOA. Each new service has to be designed tofulfill both business requirements and the fundamentalSOA properties such as loose coupling, service indepen-dence, stateless, and reusability. It means that Service-Oriented Architecture Modeling (SOAM) should focus notonly on design of services but also on modeling of busi-ness requirements. Unfortunately, these two techniquesare used at different levels of design of enterprise architec-tures. This implies that the designers of services, on theone hand, and the modelers of business processes, on theother hand, usually use different resources, methods, andtools. Therefore there arises a semantic gap between themodels of both groups. This gap prevents the IT special-ists from implementing business processes directly frombusiness process models created by business analysts.

This paper presents a possible way how to bridge thatsemantic gap. It introduces an approach for integrationof Business Process Modeling (BPM) with Service Mod-eling (SM). The approach is based on a technique thattransforms business process diagrams into models of aservice orchestration1. A particular service orchestration

1Service orchestration is a special form of collaboration

80 Weiss, P.: Modeling of Service-Oriented Architecture: Integration of Business Process and Service Modeling

represents the realization of a corresponding business pro-cess. To be more specific, the business process diagramsare modeled by means of the Business Process ModelingNotation (BPMN) and the service orchestration is mod-eled by means of the Unified Modeling Language (UML).Since UML models are widely understandable by IT im-plementers, the models produced by the transformationcan easily be used by implementers to create a particularimplementation of the given business process. Besides,a formal description of diagrams of business processes ispresented in this article. The description facilitates thespecification of the transformation process, and makes thespecification independent of languages that are used tomodel business processes.

2. Service-Oriented ArchitectureThe goal of this chapter is to shortly introduce the conceptof SOA and outline its basic aspects. In addition, theprinciples of services as fundamental SOA elements areexplained in this chapter.

SOA is not a concrete architecture it is something that“leads” to a concrete architecture. Hence, SOA is rathera paradigm than a standard. Thus, there are various def-initions of SOA, e.g. by OASIS (Organization for theAdvancement of Structured Information Standards) [14],Newcomer and Lomow [13], and by Erl [7]. Other defini-tions proposed by various industry experts can be foundin [10]. The definitions are more or less the same mean-ing. Mostly, they differ only in the point of view of theauthors. Generally, we can say that SOA is a style ofdesigning large distributed information systems based onautonomous, QoS-capable, vendor diverse, interoperable,discoverable and potentially reusable service. discover-able and potentially reusable services,

2.1 ServicesThis section explains the meaning of the term service. Asfor SOA, it is hard to find an exact definition of the termservice because so many definitions exist, e.g. by New-comer and Lomow [13], OASIS [14], and by Biebersteinet al. [5]. If I should summarize the definitions, I willsay that service is a mechanism to enable access to oneor more capabilities, which are accessible via service in-terfaces. The service interfaces hide the implementationfrom potential service consumers, i.e. they create an ab-straction of the service. Besides, services are providedby service providers. A service provider is responsible forproviding a service description of each service. The de-scription is based on service interfaces and it defines howto invoke a service and how to communicate with the ser-vice. Services communicate with their environment bymeans of messaging (see Figure 1).

In practice, SOA services are usually implemented as WebService. For more details see [12].

2.1.1 Principles of ServiceThis section shortly introduces basic principles of services[7], [27]:

• Services are reusable – The reusability ensures thateach service functionality will be implemented onlyonce and can be used repeatedly.

among services.

Figure 1: Basic concept of SOA

• Services share a formal contract – The contract (de-scription) defines how to communicate with a par-ticular service.

• Services are loosely coupled – The loose coupling isa concept of minimizing dependencies. This leadsto better flexibility.

• Services abstract underlying logic – Services act asblack boxes, i.e. they hide their details from outsideworld and are accessible only via their interfaces.

• Services are composable – Composability is based onthe fact that services can be used by other services.Composability can be simply understood as anotherform of reuse because a particular service can act inseveral compositions.

• Services are autonomous – Services have control overthe logic they encapsulate. This supports the otherprinciples, such as loosely coupling.

• Services are stateless – A stateless service is a ser-vice that does not maintain any state informationbetween different service calls. It means that afterthe service call is over, all local information that hasbeen created temporarily for that call at the serviceside is thrown away.

From the above-mentioned follows that the key elementsof SOA are services. To clarify their roles in SOA, this sec-tion presents SOA as a partially layered architecture. Fordetails see Figure 2. In the figure, SOA consists of threeabstract layers (application layer, service layer and busi-ness process layer) and two sections in parallel with theselayers (integration layer and controlling layer). Each ofthese layers is introduced individually in the followingsub-sections.

Application LayerThe Application layer consists of existing custom built ap-plications, sometimes referred to as legacy systems. Suchsystems can be decomposed into smaller fragments – com-ponents. Components are the basic building blocks of ser-vices

Service LayerThe service layer is located between the business processand application layer. This is where the services thatparticipate in realizations of business processes reside.The variety of business functionality is enormous, andservices serve very different purposes and play differentroles. Therefore, within this layer, three other abstractlayers can be identified. These sub-layers divide servicesinto three categories:

Information Sciences and Technologies Bulletin of the ACM Slovakia, Vol. 2, No. 2 (2010) 79-92 81

Figure 2: SOA as a partially layered architecture

• Application services – These services encapsulateplatform-specific aspects and implementation detailsfrom the outside world are intended to provide tech-nology specific functionality.

• Business services – These services represent businesslogic. Business services act as controllers to com-pose available application services to execute theirbusiness logic.

• Process services — Process services allow us to di-rectly link process logic to service interactions. Itmeans that process services compose business ser-vices, in order to execute a process.

Business Process LayerThis layer provides the business logic. The logic is gen-erally expressed in the form of business processes. In thecontext of SOA, a business process is implemented as asequence of services, usually as a sequence of process ser-vices which orchestrate business services. Hence, from theIT point of view, realizations of business processes can beconsidered as long-term running applications.

Integration and ControllingThese layers enable the integration of services, providetechniques and tools required to monitor, manage, andmaintain quality of services, security, performance, andavailability.

3. Related workThe aim of this chapter is to present the current state inthe area of integration of business process modeling andmodeling of target IT architectures, modeling of services,and related issues of BPM.

3.1 UML Profiles for SOAThe first profile is from Amir and Zeid [2]. They intro-duce a simple UML profile that is intended to use formodeling of web services. Next profile for web servicescan be found in [21]. The profile is intended to enablevisually-oriented design of web services’ contracts. Forthis purpose, a number of various UML stereotypes areintroduced. Then, each WSDL element is represented bythe corresponding UML stereotype. Next, an advancedprofile is presented by Johnston [8]. The profile is definedby means of UML 2.0 and can be used in different stagesof the development lifecycle of a service-oriented solution.Rao [22] introduces Reference Architecture of SOA-basedsystems. The author identifies six fundamental typesof services that may collaborate in a particular system.

Moreover, the author provides a way how to model therelation among services and underlying components. Fi-nally, the SENSORIA project [9] adds an advanced SOAsupport to the UML by means of its UML4SOA profile.The profile is based on a meta-model of SOA and it is pri-marily intended to model both structural and behavioralaspects of service orchestrations.

All the above mentioned profiles are a good starting pointto model both the structural and the behavioral proper-ties of services by means of UML. But, most of them areeither too platform-specific ([2], [21]) or do not provide therelation to business requirements ([8], [22]), which mustbe taken into account when we model services. However,I used the knowledge gained by the study of those pro-files to create a framework for modeling of services whichis proposed in Section 4.2.

3.2 BPEL and BPMNIn the field of BPM, there are two fundamental modelinglanguages, BPEL2 and BPMN3. Both of them have theiropponents and followers. Thus, the way of using them isa frequently discussed topic.

The primary difference between BPEL and BPMN is thatBPMN is a modeling standard while BPEL is an executionstandard. Therefore, it is more than difficult to use BPELin the target domain of BPMN and vice versa. Otherdifferences between BPEL and BPMN are discussed in[26].

3.3 Bridging the Gap between Business and ITThis section brings a short overview of the current statein the area of bridging the gap between business and ITin general. Subsequently, integration of BPM and SM isintroduced as a particular way how to bridge the gap. Atlast, existing approaches in the field of the BPM-to-SMintegration are discussed.

3.3.1 The Current StateCurrently, the need of an alignment between businessneeds and IT capabilities is a frequently discussed topicin both academic and industrial environment. In 2009,a group of SOA experts introduced a SOA Manifesto[1]. This manifesto highlights six business values thatare brought by using SOA and 14 guiding principles de-scribing how a SOA-based system should be build. One ofthe principles is directly related to the need of the Busi-ness/IT alignment:

Verify that services satisfy business requirements and goals.

Besides, there exist other groups of SOA developers deal-ing with the issue of bridging the gap between businessand IT. For example, the SOA Consortium [6], or theBusiness Ecology Initiative [32]. Next, the importance ofbringing Business Process Management and SOA togetheris also stressed in [28]. The author explains why the rela-tionship between Business Process Management and SOA

2BPEL is provided as an OASIS standard for designingand running business processes [15].3The Business Process Modeling Notation (BPMN) is astandard for capturing business processes in the earlyphases of systems development, which is now managedby the Object Management Group (OMG) [18].


should not be considered as competitive one. More par-ticularly, the author presents several reasons why to useboth Business Process Management and SOA in order toproduce maximal business value.

3.3.2 Integration of BPM and SMModels of business processes are traditionally used tospecify how things must/should/could be done in orderto fulfill given business goals that produce a “businessvalue”. It is more or less clear that the real business valueis delivered through the execution of a particular busi-ness process. To execute a business process, the modelof the process can directly be run in a workflow basedruntime platform or the model can be transformed into a“solution model”that represents a particular realization ofthe process. Such transformation enables using of exist-ing solutions, which increases the level of reuse, facilitateschanges, and leads to better performance, scalability, andsecurity. Of course, the solution model must be imple-mented afterwards in order to execute the process.

The next section presents existing approaches that dealwith the possibility of realization of business processesthrough the integration of business process modeling withmodeling of target IT solutions, especially with servicemodeling.

3.3.3 Realization of Business Processes through theIntegration of BPM and SM

The idea of a transformation that produces service-basedsolution models from models of business processes was ini-tially introduced by Amsden in [3]. The author presentsan approach called business services modeling. The ap-proach describes a high-level mapping of a business pro-cesses to a corresponding Business Service Model (BSM).More precisely, each BSM shows a particular business pro-cess as a UML 2.0 collaboration that specifies the par-ticipants in the processes and what they are responsiblefor. Although the author of [3] presents a mapping be-tween a business process model and the correspondingUML BSM in an example, the mapping process is notclear, because most of the transformation is done by IBMmodeling tools. Consequently, Amsden [4] presented aseries of five articles about developing software based onSOA. The approach presented in the series is similar tothe one presented in my paper. The author focuses onrealization of business processes. For this purpose, heintroduces a method that transforms models of businessprocesses into service-based models that represent real-ization of the business processes. Similarly as in [3], theauthor demonstrates the approach through an ad hoc ex-ample. However, the way of decomposing the input busi-ness process is not clear and a relatively large portion ofthe principle is hidden by using of various IBM modelingtools. Moreover, some services are designed in such a waythat they do not meet fundamental SOA principles (e.g.stateless, see Section 2.1.1). In a nutshell, no systemat-ical method how to transform business process diagramsis presented. So, it is more than debatable whether theapproach can be successfully applied to any business pro-cess.

My approach solves the above mentioned problems of [3]and [4]. See Chapter 5 for results. Following proposalsare focused on various transformation of BPMN. An auto-matic translation from BPMN diagrams to human read-

able BPEL code was proposed in [19] and [20]. The au-thors of those proposals formally define a subset of BPMNdue to unclear semantic in the specification. Using thatformalism, they present a systematical approach for de-composing business process models based of workflow pat-terns. Unfortunately, the subset of BPMN is too small tocover common business cases. The elements representingroles, messages, data artifacts and some types of tasksand events are missing in the subset. In this article, [19],and [21] are used to establish a formal basis of BPMN.

3.4 Related Topics in the Field of BPMIn order to create a method that transforms business pro-cess diagrams, it was necessary to be acquainted withthe issues of BPM. The following proposals gave me therequired knowledge. First of all, [24] and [25] must bementioned. These two proposals laid the foundations ofpattern-based modeling of workflow processes. Their au-thors brought a detailed analysis of 26 workflow patterns.These patterns were designed independently of currentworkflow languages. The use of them in various workflowtools is discussed in those papers. Murzek and Kramler[11] deal with transformation of business process mod-els between several modeling languages. The authors de-scribe the ambiguity of models arising from the transfor-mation between different modeling languages. Based onthis, they discuss most stressing model transformation is-sues, e.g. decision (un)ambiguity, different start objects,split/merge unambiguity, and different final nodes.

4. Transformation of Business Process Diagramsinto Models of Service Orchestration

This section describes how to transform a business pro-cess that is modeled by means of BPMN into a corre-sponding service orchestration that realizes the businessprocess. Before we start with the transformation processitself, the theoretical background of the transformationmust be introduced. The transformation process is thendescribed in Section 4.4.

4.1 Formal Description of the TransformationThis section provides a formal approach to describe BPMNdiagrams. In the transformation process, the formal de-scription of BPMN diagrams is used to identify and reduceworkflow patterns. BPMN is a language with a graphicalnotation, it means that the BPMN standard (v1.4) pro-vides a set of graphical elements and defines how to linkthese elements in order to create a diagram (i.e. a modelof a business process). However, the standard does notdefine any semantics or formal description of the syntax.Therefore, a systematical processing of BPMN diagramscan be quite difficult without any formal description oftheir structure.

This section gives a formal description of BPMN dia-grams. The definitions presented in this section are in-spired by [21] (see Section 5.1 for the details about therelation between [20] and this article).

Definition 1. An Extended Core BPD of a BP modeledby means of BPMN is a tuple BPD = (O, E, G, A, T, TR,TSI, TSP, TSE, TU, ES, ESN, ESM, EST, EI, EIM, EIMT,EIMC, EIT, EIE, EIMCE, EITE, EIEE, EE, EEN, EEM, GF,GJ, GX, GM, GV, F, P, L, M, D, DM, DT, DTI, DTO,DPI, DPO, Datingmsg, Datingin, Datingout, Cond, Excp,


Pooling, Lining, Roling), shortly only P = (O, F, P, L, M,D, Dating, Cond, Excp, Pooling, Lining, Roling) with:

• O is a set of objects, which can be partitioned intodisjoint sets of activities A, events E, and gatewaysG,

• A can be partitioned into disjoint sets of tasks Tand sub-processes TSP,

• T can be partitioned into disjoint sets of receivetasks TR, send tasks TS, service invocation tasksTSI, script execution tasks TSE and undefined tasksTU,

• E can be partitioned into disjoint sets of start eventsES, intermediate events EI, and end events EE,

• ES can be partitioned into disjoint sets of unde-fined start events ESN, message start events ESM

and timer start events EST,

• EE can be partitioned into disjoint sets of undefinedend events EEN and message end events EEM,

• EI can be partitioned into disjoint sets of messageintermediate events EIM (EIM can be partitionedinto disjoint sets of throw message intermediate eventsEIMT and catch message intermediate events EIMC),timer intermediate events EIT, and error interme-diate events EIE,

• EIMCE ⊆ EIMC is a set of exception catch messageintermediate events,

• EITE

⊆ EIT is a of exception timer intermediateevents,

• EIEE ⊆ EIE is a set of exception error intermediateevents,

• G can be partitioned into disjoint sets of parallel forkgateways GF, parallel join gateways GJ, data-basedXOR decision gateways GX, event-based XOR de-cision gateways GV, and XOR merge gateways GM

(note that XOR means choose M from N possibili-ties),

• F ⊆ O × O is the control flow relation, i.e. a set ofcontrol flows connecting objects,

• P is a set of pools,

• L is a set of lanes,

• M ⊆ (P ∪ TSI ∪ TSP ∪ TS ∪ EIMT ∪ EEM) × (P ∪TSI ∪ TSP ∪ TR ∪ EIMC ∪ ESM) is a message flowrelation, i.e. a set of message flows between pools,tasks and intermediate message events,

• Msource = P ∪ TSI ∪ TSP ∪ TS ∪ EIMT ∪ EEM is aset of source nodes of the message flow relation,

• Mtarget = P ∪ TSI ∪ TSP ∪ TR ∪ EIMC ∪ ESM is aset of target nodes of the message flow relation,

• in short M ⊆ Msource × Mtarget,

• Cond: F ∩ (GX × O) −→ C is a injective function,which maps sequence flows emanating from data-based XOR gateways to a set of boolean conditionsC,

• Excp: (EIMCE ∪ EITE ∪ EIEE ) −→ A is a surjec-tive function assigning each exception intermediateevent to an activity such that the occurrence of theevent signals an exception and thus interrupts theperformance of the task,

• Pooling: O−→ P is a non-injective and non-surjectivefunction assigning each object to a pool such thatthe pool contains the object,

• Lining: O−→ L is a non-injective and non-surjectivefunction assigning each object to a lane such thatthe lane contains the object,

• Roling: L−→ P is a non-injective and non-surjectivefunction assigning each lane to a pool such that thelane represents a role within the pool,

• D is a set of data objects, which can be partitionedinto disjoint sets of message data objects DM andtask data objects DT,

• DTI ⊆ DT is a set of input task data objects,

• DTO ⊆ DT is a set of output task data objects,

• Datingmsg: DM −→ M \ ( (P ∪ EIMT ∪ EEM) × (P∪ EIMC ∪ ESM) ) is an injective function assigningeach message data object to a message flow, whoseset of sources is restricted to TSP ∪ TSI ∪ TS andthe set of target to TSI ∪ TSP ∪ TR,

• Datingin: DTI −→ (TSP ∪ TSI ∪ TSE ∪ TS) is anon-injective and non-surjective function assigningeach input task data object to a task such that thetask consumes the data object,

• Datingout: DTO −→ (TSP ∪ TSI ∪ TSE ∪ TR) is anon-injective and non-surjective function assigningeach output data object to a task such that the taskproduces the data object,

• DPI = DTI \ DTO is a set of input process param-eters, i.e. a set of input task data objects that arenot produced by any tasks,

• DPO = DTO \ DTI is a set of output process param-eters, i.e. a set of output task data objects that arenot consumed by any tasks.

The relation F defines a directed graph with nodes (ob-jects) O and arcs (control flows) F. For any node x ∈ O,input nodes of x are given by in(x) = {y ∈ O | yFx} andoutput nodes of x are given by out(x) = {y ∈ O | xFy}.Definition 1 allows for graphs that do not have start orend events, contain objects without any input and outputor with multiple input/output, etc. Therefore, the defini-tion needs to be restricted to Well-formed Extended CoreBPD. Some parts of the BPMN standard allow for un-connected elements (e.g. can be easily transformed intoa Well-Formed Extended Core BPD [11]. The definitionof a Well-formed BPD contains also some restrictions onthe message flow relation and to the data objects.

Definition 2. An extended core BPD in Definition 1 isa Well-Formed Extended Core BPD iff:

• | P | > 1, | L | > 1, there is at least one pool withat least one lane in the BPD,


• ∀s ∈ ES ∪ dom(Excp): in(s) = ∅ ∧ | out(s) | = 1, i.e.start events and exception events have an indegreeof zero and an outdegree of one,

• ∀e ∈ EE: out(e) = ∅ ∧ | in(e) | = 1, i.e., end eventshave an outdegree of zero and an indegree of one,

• ∀x ∈ A ∪ (EI \ dom(Excp)): | in(x) | = 1 and |out(x) | = 1, i.e. activities and non-exception in-termediate events have an indegree of one and anoutdegree of one,

• ∀g ∈ GF ∪ GX ∪ GV: | in(g) | = 1 ∧ | out(g) | >1, i.e. fork or decision gateways have an indegree ofone and an outdegree of more than one,

• ∀g ∈ GJ ∪ GM: | out(g) | = 1 ∧ | in(g) | > 1, i.e. joinor merge gateways have an outdegree of one and anindegree of more than one,

• ∀g ∈ GV: out(g) ⊆ ( EI \(EIMT ∪ dom(Excp) ) ∪TR, i.e. event-based XOR decision gateways mustbe followed by intermediate message or timer eventsor receive tasks,

• ∀g ∈ GX: ∃ an order <g, which is a strict total orderover the set of flows {g} × out(g) and ∃x ∈ out(g)

such that An∃f ∈{g} × out(g) ((g, x) <g f), i.e. (g,x) is the default flow among all the outgoing flowsfrom g,

• ∀x ∈ O: ∃s ∈ ES ∪ dom(Excp): ∃e ∈ EE: sF*x ∧xF*e, i.e. every object is on a path from a startevent or an exception event to an end event,

• ∀f = (x, y) ∈ F: ( (Pooling(x) = p1) ∧ (Pooling(y)= p2) )⇒ (p1 = p2), i.e. a control flow can connectonly objects from the same pool,

• ∀x, y ∈ O: ( ((x 6= y) ∧ (Pooling(x) = Poling(y)))⇒ (xF+y) ), i.e. within a pool, there is only onepath and all contained objects are on this path,

• ∀x ∈ O: ( Roling(Lining(x)) = Pooling(x) ), i.e. allobjects from a lane belong to the pool that the lanebelongs to,

• ∀x, y ∈ O: ( (x 6= y) ∧ (Lining(x) = Lining(y)) ⇒(∃p ∈ P: (Pooling(x) = p) ∧ (Pooling(y) = p)) ),i.e. a lane can contain objects only from the samepool,

• M is irreflexive and:

– ∀m = (x, y) ∈M ∩ ( (Msource \ P)× (Mtarget \P) ): ( (Pooling(x) = p1) ∧ (Pooling(y) = p2) )⇒ ( p1 6= p2 ), i. e. a message flow can connecttwo objects only from different pools,

– ∀m = (x, y) ∈ M ∩ ( (Msource \ P) × P ):∀o ∈ O: Pooling(o) 6= y, i.e. a message flowcan connect objects from a pool to an abstractpool,

– ∀m = (x, y) ∈ M ∩ ( P × (Mtarget \ P) ):∀o ∈ O: Pooling(o) 6= x, i.e. a message flowcan connect an abstract pool to an object fromanother pool,

– ∀m = (x, y) ∈ M ∩ (P × P): ∀o ∈ O: (Pool-ing(o) 6= y) ∧ (Pooling(o) 6= x), i.e. a messageflow can connect two different abstract pools,

– ∀x ∈ (EE ∪ EIMT): | (⋃

y ∈ Mtarget (x, y) ∈M | ≤ 1, i.e. each throw message intermediateevent or end event can be a source of at mostone message flow,

– ∀y ∈ (ES ∪ EIMC): | (⋃

x ∈ Msource (x, y) ∈M | ≤ 1, i.e. each catch message intermediateevent or start event can be a target of at mostone message flow,

• DT \ (DTI ∪ DTO) = ∅, i.e. the set of all task dataobjects (DT) contains only input task data objects(DTI) and output task data objects (DTO),

• ∀d ∈ DT: (d ∈ dom(Datingout) ∩ dom(Datingin))⇒ ( Pooling(Datingin(d)) = Pooling(Datingout(d))), i.e. tasks that produce and consume the samedata object must belong to the same pool.

In order to analyze a BPD, we have to decompose it into aset of fragments (called as graph components), which referto subsets of the BPD. A graph component is a subsetof a BPD that has one entry point and one exit point.Before identifying patterns, it is necessary to formalize thenotion of graph components in a BPD. To formulate thedefinitions, I use an auxiliary function elt over a domainof singletons, i.e. if X = {x}, then elt(X) = x.

Definition 3. Let BPD = (O, F, P, M, D, Dating, Cond,Excp, Pooling, Lining, Roling) be a well-formed extendedcore BPD. A subset of BPD, as given by C = (OC, FC,CondC), is a Graph Component iff:

• OC ⊆ O \ (ES ∪ EE), i.e. a graph component doesnot contain any start or end event,

• | (⋃

x∈OC in(x)) \ OC | = 1, i.e. there is a singleentry point into the graph component, which can bedenoted as entry(C) = elt( (

⋃x∈OC in(x)) \ OC ),

the entry point does not belong to the graph com-ponent,

• | (⋃

x∈OC out(x)) \ OC | = 1, i.e., there is a singleexit point out of the graph component, which can bedenoted as exit(C) = elt((

⋃x∈OC out(x))\OC), the

exit point does not belong to the graph component,

• there exists a unique source object iC ∈ OC and aunique sink object oC ∈ OC and iC 6= oC, such thatentry(C) ∈ in(iC) and exit(C) ∈ out(oC),

• FC = F ∩ (OC × OC),

• CondC = Cond[FC], i.e., the Cond function wherethe domain is restricted to FC.

The decomposition of a BPD helps to define an iterativeapproach, which allows us to incrementally transform the“componentised” BPD into UML diagrams. Below, I de-fine the function Fold that replaces a graph component bya single task object in a BPD. This function can be usedto perform iterative reduction of a componentised BPDuntil no graph component is left in the BPD.

Definition 4. Let BPD = (O, F, P, M, D, Dating, Cond,Excp, Pooling, Lining, Roling) be a well-formed extended


core BPD and C = (OC, FC, CondC) be a graph compo-nent. The function Fold replaces C in BPD by a blanktask object tC /∈ O, i.e., Fold(BPD, C, tC) = BPD’ = (O’,F’, P’, M’, D’, Dating’, Cond’, Excp’, Pooling’, Lining’,Roling’) with:

• O’ = (O \ OC) ∪ {tC},

• TC is the set of tasks in C, i.e., TC = OC ∩ T,

• TU’ = (TU \ TC ) ∪ {tC}, is the set of undefinedtasks in BPD’, i.e. tC is a undefined task,

• F’ = (F ∩ ((O \ OC) × (O \ OC))) ∪ {(entry(C),tC ), (tC , exit(C))},

• Cond’ =

Cond[F’] . . . . . . if entry(C) /∈ GD

Cond[F’] ∪ ((entry(C), tC,Cond(entry(C), iC)) . . . . . . otherwise

• P’ = P,

• Pooling’ = Pooling[O \ OC] ∪ {(tC, Pooling(oC))},for any oC ∈ OC,

• Roling’ = Roling,

• Lining’ = Lining[O \ OC] ∪ {(tC, l)}, for any l ∈ L,

• let MsourceC = Msource \ (OC ∩ Msource) and Mtarget

C

= Mtarget \ (OC ∩ Mtarget) then

• M’ = M \ ((MsourceC ×Mtarget) ∪ (Msource ×Mtarget

C )),i.e. after application of the Fold function, the dia-gram contains only message flows that do not startor end in an object that belongs to the graph com-ponent,

• Datingin’ = Datingin[DTI \ {e: e ∈DTI ∧Datingin(e)∈ OC ∩ (TSP ∪ TSI ∪ TSE ∪ TS)}],

• Datingout’= Datingout[DTO \ {f: f ∈ DTO ∧Datingout(f) ∈ OC ∩ (TSP ∪ TSI ∪ TSE ∪ TR)}],

• D’ = D \ ({d: d ∈ DM ∧ Datingmsg(d) ∈ ((MsourceC

× Mtarget) ∪ (Msource × MtargetC ))} ∪ {g: g ∈ DTI

∧ Datingin(g) ∈ OC ∩ (TSP ∪ TSI ∪ TSE ∪ TS)} ∪{h: h ∈ DTO ∧ Datingout(h) ∈ OC ∩ (TSP ∪ TSI

∪ TSE ∪ TR)}), i.e. if a data object is associatedwith a message flow that starts or ends in an ob-ject that belongs to the graph component, the dataobject do not belong to the set of data objects ofthe diagram that raised by the application of theFold function. Similarly, data objects that are in-put or output parameters of a task that belongs tothe graph component do not belongs to BPD’.

• Excp’ = Excp[(EIMCE ∪ EITE ∪ EIEE ) \ (OC ∩(EIMCE ∪ EITE ∪ EIEE ))].

Definition 5. Let BPD = (O, F, P, M, D, Dating, Cond,Excp, Pooling, Lining, Roling) be a well-formed extendedcore BPD and C = (OC, FC, CondC) be a graph compo-nent. The following graph components are identified asWell-Structured Patterns:

1. C is defined as a Sequence Pattern iff OC ⊆ A andentry(C) /∈ GV. C is a Maximal Sequence Patterniff C is a sequence-pattern and there is no othersequence-pattern C’ such that O’C ⊂ OC where O’Cis the set of objects in C’.

2. C is defined as a Parallel Pattern iff:

• iC ∈ GF ∧ oC ∈ GJ,

• OC ⊆ A ∪ (EI \dom(Excp)) ∪ {iC, oC},

• ∀x ∈OC \{iC, oC}: in(x)={iC} ∧ out(x)={oC}.

3. C is identified as a Switch Pattern iff:

• iC ∈ GD ∧ oC ∈ GM,

• OC ⊆ A ∪ (EI \dom(Excp)) ∪ {iC, oC},

• ∀x ∈ OC\{iC, oC}, in(x)={iC} ∧ out(x)={oC}.

4. C is identified as a While Pattern iff:

• iC ∈GM ∧ oC ∈GD ∧ x ∈A ∪ (EI \dom(Excp)),

• OC = {iC, oC, x},

• FC = {(iC, oC), (oC, x), (x, iC)}.

5. C is identified as a Repeat Pattern iff:

• iC ∈GM ∧ oC ∈GD ∧ x ∈A ∪ (EI \dom(Excp)),

• OC = {iC, oC, x},

• FC = {(iC, x), (x, oC), (oC, iC)}.

4.2 Primitive and Composite ServicesIn my approach, I use two types of services: primitiveservices and composite services. Each primitive service isderived from a service invocation task, and it is respon-sible for providing functional capabilities defined by thetask. A composite service is an access point to an or-chestration of other primitive or composite services. Theidea of primitive and composite services along with theway how services are modeled by means of UML, whichis described in the next section, forms a framework formodeling of services.

4.3 Model of a ServiceIn this paper, each service is modeled as a stereotype ser-vice that extends the UML class Component [17]. Thisconcept was initially introduced in [30] and [23]. Each ser-vice is characterized by a unique specification. The servicespecification describes the behavior and the architecture ofa particular service and defines a communication protocolof the service.

The behavior describes which actions are executed whenan operation of the service is invoked, and the architec-ture includes definition of ports and interfaces. The com-munication protocol specifies in which order a particularservice must send/receive messages, i.e. how a consumershould communicate with the service, in order to success-fully fulfill its role in a particular orchestration.

4.4 Transformation RulesThe core of the transformation is described in Figure 3 to6. Each figure depicts a transformation table. Each rowof a particular table represents a transformation rule. Forbetter readability, the transformation rules are expressedin the graphical form using the BPMN and UML notation.Each rule defines how to transform a workflow pattern(eventually a basic BPMN element) into a UML-basedservice specification. Each specification has three parts:


• Service structure. It is modeled by means of UMLcomponent diagrams. To be more specific, the struc-ture is described by two component diagrams. Thefirst one depicts the service topology by means ofUML packages and the other one depicts how ser-vices are connected to each other in a service orches-tration.

• Communication rules. These are defined by meansof an UML sequence diagram.

• Description of the behavior (an UML activity dia-gram).

Some rules include context information that is needed tounderstand the use of the rule. For this purpose, elementsthat are newly created according to a particular rule areinserted into a red-line-bordered area. If nothing is high-lighted, all depicted elements are considered to be newlycreated, unless otherwise stated. Note that some patternscan be transformed more than one way (see e.g. Figure4, Rule 5).

4.4.1 Transformation Rules for Basic ElementsThe transformation rules for basic BPD elements are de-picted in Figure 3. The transformation table containesrules for swimlanes (Rules 1,2 ), start events (Rule 3),sub-processes (Rule 4a) and tasks (Rules 4b,c).

4.4.2 Transformation Rules for Sequence PatternsIn Figure 4 it is shown how to transform Sequence pat-terns. Rules 5a to 5c define the transformation of twoservice invocation tasks. The transformation can be donein three different ways. Generally, the first rule (5a) isusually used if we need to create a new standalone ser-vice. The second rule (5b) is used if we need to controlthe primitive services for a reason, i.e. because of QoSor security issues. If we want to use an existing servicewith only some modifications of its functionality, we canapply the third (5c) rule. Rule 5d can be used when wetransform a script execution task.

4.4.3 Transformation Rules for Parallel and SwitchPatterns

Next, the transformation rules for Branching Patterns aredepicted in Figure 5. Branching patterns include Parallelbranching pattern (Rule 6a) and Switch pattern (Rule6b). The principle of these patterns is described in [24].

4.4.4 Transformation Rules for Cycle PatternsIn Figure 6 it is shown how to transform Repeat Patterns(Rule 7a) and While Patterns (Rule 7b).

4.5 Example of TransformationThis section gives an ad hoc example, in which the basicidea of the transformation is demonstrated. The exampleis primarily intended to explain several concepts which arerelated to the subject of the transformation. It means thatthe example provides no sequence of transformation ruleswhich were applied during the transformation. It providesonly the input BPD and the output service orchestration.

Figure 7 depicts an exemplary “Purchase Order” businessprocess. The example is adopted from [16]. The pro-cess starts by receiving a purchase order message. Sub-sequently, the “Invoicing” role calculates an initial price.

This price is not yet complete, because the total pricedepends on where the products are produced and theamount of the shipping cost. In parallel, the “Schedul-ing” role determines when the products will be availableand from what locations. At the same time, the shippinginformation is updated and the process requests shippingfrom the “Shipping” role. Afterwards, “Shipping” waitsfor a shipping schedule to be sent from “Scheduling”. Assoon as the shipping information is known, the completeprice can be calculated. Finally, when the complete priceis available and shipping is ensured, the invoice can becompleted and sent to the customer. The process endswhen the schedule is processed.

In this example, I assume that following tasks were iden-tified as service invocation tasks: “Initiate Price Calcula-tion”, “Complete Price Calculation”, “Request Shipping”,“Request Production Scheduling” and “Send ShippingSchedule”. The remaining tasks are script execution tasks.

The orchestration that can be generated from the diagramin Figure 7 is depicted in Figure 8. The orchestration iscomposed of two composite and four primitive services.The PurchaseOrder service is one of the composite ser-vices and it represents the business process itself. Thisservice orchestrates the rest of remaining services. Thebehavior of PurchaseOrder is depicted in Figure 9.

This example is used in following sections in order to ex-plain the principle of asynchronous services, passing ofdata and stateless services.

4.6 Asynchronous ServicesIn my approach, each service that enables asynchronouscommunication must implement an auxiliary interface thatprovides a method to accept replies to asynchronous calls.In Figure 8, we can also see that the PurchaseOrder ser-vice provides the AsyncReply interface at its consumerport for this purpose.

4.7 Stateless ServicesThe other characteristic feature of my approach is the re-striction on services’ interfaces to provide only one servicefunctionality. Regardless, it is possible to implement ser-vices with more interfaces (i.e. with more functional ca-pabilities), but the interfaces must provide independentfunctionality (see the PriceCalculation service in Fig-ure 8). It means that services are not allowed to hold anystate information between two independent incoming re-quests, in spite of which interface the service was invokedon. This leads to stateless services. Although statelessservices provide better reusability I must cope with theissue of holding states of services that are participating inthe orchestration in relation with the state of the parentcomposite service. This is explained in the next section.

4.8 Passing of Data between ServicesGenerally, every composite service is responsible for keep-ing its subordinate services independent and stateless.This is achieved by forwarding state information betweenparticular invocations of any subordinate service via thecomposite service. It means that the service that realizesa process changes its state instead of services that im-plements functional capabilities of particular tasks. Themerit of such design is the independence of requested ser-vices, although they share data and states.


Figure 3: Transformation rules for basic elements


Figure 4: Transformation rules for Sequence patterns

Figure 5: Transformation rules for Branching Patterns


Figure 6: Transformation rules for Sequence patterns

Figure 7: Business process model of the “Purchase Order” process [16]

Figure 8: The derived service orchestration


Figure 9: Behavior of the service orchestration

5. Results5.1 Comparison with Other ApproachesAmsden [3] initially introduces the idea of how to bridgethe semantic gap between business requirements and thearchitecture of IT solutions that are intended to meetthem. The principles described in that proposal are notmuch detailed but they were a good starting point for theprocess of establishing the transformation rules describedin Section 4.4.

Next, Amsden presents a similar concept to this in [4].However, the concept is incomplete, sometimes unclearand suffers from several shortcomings. The most seriousproblem of that proposal is that no systematic approachis presented – the whole transformation process is demon-strated in an ad hoc example. Next, some services are de-signed in such a way that they store data affecting theirfunctionality between two single incoming requests, whichcontrasts with one of the fundamental SOA principles –stateless.

On the other side, my approach can be applied to a real-world business process Moreover, the proposed frameworkfor modeling of services (see Section 4.2 and 4.6 – 4.8) en-sures that generated services will have the following prop-erties:

• Abstraction is achieved by means of interfaces;

• Reusability results from using the flat model andcomposite services;

• Stateless is supported by the concept of compositeservices;

• Extensibility is based on using ports and indepen-dent interfaces.

Concerning the formal approaches, [20] and [19] proposea formalism that can be used to decompose a BPD and,consequently, transform it into BPEL code. The majorshortcoming of [20] and [19] is that the set of modelingelements that are covered by these proposals is too small.To be able to model common business cases, my paperextends the original set to include the following elements:

• sub-processes, service invocation tasks, script tasks,receive tasks, send tasks,

• pools, swimlanes,

• data objects,

• message flows,

• start message events, end message events, throwmessage intermediate events, and catch message in-termediate events.

5.2 Main ContributionConsidering the above presented comparison, the follow-ing merits of my approach could be summarized.

• The approach transforms models that describe ac-tivities and requirements into models that describearchitecture and behavior of a particular solution.

• The transformation algorithm can be implementedin any programming language and regardless of a par-ticular software development tool. Input/output di-agrams can be specified by use of any type of graph-ical or textual notation. The only restriction here


is that a BPMN diagram that inputs the transfor-mation must meet the formal definition of businessprocess diagrams given in Section 4.1.

• The generated service models can be implementedusing various technologies. As already mentioned,Web Services (WS) are one of the suitable technolo-gies for implementing SOA services. In order to useWS, the generated service diagrams must be trans-formed into corresponding WS models.

• The proposed framework for modeling of servicesenables to integrate structural models of serviceswith models of SOA-lower-level elements, especiallycomponents, which are responsible for performingservice functionalities.

6. Conclusion and Future WorkTo conclude, this paper deals with Service-Oriented Ar-chitecture Modeling, especially with the integration ofBusiness Process Modeling and Service Modeling. Forthis purpose, an approach that supports the integrationhas been proposed. The approach is based on a trans-formation technique that defines how a business processmodel should be transformed into a model of service or-chestration and how services should collaborate within theorchestration in order to fulfill the business goals speci-fied in the business process model. More precisely, theproposed approach includes an UML framework for mod-eling of services, formal specifications of BPMN diagramsand service orchestrations and, finally, a set of transfor-mation rules based on workflow patterns. Some of thosefeatures are novel and have not been integrated into theexisting methods of modeling of SOA.

The ongoing research should be focused primarily on twoareas, to improve the proposed approach by adding newfeatures and to eliminate possible drawbacks of the ap-proach. For example, additional transformation rulescould be created in order to support more workflow pat-terns (e.g. transformation rules for control-flow patternsthat are based on intermediate events). Next, there aretwo software applications that partially implement thetransformation method presented in this thesis. The firstone is intended to analyze BPMN diagrams in order tofind workflow patterns. The other one transforms BPMNdiagrams into UML Business Services Specifications. So,the future work should focus on consolidation of thesetwo applications into a new one that will fully implementthe approach presented in this article.

Unfortunately, due to the limitation of space in this arti-cle not all ideas could by fully explained. The detaileddescription of the research objectivities, methods, andachievements can be found in the author’s disertation [29].

References[1] SOA manifesto. http://soa-manifesto.org/, 2009.[2] R. Amir and A. Zeid. A UML profile for service oriented

architectures. In OOPSLA ’04: Companion to the 19th annualACM SIGPLAN conference on Object-oriented programmingsystems, languages, and applications, pages 192–193, New York,NY, USA, 2004. ACM.

[3] J. Amsden. Business services modeling. Technical report, IBMdeveloperWorks, 2005.

[4] J. Amsden. Modeling soa: Part 1. service identification. Technicalreport, IBM developerWorks, 2007.

[5] N. Bieberstein, S. Bose, M. Fiammante, K. Jones, and R. Shah.Service-Oriented Architecture (SOA) Compass: Business Value,Planning and Enterprise Roadmap. IBM Press, USA, 2005.

[6] S. CONSORTIUM. SOA consortium core document. Technicalreport, Object Management Group, 2008.

[7] T. Erl. Service-Oriented Architecture: Concepts, Technology, andDesign. Prentice Hall PTR, Upper Saddle River, NJ, USA, Aug.2005.

[8] S. Johnston. UML 2.0 profile for software services. Technicalreport, IBM developerWorks, 2005.

[9] N. Koh. D1.4a: UML for service-oriented systems. Technicalreport, SENSORIA, 2007.

[10] M. Mimoso. A defining moment for soa. Technical report,SearchSOA.com, 2004.

[11] M. Murzek and G. Kramler. Business process modeltransformation issues – the top 7 adversaries encountered atdefining model transformations. In J. Cardoso, J. Cordeiro, andJ. Filipe, editors, ICEIS (3), pages 144–151, 2007.

[12] E. Newcomer. Understanding Web Services: XML, WSDL, SOAP,and UDDI. Addison-Wesley Professional, Pearson Education,Inc., USA, 2002.

[13] E. Newcomer and G. Lomow. Understanding SOA with WebServices. Addison-Wesley Professional, Pearson Education, Inc.,USA, 2004.

[14] OASIS. Reference model for service oriented architecture 1.0.Technical report, OASIS, 2006.

[15] OASIS. Web services business process execution languageversion 2.0. Technical report, OASIS, 2007.

[16] OMG. UML profile and metamodel for services (UPMS), requestfor proposal. Technical report, OMG, 2006.

[17] OMG. UML superstructure, version 2.1.2. Documentformal/2007-11-02, The Object Management Group, Nov. 2007.

[18] OMG. Business process modeling notation (BPMN), version 1.1.Document formal/2008-01-17, The Object Management Group,Jan. 2008.

[19] C. Ouyang, M. Dumas, and A. H. M. T. Hofstede. Pattern-basedtranslation of BPMN process models to BPEL web services.International Journal of Web Services Research, 5(1), 2007.

[20] C. Ouyang, M. Dumas, A. H. M. ter Hofstede, and W. M. P.van der Aalst. From BPMN process models to BPEL webservices. In ICWS ’06: Proceedings of the IEEE InternationalConference on Web Services, pages 285–292, Washington, DC,USA, 2006. IEEE Computer Society.

[21] W. Provost. UML for web services. Technical report, OâAZReillyxml.com, 2003.

[22] P. Rao. Using UML service components to represent the SOAarchitecture pattern: Help stakeholders to better understandservice components that comprise an SOA. Technical report, IBMdeveloperWorks, 2007.

[23] M. Rychlý and P. Weiss. Modeling of service orientedarchitecture: From business process to service realisation. InENASE 2008 Third International Conference on Evaluation ofNovel Approaches to Software Engineering Proceedings, pages140–146. Institute for Systems and Technologies of Information,Control and Communication, 2008.

[24] W. M. P. van der Aalst, A. P. Barros, A. H. M. ter Hofstede, andB. Kiepuszewski. Advanced workflow patterns. In O. Etzion andP. Scheuermann, editors, CoopIS, volume 1901 of Lecture Notesin Computer Science, pages 18–29. Springer, 2000.

[25] W. M. P. van der Aalst, A. H. M. ter Hofstede, B. Kiepuszewski,and A. P. Barros. Workflow patterns. Distributed and ParallelDatabases, 14(1):5–51, 2003.

[26] P. Vigneras. Why BPEL is not the holy grail for BPM. Technicalreport, InfoQ, 2008.

[27] J. Štumpf. SOA – další fáze budování IS? In Datakon 2006:Sborník databázové konference, pages 93–112. Masarykovauniverzita, 2006.

[28] N. Ward-Dutton. Bringing BPM and SOA together for maximumbusiness value. Technical report, SOAInstitutte.org, 2009.

[29] P. Weiss. Modeling of Service-Oriented Architecture: Integrationof Business Process and Service Modeling. PhD thesis,


Department of Information Systems, Faculty of InformationTechnology, Brno University of Technology, 2010.

[30] J. Zendulka and P. Weiss. Modeling of services and servicecollaboration in UML 2.0. In Information Systems and FormalModels, pages 29–36. Faculty of Philosophy and Science inOpava, Silesian University in Opava, 2007.

Selected Papers by the AuthorP. Weiss. Using UML 2.0 in Service-Oriented Analysis and Design.

In Martin Vítek, Filip Orság, editors, Proceedings of the 12thConference and Competition STUDENT EEICT 2006, Volume 4,pages 420–424, Brno, Czech Republic, 2006. Faculty ofInformation Technology BUT.

P. Weiss, J. Zendulka. Modeling of Services and ServiceCollaboration in UML 2.0. In Alice Klementová, et al., editors,Information Systems and Formal Models, pages 29–36, Opava,Czech Republic, 2007. Silesian University in Opava.

M. Rychlý and P. Weiss. Modeling of service oriented architecture:From business process to service realisation In CesarGonzales-Perez,Stefan Jablonski, editors, ENASE 2008 ThirdInternational Conference on Evaluation of Novel Approaches toSoftware Engineering Proceedings, pages 140–146, Funchal,Portugal, 2008. Institute for Systems and Technologies ofInformation, Control and Communication.

P. Weiss. Service-Based Realization of Business Processes Driven byControl- Flow Patterns. Accepted for publication inpost-proceedings of CEE-SET 2008 by Springer Verlag in theLNCS series.

Modeling of Service-Oriented Architecture: Integration of...

Documents

Transcript of Modeling of Service-Oriented Architecture: Integration of...