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:
Andrea,
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
issues.
Regards this point i've removed any references about jbm in the project
proposal.
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... ).
Cheers
Andrea Zoppello
