Lecture 05 - The Enterprise Service Bus

780 views

Published on

Lecture 05 - The Enterprise Service Bus

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
780
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
33
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Lecture 05 - The Enterprise Service Bus

  1. 1. Book Author: Nicolai M. Josuttis Chapter Five: The Enterprise Service BusIT-Slideshares http://it-slideshares.blogspot.com/
  2. 2. 5.0 ESB introduction PART OF SOA IS THE INFRASTRUCTURE THAT ALLOWS YOU TO USE SERVICES IN A PRODUCTIVE SYSTEM landscape. This is usually called the enterprise service bus (ESB).[4] As youll see in this chapter, there are different opinions about the exact role and responsibilities of an ESB. Part of the reason for the different understandings of ESBs is that there are very different technical approaches to realizing an ESB. This chapter will also explore the consequences of some of these approaches.
  3. 3. 5.1 ESB Responsibilities It is the responsibility of the ESB to enable consumers to call the services providers supply. ESB’s responsibilities.  providing connectivity  Data transformation  (Intelligent) routing  Dealing with security  Dealing with reliability  Service management  Monitoring and logging The ESBs main role is to provide interoperability. Another fundamental ESB task is routing. Extending of the core task of providing interoperability.
  4. 4. 5.2 Heterogeneous ESBs•The ESB was originally considered to be an EAI bus. Web Services becamede facto standard.•Need for mapping proprietary bus to Web Service Bus via gateways.•From the providers and consumers points of view, the service API shouldbe transparent
  5. 5. 5.3 ESB Differences Technically and conceptually, ESBs can differ widely. On one hand, your solution might not involve any specific tool or piece of software at all. Just defining a protocol might be enough (in this case, the ESB would delegate a lot of tasks to the providers and consumers). On the other hand, an ESB might consist of several tools and programs that run centrally, and/or decentrally and are used by service designers, implementers, and operators.
  6. 6. 5.3.1 Point-to-Point Connectionsvs. MediationPoint-to-Point: If the consumer has Mediation: the consumer does not have toto know the endpoint, it sends each know the endpoint of the provider, itrequest to a specific receiver. Call identifies the provided service by a tag orfails if physical receiver is not symbolic that the ESB interprets to find anavailable. appropriate provider. ESB plays the role of a mediator or broker, which leads to a loosely coupled infrastructure.
  7. 7. 5.3.2 Interceptors An ESB based on a point-to-point protocol can support indirect service calls is by providing so-called "interceptors" or "proxies. An ESB with a load balancer for provided services.
  8. 8. 5.3.2 Interceptors (con’t)A more complicated ESB approach provides an interceptor or proxy for eachprovider and for each consumer. In this case, the consumer will communicate in a"point-to-point" fashion only with its specific interceptor. The interceptor willroute each call to the appropriate provider, using its specific interceptor.
  9. 9. 5.3.2 Interceptors (con’t) Note that the Web Services protocol is an inherently point-to-point protocol. Web service standards contain no provisions for load balancing and failover. If left alone, a failed or overloaded web service has no way of routing SOAP requests to alternative web sites. Future ESB based on web services would need to incorporate interceptors, and deal with other aspects such as security and monitoring.
  10. 10. 5.3.3 Protocol-Driven vs. API-Driven ESBFigure 5-6. Connecting to a protocol- Figure 5-7. Connecting to an API-driven ESB. With the protocol-driven driven ESB. With the API-drivenapproach, the ESB defines a protocol, and approach, the ESB defines platform-the providers and consumers send and specific APIs (such as Javareceive messages according to this interfaces), and the providers andprotocol (see Figure 5-6). Web consumers use these APIs for serviceServices, which require a SOAP implementations and service calls.protocol, might be an example for thisapproach.
  11. 11. 5.3.3 Layers from business to Protocol Code The principal tradeoff here has to do with how independent the infrastructure team and development teams for the providers and consumers are. The protocol-driven approach gives providers and consumers more responsibility.
  12. 12. 5.4 Value-Added ESB Services
  13. 13. 5.5 Summary

×