Dynamic Reconfiguration Using Template BasedWeb Service Composition

Kristof Geebelen, Sam Michiels and Wouter JoosenIBBT-DistriNet, Dept. Computer Science, K.U.Leuven

Celestijnenlaan 200A3001 Leuven, Belgium

{kristof.geebelen, sam.michiels, wouter.joosen}@cs.kuleuven.be

ABSTRACTCurrent workflow languages introduce limitations regardingmodularity and flexibility. They are lacking support forreusability of primitive and structured activities. Designingprocesses often leads to duplication which makes the work-flow descriptor complicated and unnecessarily large. Fur-thermore, due to the static character of the scripts, there isinsufficient flexibility to model dynamic, evolvable and fail-safe workflows. In this paper we present a framework thatallows the design of WS-BPEL processes in a modular waybased on reusable templates. In addition, we introduce anextra layer on top of WS-BPEL that allows template pro-cessing based on parameter values. This layer offers supportfor decision logic to adapt processes dynamically. The ap-proach is based on the ”Ruby On Rails” (RoR) framework,known for adding dynamism to static web pages. The pro-posed solution is portable with existing WS-BPEL engines.

Categories and Subject DescriptorsH4.1 [Information Systems Applications]: WorkflowManagement

General TermsDesign, Management

KeywordsModularization, Dynamic Reconfiguration, Service Compo-sition, WS-BPEL

1. INTRODUCTIONWeb services have become increasingly popular as a means

to integrate existing applications into new environments.With a Service Oriented Architecture [11] as foundation forcreating individual solutions, an integration language can beused to orchestrate existing services into more complex busi-ness solutions. At this moment, the Web Services Business

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.MW4SOC ’08, December 1, 2008, Leuven, BelgiumCopyright 2008 ACM 978-1-60558-368-6/08/12 ...$5.00.

Process Execution Language (WS-BPEL) [12] has profileditself as the de-facto industry standard for orchestrating webservices. However, this standard exhibits major limitationsregarding modularity and flexibility.

When developing an application in a general purpose lan-guage like Java, code modules can be reused by definingclasses and methods. Functionality declared in a class ormethod body can be reused by creating new objects or by in-voking methods multiple times. WS-BPEL is used to modelthe behavior of processes with xml-based syntax. However,for designing and implementing such a process there is littlesupport for concepts that foster modularization and reuseof code. Besides modularization of the functional part, itis useful to provide a means to separate concerns from theworkflow specification. Examples of such concerns are log-ging, billing and security. Typically, we want to avoid thatthose concerns end up scattered across the process specifi-cation and tangled with one another.

A second limitation concerns the flexibility offered by work-flow languages. The integration of heterogeneous web ser-vices, often developed by a third-party, into a new businessprocess over the Internet may lead to unpredictable behav-ior. The web services used in workflows are not alwayscontrollable by the developer of the business process. Toprovide reliable solutions for services that are often subjectto change there is need for fail-safe mechanisms that allowanticipation on unpredictable factors. Examples of irregu-lar behavior include web services that go off-line and per-formance bottlenecks. WS-BPEL offers fault handlers andcompensation handlers that allow anticipation to a certaindegree. We argue, however, this is not sufficient to providereliable, high quality solutions in the dynamic context ofweb services.

The contribution of this paper complements earlier re-search (Padus [8]), in which we propose an aspect-orientedapproach to comply with shortcomings of WS-BPEL; Weleverage on this expertise and investigate how RoR can bemapped to the domain of web services since it handles sim-ilar issues in dynamic web design. This paper proposes atemplate framework for designing WS-BPEL processes thatallows the interpretation of templates based on parameters.The approach is easy to use for the designer and tacklesthe shortcomings mentioned above without reducing perfor-mance at runtime. The idea is to start from a generic masterprocess in which designers can model functionality indepen-dent of concrete implementations. A template library is pro-vided which contains combinations of WS-BPEL activitiesthat fulfill common functionalities. The templates together

49

with the generic master process are the ingredients for acontroller that generates a tailored WS-BPEL process. Thecontroller composes the WS-BPEL process by interpretingvarious parameters associated with the runtime environmentand by selecting appropriate templates from the template li-brary. The template framework introduces a mechanism ontop of the execution layer that tackles the issues concern-ing flexibility and modularization before deployment. Thismakes the resulting WS-BPEL process compatible with ex-isting WS-BPEL engines.

2. WEB SERVICE COMPOSITION WITH WS-BPEL

