1. The Next Generation ESB
Apache ServiceMix 4.0
The Next Generation ESB
Guillaume Nodet

2. About the author Open Source IONA Principal Engineer Guillaume Nodet
PMC Chair of the Apache ServiceMix project
Involved in Apache Geronimo, Apache ActiveMQ, Apache ODE, Apache CXF, Jencks
Previously involved in XFire, Mule
IONA Principal Engineer
Since LogicBlaze acquisition in April 2007

3. Schedule JBI 1.0 Apache ServiceMix 4.0 Building blocks
Overview
Architecture
WSDL Messaging Model
Normalized Message Router
Lessons learned
Apache ServiceMix 4.0
Goal
Standard based
Simplified API
Building blocks
OSGi as a platform
Spring for configuration
Intuitive EIP router
High performance message broker
Easy to use Services Framework
Around the container
Eclipse tooling
Long term
JBI 2.0, SCA
Demo

4. JBI 1.0: what is JBI? Integration Systems Plug-in Components
Normalized exchanges
WSDL
Decoupling
JBI is a java based standard to build integrations systems by using plug-in components which interoperates through mediated normalized message exchanges.
The message exchange model is based on the web services description language (WSDL).
The figure at the top shows a high level concept of JBI of the plug-in framework. The JBI environment provides interfaces to be used by plug-in components, while the components provides interfaces used by the JBI environment. Components do not interact with each other directly. Instead, as shown in the bottom figure, JBI acts as an intermediary to route messages between components. This separation is the key to decoupling between service providers and consumers, which is one of the goal of service oriented architectures. In addition, it provides a key point for message processing and monitoring.
In this WSDL-based, service-oriented model, JBI plug-in components are responsible for providing and consuming services. By providing a service, a component is making available a function or functions that can be consumed by other components (or even itself). Such functions are modeled as WSDL 2.0 operations, which involve the exchange of one or more messages. A set of four WSDL-defined, basic message exchange patterns (MEPs) crisply defines the sequence of messages allowed during execution of an operation. This shared understanding, between consumer and provider components, of the message exchange pattern is the foundation of interoperability of such components in JBI.
The services provided by components (if any) are described to JBI by the component, using WSDL 1.1 or This provides an abstract, technology-neutral model of services using XML-based message exchanges. WSDL also provides a mechanism for declaring additional service metadata of interest to service consumers and JBI itself. Components can query JBI for the for the WSDL describing available services.

5. JBI 1.0: architecture
This picture describes the architecture of the JBI system.
The JBI environment provides deployment, control & monitoring features through JMX based administration tools
The Normalized Message Router or NMR, which provides the mediated message exchange infrastructure
Components (in white rectangles)
Components are divided in two categories:
Service Engines (on top) provides business logic and transformation services and also consumes such services.
Binding Components provide connectivity to services external to the JBI environment.
Service engines and binding components can function as service providers, consumers, or both. Note that the distinction between SEs and BCs is purely pragmatic, but the separation of business logic from communications logic reduces complexity and increases flexibility.
The JBI environment, in addition to the messaging system, defines a management structure based on JMX which provides standard mechanisms for:
Installing components
Managing a component’s life cycle (start / stop)
Deploying service artifacts to components
JBI components often function as a type of container to which artifacts can be deployed to add new service or provider logic. For example, a service engine that provides XSLT-based transformation services would have XSLT style sheets deployed to it, in order to add new transformation operations. This process of adding such component-specific artifacts to an installed component is called deployment, to distinguish it from component installation. Such an artifact is called a service unit, while collection of deployment artifacts and associated metadata is called a service assembly.
The core message exchange concept implements WSDL messaging. Service requests are generated by consumer components, routed by the NMR, and delivered to a provider component. For example, the BPEL SE may generate a request, which happens to be provided by the external service provider connected to the WS-I BC. The NMR will route the request to the WS-I binding. The SE in this case is a service consumer, and the BC a provider.

