Good reply message Ted. Your "we don't know yet" answer is my take on Web Services too. I've been testing Web Service based systems for the past two years and the variety and complexity of systems is huge. It brings new meaning to the old words "your results may vary." hehe
Some of the things I have come to know about RPC and Document calls from my tests: 1) While RPC calls are convenient for software developers they do not scale well. I have seen several applications that use RPC to send complex objects across an HTTP connection. While testing these I increased the size of the object and found that the SOAP stacks decreased their ability to handle transactions. 2) Document-style calls provide scalability but are not well suited for complex data. I found examples where developers had misinterpreted the WSDL definition for the content of the response. I also found one case where a developers hand-coded XML parser method was slower than Xerces. It seems to me that .NET got scalability right over RPC-based Web Services. .NET uses document-style calls. I'm writing up my results over the next 2 weeks and will post my findings here. -Frank (http://www.pushtotest.com) Quoting Ted Neward <[EMAIL PROTECTED]>: > JAXRPC, as its name implies, seems to be intended for WebServices > that can > be described (and therefore be supported by tools and > code-generative > utilities) by WSDL, whereas JAXM deals much more directly with the > SOAP > packets themselves. I suppose an analogy here would be "do you want > to crack > the HTTP packets yourself, or let Struts do it for you?". More power > may be > available by writing directly against JAXM, particularly in areas > that are > not very well-defined by WSDL yet (oneway, solicit/notification, > asynchronous or non-blocking request/response calls, and so on), or > for > messages that cannot be described using WSDL 1.1 (such as SOAP w/ > attachments messages). > > This is, as was noted earlier, just one man's opinion, but a good > resource > for this kind of discussion is the Microsoft WebServices area on > MSDN; some > very high-powered guys (Tim Ewald manages that portion of MSDN, > Martin > Gudgin is on the W3C WSDL and SOAP committees, and of course Don Box > is deep > into this stuff, too, and so on) are writing on these kinds of > subjects. > Also, XMLHack seems to have some good articles on WSDL and SOAP and > "what's > it all mean" and so on. > > Finally, I think it's important to mention that these questions > you're > asking won't have a definitive answer--the truth of it is, we don't > know > yet. All of this stuff is so bleeding-edge, we haven't figured out > all of > the implications and/or consequences associated with it yet. It seems > to > take a few years (2 or 3) for us as an industry to figure out all the > warts, > so expect some backtracking and revisiting. Much of that is already > going on > with SOAP 1.2 and WSDL 1.2 already, but SOAP 1.2 *just* came out, and > WSDL > 1.2 is still very much on the drawing board. And even then, that > doesn't > mean we'll get it right the first time. > > Ted Neward > { .NET || Java } Author, Course Author, Instructor > http://www.javageeks.com > http://www.clrgeeks.com > > -----Original Message----- > From: Sam [mailto:[EMAIL PROTECTED]] > Sent: Sunday, July 21, 2002 23:21 > To: [EMAIL PROTECTED] > Subject: Re: rpc-literal and document-literal > > > Thats an interesting comparison you bring up. Which leads to > my next question > > Why would someone use the doc/literal style with JAX-RPC instead of > > JAXM ? > Doesnt the doc/literal seem redundant in JAX-RPC and doesnt JAXM do > > the same thing ? > > /s > > > > > Ted Neward wrote: > > > > It's really more of a "Zen" thing--rpc/encoded is the act of > replicating a > > call stack, whereas doc/literal is the act of passing messages, > much in > the > > same differentiation between RMI and JMS. In many ways, one can > look at > RMI > > and simply say, "Oh, that's easy, that's just passing an 'input' > message > to > > an endpoint, and receiving an 'output' message back." This in turn > begs > the > > question, what's the choice between RMI and JMS? Or, in short, > what's the > > choice about between any messaging-based application, and an > RPC-based > one? > > > > A messaging-based app usually offers more in the way of > flexibility--for > > example, a messaging-based app can do all sorts of "oneway" > actions > without > > requiring a response, and can offer store-and-forward kinds of > functionality > > as a result. (Think of the difference between email--messaging--and > a > phone > > call--RPC. One requires only some supporting plumbing to make sure > the > > message gets there; the other requires the same plumbing, but also > that > the > > recipient be there, ready to answer the incoming request and send > back a > > response.) The commensurate cost that goes with a messaging > application is > > the overhead of tying "request" and "response" > together--identifying that > > *this* response goes with *that* request five minutes ago, and so > on. (JMS > > has some headers they reserve for precisely this purpose.) > > > > Ted Neward > > {.NET || Java} Course Author & Instructor, DevelopMentor > > (http://www.develop.com) > > http://www.javageeks.com/tneward > > http://www.clrgeeks.com/tneward > > > > ----- Original Message ----- > > From: "Sam" <[EMAIL PROTECTED]> > > To: "axis" <[EMAIL PROTECTED]> > > Sent: Sunday, July 21, 2002 5:16 PM > > Subject: rpc-literal and document-literal > > > > > I was trying to think of the use cases where one would prefer > > > to use document-literal over rpc encoded and drew a blank. > > > > > > Can anyone highlight why an application would choose > > > document-literal or rpc-literal as the message format ? > > > > > > What would such a use case look like ? > > > > > > > > > Thanks > > > /s > > > > > > > -- http://www.PushToTest.com for free testing tools for testing Web Services
