A month ago I asked the same question and I have spent quite some time digging out the information needed to understand this also. The two best articles I found are these
The main differens between RPC and Document styles are that in RPC style all objects that you send back and forth are predetermind by a descriptive schema that lays elsewhere. In Document style, the object structure is included in the WSDL, so you can describe whatever you want (it must still confirm to a schema, but a more general).
For both RPC and Document style, you do not have to code any serializer/deserialiser if you use objects that follows plain old java code and Bean standards. Everything can be automatically produced with the wscompile tool delivered with Sun's JWSDP 1.5. In that case you can swap between RPC and Document very easy and with a minimal amout of changes in the client access code (I have just done this in our web service since .Net does not support RPC style). I guess there is more to it with Document style, more strengths you can use, but my knowledge of that is at a minimum.
The links above describes the differences in more details. Hope this helps.
Oh... I forgott. On the .Net side (if you are going to use that), in Visual Studio 2003, you point out a WSDL file and the program takes care of the code generation and compilation. You just use the generated classes and structures directly... Very easy. I guess there is some similar tools for the java side as well.
great responses and references, thank you!!
md5georg, I confirm some of the warnings regarding .NET compatibility. RPC/encoded seems to work flawlessly (for the simple cases), while RPC/literal doesn't seem to play nicely.
The Document Literal does work, just a different way of thinking (and extra object creation it seems on the Client side). Document Literal/Wrapped looks cool, but I do not see any support from the Java camp just yet on it.
One of my posts has to do with how to create RPC/Enc, RPC/lit, and Doc/lit webservices from the same EJB Bean, hopefully that will prove enlightening for all services. :-)
Again, thanks everyone!