Re: [equinox-dev] Finding a running instance

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Thomas,

I just want to jump in here.  I think that there are reasons to consider 
standardizing (with OSGi R5 or future) an API for remote 
services...*independent* from a specific full remote service 
implementation (e.g. Jini, JXTA).  Some reasons:

1) As Waldo points out in his posting:  
http://www.artima.com/weblogs/viewpost.jsp?thread=202304, OSGi and 
JINI's service layers are not conflicting, i.e. OSGi's notion of service 
was originally focused on in-process service access, and JINI's 
out-of-process...unless you believe in 'strong transparency' these are 
not the same service models.  Apps differ in their need for in-process 
vs. out-of-process service access, and so it doesn't make sense to 
require having just one service model (either OSGi-on-JINI or JINI-on-OSGi).

2) JINI implies a certain approach to remote service access, which by 
itself may be overly restricting.  Namely, service access is always via 
RPC...i.e. with call/return semantics.  Although I don't think there is 
anything wrong with this, I think that in many cases other sorts of 
service interaction models are desireable (e.g. asynch with callback, 
'fire and go', etc).  For example, JXTA is based upon asynch messaging 
to a single process or group, and this makes it desireable for some 
use/app cases.

So I think that what would be most desireable is if the OSGi service 
specification was enhanced with new APIs for things like:

a) remote service discovery
b) remote service access (asynch/synch)

In ECF, we've tried to begin this process by defining an abstract 
discovery API bundle (org.eclipse.ecf.discovery [1]) and a remote 
service access API (org.eclipse.ecf.remoteservices) bundle.  Neither of 
these is bound to a particular transport/wire protocol, and 'b' is, by 
design, very close in approach to the OSGi service API (e.g. 
IRemoteServiceReference, IRemoteService, etc...you get the idea)...but 
with constructs that *allow* other styles of remote access (e.g. 
IRemoteService.callAsynch) as well as RPC...e.g. 
IRemoteService.getProxy()).   Note that parts of this API could be also 
be exposed 'transparently' (i.e. like R-OSGi).

Anyway, IMHO the key for standardization is focusing on protocol 
independent API for access to remote OSGi services, and *not* try to 
force/standardize

1) a particular transport
2) whether remote services are network 'transparent' or not (allow both)
3) what interaction style (e.g. synch/asynch) can be used to interact 
with remote services

My $0.03.

Scott

[1] http://wiki.eclipse.org/index.php/ECF_API_Docs#Discovery_API
[2] http://wiki.eclipse.org/index.php/ECF_API_Docs#Remote_Services_API


Thomas Hallgren wrote:
> Perhaps this could be a path forward, at least long term. 
> http://www.aqute.biz/Blog/2007-04-05 ?
>
> What would happen if OSGi decided to adopt JINI for remote services?
>
> - thomas
>
> Pascal Rapicault wrote:
> > There is not support for that in equinox, though there is an enhancement
> > request toward that (I can't seem to find the bug #) and there is also a
> > SOC project trying to do a similar thing
> > (http://wiki.eclipse.org/Eclipse_Web_Interface).
> > It is an area where we would be happily reviewing contributions.
> >
> > HTH
> >
> > PaScaL
> >
> >
> >                                                                            
> >              Thomas 
> > Hallgren                                                            
> > <thomas@xxxxxxx>                                              
> >              Sent 
> > by:                                                   To              
> > equinox-dev-bounc         Equinox development mailing list    
> >              es@xxxxxxxxxxx            
> > <equinox-dev@xxxxxxxxxxx>           
> >                                                                         
> > cc 
> >                                                                            
> >              06/28/2007 03:53                                      
> > Subject              PM                        [equinox-dev] Finding 
> > a running                                            
> > instance                            
> >                                                                            
> >              Please respond 
> > to                                                               
> > Equinox                                                  
> >                 
> > development                                                
> >                mailing 
> > list                                                             
> > <equinox-dev@ecli                                             
> >                  
> > pse.org>                                                  
> >                                                                            
> >                                                                            
> >
> >
> >
> >
> > Hi,
> > we have a use-case where one app based on the Eclipse runtime would like
> > to discover other running applications, also based on the Eclipse
> > runtime, on the same machine. Does the Equinox OSGi layer contain some
> > kind of discovery mechanism that would make this possible? If not, does
> > anyone know of other projects that might have a solution or work in
> > progress to solve this?
> >
> > Thanks,
> > Thomas Hallgren
> >
> >
> > _______________________________________________
> > equinox-dev mailing list
> > equinox-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/equinox-dev
> >
> >
> > _______________________________________________
> > equinox-dev mailing list
> > equinox-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/equinox-dev
> >   
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev