The document does describe how to do that. Generally you don’t need a custom soap processor unless you have something that the default processor cannot handle well, like some of the extended WS-I specs, security etc.
IS 6.5 (or older) will not generate a stub Flow service to provide a web service from a WSDL. However, you can use the Flow generated by the much-maligned web services connector (WSC) wizard to get you most of the way there.
In addition to generating Flow to consume a web service operation from a WSDL, the WSC will attempt to create document types from the “types” section of the WSDL. Those docs would be used as the input and output of a Flow providing a web service operation.
Inside the “provider Flow” you would have to perform the functions of a document / literal “wrapper” service as described in the post you cited (and others).
Creating or exposing web service operations from an existing WSDL is often called “WSDL-first”. When done well, WSDL-first represents a top-down approach in which Services, operations, messages and their underlying XML data structures are modeled before a single line of code to provide the Service is written.
WSDL-first can be contrasted with “tool-first” in which some development tool exposes a so-called “web service” usually at a method or function level of granularity much too fine to be useful at an enterprise level.
Based on published information, I believe that the upcoming 7.1 versions of IS and Developer will support WSDL-first.
Thanks for confirming my hypothesis about the document. While I have a very good understanding of “WSDL-First”, I have been trying to convince a few webMethods developers that it can be done.
I have no experience with webMethods per se, but have worked with WBI (when it was crossworlds) and most recently with eGate and JCAPS. As I said, I knew it could be done. The idea of reaching out to the members here was to validate what I have been saying so I can go back to the webMethods developers and show them that it CAN be done.