|Riena Remote Services OSGi EE compliant using ECF [message #642173]
||Tue, 30 November 2010 08:59
| Christian Campo
Registered: July 2009
I received the ping from Scott Lewis that is shown on the bottom of this post.
Basically he is asking whether Riena wants to complete an implementation (for which a torso is hosted at ECF) which
would make Riena remote services or better Hessian a protocol that can be used through ECF.
So in other words you could and would then use ECF's mechanism to do remote servicing and not only have the option to
use r-osgi, ecf generic, jms etc. but also use Hessian or use Riena Remote Service.
The benefit that Scott sees that you get all the standards pieces for free. Like publishing Services you would notions
from the OSGi EE standards specification and the same for creating proxies for remote services on the client.
You also get a discovery mechanism that ECF implemented. We in Riena just abandoned our own discovery mechanism because
was not really used and useful.
So my question is:
1. Has anybody who uses Riena (!) has a strong opinion about such an ECF-provider for Riena ? Would you want one ? Do
you see an advantage in using a OSGi EE standard way of doing remote services ? Both options (the current way in Riena
and the other way using ECF and then Riena Remote Services) allow you to have the same implementation for your OSGi
Services and you can also for both options use the same kind of Dependency Injection that you use today. The difference
is about making OSGi Service published and creating remote proxies on the client plus discovery. (I know ECF-people have
an opinion but I am pointing this question to current Riena users)
2. Who is willing to work on such a thing (with support from us and probably from the ECF Team) to create such a
provider. That means understanding the concept of ECF-providers and writing some code to make that work with the current
implementation of Riena remote service ? (Please answer this question independant of question. So its valid to want an
implementation but not want to implement this :-) ) The background of this question is that I have neither from any
customer nor from the community yet seen anyone who is missing such a provider. So I personnaly have no urge and no
ressources to implement it. But maybe that is completly different for others.
I look forward to your feedback. More information about this topic can be found in the bug mentioned below. Please also
comment or reply if that topic never occurred to you and you have questions or comments.
Feel free to use the newsgroup, the mailing list or directly the bug report below.
Product/Component: Riena / core
--- Comment #36 from Scott Lewis <firstname.lastname@example.org> 2010-11-25 11:17:28 EST ---
This is a ping to determine if there has been any progress from the Riena team
on this enhancement.
As described in comment 35, there is a skeleton Riena provider plugin that
could be used to create a Riena-based remote services provider. This project
is now in the ECF git repo, since ECF has moved over to git. It's located
For general info relevant to this enhancement...ECF 3.4 was recently released
with an impl of the OSGi 4.2 remote services spec. This impl uses the ECF
remote services API abstraction to allow pluggability of any provider (current
providers based upon r-osgi, ecf generic, jms, xmpp, rest, javagroups).
The point being that a completed Riena-based provider (this bug) would
immediately be usable for fully-compliant-to-standard remote services...without
any further additions or changes...just like the ones listed above.
As well, we are nearing completion of the OSGi 4.2 remote services *admin*
spec...see bug 324215. Any/all ECF remote services provider would/will also be
usable with this standard implementation without modification/further
additions. Also, Riena-based distribution and remoting would be usable with
any/all existing ECF discovery providers (e.g. zeroconf, zookeeper, slp, dnssd,
To summarize...completion of a Riena-based provider (this bug) offers the
following to both the Riena community and the broader consumer community:
1) Immediate standards compliance...with no additional technical work (i.e.
without reimplementing the OSGi 4.2 remote services spec)
2) Ability for consumers to mix Riena-based remoting with any/all the ECF
discovery providers (and/or new ones)
Powered by FUDForum
. Page generated in 0.02433 seconds