2.1 IntroductionBusiness Process Execution Language for Web Services

(WS-BPEL) [12] provides a language for the specification ofbusiness processes and business interaction protocols. WS-BPEL is built on top of XML specifications. For example,it uses the web service description language (WSDL) [13]to describe the web service interfaces that participate in aprocess. An executable WS-BPEL process is defined by acontrol flow that consists of a combination of basic and struc-tured activities.

Figure 1: Overview

The Business Process Modeling Notation (BPMN) [14] isa standardized graphical notation for drawing business pro-cesses using a flow chart. The BPMN specification includesa mapping from BPMN diagrams to executable WS-BPELprocesses. Processes built with a design tool can automati-cally be generated from the workflow diagrams.

To make a business process operational, it has to be de-ployed on a WS-BPEL orchestration engine (e.g. IBM [17],Oracle [16], ActiveBPEL [15]). Since WS-BPEL is standard-ized, processes are portable between different engines to acertain extent.

2.2 LimitationsIn different research papers, current limitations of work-

flow languages have been discussed, including modulariza-tion and flexibility.

In an evaluation of WS-BPEL to Scientific Workflows [1]the need for adaptive and flexible workflows is identified.However, there is little support in WS-BPEL for dynami-cally modifying a workflow at runtime. Furthermore, thereusability of the basic and structured activities in WS-BPEL is limited. It is not possible, for instance, to re-execute an activity that is defined earlier by referring toit later [1].

IBM and SAP [8] identify a similar problem related tomodularity: ”The BPEL language currently does not sup-port the explicit definition of business process ”fragments”that can be invoked from within the same business processor from another business process”.

Other papers [2, 5, 6, 7] focus on the need for separation ofconcerns in the workflow specification. WS-BPEL processes

suffer from a problem that is known as the ”tyranny of thedominant decomposition”. A WS-BPEL process can only bedecomposed according to the control flow of the process, andconcerns that do not align with this decomposition end upscattered across the process specification and tangled withone another [2]. These cross-cutting concerns give rise tolarge and complex process definitions which are difficult tounderstand and maintain.

3. TEMPLATE BASED WEB SERVICE COM-POSITION

In this section we address the limitations of WS-BPELintroduced previously. First we motivate our approach bymapping the problems to the domain of dynamic web de-sign. Then we present the basic building blocks used in theframework: the template definitions, the library, the masterprocess and the controller. Support for modular design anddynamic configuration is discussed in detail by means of arepresentative example.

3.1 ApproachOur approach to create WS-BPEL processes in a modu-

lar and dynamic way is based on similar evolutions in thedomain of web design. The intent of web design is to createa website that presents content to the end users in the formof web pages. To comply with today’s expectations of end-users, there is growing tendency to use dynamic web pages.In contrast to static pages, where the content and layout isnot changed with every request, dynamic pages adapt theircontent on the fly depending on the user’s input.

To support dynamic web design there are a lot of prod-ucts and tools on the market. One that caught our attentionis the ”Ruby On Rails” framework [10]. RoR is a popularopen source web application framework written in the Rubyprogramming language. RoR is based on an architectureknown as MVC (Model - View - Controller). The architec-ture consists of a set of design patterns that allow a clearseparation between data models, user interfaces, and con-trol logic of the application. The model is responsible forinteracting with the application data. The view is the pre-sentation layer. It defines how the application presents data.Controllers orchestrate the application; they receive events,interact with the model, and display an appropriate view tothe user. Figure 2 illustrates the basic functionality providedby the framework to handle a web request: (1) Web requestsare routed to the appropriate controller; The controller coor-dinates the interaction between the user, the views, and themodel. To use application data, it can contact the model(not presented in fig. 2). The controller manages helpermodules which extend the capabilities of the view templateswithout bulking up their code. (2) The controller instructsthe view to generate an appropriate presentation. (3) Theview uses the results from the controller to render the nextbrowser screen [10].

The RoR framework allows dynamically adapting the con-tent of a static web page expressed in html. Based on theuser request, the framework calculates the values of variablesthat are then used to generate the web page. Furthermore,the helper class contains template definitions of html codethat can be substituted in the html page. The ruby program-ming language is used to implement the logic that decideson which template is returned.

50

Figure 2: A web request with Ruby On Rails

We extend the concept of dynamic web design to web ser-vice composition in order to comply with frequently chang-ing environments and unpredictable behavior. The proposedtemplate framework is based on the MVC concept used inthe RoR framework. Figure 3 shows the general architec-ture. The idea is to start from a generic master process.This process represents a generic workflow where require-ments can be modeled without being bound to specific im-plementations. The concrete modules of WS-BPEL activi-ties are modeled as templates and stored in a library. (1)The controller can be triggered to regenerate the process.(2) It interprets provided parameter values (2a) and looksup the corresponding templates from the library (2b) whichare integrated in the master process. (3) The result is anexecutable WS-BPEL process generated by the controller.

The introduction of a layer on top of the WS-BPEL execu-tion allows dynamic composition of templates into the mas-ter process by interpreting changing parameters. This newrecomposition, triggered at the template controller, happensin the modeling space and replaces the old workflow compo-sition at the execution layer by redeployment. The mappingfrom the template framework illustrated in Figure 3 to theRoR example shown in Figure 2 is straightforward: Throughthe RoR Helper class (Template Controller), concrete tem-plates can be selected which extend the View (Master Pro-cess) to render a specific representation (Executable BPELProcess).

In this paper, we restrict our focus to the reuse of templatedefinitions. This maps only to a basic feature of in the RoRframework. However we motivate our approach from thisviewpoint since we believe that many other features offeredby RoR have the potential to be successfully mapped tothe domain of web services. These include features werethe execution feeds back into the model and they will beinvestigated in future work.

3.2 Building BlocksWe show how the template framework can be used to de-

sign a simple brokerage service. The service integrates someweb services into a workflow that allows end-users to retrievestock quotes and place market orders. For this process wewant to apply the following informal policy rules:

• Users must be authenticated before using the services.

• Since there are multiple broker services available, theone with the lowest response time will be used. Reeval-

uation of the response time will be done every hour.

• After the invocation of a broker services, a billing schememust be applied that bills a fixed amount to the cus-tomer.

3.2.1 Template DefinitionsThe syntax used for defining templates is based on an

existing syntax for describing WS-BPEL modules [3].A template definition represents a coherent set of basic

and structured WS-BPEL activities that realizes a particu-lar functionality. For example, Listing 1 shows a templatedefinition that allows the invocation of a billing service.

1 <template name=”Gene r i cB i l l i n g ” r e s u l t=””>2 <module name=”b i l l i n g S e r v i c e ”>3 <invoke partnerLink=”b i l l i ngPL ” portType=”b i l l :

b i l l ingPT ” operat ion=”b i l l ”4 inputVar iab le=”b i l l i ngMsg”>5 </module>6 . . .7 </template>

Listing 1: Template defining generic billing

A template consists of one or more modules. A module isa cluster of WS-BPEL activities. Different modules are usedwhen the contained activities are scattered throughout theprocess to realize the functionality provided by the template.Listing 2 illustrates a template that consists of two modules.The first one is responsible for registering the start time.Next, some action will proceed for which its duration willbe billed. After that action the resulting price is sent to abilling service.

1 <template name=”Durat i onB i l l i ng ( St r ing Pr ice ) ” r e s u l t=””>2 <include name=”Gene r i cB i l l i n g ”/>3 <module name=”s t a r t ”>4 <ass ign>5 <copy>6 <from expre s s i on=”func : getCurrentTime ( ) ” />7 <to va r i ab l e=”startTime ” />8 </copy>9 </ass ign>

10 </module>11 <module name=”end”>12 <sequence>13 <ass ign>14 <copy>15 <from expre s s i on=”func : c a l c u l a t eP r i c e ( bpws :

getVar iab leProperty ( ’ startTime ’ ) , $Pr ice )”/>16 <to va r i ab l e=”b i l l i ngMsg ” part=”p r i c e ” />17 </copy>18 </ass ign>19 <template name=”b i l l S e r v i c e ” />20 </sequence>21 </module>22 . . .23 </template>

Listing 2: Template defining Duration Billing

51

Figure 3: The template framework

Another feature illustrated in Listing 2 is the reuse of tem-plates from within a template definition. Include statementsare used to include the contents of another template file. Thesemantics of the statement is the same as if the contents ofthe included template were copied to this template.

The template definition can be compared with the signa-ture of a method in a general programming language. Argu-ments can be passed in the form of strings and WS-BPELvariables. The values of the parameters will be replaced atthe corresponding references within the template.

3.2.2 LibraryIn this section we zoom in on the template library avail-

able for the design of the workflow. The library containstemplates for billing, security and invoking a broker service.We illustrate examples in Listing 3 and 4. Analog there arealternative templates for invoking a second broker service(Service B) and for certificate validation (Mechanism B) re-spectively.

Template library:

• Place Market Orders

1 <template name=”Broker1 (Var order ) ” r e s u l t=”Var s ta tu s”>2 <module>3 <invoke partnerLink=”stockBroker1 ” portType=”sb :

stockBroker1PT ” operat ion=”placeMarketOrder ”inputVar iab le=”order ” outputVar iable=”s ta tu s”>

4 </module>5 . . .6 </template>

Listing 3: Service A - Stock Broker 1

• Security

1 <template name=”passwordSecur ity ( XpathStringIncommingPassword )”>

2 <module>3 <sequence>4 <ass ign>5 <copy>6 <from>IncommingPassword</from>7 <to va r i ab l e=”password ” part=”msg”/>8 </copy>9 </ass ign>

10 <invoke partnerLink=”passwordSecPL ” portType=”ps :passwordSecPT” operat ion=”checkPassword ”inputVar iab le=”password ” outputVar iable=”Result”/>

11 < i f name=”Val idateAuthenticat ionToken”>12 <condit ion>Result = f a l s e </condit ion>13 <throw faultName=”ps : Authent i ca t ionFa i lu re ”

f au l tVa r i ab l e=”Fault ” />14 </ i f >15 </sequence>16 </module>17 . . .18 </template>

Listing 4: Mechanism A - Password Security

3.2.3 Master ProcessWith the template library in mind we can design our mas-

ter process. The master process is designed as a regularprocess. But instead of including all the specific details ofall possible situations on which anticipation is required, itis designed on a meta-level, containing more generic tem-plate statements. Listing 5 shows a fragment of the masterWS-BPEL process. Here we state that the invocation of abroker service, a security mechanism and a billing schemeare needed. Details are passed as an argument.

1 <process>2 . . .3 <%= insertSecurity ( $BrokerServ iceOperat ionIn .

secur ityToken ) %>4 . . .5 <sequence name=”Sequence1”>6 <%= placeMarketOrder ( $BrokerServ iceOperat ionIn .

orderRequest ) %>7 <%= insertFixedBill ing ( ) %>8 . . .9 </sequence>

10 . . .11 </process>

Listing 5: Fragment of master WS-BPEL process

A business process is usually designed in a workflow chart.Figure 4 illustrates a graphical representation of the work-flow. The master process is modeled like a regular processexcept for the generic parts we use controller statementsinstead of concrete WS-BPEL activities. The circles in Fig-ure 4 represent high level calls in the workflow.

Figure 4: Master BPEL Process

52

3.2.4 ControllerThe final step is to implement the logic that decides which

templates to use. The decision logic on how specific pro-cesses must be generated is implemented in the templatecontroller. The concrete implementation is shown in List-ing 6. Parameters we use to decide on which template tochoose are for example the response times of two broker ser-vices. Those times are calculated in the background and canbe retrieved from a database. The template correspondingwith the service that has the lowest response time is returnedand substituted in the master process. Depending on howfrequently the controller is triggered to check for a changein parameter values and generate and deploy a new versionof the process, decides how quick we can anticipate on achanging environment.

1 module BrokerContro l l e r2 def insertSecurity ( incommingPassword )3 return templates . passwordSecur ity ( incommingPassword )4 end5 def placeMarketOrder ( order )6 in t responseTimeA = Database . getResponseTimeA ()7 in t responseTimeB = Database . getResponseTimeB ()8 i f ( responseTimeA < responseTimeB )9 return templates . Broker1 ( order )

10 e l s e11 return templates . Broker2 ( order )12 end13 end14 def i n s e r t B i l l i n g15 Str ing p r i c e = Database . g e tPr i c e ( )16 return templates . F ixedFeeBi l l i ng ( p r i c e )17 end18 end

Listing 6: Template Controller Logic

3.2.5 DiscussionWe illustrate the impact on an evolving application by de-

scribing a scenario that implies the need to change. Imaginethat the password security mechanism currently used is nolonger safe and needs to be upgraded to a system that ex-changes certificates. This requirement can easily be achievedby changing the template controller logic to return the cor-responding template found in the library. Since ruby is aninterpreted language, changes in the implementation are ap-plied immediately.

The lack of flexibility is handled by introducing an ex-tra layer that allows template processing. By using tem-plates, the framework supports not only the separation ofconcerns, but also modularization in a more general con-text. Grouping coherent pieces of WS-BPEL activities intoreusable modules minimizes redundancy while developingbusiness processes. The use of standardized templates easesthe exchange of existing modules. The complete integra-tion of the templates in the master process provides a highcoupling between the modules and the parent process.

