OSB Patterns and Best Practices

Service Design, Best Practices and Patterns
SOA Best Practices Using WLI 8.1
page 1 of 69
Patterns and Best Practices
Table of Contents
1 2 Introduction ...................................................................................................................... 5 Service Design Process ..................................................................................................... 6 2.1 2.2 2.3 2.4 3 3.1 3.2 3.3 What Is the Service Design Process? ......................................................................... 6 What are the inputs to the Service Design Process? .................................................. 6 What are the steps in the Service Design Process? .................................................... 7 What are the main characteristics of a service? ......................................................... 9 What is the Connectivity Problem? .......................................................................... 11 Published Interface ................................................................................................... 11 What are the Tools to help solve the Connectivity Problem? .................................. 12 Web Services .................................................................................................... 13 JMS, Messaging Bridge ................................................................................... 14 Adapters, Application Views ........................................................................... 15 Controls ............................................................................................................ 16 Event Generators .............................................................................................. 17 WebLogic Tuxedo Connector (WTC).............................................................. 18 HTTP ................................................................................................................ 18 B2B................................................................................................................... 19 JPD Proxy......................................................................................................... 20 Consumer Connectivity .................................................................................... 21 Back-end System Connectivity ........................................................................ 22 Internal Communications ................................................................................. 24 General ............................................................................................................. 25 What is the Data Handling Problem? ....................................................................... 26 What are the Data Handling Tools? ......................................................................... 26 XQuery ............................................................................................................. 26 XSLT ................................................................................................................ 27 Format Builder and MFL ................................................................................. 27 XML Beans ...................................................................................................... 28 Data Model ....................................................................................................... 28
Communications and connectivity ................................................................................ 11
3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.3.6 3.3.7 3.3.8 3.3.9 3.4 3.4.1 3.4.2 3.4.3 3.4.4 4 4.1 4.2
Recommendations .................................................................................................... 21
Data Handling................................................................................................................. 26
4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.3
Recommendations .................................................................................................... 28
page 2 of 69
Process ............................................................................................................................. 30 5.1 5.2 What is the process problem?................................................................................... 30 What are the Tools to help solve the Process Problem? .......................................... 30 Process Properties ............................................................................................ 30 Process Management and Monitoring .............................................................. 35 Patterns ............................................................................................................. 46 The Layers ........................................................................................................ 51 The Access Services Layer .............................................................................. 52 The Co-ordination Service Layer ..................................................................... 53 The Consumer Service Layer ........................................................................... 54 End-to-End Perspective .................................................................................... 54 Service Repository ........................................................................................... 55 Patterns and layers ............................................................................................ 56
5.2.1 5.2.2 5.2.3 6 6.1.1 6.1.2 6.1.3 6.1.4 6.1.5 6.1.6 6.1.7 7 7.1
Layered Architecture ..................................................................................................... 51
Appendix ......................................................................................................................... 58 Graphical Examples of the Core Implementation PAtterns ..................................... 58 Pattern 1: Basic Synchronous Stateless 2-Way Service ................................... 58 Pattern 2: Basic Asynchronous Stateless 2-Way Service................................. 59 Pattern 3: Basic Asynchronous Stateless 1-Way Service................................. 60 Pattern 4: Basic Asynchronous Stateful 2-Way Service .................................. 61 Pattern 5: Basic Asynchronous Stateful 1-Way Service .................................. 62 Pattern 6: Composite Synchronous Stateless 2-way Service ........................... 63 Pattern 7: Composite Synchronous Stateful 2-way Service ............................. 64 Pattern 8: Composite Asynchronous Stateless 2-way Service ......................... 65 Pattern 9: Composite Asynchronous Stateless 1-way Service ......................... 66 Pattern 10: Composite Asynchronous Stateful 2-way Service......................... 67 Pattern 11: Composite Asynchronous Stateful 1-way Service......................... 68 7.1.1 7.1.2 7.1.3 7.1.4 7.1.5 7.1.6 7.1.7 7.1.8 7.1.9 7.1.10 7.1.11 7.2
Web Services Source Code For the Synchronizer PAttern ...................................... 69
page 3 of 69
Table of Figures
Figure 1: Integration Service Design Iterative Process .............................................................. 8 Figure 2: BES Connectivity Decision Flowchart ..................................................................... 23 Figure 3: WebLogic Workshop transformations ...................................................................... 27 Figure 4: Synchronous process start node ................................................................................ 31 Figure 5: Asynchronous process start nodes ............................................................................ 31 Figure 6: Stateless process indicator ........................................................................................ 33 Figure 7: Stateful process indicator .......................................................................................... 34 Figure 8: Timeout path ............................................................................................................. 39 Figure 9: Exception and message paths ................................................................................... 42 Figure 10: Compensation example ........................................................................................... 43 Figure 11: De-Synchronizer Service ........................................................................................ 49 Figure 12: Synchronizer Service .............................................................................................. 50 Figure 13: The SOA Platform layers........................................................................................ 52 Figure 14: End-to-end perspective ........................................................................................... 55 Figure 15: Example of Basic Synchronous Stateless 2-Way service ....................................... 58 Figure 16: Examples of Basic Asynchronous Stateless 2-Way Services ................................. 59 Figure 17: Examples of Basic Asynchronous Stateless 1-Way Services ................................. 60 Figure 18: Examples of Basic Asynchronous Stateful 2-Way Services .................................. 61 Figure 19: Examples of Basic Asynchronous Stateful 1-Way Services .................................. 62 Figure 20: Example of Composite Synchronous Stateless 2-way Service............................... 63 Figure 21: Example of Composite Synchronous Stateful 2-way Service ................................ 64 Figure 22: Examples of Composite Asynchronous Stateless 2-way Services ......................... 65 Figure 23: Examples of Composite Asynchronous Stateless 1-way Services ......................... 66 Figure 24: Examples of Composite Asynchronous Stateful 2-way Services ........................... 67 Figure 25: Examples of Composite Asynchronous Stateful 1-way Services ........................... 68
page 4 of 69
INTRODUCTION
This document outlines the best practices and service implementation patterns that fit into a SOA implementation built using WLI 8.1. Note that this document discusses only design and implementation issues 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 endto-end solution design process. Communications and Connectivity. This section discusses the communications and connectivity issues when designing SOA services, using WLI 8.1. This includes the definition of the published service contract. Data Handling. This section discusses the data handling issues when designing SOA services, using WLI 8.1. Process. This section includes best practices for implementing process in WLI 8.1, 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 BESs 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 cant call the services directly.
page 5 of 69
2
2.1
SERVICE DESIGN PROCESS

