[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Finding a running instance
The OSGi EEG is working on an RFP related to remote service.
Sent by: Equinox development mailing list
06/28/2007 09:40 Re: [equinox-dev] Finding a running
Please respond to
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
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
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 ) 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
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
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
>> It is an area where we would be happily reviewing contributions.
>> by: To
>> equinox-dev-bounc Equinox development mailing list
>> 06/28/2007 03:53
>> Subject PM [equinox-dev] Finding
>> a running
>> Please respond
>> 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?
>> Thomas Hallgren
>> equinox-dev mailing list
>> equinox-dev mailing list
> equinox-dev mailing list
equinox-dev mailing list