Steve White wrote:
Jan,
On 7.08.08, Jan Ploski wrote:
Steve White wrote:
A user asked me, what are Web Services?
A web service is a procedure which can be invoked remotely using a set
of communication protocols prescribed by W3C.
Which communications protocols? Any protocol?
Hi Steve,
Not any protocols, just those endorsed by W3C. So CORBA or
language-specific RPC/RMI mechanisms do not qualify, for instance. HTTP
and SOAP and WS-anything do. The exact membership of this protocol set
is going to change tomorrow. As others have pointed out, "RESTful
services", which are really just plain old HTTP request-response dressed
up in new buzzwords also qualify as web services, probably just because
they rely on HTTP and HTTP means "web".
Yes, my explanation skims over a lot of technical detail, but when you
are asked this question by a user, it might actually be a good tactic to
just give a brief explanation. For we should ask ourselves a
meta-question: what is the purpose of this sought definition - when we
ask "what *is* a web service", what do we really want to do with the
answer? It depends on the context and individual needs, of course.
I think that is not what is usually meant by the term--it is somehow
more restrictive. But this is the question: how restrictive?
My impression is that the term "(web) service" is used in different
types of discourse. First, on a down-to-earth technical level - where my
proposed definition applies. Second, on an "architectural" level - where
the term refers to a metapher useful in structuring software systems.
However, I wouldn't bother explaining to a user this second meaning. It
would be like engaging in a discussion of what an object "is" in context
of oriented-oriented design. Unless a precise question is asked, no
precise answer can be given, and precise questions seldom start with
"what is ...".
In fact, any time two machines talk, effectively a procedure is being
called. So if the communications protocol is defined by the W3C, those
procedures are Web Services? I don't think so.
The implementor of client software must have an intent to invoke a
specific remote procedure (one with a specific name and parameters). So
low-level socket-based communication, which also qualifies as "machines
talking", would not be enough. Other than that, I do think that indeed
"if the communications protocol is defined by the W3C, those procedures
are Web Services".
To be even more exact, a "web service" is a *set* of topically related
procedures, much like a package or module in a traditional programming
language. But here too, I'd say that the simplified explanation (web
service = remotely invokable procedure) is good enough for someone
unfamiliar with the concept.
If you are familiar with
the RPC concept, web services are easily explained as one possible
implementation of this general concept.
For people who are familiar with RPC (as am I), that serves as a starting
point. But then the question is: How do Web Services differ from
other implementations of RPC?
The individual W3C specifications of course explain most of the gory
details. Whatever you pick from the standards in order to make the
definition more specific, you can always raise the question afterwards
"yes, but how does it differ from ..." For example, one could say that
web services are meant to be independent of programming languages or
that their deployment locations are supposed to be looked up through a
registry. But that's also true for CORBA. In the end, I don't think we
can or should inflate a definition of "web service" with such details,
especially if we consider the actual broad and rather unspecific usage
of the term.
An analogous situation might be asking "what is Java?". A possible
answer: "a popular programming language and a set of related
technologies". But how does it differ from other programming languages?
What do you want to know precisely? Go read the specification so-and-so
to find out.
For people not familiar with RPC... it isn't helpful.
I agree. However, RPC can be explained easily. Most people are (?)
familiar with the concept of "procedure" and can (?) imagine the
benefits of being able to invoke one across the network on another computer.
The standardized Web Services include
WS-Security
WS-Addressing
WS-Notification
WS-Reliability
WS-Transaction
These standards just describe the calling conventions and communication
protocols. But they don't specify any standardized web services and
certainly cannot be said to *be* web services themselves.
Right. How about this instead?
A client interacts with a Web Service by way of its interface.
(described for example by WSDL).
Some standardized Web Service interfaces include
WS-Security
WS-Addressing
WS-Notification
WS-Reliability
WS-Transaction
However, none of the documents at hand explain what "interface" means in
the context of Web Services.
I guess that's the next question.
It is better than the previous try, but overcomplicating. Now you have
not just a "web service", but also an "interface of a web service" to
explain, as if they were distinct separable entities. This leads down
the road of WS-jargon (endpoints, port types, etc.) No such dilemma
arises from my irreverent definition.
Best regards,
Jan Ploski
