Re: Development Trends in Web and Oracle

Mark C. Stock apparently said,on my timestamp of 14/03/2005 10:46 PM:

>
> http://www.oracle.com/technology/sample_code/tech/xml/xmldb/XDBBasicDemo.zip
> http://www.oracle.com/technology/sample_code/tech/xml/xmldb/XDBBasicDemo.pdf

Thanks, Mark. Good stuff there.

> Please describe your preferred architecture for the following typical
> scenario:
>
> Customer X generates XML purchase orders (format non-negotiable, we are one
> of 3000 vendors that receive the same format)
> System R (which we are architecting and have full control over) receives the
> XML document electronically, fulfills it, and sends an XML response.
>
> What would you use for processing the incoming XML document?
> How would you keep an official record of the customer's order?
> What would you use to extract the data from the incoming document?
> What would you use to generate the response document?

Very good example.
If I may venture a solution?

 > Customer X generates XML purchase orders (format non-negotiable, we are one  > of 3000 vendors that receive the same format)

Well, if someone WANTS to talk esperantu I have to talk esperantu, don't I? I thought we were talking about CHOICE. As soon as you throw in "non-negotiable", well...

 > What would you use for processing the incoming XML document?

I hope that the remaining questions describe the "for processing"? Because to just say "for processing" means exactly squat. Unless you meant "capturing the message" itself, in which case it'd have to be a comms program.

 > How would you keep an official record of the customer's order?

In a relational database schema, after extracting the data off the XML message/document. Format highly contingent on the requirements of the application, of course.

 > What would you use to extract the data from the incoming document?

Given that it is XML, I'd hope some form of XML schema would tell me what is in the document and where. Presumably, the client would send me the schema beforehand. To extract the data given the schema, there is a multitude of little parsers and libraries that can do that. Oh sorry: if you are talking Java, it's "classes". Not libraries...

 > What would you use to generate the response document?

Assuming I had done whatever with the data and got enough results for a response, it would have to be formatted according to the schema once again. Another use for a parser utility or library. Er, "class".

In summary:

The example is rigged, of course. There is no such thing as "one customer demands XML" in real life. Much more likely, you have HEAPS of customers, EACH with its own requirements. And even more likely: EACH customer will have DIFFERENT requirements, depending on how far down their own evolution they are.

And of course I could use Oracle XDB to do all the non-database XML transformation steps described above.

However, the only place (in THIS example!!!) where Oracle is desirable is in storing the "official record" for future reference. Which you can do a lot faster, more efficiently and more reliably if you use the native Oracle relational db and simply write a "persistence" class that picks up the data AFTER parsing and plonks it in a suitable relational schema.

One thing this much more desirable approach avoids: what happens if you do it all in Oracle XDB and 6 months down the line the client sends you another xsd file with a new schema? What do you do with the old one and its data? You write an xsl for each change to reduce the data to a common format? What if you have 1000 clients, each with its own multiple schemas and or demands? You have a "XML-table/per/client"? Good luck with the cost of maintaining all that jazz...

You see, real life is ALWAYS different from case studies!

-- 
Cheers
Nuno Souto
in sunny Sydney, Australia
wizofoz2k_at_yahoo.com.au.nospam