----- Original Message ----- From: "Andrew Vardeman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, May 31, 2002 10:57 AM Subject: Re: AW: How do you pass an XML document between Axis and .Net Cl ient?
> comments inline > > > At 09:58 AM 5/31/2002 -0700, you wrote: > > >----- Original Message ----- > >From: "Andrew Vardeman" <[EMAIL PROTECTED]> > >To: <[EMAIL PROTECTED]> > >Sent: Friday, May 31, 2002 7:53 AM > >Subject: RE: AW: How do you pass an XML document between Axis and .Net Cl > >ient? > > > > > >Ack! > > > > >Maybe this shouldn't bug me since the whole point of Axis is you're not > > >supposed to care what's on the wire--but the notion of XML-encoding an > > >entire XML document so it can be passed as a string via RPC, when instead > > >you could just insert the literal document as the SOAP Body, makes no sense > > >to me. > > > > > > >well, imagine you are using a standard XML doc format, like say the 300+ > >page Job description format for printing (http://www.cip4.org/). And imagine > >that two years from now you might have to support the next version. > > > >if your endpoint has a method like submit(JDF descriptor) your runtime can > >handle future versions of the format in the same endpoint, by looking at the > >schema version of the payload and running with it. > > sure, but couldn't you get the same effect by dropping the XML document > down a level in the SOAP Body, say, under an "<JDF>" label? You could > define a request format like this: > > <docSubmission> > <descriptor>some descriptor</descriptor> > <JDF> > <blah_blah_blah /> > </JDF> > </docSubmission> > > I understand your point, which is that RPC is good for passing typed > parameters and you'll often want to pass some parameters along with an XML > document. But RPC certainly isn't *necessary* for this. I suppose the > argument would be that agreeing on a standard way of passing these > parameters is better than defining your own request schema for every web > service you write. I am with you in preferring doc/lit over RPC; I dont think RPC works well over high-latency low-reliability networks. > I guess I'm thinking of things at the SOAP spec level rather than the > specific implementation level, which is probably silly. Theoretically, > couldn't a SOAP toolkit could give you SAX events from the SOAP Body just > as easily as a complete DOM? I presume no toolkit actually does > this. When I first looked into SOAP and didn't know about Axis, .NET, > etc., I thought I would have to be constructing and disassembling SOAP > Envelopes manually, so I'm still kind of stuck on what *could* be done > according to the spec, as opposed to what is currently being done by > specific implementations. There is a lot to be said for SAX model or Pull model processing of inbound stuff. We have used it to start validating (and base-64 deconverting) content as it comes in; gives you a boost over long-haul connections, which helps meet those pesky SLA process time requriements. That certainly doesnt work well with RPC bound to methods implementation model, at least not in Java or C#, neither of which let you curry a function by calling it a parameter at a time.
