Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Eclipse Communications Framework (ECF) » How does the Hello Service example project with Declarative Services work?
How does the Hello Service example project with Declarative Services work? [message #625369] Fri, 06 August 2010 11:37 Go to next message
Pablo Mising name is currently offline Pablo Mising nameFriend
Messages: 24
Registered: July 2010
Junior Member
Hi all.

Well, I am starting with OSGi and ECF, and I guess I am going to post here an stupid question...

I've tested the examples of http://wiki.eclipse.org/Getting_Started_with_ECF's_OSGi_Remote_Services_Implementation and they work great in several instances of Equinox in my local machine. But I don't know how the DS example is working. The service description of the consumer project requires the "IHello" service, and it is automatically bound when the host is available. Perfect. But... how the discovery service knows where to search? I mean, the normal example (hello.consumer, not hello.ds.consumer) includes the hello-service-description-generic.xml which defines the property "ecf.sp.cid" with the URL of the host (ecftcp://localhost:3787/server). But in the DS project there is no reference to that URL. And as I said, it works properly: binds the IHello, connects to the host, shows messages... but I don't know why :)

That brings me to another question: if I want to test remote services in another machines using DS, how can I stablish the URL of the machines that hosts that services? (I know how to do it without DS).

Thanks in advance, and as I said, sorry for the stupid question ;)
Re: How does the Hello Service example project with Declarative Services work? [message #625370 is a reply to message #625369] Sat, 07 August 2010 00:22 Go to previous message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Pablo,

Pablo wrote:
> Hi all.
>
> Well, I am starting with OSGi and ECF, and I guess I am going to post
> here an stupid question...
>
> I've tested the examples of
> http://wiki.eclipse.org/Getting_Started_with_ECF's_OSGi_Remote_Services_Implementation
> and they work great in several instances of Equinox in my local machine.
> But I don't know how the DS example is working. The service description
> of the consumer project requires the "IHello" service, and it is
> automatically bound when the host is available. Perfect. But... how the
> discovery service knows where to search? I mean, the normal example
> (hello.consumer, not hello.ds.consumer) includes the
> hello-service-description-generic.xml which defines the property
> "ecf.sp.cid" with the URL of the host (ecftcp://localhost:3787/server).
> But in the DS project there is no reference to that URL. And as I said,
> it works properly: binds the IHello, connects to the host, shows
> messages... but I don't know why :)


The hello.ds example uses the zeroconf discovery provider. This is
indicated in the name of the product configuration file...i.e. this file
for the consumer:

/org.eclipse.ecf.examples.remoteservices.hello.ds.consumer/p roducts/Hello
Service Consumer DS (zeroconf,generic).product

And this file for the service host:

/org.eclipse.ecf.examples.remoteservices.hello.ds.host/produ cts/Hello
Service DS Host (zeroconf,generic).product

Zeroconf publishes service meta-data automatically on the LAN. The
consumer receives that meta-data (via zeroconf)...then discovers the
service. Then the distribution system retrieves/creates a proxy, and
registers that proxy in the local service registry (on consumer)...and
DS takes over from there...notifying the HelloClientComponent by
injecting the IHello proxy into the HelloClientComponent.

No static (service description xml file) is *not needed*...since the
service meta-data is communicated via zeroconf over the network (or
zookeeper, or slp, etc). This is why you just see the IHello remote
service just 'appear'...because zeroconf communicates the existence of
this service via multicast on your LAN.



> That brings me to another question: if I want to test remote services in
> another machines using DS, how can I stablish the URL of the machines
> that hosts that services? (I know how to do it without DS).


So if you are able to use one of the network-based discovery protocols
(i.e. jmdns, apache zookeeper, slp), this shouldn't even be
necessary...since you don't need to specify a URL statically...it is
part of the meta-data communicated via the network discovery protocol.

But, if you do wish to specify the URL of the remote host statically
(i.e. file-based discovery) then you do need to know this URL and put it
into the xml service description...like this (this is copied from the
following file:

/org.eclipse.ecf.examples.remoteservices.hello.consumer/OSGI -INF/remote-service/hello-service-description-generic.xml

....
<service-description>
<provide
interface="org.eclipse.ecf.examples.remoteservices.hello.IHello "/>
<property
name="ecf.sp.cid">ecftcp://localhost:3787/server</property>
<property
name="ecf.sp.cns">org.eclipse.ecf.core.identity.StringID</property >
<property name="ecf.sp.ect">ecf.generic.server</property>
</service-description>
....


This is the miminal metadata needed to discover a remote ECF service.
The 'ecf.sp.cid' means: ecf service publication *container id*' The
container id is the value returned from IContainer.getID(). The
'ecf.sp.cns' means: ecf service publication *namespace*. This is the
*name of the namespace* used to create an ECF ID instance (i.e.
IDFactory.getDefault().createID(namespace,containeridstring) ). The
'ecf.sp.ect' means: ecf container type.

Now...to get the host container's ID (and namespace) you need to either:

a) specify the host container's ID upon construction (i.e. create a
container instance yourself and specify it's ID upon creation)
b) get the IContainer instance that's used...and call getID() on it (and
put the ID's name and namespace name the service description file).

If your plan is to use a static service description file on the
consumer, I would suggest that you probably want to do 'a'...i.e. so
that you can directly control what the host container's ID is (and what
it's hostname, port, and path in the ID is).

In the host.ds example, the container type and container id are
specified in the hello.xml file...i.e.
/org.eclipse.ecf.examples.remoteservices.hello.ds.host/OSGI- INF/hello.xml

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0"
enabled="true" immediate="true"
name="org.eclipse.ecf.examples.remoteservices.hello.ds.host ">
<implementation
class=" org.eclipse.ecf.examples.internal.remoteservices.hello.ds.ho st.HelloComponent "/>
<property name="service.exported.interfaces" type="String" value="*"/>
<property name="service.exported.configs" type="String"
value="ecf.generic.server"/>
<property name="org.eclipse.ecf.containerFactoryArgs" type="String"
value="ecftcp://localhost:30001/server"/>
<service>
<provide
interface="org.eclipse.ecf.examples.remoteservices.hello.IHello "/>
</service>
<reference cardinality="1..1"
interface="org.eclipse.ecf.core.IContainerFactory"
name="IContainerFactory" policy="static"/>
</scr:component>


The important/relevant info in this file is the value of the
'org.eclipse.ecf.containerFactoryArgs' property:
ecftcp://localhost:30001/server

When the IContainer instance is created (as part of the IHello service
registration by DS), the value of containerFactoryArgs is passed to code
that looks something like this:

IContainer hostRemoteServiceContainer =
containerFactory.createContainer("ecf.generic.server",new String[] {
"ecftcp://localhost:30001/server" });

Notice that the value 'ecf.generic.server' comes from the
'service.exported.configs'.

So the container id for the host container in this ds example is
'ecftcp://localhost:30001/server'. The container namespace is the value
of IContainer.getConnectNamespace().getName()...for the generic
provider...which is: 'org.eclipse.ecf.core.identity.StringID'. The
container type for the generic server is: 'ecf.generic.server'.

You can also create your own IContainer *before* the remote service
registration, and set it's ID upon construction...e.g. code like this:

IContainer c = containerFactory.createContainer("ecf.generic.server",
new Object[] { "ecftcp://localhost:30001/server" });

Namespace ns = c.getConnectNamespace();

// containerType = ecf.generic.server,
// container id = ecftcp://localhost:30001/server
// container namespace name = ns.getName() (which for generic server is
// org.eclipse.ecf.core.identity.StringID

One way to summarize this: the meta-data (for ECF remote services)
needed to statically discover a remote service is (as in the service
description file):

service interface name:
org.eclipse.ecf.examples.remoteservices.hello.IHello

container type: (ecf.sp.ect): ecf.generic.server
container id: (ecf.sp.cid): ecftcp://localhost:3787/server
container namespace: (ecf.sp.cns): org.eclipse.ecf.core.identity.StringID

There's more here going on under the covers, so if you want more
information please let me know.

Scott
Previous Topic:Download failure using Project Set File
Next Topic:OSGi Container bundles used at the Eclipse Remote Service tutorial
Goto Forum:
  


Current Time: Fri Mar 29 07:20:00 GMT 2024

Powered by FUDForum. Page generated in 0.02909 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top