I searched the list for thoughts on 'client interfaces' concerning
this JSR, and didn't see anything. The spec currently lists 'client'
support as a non-goal.
That's a little worrying to me. Because it seems like 'client' side
interfaces should somehow be able to flow from the server side
definition, and if there's noone thinking about this, that might end
up being a harder job than it otherwise would be, once this JSR is
baked.
For example, if the service interfaces were annotated / described on
Java interfaces, instead of classes, you could easily imagine that
the interface could be used on the client as well. For instance, via
Proxy.
Things get tricky when wanting to describe a stream on either end of
the message; and figuring out how to make an invocation asynchronous
and cancellable on the client side might impact the method signatures
in various ways (constraining the types further; addinging some kind
of context/handler parameter).
It won't be simple. But it would be quite valuable.
Before you say "but Java is primarily used on the server; there
aren't that many clients that will need this", I'll point out (per my
previous note) J2ME. Sure would be nice to have a simplish RESTy
framework for my phone-based apps.
But there's a bene even for the server. I certainly expect that as
folks start building out more and more services, that they'll be
cases where service implementations end up being clients to other
service implementations. Which could then make use of a client
facing API.
Patrick Mueller
http://muellerware.org/