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
