[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] iPOPO Compatible Providers

Hi Thomas,

On 11/21/2013 11:27 AM, Thomas Calmant wrote:

Hi

Just a small reply about properties.
I think we have 4 kinds of values to handle : strings, integers, floats and lists (of those types)

Or at least lists of strings, like the objectClass properties.


I should have previously referred you and all to the RSA enterprise spec chap 122.8 [1]...which gives what they call the 'endpoint description extender' format...and supported types.   I say this because since we implement the RSA spec, we support all the types defined in the EDEF. 

In ECF's RSA implementation, the IServiceInfoFactory service is (on host) responsible for the transition from

EndpointDescription -> discovery api service properties

and (on consumer/receiver)

discovery api service properties -> EndpointDescription

Since the types of all of the RS/RSA standard service properties are known (e.g. String[] for objectClass)...*I believe* that the ServiceInfoFactory default implementation simply uses Strings for encoding these standard properties for publish via discovery API (doesn't use serialized Long, or Float, or List or etc).   For example, with objectClass (what OSGi refers to as 'String+'...which is either String or String[]) I believe it gets encoded within the discovery service properties as:

Object[] objectClass = { "fqclass1","fqclass2","fqclass3" } gets encoded in discovery properties as:  "objectClass" = "fqclass1,fqclass2,fqclass3"

or Object[] objectClass = { "fqclass1" } gets encoded in discovery properties as:  "objectClass" = "fqclass1"

And then on the receiver side...it simply reads/parses these properties and converts them to the known appropriate type...e.g.

String[] objectNames = decode("fqclass1,fqclass2,fqclass3");  //  where decode/parsing is split(",");

I say all this because I think that given this, it may be easiest (and most generally useful) if on the python side something be created to implement the decode from the (jmdns) service properties (or any discovery protocol set of service properties) to a (RSA-specified) EndpointDescription.   As with String[] (lists), this decode is almost trivial for all the standardized service properties...and by looking at ServiceInfoFactory I can tell you exactly what it's doing for all of the standard properties)...and then this could be reused in python using *any* discovery provider...since ECF does the same thing wrt EDEF for all the discovery providers.

Just for example/reference, below is an EDEF xml generated (via ECF RSA) for one of our example remote services.  Since all of the properties in this example are standard ones (or ECF-specific ones), the types are known/specified...so as I describe above...I believe that they are encoded for discovery as String name/value pairs...even for Long,Class[], or List types.

Of course, if there are other (non-standardized) complex service properties for a given remote service then those will have to be dealt with differently (perhaps via the EDEF 'xml'?).

Scott

<?xml version="1.0" encoding="UTF-8"?>
<endpoint-descriptions xmlns="http://www.osgi.org/xmlns/rsa/v1.0.0">
  <endpoint-description>
    <property name="ecf.endpoint.id.ns" value-type="String" value="com.mycorp.examples.timeservice.provider.rest.namespace"/>
    <property name="endpoint.framework.uuid" value-type="String" value="20cc5d57-e8f0-0012-192b-c570b422d1f9"/>
    <property name="endpoint.id" value-type="String" value="http://localhost:8181"/>
    <property name="endpoint.package.version.com.mycorp.examples.timeservice" value-type="String" value="1.0.0"/>
    <property name="endpoint.service.id" value-type="Long" value="0"/>
    <property name="objectClass" value-type="String">
      <array>
        <value>com.mycorp.examples.timeservice.ITimeService</value>
      </array>
    </property>
    <property name="remote.configs.supported" value-type="String">
      <array>
        <value>com.mycorp.examples.timeservice.rest.host</value>
      </array>
    </property>
    <property name="remote.intents.supported" value-type="String">
      <array>
        <value>passByValue</value>
        <value>exactlyOnce</value>
        <value>ordered</value>
      </array>
    </property>
    <property name="service.id" value-type="Long" value="66"/>
    <property name="service.imported" value-type="String" value="true"/>
    <property name="service.imported.configs" value-type="String">
      <array>
        <value>com.mycorp.examples.timeservice.rest.host</value>
      </array>
    </property>
  </endpoint-description>
</endpoint-descriptions>







Cheers
Thomas

Le 21 nov. 2013 20:03, "Scott Lewis" <slewis@xxxxxxxxxxxxx> a écrit :
Hi Thomas,

On 11/21/2013 8:52 AM, Thomas Calmant wrote:
Hi Markus,

I played a little with Zeroconf, and I'm able to send notifications (except updates).
It's still a work in progress, e.g. it doesn't registers the detected services.
The code is on GitHub [1], for more visibility.

It seems that the ECF mDNS discovery uses Java serialization, which is unreadable for Python, to transfer non-String objects in service properties.

That's true...but as you say only for non-String service properties.   Do you need non-String properties for these services?  If you just use Strings, then it shouldn't present a problem.

If you do (and they are only simple types...e.g. Integer, Float, Double, etc)...perhaps you could just use this library to read them:   https://code.google.com/p/python-javaobj/    I haven't tried it, but if it does what's published it might very well be sufficient...particularly since I *believe* that what is published for remote services discovery (the OSGi RSA-defined Endpoint Description) is actually represented as only Strings and Longs. 

Also...we can/could extend the ECF RSA impl to publish EndpointDescriptions encoded as json.  For the ECFer's:  this process of encoding the RSA data for ECF discovery is done via the highest priority instance of this service: 

org.eclipse.ecf.osgi.services.remoteserviceadmin.IServiceInfoFactory

And the default implementation is: 
org.eclipse.ecf.osgi.services.remoteserviceadmin.ServiceInfoFactory). 

