Re: Web Services Solutions

From: richard@xxxxxxxxxxx

This allows your .Net or Java layers to remain very thin and mainly
related to UI work as you mentioned. I just prefer sprocs over the data
queue method because you can plumb directly to the program calls via the
database connection instead of using data queues.

Yeah, this is the part of the argument that's really weird to me.  You seem
to imply that data queues are somehow inferior to database connections, and
that they're more complex whereas it's really just the opposite.  I prefer
data queues over stored procedures because they're native to the operating
system and I don't have the unnecessary overhead and irrelevant syntax of
the database connection.  All modern architectures (everything from OO
languages to communications protocols to Web Services) use messages, and the
fastest and simplest method for sending messages is a queue.

Using a database connection to call a program is just wrapping an extra
layer of complexity around a very basic feature, and doesn't make a lot of
sense to me.  I suppose it could be helpful to someone who is only
comfortable with database connections because that's all they've ever used;
I could see where a stored procedure might make sense to someone coming from
a pure ODBC background. 

But I've spent my entire career designing multi-tiered systems, and I
understand how they work at the lowest level.  Over the years I've probably
used every protocol imaginable to get one machine to talk to another.  And
as it became clear that result sets weren't going to work as a way to
communicate between tiers, I've watched the attempt to graft what are in
effect remote procedure calls into SQL.  It hasn't been particularly pretty
(the old horse butt bag concept).  Me, I've never liked shoehorning a
communications protocol inside ODBC syntax, especially the part where you
code the user ID and password in the clear, or get it out of a text file.

Anyway, I'm still a proponent of KISS, and unless I need result sets I don't
need a database connection.  Instead I'll stick with queues; they've been
the communications technique of choice for 45 years or so, and they seem to
be doing fine.

Joe