4. PROTOTYPEFor the implementation of the framework we have reused

the concepts from the RoR framework. Simply by consid-ering the master process as a static web page and the tem-plate controller as a helper class we can already generateexecutable processes by simulating a web request. Of coursea more usable and user friendly solution requires still someefforts. Extensions to the RoR framework are needed tomake the design of master processes straight forward. In-tegration of WS-BPEL support like easy deployment andgraphical design tools are the next steps to come to a usefulsolution.

5. RELATED WORKBPEL-SPE [8] introduces an extra layer on top of the

WS-BPEL language that supports invocation of a businessprocess as a sub-process of another business process. Thisapproach focuses on modularization and reuse. One of theirchallenges is to allow a tight coupling between the parentand sub-process. The paper examines various flavors of sub-processes and different modes of invocation, and outlinesthe syntax and semantics of needed extension. The lan-guage specification, which defines the precise syntax of thisextension, is not implemented yet.

Akram [1] investigates the requirements of Scientific Work-flows in context of WS-BPEL and evaluates to what ex-tend WS-BPEL is able to fulfill these requirements. Dueto the complexity, unpredictability and inter-dependency ofthe components in a scientific workflow there is a demandfor high flexibility of the underlying workflow that will beused. The identified shortcomings of WS-BPEL for Scien-tific Workflows were also relevant to this paper.

Casati [4] presents the eFlow platform that allows dy-namic and adaptive composition of e-services. The paperdiscusses some interesting constructs to allow adaptive work-flows: dynamic conversation selection, multi service nodes,generic nodes and dynamic process modifications. In con-trast to our approach the binding of service templates is doneat a late stage and requires a customized workflow engine.

Although no pointcut language is used in our approach,it is strongly related to AOP. The controller statements canbe seen as annotations that allow the weaving of reusablemodules into the base program (master process).

Charfi [5] and Courbis [7] both present an aspect-orientedextension to WS-BPEL allowing runtime aspect additionand removal. The approach we used to generate an ex-ecutable process is done statically. This means that thetemplates and base-code are merged before runtime. Thestatically generated process needs still to be deployed on aBPEL engine before it will be executed. However, we believethat this approach has some advantages compared to run-time adaptation of the workflow. When a new WS-BPELprocess is created it can usually be packaged and deployedon a running engine on the fly. This means that redeploy-ing a new process generates only a one-time minimal extraoverhead. From then on instances from the new process canbe executed at full performance. Runtime adaptation wouldimply that each time a WS-BPEL activity is called, we needto recheck the templates during the execution of the pro-cess. Real time processes, where performance is extremelyimportant, do not tolerate that extra overhead. So in manycases the cost of periodical redeployment will be much lowerthan the cost of continuous probing for changes. Only ifthe adaptation rate of the workflow is very high continuousprobing will probably perform better. Furthermore, to allowruntime checking a custom-made BPEL engine is required.This would bind the framework to a specific implementationand limit the portability of the resulting workflows. Anotherpossible problem with runtime adaptation that comes to ourmind is a need for consistency checking. When the work-flow of a process instance gets adapted while it is running itcan lead to unpredictable behavior and enter an inconsistentstate.

Isolating process-level concerns using Padus [2] is alsobased on an aspect-oriented language extension. The staticweaving approach used here introduces no runtime overhead

53

and the resulting process is compatible with existing WS-BPEL engines. The concepts from Padus can be used com-plementary to the ideas presented in this paper. Insteadof inserting controller statements manually in the masterprocess, we can use the rich joinpoint model, the pointcutlanguage and the deployment descriptor of Padus to weavethem into the workflow in an aspect-oriented way. In a nextstep, the template framework will translate them to concreteWS-BPEL activities.

6. CONCLUSIONS AND FUTURE WORKThis paper focused on the modularization and flexibility

of WS-BPEL processes. We presented a framework that usesa controller to select template definitions from a library andintegrate them into a master process. Our approach is basedon the helper module concept from the RoR framework. Theresulting process is a standard WS-BPEL process, deploy-able on any existing engine and executable without gener-ating extra performance overhead at runtime.

We highlighted only one of the aspects that RoR offers todesign dynamic web pages and mapped it to the WS-BPELcontext. However there are other features offered by theframework that can be useful to adopt [10]:

