WIXLIB

Architectural Decisions and Patterns for Transactional Workflows in SOA85activities that do not participate in the same transaction (the one in which the BPELprocess runs) have been committed on the system level already.Recurring architectural decisions. It is technically feasible to transform the analysis-level BPM from Figure 1 into a design-level process model, e.g., via basicBPEL/SCA export utilities provided by commercial SOA tools [7]. However, suchpredefined transformations do not obey any architectural decisions that are made inresponse to project-specific requirements [20]. Many of these architectural decisionsmust be made for any process-enabled SOA, not just our CRM example: Which composition paradigm and resource protection approach should be selected? Who coordinates the transactions? Which invocation protocols are best suited to invoke servicesfrom the process activities in the SCL? Should the process activities and the serviceinvocations run in separate transaction islands or form a transaction bridge? Whichcompensation technology should be used, and where should it be placed?As step (a) of our method, Figure 2 organizes these recurring decisions by their abstraction level and scope. The abstraction level refines from conceptual issues such asselection of a composition paradigm (here: workflow) to technology and asset selection (here: BPEL language and BPEL engine). The scope of a decision assigns it to design model elements; in the CRM example, the activity transactionality has to bedecided for Reconcile Profile Upgrade and the other four tasks shown in Figure 1.Conceptual LevelProject Scope (e.g., CRM)Process Scope (Upgrade Customer)Q – Question (Architectural Decision)O – Option (Architecture stomCodeQRMI – Remote Message InvocationIIOP – Internet Inter-ORB ProtocolJMS – Java Messaging ServiceMOM – Message-Oriented MiddlewareJ2EE – Java 2 Enterprise tivity/Operation Scope (5 Tasks in BPM)OSystem Transactions(Global Transaction)OCompensation (Business Transaction)OProcess Engine inSCLOExternal Coordinator(Third Party)OWorkflowLanguageOQBPELNoneTechnology BPEL handler(and/or WBAF)OEngine-specificcompensationOCustom codeOQCompensationPlacementTransactionalityService LactivityOTransaction Islands(Section 4.1)OTransaction Bridge(Section 4.1)OStratified Stilts(Section 4.1)OSOAP/HTTPOSOAP/HTTP withWS-AT enabledORMI/IIOPOJMS, other MOMQEJB TransactionAttributeORelatedworkOSCAQSCA ReferenceQualifierO(Section4.2)QSCA InterfaceQualifierO(Section4.2)OJ2EEQSCA ImportQualifierO(Section4.2)QSCA Implementation QualifierO(Section4.2)Asset LevelWPS – WebSphere Process ServerQBPEL EngineSelectionOOIBM WPS(Section 4.2)OtherQTransactional ActivityBehavior in WPSO(Section 4.2)Fig. 2. Architectural decisions and alternatives for transactional workflows in SOA4 Architectural Patterns as Decision AlternativesAs step (b) of our method, we now introduce three conceptual patterns as solutionoptions (architecture alternatives) for the activity transactionality decision from

86O. Zimmermann et al.Figure 2. These conceptual patterns comprise of platform-independent primitives thatwe map to BPEL and SCA technology and engine deployment artifacts in step (c).The primitives are designed in such a way that other mappings can also be provided.4.1 Conceptual Patterns and PrimitivesThe tasks from Figure 1 require different transactional treatment: Determine WirelessCustomer Status does not change any enterprise resource; transactional execution isnot required. The retrieval should execute as fast as possible. Upgrade WirelessCustomer Profile updates wireless customer profiles; the service operation is colocated with that realizing the Retrieve Wireless Customer Profile task. Changes mustbe executed with all-or-nothing semantics. The CRM systems contacted in ReconcileProfile Upgrade offer messaging interfaces and may take days to respond. Still, all-ornothing semantics is required; if any of the reconciliation request messages returns anerror or times out, the updates to the wireless customer profile made by UpgradeWireless Customer Profile must be undone.TRANSACTION ISLANDS, TRANSACTION BRIDGE, and STRATIFIED STILTS are threepatterns commonly used to address resource protection requirements such as those inthe CRM. In theory, more design options exist; however, faithful to establishedpattern capturing principles, we only present patterns observed and proven in practice.Figure 3 illustrates the patterns on an abstract level; a more detailed pattern description follows later. The SCL is represented by the white boxes. It implements thetasks in the analysis-level BPM as process activities that are part of executableworkflows; two invoke activities I1 and I2 enclose a third activity U, which forexample may be a BPEL assign activity or another utility. S1 and S2 represent serviceproviders exposing operations. Service operation invocations are displayed as dottedlines. A contiguous light grey area represents a single global transaction as defined in[8], which may be extended if it is not enclosed by a solid black line.(1) Processactivities in SCLI1UI2I1S2S1UI2I1S2S1UI2(2) Communications infrastructure(3) ServiceprovidersS1Pattern 1:TRANSACTION ISLANDSPattern 2:TRANSACTION BRIDGES2Pattern 3:STRATIFIED STILTSFig. 3. Transaction context sharing options between process activities and service operationsThese patterns comprise of three types of primitives that correspond to thearchitectural layers from Figure 3: (1) Process Activity Transactionality (PAT) primitives for the process activities in the SCL. (2) Communications Transactionality (CT)primitives modeling the capabilities of the communications infrastructure (invocation

Architectural Decisions and Patterns for Transactional Workflows in SOA87I1UI2(1) PAT – Process ActivitySSI(ST-N) NewI(ST-J) JoinI(CT-AS)Asynchronous StratifiedI2(CT-ST)Synchronous TransactionalU(CT-SNT)Synchronous Non-TransactionalI1Transaction(PAT-N) New(PAT-J) Joinprotocol, component technology). (3) Service provider Transactionality (ST) primitives stating the capability and willingness of service providers to join a transaction.These primitive types are conceptual, platform-independent abstractions ofconcepts for example found in today’s BPEL/SCA technology, and can be viewed asdesign time statements of architectural intent. Figure 4 illustrates the primitives:SSS(2) CT – Communication(3) ST – Service ProviderFig. 4. Conceptual primitives as pattern building blocks (notation same as in Figure 3)To elaborate upon the defining characteristics of the patterns and the primitives, wenow present them in a format commonly used in the design patterns literature.Intent. All patterns and primitives share the objectives motivated in Sections 2 and 3:To protect enterprise resources against integrity and correctness threats that mayoccur during concurrent process execution, e.g., when multiple processes and activities in the SCL invoke distributed services via a SOA communication infrastructure.Pattern 1. Decoupled TRANSACTION ISLANDS (PAT-J CT-SNT ST-N in Figure 3)Problem. How to isolate SCL process activities from service operation execution?Solution. Do not propagate the transaction context from the SCL to the service.Example. In the CRM case study, this pattern is applicable for Determine WirelessCustomer Status. This analysis-level task is realized as a process activity that invokesa read-only operation which in this example should execute non-transactionally.Forces and consequences. If a service operation fails, the process navigation in theSCL is not affected, and vice versa. If a service works with shared enterprise resources, its operations must be idempotent, as they may be executed more than oncedue to the transactional process navigation in the SCL. In many cases, the serviceprovider must offer compensation operations, and higher-level coordination of thecompensation activities is required (e.g., via business transactions; various modelshave been proposed). In practice, this pattern is often selected as a default choice.Pattern 2. Tightly coupled TRANSACTION BRIDGE (PAT-J CT-ST ST-J shown inFigure 3); MULTIPLE BRIDGES variant (PAT-N CT-ST ST-J).Problem. How to couple process activity execution in the SCL and service operationexecution from a system transaction management perspective?

88O. Zimmermann et al.Solution. Configure process activities, communications infrastructure, and serviceproviders in such a way that the SCL transaction context is propagated to the service.Example. In the CRM case study, this pattern addresses the all-or-nothing requirements stated for Retrieve/Upgrade Wireless Customer Profile (co-located services).Forces and consequences. Process activities and the service operations invoked bythem execute in the same transaction. As a result, several service operations can alsoparticipate in the same transaction. Therefore, a natural limit for their response timesexists (“tens of seconds to seconds at most” [8]). If a service-internal processing erroroccurs, previous transactional work, which can include process navigation in the SCLand the invocation of other services, has to be rolled back. This pattern meets resourceprotection needs well on the system level, but often is not applicable, e.g., whenprocesses and operations run for days or months. Hence, a common variation of thispattern is to split an SCL process up into several atomic spheres [8], creatingMULTIPLE BRIDGES for selected process activity/service operation pairs. Executingthe process activities in a small number of transactions (single TRANSACTION BRIDGE)reduces the computational overhead for process navigation; splitting the process upinto several atomic spheres (MULTIPLE BRIDGES) increases data currency.Pattern 3. Loosely coupled STRATIFIED STILTS (PAT-J CT-AS ST-J in Figure 3)Problem. How to realize asynchronous, queued transaction processing in SOA?Solution. Use message queuing as SOA communication infrastructure.Example. In the CRM case study, this pattern must be applied for Reconcile ProfileUpgrade, as the wireline CRM systems only provide messaging interfaces (e.g., JMS);additional compensation logic is required. In Figure 3, I1 and S1 use stratified transactions (as defined in [8]) during service invocation; on the contrary, service S2 readsthe request message and sends the response message within a single transaction.Forces and consequences. Services do not have to respond immediately; the deliveryof the messages is guaranteed by the communications infrastructure. If the executionof the service operation fails, the process may not get an immediate response; additional error handling is required, often involving compensation logic. This pattern oftenis the only choice in process-enabled SOA, e.g., when integrating legacy systems.PAT primitives. As Figure 4 shows, Process Activity Transactionality (PAT) definestwo primitives for the SCL, transaction context sharing or Join (J), and transactioncontext separation or New (N). If set to PAT-J, a process activity executes in the sametransaction context as the adjacent activities in the same process; it joins an existingcontext. As a consequence, the process activity’s work might be rolled back if anyother process activity or service operation that participates in the same transactionfails. With PAT-N, a process activity is executed in a new transaction context. BothPAT-J and PAT-N are valid choices in all three composite patterns; PAT-J is shownin Figure 3 and commonly used in practice. In TRANSACTION BRIDGE, PAT-N modelsthe MULTIPLE BRIDGES variant. Deciding for PAT-N is justified if two process activities should be independent from each other from a business requirement point ofview. Furthermore, some process models contain loops that are too complex to fit into

Architectural Decisions and Patterns for Transactional Workflows in SOA89a single, short-lived system transaction (e.g., due to retries, refinement/completioncycles, and service provider limitations).CT primitives. We model three Communication Transactionality (CT) primitives,Synchronous Non-Transactional (CT-SNT), Synchronous Transactional (CT-ST),and Asynchronous Stratified (CT-AS). CT-SNT is used in the TRANSACTION ISLANDSpattern. It represents a synchronous service invocation from the process activity without propagation of the transaction context. As a consequence, the activity waits untilthe call to the service returns. Once the service has been called, there is no possibilityto influence the work the service conducts. For example, the CT-SNT service invocation may cause the transaction to exceed the maximum duration configured in theSCL, which may result in a transaction timeout and a subsequent rollback. With CTSNT, undoing the work of the service can not be included in this rollback.CT-ST is required to build a TRANSACTION BRIDGE. It models a synchronous service invocation with transactional context propagation. As a consequence, the processactivity waits until the call to the service returns; a rollback may occur after theservice execution has completed (the service participates in the SCL coordination).CT-AS is part of the STRATIFIED STILTS pattern. It represents an asynchronousservice invocation without transaction context propagation. In CT-AS, long-runningservices can be invoked without loosing transactional behavior, as the processnavigation is part of a stratified transaction [8]. At least three transactions areinvolved in the invocation of a long-running service: the request message is sent in afirst transaction; in a second transaction, the message is received by the serviceprovider and the response message is sent; in a third transaction, the process activityreceives the response from the service. As shown in Figure 3, depending on theservice implementation, the second transaction (provider side) may be split up intotwo transactions: receive the message and commit, and later on, send the response in anew transaction. Such stratification details are described further in [8].ST primitives. Two choices and corresponding primitives exist for the ServiceProvider Transactionality (ST): join an incoming transaction (ST-J) or create a newone (ST-N). ST-J is used in TRANSACTION BRIDGE, ST-N in TRANSACTION ISLANDS.In ST-J, the service provider participates in the transaction of the caller (if a transaction exists). As a consequence, process activity execution in the SCL and the invokedservice operation influence each other, e.g., when causing a rollback. In ST-N, theservice provider does not participate in the incoming transaction. As a consequence, ifthe transaction in which the process activity runs is rolled back and the activity isretried later (e.g., due to process engine-specific error handling procedures), the service may operate on enterprise resources that have been modified in the meantime.4.2 Sample Mapping of Primitives to BPEL/SCA Technology and EngineAs step (c) of our method, we now map the three PAT, CT, and ST primitives toBPEL and SCA and other technology platforms. We expect that BPEL enginesprovide settings that allow configuring the transactional behavior at least for invokeactivities. Services are invoked via protocols such as SOAP/HTTP, IIOP and JMS,which differ in their support for transaction context propagation and (a)synchrony.The transactional behavior of SCA components is defined by SCA qualifiers.

90O. Zimmermann et al.Qualifiers specify the behavior desired from the point of view of the service consumer(SCA reference and SCA import) and the service provider (SCA interface, SCAimplementation).(1) The PAT primitive from Figure 4 does not have a direct BPEL realization; typically, BPEL engine vendors add proprietary support for it. Furthermore, additionalstandardization work is underway; for example, the BPEL for Java (BPEL4J) specification introduces ACID scopes [2]. The exact semantics are BPEL engine-specific.For example, during a rollback an engine may let the entire process fail, request resolution by a human operator, or retry one or more activities at a later point in time (potentially with a different transactional scope). While this is engine-specific behavioroutside of the scope of the BPEL specification, the process modeler must be aware ofit when selecting between PAT-J and PAT-N. (2) CT-SNT as a synchronousinvocation not propagating the transactional context maps to SOAP/HTTP or IIOP astransport protocol. CT-ST maps to SOAP/HTTP with WS-AtomicTransaction supportor to IIOP. CT-AS can be implemented with JMS; however, no standardized WSDLbindings exist at present. CT also determines the SCA qualifiers on reference, import,and interface level, e.g., SuspendTx and JoinTx. (3) ST can be mapped to the SCAqualifier Transaction on component implementation level.Table 1 maps the three conceptual patterns from Section 4.1 to CT and STprimitives and corresponding SCA qualifiers. At the time of writing, these qualifiersresided in a non-standard namespace [7], not yet in one of the emerging SCAstandards [9]. The full mapping reference can be provided.Table 1. Mapping of conceptual patterns to primitives and SCA LANDSTRANSACTIONBRIDGESTRATIFIEDSTILTSCTSCA reference(BPEL process as component invokingothers)CT-SNTCTSCA import(reference toexternal service)CT-SNTCTSCA interface (serviceprovidercomponent)CT-SNTSTSCA implementation(service providercomponent)ST-N (or ST-J)DeliverAsyncAt n/aSuspendTx trueJoinTx falseJoinTx falseTransaction local global anyCT-STCT-STCT-STST-JDeliverAsyncAt n/aSuspendTx falseJoinTx trueJoinTx trueTransaction globalCT-ASCT-ASCT-ASST-JDeliverAsyncAt commitSuspendTx falseJoinTx n/aJoinTx n/aTransaction globalMapping to IBM WebSphere Process Server (WPS). WPS [7] provides a BPELengine, which exposes processes and services as SCA components; in WPS, a BPELbased SCL connects to the underlying architectural layers via SCA. The SCA qualifiers from Table 1 govern the transactional context propagation and behavior.Furthermore, PAT translates into a proprietary invoke activity configuration attributecalled tran

A method for the systematic design of transaction management settings in process-enabled SOA, which (a) identifies the required architectural decisions in analysis-level process models, (b) captures proven design options as patterns which facilitate the decision making, and (c) transforms the pattern