1. A proposal for ObjectWeb ESB Antoine Mensch October 4, 2004

2. A proposal for ObjectWeb ESB - Page 2 - october 2004 ObjectWeb ESB ESB concepts and definitions Critical design decisions Communications backbone ESB messaging ESB value-added services Connectivity Tools Conclusions

3. A proposal for ObjectWeb ESB - Page 3 - october 2004 XQuark Group Société de services en logiciel libre, fondée en 2003 Mission Fournir des solutions d’intégration de données adaptées au besoin du client Basées sur le standard XML et ses dérivés, et les serveurs J2EE Utilisant du logiciel libre Gérer les évolutions, la distribution et la maintenance de composants « open source » d’intégration de données En partenariat avec l’Université de Versailles – Saint Quentin, propriétaire original du code Fournir les prestations de service associées Conseil en architecture et modélisation Formation aux standards: XML Schema, XSL-T, XQuery, XForms… Assistance technique et réalisations au forfait Support et maintenance

4. A proposal for ObjectWeb ESB - Page 4 - october 2004 Enterprise Service Bus: a possible definition A foundation for service-oriented and event-driven architectures Service interaction: the message consumer publishes the interface Event interaction: the message producer publishes the interface A new generation of integration middleware Based on open standards Simpler and cheaper than proprietary EAI software Provide built-in routing and transformation services Main characteristics of an ESB Endpoints Entry and exit points for messages transiting in the ESB Internal endpoints can also be defined by the administrator Pipelines Provide configurable endpoint connections Execute the value-added services of the ESB

5. A proposal for ObjectWeb ESB - Page 5 - october 2004 ESB Asynchronous communications SOAP/XML messaging Content-based routing Message transformations Service-oriented and event-driven architecture Request Response Notification Event Endpoint Pipeline

6. A proposal for ObjectWeb ESB - Page 6 - october 2004 Added value of an ESB over a MOM Transparent message content Enables generic message processing Validation Enrichment Transformation Content-based routing Endpoints can be associated with the types of messages they produce and receive Logical addressing Content-based routing and typed endpoints provide an abstraction layer on top of the physical endpoints Loose coupling between endpoints Message producers and consumers may use different endpoints Pipelines can be defined to map messages between different endpoints and endpoint message types

7. A proposal for ObjectWeb ESB - Page 7 - october 2004 Added value of an ESB over Plain Old Web Services Reliability and scalability The underlying MOM ensures reliable message delivery The ESB can be designed to ensure scalability (e.g through a « snowflake » architecture) Logical addressing The ESB acts as a message broker that hides the physical location of the invoked service Definition of new services and federation Message transformation and enrichment capabilities enable new service definition and service composition More advanced orchestration capabilities can be provided transparently Support for event-driven services An ESB can at last provide semantics for Notification and Solicit- Response message exchange patterns.

8. A proposal for ObjectWeb ESB - Page 8 - october 2004 Critical design decisions ESB backbone ESB messaging Message format Endpoint and service description Endpoint and service discovery Pipeline definition and execution Functionalities and languages Execution architecture Connectivity Bus connector API Built-in connectors Tooling Development Configuration and deployment Monitoring

9. A proposal for ObjectWeb ESB - Page 9 - october 2004 ESB backbone Requirements Asynchronous, reliable communications mechanism Robust Scalable Secure JMS is the obvious candidate First solution: the ESB is layered on top of the JMS API High portability Performances and deployment issues Second solution: the ESB is layered on top of a specific ESB implementation JORAM Other protocols Connectivity to other MOMs (JMS and non-JMS) HTTP SMTP FTP

10. A proposal for ObjectWeb ESB - Page 10 - october 2004 ESB messaging Requirements Based on standards Transparent message contents Proposed message format SOAP 1.2 (W3C standard) WS-Addressing (submission to W3C) Standardised SOAP header contents for protocol-independent addressing information XML representation of endpoints Additional WS-* specifications Policy, Security, Eventing, Discovery… Proposed endpoint and service description WSDL 1.1 (W3C note) or 2.0 (Last call WD) Association of a JMS destination and WSDL descriptions Proposed endpoint and service discovery Centralized, registry-based: UDDI Ad-hoc: WS-Discovery

11. A proposal for ObjectWeb ESB - Page 11 - october 2004 Pipeline definition Functional requirements Message validation Message enrichment, transformation and splitting Content-based routing Non-functional requirements Based on standards Extensible Robust and scalable Non-exhaustive list of relevant technologies Schema languages for validation XQuery and XSL-T for message enrichment and transformation Routing language to be defined (based on XPath and simple rules) Pipeline definition A pipeline segment is defined by an entry point and one or several exit points, with well-defined message types It implements a single functionality A pipeline is built by connecting segments Entry and exit points may be ESB endpoints

12. A proposal for ObjectWeb ESB - Page 12 - october 2004 ESB client Pipeline execution As a JMS/ESB client Uses the ESB connector API No dependency on JMS/ESB implementation Issues Performances Deployment Limited added value Within the JMS/ESB provider Uses internal API and configuration facilities Issues Dependency on a single JMS/ESB implementation ESB

13. A proposal for ObjectWeb ESB - Page 13 - october 2004 Connectivity ESB Connector API for « heavy » clients JMS API Connection, session, destination JAX-RPC & JAX-M API Web Services invocation Built-in connectors SOAP over HTTP SOAP over SMTP JMS JCA …

14. A proposal for ObjectWeb ESB - Page 14 - october 2004 Tooling Development Service/endpoint definitions Pipeline definitions Based on standard languages WSDL XSL-T XQuery Could rely on existing IDEs Eclipse Web Tools project Extensions for non-standard language Deployment and monitoring Extensions of existing JMS tools JMX SNMP

15. A proposal for ObjectWeb ESB - Page 15 - october 2004 Conclusions ObjectWeb ESB is a reachable target Many open-source ESB components are available Within ObjectWeb JORAM XQuark Active XML Outside ObjectWeb Apache: XSL-T, Web Services… Some additional work is required Integration Tools The ESB can be used as a foundation for higher-level tools Business Process Management Business Activity Monitoring …