Re: [ecf-dev] Remote service API

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Yes, the evolution of the OSGi enterprise
effort has been one motivator to look more closely at the ECF work.  Clearly
the Eclipse community contains a large number of people from the "enterprise"
space.  Given Eclipse's adoption of OSGi it is natural that we be
very interested/involved in these efforts.  The Equinox project scope
includes all things related to OSGi specifications.  In the past Equinox
committers have worked very actively as part of the OSGi Core Platform
Expert Group to address the needs of Eclipse.  ECF it turns out has
developed a number of interesting approaches and technologies that look
interesting from an enterprise perspective.

As the Enterprise EG forms and sets
an agenda, the potential roles of Equinox and ECF (and the other Eclipse
projects) will become more clear.  Right now it is hard to say which
direction things will go and what will be needed.  With an emphasis
on distribution ECF does seem to be relevant in this area.

One of the challenges will be to see
*how* we can participate.  Currently OSGi is a closed specification
body in that only full members are allowed to participate in the expert
groups.  When the Eclipse Foundation does become a member it would
likely be as an associate member.  It is not clear that being a full
member would then suddenly confer rights to Eclipse members or committers
(seems unlikely).  So, you need some folks who work for OSGi member
companies and have an interest in pushing ECF in the EEG.  

Jeff

Scott Lewis <slewis@xxxxxxxxxxxxx>
Sent by: ecf-dev-bounces@xxxxxxxxxxx

09/15/2006 12:04 PM

Please respond to
"Eclipse Communication Framework (ECF) developer mailing list." <ecf-dev@xxxxxxxxxxx>

To	"Eclipse Communication Framework (ECF) developer mailing list." <ecf-dev@xxxxxxxxxxx>
cc
Subject	Re: [ecf-dev] Remote service API

Hi Ken,

It's an interesting posting.   The EF is getting more involved with
OSGi standardization efforts...I think that Jeff is heavily involved with
Peter and others on exactly this effort.  Jeff would you care to comment
on what you see as the right role for Equinox, ECF, and/or this remoteservices
API in this?

Thanksinadvance,

Scott

Ken Gilmer wrote: 

This post on the OSGi.org blog is relevant to this discussion:

http://www.osgi.org/blog/2006/09/enterprise-workshop.html


-Ken

On Sep 12, 2006, at 9:30 PM, Jeff McAffer wrote:


Sounds like fun!  I have not been following the ins and outs of ECF
much so please excuse any ignorant questions... 

- do you see a path to this being integrated with declarative services
and/or Spring and whatever Spring does for remoting?

- do you see integrating with/using concurrency constructs like Futures
whith remove services?   

- can I assume that under the covers you can use any transport to contact
the remote service? 

- do you know where I can find some spare time to play with all the great
things people are creating these days? ;-) 

Jeff

slewis <slewis@xxxxxxxxxxxxx>
Sent by: ecf-dev-bounces@xxxxxxxxxxx

08/04/2006 12:02 PM

Please respond to
"Eclipse Communication Framework (ECF) developer mailing list." <ecf-dev@xxxxxxxxxxx>

To	"Eclipse Communication Framework (ECF) developer mailing list." <ecf-dev@xxxxxxxxxxx>
cc
Subject	[ecf-dev] Remote service API

Hi Folks,

Although not completed, a 'signs of life' ECF remote service API is now
functioning with test code.  The intention of this API is to provide
access to remote services similar to the manner in which OSGI provides
access to local services via OSGi service registry.

The remoteservice API, however, is *not* the same as the OSGi service 
API,  in recognition/acknowledgment of the problems introduced by
approaches that attempt network transparency.   The remoteservice
API  
exposes a distinct API and underlying service registry, similar in 
structure to the OSGi services API, but with modifications to account 
for 1) the use of asynchronous messaging; 2) partial failure.

The three plugins in CVS are:

plugins/org.eclipse.ecf.remoteservice (API)
plugins/org.eclipse.ecf.provider.remoteservice (exampleprovider)
plugins/org.eclipse.ecf.test.remoteservice (JUnit Plugin test code)

As a brief example, here's how a remote service is registered/made 
available for remotes to access.  This is done on the client that
is the 
server for this particular service

// First get IRemoteServiceContainer adapter
IRemoteServiceContainer rsc = (IRemoteServiceContainer) 
container.getAdapter(IRemoteServiceContainer);
// Then register remote service
rsc.registerRemoteService(new String [] { IMyService.class.getName() },
service, null);

Note that the 'service' object must implement the IMyService.  Assume
that IMyService has a single method "exec()".  For those
familiar with 
the OSGI service interface, this looks very much like the 
BundleContext.registerService method.

Then, on the client that wishes to use the service:

IRemoteServiceReference [] refs = rsc.getRemoteServiceReferences(null,
IMyService.class.getName(),null);
// Assume we want the first one
IRemoteService remoteService = rsc.getRemoteService(refs[0]);
// Now call service with one of methods on IRemoteService:  callSynch,
callAsynch, fireAsynch, getProxy()

Note the getRemoteServiceReferences(...) and getRemoteService(...) are
similar to the OSGI BundleContext.getServiceReferences(...) and 
getService(...) methods.

The methods on IRemoteService allow the client to invoke the service in
several different ways...i.e. synchronously (callSynch) or 
asynchronously (callAsynch...with a listener callback for results, and
fireAsynch which fires a remote method asynchronously with no return 
value).  Note also the 'getProxy()' call, which will return an Object
*that is guaranteed to implement the IMyService interface*.  Meaning
that one can do this:

IMyService proxy = (IMyService) remoteService.getProxy();
proxy.exec();

And the remote 'exec()' method will be remotely invoked.

So the point of the IRemoteService interface is to allow the client to
control how the remote service invocation is done...synchronously with
return value, synchronously via proxy, or asynchronously with 
(callAsynch)/without (fireAsynch) return value.

There's test code in the org.eclipse.ecf.test.remoteservice test plugin
that uses these methods on IRemoteService interface.  I've made put
project set files for committer and anonymous cvs access here: 
http://wiki.eclipse.org/index.php/Remote_OSGI_Services

Any comments/criticisms/flames welcome.  This is just an initial "signs
of life" attempt, and the API and implementation will likely go through
many changes. 

Thanks,

Scott
_______________________________________________
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

---

_______________________________________________
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