Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [soa-pmc] Re: eBPM Proposal


the only reservation I have with the proposal is that I feel that the tentative time line is a tad too aggressive. I'm aware that your codebase is already pretty mature, but given the complexity of the Eclipse IP process I would suggest to be a bit more conservative here. And, please keep in mind that a 1.0 release in the Eclipse world does not only require the codebase itself to be mature, but it also means that the project has to succeed in building the 3 communities (developers, users, adopters).


Am 09.02.2010 um 09:51 schrieb Zsolt Beothy-Elo:

Hello Andrea,
thanks for the new version. It improved a lot and from my perspective it could be made public, but first you have to provide the emo with the latest version to allow them to update the draft on the net.
regarding the overlap with Swordfish I did not think that to be an impediment, but rather an oportunity to have a nice integration between the two products.


Anfang der weitergeleiteten E-Mail:

Von: Andrea Zoppello <andrea.zoppello@xxxxxx>
Datum: 3. Februar 2010 14:32:52 MEZ
An: Zsolt Beothy-Elo <zsolt.beothy-elo@xxxxxxxxx>
Betreff: Re: Fwd: [soa-pmc] Re: eBPM Proposal

Hi Zsvolt,

Well done, i'm not subscribed to soa-pmc, i'm going to subscribe quite now.

BWT your feedback are welcome.
I've attached the pdf version of the last proposal sent .

See my inline response:

Il 03/02/2010 12:23, Zsolt Beothy-Elo ha scritto:

I agree with Wayne that the section describing the scope should be
more specific. Additionally I have some further points:
- You should make explicit that not every OSGi service can be
orchestrated by eBPM out of the box. To be  part of the orchestration
a service has to follow the messaging model you mention and provide
the corresponding interface. So for existing services at least an
eBPM specific facade has to be implemented.

I've post an update project proposal where the project scope is more
clear, and where i explain we're going to provide a eBPM core framework,
so now i think this point is quite right now.
I've done clarification also on what we're going to provide and what
we're leveraging from other eclipse projects.
- While eBPM is targeted to orchestrate services located in the same
runtime (at least the pictures imply it) with the help of suitable
connector services you can also integrate external services (OSGi and
non OSGi), e.g. remote OSGi service with an ECF based connector or
Web services with a Swordfish based connector. I think this is worth
to be mentioned.
This is partially true. eBPM uses as it's base the OSGi Event Admin
Service so ideally you could use a distributed implementation of the
EventAdmin to orchestrate remote services, in these days i'm
working a lot on this and it's working pretty nice without any
connectors, i simply get the distributed event admin implementation from
ECF and it's working.

BWT i've taken your point and when talking about eBPM connectivity
services i put the collaboration with ECF and Swordfish as a project
goal. At this point of the process this is enough for me.
It does not make sense at this point to go in depth about the detail of
eBPM/Swordfish integration. We could do that when the project will be in
incubation stage.

- You also mention as one of the proposed components the "BPM Gateway
Process Engine" which will be be based on an open source process
engine for example jbpm. If you really want to base the component on
jbpm even if you do not intend to deliver jbpm together with the
project you will have a dependency to it, which must be approved by
the IP team. Unfortunately jbpm is published under LGPL which at
least to my knowledge will not be approved by the IP team. I would
advise you to select another more eclipse friendly process engine or
at least get in contact with the IP team to smooth out potential IP
Regards this point i've removed any references about jbm in the project

As described in the project goal, one of the goal of the project will be
to provide a BPMGateway API, and a BPM Gateway implementation. We'll
discuss about what
implementation to provide in future after we had talk with IP Team.
We've an implementation based on JBPM, btw we're considering other ways
so to provide a "light default implementation"
so to be ok with the project scope without having IP Issues.
The other option we have is to "discuss" with the IP Team about this
argument, but as the project looks now there's no problem.

- You should also mention that there is some overlap with Swordfish
regarding the base technology we are using. eBPM's messaging model is
conceptually very similar to one from JBI exposed through the
Normalized Message Router(NMR). Swordfish itself is based on JBI
through ServiceMix and relies on the messaging model provided
Normalized Message Router(NMR). As discussed we should investigate
whether it is feasible to base Swordfish on eBPM's messaging model
and achieve a better integration between both products.

Zsvolt, in last version of Spagic ( eBPM ) we rename the bundle that
were creating problems. The only overlap was in the usage of the nmr api
bundle. Regards the integration as our last meeting
in Municvh we've already demonstrate that Spagic/eBPM could work with
SOPERA/Swordfish quite welll with no problem.

BTW i think we could discuss this "technical details" further
(incubation phase and not in the "pre-proposal" phase... ).

Andrea Zoppello
<Eclipse BPM Project_final-1.pdf>


Oliver Wolf
Chief Architect 
Tel.:    +49 228-182 19059
Fax:    +49 228-182 19193
Mobil:  +49 160-98931313

Wussten Sie schon? 
SOPERA <>  hat den Open Source Business Award 2009 <>  verliehen bekommen!  

SOPERA GmbH - Open Source SOA
Subscription Services, Support & Maintenance, Training, 
Technical SOA Consulting & Customized Development <
SOPERA GmbH · Geschäftsführer: Dr. Ricco Deutscher, Harald Weimer, Peter Spiegel
Sträßchensweg 10 · 53113 Bonn · Handelsregister: Bonn HRB 15336
Hohenlindnerstraße 11b · 85622 München

Vertraulichkeitshinweis: Diese Nachricht und jeder übermittelte Anhang beinhaltet vertrauliche Informationen und ist nur für die Personen oder das Unternehmen bestimmt, an welche sie tatsächlich gerichtet ist. Sollten Sie nicht der Bestimmungsempfänger sein, weisen wir Sie darauf hin, dass die Verbreitung, das (auch teilweise) Kopieren sowie der Gebrauch der empfangenen E-Mail und der darin enthaltenen Informationen gesetzlich verboten ist und gegebenenfalls Schadensersatzpflichten auslösen kann. Sollten Sie diese Nachricht aufgrund eines Übermittlungsfehlers erhalten haben, bitten wir Sie, den Sender unverzüglich hiervon in Kenntnis zu setzen.

Back to the top