[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Fun with remote services part 1

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