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

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