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
