The thing that many developers (IMHO) will find more complicated about doc/literal as opposed to an rpc/encoded scenario as its done today is that types must (for all intents and purposes) be specified in schema, rather than in Java (or C#, or whatever your "source" language is). That requires you to learn and understand the nuances of XML Schema, which are somewhat nontrivial.
That said, though, I think ultimately it's the best approach to take, in order to maximize the interoperability of your web service, which (if you think about it) is really the whole point in the first place. Ted Neward Author, Instructor, Presenter: Java and .NET http://www.neward.net/ted/weblog http://www.javageeks.com http://www.clrgeeks.com > -----Original Message----- > From: Stu Halloway (DevelopMentor) [mailto:[EMAIL PROTECTED] > Sent: Friday, May 30, 2003 11:04 AM > To: [EMAIL PROTECTED] > Subject: RE: Best practices question > > Hi Jim, > > << > It does seem to complicate the 'set up' of the call from the client side > when you use doc/literal. Doesn't the client have to manually construct > the > XML message to be passed to the server in the case of a doc/literal > service > call (when the xsd types required by the doc/literal service are > complex)? > >> > > There is no reason that doc/literal implementations need to be more > complex to program against than rpc/* implementations. This may be true > in Axis today, but that is more a statement about Axis than about doc > vs. rpc. > > If you look at the WSDL, doc/literal is actually simpler than > rpc/encoded. The types are completely specified by schema, which means > that schema is the single source of truth instead of having to combine > types/message parts/encoding to figure out what you are looking at. > > Yasser Shohoud wrote a nice article about doc/literal vs. rpc/literal > that you can find at [1] > > Regards, > Stu > > [1] > http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/d > nwebsrv/html/rpc_literal.asp > > Stuart Halloway > DevelopMentor > Guerrilla Java Web Services June 16! > http://www.develop.com/courses/gjws
