river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Firmstone (JIRA)" <j...@apache.org>
Subject [jira] Commented: (RIVER-315) "Translation layer" from OSGi components and River services and back again
Date Mon, 08 Feb 2010 23:05:28 GMT

    [ https://issues.apache.org/jira/browse/RIVER-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12831181#action_12831181
] 

Peter Firmstone commented on RIVER-315:
---------------------------------------

A Jini Service, to OSGi service mapping, would have to map multiple OSGi services to one Jini
Service, this is because Jini registers all the interfaces for it's service type, while an
OSGi Service registers only one interface, this will present visibility issues when using
remote reflective proxies (their service clients will need to import classes and packages
they don't utilise - oops).  So there it is, Jini's Service semantics are better suited to
distributed computing.  OSGi's service semantics are better suited to the local JVM, (just
like SPI) where your only interested in finding one interface. 

It is probably best not to attempt OSGi to Jini service mapping.  It would be possible to
map a Jini service to multiple OSGi services in the OSGi service registry, although the reason
to do this directly is not clear.  It would be better for an implementer to create a bundle
that is a client for a jini service and register a particular OSGi service, from that bundle,
relevant to the application.

> "Translation layer" from OSGi components and River services and back again
> --------------------------------------------------------------------------
>
>                 Key: RIVER-315
>                 URL: https://issues.apache.org/jira/browse/RIVER-315
>             Project: River
>          Issue Type: New Feature
>            Reporter: Tom Hobbs
>
> From the mailing list
> "Was there proposal to create an OSGi compatible module that acts as a Facade to host
River distributed services to OSGi applications that otherwise wouldn't be capable of taking
advantage of network aware (the
> 8 fallacies of distribute computing) redundancy capabilities?  What is the use case for
this?  Is this for a service that is critical to a particular application (from performance
or redundancy perspective) that may be subject to failure and the abilities of River to run
multiple services.  An OSGi based application that has outgrown it's roots so to speak, parts
of it can be rewritten based on River?  What issues would arrise due to remote objects?"
> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200907.mbox/%3c4A5D9AF0.6020100@zeus.net.au%3e

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message