[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [ecf-dev] Re: More interfaces on remote OSGI services page

+1

-----Original Message-----
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

Hi Peter/all,

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.getServiceReferences(), 
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 
calls/responses.

Hopefully more to come soon...I've got to run now.

Scott


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 
> allows...
>
> --Peter
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ecf-dev


_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev

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.