osb patterns and best practices

Service Design Best Practices and Patterns

SOA Best Practices Using WLI 81 page 1 of 69 Patterns and Best Practices

Table of ContentsTable of Contents

1 Introduction5

2 Service Design Process6

21 What Is the Service Design Process6

22 What are the inputs to the Service Design Process6

23 What are the steps in the Service Design Process7

24 What are the main characteristics of a service9

3 Communications and connectivity11

31 What is the Connectivity Problem11

32 Published Interface11

33 What are the Tools to help solve the Connectivity Problem12

331 Web Services13

332 JMS Messaging Bridge14

333 Adapters Application Views15

334 Controls16

335 Event Generators17

336 WebLogic Tuxedo Connector (WTC)18

337 HTTP19

338 B2B19

339 JPD Proxy21

34 Recommendations21

341 Consumer Connectivity21

342 Back-end System Connectivity22

343 Internal Communications24

344 General25

4 Data Handling26

41 What is the Data Handling Problem26

42 What are the Data Handling Tools26

421 XQuery26

422 XSLT27

423 Format Builder and MFL27

424 XML Beans28

425 Data Model28



5 Process30

51 What is the process problem30

52 What are the Tools to help solve the Process Problem30

521 Process Properties30

522 Process Management and Monitoring35

523 Patterns46

6 Layered Architecture51

611 The Layers51

612 The Access Services Layer52

613 The Co-ordination Service Layer53

614 The Consumer Service Layer54

615 End-to-End Perspective54

616 Service Repository55

617 Patterns and layers56

7 Appendix58

71 Graphical Examples of the Core Implementation PAtterns58

711 Pattern 1 Basic Synchronous Stateless 2-Way Service58

712 Pattern 2 Basic Asynchronous Stateless 2-Way Service59


714 Pattern 4 Basic Asynchronous Stateful 2-Way Service61


716 Pattern 6 Composite Synchronous Stateless 2-way Service63

717 Pattern 7 Composite Synchronous Stateful 2-way Service64

718 Pattern 8 Composite Asynchronous Stateless 2-way Service65


7110 Pattern 10 Composite Asynchronous Stateful 2-way Service67


72 Web Services Source Code For the Synchronizer PAttern69


Table of FiguresTable of Figures

Figure 1 Integration Service Design Iterative Process8

Figure 2 BES Connectivity Decision Flowchart23

Figure 3 WebLogic Workshop transformations27

Figure 4 Synchronous process start node31

Figure 5 Asynchronous process start nodes31

Figure 6 Stateless process indicator33

Figure 7 Stateful process indicator34

Figure 8 Timeout path39

Figure 9 Exception and message paths42

Figure 10 Compensation example43

Figure 11 De-Synchronizer Service49

Figure 12 Synchronizer Service50

Figure 13 The SOA Platform layers52

Figure 14 End-to-end perspective55

Figure 15 Example of Basic Synchronous Stateless 2-Way service58

Figure 16 Examples of Basic Asynchronous Stateless 2-Way Services59


Figure 18 Examples of Basic Asynchronous Stateful 2-Way Services61


Figure 20 Example of Composite Synchronous Stateless 2-way Service63

Figure 21 Example of Composite Synchronous Stateful 2-way Service64

Figure 22 Examples of Composite Asynchronous Stateless 2-way Services65


Figure 24 Examples of Composite Asynchronous Stateful 2-way Services67



11 INTRODUCTIONINTRODUCTION

This document outlines the best practices and service implementation patterns that fit into a SOA implementation built using WLI 81 Note that this document discusses only design and implementation issues ndash deployment issues are discussed in a separate Deployment document

The document is made up of the following sections

Service Design Process This section discusses the overall design process for SOA services The service design process is part of solution design and starts when the functional requirements and non-functional requirements have been identified for the services that are needed to provide the solution This section does not cover the end-to-end solution design process

Communications and Connectivity This section discusses the communications and connectivity issues when designing SOA services using WLI 81 This includes the definition of the published service contract

Data Handling This section discusses the data handling issues when designing SOA services using WLI 81

Process This section includes best practices for implementing process in WLI 81 using common design patterns

Layered Architecture This section covers the Layered Architecture that is recommended in this document Each layer has a unique set of technical requirements and a unique contribution to the success of the platform

The access layer is responsible for publishing a subset of the BESsrsquo interfaces as a standard service

The co-ordination layer regroups the services that implement the integration logic

The consumer layer is responsible for enabling FESs to access published services in the other two layers when they canrsquot call the services directly


22 SERVICE DESIGN PROCESSSERVICE DESIGN PROCESS

21 WHAT IS THE SERVICE DESIGN PROCESS

For the purposes of this document we will assume that WLI 81 facilities will be used to produce the integration services Services will be built using the support for java process definitions (JPDrsquos) in WLI 81 supplemented with the use of the other capabilities of the WL Platform including the standard J2EE capabilities

Given a particular integration use case solution designers will first break down the use case into a set of services which together will meet the requirements Then the service design process is the set of activities which will result in the design for each of these services A service may or may not access any remote system for example it is feasible that data transformations may be implemented as re-usable services

22 WHAT ARE THE INPUTS TO THE SERVICE DESIGN PROCESS

Typically the following are inputs into the Service Design Process for any given integration use case Please note that although timescales resource constraints and cost constraints could all have an impact on this process they are not included in this section which is focused on the technical aspects of the design process

Functional Requirements These will cover the data inputs data outputs and the required behaviour of the use case in particular in terms of updates to the state of any affected systems in the enterprise All systems involved will be listed as well as all required interactions between them Conditional logic and any other logic flow needed for the service is also part of the functional requirement Ideally the functional requirements will include a description of any required fall-out management

Non-Functional Requirements This will include expected volumetrics required response times availability requirements security requirements and quality of service requirements

WL Integration 81 Documentation This will include all documentation of WL Integration 81 WL Server 81 and WL Workshop 81

Best Practices and Design Patterns This will include any generic best practices and design patterns produced for using WL Integration 81 including this document

Previous Experiences of Solving Integration Problems This covers the collective experiences of the design team members

Repository of Existing Solutions This will include documentation of any existing solutions including services


Service Design Process

Functional Requirements

Non-Functional Requirements

WLI 81 Documentation

Design Patterns and Best Practices

Designer(s) with Previous Experiences

Service Design Solution

Repository of Existing Solutions

Input for Service Design Process

When looking at the non-functional requirements for a use case it is useful to consider the following SMART criteria for such requirements[3]

Specific without ambiguity using consistent terminology simple and at the appropriate level of detail

Measurable it is possible to verify that this requirement has been met What tests must be performed or what criteria must be met to verify that the requirement is met

Attainable technically feasible What is your professional judgement of the technical ldquodo-abilityrdquo of the requirement

Realizable realistic given the resources Do you have the staffing Do you have the skill Do you have access to the development infrastructure needed Do you have access to the run-time infrastructure needed Do you have enough time

Traceable linked from its conception through its specification to its subsequent design implementation and test

High level design guideline Further DetailsNon-functional requirements should fulfill the SMART criteria

It is often the case that you have many requirements that contradict each other or that are described too generically to be ensured of implementation success

23 WHAT ARE THE STEPS IN THE SERVICE DESIGN PROCESS

Given the requirements for a particular service then the service design process can be broken down into the following activities


1 Solve the Communications and Connectivity Issues This includes the definition of the published service interface any connectivity from the service consumer to the SOA platform any connectivity from the SOA platform to the BESrsquos as well as internal connectivity between components within the SOA platform

2 Solve the Data Handling Issues Once the communication and connectivity issues have been identified this will provide data handling requirements that need to be solved through data translations and transformation

3 Design the Process This includes the design of co-ordination logic any sequencing of steps conditional logic and any other execution rules

Figure 1 Integration Service Design Iterative Process

We recommend that these steps be performed in sequence as communications problems may well surface requirements that feed into the data handling and the process design and data handling problems may well surface requirements that feed into the process design

Another reason for looking at connectivity requirements early is that sometimes it will show a need for procurement or development and then acceptance testing of new infrastructure ndash eg controls or adapters This must be identified as soon as possible to enable risk management hopefully to shorten the service delivery timescale

It is possible to achieve parallelism in this process if there are several people involved in the design of a service but then the fact that some requirements for any phase will come out of the other activities needs to be taken into account

The flow above is shown as iterative as it is usually worth revisiting the communications problems after looking at the data handling issues and the process design can impact the decisions made for communications and data handling as well as introducing new requirements in these two areas It is always a very big project risk to enter development without interface documents being approved and signed-off as these feed into the first step of this iterative process

High level design guideline Further DetailsWe recommend that these steps be performed in sequence

Communications problems may well surface requirements that feed into the data handling and the process design and data handling problems may well surface requirements that feed into the process design This also identifies any components that need to be procured or developed early in the project


24 WHAT ARE THE MAIN CHARACTERISTICS OF A SERVICE

Given an end-to-end integration use case such a use case might be broken up into one or more services each of which will need to be properly designed The end-to-end service and any component services are all services A service is going to have a number of characteristics which will be important to the design of the service It will be very important for the designer of a particular service to be able to categorise the service characteristics in each of these areas

First based on the its design a service has a number of properties

1 Complexity

Basic ndash defined as a service with one call to another component1

Composite ndash defined as a service with more than one call to other components

2 Calling Paradigm

Synchronous ndash the consumer of such a service will block waiting for the response while the service completes

Asynchronous ndash the consumer of such a service will not block waiting for the response while the service completes

Mixed ndash this will be a service with a Synchronous part followed by an Asynchronous part

3 Exchange Paradigm

Two-way ndash requestreply

One-way ndash fire and forget

As well as the service properties described above which are decided by the service designer the services have a number of characteristics that come from the non-functional requirements

4 Volume

High ndash more than 100 service calls per second

Medium ndash between 1 and 100 service calls per second

Low ndash less than 1 service call per second

5 QOS (reliability)

At-Most-Once ndash the service guaranteed to be executed no more than once This typically returns a failure to the consumer for them to handle the errorretries

At-Least-Once ndash the service guaranteed to be executed at least once thus allowing for the possibility of duplicates

Exactly-once (aka Once-And-Only-Once) ndash the service is guaranteed to be executed once and only once This typically uses acknowledgement retry and duplicate detection and elimination Where a service involves updates to multiple systems we have two choices regarding the timing of the updates

o They can all be updated within the same distributed transaction ndash all or nothing

o They can be updated independently of each other ndash JMS store-and-forward

1 A component could either be another SOA service or a call to a BES


6 Duration

Very Short ndash between 01 and 10 seconds

Short ndash between 1 and 60 seconds

Average ndash between 30 seconds and 1 hour

Long ndash between 60 seconds and 1 month


33 COMMUNICATIONS AND CONNECTIVITYCOMMUNICATIONS AND CONNECTIVITY

31 WHAT IS THE CONNECTIVITY PROBLEM

The first consideration when looking at an integration use case is what are the communication or connectivity problems that need to be resolved

1 Back-end System Connectivity ndash which back-end systems (BES) need to be called and how

2 Consumer Connectivity ndash how will the front-end system (FES) or service consumer invoke the service

3 Internal Connectivity ndash what internal communications within the SOA platform might be needed in order to resolve the end-to-end use case

Note that key characteristics of connectivity include

Protocols Used eg RMI HTTP IIOP etc

Direction of Connectivity

The Calling Paradigm used for Connectivity

o Synchronous ndash the consumer of such a service will block waiting for the response while the service completes

o Asynchronous ndash the consumer of such a service will not block waiting for the response while the service completes

o Mixed ndash this will be a service with a Synchronous part followed by an Asynchronous part

Exchange Paradigm

o Two-way ndash requestreply

o One-way ndash fire and forget

Transactional Support This includes support for propagating transactions

Data Format(s) supported eg XML FML32 ndash this feeds into the next section on Data Handling for the service

32 PUBLISHED INTERFACE

A published service interface is an interface for a service that can be requested from outside of the SOA platform The protocol options available used to make the call depend on the process design It is this request that initiates the service Note that it is decisions about loose coupling and maintainability that should drive the definition of published interfaces

The service request may be made using many different protocols andor technologies See the sections below on the various technologies for discussions around this


High level design guideline Further DetailsThere should be a repository of existing published interfaces

This should include words describing services especially in terms of side effects updates etc This should include internal services as well

All services in this repository should be specified in a standard way

This should include service design requirements implementation characteristics key design decisions etc

33 WHAT ARE THE TOOLS TO HELP SOLVE THE CONNECTIVITY PROBLEM

The following WL Integration 81 features are all relevant to connectivity

Web Services

JMS Messaging Bridge

Adapters Application Views

Controls

Event Generators Message Broker

WTC

Raw HTTP

B2B (ebXML RosettaNet)

JPD Proxy

The table of Technologies with Connectivity Characteristics below gives a high level view of the possible options Section 33 discusses each of the features in turn considering the following uses

Consumer connectivity

Back-end system connectivity

Internal connectivity

Section 34 contains recommendations


SynchAsynch

Trans-actional

Security Notes

Web Services over HTTP

