On Mar 3, 2008, at 4:02 PM, Gabor Szokoli wrote:
> On 3/3/08, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>> Gabor Szokoli wrote:
>>> Jersey does everything I want, but somehow I'm unable to find it out
>>> myself from the documentation...
>>>
>>
>>
>> Sorry :-( we need a big picture arch document, linking to JavaDoc...
>
> Didn't mean to complain, the framework works great for the
> circumstances :-)
>
No problem, you make a valid point, we had productive meeting
yesterday with the GF documentation team so i hope we may be able to
have some better documentation at some point.
> We use it for machine consumed output for now, so I have not looked
> into the human readable output generation facilities of Jersey yet.
>
> My current theory of how things should be done (at least in our
> situation) involves a web service layer as an official interface, and
> then GUIs can be built on top of that.
> If the GUI is a java servlet, then it would be a nice optimisation to
> make the same service interface methods available over CORBA instead
> of HTTP/XML.
>
If it is the data serialization/parsing that is the issue then you
may still be able to use HTTP with alternative media types i.e. your
same service could expose the data as XML, as Binary XML, or Java RMI
serialization.
> The Imperial WS world has an appealing feature for this: you can make
> your web service provider class an EJB at the same time.
>
Note that the REST style and RPC are very different so your milage
may vary in support of both using one programming model. IMHO i don't
think it a good idea if you want to stick with the REST constraints
as what you may end up with is a lowest common denominator that is
essentially RPC over HTTP.
My view is that HTML is just one form of hypermedia XML/JSON are
others so potentially the same service can expose all three (i think
we are seeing that to some extent with Ajax where (X)HTML and
JavaScript are served up and that JavaScript makes HTTP requests back
to the server for data, usually in the JSON format). But i understand
why one may want to clearly separate HTML-based services from data-
based services.
Paul.