A SOAP Document/Literal encoded file (a.k.a. SOAP_MSG) is just an XML file that can be processed by any XML processor and validated with any XML Schema validator, so it is fine to send to wm.tn:receive or better to send to your own entry point service via the soap/default handler which pulls out the document payload and sends just that to wm.tn:receive. See WmPublic pub.soap.utils for services that make this easy. Using the soap/default processor will do things like handle the Soap specific HTTP States, but is only needed if you are using a Soap Client, rather than just using a SOAP evelope and Document/Literal encoding for your message.
SOAP RPC messages use a special encoding (a.k.a Section 5 encoding from the SOAP “Spec” section). This means SOAP RPC documents can not be described by XML Schema - particularly there is a non-standard way of defining arrays, which require a special decoder and validator and a wrapper element that defines the RPC to invoke.
Also, the SOAP RPC model implies a point-to-point RPC, rather than a rich document passing model of ‘traditional’ XML business documents (which is the model of SOAP Message documents).
What does this mean?
SOAP Message encoded documents make sence to go to wm.tn:receive and future versions of IS and TN will add extra facilities to support SOAP header processing rules as standard headers emerge.
SOAP RPC documents need to go to the /soap/rpc handler which implements the Section 5 SOAP RPC decoding rules and uses the RPC ‘wrapper’ element QName to find which IS Service to invoke. One can define a Universal Name for an IS service using Developer to allow for an abstraction of QName from the IS service name. You can make the RPC map to wm.tn:receive or create your own entry point service that turns around and calls wm.tn:receive.
Note that the SOAP RPC decode maps many xsi:types to native Java types (other than String), which is a feature much better for RPC than for ‘traditional’ document processing.