Yes, this has been worked on between the two teams for a while. It'll be in the MR2 release in the next couple of weeks. I think most/all of the code is in the trunk now. If you've any questions or comments, feel free to post here.
If you are willing to checkout directly from SVN you will find jBPM+ESB integration already in place. However, give us just another couple of weeks and we'll have a great demo/example or two (quickstarts) plus some preliminary documentation.
jBPM will deploy as a "service" in the ESB to allow for advanced orchestration and human task management/workflow.
Would you mind describing your potential use case scenarios? What is your vision of how these two technologies come together to solve a real-world business problem?
At the moment, I have no requirements, but I'm evaluating technologies.
Honestly, I'm finding it difficult to determine exactly what an ESB gives me. I mean, I can throw together a web service using a variety of techniques really easily now, so why use an ESB when it seems that an ESB effectively locks me into an API compared to developing discrete web services?
However, I still need to tie all the web services together, and I see jBPM as being a tool to do that. Having jBPM as a JBoss ESB service would be great. Will it also be exposed as a web service in its own right, or would I need to develop a gateway to access the jBPM ESB service from another web service?
(Incidently, the other important feature would be integration with registry services. Does JBoss ESB help me get WSDL into a JNDI registry?)
Apologies if these seem like stupid questions. I guess I still see SOA as somewhat requiring web services, and an ESB as an implementation of SOA which doesn't necessarily require web services. I'm hoping for an ESB which makes it easy to do things with web services which are a pain or absolutely common across all web services.
I would really love to see a list of great things that JBoss ESB did for me, like:
1) Contains a workflow engine
2) Allows dual-mode web services and ESB services.
3) Exposes web service capable ESB services in UDDI
4) Improves performance between ESB services vs. web services by x%
5) Handles transactions across services
It is difficult to nail down the definition of an ESB in today's market. It is a bit like 1996/1997 when the industry began to adopt the concept of an application server.
One of the primary benefits of an ESB is the intermediation/abstraction it provides so that a consumer/client doesn't have any knowledge of a producer/service. Use of web services alone tends to lead to a more inflexible point to point architecture. For instance, your COBOL application simply drops a file into a FTP server, it is unaware of the ESB. Your Powerbuilder application simply writes a record to a database.
JBoss ESB is middleware for transformations, declarative/intelligent routing, orchestration, service registry, transport mediation, business rules, workflow and much more. More importantly it is based on the notion of federation where multiple nodes make up a network of services and no two nodes have to be alike.
Let me try to respond to your specific questions & points:
- Why use an ESB when it seems that an ESB effectively locks me into an API compared to developing discrete web services?
We recommend that you continue to use Web Services, EJBs, Spring POJOs, etc. as the basis for your business logic. The API used in the ESB is to introduce intermediation capabilities such as transformation, routing and orchestration.
- Having jBPM as a JBoss ESB service would be great. Will it also be exposed as a web service in its own right, or would I need to develop a gateway to access the jBPM ESB service from another web service?
The goal is to allow the "composite" service that was wired together via jBPM to be exposed via the ESB across a variety of transports (e.g. JMS, WS, FTP, File, etc).
It should be noted that if all you wish to do is wire together web services and expose the composite as a web service then you might look into BPEL also in SVN head at this moment.
- Does JBoss ESB help me get WSDL into a JNDI registry?
No, in the SOA world it is all about the UDDI registry. You could always manually load your WSDL into the standard JBoss JNDI tree however I would not recommend that. WSDL and Web Services are a technology that allows for highly interoperable invocations/communications between networked components.
For example, your remote VB client can't speak to the JNDI to try to retrieve the WSDL to generate its proxy, therefore, having it in JNDI is a barrier to usage.
- Contains a workflow engine? Presently in SVN and targeted at 4.2 M2 (2nd milestone release)
- Allows dual-mode web services and ESB services? Presently in SVN and targeted at 4.2 M2 (2nd milestone release)
- Exposes web service capable ESB services in UDDI? Actually all services WS or otherwise are registered and exposed via UDDI automatically
- Improves performance between ESB services vs. web services by x% ? This benchmark hasn't yet occurred, perhaps you'll be willing to work with us on that item.
- Handles transactions across services? 2PC style ACID transactions are targeted at ESB 5.0. However, you can certainly implement long running, orchestrated, "business transactions" via jBPM.
Thank you so much for such a great response!!