In a series of posts which give a high-level overview of the features the GlassFish stack has to offer this one will kick-off with OpenESB.

OpenESB is a runtime available for the GlassFish application server.

JBI

OpenESB is a Java Business Integration (JBI, JSR-208) based ESB implementation. JBI consists of is a fully pluggable architecture in which different types of components can be connected.
These components communicate message-driven, through the WSDL’s of these components.

Implementations of these components are Service Engines (SE) and Binding Components (BC). Communication between these components takes place through the Normalized Messaging Router.
All of the above is defined by the JBI standard.

MTOM

OpenESB has a number of extensions on this standard, but still remains compatible, one of which optimizes the message-passing internally.
All messages between components in the ESB can communicate with each other using, for instance, SOAP-HTTP/JMS or MTOM. SOAP-HTTP processing can be quite heavy for the application server, especially when binary files have to be sent across the line. Also security is an issue, when sending attachments using SOAP-with-Attachments or WS-Attachments, as WS-security is not available in this scenario.

This is where MTOM can aid.
MTOM is a SOAP extension (SOAP Message Transmission Optimization Mechanism) which optimizes sending binary parts of a SOAP message.
When SwA (Soap with Attachments) is used in conjunction with WS-Security, the service should encrypt the attachments itself as WS-Security does not support this. Also base64-encoding the binary files must be done so that they can be sent over the line.

MTOM is a SOAP extension which allows binary files to be sent without base64-encoding them. A SOAP message will be MIME Multipart/Related, it has a body part and additional part which contain the binary attachments. When using MTOM WS-Security is available when binary content is sent.

Service Engines and Binding Components

Service Engines contains business logic and transformation logic and can communicatie with other SEs.
Binding Components functions as a bridge between components in- and outside the JBI bus. For instance letting services in the JBI bus communicatie with a database outside the JBI bus.

From the OpenESB community several SEs and BCs are being made available and developed on. For instance BCs which communicate with SMTP- and FTP-servers and databases.

A much used Service Engine is the Java EE Service Engine which takes care of enabling Java EE webservices in the JBI bus.

The Java EE SE takes care of enabling Java EE webservices to the JBI bus and for enabling components within the JBI bus to communicate with these Java EE webservices.
Without the Java EE SE, these services are only available through an over-the-wire protocol such as SOAP-HTTP or JMS. They lack the simplification of accessing them which the Java EE SE provides.

To enable a Java EE component (EAR,WAR,JAR) as a JBI component, a service assembly must be made to which this Java EE component has been added. Other service units can be added to this service assembly as well.
A jbi.xml defines the component configuration which is read by the Java EE SE.
When the service-assembly is deployed then the appserver will communicate with the Java EE SE which in turn enables the Java EE component to the JBI bus.
In other available ESB products like Apache ServiceMix or Oracle ESB more work has to be done to enable an EJB in the ESB.

In Oracle ESB for instance, WSIF bindings have to be defined to enable the EJB in the ESB. If a WSIF binding is not supplied then the EJB is only available over SOAP-HTTP.

The last item for this post is that Transactionmanagement works throughout the JBI bus, by this I mean that, whenever a transaction within a composite application is started, it is used by all services which need to participate in that transaction.