Both No Yes

Web Services over JMS

Asynch Yes2 Yes Connection pooling through MDB pool size for the JMS destination

JMS and Messaging Bridge

Asynch Yes Yes Connection pooling through MDB pool size

Adapters and App Views

Both Yes Yes

Controls Both Both Yes3 Connection pooling dependent on resource control is accessing eg JDBC

Event Generators

Asynch Yes4 No Connection pooling through MDB pool size

WTC Both Yes Yes Security propagation can be enabled with TUXEDO 71 and above

Raw HTTP Synch No Yes

B2B Asynch Yes Yes

JPD Proxy Synch Yes Yes

Table of Technologies with Connectivity Characteristics

331 WEB SERVICES

The Web Services standards currently do not support Transactions although standards are emerging in this area Web Services Security and Web Services Reliability are two additional areas where standards are still emerging Web Services are most often exposed over the HTTP protocol for best effort delivery or idempotent operations and JMS for guaranteed delivery

3311 CONSUMER CONNECTIVITY

Daryl Plummer of Gartner writes that ldquoOne of the most valuable aspects of Web services is the use of WSDL as the interface definition language (IDL) for publishing interfaces Most interface description languages are tied to a language (such as Java) or to a component model (such as CORBA) WSDL on the other hand is language and model independent Interface definitions are separated from the underlying technology just as the interfaces are separated from the implementation You can use WSDL descriptions with any SOA environmentrdquo

So Web services have a means of describing the published interface for a service using a standard ndash WSDL ndash which makes such services easily accessible from most consumer 2 The Transaction does not include the caller of the Web Service3 Controls will be executed using the Processrsquos Security credentials4 The Transaction semantics covers delivery to the subscribersrsquo delivery queues


environments Typically modern consumer systems will be able to take the WSDL for a service and generate their service consuming code for Web Services BEA Workshop can be used to generate the Web Service proxy class for WebLogic Web Services and for WebLogic Integration processes

3312 BACK-END SYSTEM CONNECTIVITY

For calls from a SOA Platform to BESrsquos that expose a Web Service interface Web Services is an option for this connectivity but noting the lack of standards around reliability transactions and security propagation through Web Services this area is still immature at this point Increasingly BESrsquos are exposing Web Services

3313 INTERNAL CONNECTIVITY

For interactions within the SOA Platform particularly in a distributed architecture the use of web services will become increasingly important Note that the web services stack is expensive in terms of marshalling and there is no way to propagate transactions through a web service call which are important limitations It is currently very easy to use Web Services for internal connectivity both within a WL Integration 81 domain and between WL Integration 81 domains

332 JMS MESSAGING BRIDGE

JMS is a J2EE subsystem to enable decoupled messaging WL Platform also includes a feature for bridging between local queues and remote queues calling the Messaging Bridge Using a Messaging Bridge the remote queues can either be JMS queues in remote WLS domains JMS queues in remote non-WLS environments or even non-JMS queues in remote non-WLS environments eg MQ Series In terms of supporting connectivity JMS is supported as a means of accessing any J2EE platform and many MOM products have JMS interfaces JMS can be configured to support various qualities of service (QOS) as described above including At-Most-Once Exactly-Once although these also depend on the receiving systemrsquos capabilities

The Messaging Bridge is needed for connecting to remote queues because any JMS access is local to the client The store-and-forward capabilities of the Messaging Bridge insulate local processes from problems with access to remote providers Thus the Messaging Bridge is configuration that maps the local representation to some external queue


A service consumer can use JMS and the Messaging Bridge for the asynchronous invocation of SOA services if that system is able to post messages to a JMS request destination If service responses are needed then there will be a need for the service consumer to listen for messages on a JMS response destination and to be able to correlate the responses to the requests There will be a need for the consumer and the SOA platform service to agree on some data either in the header or the body of the messages to enable this correlation


For completely decoupled or loosely coupled asynchronous messaging between the SOA platform and a BES JMS and the Messaging Bridge can be used For loosely coupled messaging ie where responses are needed then there will be a need for the service implementation to listen for messages on a JMS response destination and to be able to correlate the responses to the requests There will be a need for the service implementation and the BES to agree on some data either in the header or the body of the messages to enable this correlation



In WL Integration 81 (and WLI 70) JMS is heavily used for decoupled messaging between processes and it can also be used for buffering service requests andor service responses For messaging between WL Integration 81 domains the Messaging Bridge is a viable option which supports all of the possible Quality of Service (QOS) options For services with a QOS requirement of At-Most-Once non-persistent queues can be used

Location independence can be achieved using JMS because it is at deployment time that the location of JMS destinations is decided

333 ADAPTERS APPLICATION VIEWS

WL Integration 81 includes support for both standard J2EE CA 10 adapters as well as adapters which support BEArsquos proprietary Application Integration (WLAI) extensions

Standard J2EE CA 10 adapters can be used for exposing functionality within an Enterprise Information System (EIS) but not for enabling calls from that EIS to other services The J2EE CA 15 specification [2] includes support for events as well as synchronous andor transactional calls from an EIS through J2EECA adapters into an application server

In contrast to the J2EE CA 10 adapters WLI 81 adapters include support for BEArsquos WLAI extensions including

Support for events

The ability to define the adapter connectivity settings adapter services and adapter events in an application view using a GUI

Support for asynchronous invocation of services

Adapters are written to make use of whatever mechanisms are made available for interfacing with a specific BES This means that the communication and connectivity options available are constrained by the BES integration capabilities

Adapters will differ in terms of the transactional semantics as well as support for security propagation to the BES Adapter services and events are able to support transactions if the EIS is transactional and the adapter supports it

As noted above WLI 81 adapters include support for application views An application view provides a layer of abstraction on top of an adapter whereas adapters are closely associated with the specific functions available in the EIS an application view is associated with business processes that must be accomplished by clients The application view converts the steps in the business process into operations on the adapter

The Application View control allows your web service or business process to access an enterprise application using an application view


In WL Integration 81 a service consumer can use event adapters for the asynchronous invocation of SOA services If service responses are needed then there will be a need for the service consumer to either listen for messages on a JMS response destination or to expose a call-back service In either case there will also be a need for the service consumer to be able to correlate the responses to the requests There will be a need for the consumer and the SOA platform service to agree on some data either in the header or the body of the messages to enable this correlation


In WL Integration 90 service consumers will be able to take advantage of the new support for synchronous inbound communications using adapters


It is in the area of connectivity between a service and the BESrsquos that adapters are most important WLI Adapters in WLI expose services against the BES with an XML-in XML-out service interface This functionality is offered by the application views These services can then be invoked synchronously or asynchronously using BEArsquos WLAI framework WLI Events can also be used for communication between a BES and a SOA service implementation for example for the delivery of asynchronous responses or to deliver unsolicited updates for a long-running BES process


The only viable use of adapters for internal communications within WLI 81 is the (hidden) usage of JMS adapters by the Messaging Bridge Different JMS adapters have been written for the various versions of WLS Note that when interoperating with versions of WLS older than WLS 7 not all messaging QOS options are possible

334 CONTROLS

Controls are reusable Workshop components providing a common interface that can be used within one or more process definitions These can be the interface between SOA layers or components within a layer for example data transformations Controls can be used within a process definition to make calls to a BES eg the Database control allows a process to send SQL to an RDBMS using a JDBC Connection Pool

Below please find a listing of Controls available within WL Integration 81 which are categorised as being either Transactional or Non-Transactional Some of these are defined in the Glossary All are documented at the following URL - httpedocsbeacomwlidocs81indexhtml The transactional nature of these controls and this is essential knowledge for the process developer using the controls

Transactional Controls Non-Transactional Controls

Database

JMS

WLI JMS

Application View (if JCA adapter is transactional)

Worklist

Timer

EJB

Message Broker

Transformation

Process Control

TUXEDO

File

E-mail

Service (JWS)

Service Broker5

RosettaNet

EbXML6

HTTP (dev2dev)

Application View (if JCA adapter is not transactional)

The Controls listed above are all documented in the Workshop Help Pages

5 If a request is buffered the buffer part if transactional6 JMS is used under the covers so it could be argued that these are transactional up to a point


httpedocsbeacomworkshopdocs81docencoreindexhtml

Using a transactional control against a non-transactional resource will mean that the work done against the resource will be outside of the transaction

It is also possible to write custom java controls These can either be written to wrap other controls or to implement new functionality

To the client these controls appear no different to those in the table above


This is not an area where controls will be used much except for WL Platform consumers which can make use of controls to access services using the Service Control the Process Control etc The Message Broker control enables application view events published to a Message Broker channel to start services asynchronously


This is also an area where controls will be heavily used in particular the Database Control the EJB Control the TUXEDO Control the File Control the HTTP Control and the Application View Control which will enable processes to invoke BES services defined using adapters


This is an area where controls will be heavily used in particular the Message Broker Controls the WLI JMS Control the Process Control the Service Control and the Service Broker Control which all enable processes within WLI 81 to communicate with each other

335 EVENT GENERATORS

Event Generators can be used together with the Message Broker to enable asynchronous messaging between various event sources and WLI 81 BPM services

There are several Event Generators available for WLI 81 including the following

JMS

File

Timer

Email

HTTP (dev2dev ndash will come out as part of WLI 81 SP3 and will be included as part of WLI in WLI 90 as well)


In WL Integration 81 a service consumer can use event generators (via the Message Broker) for the asynchronous invocation of SOA services If service responses are needed then there will be a need for the service consumer to either listen for messages on a JMS response destination or to expose a call-back service In either case there will also be a need for the service consumer to be able to correlate the responses to the requests There will be a need for the consumer and the SOA platform service to agree on some data either in the header or the body of the messages to enable this correlation


Event Generators can be used to deliver asynchronous response messages from a BES to a service implementation in WL Integration 81 or to deliver unsolicited notifications For both


of these scenarios there will be a need to correlate the responses with a specific service implementation instance There will be a need for the service implementation and the BES to agree on some data either in the header or the body of the messages to enable this correlation


The only viable usage of Event Generators for internal communication between services in WL Integration 81 would be the JMS Event Generator which could be used together with JMS andor the Messaging Bridge for communications between services JMS could be used for messaging within a domain and the Messaging Bridge enables this messaging to be extended between domains

336 WEBLOGIC TUXEDO CONNECTOR (WTC)

WebLogic Tuxedo Connector (WTC) is a feature of WL Server 81 (and therefore of WL Integration 81) which can be used to enable bi-directional communications between WebLogic and TUXEDO Note that this can be used for ATMI or CORBA communications In WL Server 81 there is a TUXEDO Control which can be used for calls from WLS to TUXEDO services


For service consumers which are connected to TUXEDO or which are based on TUXEDO (eg Clarify) then WTC is a viable option for providing connectivity between the service consumer and the WLI 81 SOA Platform


Where TUXEDO services or eLink services are a means of accessing BES functionality then WTC is a viable option for providing connectivity between a service implementation in WLI 81 and the BES


WTC would not be used within a WL Integration 81 domain or between WL Integration 81 domains

337 HTTP

HTTP is a technology used by several FESrsquos and BESrsquos to enable outbound andor inbound connectivity Major limitations are in the area of transaction support A HTTP client will block on a reply but you have no guarantee of the return For example the reply may have been sent back to the client but fail to get through due to network problems this would then be seen as a failure at the client once it times out but this could be seen as successful at the provider end To overcome this you need to implement idempotent services or implement some guaranteed delivery protocol like that offered by the B2B protocols

This section covers HTTP when not used for SOAP HTTP Web services with interfaces defined using WSDL which will be referred to as raw HTTP


The HTTP Event Generator is the WLI 81 means of enabling FESrsquos to access services over raw HTTP currently for an asynchronous invocation although in future there might be support for synchronous invocation of SOA services on WLI 81 as well through this



The HTTP Control is the WLI 81 means of enabling raw HTTP access to BESrsquos


Raw HTTP would not be used for communication between WLI 81 services

338 B2B

B2B is also known as Trading partner integration WebLogic Integration supports the following B2B protocols and standards

ebXML 10 and 20 which is described in Introducing ebXML Solutions

RosettaNet 11 and 20 which is described in Introducing RosettaNet Solutions

These standards ensure the private secure and reliable HTTP(S) business message exchanges among trading partners using transport level security with SSL and message level security with digital signature and encryption

The main issue with raw HTTP is that you cannot guarantee that the HTTP response gets back to the caller To a service it has finished when it responds but it does not know if this response gets back or not In the case where it does not get back the caller will time out and may resend but the service has already run to completion so risks being executed again The diagram below shows an example B2B 2-way asynchronous message exchange

Example B2B 2-way asynchronous message exchange

The Buyer sends (1) a request PurchaseOrder to a Seller and recives the usual HTTP 200 response The Seller will validate and persist the PurchaseOrder document and then responds with a ReceiptAcknowledgment HTTP message (11) It is only when the Buyer receives the ReceiptAcknowledgement and the Seller has successful delivery of the ReceiptAcknowledgement that both parties know the PurchaseOrder was sent successfully This ensures that both parties know the message got through and was persisted thus guaranteeing exactly once delivery The underlying B2B protocol adds timeouts for each step


