Re: Development Trends in Web and Oracle

"Noons" <wizofoz2k_at_yahoo.com.au> wrote in message news:42358cc9$0$21006$5a62ac22_at_per-qv1-newsreader-01.iinet.net.au...
> 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?

yes, thank you.

>
> > 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...
>

well, tried to pull this out of the theoretical and into the realm wth XML is most usually encountered

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

gettting it off the wire and into your application... all the layers (ie. i'm the non-techie manager that just found out the biggest customer we've got just standardized on XML for file transfers -- what's your solution?)

>
> 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.
>

sorry, 'a comms program' sounds vague to me. -- how would you receive the document?
-- how would you extract the data out of the document?

> > 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.
>

(business manager talking here) we need a permanent record of the original received transmision. where do you propose storing it? how do you propose tracking it -- ie. if i'm looking at your extracted data through your interface, will you be able to show me the original document in case of customer dispute?
(please realize, i'm just trying to walk through a scenario, not trying skew this as justification for one technology over the other)

> > 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...
>

fair enough. becomes a question then of which layer to you want to do it in, then which tools are available, understood, and significantly performant

> > 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.
>

oh, please. let's call it 'one of my many customers' then. it's a simple use case that certainly fits into you more complex scenario -- just multply it by #customers and #formats

> 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.

Which is exactly what XML DB is designed to do. simply register the schema (once), then either create an XML resource from the XML Document via your favorite programming language, or just let the customer FTP the XML document directly into the database, or drag and drop it via a WebDav folder

Depending on how you register the schema, XML DB automaticaly extracts the data into object relational tables, which can be accessed directly and made the subect of constraints and triggers, or it simple stores the original document data in CLOBs (as advocated by a few in this thread) allowing access to the data elements via SQL, using XPATH expressions. FBI and hierarchical indexes are used for performance.

>
> 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...
>

XML DB supports schema evolution... although I'm not real familiar with the way that works.

However, the issue of schema change is unavoidable... no matter what your approach, if the partner changes the schema, you have to change your process to conform to the new version of the schema, and perhaps remain backward compatible with the old version(s). No matter what tool you choose.

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

Case studies and usage scenarios are a starting point for either further discussion or further analysis. You've nicely augmented the scenario, thank you.

++ mcs Received on Mon Mar 14 2005 - 07:50:30 CST