Broker application pattern::Runtime pattern

Design Last Updated: 10-20-2004
(Click a node to get a detailed explanation.)

The Broker tier in the Application pattern is implemented in this Runtime pattern with a Broker node. The Broker node is responsible for the routing and distribution of incoming messages to the target applications. It has the ability to decompose and recompose messages.

The Application Server/Services nodes execute the logic of the target and source applications.

Broker application pattern=Pub/Sub runtime variation

Design Last Updated: 10-20-2004
(Click a node to get a detailed explanation.)

Pub/Sub is a Runtime variation of the Broker application pattern. In this variation, the Broker node offers a dynamic quality of service named Pub/Sub. The Runtime pattern for this variation is a Collaboration composed from two types of interaction. The first of these is the Message Connection variation. This describes a subscribe/unsubscribe interaction which allows Target Applications to alter the Rules Directory content to add or remove themselves from distribution lists. The second type of interaction is the Broker interaction which describes how a single Source Application can use the Broker node to interact with multiple Target Applications.

The Pub/Sub quality of service can be further qualified as either synchronous or asynchronous. A synchronous interaction occurs when a Target Application only receives messages from the Broker node whilst online. An asynchronous interaction occurs when messages from the Broker node are queued for the Target Application while it is offline.

In this second section we specialize the Broker pattern for the SOA environment using the SOA profile. The SOA profile terminology is indicated using the [SOA] qualifier.

The generic Broker, and Rules Directory in the figure above are specialized in the SOA profile to:

• an ESB (supporting the Broker and Rules Directory requirement plus the SOA infrastructure requirement for service location transparency and interoperability, encapsulated reusable business function and explicit implementation-independent interfaces)
• Service Consumers and Providers

[SOA]Broker runtime pattern (aka ESB runtime pattern)

Design Last Updated: 04-28-2005
(Click a node to get a detailed explanation.)

The use of an Enterprise Service Bus offers the following benefits:

• The ESB is a bus with a single configuration and distributed deployment. Managing communications through the bus provides many advantages, including decoupling of service requesters and providers, and centralized control of a service namespace.
• Protocol conversion occurs inside the ESB (for example, SOAP/HTTP to SOAP/JMS). Requesters using one protocol can invoke services that are exposed using a different protocol.
• The ESB can provide logging and transformation of service requests and service responses.
• The ESB can provide centralized security for Web services invocations. It can, for example, authenticate all service requesters centrally.
• The ESB provides a common access point for service requesters that need access to services providers. The ESB intercepts and routes requests to the relevant service provider. A change in the location of the service provider only affects the ESB routing; the service provider location remains transparent to the service requester.

The ESB Topology patterns are variations of the SOA profile and describe topological relationships between ESBs.

ESB Topology::Directly Connected ESBs

Design Last Updated: 08-07-2009
(Click a node to get a detailed explanation.)

In the directly connected ESBs topology the ESB in domain 1 simply treats the service in domain 2 as another back-end system. Domain 2 continues to own the service and implement its policy and registry definition.

Benefits:

• Relatively simple to configure. The domain 2 service is likely to be exposed in a suitable standard format for easy consumption by the domain 1 ESB.
• Complete decoupling. Neither domain is aware that there is an inter-ESB interaction taking place.
• Local services consumers in domain 2 continue as before since policy is still implemented by the domain 2 ESB.

Limitations:

• A copy of at least part of domain 2’s service definition must copied into the domain 1 repository. This will have to be done explicitly for each individual service exposed in this way. It becomes difficult to have a centralized view of the service catalogue.
• The service is likely to suffer from the costs of implementing policy in both domain 1 and domain 2. In addition to this policy overhead, the request is traversing twice the number of hubs and gateways necessary.
• We are effectively performing point-to-point integration between ESBs. This has the same issues as point-to-point between applications — as the number of ESBs increases, the number of interactions grows exponentially.

ESB Topology::Brokered ESBs