unique conversationmessage IDs to allow retries and to ensure duplicate message elimination

Controls exists for both ebXML and RosettaNet to allow processes to initiate a B2B conversation the participants are implemented as standard processes (JPDrsquos)

WebLogic Integration tracks the flow and state information of business messages that are sent to or retrieved from other trading partners You can view run-time data and statistics on the Message Tracking module in the WebLogic Integration Administration Console to perform real-time monitoring process analysis troubleshooting and reporting for business messages


The use of B2B needs both consumer and provider to implement the standard which limits the number of systems that can use this as a connectivity option Due to the heavy weight implementation it is generally a strict requirement for secureprivate and reliable messaging over HTTPS that dictates a B2B standard is needed This is more applicable where the consumer sits outside of the secure enterprise boundaries It is possible to skip the secure delivery and use pure HTTP that will guarantee exactly one delivery but avoid most of the performance overhead that SSL (HTTPS) gives


This is rarely used for back-end connectivity due to the nature of the standards and that generally these BES are in a friendly location where security is not so strict an issue


This could be used to guarantee HTTP messages over a WAN Although traditionally these protocols are heavy in resources this is partly due to the security elements like SSL (HTTPS) If you want reliable messaging without secure delivery this can be implemented without SSL (HTTPS)

339 JPD PROXY

A JPD Proxy is an RMI client to a business process (JPD) An interface that matches a business process client requests is associated with each business process This interface is called the JPD public contract Each method on the JPD public contract has the same signature as the corresponding client request A JPD Proxy is a JAR file containing the compiled class file for the JPD contract You can use the class file to access the business process (JPD) as though it were a local Java class JPD Proxy calls are over Java RMI

One advantage that JPD Proxy calls have is that they can be used to propagate the transaction context from the clients to the business processes On the other hand that there is no support for callbacks using JPD Proxy


The JPD Proxy would be applicable for java-based front end systems The JPD Proxy used RMI which would need to be available as a protocol between the FES and the SOA platform



The JPD Proxy would only be applicable here if a BES was accessed through a separate WLI 81 Domain (see internal connectivity below)


The JPD Proxy could be used for RMI calls to JPDs on remote WLI 81 domains

34 RECOMMENDATIONS


High level design guideline Further DetailsFor asynchronous published service interfaces use JMS or Web Services over JMS

Because JMS is a standards-based technology multiple client platforms will be able to write to and listen to JMS queues

For FESrsquos that cannot obey published asynchronous interface rules an intermediate service should be written to offer them an interface they can obey and map this to the published interface

Some FESrsquos will be unable to write to JMS EventGenerator can be used in

many cases ndash File Email HTTP RDBMS MQ

Adapter Events for many other EISrsquos

WTC for TuxedoQ

For synchronous best-effort published service interfaces use Web Services over HTTP

Because Web Services is a standards-based technology multiple client platforms will be able to consume Web Services

For FESrsquos that cannot obey published synchronous interface rules an intermediate service should be written to offer them an interface they can obey and map this to the published interface

Some FESrsquos will be unable to invoke Web Services over HTTP

For Java-based FESrsquos the JPD Proxy is a valid means of accessing services synchronously

In the next version of the J2EE CA standard ndash version 15 [2] ndash there is support for synchronous calls from an Enterprise Information System (EIS) into an application server using an adapter There is also support for transactional calls from an EIS into an application server using an adapter

For Tuxedo based FESrsquos use WTC jATMI

For synchronous exactly-once published service interfaces implement using B2B or 2-way Asynchronous

Blocking protocols do not provide exactly-once semantics as the network could fail on reply This can be solved using a B2B (ebXML RosettaNet) protocol specifically designed to overcome this or a 2-way Asynchronous published interface should be used

Verify consumer non-compliance with published interface before writing a consumer layer service

Sometimes it is possible after discussion with the team responsible for the consumer application to solve perceived non-compliance issues in the consumer


application itself


High level design guideline Further DetailsPlease see the flowchart below This flowchart outlines the decision steps

when looking at BES connectivity

Where a particular BES can expose services using multiple different connectivity options then the recommendations above for consumer connectivity apply

It is always best if a BES offers interfaces matching the SOA published interfaces as this limits integration to be done

Where a connectivity solution already exists in the enterprise then the strategic suitability of the solution needs to be taken into account

Some connectivity solutions will over time become unsupported or will fall outside of the enterprisersquos strategic roadmap

Existing connectivity solutions for previous releases of WebLogic should not automatically be migrated

New or changed functionality in the new WebLogic release may provide a better connectivity solution

The BES owner should be consulted during any BES connectivity solution selection process

Particularly when a BES is a COTS package the vendor of the BES may be asked to support the connectivity solution so the roadmap for that COTS package needs to be taken into account This will also be true for bespoke customer-written BESrsquos


Figure 2 BES Connectivity Decision Flowchart

Worked Example for MQ Series connectivity

Assumptions

1 We have an existing connectivity solution to MQ Series in the enterprise

2 We have a particular requirement that is not met by this connectivity solution

3 The solution we have is a product from a vendor which we do not have the source code for nor is it possible to ask the vendor for changes

Based on a set of arbitrary assumptions above we have outlined the decisions taken based on the tree above in the table below


Connectivity already Exists in enterprise Yes Assumption 1 above

Meets requirements No Assumption 2 above

Can it be extended No Assumption 3 above

EIS preferred interface matches technology control

Yes New MQ Control in 81 SP3

Meets requirements Yes The particular requirement is supported in the new MQ Control

So the conclusion is to use the new MQ Control

Note For a solution that does not have any adapter or control available we enter the lower branch of the decision tree At this level it is very much a decision based specifically on the individual requirements and often decisions are made based on skill set of teams available to complete the work as this is bespoke development This development could be to implement a J2EE component like an EJB create a custom adapter or control or modify the BES system

343 INTERNAL COMMUNICATIONS

High level design guideline Further DetailsFor asynchronous communications between processes in different domains we recommend the use of JMS and the Messaging Bridge together with the JMS EventGenerator or Web Services over JMS

The Messaging Bridge supports all of the QOS options for asynchronous messaging between the domains The store-and-forward capabilities of the Messaging Bridge insulate local processes from problems with access to remote providers

For asynchronous 2-way communications between processes in the same domain we recommend the use of the Process Control rather than the Message Broker

You get approximately the same performance when starting a process using the process control or the message broker but it is significantly faster to receive a process control callback than a message broker subscription The message broker subscription filter mechanism uses a database to map the filter values to process instances Process control callbacks are routed directly to the process instances

Use raw JMS where the message size is large JMS is more efficient than marshalling large messages in web services

For synchronous communications between processes in the same domain if a transaction must be propagated between processes or performance is an issue use the process control not the service control or service broker control

The process control is transactional and avoids SOAP marshalling The service control and service broker controls are not transactional

For synchronous communications between processes in different domains you have to use the service control service broker control or the JPD Proxy

The process control can only be used within a domain The JPD Proxy provides transactional propogation at the cost of tight coupling The service control and broker donrsquot provide transaction propogation but do enable loose coupling

Use the service broker control rather than the service control or process control if the data-dependent routing

The service broker control allows for configurable routing of service calls to


facilities this offers are needed different service implementations depending on data but note that it is not transactional

344 GENERAL

High level design guideline Further DetailsControl reuse All controls should be written with a focus

on being reusable across process definitions They should also be defined in the SOA Component inventory

Custom controls development should be done with consideration of native WLI 81 controls

Maximum use of the controls available in WLI81 should be made and bespoke controls should be written only when necessary and the re-use has been clearly justified

Custom Controls should be used instead of custom java code if reuse of this code is a consideration

Creating a control for custom java code means that this code can be reused across different process definitions EJBrsquos can also be created for reuse of business logic

Controls should be versioned in source code control Controls should be treated as java code and versioned appropriately

Each application project in workshop should have a separate control project

Controls should be imported from the SOA component library into this project They then become available to all the application

Each process should carry out logging using a standard logging control

This will provide ability to log to different locations and at different logging levels


44 DATA HANDLINGDATA HANDLING

41 WHAT IS THE DATA HANDLING PROBLEM

When the communication or connectivity decisions have been made and signed-off then the next major step in designing a service is to solve any data handling problems

Key questions that need to be asked at this stage include

What data formats will be used for the published service interfaces

Can the service consumers use the data formats used for the published service interfaces

What data formats will be needed for calls or events between the SOA platform and BESrsquos

What data formats will be used internally within the SOA platform

What data integration requirements exist within the use case

If there are differences in the representation of data at various points in the execution of a service then appropriate data mappings andor data transformations will be needed Sometimes this data mapping will need to include primary key mapping functionality Data transformations allow for the data models of the FES and BES to be decoupled

High level design guideline Further DetailsData integration requirements in the use case are typically solved at the process layer These include problems like data synchronisation key mapping and unusual transactional requirements

The reason for a solution in the process layer is that often co-ordination is needed across multiple resources and the requirements are quite often specific to a use case and so canrsquot be solved generically

42 WHAT ARE THE DATA HANDLING TOOLS

The following are features that could be used to solve data handling problems within WLI 81

XQuery

XSLT

Format Builder MFL

XML Beans

Data Model

421 XQUERY

Within WLI 81 processes it is possible to achieve the following types of transformations using XQuery

Several Typed Variables =gt One Typed Variable

Where the Typed variables can be any of the following

XML messages defined by a XML Schema (defined using XML Spy or any other similar tool for authoring XML Schemas)

Non-XML messages defined by a MFL format (defined using Format Builder)


Complex java objects defined by a class definition

Java scalars eg String

Figure 3 WebLogic Workshop transformations

Within WLI 81 all typed variables are represented internally as a token stream which allows for performant mapping and transformation to other types

Note that as shown above you can have multiple variables as input for a data transformation method but only one output variable can be created This means it is possible to achieve data merging data mapping and data transformations within a single transformation control method To achieve splitting would require calls to multiple transformation control methods

If you want to use the graphical XQuery mapping tool for XML documents defined using DTDrsquos where no XML Schema exists you need to convert the DTD files to W3C XSD files (using a tool like XML Spy Enterprise Edition) and then import the XSD files into your project

422 XSLT

For XMLXML data transformations WLI 81 also supports XSLT Note that XSLT is supported for backward compatibility with previous versions of WLSWLI

XSLT support can also be accessed using Java API calls

423 FORMAT BUILDER AND MFL

Non-XML messages can be represented using MFL (Message Format Language) which is an XML syntax developed by BEA for the mapping of non-XML data formats into XML schemas WebLogic Integration 81 includes Format Builder as the GUI tool for creating and testing MFL format definitions Note that any format represented by an MFL will have two representations ndash either the non-XML format or a XML equivalent format which are interchangeable within the Workshop tool When an MFL document is added to a Workshop applicationrsquos Schemas project an XML Schema is generated for the XML equivalent representation (and XML Beans are created as well) so within the processes you can have


variables which are strongly typed XML variables adhering to this Schema as well as having variables which are strongly typed nonXML variables adhering to the MFL format

424 XML BEANS

Key to the development of processes web services and other Platform artefacts in support of services is a BEA technology that has been submitted to Apache (httpxmlapacheorgxmlbeans) called XML Beans XML Beans are a native supported part of WL Platform 81 although they can also be downloaded from Apache at the following URL

httpxmlapacheorgxmlbeanssourceAndBinaries

XML Beans can therefore be used within WLI 81 service development and they can also be used on an open source basis in non-WebLogic java environments XML Beans enable java programmers to deal with an XML document as a first-class Java object Any XML Schema that is added to a WebLogic Workshop applications Schemas project is compiled into XML Beans for GUI manipulation of variables defined using that schema as their type This means that while developing processes web services or java page flows XML documents can be graphically manipulated and also code completion is available within the source view to enable direct manipulation of XML documents via the XML Bean methods

425 DATA MODEL

A data model can be referred to by many names including Common Data Model Canonical Data Model Corporate Data Model Enterprise Data Model etc

Regardless of what it is called the aim for an enterprise or integration solution is for data to be mapped as early as possible to a ldquostandard formrdquo If correctly implemented such a data model provides the services with an EIS neutral interface It specifies how to map reference static and identifier data from an EIS data format to a ldquostandard formrdquo decoupling the hostrsquos data model from the data model of the recipient

The successful implementation of a common data model relies on enterprise ldquobuy inrdquo and rigid enforcement If this is not the case then over time several versions will evolve and co-exist and little or no benefit will be realised This will also come at a heavy maintenance cost

We would recommend as a first and quick gain to create standards for the service interface This would mean enforcing common representation of certain data types and entities within the enterprise For example always represent dates numbers postcodes and addresses in a consistent way

43 RECOMMENDATIONS

High level design guideline Further DetailsFor new data transformations we recommend that these should always be created using XQuery rather than XSLT

XQuery has many advantages over XSLT including additional functionality and better performance

Use a Data Model (EDM or CDM) only where there are clear benefits that offset the additional cost and complexity and the organisation is fully committed to its implementation and maintenance

