I was going to open up a separate topic for this but I think at this point
of discussion, this might be a good place to bring it up. For the comet
binding i used the jsonp binding as an example. I was passing parameters for
the service as a JSON array and had the surprise that converting JSON arrays
to Object[] doesn't work that well because when performing the target
invocation types don't match - due to impossible downcast probably. My
solution was to parse the JSON array and for each parameter I converted it
to the specific type it was. Something like this:
for (final DataType<?> dataType :
operation.getInputType().getLogical()) {
args[index] = this.gson.fromJson(json[index],
dataType.getPhysical());
index++;
}
So, supporting complex types wouldn't be that complicated and it's as easy
to do with Jackson as well (i used Gson). The thing is, the JSONP binding
can't handle any other types other than String... not even primitives like
int. This means services exposed through jsonp should all have String
parameters... If i'm not wrong with the above statement, that might be a bit
too restrictive... I was going to ask if this type of feature is needed or
intended for jsonp. I could implement it.
>From the comet binding perspective, I found having this kind of support is
very comfortable in javascript as it is using javascript extensively. I
believe the jsonp binding is also built having in mind it's usage with a
jquery function like $.getJSON so returning JSON objects can't hurt. I don't
know how the rest binding is destined to be used (more from Java or
Javascript) but if we're hitting the same JSON conversion problem it might
be a good thing to have a global helper for this operations in the tuscany
core and all json-related bindings can use it.
About the parameter order, I've avoided this as I generated the javascript
proxies so parameters were given in the right order but in this case it
feels right being able to get the parameter names at runtime. How complex
and risky (in affecting other things) would be this kind of change? Would it
be doable?
Florian
On Sat, Aug 28, 2010 at 11:50 AM, ant elder <ant.el...@gmail.com> wrote:
> On Sat, Aug 28, 2010 at 9:12 AM, Raymond Feng <enjoyj...@gmail.com> wrote:
> > IMO, using HTTP/GET to access the RPC style services is just a poor-man's
> > web service. Don't go deeper to support complex types, don't try to
> support
> > POST, because that will reinvent the wheels that either WS-*, REST, or
> > JSONRPC already handles.
>
> Support for http/get is certainly the one i'd like to see us
> supporting first. The big reason why this is more useful than web
> services or similar POX is it can use JSON so becomes more useful to
> all the common browser tool kits. Its not jsonrpc as a lot of things
> don't need or support that, and this also would work with jsonp so
> would work cross domain.
>
> > If you don't like the JAX-RS annotations to provide the @name for the
> > parameters, maybe we can just support arg0, arg1, ..., argN or being
> > positional. Anyway, JAX-WS/JAXB seems to have the "arg" conventions.
>
> Ok that seems reasonable to also have in the default wireFormat. So
> that wireFormat could do the parameter mapping as:
>
> First if the binding configuration contains a mapping from query
> parameter name to operation parameter then use that. Otherwise if the
> service interface or impl uses jaxrs annotations to name the
> parameters then use that mapping, otherwise if the query parameters
> are name arg0, arg1 etc than use those names for the mapping,
> otherwise use the order in the query string.
>
> Sound ok?
>
> ...ant
>
