This JSR seems to be aimed at describing business processes on a class level (annotations etc.) and it doesn't seem to address starting up engines and manipulating them in a declarative fashion. We need something that abstracts away the particular BPM implementation similar to the way that cargo hides the particular J2EE server you are using. Perhaps this is what this JSR intends on eventually doing, but until it gets released there are still numerous engines out there with their own specific means of configuration and communication methods. There is also of course the issue of JBI :). BPM's should have some notion of this or there should be components to proxy the BPM so that ESB's can properly talk to them.
-Jeff -----Original Message----- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: Saturday, April 29, 2006 2:33 AM To: [email protected] Subject: Re: Generic BPM API and ESB Integration Thanks for that, I'd forgotten all about JSR 207; I wonder when it will release something; 3 years ago it formed the expert group and its not changed status since :( On 4/29/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote: > I agree, provided that the abstraction isn't too limiting. > > That said, there seem to be a couple of standards heading in that > direction already e.g.: > > wfxml: http://www.wfmc.org/index.html > jsr 207: http://www.jcp.org/en/jsr/detail?id=207 > > cheers, > j. > > On 4/28/06, Jeffrey Puro <[EMAIL PROTECTED]> wrote: > > This isn't particularly ServiceMix specific, but eventually I would like > > to integrate this within the ESB. It appears that with the many BPM > > engines out there, there is no standard API for accessing each of these. > > I've heard that there has been talk of creating some kind of project > > like this, but not sure if anything has been started yet. The project > > should have the following basic goals: > > > > > > > > 1. Develop a generic API for accessing any type of BPM engine. > > The core functions shared across BPM engines should be supported. This > > will include process creation, signaling, resuming, etc... We can use > > some sort of Factory pattern to develop this in an extensible fashion. > > > > 2. Develop a standard declarative configuration model for starting > > up BPM engines and interacting with each. One possibility would be to > > use Spring as the IoC container for wiring the different container > > specific beans and configurations together. > > > > 3. Basic configurations should be as decoupled from the actual BPM > > engine as possible. This means that the base configuration is always > > used, like some kind of default while any extra configurations can be > > added on to get specific BPM features working. The purpose of this is > > to allow for minimum configuration for getting things started. > > > > 4. There should be integrations with the various ESB's out on the > > market. The benefits of having a BPM and ESB integrate seamlessly are > > enormous. These two technologies will probably be a core of companies' > > software stacks, so I see this as being extremely important. Some > > initial supported ESB's may be things like apache ServiceMix and Mule > > (yes I said it, our competitor :-) ). > > > > > > > > As I'm sure there is a lot of talk on this topic already, I'd like to > > hear people's feedback on this. > > > > > > > > Regards, > > > > > > > > Jeff Puro > > > > Senior Developer > > > > Sterling Testing Systems, Inc. > > > > This email (and any attachments) is intended only for the use of the individual or entity named above and may contain information that is privileged and confidential. If you are not the intended recipient, or have unauthorized access, you are hereby notified that copying, disseminating, distributing or taking any action in reliance on this email is strictly prohibited. > > > > Opinions, conclusions and other information in this message that do not relate to the official business of our company shall be understood as neither given nor endorsed by it. > > > > > > > -- James ------- http://radio.weblogs.com/0112098/