A Data Model can consume large amount of resources without real benefit If an industry data model can be used then this saves on the data modeling exercises

Due to the high cost and social challenges of implementing a Data Model a quick return is to implement standards at the interface

This is to ensure that data is represented consistently across all service interfaces For example dates postcodes addresses


are always represented in the same wayThis also includes standard message headers etc

The recipient of a message should have no knowledge of the origination of the message

If a data model or standard service interface is appropriately implemented the recipient of a message should not have to know the data format of the sending system

Any re-usable transformation should be wrapped as stateless process

This allows other components to call it as a service Including direct calls from a FES

XQuery should be used wherever possible as they enable re-use at the control level

XML Beans overlap with XQuery in functionality but become part of the source of any process implementation


55 PROCESSPROCESS

51 WHAT IS THE PROCESS PROBLEM

When both the connectivity and data decisions have been made the logic needs to be considered The key problems at this stage are

How to implement the logic

How to organize it

52 WHAT ARE THE TOOLS TO HELP SOLVE THE PROCESS PROBLEM

Services will be built using the support for java process definitions (JPDrsquos) in WLI 81 supplemented with the use of the other capabilities of the WL Platform including the standard J2EE capabilities

This section will first discuss the different ways a process can be designed (process properties) then discuss the tools available to the process designer (process management and monitoring) and finally at the different process patterns available to the process designer

521 PROCESS PROPERTIES

Processes can be of different types and are designed with to the following intrinsic properties

Complexity basic or composite

Calling paradigm synchronous or asynchronous

State stateful or stateless

Exchange paradigm 2-way or 1-way

This section details each characteristic The pattern section discusses the possible combinations of these characteristics into actual processes

5211 COMPLEXITY (BASIC AND COMPOSITE)

A process may be basic or composite

A basic process is defined as a process that makes only one call out to another service or an external system A basic process normally does not contain complex logic but may contain any number of steps for transformation exception handling

A composite process has two or more calls out to external systems A process that makes two calls out to a single BES is still said to be composite Composite processes may contain complex logic such as parallel calls out client requests after the start node etc Note that composite processes because of the multiple calls have more complex exception management

5212 CALLING PARADIGM

A process is differentiated by the way it is called synchronously or asynchronously

Synchronous

A process is called synchronously if its Starting Event is a Client Request with Return (See the diagram below)


Figure 4 Synchronous process start node

The Client Request with Return is a group More nodes can be added inside the group between the request and the return This group is forced to be contained within one single transaction This means that the group cannot contain any call waiting (such as control return timer timeout etc)

Typically all the process nodes are implemented before the return inside the group in which case the process is always stateless However it is possible to add nodes after the client return in which case the process may be stateful For example you may have an order process that has to return an order number to the caller and then continue This can be a single process that has a synchronous start which will return when the order number has been obtained but then continue asynchronously with the provisioning of the order

Asynchronous

A process is called asynchronous if it is invoked by an asynchronous method In other words an asynchronous node represents the Starting Event This includes processes that are invoked via a Client Request node a Subscription node or an Event Choice node The Synchronous Subscription node is a hybrid of asynchronoussynchronous

Figure 5 Asynchronous process start nodes

Client Request nodes represent the points in a business process at which a client invokes a method on the business process and possibly sends input to the business process

Subscription nodes represent the receipt of an asynchronous message from a Message Broker channel You create a static subscription to a Message Broker channel on this node This option also allows you to start your business process via an event through File JMS Email or Timer controls which facilitate publishing events to Message Broker channels

Event Choice node combines two or more Client Request and Subscription


Synchronous Subscription is a special case For the implementation it is similar to a Client Request with Return it is contained within one single transaction and waiting logic is not allowed within the group However if the call goes through an event generator (for all cases except a call from a message broker control) the process is still de-coupled and asynchronous Synchronous subscription also differs from the Client Request with Return in that it does not include any reply to the client The end of the group is NOT a publication back to the client as one might expect The synchronous aspect is only relative to the thread that calls the process within the engine not to the original caller For example if the subscription is JMS then the original publisher is not blocked only the event generator publisher is blocked until the dynamic subscription and any other logic within the synchronous subscription block is executed

High level design guideline Further DetailsAsynchronous 2-way processes should establish a way to pass exception or errors back to the caller process with a separate client response or publication node in the exception handler

When an error or an exception occurs it is possible to catch an exception within the process However asynchronous processes by nature cannot rethrow exception However the caller should be informed that the process did not complete successfully

An asynchronous reply control should always have a timeout method implemented

It is best practice to always enable a process to finish Whenever a process has to wait for a reply it should never be assumed it will return a timeout path should be implemented even if the time is set very large In the timeout path actions will include steps to ensure that alerts will be raised and can provide steps for manual intervention eg writing logs which are in turn monitored using log monitors or writing to a JMS error queue raising a task on a support person etc

When a quick response time is needed for a service then synchronous processes are often more suitable than asynchronous processes

In general this should only be considered for services involving quick response times from BESrsquos which can cope with peak volumes without the response times growing a lot The only case where this would be suitable for services involving longer response times from BESrsquos would be when the service is called in low volumes

An asynchronous subscription start pattern is recommended over the synchronous subscription start

The asynchronous subscription causes the subscribed process to run in a different transaction from the publishers transaction By contrast the synchronous subscription decreases loose coupling and can associate the results of a transaction rollback of one subscriber with an otherwise independent subscriber

5213 PROCESS STATE

Stateless

A stateless process is a process that is executed in memory only and does not persist its state in the database In technical terms it is compiled into a stateless session bean

Stateless processes are intended to support business scenarios that involve short-running logic and have high performance requirements Because it does not persist its state to a database it is optimized for lower-latency higher-performance execution An example of a stateless process is one that receives a message asynchronously from a client transforms the message and then sends it asynchronously or synchronously to a resource using a control Another example is a process that starts with a message broker subscription transforms a message and


publishes it to another message broker channel Such a process is analogous to the kinds of routing rules used by traditional message brokering or message routing system

Because stateless processes are compiled into stateless session beans and because these stateless session beans are reused at run-time in order to provide the performance advantage enjoyed by stateless processes some care is required when working with variables If a default value is specified for a variable in a stateless process that variable will only be initialized the first time the process is run Subsequent process instances will reuse the same stateless session bean instance and therefore will inherit the last known value of the variable in question

You cannot explicitly configure a process to be stateless By default a business process is Stateless until you add any blocking construct to the data flow such as waiting for a reply or a message This in turn forces a transaction boundary and the process becomes stateful Therefore a process is stateless if it runs within only one transaction You know when a process is stateless when the process start node at the top of your process has a white ring as follows

Figure 6 Stateless process indicator

High level design guideline Further DetailsDo not use default values in global variables unless the variable is either declared static or final Do initialize all global variables before using them

Stateless processes are implemented as stateless session beans After a process finishes subsequent process instances will reuse the same stateless session bean instance and therefore will inherit the last known value of the global variables

For synchronously called processes where the requestor needs to handle transaction demarcation the on sync failure property on the process must be set to rethrow

This property only applies to your process if it is configured to be a synchronous subprocess it is ignored for any other business processes If a synchronous subprocess fails the default behavior is to mark it as rollback which causes both the subprocess and the parent process to rollback However if the on sync failure property is set to rethrow only the subprocess is rolled back

Stateful

A stateful process is a process that runs within the scope of more than one transaction The process has persistent state in the database The process is compiled into an entity bean

Stateful processes are intended to support business scenarios that involve complex long-running logic and therefore have specific reliability and recovery requirements A process is made stateful by the addition of stateful nodes or logic that forces transaction boundaries (see Transaction Boundaries) For example a process that receives a message transforms it sends it to a business partner and then waits for an asynchronous response is stateful because the act of waiting forces a transaction boundary

The list of nodes which when used induce a quiescent point are

Control receive


Event choice (except as a start node)

Parallel branching

Some controls typically require a control receive and therefore will force a process to become stateful A non-exhaustive list of such controls follows

Worklist

Timer

Asynchronous 2-way process

JMS subscription

Message Broker subscription

Stateful processes because they have state in the database have lower performance than the memory-only stateless processes However the persistence of the state is necessary to ensure that

The process can recover and continue execution without loss of data in the event of a system outage during this waiting period

System resources are used efficiently during this waiting period During this time the entity bean may be passivated which will free memory on the server

You cannot explicitly configure a process to be stateful You know when a process is stateful when the process start node at the top of your process has a green ring as follows

Figure 7 Stateful process indicator

5214 EXCHANGE PARADIGM (ONE-WAY AND TWO-WAY)

A process may be two-way or one-way for the interactions with its client

A two-way process is a process that returns a reply to the client The reply is automatically linked to the request when using Client Request with Return or a combination of one Client Request and one Client Return However correlation between the request and the reply must be implemented in the case of a Subscription This can be implemented in a number of ways depending on the scenario

Because of this difference it is usually difficult to implement 2-way processes that support both a client request and a subscription In this case the return type and value becomes dependant upon the way the process is called It is usually easier to implement this as two processes ndash the first as a process with a client request and client return and then the second process a simple wrapper with a subscription publication interface

A one-way process is a process that accepts notifications from the client but do not send replies It is used to implement the event management use-case Obviously one-way processes can only be asynchronous

A 2-way asynchronous pattern can also be implemented using two 1-way asynchronous processes The first 1-way asynchronous process takes the inputs for the service from the


FES transforms as required and routes to the appropriate target BES The second 1-way asynchronous process is kicked off by the target system now acting as a FES the process transforms as required and routes the response to the original FES now acting as a BES

High level design guideline Further DetailsIt is not advised to implement a 2-way process with an event choice that is a combination of client requests and subscriptions

It is usually easier to implement the process with the client request and client return It is then possible to use a simple wrapper around this process with a subscription publication interface

A 2-way asynchronous pattern is more performant to implement using two 1-way asynchronous processes

This is only possible where the requestreply are decoupled - reply branch does not need any information held in the request branch

522 PROCESS MANAGEMENT AND MONITORING

Having looked at the characteristics of a process in the previous section this section discusses other aspects of a process that need to be considered when implementing Weblogic Integration BPM processes

These additional aspects are

Transactions

Human intervention (Worklists)

Process tracking and monitoring

Managing timeouts

Canceling processes

Error and exception handling

Transaction compensations

Quality of service

5221 TRANSACTIONS

Transaction boundaries

Processes in WebLogic Integration are transactional in nature Every step of a process is executed within the context of a JTA transaction A transaction ensures that one or more operations execute as an atomic unit of work If one of the operations within a transaction fails then all of them are rolled-back so that the application is returned to its prior state Depending on whether you design your business process logic such that your process is stateful or stateless there may be one or more transactions within the context of a given process

When you are building a process implicit transaction boundaries are formed based on where in the process you place blocking elements for example a Control Receive or a Client Receive The transaction boundaries within a process change as you add process nodes You can also create explicit transaction boundaries by selecting contiguous nodes and declaring them to be in a transaction separate from those created implicitly by the application Resources accessed by a process may also be part of the transaction depending on the nature of the resource and the control that provides the access


High level design guideline Further DetailsAdding transactional boundaries will introduce a quiescent point for the process definition

This forces a quiescent point and thus the implementation writes state to the database

Transactions for Asynchronously Called Processes

The caller for example an Event Generator will deliver the request to the Async Dispatcher Queue within a transaction The Async Dispatcher will begin a new transaction dequeue this request message and invoke the target process On reaching the first quiescent point within the process definition control is returned to the Async Dispatcher which will commit the transaction against the Async Dispatcher Queue In the case of a stateless target process the process will have completed In the case of a stateful target process the process state is persisted to the DBMS within the same transaction

Async call to Stateless Async call to Stateful Process

Transactions and controls

When building processes and accessing resources through controls the designerimplementer needs to be very aware of the characteristics of each Control and also those of the service being produced

There are 3 types of controls

1 Transactional and XA compliant

2 Transactional and not XA compliant

3 Non-transactional

Please refer to section 334 ldquoControlsrdquo for a list of common controls

Transactional and XA compliant

If all controls used within a process are transactional and XA compliant then the transaction of the process can be used to commitabort the underlying transaction branches The process needs to have exception handlers in place to catch any issues and make the necessary transaction decisions The developer needs to be aware on where the transaction was started


as any abortrollback will take control back to the starting point and this may not be within the process that received the exception

Transactional and not XA compliant

XA is a protocol used to manage distributed transactions WebLogic extends XA to allow non-XA resources to participate in distributed transactions with the limitation that in a given transaction only one transactional resource can be non-XA compliant Therefore if more than one transactional non-XA resource needs to be accessed in a process then the access to these resources should be encapsulated in separate JPD sub-processes which are called asynchronously by the original process These must be called asynchronously because synchronously called subprocesses run in the same transaction as the calling process

Non-transactional

For non-transactional controls the developer needs to have a strategy for exception handling Where controls are transactional automatic rollback could be used but for non-transactional a caught exception must handle the error based on the business problem being handled and the BES that raised the exception See retries and exception sections below for best practices

High level design guideline Further DetailsA process needs to have exception handlers in place to catch any issues and make the necessary transaction decisions

Nothing must ever be left to default always catch exceptions and decide what to do This is applicable to transactional and non-transactional resources

Where more than one transactional non-XA resource needs to be accessed in a process then the access to these resources should be encapsulated in separate JPD sub-processes

The original process calls the sub-processes asynchronously because synchronously called subprocesses run in the same transaction as the calling process

5222 HUMAN INTERVENTION (WORKLISTS)

Sometimes is necessary to hold up automatic processing whilst a human completes a task This task could be as simple as approval (YESNO) or inputting data The central component is a task a unit of work that someone or something must complete The term Worklist system refers to a general software implementation that manages tasks

Worklist controls exist to enable the introduction of user assigned tasks and task management to WebLogic Integration so you can build a Worklist system WebLogic Workshop provides two Worklist controls the Task control and the Task Worker control for building your Worklist system

Worklist controls enable the automated manipulation creation and management of Tasks A Task instance represents a unit of work that requires completion within a certain period of time When the work is completed a Task Instance can be used to represent a detailed record of that unit of work

A Task Instance is a particular object in the Worklist System runtime representing a Task in the real world These instances exist independent of any processes or controls Multiple processes can interact with a task throughout its lifecycle even simultaneously

A common use of a Worklist system is in the managing of exceptions It is often a requirement that on failure a user must evaluate the failure condition and decide on the corrective action This could be to correct the error and re-submit or to cancel the operation


High level design guideline Further DetailsWorklist jeopardy management would need to be designed into the process

This is only suitable for dealing with business failures defined by business rules This is not suitable for dealing with large volumes of failures that are typically caused by technicalinfrastructure problems

5223 PROCESS TRACKING AND MONITORING

A process can be tracked at various levels The system has a default tracking level and then each process can over-ride this

WLI console and underlying MBeans provides a monitoring interface to running instances and their variable values although variable values canrsquot be changed It is possible to query by instance ID or by process label Process label is something that you need to set in the instance by calling the jpd context setProcessLabel

High level design guideline Further DetailsTracking data should only be used for operational support and not for businessaudit logging

Tracking data should be purged regularly Tracking can be dynamically toggled onoff for each process at runtime using the WLI console

Process tracking should be disabled for processes that require high performance

Process tracking involves a number of database write For performance reasons tracking must be eliminated

WLI system data should only be used for support and not business level audit

The WLI system data should not be used for business level audit A designed auditlogging framework must be implemented outside of WLI system data capture

Always log the InstanceID On any errorlogaudit message always record the InstanceID

Archiving of WLI data must be scheduled The archiver itself is a process that runs a SELECT on the database so must be scheduled to run frequently on small amounts of data

Set Process Label to relevant query values The process label is a useful query string so design the values rather than leave it up to the implementor For example if a support person will need to find an order number have it represented on the process label

Use a naming convention for naming processes Using a naming convention for processes ensures that support staff can easily find processes when required

5224 MANAGING TIMEOUTS

You can associate a timeout path with individual nodes in your process with groups of nodes or with the whole process (global) You create a global timeout path by adding a timeout path to the start node of your process If you add a Timeout path to a start node the timer starts when the process begins If you add a Timeout path to any other node or group of nodes the timer starts when the process reaches that point of execution


Figure 8 Timeout path

A Timeout has a number of properties

Name enter the name you want displayed in the WebLogic Workshop for this path

Notes enter any notes you want associated with this timeout path These notes can then be accessed through the WebLogic Integration Administration Console

Duration specify the number of seconds that should laps before the path is triggered

After execute select the action you want to take place after a timeout path is executed Choose from

Skipmdashskip the node or group with which the Timeout path is associated That is resume execution of the process at the node following the node or group for which the Timeout path is defined

Resumemdashresume execution of the process at the node that was executing when the timeout triggered That is the process state returns to that before the On Timeout path executed and the On Timeout path resets (that is timeout begins again)

Retry count specify how many times after the first attempt the process engine tries to execute the node or group of nodes contained in the path before the afterExecute path is taken

The designer needs to be aware that as well as Timeout Paths individual control types themselves may offer timeout characteristics

High level design guideline Further DetailsAny stateful process must have a timeout set to enable completion

(Note that stateless processes never have a quiescent point so canrsquot implement timeouts)

It is best practice to always enable a process to finish Whenever a process has to wait for a reply it should never be assumed it would return a timeout path should be implemented even if the time is set very large In the timeout path actions will include steps to ensure that alerts will be raised and can provide steps for manual intervention eg writing logs which are in turn monitored using log monitors or writing to a JMS error queue raising a task on a support person etc

For synchronously called services which involvetimeouts configured for several components it is essential that the lowest-level component times out and propagates an error through the component stack

A calling component should never timeout before the called component returns with a response or a timeout error This is also known as a timeout funnel with the timeouts getting smaller as the call progresses along the component stack

For asynchronously called services which involve timeouts configured for several components fallout management is much more complicated than for synchronous

This needs to be designed to cope with stale response messages on queues


Retries should only be used for system errors not for business errors

For system errors such as transient network problems retries can be designed for a process The designer needs to be aware of any SLAs imposed on the processBusiness retries require specific business rules that should be owned by the FES and BES

5225 CANCELING A PROCESS

Processes can be cancelled automatically through the use of Exception handling and timeouts

In addition a process can be suspended and terminated through the WLI console

Depending on the current state of a process instance you can suspend resume terminate or unfreeze it The following table summarizes the available actions by instance state

Instance State Available Actions

Running Suspend Terminate

Suspended Resume Terminate

Frozen Terminate Unfreeze

Aborted Terminate

When you terminate a process the operation in progress finishes then the process completes without executing subsequent nodes

A process can be designed to freeze rather than abort when it encounters an unhandled exception by setting the freeze on failure property to true To learn more see Setting the Business Process Properties in Designing Your Application in Building Integration Applications This capability is useful for handling an exception due to a network outage unavailable EIS or other such transitory condition When you unfreeze a process if the condition that led the failure is still in effect the process returns to the frozen state


High level design guideline Further DetailsAll processes must have the ability to complete It is best practice to always enable a process

to finish Whenever a process has to wait for a reply it should never be assumed it would return a timeout path should be implemented even if the time is set very large In the timeout path actions will include steps to ensure that alerts will be raised and can provide steps for manual intervention eg writing logs which are in turn monitored using log monitors or writing to a JMS error queue raising a task on a support person etc

5226 ERROR AND EXCEPTION HANDLING

If an exception occurs within a process the normal flow of execution stops The process executes the activities inside the exception handler path defined closest to the point of the exception

You typically define a number of exception handlers in your business process The following sequence defines the order of their execution when an exception is thrown

1 The business process engine first executes the exception handler at the node on which the exception occurs

2 If the exception handler path completes execution normally the process resumes execution at the node following the node associated with the executed exception handler based on the post-execute parameter setting

3 If the exception handler throws an exception while it is executing the exception is propagated upwards to be handled either by an exception handler on the group of nodes in which the node is contained or by the global exception handler defined on the Start node

Note If you have the afterExecute property set to rethrow the exception itself will also propagate upwards

4 If a node or group within a transaction throws an exception the transaction will only see the exception if the exception is not handled or if an exception handler throws an exception

Note For transactional resources that force a transaction to roll back immediately in the case of an error an exception handler on a node or group of nodes does not run before the transaction rolls back However you can use exception handlers with the executeOnRollback property for compensation and clean up of the non-transactional resources

5 When a process fails and there is no exception handler configured to handle the exception thrown the process is placed into an aborted state and no recovery is possible However if the process is configured to freeze on failure the process rolls-back to last commit point and the state is persisted if it fails The process can then be


restarted from the WebLogic Integration Administration Console Note that the ldquofreeze on failurerdquo feature is only available to stateful processes

Figure 9 Exception and message paths

A Message Path is used to interrupt an executing process upon delivery of a message from either a client or a control This allows the process to halt the current stream of execution and take alternate actions You can have as many message paths as you like in your process Note receiving a message will only occur where the process is already waiting

Message paths can be associated with individual nodes a group of nodes or with the process (global) A Message Path can contain a Client Request or Control Receive node at which it receives the message For the case in which an On Message path is specified for the process (that is specified at the Start node) the first node on the path can be a Client Request with Return node



All stateless processes must throw an exception back to the caller

The caller is blocking and so must be notified of the failure as it is the only component that understands what should be done next

Process designers should establish a process level exception handler on every process definition

This is a catch-all process level exception handler Unhandled exceptions place the process into an aborted state from which no recovery is possible Freeze on failure can be set on the process in which case the process is rolled back to last commit state and persisted The administrator can then fix the problem and then ldquoun-freezerdquo the process

Process designers should be especially careful on exception handling on processes that are called through the process control synchronously

Unhandled exceptions in the called process set transactions to roll back only both sub process and caller process will be rolled back

Process designers should use interruption handlers natively available within WLI 81

This includes the ability to receive interrupts from client applications as well as timeouts

5227 TRANSACTION COMPENSATIONS

Automatic execution of compensating transactions should only be implemented with extreme caution At a design level it seems very simple to implement the reverse and in the example


below it demonstrates how easy it is to implement The issues arise when the compensation itself fails how do you recover from that and also it is often not clear cut as to what needs to be done The default design rule should be to raise an alert and manually someone can make a decision on what needs to be done

For transactional resources that force a transaction to roll back immediately in the case of an error an exception handler on a node or group of nodes does not run However by placing an exception path inside the transaction and setting the ldquoexecute on rollbackldquo property of that path to true you force the exception handler to run before the rollback occurs The exception path now has access to the current state (variables etc) and so logic added to the exception path can be used for compensation and clean-up of the non-transactional resources

Transactional resources are any resources that communicate with your business process through a Control Request node or any of the transactional controls Database JMS Application View (if JCA adapter is transactional) Worklist Timer EJB Message Broker and Transformation

Compensation Example

The following figure shows an example of how to use an exception path for compensation

Figure 10 Compensation example

In the example two nodes are running in the same transaction The first node writes to a file (non-transactional) and the second node updates a database (transactional) Both nodes are within a group with an exception handler The exception handler execute on rollback property is set to true to force the exception handler to run before any rollback occurs

In this example if the database operation fails and marks transaction for rollback only the following sequence of events occurs

1 The exception handler runs before the rollback occurs


2 The transaction handler path is executed and the node on the path deletes the file that was written earlier

3 The transaction rolls back

Note The above example is for an implicit transaction You can use the same technique for compensation with explicit transactions However ensure that you put the exception handler path inside the explicit transaction Putting it on the explicit transaction itself will not result in the desired behavior The following figure shows an example of an explicit transaction with an exception handler path with compensation logic

High level design guideline Further DetailsAutomatic execution of compensating transactions should only be implemented with extreme caution

At a design level it seems very simple to implement the reverse The issues arise when the compensation itself fails how do you recover from that and also it is often not clear cut as to what needs to be done The default design rule should be to raise an alert and manually someone can make a decision on what needs to be done

5228 IMPLEMENTING HIGH QUALITY OF SERVICE

Implementing high quality of service (at-least-once or once-only) require that special steps are taken in order to be implemented If these steps are not taken then at-least-once QOS is the default This section describes these steps for different process types

Synchronous Services

For these kinds of services the quality of service is the responsibility of the caller Only make sure that any uncaught or unhandled exception needs to be rethrown to the caller

JMS Asynchronous Services

When using JMS as a calling mechanism to a process the steps required for achieving high QOS are

The JMS queues are persistent

The JMS connection factories must be transactional

The JMS queue must have an error queue configured

Any uncaught or unhandled exception needs to be rethrown to the caller

This ensures that the message is delivered to the process If an unhandled exception occurs the message is stored in the error queue and can be recovered It is important to note that one can never be sure that a computer program of any kind will complete successfully but the high QOS means that the error is always recoverable

Event Generator Asynchronous Services (file email etc)

Because the source event is not transactional once-only QOS cannot be implemented

Client Request Asynchronous Services

Behind the scenes the client request is actually implemented using JMS The rules and caveats described in the ldquoJMS Asynchronous Servicesrdquo section apply in this case

5229 PROCESS VERSIONING

By using the WebLogic Workshop versioning feature you can make changes to your business process without interrupting any instances of the process that are currently running When you


version a business process you create a child version of a business process that shares the same public URI (interface) as its parent At run time the version of the process that is marked as active is the process that will be accessed by external clients through the public URI

New process versions are deployed as new versions of the application which would have gone through the normal development cycle What this feature means is that when the new version of a particular JPD is deployed then existing instances will run to completion on the same version of the JPD as they started with

You can version business processes but not the individual controls associated with that process or other business process related components such as schemas and transformations When you version a business process you must also version the sub processes of that process they are not versioned automatically when their parent process is versioned

High level design guideline Further DetailsProcess versioning should be used for all processes

Process versioning is a feature that allows more than one version of a process to be running at a time It makes it easier to deploy new versions of processes This guideline applies also where there is only one version of a process

Process version strategy needs to be set according to parent-child relationship

