[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [science-iwg] Triquetrum Meeting Notes
|
On 6/18/2015 11:52 AM, Erwin de Ley wrote:
Hi Scott,
I thought I saw another face popping up suddenly! ;-)
Thank you for your interest, and for your offer to support the science
projects.
ECF is a project that I've been following since a long time, and it
would be great to provide an integration.
From my personal perspective also your two other topics are of interest :
- we do have projects with Passerelle that are not fully committed to
OSGi.
Passerelle core works fine in there as long as we don't start using
modules and/or actors that depend on OSGi services.
Your work seems to be an alternative to setting up Java serviceproviders?
Let me provide a little explanation of the work described at [4]. There
has been/is an effort to standardize a 'service registry without the
OSGi bundle layer'. This would/does make it possible to have java-only
access and usage of the OSGi service registry...i.e. registering
services, looking up services with service tracker or declarative
services...essentially everything one can do with OSGi services in a
full framework impl (including all the service dynamics, which is one
cool part), but without the bundle layer and so able to run as a 'plain
ol java program' with a smaller class and memory footprint. The Apache
Connect project (part of Felix) has an initial implementation, and the
OSGi Enterprise Experts Group (EEG)...which I am on/participate in...is
discussing a spec/standardization for R7 specification work during the
coming year.
Since OSGi Remote Services is an extender for the normal/in process OSGi
service registry, with the work at [4] I've simply used ECF's RS
implementation added to Apache Connect to demonstrate remote services in
java-only environments. This has some nice applications/use cases, I
think, because it's possible to have java-only clients with OSGi
servers, or OSGi clients with java-only servers, etc. and even better
the remote services themselves and their consumers can be designed
without any consideration of what the runtime is (java-only or OSGi
framework).
I think this is nice for service designers and service consumers,
because they can
a) use all the standardized OSGi service registry APIs...e.g.
registerService, DS, ServiceTracker, etc. on java-only or full framework
impls
b) design, build, test remote services in one environment and deploy on
another, or switch out one RS spec impl for another, etc. if desired.
And know that their (remote) service will behave the same way,
independent of distribution/transport protocol.
If you want more info just let me know. In the mean time I'll work on
the tutorial doc associated with the examples.
- I know that we have already some experienced eclipse project leads
in the science group, but I'm certainly not one of them ;-)
So I might start asking for information once we start setting up a
repository, builds etc!
Sure.
Scott
