[
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
