web services and databases
. I just finished reading James Strachan's web services and databases paper. It's a cool idea, and what I really thing "W/web S/services" were created for. But...
For all the nice bullet points in the "What about databases?" section, I keep thinking "Well, for this change/implementation someone has to program the web service that will be providing the data." Am I just missing something? Granted, seperating out the data collection from the application is a good thing, but this doesn't eliminate the work. And this is the implication I get from James's paper: that implementing your app on top of a web service would get rid of work.
And what about update/insert/delete? Of course, the web service does the actual job of updating the datastore, but how do you inform it? If we're using a course-grained approach, do you want to send the whole grain back just to changing the spelling of one word? Or is the Read a course-grain and Write is fine-grained? This reminds me of some AOP-based implementation that Ricard was going on about a few weeks ago. [Vanity Foul]
My intention wasn't to suggest that the web services approach would avoid work, just that it would provide a universal communication platform that would provide a cross-language and cross-technology mechanism for working with enterprise data. Both course grained and fine grained operations could be supported; the web services can do whatever you like. e.g. you could have a changeNameSpelling service (to use your example) if thats what your application wants t do. Or a 'here's a big blob of XML please insert it' service.
The other nice thing is it simplifies your techical architecture. There's no real difference between working with 'just' persistent data or working with 'services' like google searches. Its all just web services. To use a J2EE analogy, a client wouldn't see a difference between a remote Session Bean or a remote Entity Bean, they are all just web services.
I guess I was mostly focussing on the client side. Right now just on the Java platform we have a plethora of different APIs and mechanisms for dealing with persistent data (JDBC, JDO, CMP and gazillions of others). Using a web services to work with persitent data will enable a simplfied REST-ful way to approach persistence. This would allow us to implement caching and load balancing easily while isolating the different persistent mechanisms inside the web service implementations.
Here's another way to think of it. Many relational databases support stored procedures. They are often quite simple, glorified functions that hide some of the physical details of the database from developers. Also they are typically very proprietary. Often the DBA will create stored procedures to bridge the physical database to the application developers needs. However stored procedures can be a little too simple and low level (tyipically taking simple arguments and returning one or more result sets).
So think of web services as a way to get the beneift of stored procedures but in a more flexible and powerful way while avoiding lockin to the database vendors.
To implement the web services we can use any technology that gets the job done. So if you have an Oracle database then you could use something like XSQL to generate XML or consume XML and perform insert/update/delete operations. Increasingly the database vendors themselves may start implementing web services to change database. Or there are many other technologies you could use on the server side.
So from a database perspective web services could become the new replacement for stored procedures.
11:42:48 AM 
|
