Deploying a SOAP Web service to a Web Services Adapter (for OpenEdge SOAP Web Services) instance
You can deploy a SOAP Web service to the context of any available WSA instance using the Web Service Mapping (WSM) file generated using ProxyGen. For more information on generating a WSM file, see OpenEdge Development: Web Services.
A deployed SOAP Web service receives its initial property values from the default.props file for the WSA instance. You can either change these default values before you deploy the SOAP Web service, or you can change the deployed SOAP Web service property values after you deploy the SOAP Web service. A SOAP Web service always deploys with a disabled status to prevent premature or unintended client access.
To deploy a SOAP Web service:
1. Click Resources in the management console menu. All resources managed by your console appear in the grid frame.
2. Filter or search for the WebServices Adapter broker instance where you want to deploy the SOAP Web service.
3. Click the WebServices Adapter broker instance. The WebServices Adapter details page appears.
4. In the Command and control section of the page, click Deploy.
5. Type the path and name of the WSM file for the SOAP Web service that you want to deploy.
6. Click Submit. Verify that the deployment information shown (and which is based on information in the WSM file) is correct. You can modify information in the following fields:
WSM Filename —The path and name of the WSM file.
Name — The name used to identify the SOAP Web service in the management console and to name the SOAP Web service files that are deployed to the WSA instance.
Web Service Namespace — Any value you choose to uniquely qualify the names for operations and parameters used to define the SOAP Web service.
SOAP Action — A string that the client application is required to place in the SOAPAction HTTP header when accessing a SOAP Web service hosted by the WSA instance. The SOAPAction HTTP header is required for all HTTP messages that carry SOAP messages and is used by intervening security servers (such as firewalls) to determine if each HTTP message is allowed to pass through to its destination. The default is a blank string, but it can be any string required by the intervening security servers on the network.
Append to SOAP Action — Indicates whether to append the specified SOAP Action value to any other SOAP Action values generated for the SOAP Web service messages by Web service clients.
WSDL Style/Use — Specifies the SOAP format to use when sending or receiving SOAP messages for this SOAP Web service. The value that you choose is dependent on what your anticipated SOAP Web service clients can support and can be any of the following: RPC/Encoded, RPC/Literal, and Document/Literal.
7. Click Submit to deploy the SOAP Web service with these settings. A confirmation message appears, and the WSM file name is identified in the Deployed Web Services section of the WSA instance's Details page.
You might need to document additional information about these settings, especially WSDL Style/Use, for use by SOAP Web service client developers. For more information, see the chapter on client requirements in OpenEdge Development: Web Services.
Deployment generates the following files in the WSA instance directory:
WebServiceFriendlyName.props — An XML file containing the current SOAP Web service property settings (initially set from default.props)
WebServiceFriendlyName.wsad — The Web Service Adapter Descriptor (WSAD) XML file that defines the SOAP Web service to the WSA instance
WebServiceFriendlyName.wsdl — The Web Services Description Language (WSDL) XML file that defines the SOAP Web service to potential SOAP Web service clients
For more information about these files, see OpenEdge Development: Web Services.
Caution: Once you deploy a SOAP Web service during development, you can change its definition and deployment information using a SOAP Web service update. However, once you deploy and enable a SOAP Web service for client access under production conditions, avoid making any changes to this information, as client implementations depend on its stability.
After production deployment, to make the same SOAP Web service available using different information (for example, to add a new operation or use a different WSDL Style/Use), deploy a new SOAP Web service with the new information, using a different SOAP Web service name in the same WSA context. You could also deploy the SOAP Web service to a different WSA context.
However, you can change the run-time properties of a deployed SOAP Web service at any time.
WSM Filename —The path and name of the WSM file.