cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: CXF-DOSGi Zookeeper discovery data transformation
Date Mon, 25 Jun 2012 10:32:28 GMT
Hi David

Thanks for the explanation,
On 25/06/12 09:02, David Bosschaert wrote:
> Hi Sergey,
>
> On 22 June 2012 17:43, Sergey Beryozkin<sberyozkin@gmail.com>  wrote:
>> Hi David
>>
>> On 22/06/12 15:58, David Bosschaert wrote:
>>>
>>> Hi all,
>>>
>>> I'm currently playing with CXF-DOSGi in the context of a cloud setup
>>> and I'm also using the Zookeeper-based discovery.
>>> The problem that I'm facing is that the host and port as known by the
>>> local framework (running inside a cloud instance) is not the same as
>>> the public host and port. Obviously to be able to access the remoted
>>> service from outside you need the public host and port.
>>>
>>> So I came up with a DiscoveryPlugin interface which bundles can
>>> register in the OSGi Service Registry (in the true OSGi Whiteboard
>>> pattern way) to support such a transformation.
>>> It has the following API:
>>>
>>> public interface DiscoveryPlugin {
>>>      String process(Map<String, Object>    mutableMap, String fullPath);
>>> }
>>>
>>> Before the ZooKeeper client code in CXF registers the endpoint with
>>> the ZooKeeper server all registered DiscoveryPlugin are given a chance
>>> to process the data. They can change the properties of the service
>>> registration and change the path. So in my case I can change the URL
>>> where the local framework thinks it registers it (e.g.
>>> 127.5.3.123:8080) to the URL from where things are publicly accessible
>>> (e.g. my.cloud.instance:80).
>>>
>>> Would everyone be happy with me adding this feature to the
>>> cxf-dosgi-ri-discovery-distributed module? It's backward compatible -
>>> if you have no plugins registered nothing happens.
>>>
>> Looks like a neat idea.
>>
>> What does mutableMap will represent ?
>
> You're right - I could have made that a little more clear :) It
> represents the service registration properties that will be stored in
> ZooKeeper. For an example service they look like this:
>
>    endpoint.framework.uuid=609a4e6b-9abe-0011-1888-adf8693241e9,
>    endpoint.id=http://127.0.0.1:8080/repo,
>    endpoint.package.version.org.acme.foo=1.0.0.SNAPSHOT
>    endpoint.service.id=44,
>    objectClass=[org.acme.foo.SomeInterface],
>    org.apache.cxf.ws.address=http://127.0.0.1:8080/repo,
>    service.imported.configs=[org.apache.cxf.ws],
>    service.imported=true,
>    service.intents=[SOAP.1_1, HTTP, SOAP],
>
> So it might be more appropriate to call the argument mutableProperties
> instead of mutableMap (I'll make sure to add proper JavaDoc too :).
> Whatever you change in that map will be stored in ZooKeeper using the
> changed value (note that the actual service registration in the local
> framework doesn't change).
>
OK
> The plugin also allows you to change the path where it is changed by
> returning a different path, so for example in my case the fullPath
> variable is
>    /osgi/service_registry/org/acme/foo/SomeInterface/127.0.0.1#8080##foo
> It would allow you to change that to something like
>    /osgi/service_registry/org/acme/foo/SomeInterface/my.cloud.host#80##foo
>
Sounds good. Minor observation is I guess that the plugin would only be 
interested in replacing the the "127.0.0.1#8080##foo" part, and if yes 
then may be it will be marginally simpler to have:

String process(Map<String, Object> mutableProperties,
                String registryPath,
                String hostInformation);

String actualHostInfo = plugin.process(properties,
 
"/osgi/service_registry/org/acme/foo/SomeInterface",
                                        "127.0.0.1#8080##foo");

Not sure if it make sense :-). Having a plugin to do a basic parsing of 
the fullPath would not ne a big issue I guess :-)

Cheers, Sergey

> Cheers,
>
> David



Mime
View raw message