This describes how to invoke sub processes when different versions of the parent process exist From the strategy drop-down menuSelect loosely-coupled if you want the subprocess version to be set at the time that the sub process is invokedSelect tightly-coupled if you want the subprocess version to be set at the time the parent process is invoked


523 PATTERNS

A process can be looked at based on 4 sets of properties (as described in ldquoProcess propertiesrdquo)

Stateful vs stateless

Synchronous vs asynchronous

2-way vs 1-way

Basic vs composite

Based on the different possible combinations this gives us a set of core service implementation patterns

5231 CORE IMPLEMENTATION PATTERNS

The table below lists all the possible combination of process types based on the 4 sets of properties

Some combinations are not valid The reasons are listed here

Synchronous process cannot be 1-way

Basic synchronous processes are all stateless

Pattern number Complexity Calling paradigm

State Exchange paradigm

1 Basic Synchronous Stateless 2-wayNot valid Reason Basic Synchronous Stateless 1-wayNot valid Reason Basic Synchronous Stateful 2-way

Not valid Reason Basic Synchronous Stateful 1-way2 Basic Asynchronous Stateless 2-way3 Basic Asynchronous Stateless 1-way4 Basic Asynchronous Stateful 2-way5 Basic Asynchronous Stateful 1-way6 Composite Synchronous Stateless 2-way

Not valid Reason Composite Synchronous Stateless 1-way7 Composite Synchronous Stateful 2-way

Not valid Reason Composite Synchronous Stateful 1-way8 Composite Asynchronous Stateless 2-way9 Composite Asynchronous Stateless 1-way10 Composite Asynchronous Stateful 2-way11 Composite Asynchronous Stateful 1-way

Each of the core implementation patterns can be qualified by its expected volume QOS and response time These 3 characteristics are explained below

Volume The volume is qualified as high medium or low It is the capacity for a pattern to satisfy transaction volume requirements

High volume is 100 or more transactions per second

Medium volume is from 1 to 100 transactions per seconds

Low Volume is less then 1 transaction per second

QOS Quality Of Service has one of the following values


At-most-once no duplicates but loses are possible

At-least-once no losses but duplicates are possible

Exactly-once no losses and no duplicates

Any All of the above may be implemented

Duration The process duration which in case of 2-way processes is equivalent to the response time Possible values are

Very short 01 to 10 seconds

Short 1 to 60 seconds

Average 30 seconds to 1 hour

Long 60 seconds to 1 month

Some process patterns have more than one value for this characteristic because they can be implemented with different duration based on the complexity

Important note Actual volume and response time figures in the production environment depend on the hardware and software configuration and other external factors such as the response time of the back-end systems or children services The figures given are only indicative of a typical configuration and implementation specifics have to be taken into account Also higher quality of service increases overall response time and reduces volume

Pattern Volume QOS Duration1 Basic Synch SL 2-way High All Very short2 Basic Asynch SL 2-way High All Very short3 Basic Asynch SL 1-way High All Very short4 Basic Asynch SF 2-way MediumLow All Short5 Basic Asynch SF 1-way MediumLow All Short6 Composite Synch SL 2-way HighMediumLow All Short7 Composite Synch SF 2-way MediumLow All ShortAverageLong8 Composite Asynch SL 2-way HighMediumLow All Short9 Composite Asynch SL 1-way HighMediumLow All Short10 Composite Asynch SF 2-way MediumLow All ShortAverageLong11 Composite Asynch SF 1-way MediumLow All ShortAverageLong

Below is a short description of each of the resulting patterns Example processes for each of these patterns is available in appendix

Pattern 1 Basic Synchronous Stateless 2-Way Service

This pattern is used to implement some of the fastest processes It is typically used for simple access to a BES or to implement helper processes

Pattern 2 Basic Asynchronous Stateless 2-Way Service

This pattern is used to implement some of the fastest processes It is typically used for simple access to a BES when decoupling with the processrsquos client is required



This pattern is used to implement some of the fastest processes Typically used for accessing BESs in event-driven scenarios

Pattern 4 Basic Asynchronous Stateful 2-Way Service

Not as fast as its stateless equivalent this pattern is typically used to access BESs that provide an asynchronous interface


This pattern is very rare because most of the 1-way services are usually stateless there is no need to wait for an answer It may be used to quickly access a BES in event-driven scenario where a call waiting is nonetheless required

Pattern 6 Composite Synchronous Stateless 2-way Service

This pattern is typically used to implement integration logic that requires good performance and coupling with the client is acceptable

Pattern 7 Composite Synchronous Stateful 2-way Service

This pattern represents an unusual case where logic is implemented after the client has received a response A typical requirement is the ability to have a Stateful process that runs for a period of time that is started by a synchronous requestreply Once the synchronous reply is sent the process moves to a traditional asynchronous model

Pattern 8 Composite Asynchronous Stateless 2-way Service

This pattern is a very typical way to implement integration logic that requires good performance while maintaining decoupling from its client It may also be used to implement access to a BES other than trivial when decoupling from the caller is required Obviously it is not always possible to implement this pattern because it requires that all the resources used are stateless


This pattern is a very typical way to implement integration logic that requires good performance in event-driven scenarios

Pattern 10 Composite Asynchronous Stateful 2-way Service

Usually used when the stateless version of the same pattern is not possible because at least one of the resources has an asynchronous interface It is also used a typical pattern for long-running processes


This pattern is not very common because most of the 1-way services are usually stateless there is no need to wait for an answer It is typically used to implement integration logic in event-driven scenarios but where a call waiting is nonetheless required

5232 OTHER PATTERNS

This section regroups useful patterns which can be used in combination with one of the core patterns

52321 DE-SYNCHRONIZER

The De-synchronizer pattern allows you to asynchronously call a synchronous process This is recommended if


The process needs to support both synchronous and asynchronous clients

More decoupling is required in particular if a sub-process needs to run in its own transaction

The client is unable to call services synchronously

To provide an asynchronous interface to a synchronous process the process in Figure 11 should be implemented

Figure 11 De-Synchronizer Service

This is a simple proxy process The signature of the request and the reply should remain the same as the one of the original service The De-synchronizer will pass its input values to the sub-process and return the sub-processrsquo return value to its caller

High level design guideline Further DetailsIf there is a requirement for a stateless process to support both asynchronous and synchronous clients use the de-synchronizer pattern

It is harder to maintain a process if it has multiple start nodes

52322 SYNCHRONIZER

To synchronously call an asynchronous interface becomes an implementation problem An asynchronous message needs to compete for resources on its return and by its very nature is not a guaranteed fast implementation Thus if you have a process blocking this could be for a considerable period and holds onto resources during this time causing scalability issues

When a requirement exists for calling synchronously an asynchronous process the synchronizer pattern can be used This pattern provides a polling interface to an asynchronous process therefore removing the need for blocking calls while providing a synchronous interface to the caller


Figure 12 Synchronizer Service

This approach consists in implementing a conversational web service WebLogic workshop provides all the necessary tools to quickly implement this web service This web service can be called internally using workshop or externally by a web services client The web service interface consists of three methods

StartAsynchProcess starts the conversation with the client and launches the sub-process It has the same signature as the sub-service

CheckStatus is the polling method and should be called regularly in a loop It returns one of three values in progress done or error

GetFinalResult should be called once the checkStatus method has returned an error or done It ends the conversation (and delete the conversation states it persisted) and in the case of a successful completion returns the sub-servicersquos return value

An example implementation of such a web service can be found in appendix

Other approaches

Where a synchronizer approach canrsquot be implemented a component will need to be implemented to provide a blocking wrapper of the asynchronous call It is recommended to implement this at the FES as this is where the business rules needed to implement the fallout management are known and therefore where any timeout requirements and errors can be best handled If this cannot be done and the synchronizer pattern described above is not suitable the last resort should be to implement a component within WebLogic as close to the client as possible to provide this

If the synchronous client is a web client then a proxy Servlet can be implemented This servlet would intercept the incoming request hold the client thread open and make a call to the asynchronous process as appropriate When completed the asynchronous process would post the response to a JMS queue The Servlet would block waiting on this JMS response it would then receive this message and respond to the client on the original thread

High level design guideline Further DetailsNormally do not allow stateful processes to be called synchronously If absolutely required use the synchronizer pattern

Please refer to discussion in the section above

It is recommended to implement the synchronizer pattern at the FES

This is where the business rules that are needed to implement the fallout management are known

If this cannot be done at the FES and the synchronizer pattern described above is not suitable the last resort should be to implement a component within WebLogic as close to the client as possible to provide this

WebLogic server provides the whole J2EE specification to aid this implementation


66 LAYERED ARCHITECTURELAYERED ARCHITECTURE

Typical enterprise SOA platforms connect to many enterprise application resources application clients and host many service providers and service consumers Management efficiencies can be achieved by dividing services into groups of similar services One common group of services make Back-end System (BES) resources available to service consumers Another common group of services connect application clients or Front-end Systems (FES) to the SOA platform

Orchestration services combine basic services into composite services Grouping similar services into layers allows the organization to efficiently address the unique characteristics of each layer of the SOA platform Appropriate domain expertise development patterns test fixtures deployment schemes system management regimes etc can be developed specifically for each layer

A published service is one that can be called from outside the SOA platform for example a FES sends an XML message over JMS and in this document is referred to as a service For each service a Control will also exist to enable internal layers to access the same service This enables a given service to be called in a variety of ways

611 THE LAYERS

A layered architecture is the most flexible and powerful way to implement To its simplest an SOA might be composed only of basic access services which directly encapsulate a subset of the interfaces provided by the BESs

However this set of services is unlikely to cover the integration requirements of even the most basic of the integration projects In most cases integration logic is required This integration logic should also be seen as a set of services with a well-defined published interface These services are higher-level services which make use of the lower-level BES access services These services implement what is known as the orchestration or coordination

Finally in an enterprise integration environment most of the client applications for these higher-level coordination or lower-level access services (the FESs) will not directly support the servicesrsquo interfaces Therefore another set of services is required composed of services specific to each service-consumer FES

This gives the bases for the layered architecture proposed here depicted in Figure 13


Figure 13 The SOA Platform layers

There are three layers in this architecture Each layer has a unique set of technical requirements and a unique contribution to the success of the platform

The access services layer is responsible for publishing a subset of the BESsrsquo interfaces as a standard service

The coordination services layer regroups the services that implement the integration logic

The consumer services layer is responsible for enabling FESs to access published services in the other two layers when they canrsquot call the services directly

The other main concept is that a service at any layer can be called by a FES you donrsquot have to progress through all layers in the architecture

Because an individual Enterprise Information System (EIS) can fulfil one or both of the FESBES roles it may expose services through the Access Layer and also make requests of services through the consumer layer

612 THE ACCESS SERVICES LAYER

The access services layer provides the end services that are consumed by the rest of the platform The key architectural focus of this layer is designing and managing for service reuse Designing and developing access services requires application resource domain expertise adapter development and configuration skills and message set modelling skills

The access services layer are published services that interface to a single BES where the main aim is to maximize re-use across the platform Other layers through Controls or via a published interface can access these services In itrsquos simplest form it is just a BES exposed through a Control For example a J2EE Connection Architecture Adapter (J2EECA) Database


Adapter is installed and configured to link to a specific system with services created for each SQL statement required This can then be accessed through the Integration Application View Control

A more complex scenario is where the BESrsquos API is too low a level to make a meaningful service this layer then creates a simple process that offers a single interface wrapping the low level calls This is often known as the Integration Sequencing Problem It is implemented using a composite service

What services should be part of this layer

The main consideration at this layer is that all published interfaces are designed based on the BES and not any FES or co-ordination requirements Composite services that implement multiple calls to a BES should be part of this layer only if this wrapping of multiple calls is implemented to cover for an inefficient BES interface

For example if in order to create a customer in a given BES it is necessary to create the customer id then the customer name then the customer address etc all as different calls then a ldquocreate customerrdquo composite service should be implemented that wraps all these calls On the other hand if as part of the company business process when a new customer is added a new account is also created in the BES then this should not be implemented in the access but in the coordination layer either as part of a greater service involving more than one system or simply as a helper service for the specific BES

The decision about whether such a composite service fits into the access layer or not is driven by ownership of design ie if the BES design community wants there to be a service which has both account and customer added then the service goes into access layer

The reason for this rule is that the services at the access layer should be reusable across projects as much as possible as well as being maintainable in the context of the BES rather than in the context of individual projects

In summary a process fits into the accesses if it satisfies the following

Connects to only one BES

Ownership of the interface and implementation of the service is with the BES

613 THE CO-ORDINATION SERVICE LAYER

The co-ordination service layer is focused on delivering new services by orchestrating the basic services provided by the access services layer The key architectural focus of this layer is agility Agility is achieved by properly applying data aggregation process definition and workflow tools to create the desired services Designing and developing co-ordination services requires domain expertise in integration processes and rules and development skills in data aggregation process definition and workflow

This layer is where the integration logic is implemented and published as an enriched service This layer makes use of the Access Layer to offer a meaningful service to the FESs