6. JBI 1.0: WSDL messaging model
Abstract model
Concrete model
Service providers
Service consumers
JBI models services produced and consumed by components using Web Service Description Language 1.1 or When the terminology differs between the two version, the 2.0 one is used. This is mainly the case for the interface and endpoint terms, which are called respectively “port type” and “port” in WSDL 1.1.
WSDL provides a declarative model of message-based services on two levels:
The abstract model defines services without references to a particular protocol or wire encoding
The concrete model is bound to a particular communication protocol and communications endpoint
JBI uses the abstract service model as the main basis for component interactions. Components play one of two roles in such interactions:
Service provider. The component that performs the given service (either directly or as a proxy for an external provider)
Service consumer. The component that invokes a given service (either directly or as a proxy for an external consumer)

7. JBI 1.0: WSDL messaging model
Abstract model
Message type
Normal
Faults
Operation
Qualified name
Message Exchange Pattern
Message types
Interface
Operations
Extended interfaces
WSDL service description always include an abstract service model which defines:
Message types are defined using XML schema. These can be normal messages (for the expected use of the service) or faults (for abnormal processing conditions).
Operations are interactions with a service defined in terms of normal and optional faults messages between a service consumer and a service provider. An operation is defined by:
An operation name which is a qualified name
A Message Exchange Pattern (MEP) that describes the sequence, direction and cardinality of messages sent between the consumer and provider.
Message types for each message in the MEP.
Interfaces are collections of related operations. Note that this term is unrelated to the Java Language interface definition. An interface is defined by:
An interface name: a qualified name identifying the service type globally
A set of extended interfaces. This is the same concept as in the Java Language. This means a service type may be composed of other service types.

8. JBI 1.0: WSDL messaging model
Concrete model
Binding type
Endpoint
Endpoint name
Service
Qualified name
Interface name
Endpoints
Concrete service descriptions in WSDL build upon the abstract service model, supplying information needed to "map" the abstract definition to a particular communications protocol and communications endpoint. JBI bases its component interaction model primarily on the abstract service model, thus giving it the desirable property of being communications protocol neutral. However, to be consistent with the WSDL service model, component interactions need to be defined using WSDL’s concrete service model. In JBI this is a very simple model, using the abstract model "as is" wherever possible, thus creating a simple processing model for interacting components.
The concrete service model defines the following items:
Binding types. A binding type identifies the type of protocol to which the service is being "bound".
Endpoints. An endpoint designates the communications endpoint information needed by a service consumer to interact with a service provider, using a particular protocol. In JBI endpoints are pro forma; the only protocol used internally is the standard Java-based JBI messaging contracts, which do not involve the use of normal communications protocols at all. An endpoint definition includes the following items that are of interest to JBI:
Endpoint name. This is a simple name, used to designate the endpoint within its service.
Binding type. This associates a binding type with an endpoint.
Service. A service is a collection of endpoints that offer access to the same service. A service "implements" a particular service type (interface). A service has the following items:
Service name. A qualified name used to indicate the particular service implementation.
Service type name. The name of the interface implemented by the service.
Endpoints. The service "contains" one or more endpoints, which are the individual endpoints providing access to the concrete service.
Note that normally an endpoint is identified by the combination of its service name and its endpoint name. This combination is referred to as the service endpoint.

9. JBI 1.0: Normalized Message Router
Consumers and providers
Normalized Message
Delivery Channel
Run-time Endpoint Activation
Service invocation and MEPs
Message Exchange
Endpoints
The Normalized Message Router (or NMR) receives message exchanges from JBI components and routes them to the appropriate component for processing. This decouples the service producers from consumers and enable additional processing.

10. JBI 1.0: Normalized Message Router
Consumers and providers
Normalized Message
Delivery Channel
Run-time Endpoint Activation
Service invocation and MEPs
Message Exchange
Endpoints
Consumers and providers
WSDL description
Abstract model
Decoupled
JBI components (Service Engines and Binding Components) can act as a servicemix consumer, provider or both.
The provider makes a WSDL-described service available through an endpoint. This service implements a WSDL interface, which is a collection of operations.
The consumer can invoke the service by creating a message exchange that invoke a particular operation.
Consumers and providers only share the abstract service definition and are thus decoupled, as the consumer does not know the protocol and location of the invoked service.
Several services can implement the same WSDL interface so a consumer looking providers of an interface may find more than one endpoint

11. JBI 1.0: Normalized Message Router
Consumers and providers
Normalized Message
Delivery Channel
Run-time Endpoint Activation
Service invocation and MEPs
Message Exchange
Endpoints
Normalized Message
XML payload
Properties
Attachments
JBI uses the concept of a normalized message for interactions between consumers and providers.
A normalized message consists of three parts:
A payload, which is an xml document that conforms to a WSDL message type without any protocol or encoding
Properties (or metadata) holds extra data associated with the message (security, transactions …)
Attachments are arbitrary (non-xml) data that contain a data handler to manipulate them

12. JBI 1.0: Normalized Message Router
Consumers and providers
Normalized Message
Delivery Channel
Run-time Endpoint Activation
Service invocation and MEPs
Message Exchange
Endpoints
Delivery Channel
Communication between a component and the NMR
A Delivery Channel is a bidirectional asynchronous communication pipes between a component and the NMR.
A service consumer uses its delivery channel to initiate a service invocation, while the provider uses its delivery channel to receive such invocations.
Each component is provided with a single delivery channel, so the same channel is used for both inbound and outbound communications.

13. JBI 1.0: Normalized Message Router
Consumers and providers
Normalized Message
Delivery Channel
Run-time Endpoint Activation
Service invocation and MEPs
Message Exchange
Endpoints
Endpoint activation
Declaring Service endpoint
Providing metadata
Endpoint activation is the process by which a service provider tells the NMR that it provides services, making them known to the NMR so that it can route service invocations to that service.
The activation is split in two steps”
Declaring a service endpoint (service QName + endpoint name)
Providing metadata: the component has to provide a WSDL description of the activate endpoint
The WSDL description will be used by the NMR to know which interfaces and operations are implemented by the activated endpoint.

14. JBI 1.0: Normalized Message Router
Consumers and providers
Normalized Message
Delivery Channel
Run-time Endpoint Activation
Service invocation and MEPs
Message Exchange
Endpoints
Service invocation and MEP
In-Only
Robust-In-Only
In-Out
In-Optional-Out
Service invocation refers to an instance of an end-to-end interaction between a service consumer and a service provider.
Four patterns are supported by JBI:
In-Only: consumer issues a request to provider with no error (fault) path provided.
Robust-In-Only: consumer issues a request to provider. Provider may respond with a fault if it fails to process request.
In-Out: consumer issues a request to provider, with expectation of response. Provider may respond with a fault if it fails to process request.
In-Optional-Out: consumer issues a request to provider, which may result in a response. Consumer and provider both have the option of generating a fault in response to a message received during the interaction.

15. JBI 1.0: Normalized Message Router
Consumers and providers
Normalized Message
Delivery Channel
Run-time Endpoint Activation
Service invocation and MEPs
Message Exchange
Endpoints
Endpoints
External
Internal
Addressing
Implicit
Explicit
Dynamic
JBI uses the same concept of endpoints as defined in WSDL 2.0.
Endpoints refers to a particular address, accessible by a particular protocol, used to access a particular service.
Endpoints have two distinct types:
External endpoints are endpoints outside the JBI environment. They are endpoints exposed by binding component acting as service consumers to expose an internal endpoint for the use of external service consumers
Internal endpoints are exposed by service providers inside the JBI environment. They are accessed using the NMR APIs.
Binding components serve to map between internal and external endpoints. For example, an internal endpoint exposed outside the JBI environment by a binding component is mapped by the BC to an external provider endpoint for the use of external consumers.
In JBI, endpoints are referred to (or addressed) in three distinct ways:
Implicitly: the NMR selects the endpoint based on the service type required
Explicitly: a consumer chooses the endpoint based on its own logic and configuration
Dynamically: an endpoint reference (EPR) is used within a message exchange to provide a “ call-back” address that the service provider should use to send further message exchanges. EPRs are xml fragment created and resolved by JBI components.

16. JBI 1.0: Lessons learned Pros Cons Normalized exchanges
Normalized Message Router
Cons
Classloader architecture
JBI packaging
Writing components is complex
Role of the component ?

17. ServiceMix 4.0: Goal Enterprise OSGi Container Lightweight
ESB and SOA container
Ease of use

18. ServiceMix 4.0: Standard based
Short Term
JBI 1.0
JAX-WS, WS-*
On the long term
JBI 2.0 support
SCA
IONA Support
Involved in JBI 2.0 EG, OSGi Alliance (leading OSGi Enterprise Edition EG), SCA

