Enterprise Service Bus (ESB) (Chapter 9)

1. Enterprise Service Bus (ESB)(Chapter 9) 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. Call Chain • Log file • Start billing • Finish billing • Start reservation • Finish reservation • Start ticketing • Finish ticketing Airline Ticket service Ticketing Billing Reservation

11. 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)

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

13. 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)

14. 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.

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

16. Securing SOA • ESB takes responsibility for securing an SOA • Trusted domains: airlines offering reservation on other airlines

17. ESB Summary • ESB supports easy integration of the various SOA artifacts: routing, messaging, invocation, mediation etc. • ESB also provides the non-functional aspects such as security, availability, reliability, scalability, single sign-on etc. • ESB is sold a software product by such as TIBCO.