Any service that makes use of more than one EIS is definitely part of this layer The same is true for any service that implements human interaction through worklists As described in the access layer section above some coordination layer services may access only one BES If they implement functionality that comes from the integration requirements rather than from the BES requirements then they fit into this layer A simpler rule applies to this layer any service that does not fall into the consumer or access layer is part of the coordination layer


Standalone data integration services ie services that offer data transformations data mapping (including key mapping) data dependent routing reside in this layer These may or may not access BESrsquos via the access layer

614 THE CONSUMER SERVICE LAYER

The primary purpose of the consumer service layer is to connect the platform with application service consumers ie FES systems Services in this layer provide

Protocol mapping - to the services published interface protocol JMS and Web Services

Paradigm mapping - synchronous to asynchronous and vice-versa

Data mapping - data format mapping enrichment etc

These service consumers can include applications based on a wide range of architectures Legacy service consumers such as thick clients messaging systems socket protocols etc usually require protocol translation services Consumers that support the platformrsquos protocols paradigm and data such as portals B2B services multi-channel etc may be able to interface directly with the platform Integrating service consumers to the SOA platform requires domain knowledge in the specific service consumer technology and data transformation skills


The consumer layer regroups the services that are implemented for a specific FES These services can be implemented using composite patterns and implement complex logic as long as they serve a unique FES

For example a consumer layer service receives a certain type of event from a FES but these events do not contain enough information to invoke the require coordination layer The service is implemented such as when it receives these events it then queries back the FES for more information This is known as enrichment This scenario fits into the consumer layer However if the enrichment step requires a query to a separate system then this is considered to be integration logic and should then be a separate service in the consumer layer

615 END-TO-END PERSPECTIVE

It is important to note that none of the layers are mandatory when looking at an end-to-end FES to BES communication As explained earlier the consumer layer is only required to provide access to the SOA platformrsquos standard interfaces technology If a FES natively supports such a standard it may access services in the SOA platform natively negating the need for the consumer layer Also some simple integration requirement for example the query of data available in a unique system will not require orchestration However it is recommended never to skip the access layer This ensures that the services provided by the BESs are consistent with the rest of the platform and flexible It ensures that the scenario where all the layers are skipped never occurs and therefore that the platformrsquos governance rules are always satisfied


Figure 14 End-to-end perspective

It is also worth mentioning that in a typical integration scenario most systems involved will be both FES and BES although some system are inherently front-end (such as portal) while other are nearly always back-end (such as a database) When the communication is asynchronous and very decoupled (for example using JMS) a 2-way integration requirement may be implemented as two 1-way communications This is an example where a system may act both as FES and BES in the same business process

616 SERVICE REPOSITORY

A service repository is required to document and ease reuse of the services across projects This repository does not need to be a dynamic run-time system as UDDI but is used mostly at design and development phase as a reference across the enterprise It could be as simple as a folder on shared disk or can be implemented using document management tools

The service definitions in the repository should at least detail the following for each service

The service name and version

A synopsis of the servicersquos function and intent

The functional and non-functional requirements

The layer in which the service sits as well as its granularity

The servicersquos detailed interfaces This include published andor private interfaces and for each interface all the details such as URL methods arguments types and required values and usage

The servicersquos owner This may be an individual or (more usually) an organization that is responsible for maintaining the service


617 PATTERNS AND LAYERS

There isnrsquot a core implementation pattern that is specific to a layer Similarly there is no restrictions as which pattern can be used at a given layer However there are patterns that fit better the requirements of a certain layers

Basic services are found typically in Access and Consumer layers while the coordination layer is mostly implemented using composite services

As a general rule services should be stateless whenever possible in order to achieve the best performance and called by an asynchronous mechanism in order to be as decoupled from their client as possible

However it turns out that if the 2-way services in the access layer are asynchronous then coordination layers become stateful Therefore the rule of having stateless and asynchronous services cannot be satisfied at all layers As a trade-off it follows that the best compromise between decoupling and performance for 2-way scenarios is to implement the low-level access layer services synchronous whenever possible (ie whenever the BES interface is also synchronous) while implementing the higher-level coordination layer services as asynchronous

High level design guideline Further Details2-way Access layer services should be synchronous whenever possible

This allows the best performance for the coordination layer Note that the response time for the services should be quick under peak loads and the BES should be able to cope with these loads If not then asynchronous services must be used

Coordination layer services should normally be asynchronous

This allow for maximum decoupling

These two guidelines are the best performance trade-off in the typical scenario of a round-trip call within the platform consisting of one consumer layer service one coordination layer service and several access layer services In this case whenever the BES interfaces allow all the services will be stateless except the consumer layer service

The second guideline stated above (asynchronous coordination layer services) has the added advantage of shielding the coordination layer service client of implementation changes in the back-end Whether the access layer services provide a synchronous or asynchronous interface it is always possible to keep an asynchronous interface in the coordination layer

There are circumstances under which synchronous interaction patterns are appropriate ndash Portal access of SOA Platform services is one of these The justification should show that all of the following criteria are met

The end-to-end response time is demanding

The initial response to the requestor is dependent upon a response from the target BES

The target BES can provide a fast response under peak load

The target BESs are expected to be highly available

In these cases it is advised to implement the services as synchronous but to use the de-synchronizer pattern to provide also an asynchronous interface to the coordination layer


services Thus clients that do not require the high-throughput can use the asynchronous interface

High level design guideline Further DetailsFor high-performance all synchronous services may be required

Some use case non-functional requirements need to have a fast response or high volume

If a process has a ldquolongrdquo duration it must be configured to maintain long conversation with its clients

The conversation duration of a process is configured through its max-age property The default is 1 day

Providing also an asynchronous interface to synchronous coordination layer services allows for more decoupling

This second interface is implemented using the de-synchronizer pattern

In some cases access layer services needed to be coupled asynchronously for example if in a composite coordination service more than one transactional non-xa resource needs to be accessed (see also section on Transactions) In such a case the best approach is to keep the access layer service synchronous but to implement the de-synchronizer pattern

High level design guideline Further DetailsWhen a synchronous access layer service needs to be called asynchronously keep the service synchronous but implement the de-synchronizer pattern as part of the coordination layer

Project-specific requirements should not impede on the reusability of the services in the access layer


77 APPENDIXAPPENDIX

71 GRAPHICAL EXAMPLES OF THE CORE IMPLEMENTATION PATTERNS

711 PATTERN 1 BASIC SYNCHRONOUS STATELESS 2-WAY SERVICE

Figure 15 Example of Basic Synchronous Stateless 2-Way service


712 PATTERN 2 BASIC ASYNCHRONOUS STATELESS 2-WAY SERVICE

Figure 16 Examples of Basic Asynchronous Stateless 2-Way Services





714 PATTERN 4 BASIC ASYNCHRONOUS STATEFUL 2-WAY SERVICE

Figure 18 Examples of Basic Asynchronous Stateful 2-Way Services





716 PATTERN 6 COMPOSITE SYNCHRONOUS STATELESS 2-WAY SERVICE

Figure 20 Example of Composite Synchronous Stateless 2-way Service


717 PATTERN 7 COMPOSITE SYNCHRONOUS STATEFUL 2-WAY SERVICE

Figure 21 Example of Composite Synchronous Stateful 2-way Service


718 PATTERN 8 COMPOSITE ASYNCHRONOUS STATELESS 2-WAY SERVICE

Figure 22 Examples of Composite Asynchronous Stateless 2-way Services





7110 PATTERN 10 COMPOSITE ASYNCHRONOUS STATEFUL 2-WAY SERVICE

Figure 24 Examples of Composite Asynchronous Stateful 2-way Services





72 WEB SERVICES SOURCE CODE FOR THE SYNCHRONIZER PATTERN

public class Synchronizer implements combeajwsWebService commoncontrol private templatesutilAsynchProcessPControl asynchProcessControl

private String clientResponse private String status = NOT_STARTED

static final long serialVersionUID = 1L

commonoperation jwsconversation phase=continue public String checkStatus() return thisstatus

commonoperation jwsconversation phase=finish public String getFinalResult() return thisclientResponse

commonoperation jwsconversation phase=start public void startAsynchProcess(javalangString x0) asynchProcessControlclientRequest(x0) status = IN_PROGRESS public void asynchProcessControl_clientResponse(String x0) clientResponse = x0 thisstatus = DONE


1 Introduction

2 Service Design Process

21 What Is the Service Design Process

22 What are the inputs to the Service Design Process

23 What are the steps in the Service Design Process

24 What are the main characteristics of a service

3 Communications and connectivity

31 What is the Connectivity Problem

32 Published Interface

33 What are the Tools to help solve the Connectivity Problem

331 Web Services

3311 Consumer Connectivity

3312 Back-End System Connectivity

3313 Internal Connectivity

332 JMS Messaging Bridge




333 Adapters Application Views




334 Controls




335 Event Generators




336 WebLogic Tuxedo Connector (WTC)




337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations


342 Back-end System Connectivity

343 Internal Communications

344 General

4 Data Handling

41 What is the Data Handling Problem

42 What are the Data Handling Tools

421 XQuery

422 XSLT

423 Format Builder and MFL

424 XML Beans

425 Data Model

43 Recommendations

5 Process

51 What is the process problem

52 What are the Tools to help solve the Process Problem

521 Process Properties

5211 Complexity (basic and composite)

5212 Calling Paradigm

5213 Process State

5214 Exchange Paradigm (one-way and two-way)

522 Process Management and Monitoring

5221 Transactions

5222 Human Intervention (Worklists)

5223 Process Tracking and monitoring

5224 Managing Timeouts

5225 Canceling a Process

5226 Error and exception Handling

5227 Transaction Compensations

5228 Implementing High Quality of Service

5229 Process versioning

523 Patterns

5231 Core Implementation Patterns

5232 Other Patterns

52321 De-synchronizer

52322 Synchronizer

6 Layered Architecture

611 The Layers

612 The Access Services Layer

613 The Co-ordination Service Layer

614 The Consumer Service Layer

615 End-to-End Perspective

616 Service Repository

617 Patterns and layers

7 Appendix

71 Graphical Examples of the Core Implementation PAtterns

711 Pattern 1 Basic Synchronous Stateless 2-Way Service

712 Pattern 2 Basic Asynchronous Stateless 2-Way Service


714 Pattern 4 Basic Asynchronous Stateful 2-Way Service


716 Pattern 6 Composite Synchronous Stateless 2-way Service

717 Pattern 7 Composite Synchronous Stateful 2-way Service

718 Pattern 8 Composite Asynchronous Stateless 2-way Service


7110 Pattern 10 Composite Asynchronous Stateful 2-way Service


72 Web Services Source Code For the Synchronizer PAttern

Table of ContentsTable of Contents

1 Introduction5

2 Service Design Process6

21 What Is the Service Design Process6

22 What are the inputs to the Service Design Process6

23 What are the steps in the Service Design Process7

24 What are the main characteristics of a service9

3 Communications and connectivity11

31 What is the Connectivity Problem11

32 Published Interface11

33 What are the Tools to help solve the Connectivity Problem12

331 Web Services13

332 JMS Messaging Bridge14

333 Adapters Application Views15

334 Controls16

335 Event Generators17

336 WebLogic Tuxedo Connector (WTC)18

337 HTTP19

338 B2B19

339 JPD Proxy21


341 Consumer Connectivity21

342 Back-end System Connectivity22

343 Internal Communications24

344 General25

4 Data Handling26

41 What is the Data Handling Problem26

42 What are the Data Handling Tools26

421 XQuery26

422 XSLT27

423 Format Builder and MFL27

424 XML Beans28

425 Data Model28



5 Process30





523 Patterns46


611 The Layers51







7 Appendix58





































































































1 Complexity



2 Calling Paradigm




3 Exchange Paradigm




4 Volume




5 QOS (reliability)








6 Duration



















Exchange Paradigm















Web Services



Controls


WTC

Raw HTTP


JPD Proxy







SynchAsynch

Trans-actional

Security Notes


Both No Yes






Both Yes Yes


Event Generators




B2B Asynch Yes Yes



331 WEB SERVICES


























Support for events















334 CONTROLS




Database

JMS

WLI JMS


Worklist

Timer

EJB

Message Broker

Transformation

Process Control

TUXEDO

File

E-mail

Service (JWS)

Service Broker5

RosettaNet

EbXML6

HTTP (dev2dev)


















JMS

File

Timer

Email


















337 HTTP










338 B2B


















339 JPD PROXY










34 RECOMMENDATIONS








WTC for TuxedoQ













application itself















Assumptions




























344 GENERAL



























XQuery

XSLT

Format Builder MFL

XML Beans

Data Model

421 XQUERY













422 XSLT







424 XML BEANS




425 DATA MODEL





43 RECOMMENDATIONS
















55 PROCESSPROCESS




How to organize it

















Synchronous






Asynchronous
















5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix














5 Process30





523 Patterns46


611 The Layers51







7 Appendix58





































































































1 Complexity



2 Calling Paradigm




3 Exchange Paradigm




4 Volume




5 QOS (reliability)








6 Duration



















Exchange Paradigm















Web Services



Controls


WTC

Raw HTTP


JPD Proxy







SynchAsynch

Trans-actional

Security Notes


Both No Yes






Both Yes Yes


Event Generators




B2B Asynch Yes Yes



331 WEB SERVICES


























Support for events















334 CONTROLS




Database

JMS

WLI JMS


Worklist

Timer

EJB

Message Broker

Transformation

Process Control

TUXEDO

File

E-mail

Service (JWS)

Service Broker5

RosettaNet

EbXML6

HTTP (dev2dev)


















JMS

File

Timer

Email


















337 HTTP










338 B2B


















339 JPD PROXY










34 RECOMMENDATIONS








WTC for TuxedoQ













application itself















Assumptions




























344 GENERAL



























XQuery

XSLT

Format Builder MFL

XML Beans

Data Model

421 XQUERY













422 XSLT







424 XML BEANS




425 DATA MODEL





43 RECOMMENDATIONS
















55 PROCESSPROCESS




How to organize it

















Synchronous






Asynchronous
















5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix




































































































1 Complexity



2 Calling Paradigm




3 Exchange Paradigm




4 Volume




5 QOS (reliability)








6 Duration



















Exchange Paradigm















Web Services



Controls


WTC

Raw HTTP


JPD Proxy







SynchAsynch

Trans-actional

Security Notes


Both No Yes






Both Yes Yes


Event Generators




B2B Asynch Yes Yes



331 WEB SERVICES


























Support for events















334 CONTROLS




Database

JMS

WLI JMS


Worklist

Timer

EJB

Message Broker

Transformation

Process Control

TUXEDO

File

E-mail

Service (JWS)

Service Broker5

RosettaNet

EbXML6

HTTP (dev2dev)


















JMS

File

Timer

Email


















337 HTTP










338 B2B


















339 JPD PROXY










34 RECOMMENDATIONS








WTC for TuxedoQ













application itself















Assumptions




























344 GENERAL



























XQuery

XSLT

Format Builder MFL

XML Beans

Data Model

421 XQUERY













422 XSLT







424 XML BEANS




425 DATA MODEL





43 RECOMMENDATIONS
















55 PROCESSPROCESS




How to organize it

















Synchronous






Asynchronous
















5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix














6 Duration



















Exchange Paradigm















Web Services



Controls


WTC

Raw HTTP


JPD Proxy







SynchAsynch

Trans-actional

Security Notes


Both No Yes






Both Yes Yes


Event Generators




B2B Asynch Yes Yes



331 WEB SERVICES


























Support for events















334 CONTROLS




Database

JMS

WLI JMS


Worklist

Timer

EJB

Message Broker

Transformation

Process Control

TUXEDO

File

E-mail

Service (JWS)

Service Broker5

RosettaNet

EbXML6

HTTP (dev2dev)


















JMS

File

Timer

Email


















337 HTTP










338 B2B


















339 JPD PROXY










34 RECOMMENDATIONS








WTC for TuxedoQ













application itself















Assumptions




























344 GENERAL



























XQuery

XSLT

Format Builder MFL

XML Beans

Data Model

421 XQUERY













422 XSLT







424 XML BEANS




425 DATA MODEL





43 RECOMMENDATIONS
















55 PROCESSPROCESS




How to organize it

















Synchronous






Asynchronous
















5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix



























Exchange Paradigm















Web Services



Controls


WTC

Raw HTTP


JPD Proxy







SynchAsynch

Trans-actional

Security Notes


Both No Yes






Both Yes Yes


Event Generators




B2B Asynch Yes Yes



331 WEB SERVICES


























Support for events















334 CONTROLS




Database

JMS

WLI JMS


Worklist

Timer

EJB

Message Broker

Transformation

Process Control

TUXEDO

File

E-mail

Service (JWS)

Service Broker5

RosettaNet

EbXML6

HTTP (dev2dev)


















JMS

File

Timer

Email


















337 HTTP










338 B2B


















339 JPD PROXY










34 RECOMMENDATIONS








WTC for TuxedoQ













application itself















Assumptions




























344 GENERAL



























XQuery

XSLT

Format Builder MFL

XML Beans

Data Model

421 XQUERY













422 XSLT







424 XML BEANS




425 DATA MODEL





43 RECOMMENDATIONS
















55 PROCESSPROCESS




How to organize it

















Synchronous






Asynchronous
















5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix




















Web Services



Controls


WTC

Raw HTTP


JPD Proxy







SynchAsynch

Trans-actional

Security Notes


Both No Yes






Both Yes Yes


Event Generators




B2B Asynch Yes Yes



331 WEB SERVICES


























Support for events















334 CONTROLS




Database

JMS

WLI JMS


Worklist

Timer

EJB

Message Broker

Transformation

Process Control

TUXEDO

File

E-mail

Service (JWS)

Service Broker5

RosettaNet

EbXML6

HTTP (dev2dev)


















JMS

File

Timer

Email


















337 HTTP










338 B2B


















339 JPD PROXY










34 RECOMMENDATIONS








WTC for TuxedoQ













application itself















Assumptions




























344 GENERAL



























XQuery

XSLT

Format Builder MFL

XML Beans

Data Model

421 XQUERY













422 XSLT







424 XML BEANS




425 DATA MODEL





43 RECOMMENDATIONS
















55 PROCESSPROCESS




How to organize it

















Synchronous






Asynchronous
















5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix














SynchAsynch

Trans-actional

Security Notes


Both No Yes






Both Yes Yes


Event Generators




B2B Asynch Yes Yes



331 WEB SERVICES


























Support for events















334 CONTROLS




Database

JMS

WLI JMS


Worklist

Timer

EJB

Message Broker

Transformation

Process Control

TUXEDO

File

E-mail

Service (JWS)

Service Broker5

RosettaNet

EbXML6

HTTP (dev2dev)


















JMS

File

Timer

Email


















337 HTTP










338 B2B


















339 JPD PROXY










34 RECOMMENDATIONS








WTC for TuxedoQ













application itself















Assumptions




























344 GENERAL



























XQuery

XSLT

Format Builder MFL

XML Beans

Data Model

421 XQUERY













422 XSLT







424 XML BEANS




425 DATA MODEL





43 RECOMMENDATIONS
















55 PROCESSPROCESS




How to organize it

















Synchronous






Asynchronous
















5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix


































Support for events















334 CONTROLS




Database

JMS

WLI JMS


Worklist

Timer

EJB

Message Broker

Transformation

Process Control

TUXEDO

File

E-mail

Service (JWS)

Service Broker5

RosettaNet

EbXML6

HTTP (dev2dev)


















JMS

File

Timer

Email


















337 HTTP










338 B2B


















339 JPD PROXY










34 RECOMMENDATIONS








WTC for TuxedoQ













application itself















Assumptions




























344 GENERAL



























XQuery

XSLT

Format Builder MFL

XML Beans

Data Model

421 XQUERY













422 XSLT







424 XML BEANS




425 DATA MODEL





43 RECOMMENDATIONS
















55 PROCESSPROCESS




How to organize it

















Synchronous






Asynchronous
















5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix



















334 CONTROLS




Database

JMS

WLI JMS


Worklist

Timer

EJB

Message Broker

Transformation

Process Control

TUXEDO

File

E-mail

Service (JWS)

Service Broker5

RosettaNet

EbXML6

HTTP (dev2dev)


















JMS

File

Timer

Email


















337 HTTP










338 B2B


















339 JPD PROXY










34 RECOMMENDATIONS








WTC for TuxedoQ













application itself















Assumptions




























344 GENERAL



























XQuery

XSLT

Format Builder MFL

XML Beans

Data Model

421 XQUERY













422 XSLT







424 XML BEANS




425 DATA MODEL





43 RECOMMENDATIONS
















55 PROCESSPROCESS




How to organize it

















Synchronous






Asynchronous
















5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix



























JMS

File

Timer

Email


















337 HTTP










338 B2B


















339 JPD PROXY










34 RECOMMENDATIONS








WTC for TuxedoQ













application itself















Assumptions




























344 GENERAL



























XQuery

XSLT

Format Builder MFL

XML Beans

Data Model

421 XQUERY













422 XSLT







424 XML BEANS




425 DATA MODEL





43 RECOMMENDATIONS
















55 PROCESSPROCESS




How to organize it

















Synchronous






Asynchronous
















5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix

























337 HTTP










338 B2B


















339 JPD PROXY










34 RECOMMENDATIONS








WTC for TuxedoQ













application itself















Assumptions




























344 GENERAL



























XQuery

XSLT

Format Builder MFL

XML Beans

Data Model

421 XQUERY













422 XSLT







424 XML BEANS




425 DATA MODEL





43 RECOMMENDATIONS
















55 PROCESSPROCESS




How to organize it

















Synchronous






Asynchronous
















5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix


















338 B2B


















339 JPD PROXY










34 RECOMMENDATIONS








WTC for TuxedoQ













application itself















Assumptions




























344 GENERAL



























XQuery

XSLT

Format Builder MFL

XML Beans

Data Model

421 XQUERY













422 XSLT







424 XML BEANS




425 DATA MODEL





43 RECOMMENDATIONS
















55 PROCESSPROCESS




How to organize it

















Synchronous






Asynchronous
















5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix























339 JPD PROXY










34 RECOMMENDATIONS








WTC for TuxedoQ













application itself















Assumptions




























344 GENERAL



























XQuery

XSLT

Format Builder MFL

XML Beans

Data Model

421 XQUERY













422 XSLT







424 XML BEANS




425 DATA MODEL





43 RECOMMENDATIONS
















55 PROCESSPROCESS




How to organize it

















Synchronous






Asynchronous
















5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix


















34 RECOMMENDATIONS








WTC for TuxedoQ













application itself















Assumptions




























344 GENERAL



























XQuery

XSLT

Format Builder MFL

XML Beans

Data Model

421 XQUERY













422 XSLT







424 XML BEANS




425 DATA MODEL





43 RECOMMENDATIONS
















55 PROCESSPROCESS




How to organize it

















Synchronous






Asynchronous
















5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix














application itself















Assumptions




























344 GENERAL



























XQuery

XSLT

Format Builder MFL

XML Beans

Data Model

421 XQUERY













422 XSLT







424 XML BEANS




425 DATA MODEL





43 RECOMMENDATIONS
















55 PROCESSPROCESS




How to organize it

















Synchronous






Asynchronous
















5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix
















Assumptions




























344 GENERAL



























XQuery

XSLT

Format Builder MFL

XML Beans

Data Model

421 XQUERY













422 XSLT







424 XML BEANS




425 DATA MODEL





43 RECOMMENDATIONS
















55 PROCESSPROCESS




How to organize it

















Synchronous






Asynchronous
















5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix




































344 GENERAL



























XQuery

XSLT

Format Builder MFL

XML Beans

Data Model

421 XQUERY













422 XSLT







424 XML BEANS




425 DATA MODEL





43 RECOMMENDATIONS
















55 PROCESSPROCESS




How to organize it

















Synchronous






Asynchronous
















5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix




























XQuery

XSLT

Format Builder MFL

XML Beans

Data Model

421 XQUERY













422 XSLT







424 XML BEANS




425 DATA MODEL





43 RECOMMENDATIONS
















55 PROCESSPROCESS




How to organize it

















Synchronous






Asynchronous
















5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix




















422 XSLT







424 XML BEANS




425 DATA MODEL





43 RECOMMENDATIONS
















55 PROCESSPROCESS




How to organize it

















Synchronous






Asynchronous
















5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix















424 XML BEANS




425 DATA MODEL





43 RECOMMENDATIONS
















55 PROCESSPROCESS




How to organize it

















Synchronous






Asynchronous
















5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix






















55 PROCESSPROCESS




How to organize it

















Synchronous






Asynchronous
















5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix

















Asynchronous
















5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix























5213 PROCESS STATE

Stateless












Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix






















Stateful




Control receive



Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix















Parallel branching


Worklist

Timer


JMS subscription






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix






















Transactions



Managing timeouts

Canceling processes



Quality of service

5221 TRANSACTIONS















3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix
























3 Non-transactional








Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix

















Non-transactional



























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix




























































Aborted Terminate











































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix





















































































523 PATTERNS




2-way vs 1-way

Basic vs composite
























































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix


















































5232 OTHER PATTERNS













52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix






















52322 SYNCHRONIZER










Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix




















Other approaches














611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix


















611 THE LAYERS























































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix































































































77 APPENDIXAPPENDIX











































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix




















































1 Introduction










331 Web Services












334 Controls












337 HTTP




338 B2B




339 JPD Proxy




34 Recommendations




344 General

4 Data Handling



421 XQuery

422 XSLT


424 XML Beans

425 Data Model

43 Recommendations

5 Process






5213 Process State



5221 Transactions









523 Patterns


5232 Other Patterns


52322 Synchronizer


611 The Layers







7 Appendix














osb patterns and best practices

Documents

mdb pool size

key architectural

business level

requires good

async dispatcher

message broker

stateless

roll back