Every morning I run through the woods to a great big New England farm that has been turned into a park and then make laps around the park. The park is about about a quarter mile away from the road and my running lap is about 3/4 of a mile. It is perfect for Teton and me to get a good workout and for me to think about development issues.

I must have been quite a site today gesticulating and muttering about object orientation and web services, because it's been on my mind lately, and I tend to think out loud when I run. You see me and your hear things like: "... clients expect we adhere to standards like SOAP ...", "... using the PL/SQL to do SOAP is a bad idea...". You might get the impression that I am crazy having an internal argument about nonsense.

If you're a developer, though, you will realize that my internal argument isn't crazy. So then what is it about? People like to confuse technologies. Oracle has a database for storing XML documents. I once had a project for the DoD where we converted SGML documents for maintaining an F14 aircraft into XML. Believe me, these documents were incredibly detailed and it was a fairly complex project. These documents were perfect candidates for storing in XML in an Oracle's XML database. That is because their actual type was XML.

I just had a conversation with an old colleague at a big, dysfunctional company where I used to work. The PL/SQL consultant that everyone hated except the boss just read about XML DB and using PL/SQL to use SOAP and decided that they could just support SOAP directly using the XML DB features and PL/SQL. Well, if you don't really think about it, then you can put two and two together and come up with five: "I can use the XML DB to implement SOAP and not have to worry about supporting a middle-tier J2EE layer."

Why is it such a bad idea to implement SOAP at the PL/SQL level? Several reasons. Look at the code:

    PROCEDURE generate_envelope(
       req IN OUT NOCOPY request, 
       env IN OUT NOCOPY VARCHAR2) AS
    BEGIN
      env := '
      <'||req.method||' '||req.namespace||'
      SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">'||
      req.body||'';
    END;
    

I told my friend to ask the consultant, "Why are you implementing the SOAP protocol yourself in PL/SQL as a set of concatenated strings when other people have done it for you and will give the code for free?" PL/SQL isn't object oriented and doesn't have a large, talented developer community writing frameworks like Apache Axis or even software companies writing things like Glue. So now you are in the business of keeping up with the ever-evolving SOAP protocol yourself. Of course, our friend the consultant isn't stupid, and I suspect is laughing all the way to the bank.

It is worth noting that this code example is client-side. At some level, I can appreciate the poor bastard that has to use PL/SQL and call a webservice on another database to get something, but I can't imagine how anyone could think that using PL/SQL to do SOAP on the server side is a good idea.

Second reason is that Oracle themselves recommends solve this problem quite differently. You use the standard J2EE framework that has emerged from the Jakarta project. The've called it the Oracle Application Developer Framework, but it's all there. If you look at where Oracle is going with 10i, you can see that they are embracing the standard XML handling methods that have arisen from the Java community process. Forget doing everything in the database. There are really good reasons why a middle tier layer in J2EE has become the standard.