This topic is actually what I raised up in the very beginning of this
JSR, however, it was pulled out of the scope as this JSR was declared
to focus on the server side.
JAX-WS may demonstrate a possible future if we add the client side to
this JSR. we need to come up with some client programming model with a
decent symmetric view to the server side. Even SOAP/WSDL has turned
out to have many holes against the complete mapping between web
services and programming platforms, and REST has no such an airtight
spec for both messaging and interfacing. WADL could be a candidate,
and if it's the case, then WSDL to Java (and vice versa) revives as a
form of WADL to Java (and unfortunately vice versa).
Personally I use Restlet for consuming RESTful web services and it
suffices in most cases although it necessitates kind of OX(Object-XML)
mapping (e.g. JAXB). Restlet has a good API set for representations
and provide flexible extension points.
To sum my feelings up,
1. a heavyweight approach: introduce WADL and do as JAX-WS does.
2. a lightweight approach: introduce Restlet-like client APIs and
streamline them.
Cheers,
ias
2007. 08. 20, ¿ÀÈÄ 1:39, Patrick Mueller ÀÛ¼º:
> 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/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>