19. ServiceMix 4.0: Simplified API
No more components
Deployment / Classloader is delegated to OSGi
Bundles as the packaging and extension mechanism
Leverages OSGi architecture
Leverage spring-osgi (optionally)
Endpoints as first-class citizens
Endpoint are activated when registered in the OSGi registry
Channel is now on the Endpoint
Endpoints use push delivery rather than pulling the channel

20. Building blocks Avoid reinventing the wheel
Framework: OSGi (Apache Felix)
SOAP support: Apache CXF
JMS broker: Apache ActiveMQ
Routing Engine: Apache Camel

21. Apache Camel Java DSL for EIP from(“http://localhost:8080/requests/”).
tryBlock().
to(“activemq:queue:requests”).
 setOutBody(constant(“<ack/>”)).
handle(Throwable.class).
setFaultBody(constant(“<nack/>”));
from((“activemq:queue:requests?transacted=true”).
process(requestTransformer).
to(“
filter(xpath(“//nack”)).
process(nackTransformer).
to(“jdbc:store”);
from(“
to(“activemq:queue:responses”).
setOutBody(constant(“<ack/>”)).
from(“activemq:queue:responses?transacted=true”).
process(responseTransformer).
from(“
to(“jdbc:load”);

22. Apache Camel Java DSL for EIP from(“http://localhost:8080/requests/”).
tryBlock().
to(“activemq:queue:requests”).
 setOutBody(constant(“<ack/>”)).
handle(Throwable.class).
setFaultBody(constant(“<nack/>”));
from((“activemq:queue:requests?transacted=true”).
process(requestTransformer).
to(“
filter(xpath(“//nack”)).
process(nackTransformer).
to(“jdbc:store”);
from(“
to(“activemq:queue:responses”).
setOutBody(constant(“<ack/>”)).
from(“activemq:queue:responses?transacted=true”).
process(responseTransformer).
from(“
to(“jdbc:load”);
from(“
tryBlock().
to(“activemq:queue:requests”).
setOutBody(constant(“<ack/>”)).
handle(Throwable.class).
setFaultBody(constant(“<nack/>”)); 

23. Apache Camel Java DSL for EIP  from(request). tryBlock().
to(requestStorage).
setOutBody(constant(ack)).
handle(Throwable.class).
setFaultBody(constant(nack));
from(requestStorage).
process(requestTransformer).
to(requestProvider).
filter(isNack).
process(nackTransformer).
to(dbStorer);
from(responseConsumer).
to(responseStorage).
from(responseStorage).
process(responseTransformer).
from(response).
to(dbLoader);
from(request).
tryBlock().
to(requestStorage).
setOutBody(constant(ack)).
handle(Throwable.class).
setFaultBody(constant(nack)); 

24. Apache Camel Java DSL for EIP <route>
from(“
tryBlock().
to(“activemq:queue:requests”).
 setOutBody(constant(“<ack/>”)).
handle(Throwable.class).
setFaultBody(constant(“<nack/>”));
from((“activemq:queue:requests?transacted=true”).
process(requestTransformer).
to(“
filter(xpath(“//nack”)).
process(nackTransformer).
to(“jdbc:store”);
from(“
to(“activemq:queue:responses”).
setOutBody(constant(“<ack/>”)).
from(“activemq:queue:responses?transacted=true”).
process(responseTransformer).
from(“
to(“jdbc:load”);
<route>
<from uri=“ />
<try>
<to uri=“activemq:queue:requests” />
<process ref=“setAck” />
<catch>
<exception>java.lang.Throwable</exception>
<process ref=“setNack” />
</catch>
</try>
</route> 

25. Tooling
Cimero

26. Tooling Cimero Contributed to Eclipse STP by Bull
Currently under IP process at Eclipse
Extend to provide support for Camel
Roundtrip with Camel

27. Roadmap
ServiceMix being release (first official release after graduation)
ServiceMix 3.2 following (beginning of October)
ServiceMix 4.0-m1 in october
Milestones every month or so until 4.0 final (Q1 2008)
Contributors are welcome!

28. Questions ? Guillaume Nodet Blog: http://gnodet.blogspot.com