1 / 15

Enterprise Service Bus (ESB)

Enterprise Service Bus (ESB). B. Ramamurthy. The concept of bus. Consider a hardware bus: connects chips of different functions and from different vendors Now imagine a software bus: a standardized way of hooking together any software components; examples OMG’s CORBA (synchronous)

femma
Télécharger la présentation

Enterprise Service Bus (ESB)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Enterprise Service Bus (ESB) B. Ramamurthy

  2. The concept of bus • Consider a hardware bus: connects chips of different functions and from different vendors • Now imagine a software bus: a standardized way of hooking together any software components; examples • OMG’s CORBA (synchronous) • EJB in J2EE (synchronous) • IBM’s MQSeries (asynchronous) • Tibco’s Rendezvous (asynchronous)

  3. Types of ESB • Ideal software bus supports a single communication model (fig.9.1). • A software bus may also support various communication models at the same time (fig.9.2): synchronous, asynchronous, and file-based. • The infrastructure of a real-world enterprise will normally consist of various products that support similar communication models. • An enterprise is a meta bus that supports various products and technologies of the enterprise • Example: Credit Suisse uses a synchronous information bus, an asynchronous event bus infrastructure and a file transfer-based bulk integration infrastructure driven by application which in turn are driven by business demands.

  4. ESB Functions • Stub/dispatcher code generation (development) • Execution container functions (deployment) • Logging and auditing (runtime management) • An important item is missing in the text: provisioning • Availability and scalability • Securing an SOA

  5. Service stub and dispatcher op1 Service stub Service dispatcher op2 Client implementation API op3 … Op n client server Stub and dispatcher are automatically generated

  6. Execution containers • Application servers • Server farms • Generic features set of an execution container are: • Dispatching and servicing • Transaction management • Security • Logging • Billing • Systems management functionality • Message transformation Execution container Resources: queues, Data Sources, security details

  7. Cross-container integration • Execution containers provide a rich set of functionality that makes deployment and management of individual services reasonably straightforward. • However the key challenge of an enterprise SOA is to define an architecture that enables applications to use different services independently of their container. • Challenges are: interoperability including transactionality and security • Solution: in a system where services are implemented on incompatible execution containers, one must introduce a horizontal infrastructure layer that manages technical cross-container integration of services.

  8. Cross-container Integration Service container Access control service Customer management service Flight reservation service Horizontal cross-container infrastructure (security, transactions, logging) System managing & monitoring

  9. Logging and Auditing • You must best practices to build robust systems. • Even with such systems failures are unavoidable • A error or failure must be reported to the user, to a log file or database and to a systems management system. • Severity of the error is indicated by standard notations such as: “DEBUG”, “ TRACE”, “INFO”, “WARN”, “ERROR”, “FATAL”, and “AUDIT” • Error reporting (SOAP error mechanism “fault”), distributed logging protocols (log locally, view globally) • See Fig. 9-13

  10. Availability and Scalability • Scalability: how well can you system perform under heavy load? What is the max load it can handle? • Availability: How is a failure of a system handled? • Failstop • Failover • Degraded performance (low availability)

  11. Design Choices for scalability and availability • Scalability and availability using WS • Using enterprise java beans (see fig 8.15) • Using CICS • Using CORBA • Legacy applications • Heterogeneous SOA: beware of the weakest link for uptime

  12. Security: Authentication • Authentication means that a service caller is using a mechanism to prove its identity to the called resource. • Individual login : user name , password • SOA level login: Single sign on for all the requests in a session (fig 9-17) • Authenticate yourself with an authentication service that provides tokens or tickets for interaction with subsequent interactions • Security Assertion Markup Language (SAML)

  13. Security: Authorization • Authorization is the mechanism used to grant a caller access to a specific resource. • Static group membership • Role based access and dynamic group membership • The concept of trust domain: appropriate for SOA? • Strict enforcement at application front-end; once certified by this level, can freely access service at lower levels.

  14. Other Security topics • Firewalls (/proxies) • Encryption with various strengths • Secure socket layer (SSL) • Provisioning • Sarbanes-Oxley compliance

  15. Securing SOA

More Related