[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ecf-dev] Re: More interfaces on remote OSGI services page
- From: "O'Flynn, Dennis" <Dennis.OFlynn@xxxxxxxxxxxxx>
- Date: Wed, 12 Jul 2006 07:08:10 -0400
- Delivered-to: email@example.com
- Thread-index: AcalQyCxl1xKr/qJQBecQ+fMrGp39QAYEEaA
- Thread-topic: [ecf-dev] Re: More interfaces on remote OSGI services page
From: ecf-dev-bounces@xxxxxxxxxxx [mailto:ecf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Scott Lewis
Sent: Tuesday, July 11, 2006 7:39 PM
To: Eclipse Communication Framework (ECF) developer mailing list.
Subject: Re: [ecf-dev] Re: More interfaces on remote OSGI services page
Peter sorry I haven't responded to this thread previously...it's just
lack of my bandwidth. I was very excited and happy to see that you have
some time for ECF these days.
I think there's I also think there is some similarity between part of
what Peter was proposing in his previous email and the remote OSGI
services stuff. One of the things that the OSGI services (not remote
services, just plain 'ol OSGI services API) provides is the notion of a
'ServiceReference', which is found, created and resolved by the OSGI
bundle environment (as represented by the BundleContext...e.g.
BundleContext.getService(ServiceReference), etc. This notion of a
servicereference is, in several ways, very similar to a 'proxy'...which
could potentially have underneath it the ability to get a handle on a
local reference (e.g. getService(ServiceReference), which turns around
and marshals the method call/params, makes remote call, optionally waits
for/expects response from remote host plugin of ServiceReference (on
remote server or client).
So in one sense, the ServiceReference provides something approaching a
'proxy'...used by the OSGI platform to manage the cross-bundle service
accesses (as well as to provide a means to search for services with meta
info like class, and filter).
This also bears some resemblance, I think, to Peter's "publisher"
notion...that exposes/allows searching/access to either proxies that
have registered themselves with the publisher. Note there is
flexibility in having proxies that could be 'smart' (i.e. have local
replica of state)...or proxies could just marshal/unmarshal remote
Hopefully more to come soon...I've got to run now.
Peter Nehrer wrote:
> Scott, Ken,
> I'm afraid I missed the beginning of the last conference call when you
> probably discussed this topic, so I'm not sure if this is relevant,
> but the idea of supporting selective replication of certain services
> (not necessarily as OSGi services) crossed my mind when putting
> together the shared model/pub-sub example. Initially, I was focusing
> on simply allowing interested group members to receive model updates
> from the "publisher", but while working on the implementation I
> noticed that there's a rather generic part to this scenario.
> Basically, someone puts out a "service" (to put abstractly) and others
> may request a replica to be sent over to their local container. What
> the service does and how it's manifested in the replica is completely
> application-specific. You can almost think of it in a way as service
> provisioning -- the replica could act as a proxy to a remote service
> that is not available locally.
> Scott, looking at your wiki page, I think there are a few conceptual
> similarities in the API, though I know I haven't documented nor
> finished the pub/sub example. I'll continue working on it as time
> ecf-dev mailing list
ecf-dev mailing list
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.