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 <[EMAIL PROTECTED] .com> To Sent by: Equinox development mailing list equinox-dev-bounc <[email protected]> [EMAIL PROTECTED] cc Subject 06/28/2007 09:40 Re: [equinox-dev] Finding a running PM instance Please respond to Equinox development mailing list <[EMAIL PROTECTED] 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
<[EMAIL PROTECTED]>
             Sent
by:                                                   To
equinox-dev-bounc         Equinox development mailing list
             [EMAIL PROTECTED]
<[email protected]>

cc


             06/28/2007 03:53
Subject              PM                        [equinox-dev] Finding
a running
instance


             Please respond
to
Equinox

development
               mailing
list
<[EMAIL PROTECTED]

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
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev


_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev


_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Reply via email to