Comments on: BPM and ESB http://www.brsilver.com/wordpress/2006/05/19/bpm-and-esb/ Bruce Silver's blog on business process management Wed, 07 Jan 2009 18:33:34 +0000 http://wordpress.org/?v=2.7 hourly 1 By: tomdebevoise http://www.brsilver.com/wordpress/2006/05/19/bpm-and-esb/comment-page-1/#comment-77 tomdebevoise Mon, 22 May 2006 14:29:12 +0000 http://www.brsilver.com/wordpress/2006/05/19/bpm-and-esb/#comment-77 I think the easy answer is that the choice of the ESB versus the BPM engine is in the performance requirements. Intalio includes the Iona ESB in their open-source BPM stack. The ESB is used in very high volume transaction situations. I think the easy answer is that the choice of the ESB versus the BPM engine is in the performance requirements. Intalio includes the Iona ESB in their open-source BPM stack. The ESB is used in very high volume transaction situations.

]]> By: ric.hayman http://www.brsilver.com/wordpress/2006/05/19/bpm-and-esb/comment-page-1/#comment-73 ric.hayman Sun, 21 May 2006 14:01:44 +0000 http://www.brsilver.com/wordpress/2006/05/19/bpm-and-esb/#comment-73 I WAS rather hoping to get a more definitive answer from you, Bruce. Perhaps I can direct you to the ESB/BPM software I am most familiar with - Sonic (www.sonicsoftware.com). They (through their employment of David Chappell) claim to have invented the term "Enterprise Service Bus", and have several white papers on the topic. If I had to give the shorthand version, I think it would be similar to the IBM story you quote. We've been using the JMS component for a while, and are just starting to look at orchestration via JCA, but we're some way from having a handle on the BPM stuff. I WAS rather hoping to get a more definitive answer from you, Bruce. Perhaps I can direct you to the ESB/BPM software I am most familiar with - Sonic (www.sonicsoftware.com). They (through their employment of David Chappell) claim to have invented the term “Enterprise Service Bus”, and have several white papers on the topic. If I had to give the shorthand version, I think it would be similar to the IBM story you quote. We’ve been using the JMS component for a while, and are just starting to look at orchestration via JCA, but we’re some way from having a handle on the BPM stuff.

]]> By: bruce http://www.brsilver.com/wordpress/2006/05/19/bpm-and-esb/comment-page-1/#comment-69 bruce Fri, 19 May 2006 22:28:26 +0000 http://www.brsilver.com/wordpress/2006/05/19/bpm-and-esb/#comment-69 It's kind of lame to be commenting on my own post, but I went back to look at my <a href="http://www.bpminstitute.org/bpmsreport.html">2006 BPMS Report</a> on IBM WebSphere BPMS, and there at least the relationship of ESB to the rest of the BPMS is clearcut and non-overlapping: <blockquote>In WebSphere’s service orchestration architecture, integration actions are modeled in WebSphere Integration Developer (WID) as invocations of service components. In SOA, the connectivity fabric linking service requestors and providers is called an enterprise service bus (ESB). IBM’s ESB architecture relies on the Service Integration Bus built into WebSphere Application Server v6, which may be used in conjunction with a WebSphere MQ message bus backbone spanning the enterprise. This Service Integration Bus, sometimes referred to as WebSphere Messaging Resources, provides the infrastructure for WebSphere ESB and is based on the Java Message Service (JMS) standard. A service component can send XML and SOAP messages to JMS queues or URLs over the bus, or invoke operations on external systems by sending business objects to J2EE Connector Architecture (JCA) v1.5 integration adapters. It also allows process components to receive invocations and events from J2EE applications via SOAP or JMS. The ESB is also the medium through which the Process Server communicates to human process participants, through web clients, WebSphere Portal, or WebSphere Everyplace Access. In addition to transport, WebSphere ESB provides mediation services, with capabilities of filtering, logging, and transforming messages, and performing database lookups. These message flows are modeled in WID as mediation components using WebSphere-supplied primitives.</blockquote> Thus in answer to the questions posed in my original post, in IBM's case at least, some functions of the ESB are invisible and built-in, such as communications with integration adapters and human tasks, while others must be modeled explicitly in the BPMS design tool (WID), such as message tansformation, filtering, and other so-called "mediation services." It’s kind of lame to be commenting on my own post, but I went back to look at my 2006 BPMS Report on IBM WebSphere BPMS, and there at least the relationship of ESB to the rest of the BPMS is clearcut and non-overlapping:

In WebSphere’s service orchestration architecture, integration actions are modeled in WebSphere Integration Developer (WID) as invocations of service components. In SOA, the connectivity fabric linking service requestors and providers is called an enterprise service bus (ESB).

IBM’s ESB architecture relies on the Service Integration Bus built into WebSphere Application Server v6, which may be used in conjunction with a WebSphere MQ message bus backbone spanning the enterprise. This Service Integration Bus, sometimes referred to as WebSphere Messaging Resources, provides the infrastructure for WebSphere ESB and is based on the Java Message Service (JMS) standard. A service component can send XML and SOAP messages to JMS queues or URLs over the bus, or invoke operations on external systems by sending business objects to J2EE Connector Architecture (JCA) v1.5 integration adapters. It also allows process components to receive invocations and events from J2EE applications via SOAP or JMS. The ESB is also the medium through which the Process Server communicates to human process participants, through web clients, WebSphere Portal, or WebSphere Everyplace Access.

In addition to transport, WebSphere ESB provides mediation services, with capabilities of filtering, logging, and transforming messages, and performing database lookups. These message flows are modeled in WID as mediation components using WebSphere-supplied primitives.

Thus in answer to the questions posed in my original post, in IBM’s case at least, some functions of the ESB are invisible and built-in, such as communications with integration adapters and human tasks, while others must be modeled explicitly in the BPMS design tool (WID), such as message tansformation, filtering, and other so-called “mediation services.”

]]>