WHAT IS THE SERVICE DESIGN PROCESS?
For the purposes of this document, we will assume that WLI 8.1 facilities will be used to produce the integration services. Services will be built using the support for java process definitions (JPDs) in WLI 8.1, 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.
2.2 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 8.1 Documentation. This will include all documentation of WL Integration 8.1, WL Server 8.1, and WL Workshop 8.1. Best Practices and Design Patterns. This will include any generic best practices and design patterns produced for using WL Integration 8.1, 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. Non-Functional Requirements
Functional Requirements
Designer(s) with Previous Experiences

Service Design Process

page 6 of 69
Service Design Solution

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 doability 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 Non-functional requirements should fulfill the SMART criteria.
Further Details 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.
2.3
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:
page 7 of 69
1.
2.
3.
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 BESs, as well as internal connectivity between components within the SOA platform. 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. 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 e.g. 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 We recommend that these steps be performed in sequence. Further Details 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.
page 8 of 69
2.4
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 defined as a service with one call to another component1. Composite defined as a service with more than one call to other components. Synchronous the consumer of such a service will block waiting for the response while the service completes. Asynchronous the consumer of such a service will not block waiting for the response while the service completes. Mixed this will be a service with a Synchronous part followed by an Asynchronous part. Two-way request/reply. One-way fire and forget.
2. Calling Paradigm:
3. Exchange Paradigm:
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 more than 100 service calls per second Medium between 1 and 100 service calls per second Low less than 1 service call per second At-Most-Once the service guaranteed to be executed no more than once. This typically returns a failure to the consumer for them to handle the error/retries. At-Least-Once the service guaranteed to be executed at least once, thus allowing for the possibility of duplicates. Exactly-once (a.k.a. Once-And-Only-Once) 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 all or nothing.
1
5. QOS (reliability):
A component could either be another SOA service or a call to a BES.
page 9 of 69
o They can be updated independently of each other JMS store-and-forward. 6. Duration: Very Short between 0.1 and 10 seconds. Short between 1 and 60 seconds Average between 30 seconds and 1 hour Long between 60 seconds and 1 month
page 10 of 69
3
3.1
COM M UNIC ATIONS AND CON NECTIVITY

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 which back-end systems (BES) need to be called, and how? 2. Consumer Connectivity how will the front-end system (FES) or service consumer invoke the service? 3. Internal Connectivity 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, e.g. RMI, HTTP, IIOP, etc. Direction of Connectivity. The Calling Paradigm used for Connectivity: o Synchronous the consumer of such a service will block waiting for the response while the service completes. o Asynchronous the consumer of such a service will not block waiting for the response while the service completes. o Mixed this will be a service with a Synchronous part followed by an Asynchronous part. Exchange Paradigm: o Two-way request/reply. o One-way fire and forget. Transactional Support. This includes support for propagating transactions. Data Format(s) supported, e.g. XML, FML32 this feeds into the next section on Data Handling for the service.
3.2
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 and/or technologies. See the sections below on the various technologies for discussions around this.
page 11 of 69
High level design guideline There should be a repository of existing published interfaces.
Further Details This should include words describing services, especially in terms of side effects, updates, etc. This should include internal services as well. This should include service design requirements, implementation characteristics, key design decisions, etc.
All services in this repository should be specified in a standard way.
3.3
WHAT ARE THE TOOLS TO HELP SOLVE THE CONNECTIVITY PROBLEM?
The following WL Integration 8.1 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 3.3 discusses each of the features in turn, considering the following uses: Consumer connectivity Back-end system connectivity Internal connectivity
Section 3.4 contains recommendations.
page 12 of 69
Synch/ TransAsynch actional Web Services over HTTP Web Services/ over JMS JMS and Messaging Bridge Adapters and App Views Controls Both Asynch Asynch No Yes2 Yes
Security Notes Yes Yes Yes Connection pooling through MDB pool size for the JMS destination. Connection pooling through MDB pool size.
Both Both
Yes Both
Yes Yes3 Connection pooling dependent on resource control is accessing, e.g. JDBC. Connection pooling through MDB pool size. Security propagation can be enabled with TUXEDO 7.1 and above.
Event Generators WTC Raw HTTP B2B JPD Proxy
Asynch Both Synch Asynch Synch
Yes4 Yes No Yes Yes
No Yes Yes Yes Yes
Table of Technologies with Connectivity Characteristics
3.3.1
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.
3.3.1.1 CONSUMER CONNECTIVITY
Daryl Plummer of Gartner writes that, One 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 environment.
2 3 4
The Transaction does not include the caller of the Web Service. Controls will be executed using the Processs Security credentials. The Transaction semantics covers delivery to the subscribers delivery queues.
page 13 of 69
So, Web services have a means of describing the published interface for a service using a standard WSDL which makes such services easily accessible from most consumer 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.
3.3.1.2 BACK-END SYSTEM CONNECTIVITY
For calls from a SOA Platform to BESs 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, BESs are exposing Web Services.
3.3.1.3 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 8.1 domain, and between WL Integration 8.1 domains.
3.3.2 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, e.g. 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 systems 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, i.e. 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
SOA Best Practices Using WLI 8.1 page 14 of 69 Patterns and Best Practices
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 8.1 (and WLI 7.0), JMS is heavily used for decoupled messaging between processes, and it can also be used for buffering service requests and/or service responses. For messaging between WL Integration 8.1 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.
3.3.3 ADAPTERS, APPLICATION VIEWS
WL Integration 8.1 includes support for both standard J2EE CA 1.0 adapters, as well as adapters which support BEAs proprietary Application Integration (WLAI) extensions. Standard J2EE CA 1.0 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 1.5 specification [2] includes support for events, as well as synchronous and/or transactional calls from an EIS through J2EECA adapters into an application server. In contrast to the J2EE CA 1.0 adapters, WLI 8.1 adapters include support for BEAs 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 8.1 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 8.1, 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
page 15 of 69
platform service to agree on some data, either in the header or the body of the messages, to enable this correlation. In WL Integration 9.0, 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 BESs 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 BEAs 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 8.1 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.
3.3.4 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, e.g. 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 8.1, 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 http://edocs.bea.com/wli/docs81/index.html. The transactional nature of these controls and this is essential knowledge for the process developer using the controls:
Transactional Controls Database JMS WLI JMS Application View (if JCA adapter is transactional) Worklist Timer EJB Message Broker Transformation Process Control Non-Transactional Controls File E-mail Service (JWS) Service Broker5 RosettaNet EbXML6 HTTP (dev2dev) Application View (if JCA adapter is not transactional)
5 6
If a request is buffered, the buffer part if transactional. JMS is used under the covers, so it could be argued that these are transactional up to a point.
page 16 of 69
TUXEDO
The Controls listed above are all documented in the Workshop Help Pages: http://edocs.bea.com/workshop/docs81/doc/en/core/index.html 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. 3.3.4.1 CONSUMER CONNECTIVITY
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 8.1 to communicate with each other.
3.3.5 EVENT GENERATORS
Event Generators can be used together with the Message Broker to enable asynchronous messaging between various event sources and WLI 8.1 BPM services. There are several Event Generators available for WLI 8.1, including the following: JMS File Timer Email HTTP (dev2dev will come out as part of WLI 8.1 SP3 and will be included as part of WLI in WLI 9.0 as well).
In WL Integration 8.1, 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 8.1, 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 8.1 would be the JMS Event Generator, which could be used together with JMS and/or 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.
3.3.6 WEBLOGIC TUXEDO CONNECTOR (WTC)
WebLogic Tuxedo Connector (WTC) is a feature of WL Server 8.1 (and therefore of WL Integration 8.1) 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 8.1, 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 (e.g. Clarify), then WTC is a viable option for providing connectivity between the service consumer and the WLI 8.1 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 8.1 and the BES.
WTC would not be used within a WL Integration 8.1 domain, or between WL Integration 8.1 domains.
3.3.7 HTTP
HTTP is a technology used by several FESs and BESs to enable outbound and/or 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.
page 18 of 69
The HTTP Event Generator is the WLI 8.1 means of enabling FESs 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 8.1 as well through this.
The HTTP Control is the WLI 8.1 means of enabling raw HTTP access to BESs.
Raw HTTP would not be used for communication between WLI 8.1 services.
3.3.8 B2B
B2B is also known as Trading partner integration, WebLogic Integration supports the following B2B protocols and standards:
ebXML 1.0 and 2.0, which is described in Introducing ebXML Solutions. RosettaNet 1.1 and 2.0, 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 (1.1). 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 conversation/message 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 (JPDs). 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 secure/private 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).
3.3.9
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.
page 20 of 69
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 8.1 Domain (see internal connectivity below).
The JPD Proxy could be used for RMI calls to JPDs on remote WLI 8.1 domains.
3.4 3.4.1
RECOMMENDATIONS CONSUMER CONNECTIVITY

