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

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Eugen,

Eugen Reiswich wrote:
> Hi Scott, hi Wim,
>
> I've also checked out the hello.ds examples and tried to understand 
> how this example works. As I understand the host has to provide 
> specific server properties within the service component. And as far as 
> I understand these properties will trigger ECF to make a 
> service remotely available (I didn't really get what exactly happens 
> here).  In my XMPP case I've changed the example to:
>  
> <property name="service.exported.interfaces" type="String" value="*"/>
>  <property name="service.exported.configs" type="String" 
> value="ecf.xmpp.smack"/>
>  <property name="org.eclipse.ecf.containerFactoryArgs" type="String" 
> value="jabber-server.de <http://-server.de>"/>
>
> If I got you right Scott I do no longer need to create an instance of 
> IContainer like I did before: 
>
> IContainer container = 
> ContainerFactory.getDefault().createContainer(protocol);
> XMPPID xmppid = new XMPPID(container.getConnectNamespace(), userName + 
> "@" + server);
> IConnectContext connectContext = 
> ConnectContextFactory.createUsernamePasswordConnectContext(userName, 
> password);
> container.connect(xmppid, connectContext);
>
> But how do I now  provide with DS username and password in order to be 
> able to connect to a server?

Because OSGi 4.2 provides no standard way to provide credentials for 
connect authentication, and the XMPP provider and service obviously 
require such credentials, it's necessary to use some mechanism not 
exposed by OSGi service properties.  There are a couple of ways provided 
by ECF's implementation:

1) An explicit connect...i.e. the code that you use above to create and 
connect a container. 
2) Implementing and registering your own IProxyContainerFinder, so that 
upon discovery (and container creation, and connect), that your 
credentials can be provided.

I would say, that given that you already have the code for 1, that 1 
seems more appropriate for you...since you are already doing it.

Nevertheless, I'll describe 2 a little bit here.  The easiest way to 
customize the proxy container find/creation/connect is to extend  
org.eclipse.ecf.osgi.services.distribution.DefaultProxyContainerFinder 
and override this method (actually declared in 
AbstractProxyContainerFinder):

   protected IConnectContext getConnectContext(IContainer container,
           ID connectTargetID) {
       return null;
   }

Then, to have your proxy container finder used rather than the default 
one, simply register your instance as an OSGi service using the 
whiteboard pattern:

context.registerService(IProxyContainerFinder.class.getName(), new 
MyProxyContainerFinder(), null);
(you can do the registration with ds if you prefer)

By overriding this method (getConnectContext) you can provide the 
appropriate credentials for the connect that happens within the proxy 
container finder during the OSGi 4.2 consumer-side discovery.  So, for 
example

public class MyProxyContainerFinder extends DefaultProxyContainerFinder {

private String username;
private String password;

public MyProxyContainerFinder(String username, String password) {
  this.username = username;
  this.password = password;
}

protected IConnectContext getConnectContext(IContainer container, ID 
connectTargetID) {
  if (container and connectTargetID are appropriate types/values)
     return 
ConnectContextFactory.createUsernamePasswordConnectContext(this.username, 
this.password);
}

}

There is a little more documentation on the host and proxy container 
finder...and customizing the ECF impl of OSGi remote services:

http://wiki.eclipse.org/Customizing_and_Extending_ECF_Remote_Services

Note that depending upon how you are doing host registration and 
discovery, you will also have to specify (in service properties) the 
connectTargetID...which is used by the 
DefaultProxyContainerFinder.findProxyContainers method (which ultimately 
calls the getConnectContext when creating and then connecting a 
container). 

So like I mentioned before, it seems to me that method 1 may be the 
easiest/quickest route for you (rather than method 2), but I wanted to 
use the opportunity to explain method 2 a little, since it provides 
quite a lot of flexibility for use cases that don't fit into the default 
OSGi 4.2 rs mold...like the use of XMPP.

Incidently...another thing to mention...it's also possible to override 
DefaultProxyContainerFinder.findProxyContainers and change the entire 
implementation of how an ECF container is selected/created/connected 
during OSGi 4.2 discovery.  For some use cases, this might be desired.

> On the client side the hello.ds.consumer bundle only describes that it 
> requires an IHello service. But I was not able to find out how the 
> service is configured: server url, username, password.

The server url and username (for xmpp) would be conveyed in what's 
called the 'endpointID' in discovery...e.g. for the XMPP provider the 
endpoint id would be an XMPP account:  'scottslewis@xxxxxxxxx'

Scott