• The Rails controller classes are the logical center ofthe web application. The code written allows addingapplication level functionality by extending the basicfunctionality offered by the static web pages. Simi-larly we could extend the basic functionality offeredby WS-BPEL with ruby method invocations duringthe execution of the workflow. Currently most WS-BPEL engines already enable to call custom functionsat runtime. However these functions are often inte-grated in the engine implementation and difficult toadapt. The challenge is to provide user-friendly sup-port, integrated with the template framework which al-lows a WS-BPEL designer to easily extend WS-BPELactivities with custom-made ruby method calls.

• Active Record is an Object-Relational Mapping (ORM)layer supplied with Rails. This layer provides sup-port to easily use stored data into the web application.Database support in WS-BPEL is usually limited topersistence of process instances. Extending the execu-tion of a workflow with database access via customizedfunctions improves its flexibility.

Another possible extension to the template framework al-lows real time modification of workflows based on incomingmessages. This approach demands to queue and process in-coming messages. If this message requires adaptation of theworkflow, a new specific version is generated and deployedby the template framework. Then the queued message canbe rerouted and executed by the adapted workflow. It isobvious that the extra flexibility offered by this approach isat the cost of performance. We need to study this more indetail to see if certain cases could benefit from this approach.

7. ACKNOWLEDGMENTSWe would like to acknowledge the input of Kris Verlae-

nen to the ideas presented in this paper. Also thanks goesto Dimitri Van Landuyt and Tom Stijnen for some interest-ing discussions on the topic and to the reviewers for theirconstructive comments.

8. REFERENCES[1] Akram, A., Meredith, D. and Allan R.: Evaluation of

BPEL to Scientific Workflows. Proceedings of theSixth IEEE International Symposium on ClusterComputing and the Grid (CCGRID’06).

[2] Braem, M., Verlaenen, K., et al.: Isolatingprocess-level concerns using Padus. Proc. of the 4thInt’l Conf. on Business Process Management (BPM2006), Vienna, Austria, Springer (2006).

[3] Braem, M., Joncheere, N., Geebelen, K. andVerlaenen, K., Guiding aspect-oriented servicecomposition in WS-BPEL and Padus(Demonstration), Proceedings of the 6th internationalconference on aspect-oriented software development,March 2007.

[4] Casati, F., Shan, M. C.: Dynamic and adaptivecomposition of e-services. Information system. 6(3):143-162,2001.

[5] Charfi, A., Mezini, M.: Aspect-oriented web servicecomposition with AO4BPEL. In Zhang, L.J., ed.:Proceedings of the 2nd European Conference on WebServices (ECOWS 2004), Erfurt, Germany,Springer-Verlag (2004) 168-182.

[6] Charfi, A., Mezini, M.: Aspect-oriented workflowlanguages. In the Proceedings of the 14thInternational Conference on Cooperative InformationSystems (COOPIS’06).

[7] Courbis, C., Finkelstein, A.: Towards aspect weavingapplications. In: ICSE ’05: Proceedings of the 27thinternational conference on Software engineering, NewYork, ACM Press (2005) 69-77.

[8] Kloppmann, M., Rickayzen, A., et al.: WS-BPELExtension for Sub-processes - BPEL-SPE. A JointWhite Paper by IBM and SAP (2005).

[9] Suvee, D., Vanderperren, W.: JAsCo: Anaspect-oriented approach tailored for component basedsoftware development. In Akysit, M., ed.: Proc. 2ndInt’ Conf. on Aspect-Oriented Software Development(AOSD-2003), ACM Press (2003) 21-29

[10] Thomas, D.,Hansson, D.,Breedt, L. and Clark, M.:Agile Web Development with Rails, 2nd Edition

[11] Reference Architecture for Service OrientedArchitecture Version 1.0, April 2008, OASIS TechnicalCommittee,http://www.opengroup.org/projects/soa/.

[12] Web Services Business Process Execution LanguageVersion 2.0, April 2007, OASIS Technical Committee,http://docs.oasis-open.org/wsbpel/.

[13] Web Services Description Language (WSDL) Version2.0, June 2007, W3C Note,http://www.w3.org/TR/2007/REC-wsdl20-20070626/.

[14] Business Process Modeling Notation (BPMN) Version1.1, January 2008, OMG Specification,http://bpmn.org/.

[15] Active Endpoints,http://www.activevos.com/community-open-source.php .

[16] Oracle BPEL Process Manager,http://www.oracle.com/technology/products/ias/

bpel/index.html .

[17] IBM Business Process Execution Language for WebServices JavaTM Run Time (BPWS4J),http://www.alphaworks.ibm.com/tech/bpws4j.

54