[news.eclipse.technology.riena] Re: Please remove incorrect remarks abou

[Christian Campo <christian.campo@xxxxxxxxxxxx>]

Hi Scott,


Scott Lewis schrieb:
> Rieners,
>
> In the current Riena proposal is this statement about ECF:
>
> > Eclipse already contains a powerful multipurpose communication 
> > framework called ECF. 
>  >It can be used for chat, VoIP, application- and >data sharing and many 
> of other purposes
>  >inside the IDE and in eclipse-based applications themselves.
>
> This is correct, except that it leaves out that ECF can/is also used for 
> RCP and Equinox-based server applications as well.

I'd argue that RCP and server based applications is what we meant with "eclipse-based applications".
However we can change the wording if that is helpful.

> > It also contains a remote services concept not based on OSGi Services.
>
> This is not correct.  ECF's Remote Services API is indeed based upon 
> OSGi Services.  For technical details see:
>
> http://wiki.eclipse.org/index.php/ECF_API_Docs#Remote_Services_API
>
> And for info about using ECF remote service API transparently or not (up 
> to programmer), see below.

Certainly true. We need to change that.
> > Both, ECF and Riena remote service support are able to fulfill the 
> > requirements of 
>  >enterprise applications using different approaches.
>
> This much is correct...although the approaches are not really that 
> different.  The main difference is that ECF has a built-in separation 
> between remote services API (ECF Remote Services API) and implementation 
> (ECF providers).

I think the approaches are not identical. While ECF has its own API, Riena Remote
Services can only be accessed using the OSGi APi. Furthermore because a Web Service Endpoint
on the server is (currently) only created for existing OSGi Services.

I certainly agree that Riena users should be able to use ECF or Riena Remote Services on their
own choice. However the approaches, the focus and the audience for both APIs is not identical.
There are differences which does not make one superior but just make them different.

> > Riena's remote service support is not intended to be an all-purpose 
> > communication 
>  >framework, but rather be focused and optimized for remote service 
> communication based on the Equinox platform.
>
> This implies that ECF remote services is not focused and optimized for 
> remote service communication based upon the Equinox platform...which is 
> incorrect.

I disagree. This just says that Riena is focused on only one protocol, one type
of communication and not meant to be multipurpose. ECF has more than one focus
namely voip, chat, remote services and many other categories (at least my impression
from the presentation on the ESE 2007).

I can change it to "... is only focused...." if that helps....


- christian

> Please make these corrections to the proposal.
>
> Scott
>
> About using ECF remote services API with network transparent proxies:
>
> A completely transparent access to the ECF remote services API was 
> added...such that if a certain property is set upon service 
> registration, the remote creates/adds a proxy to the local service 
> registry, and clients simply lookup with the normal
>
> ServiceReference ref = bundlecontext.getServiceReference(IFoo.class);
> IFoo inst = (IFoo) bundlecontext.getService(ref);
> // use IFoo inst
>
> and the IFoo is an ECF-dynamically created proxy to the actual (remote 
> service).
>
> There is working test code for this here:
>
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/tests/org.eclipse.ecf.tests.remoteservice/src/org/eclipse/ecf/tests/remoteservice/ServiceReferenceTest.java?root=Technology_Project&view=log 
>
>
> As you can see from the code, for the client, it only uses the 'normal' 
> service registry.
>
> The fact that it is actually a remote reference is exposed/discoverable 
> via the service properties.  See the other test case in the test code 
> above.