Re: [ecf-dev] Fun with remote services part 1

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Eugen,

Eugen Reiswich wrote:
> Hi Scott, 
>
> sure! The first problem I ran into was that (as you have explained 
> recently) DS does not support providing authentication information. 
> Due to that I had to create the ECF-IContainer instance 
> programmatically. Afterwards I registered this instance as an OSGi 
> service. Next, I've provided for the services I wanted to publish the 
> following properties (the second one was a guess):
>    <property name="service.exported.interfaces" type="String" value="*"/>
>    <property name="service.exported.configs" type="String" 
> value="ecf.xmpp.smack"/>
>
> I did not provide the server URL as my IContainer was already 
> connected so I didn't see any sense to do it here again. As soon as I 
> started my application ECF threw an exception that there was a problem 
> with a container. I did not know how to fix the problem. Unfortunately 
> I can't reproduce the error because I've already changed my code. So 
> the server side did not work so far.

To figure out what went wrong here, some sort of indication of what 
method call resulted in the exception...and ideally a stack trace would 
be needed.  Without this, it's impossible to tell whether the problem 
was initiated by your code, something in ECF, or DS, or some interaction.

> Client-Side: 
> I did not understand how I can connect to my XMPP server client-side 
> using DS. As far as I understand again I would have to do this 
> programmatically (create IContainer, register in the client side 
> service registry) because of the authentication information. Next, in 
> order to be able to use a remote service in my RCP application I 
> didn't understand how I can retrieve the appropriate remote service. 
> I've tried to do it the way you've shown me, just to ask the service 
> registry for a service using DS. But I got a NP - well how should the 
> registry know that I require a service instance running on a different 
> machine? So this didn't work either.

Where/in what code do you get a NPE?  As per above, more info would be 
needed to determine whether such a problem is with your code, in DS, 
ECF, or in some interaction.

WRT your question about registry knowing that you require a service 
instance running on a different machine...as per the OSGi 4.2 remote 
services spec, on the consumer proxy there is a standard service 
property set...that service property is:  "service.imported".  On the 
*proxy*, this service property will be set to some non-null value.  In 
ECF's implementation, this property is set to the IRemoteService 
instance associated with the proxy. 

With a ServiceTracker, you can set up a filter that only detects/tracks 
service registry entries that have the 'service.imported' service 
property set to a non-null value.  There's an example of doing this in 
this class:  
org.eclipse.ecf.internal.examples.remoteservices.hello.consumer.HelloConsumerApplication

With DS, you can get at the service properties for an injected service 
(via bind method) by exposing a bind method with the following signature:

void <bindMethodName>(ServiceReference svcReference)
e.g.
void bindHello(ServiceReference helloReference) {
  ...examine helloReference properties...to see if 'service.imported' 
is set...if it is, then you want it...if not then not
}

It's also possible to have the bind method use a signature like this

void bindHello(IHello hello, Map svcProperties)

This is as specified in the DS specification, section 112.3.1 in the 
OSGi 4.2 compendium spec. 

> And as you mentioned I started to read articles that were outdated and 
> hence used an old API. Furthermore I've found some ECF/DS examples 
> that only work in a local subnet but didn't find any example with ECF, 
> DS and XMPP.

Do you mean the hello examples?  Yes, these use the ECF generic and DS 
rather than the XMPP provider.  Unfortunately, we simply don't have 
enough resources to create examples with all combinations of 
providers...crossed with the use of DS or not.

> Well now I'll wait for an article or tutorial that could help me. I 
> don't think I'll solve my problems without on site guidance.

I'm not sure that waiting for someone else to create an article or 
tutorial that has this specific combination of technologies for your use 
case (i.e. OSGi remote services, DS, and XMPP provider) is a great 
idea...as although I and some others could certainly do it, without some 
support several of us don't have the means to do it specifically for 
this one use case...given the other docs, examples, combinations of 
technologies that have been/are being requested.

If you want something like this (article, tutorial, working example 
code, etc) specifically for your use case, it would be best, I think, to 
either contribute to creating it, support (via some means) someone else 
in doing so, or some combination of both.

Scott