The heart of 4S4C is the dispatcher, this component does the work of taking the text of the SOAP request, parsing it, creating the correct component, building the call stack, making the method call, and finally building the response text.
The component uses the SAX2 Parser from Apache's Xerces-C for parsing the request XML. The call stack and method call is all driven using the type library definition of the interface.
The HTTP and SMTP listener are simple pieces of code which grab the request, call the dispatcher and return the results, the ASP listener is 13 lines of VBScript, whilst the SMTP listener is about 90 lines of C++. If you wanted to support other transports besides those provided you should have little trouble writing the transport code.
interface IDispatcher : IUnknown { HRESULT Go ( [in] BSTR soapRequestXML, [in] BSTR ProgID, [in] BSTR InterfaceIID, [out,retval] BSTR * soapResponseXML ) ; }; interface IDispatcher2 : IDispatcher { HRESULT ExecuteWithConfig ( [in] BSTR soapRequestXML, [in] IConfigFactory * pConfig, [out,retval] BSTR * soapResponseXML ) ; }; interface IDispatcher3 : IDispatcher2 { HRESULT ExecuteWithConfig2 ( [in] VARIANT soapRequest, [in] IConfigFactory * pConfig, [in,out] VARIANT * Faulted, [out,retval] VARIANT *soapResponseXML ) ; };IDispatcher::Go is the pre 1.2 method for invoking requests, it takes the text of the SOAP request, along with the Prog-ID and stringified IID of the component to invoke. IDispatcher2::ExecuteWithConfig is the 1.2 -> 1.3.2 version. 1.3.3 onwards uses IDispatcher3, and this is the prefered interface to use. soapRequest is expected to be an array of bytes that represent the request, this allows the dispatcher component to correctly handle character encoding issues, the response is an array of bytes in UTF-8 encoding. Faulted will be set to VARIANT_TRUE if the response is a SOAP Fault, this allows the transport level code, to correctly set a transport level fault if needed (in HTTP this flag should be used to set the HTTP status code to 500 for faults).