Your question seems to reference two ways of consuming Web Services, both are independent of each other. Outbound Workflow actions have very specific requirements that this service will likely not meet if its been designed independently. So using Outbound Workflow may not be possible, unless you go back to the service provider to change. Otherwise you can choose to attempt to consume the Web Service directly via Apex and Apex Triggers, this approach does not utilise Salesforce Workflow, as it cannot call Apex.
Here is a summary of both just in case.
Outbound Workflow messages must conform to a predefined (by Salesforce) definition. You cannot have such Workflow actions confirm arbitrary Web Services unfortunately. This help topic describes how to obtain the WSDL (Web Service Definition Langauge file). You then need to give that to your service provider or build the web service yourself. For example .Net's VisualStudio will consume the WSDL and generate some stub code to enable you to complete the implementation of the web service.
Consuming the WSDL and calling via Apex. There are a few approaches to getting the best out of the WSDL2Apex tool (accessed under Develop > Apex Classes > Generate from WSDL) to generate your Apex code. It has some feature gaps but also some reasonable workarounds as well.
- Review the 'Apex Callouts' section of this article and the formal docs here.
- Review and pay close attention to the supported features here, it's not neccessarly a stopper, depending on the unsupported feature you need. Since you can edit either the WSDL file and/or the Apex generated code to workaround some. Which is sometimes not ideal, if your WSDL is changing often. However maybe prefferable to manually constructing the SOAP messages as per the last option below, which is more fragile and involving.
- Review and pay close attention to the understanding of the generated Apex code here.
Run the WSDL2Apex tool and editing the WSDL.
4.1 If you get errors such as XML Schema must be embedded. Download the WSDL (add ?wsdl to the end of a .Net svc URL) and attempt to edit locally before giving it back to the WSDL2Apex tool.
4.2. Often you can edit the WSDL without breaking the contract (structure of the XML packets) it describes. Such as copying (or flattening) in the XSD xsd:schema root tag into the WSDL file body using the wsdl:types element. As shown in the W3C standards doc here.
4.3. Some unsupported data types can be changed to xsd:string. You must then ensure that your Apex code populating the generated member variables of the classes formats things according to the expected data type.
- Once you get the Apex code generated, you may find it still does not work, for example if xsd:extension is used in the schema. However you can modify the generated Apex code to resolve this. The notes here describe how this has been done for the Salesforce Metadata API, but the same approach applies.
- Finally, if you cannot get the WSDL2Apex tool approach to work, but you can get hold of sample of the SOAP XML being transmitted to the service. You can manually make the Web Service call out using the the XML and HTTP features of Apex. As described here.