Re: my first web service

["Walden H. Leverich" <WaldenL@xxxxxxxxxxxxxxx>]

A web service can return any text you want it to (or binary w/DIME, but
we won't go there). It's not going to return a "result set" in the SQL
sense of the term, but there's no reason it couldn't return a list of
records. The rows could be a full-on XML representation:

<orders>
<order id=1 date='1/1/2009' customer='11111' />
<order id=2 date='1/1/2009' customer='22222' />
<order id=3 date='1/1/2009' customer='33333' />
<order id=4 date='1/1/2009' customer='44444' />
</orders>

Or the result could be just a list of comma separated text:

1, 1/1/2009, 1111
2, 1/1/2009, 2222
3, 1/1/2009, 3333
4, 1/1/2009, 4444

etc. It's up to you to represent the data in a way that can be consumed
by your customers.

As for security. There are several main schools of thought, and each one
has its merits and uses.

1) Don't secure it. Possibly acceptable in an internal network where you
tightly control both ends.
2) Add a web service to "login" to your system. That service takes a
secret (username/password) and returns a session id. Then every other
service takes the session id (usually as the first parm) and validates
it. Throwing if it's not valid.
3) Perform the same "session" management using cookies, or a similar
construct. This depends more on your deployment infrastructure.
4) Pass the shared secret (username/password) on each call. Then you
don't need to worry about sessions, you just validate the secret each
time.

There are also approaches using client-side certificates, but I've found
those to be more trouble then their worth.

-Walden