A Primer: Web Services for webMethods By Mark Carlson

---

An Introduction to Web Services

Web services technology involves exposing a service or functional component on one server so that a remote client application can invoke the service without knowing anything about how it is actually implemented.

Web services are described using the XML-based Web Services Descriptor Language (WSDL). WSDL files consist of two basic parts:

1. The XML schema that identifies the input and output signatures (parameters and data types) of the service
   
   
2. Bindings information identifying the protocols and server addresses used to call the service

Using publically available tools, a developer can refer to or import a WSDL file to generate programming code used to invoke the services. Microsoft .Net clients can invoke services created in Java and vice versa assuming that the consuming, or client, program can understand the publishing server’s WSDL file (more on that later).

The protocol for invoking web services is the Simple Object Access Protocol (SOAP). SOAP messages are XML messages that are usually sent over HTTP/S although the SOAP specification allows for messages to be sent using other protocols such as SMTP (email) or FTP.

---

webMethods Initial Support for WSDL Falls Short

When Integration Server 4.6 was released, it introduced native support for SOAP messages and enabled developers to generate WSDL files using the Developer tool. While this was a big improvement over the previous approach -- writing flow services to parse a SOAP document -- there were a few issues with the initial implementation.

These issues primarily related to the Developer tool's parsing of WSDL files at design time. When WSDL files were used to generate a web service connector -- a Flow service that invokes a web service -- there were often problems that resulted in inproperly defined records and incorrect Flow service code. Web services that returned results using arrays were particularly problematic. Another serious shortcoming was that WSDL files generated by Developer were sometimes not understandable by client programs.

Workarounds could usually be found for both types of problems, but often involved manually editing WSDL files or refactoring input or output signatures to avoid use of array types.

---

webMethods Achieves Complete Web Services Interoperability

To address these issues, webMethods released the "Web Service Pack". The Web Services Pack consists of the following products:

1. An Interoperability Service Pack (ISP) that includes IS 4.6 Service Pack 1 and which requires the Developer tool Service Pack 2. The ISP addresses many of the issues that hindered IS from consuming flow services built using other tools or having its services consumed by client programs written in other languages (e.g. Microsoft .Net). With the ISP, webMethods now claims "Complete Web service interoperability with Microsoft .NET, IBM WSTK/Axis and BEA Weblogic.".
   
   
2. A new Web Services Starter Package delivered as the WmEWS package. The WmEWS package contains several "quick start" tutorials in PDF format and examples for publishing and consuming web services using Microsoft .Net and Apache AXIS.
   
   
3. The Web Services Browser which allows a user to:
   
   
   • View an existing flow service as a web service
   • Generate default or custom WSDL for a flow service
   • Invoke that flow service as a web service
   • View the SOAP response document returned by the remote server
     
     
   The Web Services Browser illustrates a fact that I had missed in my first use of IS 4.6. Any flow service is immediately accessible as a web services with no additional work or coding! All the calling application needs to know is the correct format for the SOAP message.

Two of the more useful items in the starter package are the DisplayData generic SOAP client and the Web Services FAQ. Use the home page of your WmEWS package http://<serverhost>:<port>/WmEWS as a great starter point for accessing the Starter Package contents.

The Web Services Pack can be downloaded from the EWS Central section of the webMethods Advantage site or from http://evals.webmethods.com.

---

Potential Applications for Web Services

So why would you want to build or consume web services with webMethods Integration Server? Here a few of the more common usage scenarios:

• Expose existing webMethods integrations as web services. Most webMethods users have extensive portfolios of Enterprise integrations and flow services. These can now be quickly exposed to client programs or external partners with minimal incremental development.
  
  
• Expose functionality in existing legacy applications, CRM packages and ERP systems as web services. You can now leverage your existing webMethods integration expertise to expose existing application functionality as a web service.
  
  
• Allow legacy applications, CRM and ERP packages to consume web services. While the ERP and CRM vendors are aggressively working on tools to allow their products to consume web services, you can do this today by leveraging existing webMethods adapters and Integration Server.
  
  
• Consume web services in new or existing integrations. As component-based functionality becomes available as robust web services, it may be useful to incorporate those services inside of existing integrations.

In summary, webMethods has achieved a high degree of interoperability with other web services tools and has made it easier than ever before to create or consume web services using the Integration Server.

---

[1]  

Go Deeper on the Subject: The wMUsers Discussion Forums