Index Changes

Realising SOA Design Patterns in OpenESB

There are many pages on this wiki that show how to implement specific technical features of OpenESB. However, there is far less information to help with the design of solutions that will utilise OpenESB. The goal of this section is to provide information on how to use OpenESB to implement SOA Design Patterns. That is, if you think a particular SOA Design Pattern is useful to your solution design then this section will detail different alternatives for realising that pattern using OpenESB and the consequences of its implementation.

There are many different design patterns that can be used within a SOA architecture style, this information starts with those presented in Thomas Erl's book, SOA Design Patterns. If you don't have a copy, all the patterns also have a basic introduction on the accompanying website. Other sources of Patterns, such as the SOA Patterns book by Arnon Rotem-Gal-Oz, Eric Bruno, and Udi Dahan, will also also be used.

To understand how it is possible to implement these patterns, you will need a basic understanding of how OpenESB works - especially the concepts of the Java Business Integration standard. If you are unfamiliar with these concepts you should start with the following:

  • The OpenESB Introduction Screencast includes a description of JBI explaining how a JBI-based composite application is developed, deployed and how interaction between components happens. The first 15mins provides an introduction to the required JBI concepts.
  • LearnJBI

SOA Design Patterns

Because some patterns are too generic to have direct implementation alternatives, only a subset are relevant for discussion. For instance, the Agnostic Context pattern prescribes how to create reusable services through the partitioning of business logic. This is purely concerned with service identification and design and not something that can be influenced by OpenESB technology. On the other hand, alternatives for how you effectively implement a pattern such as Protocol Bridging can be very much dependent on how OpenESB separates functionality into Service Engines and Binding Components.

The tabbed sections below explain:

  • Which versions of OpenESB this information applies to
  • The structure of the descriptions
  • Browsable list of patterns grouped by:
    • Compound / Group Patterns or
    • Full List of Individual Patterns:

Which version of OpenESB does this refer to?

The descriptions of how to realise different patterns will primarily refer to GlassfishESBv2.x, the supported subset of OpenESB. However, where relevant, these descriptions will be augmented with possible improvements using functionality in OpenESB and Project Fuji. For instance, Project Fuji will provide Interceptors and Aspects to future versions of GlassfishESB. These will provide improved techniques of implementing patterns such as Service Agent and their utilisation will be detailed also.

A common source of confusion for people is the differences between the products/projects: OpenESB, GlassfishESB, Fuji, and JavaCAPS.

The open source project with the latest, greatest updates. Development on components of this project are performed by many individuals and organisations
The subset of OpenESB that is supported by Sun Microsystems. This subset includes components developed by Sun and is limited to those components that are considered ready for production deployments. At the time of writing, the latest release is v2.1
Project Fuji / OpenESBv3.x
Project Fuji is a research project to explore new functionality for OpenESB. The successful results of Project Fuji will form OpenESBv3.x. Its important to note that OpenESBv3.x will be a superset of OpenESBv2.x. That is, applications developed for x2.x will continue to work in v3.x, and descriptions provided here will be forward compatible
Commercial SOA / Business Integration middleware provided by Sun Microsystems. This product includes the latest supported version of GlassfishESB plus additional technologies based on previous versions of JavaCAPS


Short synopsis of the pattern statement, clipped from the website
  • Link to pattern at
  • small image that symbolizes the Pattern. Linked from the external site E.g:

Realisation with OpenESB

Explanation of OpenESB details that are relevant to understanding how the pattern can be realised For instance how do Bindings work, or how is transaction information passed in the Normalized Message

Implementation Scenarios

<> E.g.:

It may be possible to implement this pattern in multiple ways in OpenESB depending on the end-user scenario.

This section lists the most common implementation scenarios and provides a description and/or screencast showing how to implement that scenario.

Most SOA Patterns assume that the ESB is providing smart connections between service consumers and providers that are external to the ESB. However, in OpenESB there can be services offered within the ESB itself - using Service Engines. This has implications for the different ways of realising the patterns. This section should list:

  • Scenarios where services are offered locally in an OpenESB Service Engine (e.g., JavaEE SE, BPEL SE, IEP SE)
  • Scenarios where services are offered remotely via an OpenESB Binding Component (e.g., EJB WS offered by GF but not in the JavaEE SE)

Service offered locally in an Service Engine

  • description of these scenarios

Service offered remotely through a Binding Component

  • description of these scenarios

Other Examples

  • pointers to other examples online that highlight this pattern

Beyond OpenESB v2

Description of any alternative implementation approaches based on new functionality to be released in OpenESB v3

  • Enterprise Service Bus
    • Asynchronous Queuing
    • Intermediate Routing
    • Service Broker
    • and can be further extended via
      • Reliable Messaging
      • Policy Centralization
      • Rules Centralization
      • Event-Driven Messaging

  • Orchestration
    • Process Abstraction
    • State Repository
    • Process Centralization
    • Compensating Service Transaction
    • and can be further extended via
      • Atomic Service Transaction
      • Rules Centralization,
      • Data Model Transformation.
  • Canonical Schema Bus
    • Enterprise Service Bus
    • Decoupled Contract
    • Contract Centralization
    • Canonical Schema
  • Service Interaction Security Patterns (not compound but a group)
    • Data Confidentiality
    • Data Origin Authentication
    • Direct Authentication
    • Brokered Authentication

Individual Patterns List

  • Asynchronous Queuing
  • Intermediate Routing
  • Reliable Messaging
  • Policy Centralization?
  • Rules Centralization?
  • Event-Driven Messaging
  • Decoupled Contract
  • Contract Centralization (NA)
  • Canonical Schema
  • Data Model Transformation
  • Data Format Transformation
  • Protocol Bridging
  • Process Abstraction
  • State Repository
  • Process Centralization
  • Compensating Service Transaction
  • Atomic Service Transaction
  • Logic Centralization (NA)
  • Data Confidentiality
  • Data Origin Authentication
  • Direct Authentication
  • Brokered Authentication
  • Canonical Protocol
  • Dual Protocols
  • Stateful Services?
  • Inventory Endpoint?
  • Non-Agnostic Context?
  • Service Facade
  • Redundant Implementation
  • Service Data Replication?
  • Partial Validation
  • UI Mediator
  • Exception Shielding
  • Message Screening
  • Trusted Subsystem
  • Concurrent Contracts
  • Validation Abstraction
  • Legacy Wrapper
  • Multi-Channel Endpoint
  • File Gateway
  • Service Refactoring
  • Proxy Capability
  • Distributed Capability
  • Service Messaging
  • Messaging Metadata
  • Service Agent
  • Intermediate Routing
  • State Messaging
  • Service Callback
  • Agnostic Sub-Controller
  • Composition Autonomy

JSPWiki v2.4.100
« Home Index Changes Prefs
This page (revision-3) was last changed on 29-Nov-09 13:01 PM, -0800 by jb