RE: Generic BPM API and ESB Integration

[Jeffrey Puro <jp...@sterlingtesting.com>]

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:james.strachan@gmail.com] 
Sent: Saturday, April 29, 2006 2:33 AM
To: servicemix-users@geronimo.apache.org
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 <ja...@gmail.com> 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 <jp...@sterlingtesting.com> 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/