One thing to understand is that SOAP is a very flexible protocol that stablishes a set of possible scenarios, being RPC or not.

The common scenarios are:

• RPC/Encoded
• RPC/Literal
• Document/Literal Wrapped (used by MS .Net)
• Document/Literal

RPC and Document style services.

So what defines RPC? RPC is when you have a service endpoint that provides several operations, or "procedures" to be called with a set of parameters. This means that the first and only child of the "body" element of the SOAP message will be the name of the operation to be invoked.

This way, the "Document/Literal Wrapped" pattern used by MS .Net *is* a RPC style service, even if it uses the "document/literal" SOAP style, it in fact is a mess confusion, and in the end is completely similar to the RPC style.

The other aspect of the RPC style is how the parameters are encoded. The most standard way is using the "SOAP Encoding", which then results in the "RPC/Encoded" pattern. This encoding standard is fairly simple and usefull for most cases.

The "literal" encoding is supposed to handle an arbitrary XML document, that would be delivered as-is to the service. What is wrong in the "wrapped" implementation is that, in fact the encoding is not "literal", but it is an encoding defined by the .Net framework. It is just not documented, so they call it "literal", where it probably needed to be called ".Net encoding" which would make a more reasonable name "RPC/.Net".

The idea behind the literal is the possibility of having arbitrary XML documents as parameters. But what is most important to realise is that SOAP allows you to define a custom encoding, for instance, let's suppose your RPC method receives an RDF information. You can just declare it as "RPC/RDF", and your framework would be able to automatically serialize and desserialize between some RDF high-level object and the RDF document.

The Document style services, on the other hand are a kind of service which do not implement the semantics of a remote procedure call, this means that the message don't contain an "operation name". It simply will contain an arbitrary XML document inside the body, you may even have several elements below body.

This is important to implement services that would, for instance, register your Europass CV (which have a known XML schema), in a system. You don't need any RPC on that, you just need a SOAP service endpoint where the EuroPass CV may be published and that's all.

The encoding is also meaningfull in the Document style. While Document/Encoded is a standard that simply doesn't seem to make sense (as SOAP encoding is RPC related) you may implement several variations beyound the Document/Literal pattern, which is simply a way to implement a non-declarative arbitrary encoding. The more sane would be, in the above case, to declare it as "Document/EuroPass", as the framework implementations would then be able to automatically provide a higher-level representation of the europass cv instead of a plain XML document to the service

Toolkits

Here, the more important question is: are you going to serve or consume SOAP?

To consume SOAP you can use SOAP::Lite, SOAP::WSDL and XML::Compile::SOAP. SOAP::Lite is very efficient with "RPC/Encoded" services, althought SOAP::Lite code is very weird, the module just work. On the other hand, if you need to deal with Document style services and encoding different from "SOAP Encoding" SOAP::Lite will start to be a problem (I will refer "Document/Literal Wrapped" as "RPC/.Net" from now on).

SOAP::WSDL and XML::Compile::SOAP seems to be more smart to deal with different encodings. I didn't stressed any of the both, but they seem to solve your problems in most cases.

On the other hand, if you're going to serve SOAP, then you have only SOAP::Lite and Gantry at the moment, I'm working on Catalyst::Controller::SOAP to provide that in Catalyst as well, and I should release the first early version this week. The good part is that this module I'm working on will be oriented to the SOAP concepts as I presented earlier. It will be easier to implement different types of encodings.

But again, if you're going to serve anything different from "RPC/Encoded" SOAP::Lite will not be very helpfull.

Important Disclaimer

Even when there are a lot of articles saying that RPC/Encoded is bad, these articles are promoting the "just plain broken" "Document/Literal Wrapped" pattern. So, be a good guy and declare your style and encoding accordingly. If you're going to do RPC, use RPC style, if you're going to encode parameters to the procedures, declare your encoding. The easy path is: "stick to RPC/Encoded".