Further Details Because JMS is a standards-based technology, multiple client platforms will be able to write to and listen to JMS queues. Some FESs will be unable to write to JMS: EventGenerator can be used in many cases File , Email, HTTP, RDBMS, MQ. Adapter Events for many other EISs. WTC for Tuxedo/Q Because Web Services is a standardsbased technology, multiple client platforms will be able to consume Web Services. Some FESs will be unable to invoke Web Services over HTTP: For Java-based FESs, the JPD Proxy is a valid means of accessing services synchronously. In the next version of the J2EE CA standard version 1.5 [2] 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 FESs use WTC jATMI Blocking protocols do not provide exactlyonce 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.
High level design guideline For asynchronous published service interfaces, use JMS or Web Services over JMS. For FESs 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.
For synchronous, best-effort published service interfaces, use Web Services over HTTP. For FESs 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.
For synchronous, exactly-once published service interfaces, implement using B2B or 2-way Asynchronous.
page 21 of 69
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 noncompliance issues in the consumer application itself.
3.4.2
BACK-END SYSTEM CONNECTIVITY

Further Details This flowchart outlines the decision steps when looking at BES connectivity.
High level design guideline Please see the flowchart below.
Where a particular BES can expose services using multiple different connectivity options, then the recommendations above for consumer connectivity apply. Where a connectivity solution already exists in the enterprise, then the strategic suitability of the solution needs to be taken into account.
It is always best if a BES offers interfaces matching the SOA published interfaces as this limits integration to be done.
Some connectivity solutions will over time become unsupported, or will fall outside of the enterprises 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 BESs.
page 22 of 69
Connectivity already Exists in enterprise? No
Yes
Meets requirements? No Can it be extended? No
Yes
Use it
Yes
Use it
EIS preferred interface Matches technology control? No
Yes
Meets requirements? No
Yes
Use it
Adapter for preferred interface Can be acquired? No
Yes
Meets requirements? No
Yes
Use it
Custom J2EE component
Custom adapter
Custom control
BES modification
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:
page 23 of 69
Connectivity already Exists in enterprise? Meets requirements? Can it be extended? EIS preferred interface matches technology control Meets requirements
Yes No No Yes Yes
Assumption 1 above. Assumption 2 above. Assumption 3 above. New MQ Control in 8.1 SP3. 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.
3.4.3 INTERNAL COMMUNICATIONS
Further Details The Messaging Bridge supports all of the QOS options for asynchronous messaging between the domains. The store-andforward capabilities of the Messaging Bridge insulate local processes from problems with access to remote providers. 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. JMS is more efficient than marshalling large messages in web services. The process control is transactional and avoids SOAP marshalling. The service control and service broker controls are not transactional.
High level design guideline For 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.
For asynchronous 2-way communications between processes in the same domain, we recommend the use of the Process Control rather than the Message Broker.
Use raw JMS where the message size is large. 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. 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 dont provide transaction propogation but do enable loose coupling. The service broker control allows for configurable routing of service calls to
Use the service broker control rather than the service control or process control, if the data-dependent routing
page 24 of 69
facilities this offers are needed.
different service implementations depending on data, but note that it is not transactional.
3.4.4
GENERAL
Further Details All controls should be written with a focus on being reusable across process definitions. They should also be defined in the SOA Component inventory. Maximum use of the controls available in WLI8.1 should be made and bespoke controls should be written only when necessary and the re-use has been clearly justified Creating a control for custom java code means that this code can be reused across different process definitions. EJBs can also be created for reuse of business logic. Controls should be treated as java code and versioned appropriately. Controls should be imported from the SOA component library into this project. They then become available to all the application. This will provide ability to log to different locations and at different logging levels
High level design guideline Control reuse
Custom controls development should be done with consideration of native WLI 8.1 controls
Custom Controls should be used instead of custom java code if reuse of this code is a consideration
Controls should be versioned in source code control Each application project in workshop should have a separate control project Each process should carry out logging using a standard logging control
page 25 of 69
4
4.1
D AT A H AND LING
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 BESs? 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 and/or 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 Data 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. Further Details 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 cant be solved generically.
4.2
WHAT ARE THE DATA HANDLING TOOLS?
The following are features that could be used to solve data handling problems within WLI 8.1: XQuery XSLT Format Builder, MFL XML Beans Data Model
XQUERY
4.2.1
Within WLI 8.1 processes, it is possible to achieve the following types of transformations using XQuery: Several Typed Variables => 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)
page 26 of 69
Non-XML messages defined by a MFL format (defined using Format Builder). Complex java objects defined by a class definition. Java scalars, e.g. String.
Figure 3: WebLogic Workshop transformations
Within WLI 8.1, 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 DTDs 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.
4.2.2 XSLT
For XMLXML data transformations, WLI 8.1 also supports XSLT. Note that XSLT is supported for backward compatibility with previous versions of WLS/WLI. XSLT support can also be accessed using Java API calls.
4.2.3 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 8.1 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 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
page 27 of 69
applications 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.
4.2.4 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 (http://xml.apache.org/xmlbeans/) called XML Beans. XML Beans are a native supported part of WL Platform 8.1, although they can also be downloaded from Apache at the following URL: http://xml.apache.org/xmlbeans/sourceAndBinaries XML Beans can therefore be used within WLI 8.1 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.
4.2.5 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 standard form. 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 standard form, decoupling the hosts data model from the data model of the recipient. The successful implementation of a common data model relies on enterprise buy in and rigid enforcement. If this is not the case, then over time, several versions will evolve and coexist, 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.
4.3
RECOMMENDATIONS
Further Details XQuery has many advantages over XSLT, including additional functionality, and better performance. 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.
High level design guideline For new data transformations, we recommend that these should always be created using XQuery rather than XSLT. 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.
page 28 of 69
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 way. This also includes standard message headers etc. 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. This allows other components to call it as a service. Including direct calls from a FES. XML Beans overlap with XQuery in functionality but become part of the source of any process implementation.
The recipient of a message should have no knowledge of the origination of the message.
Any re-usable transformation should be wrapped as stateless process. XQuery should be used wherever possible as they enable re-use at the control level.
page 29 of 69
5
5.1
PROCESS
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.
WHAT ARE THE TOOLS TO HELP SOLVE THE PROCESS PROBLEM?
5.2
Services will be built using the support for java process definitions (JPDs) in WLI 8.1, 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.
5.2.1 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.
5.2.1.1 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.
5.2.1.2 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).
page 30 of 69
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 asynchronous/synchronous.
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.
page 31 of 69
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 Asynchronous 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. An asynchronous reply control should always have a timeout method implemented. Further Details 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. 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, e.g. 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. In general, this should only be considered for services involving quick response times from BESs 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 BESs would be when the service is called in low volumes. The asynchronous subscription causes the subscribed process to run in a different transaction from the publisher's 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.
When a quick response time is needed for a service, then synchronous processes are often more suitable than asynchronous processes.
An asynchronous subscription start pattern is recommended over the synchronous subscription start.
5.2.1.3 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
page 32 of 69
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 Do not use default values in global variables unless the variable is either declared static or final. Do initialize all global variables before using them. 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. Further Details 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. 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, longrunning 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
page 33 of 69
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
5.2.1.4 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 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.
page 34 of 69
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 It is not advised to implement a 2-way process with an event choice that is a combination of client requests and subscriptions. A 2-way asynchronous pattern is more performant to implement using two 1-way asynchronous processes. Further Details 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. This is only possible where the request/reply are decoupled - reply branch does not need any information held in the request branch.
5.2.2
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
5.2.2.1 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.
page 35 of 69
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 Adding transactional boundaries will introduce a quiescent point for the process definition. Further Details 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

Transactions and controls
Async call to Stateful Process
When building processes and accessing resources through controls the designer/implementer 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 3.3.4 Controls for a list of common controls.
page 36 of 69
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 commit/abort 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 abort/rollback 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 A process needs to have exception handlers in place to catch any issues and make the necessary transaction decisions. Further Details Nothing must ever be left to default, always catch exceptions and decide what to do. This is applicable to transactional and nontransactional resources. The original process calls the sub-processes asynchronously because synchronously called subprocesses run in the same transaction as the calling process.
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.
5.2.2.2 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 (YES/NO) 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.
page 37 of 69
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 Worklist jeopardy management would need to be designed into the process. Further Details 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 technical/infrastructure problems.
5.2.2.3 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 cant 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 Tracking data should only be used for operational support, and not for business/audit logging. Process tracking should be disabled for processes that require high performance. WLI system data should only be used for support and not business level audit. Further Details Tracking data should be purged regularly. Tracking can be dynamically toggled on/off for each process at runtime using the WLI console. Process tracking involves a number of database write. For performance reasons, tracking must be eliminated. The WLI system data should not be used for business level audit. A designed audit/logging framework must be implemented outside of WLI system data capture. On any error/log/audit message always record the InstanceID. 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. 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. Using a naming convention for processes ensures that support staff can easily find processes when required.
Always log the InstanceID.
Archiving of WLI data must be scheduled.
Set Process Label to relevant query values.
Use a naming convention for naming processes.
page 38 of 69
5.2.2.4 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: Skipskip 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. Resumeresume 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 Any stateful process must have a timeout set to enable completion. Further Details 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, e.g. 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. A calling component should never timeout before the called component returns with a response or a timeout error. This is also
(Note that stateless processes never have a quiescent point so cant implement timeouts).
For synchronously called services, which involve timeouts configured for several components, it is essential that the lowest-level component times out
page 39 of 69
and propagates an error through the component stack.
known as a timeout funnel, with the timeouts getting smaller as the call progresses along the component stack. This needs to be designed to cope with stale response messages on queues.
For asynchronously called services, which involve timeouts configured for several components, fallout management is much more complicated than for synchronous. 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 process. Business retries require specific business rules that should be owned by the FES and BES.
5.2.2.5 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 Suspend, Terminate Resume, Terminate Terminate, Unfreeze Terminate
Running
Suspended
Frozen
Aborted
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.
page 40 of 69
High level design guideline All processes must have the ability to complete.
Further Details 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, e.g. 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.
5.2.2.6 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 rollsback 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 freeze on failure 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.
High level design guideline Asynchronous 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. All stateless processes must throw an exception back to the caller. Process designers should establish a process level exception handler on every process definition
Process designers should be especially careful on exception handling on processes that are called through the process control synchronously Process designers should use interruption handlers natively available within WLI 8.1
Further Details 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. 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. 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 unfreeze the process. Unhandled exceptions in the called process set transactions to roll back only, both sub process and caller process will be rolled back. This includes the ability to receive interrupts from client applications as well as timeouts
5.2.2.7 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
page 42 of 69
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 execute on rollback 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 Automatic execution of compensating transactions should only be implemented with extreme caution. Further Details 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.
5.2.2.8 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 JMS Asynchronous Services section apply in this case.
5.2.2.9 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 Process versioning should be used for all processes. Further Details 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. This describes how to invoke sub processes when different versions of the parent process exist. From the strategy drop-down menu: Select loosely-coupled if you want the subprocess version to be set at the time that the sub process is invoked. Select tightly-coupled if you want the subprocess version to be set at the time the parent process is invoked.
Process version strategy needs to be set according to parent-child relationship.
page 45 of 69
5.2.3
PATTERNS
A process can be looked at based on 4 sets of properties (as described in Process properties): 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.
5.2.3.1 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 1 Not valid. Reason Not valid. Reason Not valid. Reason 2 3 4 5 6 Not valid. Reason 7 Not valid. Reason 8 9 10 11 Complexity Basic Basic Basic Basic Basic Basic Basic Basic Composite Composite Composite Composite Composite Composite Composite Composite Calling paradigm Synchronous Synchronous Synchronous Synchronous Asynchronous Asynchronous Asynchronous Asynchronous Synchronous Synchronous Synchronous Synchronous Asynchronous Asynchronous Asynchronous Asynchronous State Stateless Stateless Stateful Stateful Stateless Stateless Stateful Stateful Stateless Stateless Stateful Stateful Stateless Stateless Stateful Stateful Exchange paradigm 2-way 1-way 2-way 1-way 2-way 1-way 2-way 1-way 2-way 1-way 2-way 1-way 2-way 1-way 2-way 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
page 46 of 69
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: 0.1 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 1 2 3 4 5 6 7 8 9 10 11
Basic Basic Basic Basic Basic Composite Composite Composite Composite Composite Composite Synch Asynch Asynch Asynch Asynch Synch Synch Asynch Asynch Asynch Asynch SL SL SL SF SF SL SF SL SL SF SF 2-way 2-way 1-way 2-way 1-way 2-way 2-way 2-way 1-way 2-way 1-way
Volume High High High Medium/Low Medium/Low High/Medium/Low Medium/Low High/Medium/Low High/Medium/Low Medium/Low Medium/Low
QOS All All All All All All All All All All All
Duration Very short Very short Very short Short Short Short Short/Average/Long Short Short Short/Average/Long Short/Average/Long
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 processs client is required.
page 47 of 69
Pattern 3: Basic Asynchronous Stateless 1-Way Service
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.
Pattern 5: Basic Asynchronous Stateful 1-Way Service
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 request/reply. 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.
Pattern 9: Composite Asynchronous Stateless 1-way Service
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 longrunning processes.
Pattern 11: Composite Asynchronous Stateful 1-way Service
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.
5.2.3.2 OTHER PATTERNS
This section regroups useful patterns, which can be used in combination with one of the core patterns.
5.2.3.2.1 DE-SYNCHRONIZER
The De-synchronizer pattern allows you to asynchronously call a synchronous process. This is recommended if:
page 48 of 69
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-process return value to its caller.
High level design guideline If there is a requirement for a stateless process to support both asynchronous and synchronous clients, use the de-synchronizer pattern. Further Details It is harder to maintain a process if it has multiple start nodes.
5.2.3.2.2
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.
page 49 of 69
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-services return value. An example implementation of such a web service can be found in appendix.
Other approaches
Where a synchronizer approach cant 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 Normally, do not allow stateful processes to be called synchronously. If absolutely required, use the synchronizer pattern. It is recommended to implement the synchronizer pattern at the FES. 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. Further Details Please refer to discussion in the section above.
This is where the business rules that are needed to implement the fallout management are known. WebLogic server provides the whole J2EE specification to aid this implementation.
page 50 of 69
L AYERED ARCH ITECTURE
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.
6.1.1 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 services 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.
page 51 of 69
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 BESs 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 cant call the services directly.
The other main concept is that a service at any layer can be called by a FES, you dont have to progress through all layers in the architecture. Because an individual Enterprise Information System (EIS) can fulfil one or both of the FES/BES roles, it may expose services through the Access Layer and also make requests of services through the consumer layer.
6.1.2 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 its simplest form it is just a BES exposed through a Control. For example a J2EE Connection Architecture Adapter (J2EECA) Database
page 52 of 69
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 BESs 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 create customer 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, i.e. 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.
THE CO-ORDINATION SERVICE LAYER
6.1.3
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.
page 53 of 69
Standalone data integration services, i.e. services that offer data transformations, data mapping (including key mapping), data dependent routing, reside in this layer. These may or may not access BESs via the access layer.
6.1.4 THE CONSUMER SERVICE LAYER
The primary purpose of the consumer service layer is to connect the platform with application service consumers, i.e. 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 platforms 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.
6.1.5 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 platforms 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 platforms governance rules are always satisfied.
page 54 of 69
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.
6.1.6 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 services function and intent. The functional and non-functional requirements. The layer in which the service sits as well as its granularity. The services detailed interfaces. This include published and/or private interfaces and for each interface all the details such as URL, methods, arguments types and required values and usage. The services owner. This may be an individual or (more usually) an organization that is responsible for maintaining the service.
page 55 of 69
6.1.7
PATTERNS AND LAYERS
There isnt 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 (i.e. whenever the BES interface is also synchronous), while implementing the higher-level coordination layer services as asynchronous.
High level design guideline 2-way Access layer services should be synchronous whenever possible. Further Details 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. This allow for maximum decoupling
Coordination layer services should normally be asynchronous.
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 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 desynchronizer pattern to provide also an asynchronous interface to the coordination layer
page 56 of 69
services. Thus, clients that do not require the high-throughput can use the asynchronous interface.
High level design guideline For high-performance, all synchronous services may be required. If a process has a long duration, it must be configured to maintain long conversation with its clients. Providing also an asynchronous interface to synchronous coordination layer services allows for more decoupling. Further Details Some use case non-functional requirements need to have a fast response or high volume, The conversation duration of a process is configured through its max-age property. The default is 1 day. 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 When 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. Further Details Project-specific requirements should not impede on the reusability of the services in the access layer.
page 57 of 69
7
7.1
APPENDIX
GRAPHICAL EXAMPLES OF THE CORE IMPLEMENTATION PATTERNS PATTERN 1: BASIC SYNCHRONOUS STATELESS 2-WAY SERVICE
7.1.1
Figure 15: Example of Basic Synchronous Stateless 2-Way service
page 58 of 69
7.1.2
PATTERN 2: BASIC ASYNCHRONOUS STATELESS 2-WAY SERVICE
Figure 16: Examples of Basic Asynchronous Stateless 2-Way Services
page 59 of 69
7.1.3
PATTERN 3: BASIC ASYNCHRONOUS STATELESS 1-WAY SERVICE
Figure 17: Examples of Basic Asynchronous Stateless 1-Way Services
page 60 of 69
7.1.4
PATTERN 4: BASIC ASYNCHRONOUS STATEFUL 2-WAY SERVICE
Figure 18: Examples of Basic Asynchronous Stateful 2-Way Services
page 61 of 69
7.1.5
PATTERN 5: BASIC ASYNCHRONOUS STATEFUL 1-WAY SERVICE
Figure 19: Examples of Basic Asynchronous Stateful 1-Way Services
page 62 of 69
7.1.6
PATTERN 6: COMPOSITE SYNCHRONOUS STATELESS 2-WAY SERVICE
Figure 20: Example of Composite Synchronous Stateless 2-way Service
page 63 of 69
7.1.7
PATTERN 7: COMPOSITE SYNCHRONOUS STATEFUL 2-WAY SERVICE
Figure 21: Example of Composite Synchronous Stateful 2-way Service
page 64 of 69
7.1.8
PATTERN 8: COMPOSITE ASYNCHRONOUS STATELESS 2-WAY SERVICE
Figure 22: Examples of Composite Asynchronous Stateless 2-way Services
page 65 of 69
7.1.9
PATTERN 9: COMPOSITE ASYNCHRONOUS STATELESS 1-WAY SERVICE
Figure 23: Examples of Composite Asynchronous Stateless 1-way Services
page 66 of 69
7.1.10 PATTERN 10: COMPOSITE ASYNCHRONOUS STATEFUL 2-WAY SERVICE
Figure 24: Examples of Composite Asynchronous Stateful 2-way Services
page 67 of 69
7.1.11 PATTERN 11: COMPOSITE ASYNCHRONOUS STATEFUL 1-WAY SERVICE
Figure 25: Examples of Composite Asynchronous Stateful 1-way Services
page 68 of 69
7.2
WEB SERVICES SOURCE CODE FOR THE SYNCHRONIZER PATTERN
public class Synchronizer implements com.bea.jws.WebService { /** * @common:control */ private templates.util.AsynchProcessPControl asynchProcessControl; private String clientResponse; private String status = "NOT_STARTED"; static final long serialVersionUID = 1L; /** * @common:operation * @jws:conversation phase="continue" */ public String checkStatus() { return this.status; } /** * @common:operation * @jws:conversation phase="finish" */ public String getFinalResult() { return this.clientResponse; } /** * @common:operation * @jws:conversation phase="start" */ public void startAsynchProcess(java.lang.String x0) { asynchProcessControl.clientRequest(x0); status = "IN_PROGRESS"; } public void asynchProcessControl_clientResponse(String x0) { clientResponse = x0; this.status = "DONE"; } }
page 69 of 69

