Hi Mickael,
Thank you for your message, this is
an interesting point and worth to be discussed.
I agree that SOA and BPM are
different things, and I think this is something most people
would agree with. There are 2 points in your email:
1. The name of the Eclipse SOA TLP (it
indicates SOA but it also contains BPM stuff)
2. Whether or not SOA and BPM should be
integrated in the same Eclipse project.
I’ll start with the name: yes, maybe
SOA is a bit confusing because it can be seen as limiting.
There are several reasons why we got to this name, but I
agree there is a case to perhaps change it to something that
symbolises more than just SOA.
On your second point though, I am of
the opinion that SOA and BPM should be integrated, and in
fact this is perceived as one of the main challenges today
in the field. Companies need to have a strong SOA base and a
strong BPM methodology and these two MUST be integrated. You
can obviously have one without the other but this brings a
lot of limitations. This is in fact perceived in the
commercial offers of many large players, where they try to
integrate the two paradigms as well as possible. Sure, for
small companies using (for now) one of the 2 (either some
SOA runtime or some BPM engine), this is not a problem, they
can still ‘choose’ because in many SOA or BPM offerings
there is some degree of hybridization that brings ‘enough’
capabilities for limited environments. However, large
enterprises that have important investments in both SOA and
BPM (or in one of them but with plans to tackle the other as
well), it is important that the two be very well integrated.
So yes, they should be in the same
top-level project because this facilitates integration (both
conceptual and practical). Again, on the question of name of
the TLP, this is something that the PMC should probably
re-consider at some point.
Cheers,
Adrian.
Hi all,
I have started reading the soa-pmc mailing-list a very few
weeks ago, but I've followed what happens in the BPM and SOA
landscape at Eclipse for the last few years.
I have some experience on both SOA and BPM, and I'd like to
start a debate here that I hope will lead to conclusions that
will make easier for people to consume BPM and/or SOA.
In my opinion, this is a confusing idea to have one top-level
SOA project that provides pure-BPM things. BPM and SOA are
different things, either in term of goal, expectations, and
technologies. People can use BPM without SOA, people can use
SOA without BPM.
Of course there are some integrations that are possible, but
the coupling is not strong enough to merge SOA and BPM at
Eclipse. Having BPM components in the SOA projects make people
believe that BPM is part of a SOA. That's wrong.
For BPM, SOA simply means that your BPM engine and tools will
be able to consume services. Your BPM can also read data in
Databases, then you have the same coupling between BPM and
SOA@Eclipse than between BPM and DataTools. DataTools does not
contain BPM stuff.
BPM is wide, SOA is even wider, but there is no strong
coupling between both. Integrations are possible, but not
necessary. Maybe it would be more relevant to have a BPM
top-level project at Eclipse independently of SOA, and some
projects that would provide some interactions, on top of both
BPM and SOA.
That are my 2 cents.