15
A proposal for ObjectWeb ESB Antoine Mensch October 4, 2004

A proposal for ObjectWeb ESB Antoine Mensch October 4, 2004

Embed Size (px)

Citation preview

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

A proposal for ObjectWeb ESB

Antoine MenschOctober 4, 2004

Page 2: A proposal for ObjectWeb ESB Antoine Mensch October 4, 2004

A proposal for ObjectWeb ESB - Page 2 - october 2004

ObjectWeb ESB

ESB concepts and definitions

Critical design decisionsCommunications backboneESB messagingESB value-added servicesConnectivityTools

Conclusions

Page 3: A proposal for ObjectWeb ESB Antoine Mensch October 4, 2004

A proposal for ObjectWeb ESB - Page 3 - october 2004

XQuark Group

Société de services en logiciel libre, fondée en 2003

MissionFournir 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 J2EEUtilisant 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éesConseil en architecture et modélisationFormation aux standards: XML Schema, XSL-T, XQuery, XForms…Assistance technique et réalisations au forfaitSupport et maintenance

Page 4: A proposal for ObjectWeb ESB Antoine Mensch October 4, 2004

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 interfaceEvent interaction: the message producer publishes the interface

A new generation of integration middlewareBased on open standardsSimpler and cheaper than proprietary EAI softwareProvide built-in routing and transformation services

Main characteristics of an ESBEndpoints

Entry and exit points for messages transiting in the ESBInternal endpoints can also be defined by the administrator

PipelinesProvide configurable endpoint connectionsExecute the value-added services of the ESB

Page 5: A proposal for ObjectWeb ESB Antoine Mensch October 4, 2004

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

Reque

stResponse

Notification

Event Event

Endpoint

Endpoint

Endpoint

Pipeline

Page 6: A proposal for ObjectWeb ESB Antoine Mensch October 4, 2004

A proposal for ObjectWeb ESB - Page 6 - october 2004

Added value of an ESB over a MOM

Transparent message contentEnables generic message processing

ValidationEnrichmentTransformationContent-based routing

Endpoints can be associated with the types of messages they produce and receive

Logical addressingContent-based routing and typed endpoints provide an abstraction layer on top of the physical endpoints

Loose coupling between endpointsMessage producers and consumers may use different endpointsPipelines can be defined to map messages between different endpoints and endpoint message types

Page 7: A proposal for ObjectWeb ESB Antoine Mensch October 4, 2004

A proposal for ObjectWeb ESB - Page 7 - october 2004

Added value of an ESB over Plain Old Web Services

Reliability and scalabilityThe underlying MOM ensures reliable message deliveryThe ESB can be designed to ensure scalability (e.g through a « snowflake » architecture)

Logical addressingThe ESB acts as a message broker that hides the physical location of the invoked service

Definition of new services and federationMessage transformation and enrichment capabilities enable new service definition and service compositionMore advanced orchestration capabilities can be provided transparently

Support for event-driven servicesAn ESB can at last provide semantics for Notification and Solicit-Response message exchange patterns.

Page 8: A proposal for ObjectWeb ESB Antoine Mensch October 4, 2004

A proposal for ObjectWeb ESB - Page 8 - october 2004

Critical design decisions

ESB backboneESB messaging

Message formatEndpoint and service descriptionEndpoint and service discovery

Pipeline definition and executionFunctionalities and languagesExecution architecture

ConnectivityBus connector APIBuilt-in connectors

ToolingDevelopmentConfiguration and deploymentMonitoring

Page 9: A proposal for ObjectWeb ESB Antoine Mensch October 4, 2004

A proposal for ObjectWeb ESB - Page 9 - october 2004

ESB backbone

RequirementsAsynchronous, reliable communications mechanismRobustScalableSecure

JMS is the obvious candidateFirst solution: the ESB is layered on top of the JMS API

High portabilityPerformances and deployment issues

Second solution: the ESB is layered on top of a specific ESB implementation

JORAM

Other protocolsConnectivity to other MOMs (JMS and non-JMS)HTTPSMTPFTP

Page 10: A proposal for ObjectWeb ESB Antoine Mensch October 4, 2004

A proposal for ObjectWeb ESB - Page 10 - october 2004

ESB messagingRequirements

Based on standardsTransparent message contents

Proposed message formatSOAP 1.2 (W3C standard)WS-Addressing (submission to W3C)

Standardised SOAP header contents for protocol-independent addressing informationXML representation of endpoints

Additional WS-* specificationsPolicy, Security, Eventing, Discovery…

Proposed endpoint and service descriptionWSDL 1.1 (W3C note) or 2.0 (Last call WD)Association of a JMS destination and WSDL descriptions

Proposed endpoint and service discoveryCentralized, registry-based: UDDIAd-hoc: WS-Discovery

Page 11: A proposal for ObjectWeb ESB Antoine Mensch October 4, 2004

A proposal for ObjectWeb ESB - Page 11 - october 2004

Pipeline definitionFunctional requirements

Message validationMessage enrichment, transformation and splittingContent-based routing

Non-functional requirementsBased on standardsExtensibleRobust and scalable

Non-exhaustive list of relevant technologiesSchema languages for validationXQuery and XSL-T for message enrichment and transformationRouting language to be defined (based on XPath and simple rules)

Pipeline definitionA pipeline segment is defined by an entry point and one or several exit points, with well-defined message types

It implements a single functionalityA pipeline is built by connecting segmentsEntry and exit points may be ESB endpoints

Page 12: A proposal for ObjectWeb ESB Antoine Mensch October 4, 2004

A proposal for ObjectWeb ESB - Page 12 - october 2004

ESB client

Pipeline execution

As a JMS/ESB clientUses the ESB connector API

No dependency on JMS/ESB implementation

IssuesPerformancesDeploymentLimited added value

Within the JMS/ESB provider

Uses internal API and configuration facilitiesIssues

Dependency on a single JMS/ESB implementation

ESB

ESB

Page 13: A proposal for ObjectWeb ESB Antoine Mensch October 4, 2004

A proposal for ObjectWeb ESB - Page 13 - october 2004

Connectivity

ESB Connector API for « heavy » clientsJMS API

Connection, session, destinationJAX-RPC & JAX-M API

Web Services invocation

Built-in connectorsSOAP over HTTPSOAP over SMTPJMSJCA…

Page 14: A proposal for ObjectWeb ESB Antoine Mensch October 4, 2004

A proposal for ObjectWeb ESB - Page 14 - october 2004

Tooling

DevelopmentService/endpoint definitionsPipeline definitionsBased on standard languages

WSDLXSL-TXQuery

Could rely on existing IDEsEclipse Web Tools projectExtensions for non-standard language

Deployment and monitoringExtensions of existing JMS toolsJMXSNMP

Page 15: A proposal for ObjectWeb ESB Antoine Mensch October 4, 2004

A proposal for ObjectWeb ESB - Page 15 - october 2004

Conclusions

ObjectWeb ESB is a reachable targetMany open-source ESB components are availableWithin ObjectWeb

JORAMXQuarkActive XML

Outside ObjectWebApache: XSL-T, Web Services…

Some additional work is requiredIntegrationTools

The ESB can be used as a foundation for higher-level tools

Business Process ManagementBusiness Activity Monitoring…