This report looks at the use of the Enterprise Service Bus (ESB) to support layered architecture and varying business requirements and considers the benefits an ESB can deliver. It also looks at appropriate ESB deployment patterns.

The role of SOA Middleware

SOA middleware may seem an oxymoron. SOA is meant to free organizations from the tyranny of tightly coupled implementations, which in my mind includes creating dependences on middleware, not just application and platform-level dependencies.

With support for Web Service protocols embedded in the Application Servers, and WS-STAR1 providing support for federated, secure, reliable, transactions between endpoints, why should there be a need for additional middleware?

The reality is that existing benefits of a middleware approach still largely applies. SOA middleware can be used to:

  • Separate concerns – remove middleware capability such as messaging and mediation away from applications. Though a modern platform can also assist in achieving this, such as Microsoft Windows Communications Framework (WCF)
  • Support Heterogeneity – separate capability away from OS/Platform specific functions
  • Provide a more agile environment where changes to infrastructure do not impact applications, or vice versa
  • Form part of a shared enterprise SOA infrastructure, rather than embedded in or specific to each application solution
  • Manage by policy, and manage centrally. It is easier to deploy and enforce policies through a layer of SOA infrastructure designed for this purpose.
  • Web Services are not the only protocol. Even when they do become widely used, most organizations will continue to use the existing middleware and other protocols already in use for some time. Hence SOA middleware often provides support for other protocols.

A challenge for many organizations today, is that the capability required for SOA middleware and SOA infrastructure in general is that it is spread, and often duplicated across multiple products and technologies. In addition it is often found in a mixture of point solutions and specialist SOA products plus existing infrastructure that is typically upgraded to support SOA requirements. Whilst Table 1 presents some good reasons to consider new infrastructure products to support SOA, it also highlights a strong reason for many organizations to look at how they upgrade their existing infrastructure to support SOA – namely, that they already have it, and the existing infrastructure must remain in place to support existing requirements.

However, it is not as straightforward as depending on existing infrastructure. Although not an immediate concern for some organizations, SOA will place new demands on infrastructure capability that the existing infrastructure cannot so easily support. Longer term, the SOA infrastructure must itself become Service-based and able to be virtualized in the same way that is required of business capability. Even in the near term, organizations can gain advantage from using a networked approach to some SOA middleware requirements rather than using a hub and spoke approach that frequently exists today. Longer term, the federated SOA will make this a requirement.

Continued in PDF

Document Download: Applying ESB (pdf)

Description:

This report looks at the use of the Enterprise Service Bus (ESB) to support layered architecture and varying business requirements and considers the benefits an ESB can deliver. It also looks at appropriate ESB deployment patterns.

Type: pdf

File Size: 2MB

Published: 6 Jan 2011 00:00

Please sign in if you wish to comment.