OSB Patterns and Best Practices

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OSB Patterns and Best Practices

Uploaded by

Copyright:

Available Formats

Service Design, Best Practices and Patterns

SOA Best Practices Using WLI 8.1

Patterns and Best Practices

Communications and connectivity ................................................................................ 11

4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.3

SOA Best Practices Using WLI 8.1

Patterns and Best Practices

Layered Architecture ..................................................................................................... 51

Web Services Source Code For the Synchronizer PAttern ...................................... 69

SOA Best Practices Using WLI 8.1

Patterns and Best Practices

SOA Best Practices Using WLI 8.1

Patterns and Best Practices

SOA Best Practices Using WLI 8.1

Patterns and Best Practices

SERVICE DESIGN PROCESS

Designer(s) with Previous Experiences

Service Design Process

Service Design Solution

WHAT ARE THE STEPS IN THE SERVICE DESIGN PROCESS?

SOA Best Practices Using WLI 8.1

Patterns and Best Practices

Figure 1: Integration Service Design Iterative Process

SOA Best Practices Using WLI 8.1

Patterns and Best Practices

WHAT ARE THE MAIN CHARACTERISTICS OF A SERVICE?

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

SOA Best Practices Using WLI 8.1

Patterns and Best Practices

SOA Best Practices Using WLI 8.1

Patterns and Best Practices

COM M UNIC ATIONS AND CON NECTIVITY

SOA Best Practices Using WLI 8.1

Patterns and Best Practices

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

WHAT ARE THE TOOLS TO HELP SOLVE THE CONNECTIVITY PROBLEM?

Section 3.4 contains recommendations.

SOA Best Practices Using WLI 8.1

Patterns and Best Practices

Event Generators WTC Raw HTTP B2B JPD Proxy

Asynch Both Synch Asynch Synch

Yes4 Yes No Yes Yes

No Yes Yes Yes Yes

Table of Technologies with Connectivity Characteristics

SOA Best Practices Using WLI 8.1

Patterns and Best Practices

SOA Best Practices Using WLI 8.1

Patterns and Best Practices

SOA Best Practices Using WLI 8.1

Patterns and Best Practices

3.3.5.1 CONSUMER CONNECTIVITY

3.3.5.2 BACK-END SYSTEM CONNECTIVITY

SOA Best Practices Using WLI 8.1

Patterns and Best Practices

3.3.7.1 CONSUMER CONNECTIVITY

3.3.8.1 CONSUMER CONNECTIVITY

SOA Best Practices Using WLI 8.1

Patterns and Best Practices

3.3.9.1 CONSUMER CONNECTIVITY

RECOMMENDATIONS CONSUMER CONNECTIVITY

SOA Best Practices Using WLI 8.1

Patterns and Best Practices

BACK-END SYSTEM CONNECTIVITY

High level design guideline Please see the flowchart below.