[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [soa-iwg] Content of the Eclipse SOA Package
|
Hi Oisin,
Oisin Hurley wrote:
I don't think that including the ECF distributed OSGi work (i.e.
RFC119 and dependencies) at all leads to a disintegrated set of
components. A coherent SOA package, by my definition, would include
that work...since it represents the available work from the Runtime
projects on that section of OSGi 4.2.
For 'coherence' there would need to be a level of useful
integration and guided tooling around creating a Remote
Service using the DOSGi capabilities, PDE etc.
I don't completely agree with this definition of coherence. I'm
referring primarily to coherence WRT the runtime/Equinox in
particular...which has to do with coherence+integration with Equinox and
existing other Runtime technologies...not primarily coherence wrt
tooling. I'm not saying coherence WRT tooling is bad or anything, I'm
just saying that's not the primary notion of coherence (afaict) in the
Runtime project that I've experienced so far. It seems to me that
standardization (i.e. OSGi 4.2 in general, RFC119 in particular) is an
important part of what Runtime coherence is...(obviously my opinion, but
I doubt that would be in too much dispute).
BTW, the existing PDE and ECF do have some support already for RFC119
(transparent remote services). Since the RFC119 notion of a remote
service looks to clients just like a local service (i.e. in service
registry with a 'remote' service property), remoted services
can/will/are already in the PDE registry view (also this enhancement
request to make it clearer [1]).
Further, we (ECF) do have user interface for showing discovered service
publications (i.e. via our discovery API), and even invoking arbitrary
remote services on those discovered services via simple UI that does
reflective lookup on the service interface. This does constitute some
tooling in support of the distributed OSGi work...primarily useful for
debugging the service. Further, since declarative services is
inherently usable with remote services/RFC119, the PDE 3.5 tools for
creation of a remote service are immediately usable for
creating/building remote services as well.
Same goes for any other runtime that's being included,
of course, I'm not picking on ECF specifically.
As for participation...I consider creating the relevant
software significant participation.
Your opinion is interesting - but what does everyone
else think?
Good question. I would point to the community input we've received via
1) The ECF rfc119 support enhancement request [2]
2) The ECF dev mailing list [3]
3) A couple of blog postings specifically about usage (e.g. in
combination with declarative services support) [4] , [5]
4) Other bugs/enhancement requests we've received (search for
ecf.remoteservices component open/assigned bugs)
5) Newsgroup [6]
There are others, of course, so if you want additional, specific,
opinions please let me know and I'll point you at the ones I know about
> BTW, I think ECF being the wire between equinox based SCA runtimes
> would really make a lot of sense :-)
>
Me too. So I think we've established that most of what it takes to
effect it is some sense.
I'm reading that last sentence to have a rather insulting
and abusive meaning. But I must be making an error.
You are (making an error). Insulting/abusive is not the intention. As
all know, email is notoriously poor for such subtlety...and I regret the
attempt.
Any
chance you could expand on it a bit more?
No, I would prefer to stay on the main topic.
Scott
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=270684
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=249240
[3] http://dev.eclipse.org/mhonarc/lists/ecf-dev
[4]
http://industrial-tsi-wim.blogspot.com/2009/08/running-equinox-osgi-and-ecf-on-system.html
[5]
http://bryanhunt.wordpress.com/2009/06/20/remote-declarative-osgi-services/
[6]
http://dev.eclipse.org/newslists/news.eclipse.technology.ecf/maillist.html
