Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Finding a running instance

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



Back to the top