Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] tutorial idea: OSGi remote services for existing services

On 12/9/2014 1:18 AM, Keimel, Christoph wrote:
Hi Scott

Thanks for working on a tutorial on this subject! It reads very well and understandable. There are some questions I asked myself while reading. Maybe this could also be interesting for others?

Quote:
"2. Serialize the parameters passed to the getTimezone method (i.e. 'lat' and 'lng') and add them as URL request parameters, resulting in the URL: http://api.geonames.org/timezoneJSON?lat=<lat param value>&lng=<lng param value>&username=<username default value>"

Questions:
1. How does ECF know which parameters of the function getTimezone correspond to the parameters of the REST service? Is the relation itself built in the order in which the parameters where defined?

Yes, it's the order.


2. Would it be possible to overload getTimezone and also have a version supplying the username?

Yes.


3. Would it be possible to overload getTimezone adding some other parameter unrelated to the REST request, which should be cached to be reused by the responseDeserializer?

Yes.


4. How does ECF know how to serialize the parameters of the function getTimezone for the request URL? Is this customizable?

Yes, it's customizable by calling AbstractClientContainer.setParameterSerializer(IRemoteCallParameterSerializer serializer). The default is set to an instance of StringParameterSerializer, which is what is used in the example code to serialize the Doubles in the proxy call to Strings in the request.

In general much of the behavior of creating a request URL, processing and serializing parameters, making the http request, deserializing the response, etc. can be customized via setting new default instances and/or overriding methods on either the Container or the RestRemoteService instance. I've tried to anticipate and allow as much extension as I could. There are probably use cases that could be handled more gracefully, but I suppose that's what new API is for. :)

Scott




Back to the top