Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [soa-pmc] Separate BPM and SOA.

Hi all,

Very interesting discussion, this is just my two cents contribution to that discussion.

In general i definitely agree, with adrian vision. Just let me to explain the vision  we ( INRIA ad Engineering ) have
when we started the STP intermediate model.

In particular we see SOA and BPM integrated in bidirectinal way so:

1) It's possible to have SOA services ( in particular OSGi service ) to be called ( integrated ) within BPM engines. This is
the case you're speaking about.

2) But we could also expose BPM processes as services, so in our view a process *is a services itself*. A process
is a service that is able to orchestrate other services, that's quite simple but powerful, and in my opinion it fit well
with both SOA and BPM concepts.

Obviuosly i just talk for the pojects for which i'm involved ( STP Intermediate Model now Mangrove and eBPM)
but i think  that projects that are now part of SOA top level landscape are sharing the same vision where
services and process, could live alone, but are also well integrated if you need.

So i definitely agree with Adrian, if it's necessary we could discuss about naming but i would still prefer to have
BPM and SOA components together in the same SOA TLP projects

Cheers
Andrea

Il 05/07/2011 13:14, Mos, Adrian ha scritto:

Hi again Mickael,

 

So we all agree that having SOA/BPM integration is a powerful thing. And this is one of the goals we are trying to achieve with Eclipse SOA TLP, on a tooling level as well as with runtime ramifications. The partners involved in the TLP are interesting in this combined offer, and this has been the case for a long time I think (even in Eclipse STP we had BPMN and SCA for instance, as well as other projects). From an integration perspective, it makes a lot of sense to work in your BPM space, or your SOA space and have these two integrated easily.

 

You’re saying this is just a particular case of integration between two methodologies. I think it’s more than that, it’s about integration between the two dominant methodologies that have been for long seen as orthogonal. The combined offering of these in the portfolio of major players is not just a marketing stint, it’s also driven by customer needs. Aside from commercial offers from big players which I think make this connectivity clear, we have seen this need over and over in Eclipse, and long-time project partners such as Engineering  have long been offering solutions which required such integration. You can also see this in the Stardust project proposal, and the list could go on.

 

Don’t forget also that SOA is much more than technology (and much more than an ESB). It’s about thinking about reusable IT assets in a way that fits more with the enterprise needs for change. So integrating BPM and SOA goes much further than providing some connectivity to BPM. I could go on about this, but what’s important I guess is that projects that make sense together, be together, and that a top-level project provide a space for creating cool, vibrant solutions. I’m happy that this TLP seems to become more active, and this discussion is proof J

 

Thanks for your points!

Adrian.

 

From: soa-pmc-bounces@xxxxxxxxxxx [mailto:soa-pmc-bounces@xxxxxxxxxxx] On Behalf Of Mickael Istria
Sent: mardi 5 juillet 2011 12:25
To: soa-pmc@xxxxxxxxxxx
Subject: Re: [soa-pmc] Separate BPM and SOA.

 

On 05/07/2011 11:17, Mos, Adrian wrote:

Hi Mickael,

Hi Adrian,


 

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:

 

The name of the Eclipse SOA TLP (it indicates SOA but it also contains BPM stuff)

Whether or not SOA and BPM should be integrated in the same Eclipse project.

 

I agree that we can separate those 2 points. Then I agree on point 1.

Now about the 2nd point:

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.

should or MUST ;)


You can obviously have one without the other but this brings a lot of limitations.

I don't see any limitation of using BPM without SOA. Of course, having a well-built SOA platform will allow you to consume more easily some other services of your Business Processes, but not having SOA is not a limitation when developping processes. Having SOA is a benefit for BPM, like having access to database or mail server or ability to connect to your ERP. I think everything is just about providing connectivity in your processes. SOA is a good way to provide good connectivity, but the coupling is very low for me.


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.

Of course, commercial offers prefer selling a BPM solution + a SOA solution than selling only a BPM solution ;) I am still not sure about the necessity for _need_ for such a strong coupling between BPM and SOA.


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.

Ok, about providing integrations. I understand than having good BPM with good SOA is a very powerful thing, like having your BPM interacting with your ERP. But there is no ERP related-stuff in the SOA TLP, whereas there is SOA... The coupling is as strong between BPM and SOA than between BPM and ERP, than between ERP and SOA.
My concern is first about the naming (point 1), but also about the coupling (point 2). IMHO, the links between BPM and SOA are weak, both are independant, but there are possible integrations. There are always possible integrations between methodologies and technologies, this case is not a specific one.


 So yes, they should be in the same top-level project because this facilitates integration (both conceptual and practical).

I'm not convinced ;) But I am not trying to make a revolution, the idea is more to start this debate and think about what people do with BPM and SOA, and how Eclipse can provide the best experience for them in these fields. Simplicity often provides the best experience.


Again, on the question of name of the TLP, this is something that the PMC should probably re-consider at some point.

+1


Regards,

--

Mickael Istria
R&D Engineer, Eclipse Plug-in RCP Developer

PetalsLink - Open Source SOA

My blog - My Tweets

_______________________________________________ soa-pmc mailing list soa-pmc@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/soa-pmc


--

Andrea Zoppello
Spagic Architect

Corso Stati Uniti, 23/C - 35127 Padova - Italy
Tel. +39-049.8283411
Mob. +39-345.4668537
andrea.zoppello@xxxxxx
www.spagoworld.org
Engineering Group
IT Solution Architect
Research & Innovation Division
Architectures & Consulting
www.eng.it

  Respect the environment. Please don't print this e-mail unless you really need to.

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.


Back to the top