Web Services in 30 seconds:
Web Services are the hot new item in distributed systems. One of the big
problems with DCOM, CORBA, etc. is that they worked great on the platforms
they were designed for, but fell apart in an environment where there
were many different platforms trying to interoperate or when the
distribution crossed organizational boundaries.
In a "heterogeneous
environment" where you have Windows platforms, Unix platforms, IBM and so on
trying to talk to each other, you get data-mismatch problems and the data
transport and conversion becomes a nightmare (or a heinous bug.)
In distributed scenarios where the distribution crosses organizational
lines, you run into issues of traversing firewalls, authentication and the
basic mistrust of IT departments for anything that can move binary (and thus
potentially executable) code around their networks. Anyone who has deployed
a DCOM application knows what it's like trying to get everyone's permissions
aligned. My experience is that 90% of all DCOM installations end up
virtually switching off security because it's too hard to get right.
Web Services get around the distribution problem by using HTTP as a
transport and text as the medium of exchange. They get around data
conversion by making the text be XML, which allows services to return
arbitrarily complex structures and values all represented in plain, old text
which is re-constructed on the receiving end into a structure and data types
that make sense to the receiver. Security is handled by the same mechanisms
that are used to secure other web access.
Of course, random text flying around the network doesn't really help
anyone. So in an attempt to bring order out of chaos, a protocol was
devised. The protocol is SOAP and it specifies how to send a request and how
to interpret a response and how to pass error information, etc. As a first
approximation, it's fair to think of it as a sort of remote procedure call,
but it's important to remember that it isn't really that.
Think of web services as a web page for your computer. Imagine you browse
to a bank site and run their mortgage calculator to see if you can afford
that new summer place on the lake. You fill in a web form (price you're
paying, amount you put down, how many years you want the mortgage to run,
etc.) the bank site does the calculation on your behalf and then prints the
payment information on the page you're looking at. Web services are just
like that -- your application "browses" to the service location, sends an
XML request with information and the computer hosting the service does
something on your behalf then your application receives an XML reply with
the result. (There's even Google for computers -- it's called UDDI and it
lets you find services and bind to them.)
wsDice
This site hosts a web service called wsDice which has two methods available: RollDice and Shuffle.
It's not a very clever service -- I wrote it as an exercise while studying
for my MCSD certification so I could understand how these things work. But
the point is that it does work and illustrates some interesting things
besides my ability to use the Microsoft tools.
RollDice
RollDice simulates rolling dice (big surprise.) It presumes all the dice in a roll are the same, so when you call
it, you specify the low value of a single die, the high value and the number
of dice you want to roll. For example, to roll five six-sided dice you'd
specify
lowValue=1 highValue=6 numberOfDice=5
As a response, you'd get back
an array of five random integers, each between 1 and 6 (inclusive.) If you
ask for zero or a negative number of dice, or if you specify a low value
that's higher than the high value, RollDice will throw an error. The error
is a SOAP Exception and if you're using the SOAP protocol, your code can
respond to the exception.
To see a web form that uses the service,
click here.
The form uses web form validation controls, so it won't let you trigger the
SOAP exceptions.
Shuffle
Shuffle is similar to RollDice in a way -- you specify how many "cards"
you want shuffled, and it returns an integer array with numbers from 1 to <numberOfCards>
in random order within the array with no number repeating. If you wanted to
shuffle a deck of 52 cards, say, then you'd get a fifty-two element array
with the numbers 1 through 52 randomly distributed in it. If you ask to
shuffle zero or fewer cards, Shuffle will throw an error.
To see a web form that uses this service,
click here.
The role of services
It's important to note that RollDice and Shuffle don't actually have any
value by themselves. They just provide a service over the web
(get the picture?) They don't decide how many dice to roll or how many cards
to shuffle. They don't send back renderings of the dice or cards, nor do
they interpret the results. Rendering is the User Interface's job.
Evaluating the results is the Business Logic's job. RollDice and
Shuffle just provide randomization services.
In fact, I'm just leading you on by mentioning dice and cards. RollDice
returns an array of random integers between two boundary values where
repeats are allowed-- that has a lot of application. Shuffle returns an
array with a fixed number of elements randomly arranged. You could use that
to arrange any set of things that you wanted to appear exactly once -- like
questions on a practice exam, or the order or entrants in a race. Again, the
use of the data is Business Logic.
Why Services are Used
Services are another step along the path of component software. They
allow you to leverage someone else's code in your own product. The
dice-rolling algorithm really isn't that complex, so at first blush, it
looks like something that would only be good as a simple example. But, in
fact, there are reasons why even a dice-rolling service would be of value.
If you've ever played backgammon on line, for example, you know how
suspicious people are about dice. Wouldn't it be nice if you could
make it possible for a user to select his/her own trusted dice-rolling
service? With RPC, DCOM or CORBA, you have to pack a lot of disclaimers into
the conversation about doing that sort of thing. With web services, there
are fewer. (But, of course, there are some.)
How Services are Used
It's all well and good for me to explain RollDice and Shuffle to you, but
how are you actually going to use them? Do you have to hand-code a request
and try it a dozen times to get it just right? No. Web Services can describe
themselves in a way that makes it possible for your code to read the
description and build the proper structures to exchange information with the
services. The people who designed the mechanism even allowed for people to
get into the act -- want to see a service describe itself?
Click Here.
(You'll probably have to wait a few seconds while the page creates itself.
It's unlikely that it will be cached and waiting. ;-) )
You can register your service with a UDDI service so that people can
"discover" your service and use it. (To see the UDDI entry for
wsDice,
click here.) Now you can leverage other people's code
or they can leverage yours. Since services are self-describing, you can
integrate them into your code with fewer misunderstandings. Of course, if
you're looking for a valuable service, it's probably going to cost you
something, but that's what the internet is all about.
All of this is incredibly complex and if you're looking for alpha-geek
status, this is an area where you can learn all the little fiddly bits and
be very proud. But if your focus is on getting applications to customers,
then the good news is that there are frameworks and development tools that
make all of this virtually transparent. If you're a Windows guy, like I am,
you use the .Net Framework and Visual Studio .Net. If you're a unix guy, you
probably use some tool named after the author's pet iguana -- I don't care. The beauty is that you can
use my web service even if you're a beastly Mac programmer or a cyber-hermit
building HTML apps with a text editor, because HTTP, Web Services, SOAP, XML,
etc. are all standardized.
Q: How long did it take you to create wsDice, package and deploy it for
use on the Net?
A: About four hours using Visual Studio .Net
Q: What took you so long?
A: I had to figure out how my hosting company enabled me to allow code to
execute from a subdirectory. It's often the infrastructure issues that are
the roadblocks, not the technology. |
.jpg)
.jpg)