Design Last Updated: 08-07-2009
(Click a node to get a detailed explanation.)

For Brokered ESBs, one ESB is chosen to act as a master domain or broker through which all interactions traverse when they need to make use of a service in another domain.
Domain 1 has been chosen as the master domain. Consumers from other domains such as domain 3 always use domain 1 to get to services that are outside their domain, rather than creating a further connection from their own ESB.

Benefits:

• Domain 1’s registry now represents a catalogue of all the services available in the enterprise.
• If service endpoint details change, they only need to be altered in domain 1.
• Local services consumers in domain 2 continue as before since policy is still implemented by the domain 2 ESB.

Limitations:

• Domain 1’s registry has satellite copies of parts of it’s catalogue spread out among the other ESBs, leading to extra maintenance effort, and opportunities for erroneous configuration.
• We have the overhead of going through three sets of hubs and gateways, and no doubt implementing repeated policies. Now this is probably slightly unfair, since in reality communication would most probably only need to go via the three gateways, with minimal transformation, and then through just the one hub at the end of the chain to reach the provider.

ESB Topology::Brokered ESBs Variation

Design Last Updated: 08-07-2009
(Click a node to get a detailed explanation.)

The Brokered ESB’s variation is a more realistic Brokered ESB topology. Note that some domains such as Domain 3 may not have an ESB and so they would call the domain 1 gateway directly. We also show that domain 1 will most probably also provide services itself, and will have consumers of those and other services.

ESB Topology::Federated ESBs

Design Last Updated: 08-07-2009
(Click a node to get a detailed explanation.)

Each of the domain’s ESBs are autonomous, and yet they all have a knowledge of the wider enterprise-level services. Any consumer can call services in any domain without necessarily having set up the communication paths in advance.

There are some key capabilities that would need to be in place for this pattern to be possible:

• Peer-to-peer lookup or replication facilities between registries
• Standardization of protocols used between ESB Gateways and Hubs
• Trusted channels for intra-ESB traffic between domains
• Standardization of policy attributes
• Capability of all ESB Gateways to be able to retrieve and use service information at run time
• Capability of all ESB Gateways to perform service agnostic policy based on dynamically retrieved policy metadata
• Policy executed to create the same ultimate effect regardless of the gateway implementing the policy

The peer-to-peer relationship is made possible by the fact that the domains registries have knowledge of one another and are able to look up or replicate endpoint information for services that are outside of their domain.

For this pattern to work, there must be some level of agreement at the enterprise level about what protocols and interaction types are allowable between ESB Gateways and Hubs, and there need to be suitable channels opened up across domain boundaries to allow service calls to pass. The two ESB zones represent a set of nodes that communicate with an agreed upon set of protocols over trusted channels.

An interesting consequence of having so rigidly defined the ESB Gateway to Hub protocols is that if an application provides a suitable interface already, it could in theory directly publish itself in the registry as an endpoint. In other words, the application may not need to be connected to a Hub in order to be exposed to the enterprise. It can then be called directly by the ESB Gateways using the same standard protocols used to converse with Hubs. Consumers of the service are already decoupled from future change to the endpoint by virtue of the fact that they call the ESB Gateway and will draw any changes to the service endpoint from the registry at run time.

Benefits:

• Domain 1’s registry now represents a catalogue of all the services available in the enterprise.
• If service endpoint details change, they only need to be altered in domain 1.
• Local services consumers in domain 2 continue as before since policy is still implemented by the domain 2 ESB.

Limitations:

• Domain 1’s registry has satellite copies of parts of it’s catalogue spread out among the other ESBs, leading to extra maintenance effort, and opportunities for erroneous configuration.
• We have the overhead of going through three sets of hubs and gateways, and no doubt implementing repeated policies. Now this is probably slightly unfair, since in reality communication would most probably only need to go via the three gateways, with minimal transformation, and then through just the one hub at the end of the chain to reach the provider.