For example...we could encode any complex properties in EndpointDescriptions as json very easily with a custom IServiceInfoFactory.  And then simply replace the default impl by registering a higher priority IServiceInfo.

But before creating a custom IServiceInfoFactory...I think it would be worthwhile to attempt publishing (via RSA) the service, and look at what actually ends up in the jmdns service properties for the published service.  If it's all Strings...or maybe just Strings and Longs (with python-javaobj), then it may not be necessary to encode the complex EndpointDescription properties as json (but if someone wants to take that on, I would certainly endorse that...and of course could help with the IServiceInfoFactory integration).

Scott



The current version of the Python implementation uses the JSON format for common types (lists of strings, dictionaries, etc).

[1] https://github.com/tcalmant/pelix-ecf-chat/blob/master/experiment/mdnssd.py

Cheers,
Thomas



2013/11/20 Thomas Calmant <thomas.calmant@xxxxxxxxx>
I overlooked it when I started the iPOPO remote services (1 year ago), but I didn't found an easy way to notify services properties changes (only addition and removal).
I don't know if I missed it or if it is the way the protocol works.

I still haven't looked at the org.eclipse.ecf.provider.jmdns bundle, I planned to try to mimic its behavior with pyzeroconf.
An early draft is available on my dropbox [1].

[1] https://www.dropbox.com/s/3d8dcuva4y91dil/mdnssd.py

Thomas


2013/11/20 Markus Alexander Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx>
On 11/20/2013 01:52 AM, Thomas Calmant wrote:
> I got a case where services had serveral, very long properties values
> (full text strings), which implied to send packets larger than 1600
> bytes on notifications (registration and update).
> Of course, it raised the UDP packet ordering problem, so I decided to
> use multicast for small event packets only, and HTTP for information
> transfer.
> This is one implementation of a discovery protocol: other
> implementations can ignore the dispatcher servlet.
>
> Also, in this case, the HTTP server must be active for JSON-RPC to work,
> so there were no real constraint against this servlet.
> New providers can work without the dispatcher servlet without problem,
> as long as we have this "horror case" (the problematic exported service
> has been cleaned up since).


What about re-using an existing multicast-based solution like pyzeroconf
[1]?

M

[1] https://github.com/mcfletch/pyzeroconf
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev




_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev


_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev



_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev