Skip to Content

Just a reference of the earlier blogs for you to refer the whole series

ESB I ESB Basics – I

ESB II ESB Basics – II

ESB III ESB Basics – III

In this blog , Let us have a look at the Usage Patterns of ESB.

Usage Pattern is used to distinguish how the ESB is being used for any process automation.One must note that in the same process, the usage pattern of ESB can be different for different process steps.

The ESB can be classified to have five usage patterns at a high level –

  1. Service Routing
  2. Proxy or Gateway
  3. Transcoder (Protocol Switch)
  4. Discovery/Matchmaking
  5. Distribute

 

The charecteristics of the various patterns are listed below –

  1. Service Routing
  • Request is distributed to at most one of multiple target providers

  • Service selection may involve other SOA components in addition to ESB

  • Service Registry lookup in any of the examples

  • Information lookup from a monitoring tool for the more complex routing that required infrastructure information

   2.      Proxy or Gateway

  • Acts as a single entry point and maps service interfaces or endpoints

  • Normally includes security functions (access control, authorization & auditing)

  • For example, service portals, in which a single point of contact is provided for multiple services and the details of “internal” services may be hidden from the service requestors

   3.    Transcoder (Protocol Switch)

  • Maps requests into the targeted service provider’s format enabling requestors and providers to use differing network protocols
  • Mediation for this pattern can be generated easily when a clear relationship between the two formats is available.
  • For example, SOAP/HTTP requests onto a more reliable SOAP/JMS infrastructure or mapping between JMS and non-JMS applications

   4.   Discovery/Matchmaking

  • Queries ESB registry to discover a set of possible service providers preconfigured at the mediation, selects one, and routes the message there
  • Selecting suitable target services dynamically based on a set of policy definitions i.e. match requestor’s message format, QOS required, or the protocol supported from the mediation to the possible providers
  • For example, in a failover scenario, after bringing up the fallback server and registering services of this server, traffic should be routed to it without having to updating the configuration of every mediation

   5.   Distribute

  • Services that wish to be notified of certain events may be able to add themselves to the interested-parties/subscriber’s list managed by the ESB
  • Message is distributed to more than one target provider, based on a list of interested parties
To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply