how does one talk to a web service? What makes something a webservice?

[Andrew]

I thought I knew what a web service was but now I am not so sure. I am
still learning java and come from a C++ background. The way people on
my project talk about web services reminds me of the C++ CORBA
servants I used to write. In which case we would use WSDL instead of
OMG IDL. But I have seen the code of some of the sruff they say is a
web service and it does not seem like a service to me. For a start,
there is no WSDL. There is a spring MVC controller responding to a URL
pattern. People can go to the URL and do admin type things from the
web page. That doesnt seem like a web service to me.

I have been asked to work on a process that has to talk to such a
'service'. How would be this be done from java please? Since AFAICS it
is just a web page I would have to talk HTML, post a request and get a
response etc. That doesn't seem the right way to use a service to me.
It seems far too low level. The equivalent in my old world would be
for someone to say that I would be talking to a CORBA service and then
I find I am expected to code it using raw sockets and working directly
with the low level CORBA data transmission protocol.

Regards,

Andrew Marlow

 

[Arne Vajhøj]

I thought I knew what a web service was but now I am not so sure. I am
still learning java and come from a C++ background. The way people on
my project talk about web services reminds me of the C++ CORBA
servants I used to write. In which case we would use WSDL instead of
OMG IDL. But I have seen the code of some of the sruff they say is a
web service and it does not seem like a service to me. For a start,
there is no WSDL. There is a spring MVC controller responding to a URL
pattern. People can go to the URL and do admin type things from the
web page. That doesnt seem like a web service to me.

I have been asked to work on a process that has to talk to such a
'service'. How would be this be done from java please? Since AFAICS it
is just a web page I would have to talk HTML, post a request and get a
response etc. That doesn't seem the right way to use a service to me.
It seems far too low level. The equivalent in my old world would be
for someone to say that I would be talking to a CORBA service and then
I find I am expected to code it using raw sockets and working directly
with the low level CORBA data transmission protocol.

A web service is:
program---web service
not:
browser---web app

If they do not expose a SOAP interface (documented with WSDL), then
you may need to use (Http)URLConnection or Jakarta HttpClient to
send requests.

Arne

 

[Tom Anderson]

I thought I knew what a web service was but now I am not so sure. I am
still learning java and come from a C++ background. The way people on my
project talk about web services reminds me of the C++ CORBA servants I
used to write. In which case we would use WSDL instead of OMG IDL. But I
have seen the code of some of the sruff they say is a web service and it
does not seem like a service to me. For a start, there is no WSDL. There
is a spring MVC controller responding to a URL pattern. People can go to
the URL and do admin type things from the web page. That doesnt seem
like a web service to me.

A web service is a website that has a machine-readable interface. That's
all. I could write a CGI script which would accept RSS documents via POST,
and return RSS documents translated into Esperanto, and that would be a
web service.

The conventional way to do web services is indeed virtually a straight
port of CORBA (without the sophistication, performance, richness, etc) -
an RPC mechanism with SOAP as the transport, WDSL as something like IDL,
then various other WS* and UDDI and whatnot providing facilities on top of
that.

Another major approach is REST, which is hip but widely misunderstood.
REST basically maps URLs to objects, and uses GET, PUT and DELETE to
transfer representations of their state between client and server in some
machine-readable format like XML or JSON, or even CSV (the POST method
gets used to, but has a bit of a variable meaning). Rather than have
method calls as such, you try to factor out sub-objects which can be GOT
and PUT.

From what you say, it sounds like your alleged web service may be RESTful.
Although if it's human-readable, then it may not be easily
machine-readable, which would mean it's not really REST. You can still
program to it, but it will involve a lot more pain in dealing with the
HTML.

I have been asked to work on a process that has to talk to such a
'service'. How would be this be done from java please? Since AFAICS it
is just a web page I would have to talk HTML, post a request and get a
response etc. That doesn't seem the right way to use a service to me. It
seems far too low level. The equivalent in my old world would be for
someone to say that I would be talking to a CORBA service and then I
find I am expected to code it using raw sockets and working directly
with the low level CORBA data transmission protocol.

There isn't the level of tool support around REST that there is around the
SOAP stack. But then it's not clear it's needed, because REST is so simple
- you form a URL, download it, stick the XML in a parser, and you're away.
If the XML is complicated, you could use JAXB to turn it into objects.

tom

 

[Andrew]

A web service is:
   program---web service
not:
   browser---web app

If they do not expose a SOAP interface (documented with WSDL), then
you may need to use (Http)URLConnection or Jakarta HttpClient to
send requests.

Arne

There is no WSDL. I think they are expecting HttpClient to be used. I
don't call that a web service.

 

[Lew]

There is no WSDL. I think they are expecting HttpClient to be used. I
don't call that a web service.

WSDL, indeed, SOAP are not essential to web services. They're just the latest
rage for implementation of web services.

A web service is simply a service that is invoked via the web.

 

[Mike Schilling]

There isn't the level of tool support around REST that there is
around the SOAP stack. But then it's not clear it's needed, because
REST is so simple - you form a URL, download it, stick the XML in a
parser, and you're away.

Of course, one the REST folks decide they need security, or transports
other than HTTP, or standard error handling, or to interpret their XML
representations as objects, or to model things that don't map neatly
to virtual file systems, it'll be fun to see REST get more and more
complex until the next "But this is so much simpler" approach emerges.

 

[Tom Anderson]

Of course, one the REST folks decide they need security, or transports
other than HTTP, or standard error handling, or to interpret their XML
representations as objects, or to model things that don't map neatly to
virtual file systems, it'll be fun to see REST get more and more complex
until the next "But this is so much simpler" approach emerges.

There's some truth in that. But they'd have to really, really **** it up
before it was overcomplicated as the SOAP stack.

Turning to specifics, though:

- What security do you mean other than HTTPS? Roles and stuff?

- What transports other than HTTP? If they're so important, why isn't
anyone using SOAP over them? There are a vanishingly small number of uses
of SOAP over email, and some SOAP over JMS, but nothing else in any
serious way.

- Standard error handling sounds interesting; it's true that HTTP error
codes aren't exactly a rich vocabulary. What does SOAP have?

- The question of representing XML as objects is a red herring. REST moves
XML (or JSON or whatever). What you do with that XML is up to you, and
although it does need to be dealt with, the way that's done doesn't need
to be uniform across clients, because the interface itself is defined in
terms of the XML.

- REST has nothing to do with virtual file systems. You're confusing
meaningful URLs with REST - they're actually *completely* unrelated. A lot
of people thing REST means urls.th.at/look/like/this, but that's mistaken.
In REST as defined in Fielding's work, URLs are opaque - you could write a
REST API in which all the URLs looked like /api/d056889d45 and it would
still be REST. In Fielding-approved REST, you never construct URLs, you
always obtain them from some resource you've been served (i think the idea
is called 'hyperlinks', you may have heard of it), so their structure is
never relevant.

tom

 

[Mike Schilling]

There's some truth in that. But they'd have to really, really ****
it
up before it was overcomplicated as the SOAP stack.

What's so complicated about SOAP?

Turning to specifics, though:

- What security do you mean other than HTTPS? Roles and stuff?

There's lots of reasons to do application-level security instead of
transport level. Roles is one. Another is to maintain a security
context across routers. A third is to map users across security
realms.

- What transports other than HTTP? If they're so important, why
isn't
anyone using SOAP over them? There are a vanishingly small number of
uses of SOAP over email, and some SOAP over JMS, but nothing else in
any serious way.

SOAP over JMS is used on a significant number of intranets.
Transactions that don't fail because one node is down can be crucial.

- Standard error handling sounds interesting; it's true that HTTP
error codes aren't exactly a rich vocabulary. What does SOAP have?

Faults, which contian arbitrary amounts of user-defied conent and map
naturally to exceptions.

- The question of representing XML as objects is a red herring. REST
moves XML (or JSON or whatever). What you do with that XML is up to
you, and although it does need to be dealt with, the way that's done
doesn't need to be uniform across clients, because the interface
itself is defined in terms of the XML.

Which makes it difficult to map the XML to programming language
constucts, or to generate or verify programmatically.

- REST has nothing to do with virtual file systems. You're confusing
meaningful URLs with REST - they're actually *completely* unrelated.
A lot of people thing REST means urls.th.at/look/like/this, but
that's mistaken. In REST as defined in Fielding's work, URLs are
opaque - you could write a REST API in which all the URLs looked
like
/api/d056889d45 and it would still be REST. In Fielding-approved
REST, you never construct URLs, you always obtain them from some
resource you've been served (i think the idea is called
'hyperlinks',
you may have heard of it), so their structure is never relevant.

Sure, but the notion that all you'd ever want to do with them is look
them up, GET them and PUT them amounts to it being a hyperlinked file
system. Many applications are more interesting than that.

 

[Arved Sandstrom]

WSDL, indeed, SOAP are not essential to web services. They're just the
latest rage for implementation of web services.

A web service is simply a service that is invoked via the web.

The introduction to http://en.wikipedia.org/wiki/Web_services explains
it quite well, actually. The key sentence there is the very first one,
specifically the phrase "machine to machine interaction".

AHS

 

[Lew]

What's so complicated about SOAP?

There's lots of reasons to do application-level security instead of
transport level. Roles is one. Another is to maintain a security
context across routers. A third is to map users across security
realms.

Digital signatures, message digests, ...

Application-level security can be most useful, and is orthogonal to transport
security. HTTPS, for example, cannot prove authenticity of origin nor provide
non-repudiability, particularly across security realms and routers as Mike
pointed out.

SOAP over JMS is used on a significant number of intranets.
Transactions that don't fail because one node is down can be crucial.

I've been involved in projects that do SOAP over JMS (e.g., IBM MQ).

Nice work when you can get it. Big budgets, steady work.

Faults, which contian arbitrary amounts of user-defied conent and map
naturally to exceptions.

I've done a bit of SOAP programming in Java, although I don't consider myself
expert. I found the modeling of messages to code to be pretty
straightforward, albeit somewhat trickier when one wants to be compatible for
clients across more than one programming domain (C# and Java, in my case).

 

[Arne Vajhøj]

There is no WSDL. I think they are expecting HttpClient to be used. I
don't call that a web service.

It can still be a web service.

If it expects and returns XML I would still consider it a
web service.

But if it expects form input and returns HTML; then it is not
a web service.

Arne

 

[Arne Vajhøj]

WSDL, indeed, SOAP are not essential to web services. They're just the
latest rage for implementation of web services.

REST is the latest.

SOAP was 5 the 5 years ago.

A web service is simply a service that is invoked via the web.

Only if you by service imply program-program and by web includes
intranet.

Arne

 

[Richard Maher]

Hi Arne,

Holiday/Busy lately?

It can still be a web service.

If it expects and returns XML I would still consider it a
web service.

How 'bout JSON? WebSockets? Binary?

But if it expects form input and returns HTML; then it is not
a web service.

Arne

Cheers Richard Maher

PS. How many people have seen a serious WS-Security implementation as
opposed to poking an application-specific Username/Password into the SOAP
headers or an XML variable? (Still slightly more than have seen a serious or
even working WS-AT implementation)

 

[Donkey Hottie]

PS. How many people have seen a serious WS-Security
implementation as opposed to poking an
application-specific Username/Password into the SOAP
headers or an XML variable? (Still slightly more than
have seen a serious or even working WS-AT implementation)

Define 'serious' WS-Security implemetation.

I have implemented WS-Security with WSS4J in Java and the tools provided by
..Net 2.0 and .Net 3.0 in my SOAP projects. So I have used only WS-Security,
although only with password token.

Is that serious? At least it was easy.

 

[RedGrittyBrick]

PS. How many people have seen a serious WS-Security implementation as
opposed to poking an application-specific Username/Password into the SOAP
headers or an XML variable?

With PKCS12 certificate based digital signatures? Yes.

 

[Arne Vajhøj]

How 'bout JSON?

It does not have to be XML. It could be JSON. Or it could be CSV.

Typical JSON is used in AJAX context.

Whether AJAX calls for data are web services calls or just part
of a web app is debatable.

I would consider the calls from a RichFaces web app to be
part of the web app, but calls from a GWT app to be web service
calls.

WebSockets?

WebSockets is transport not content. I think we will need to
see some usage before we decide on whether it is a candidate
for web services.

Web services does not have to be over HTTP.

> Binary?

Possible, but there is a fundamental conflict between the web
portability and binary format.

PS. How many people have seen a serious WS-Security implementation as
opposed to poking an application-specific Username/Password into the SOAP
headers or an XML variable?

I have seen both.

Arne

 

[Arne Vajhøj]

Another major approach is REST, which is hip but widely misunderstood.
REST basically maps URLs to objects, and uses GET, PUT and DELETE to
transfer representations of their state between client and server in
some machine-readable format like XML or JSON, or even CSV (the POST
method gets used to, but has a bit of a variable meaning). Rather than
have method calls as such, you try to factor out sub-objects which can
be GOT and PUT.

It is:

POST = create
GET = read
PUT = update
DELETE = delete

There isn't the level of tool support around REST that there is around
the SOAP stack. But then it's not clear it's needed, because REST is so
simple - you form a URL, download it, stick the XML in a parser, and
you're away.

If writing the code to do the work is simple, then most things
are simple.

If the XML is complicated, you could use JAXB to turn it
into objects.

Yep.

But then it is just the same as SOAP - just using xjc instead of
WSDL2Java.

Arne

 

[Arne Vajhøj]

There's some truth in that. But they'd have to really, really **** it up
before it was overcomplicated as the SOAP stack.

Turning to specifics, though:

- What security do you mean other than HTTPS? Roles and stuff?

The usual: encryption and signing.

HTTPS is not truly end to end.

- What transports other than HTTP? If they're so important, why isn't
anyone using SOAP over them? There are a vanishingly small number of
uses of SOAP over email, and some SOAP over JMS, but nothing else in any
serious way.

That is two.

- Standard error handling sounds interesting; it's true that HTTP error
codes aren't exactly a rich vocabulary. What does SOAP have?

Exceptions/SOAP fault.

- The question of representing XML as objects is a red herring. REST
moves XML (or JSON or whatever). What you do with that XML is up to you,
and although it does need to be dealt with, the way that's done doesn't
need to be uniform across clients, because the interface itself is
defined in terms of the XML.

Since when has it been an advantage that semantics are not
well defined?

XML and a schema is absolutely necessary if it has to be structured.

- REST has nothing to do with virtual file systems. You're confusing
meaningful URLs with REST - they're actually *completely* unrelated. A
lot of people thing REST means urls.th.at/look/like/this, but that's
mistaken. In REST as defined in Fielding's work, URLs are opaque - you
could write a REST API in which all the URLs looked like /api/d056889d45
and it would still be REST. In Fielding-approved REST, you never
construct URLs, you always obtain them from some resource you've been
served (i think the idea is called 'hyperlinks', you may have heard of
it), so their structure is never relevant.

Again there is a difference between what is sufficient to be REST and
what is necessary to work well.

A structure for URL is necessary if it has to be structured.

In practice that means hierarchical.

Which can be considered a virtual file system.

Arne

 

[Owen Jacobson]

- REST has nothing to do with virtual file systems. You're confusing
meaningful URLs with REST - they're actually *completely* unrelated. A
lot of people thing REST means urls.th.at/look/like/this, but that's
mistaken. (snip)
In Fielding-approved REST, you never construct URLs, you always obtain
them from some resource you've been served (i think the idea is called
'hyperlinks', you may have heard of it), so their structure is never
relevant.

I've cut the rest because I want to talk about this theme briefly.
Tom's right; in a hyperlink-oriented structure, you navigate from some
set of root links to the data you want, rather than constructing URLs.
However, constructible, cleanly-structured URLs are an important human
factors element. Human-readable and -constructable URLs allow long-time
users of an application to skip straight to portions of a service that
they want to use, and they can be used to cut corners when it's useful
to do so in client applications and mashups.

This is something the W3C guys have been banging on about, somewhat
futilely, for years (http://www.w3.org/Provider/Style/URI explains part
of their rationale, and goes further to cover other good ideas, like
removing file extensions and other implementation details from the URI
namespace), so it's gratifying that people are starting to figure it
out on their own.

-o