I think the whole push behind doc/literal is to be "WS-I" conformant.  Because there 
is so much going on in the web services space -- some folks got together and decided 
that we should have a standard way of doing things which is certainly not a bad idea.  
At the simplest level, it's been decided that doc/literal is the way to go because 
schemas should be self-describing, i.e., you shouldn't have to interject any sort of 
encoding rules into the mix.  You tell your consumers that you expect a document that 
validates against schema x and that's as simple as it gets.  If anything, encoding 
only serves to muddy the waters (that said -- Axis seems to play much more nicely with 
rpc/encoded than it does with doc/literal).  Unfortunately, many toolkits out on the 
market are rpc-centric -- these were largely developed before the WS-I folk got into 
the mix and all these vendors had the rug yanked out from underneath them (though they 
should have supported doc/literal all along).

While there are people more qualified than I to enumerate the exact reasons why you 
might want to go doc/literal -- I think it will all boil down to a broader-range of 
interoperability.  

As a final note, if toolkits were doing their job correctly, you wouldn't have to 
worry about any of the rules ;)
Cory

-----Original Message-----
From: Paul Mackles [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 21, 2003 3:21 PM
To: '[EMAIL PROTECTED]'
Subject: The whole soap-encoding vs. doc/literal debate


Hi,

After lurking on this list for the last month or so as well as reading various 
articles, I convinced myself that I had better start using doc/literal encoding for 
the rpc style web service that I am working on - even though things were working 
pretty well using soap-encoding (using php and soap::lite on the client-side and java 
on the server-side). 

Not suprisingly, after switching to doc/literal encoding, I started getting different, 
not so desirable, results. Specifically, the java Maps I was passing from java to perl 
were no longer being deserialized as real perl hashes on the the perl-side. 

I still haven't figured out what I am doing wrong but before I torture myself anymore, 
I need somebody to tell me why I shouldn't just go back to using soap-encoding. I 
understand soap-encoding is vague in certain respects and makes life more difficult 
for the toolkit implementors but what about us folks who are just building apps? Why 
should we care? I know my WS works with soap::lite and I am pretty sure it will work 
with dotnet. Lacking any real world experience in using WS I am struggling with these 
questions. For what its worth, I noticed that both the amazon and google WS apis use 
soap-encoding - should I be taking any solace in that?

Thanks,
Paul

Reply via email to