[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Finding a running instance

Hi Pascal,

Can you provide any more info (RFP #) or pointers about this?  e.g. Who?  Is the RFP available to members/public?

Thanksinadvance,

Scott


Pascal Rapicault wrote:
The OSGi EEG is working on an RFP related to remote service.


                                                                           
             Scott Lewis                                                   
             <slewis@composent                                             
             .com>                                                      To 
             Sent by:                  Equinox development mailing list    
             equinox-dev-bounc         <equinox-dev@xxxxxxxxxxx>           
             es@xxxxxxxxxxx                                             cc 
                                                                           
                                                                   Subject 
             06/28/2007 09:40          Re: [equinox-dev] Finding a running 
             PM                        instance                            
                                                                           
                                                                           
             Please respond to                                             
                  Equinox                                                  
                development                                                
               mailing list                                                
             <equinox-dev@ecli                                             
                 pse.org>                                                  
                                                                           
                                                                           




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
    

_______________________________________________
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