 |
|---|
ESB (Enterprise Service Bus) and SOA
An IBM information page defines the ESB and the relation to SOA as below:
"An enterprise service bus (ESB) is a pattern of middleware that unifies and connects services, applications and resources within a business. Put another way, it is the framework within which the capabilities of a business' applications are made available for reuse by other applications throughout the organization and beyond. The ESB is not a new software product — it's a new way of looking at how to integrate applications, coordinate resources and manipulate information. Unlike many previous approaches for connecting distributed applications, for example RPC or distributed objects, the ESB pattern enables the connection of software running in parallel on different platforms, written in different programming languages and using different programming models."
"Examples of the enterprise service bus patterns exist today, built using existing integration tools available in the IBM Business Integrationportfolio of products. For a business, an ESB can manage connectivity needs by providing standards based application integration with support for Web services, message based transport and mediation (transformation and routing) oriented toward a service based infrastructure (often referred to as a service oriented architecture)."
SOA principles are not necessarily tied with ESB but the ESB assumes SOA. The IBM page states: "A service oriented architecture enables flexible connectivity of applications or resources by representing every application or resourceas a service with a standardized interface. This enables them to exchange structured information about business events, including messages, documents, and 'business objects', quickly and flexibly. This flexibility enables new and existing applications to be easily and quickly combined to address changing business needs, and the ability to easily combine and choreograph applications allows IT services to more readily reflect business processes."
In short, in the enterprise integration,
- every "application" or "resource" is presented as Services,
- uses a standard,
- ESB connects Services together (i.e. one can use Services regardless of platforms and either synchronously or asynchronously),
- Messages, Documents and Data will travel on the bus,
- the system can choreograph Services.
The difference between ESB/SOA and other technologies, such as RPC, CORBA, EIA, etc., is that the services are considered as a part of your process in SOA/ESB. Your application is modeled with those processes which uses the Services.. They are used by "Activitation" rather than Invocation (implies the functions are external and expects immediate response) or Messaging (implies sending messages and common objects and that asynchronous responses trigger appropriate reactions) which is from one system to another.
IBM ESB
The IBM ESB is based on WSDL. The services do not have to be external Web Services but the service interface is described as WSDL.
The IBM's SOA/ESB is WebSphere based. The "users" of the ESB is logically thought of:
- Portal
- SOAP Service Request (e.g. J2EE, .Net)
- B2B Interactions
- Service Flow
- Data
- Existing Applications
- New Service logic
It is interesting to note that the Workflow is a part of ESB, perhaps a Service.
It also identifies the Services as in the figure "The IBM Business Integration Reference Architecture":
- Business Performance Management Services, consisting of:
- Interaction Services (direct ESB connection)
- Process Servcies (direct ESB connection)
- Information Services (direct ESB connection)
- Partner Services
- Business Application Services
- Application and Data Access Services, consisting of:
- Business Application and Data Services (connects with ESB via ADA)
- Infrastructure Services
How the first difinition of the users of ESB match with the Service definitions? Perhaps the Service Flow falls under Process Services?
Sun ESB
The Sun Microsystems also defines Open ESB 2.0, which is based on JBI.
This is claimed to be a standard based and it sounds as though it should be platform independent. In a sense it is, since it is a result of Java Community Process (JCP), but it is based on JBI (Java Business Interface) and, although it is an open "standard" (of Java), the JBI part can be implemented only by a Java SOA-ESB system. The new JBI (2.0) is siad to aim to make the JBI to coexisit or work with SCA. So, JBI is not a replacement for SCA. JBI is rather a communication-handling part of an SOA.
JBI works as a network based bus (networked ESB). Each application implements a network-based ESB using JBI, then the services on multiple sysems can have access to each other via networked ESB (JBI). The communications on JBI is dealt with a bus called Normalized Message Router (NMR) which accepts and delivers so-called standardized messages, that are descibed as abstract WSDL.
The following diagram is taken from the architecture figure on the Open ESB site:
As the figure above indicates, JBI/OpenESB leverages Application Servers. It consists of, Composite Application (called Enterprise Mashup), Composite Application Editior, JBI Bus, Management/Monitoring/Administration compoments, and Services, represented by Service Engines (SEs) and Binding Components (BCs).
The Open ESB Componentsnotes that the difference between BC and SE is that a BC is designed to accept and return messages based on WSDLs, whereas an SE can accept formats other than WSDL and process them to make a message defined with the service's WSDL (or do it in reverse). For example, the JDBC BC receives a WSDL form of request from NMR and converts it to an SQL request and execute it with the external service who accepts the SQL request. Whereas, the SQL SE allows the user to create an SQL file as part of the message that receives. The service request is defined by an WSDL and contains an SQL file. The engine extracts the SQL and execute it and returns the results to NMR in reverse. Interestingly, the JDBC BC is also cited as a service provider as well as a service consumer, which means it can be connected to both external service provider and consumer.
The Open ESB 2.0 release notes lists SEs and BCc as follows. It, however, is supplied with more SEs and BCs according to the Open ESB Project.
Table 1: Service Engines Provided With Open ESB 2.0 Beta 2
|| Component || Name || Description ||
| BPEL Service Engine | sun-bpel-engine | Provides services for executing Web Services Business Process Execution Language 2.0 (WS-BPEL, or BPEL) compliant business processes. | |
| Java EE Service Engine | JavaEEServiceEngine | Connects Java EE web services to JBI components. | |
| XSLT Service Engine | sun-xslt-engine | Transforms XML documents using XSL style sheets. | |
| Intelligent Event Processor Service Engine | sun-iep-engine | Provides real-time business event collection and processing such as aggregation, filtering, and correlation, and performs event notification and event triggers. | |
| SQL Service Engine | sun-sql-engine | Provides SQL execution services to other JBI components. |
Table 2: Binding Components Provided With Open ESB 2.0 Beta 2
| Component | Name | Description |
|---|---|---|
| File Binding Component | sun-file-binding | Provides a transport service to a file system and offers a comprehensive solution to interact with the file system from the JBI environment. |
| FTP Binding Component | sun-ftp-binding | Provides inbound and outbound JBI messaging using the FTP protocol as specified in RFC 959. |
| HTTP Binding Component | sun-http-binding | Provides external connectivity for SOAP over HTTP in a JBI 1.0 compliant environment. |
| JDBC Binding Component | sun-jdbc-binding | Provides a comprehensive solution for configuring and connecting to databases that support the JDBC 3.0 API specification. |
| JMS Binding Component | sun-jms-binding | Provides Java Messaging Service (JMS) transport for inbound and outbound messages. |
| SMTP Binding Component | sun-smtp-binding | Provides a comprehensive solution for configuring and connecting to SMTP servers and clients within a JBI environment. |
| WebSphere MQ Binding Component | sun-webspheremq-binding | Provides a comprehensive solution for configuring and connecting to WebSphere MQ servers within a JBI environment. |
A UK Sun's Key Parts of the JBI Runtime shows the relationship of SEs and BCs to the Normalized Message Router (NMR) as follows:
Open ESB describes some of the BCs act as Service Providers as well as Service Consumers. This is a bit confusing, since a BC may use another BC as a service, but the latter can be also regarded as a service consumer by the external service to which it is connected.
The model is called loose-coupling by some analyst. The connection between the origin service consumer and the final service provider is not direct, i.e. it is via the service bus and it also requires two Binding Components in between. This also indicates a bi-directional nature of BCs (i.e. both request and response go though it, and in some BCs the request can go both directions).
The SEs appear to be implementing only internal services but this may be a missrepresentation since it seems that they allow user interactions. (TBD)
Worklist Manager SE (WLMSE)
WLM SE is of our interest since it is said to be a workflow engine and specialy desinged for ESB to handle human interaction.
WLM SE web page states:
A business process or workflow is a coordinated chain of activities intended to produce a business result. Total automation of business processes is practically unachievable without considering human interaction. In some processes, human workflow is a major emphasis. In others, human participation is only required on an exception basis.
Worklist Manager SE (WLMSE) is a JBI based engine, which provides task management and human intervention in a business process.Worklist Manager SE uses a simple task definition language to define the tasks related functionality like task assignment to user/groups, escalation, timeout etc.
The reasons why the OpenESB needs it are stated as:
- BPEL does not provide human interaction.
- Extending BPEL with new custom extension is cumbersome and makes BPEL complex, non portable.
- Clear separation of human interaction/task related functionality into a separate component.
- A simple language to define tasks functionality.
This uses concepts of Task and Assigment to manage user's Task List. Therefore, it is a Tasks management engine, not a general workflow engine. The difference is that this presents a work list to the user, not a list of workflows.
JBossESB
JBossESB is developed by JBoss (now it is owned by Red Hat).
An overview simplifies the structure and the technology used as:
More complex representation is shown in another document:
