[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [equinox-dev] Finding a running instance
|
Hi Scott,
I agree with you, but I though it was interesting to see that there are
efforts in this direction.
In any case, JINI is vastly overkill for what we want to accomplish.
We'd like something very lightweight and have no desire to go beyond the
boundaries of one machine. I'll ask you some questions about this on the
ecf forum.
Regards,
Thomas Hallgren
Scott Lewis wrote:
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