[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] Finding a running instance
|
I believe the access to RFPs is limited to members. Also don't be mistaken
here, as the acronym suggest those documents describe "Really Fun Problems"
and do not highlight a solution. The ones you may be interested in are:
RFP 79 Distributed OSGi Registry
RFP 75 RMI and Serialization for OSGi
PaScaL
Scott Lewis
<slewis@composent
.com> To
Sent by: Equinox development mailing list
equinox-dev-bounc <equinox-dev@xxxxxxxxxxx>
es@xxxxxxxxxxx cc
Subject
07/20/2007 02:06 Re: [equinox-dev] Finding a running
PM instance
Please respond to
Equinox
development
mailing list
<equinox-dev@ecli
pse.org>
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
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
