Most "web services" are just method calls that do little more than re-write input parameters into SQL, and return the result as XML!
Why not cut out the middle man, I say? I propose the ur-web-service, just deploy this one web service and then Declare Victory in your corporate web services strategy:
https://yourserver.com/db2xml?sql=<your urlencoded SQL here>
Returns (for example):
<Rows>
<Row type="string" name="first_name">Paul</Row>
<Row type="string" name="last_name">Ramsey</Row>
</Rows>
For security, pull the HTTP_AUTH_USER and password from the HTTP header and use those to create the database connection, that way all the security beyond simple access is handled by the existing database security layer.
I think this approach (let's call it the "brain dead approach") re-invents the minimum number of wheels while providing the maximum quantity of data access flexibility. Perhaps I should write a book; no, a pamphlet; no, a leaflet; no, a business card; on "implementing brain dead web services for the enterprise".
9 comments:
Screw XML. In the spirit of Abject-Oriented Programming, I want a response like:
200 OK
first_name | last_name
-----------+----------
Paul | Ramsey
(1 row)
Why not have an HTTP header that gets/sets the response format? You could wire up transactions using cookies or a query string parameter.
Wait... I think I'm kidding. I wonder if you could just use HTTP's "Connect" request method to drop out into a TCP tunnel like HTTPS uses.
This sounds a lot like a feature that was introduced in sql server 2000. I'm guessing other dbms had the same feature too.
http://msdn.microsoft.com/msdnmag/issues/0300/sql/
Although I always wondered why everyone is trying to abstract out the database. I spend most of my time trying to make everything look like a database so I can have one single tool to view the world. But I guess it boils down to what abstraction you are most comfortable with.
Right you are Regina, Microsoft is already all over this!
Ha ha, this is a bit hilarious to me, since I spent my working life abstracting away from the databases.
And you already know why, each customer wants to use their own database of choice with my applications.
The day when we'll have one single database to rule them all, or the day when the sql standard will extent to a point where I can write all my code to sit in the db and still be object oriented, portable without changes from one vendor to anther, and fast (not only in data extraction, but also in data crunching), that will be the day when people like me stop fighting to stay away from the db and we'll all leave in peace.
Up until then, unless you are building in-house apps where you are assured to hit just that dbms flavour, database dependende is a liabily and source of all kinds of technical pains (or commercial ones, when you lose a customer)
Well I have that problem too. But I do like the concept of the database (which lets face it is already a huge abstraction). In the end its just bytes and an ugly file system. I do like sql abstraction layer more than stuffing my data in a bulky object interface or xml parsing just because for must of my use-cases I do have less typing to do with just sql.
I do use light database abstraction layers a lot which for the most part compensate for the idiosyncracies between one dialect of sql and another, but of course not entirely compensate.
Oracle created the XSQL servlet way back when. It is very simple and thin layer on top of oracle database providing server-side XSLT and many other goodies. About as useful as a swiss army knife - I think it can be made to work on db other than oracle,
but works great if you have oracle.
Not open source, but hey that's not their thing. Maybe we need an open source equivalent.
XSQL looks good! Only thing I cannot see in the info page is how they handle authentication/access control. I really like the idea of delegating back to the database, so one access control layer handles it all.
XSQL? Not sure I see what the fuss is. Looks like XML tags wrapped around a normal parameterized SQL statement with, I assume, XML coming back from the DB. Cocoon has been doing this for years as well; and its effectively DB-independent. What subtleties am I missing?
Post a Comment