| Re: [science-iwg] Triquetrum Meeting Notes |
Scott,
Great to hear from you and I look forward to your involvement in the group.
I'm also looking forward to digging through the information you sent.
Jay
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
_______________________________________________
science-iwg mailing list
science-iwg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/science-iwg