Re: [riena-dev] Riena Remote Services OSGi EE compliant using ECF

["Ziegler, Alexander" <Alexander.Ziegler@xxxxxxxxxxxx>]

Hi Chris,

We are using Riena developing a business application within an financial
customer project. The backend functionality provides a web service based
approach for the integration into our application. Same like many other
customers.


For our project is Riena Remote Service based on hessian communication
exactly that what we need. A very simply API and fast way to implement
services (OSGi Services) an public them as Remote Services. Also on the
client side a very easy way to register an OSGi Service as Remote Service
Proxy. The Application content need using Remote Services transparently
through OSGi Services because the client can run "Online" or "Offline". In
this case it was very helpful to replace OSGi Services from Remote Service
proxies to local implementation and reverse. The application content have
no need to know about that details.

In our case we neither need Framework like ECF nor a other communication
protocol. For this kind of business application i see currently no need
for ECF or a more powerful communication API.

The OSGi EE (Remote Services) standard becomes may be interesting in the
future. At the moment i dont believe our customers think about that before
OSGi EE is entrenched and they get a real benefit (e.g. interesting
products/applications provides standard OSGI EE APIs for interoperability
reasons). 

cm2c
Alexander


Am 30.11.10 09:59 schrieb "Campo, Christian" unter
<christian.campo@xxxxxxxxxxxx>:

>Hi Rienaers,
>
>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.
>
>cheers
>
>christian
>
>
>https://bugs.eclipse.org/bugs/show_bug.cgi?id=274839
>Product/Component: Riena / core
>
>--- Comment #36 from Scott Lewis <slewis@xxxxxxxxxxxxx> 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
>here:
>
>http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/incubation/bundles/o
>rg.eclipse.ecf.provider.riena
>
>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,
>file-based discovery).
>
>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)
>
>-------------------------------------------------------------
>compeople AG
>Untermainanlage 8
>60329 Frankfurt/Main
>fon: +49 (0) 69 / 27 22 18 0
>fax: +49 (0) 69 / 27 22 18 22
>web: http://www.compeople.de/
>
>Vorstand: Jürgen Wiesmaier
>Aufsichtsratsvorsitzender: Christian Glanz
>
>Sitz der Gesellschaft: Frankfurt/Main
>Handelsregister Frankfurt HRB 56759
>Ust-Ident.-Nr: DE207665352
>-------------------------------------------------------------
>_______________________________________________
>riena-dev mailing list
>riena-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/riena-dev