Designer 10.7 | webMethods Service Development Help | Working with Web Services | About Consumer Web Service Descriptors | Creating a Consumer Web Service Descriptor
 
Creating a Consumer Web Service Descriptor
 
Supporting Elements for a Consumer Web Service Descriptor
You can create a consumer WSD from a WSDL document accessible via a URL, a WSDL document in a UDDI registry, or a service asset in CentraSite.
*You must have Write access to the folder in which you want to store the consumer web service descriptor.
*If you are creating a consumer web service descriptor from a WSDL located on a website, if the website on which the document resides is password protected, you must download the WSDL document to your local file system and then create the consumer web service descriptor.
*If the URL for the WSDL contains special characters that need to be encoded, specify the encoding using the Encoding for WSDL URL option in the Web Service Descriptor Editor Preferences page.
*To create a consumer web service descriptor from a service asset in CentraSite, Designer must be configured to connect to CentraSite.
*You can also create a consumer web service descriptor from a service asset in CentraSite by dragging and dropping the service asset from the Registry Explorer view into Package Navigator view. Designer prompts you for a name for the web service descriptor and prompts you to indicate whether you want to create a consumer or provider web service descriptor.
*To create a consumer web service descriptor from a web service in a UDDI registry, Designer must be configured to connect to that UDDI registry.
*You can specify whether Integration Server enforces strict, lax, or no content model compliance when generating IS document types from the XML Schema definition contained or referenced in the WSDL document. Content models provide a formal description of the structure and allowed content for a complex type. The type of compliance that you specify can affect whether Integration Server generates an IS document type from a particular XML Schema definition successfully.
*Do not create a consumer web service descriptor from a WSDL that specifies RPC-Encoded, contains attributes in its operation signature, and/or has complex type definitions with mixed content. Integration Server might successfully create a web service descriptor from such WSDLs. However, the web service descriptor may exhibit unexpected runtime behavior.
*To create a consumer web service descriptor
1. In Package Navigator view, click File > New > Web Service Descriptor.
2. In the New Web Service Descriptor dialog box, select the folder in which you want to save the consumer web service descriptor. Click Next.
3. In the Element Name field, specify a name for the consumer WSD using any combination of letters, numbers, and/or the underscore character. Click Next.
4. Under Create web service descriptor as, select Consumer (Outbound Request).
5. Under Web service source, select WSDL. Click Next.
6. Under Source location, do one of the following:
Select...
To generate a consumer web service descriptor from...
CentraSite
A service asset in CentraSite
File/URL
A WSDL document that resides on the file system or on the Internet.
UDDI
A WSDL document in a UDDI registry
7. If you specified CentraSite as the source, under Select web service from CentraSite, select the service asset in CentraSite that you want to use to create the web service descriptor. Click Next.
Designer filters the contents of the Services folder to display only service assets that are web services.
If Designer is not configured to connect to CentraSite, Designer displays the CentraSite > Connections preference page and prompts you to configure a connection to CentraSite.
8. If you specified File/URL as the source, do one of the following:
*Enter the URL for the WSDL document. The URL should begin with http:// or https://. Click Next
*Click Browse to navigate to and select a WSDL document on your local file system. Click Next
9. If you specified UDDI as the source, under Select web service from UDDI Registry, select the web service from the UDDI registry. Click Next.
If Designer is not currently connected to a UDDI registry, the Open UDDI Registry Session dialog box appears. Enter the details to connect to the UDDI registry and click Finish.
10. Under Content model compliance, select one of the following to indicate how strictly Integration Server enforces content model compliance when creating IS document types from the XML Schema definition in the WSDL document.
Select...
To...
Strict
Generate the IS document type only if Integration Server can represent the content models defined in the XML Schema definition correctly. Document type generation fails if Integration Server cannot accurately represent the content models in the source XML Schema definition.
Currently, Integration Server does not support repeating model groups, nested model groups, or the any attribute. If you select strict compliance, Integration Server does not generate an IS document type from any XML schema definition that contains those items.
Note:
If Integration Server cannot generate an IS document type that complies with the content model in the XML schema definition in the WSDL document, Integration Server will not generate the consumer web service descriptor.
Lax
When possible, generate an IS document type that correctly represents the content models for the complex types defined in the XML schema definition from the WSDL document. If Integration Server cannot correctly represent the content model in the XML Schema definition in the resulting IS document type, Integration Server generates the IS document type using a compliance mode of None.
When you select lax compliance, Integration Server will generate the IS document type even if the content models in the XML schema definition cannot be represented correctly.
None
Generate an IS document type that does not necessarily represent or maintain the content models in the source XML Schema definition.
When compliance is set to none, Integration Server generates IS document types the same way they were generated in Integration Server releases prior to version 8.2.
11. Under Document type generation, select the Enable MTOM streaming for elements of type base64Binary check box if you want elements declared to be of type base64Binary in the WSDL or schema to be enabled for streaming of MTOM attachments. For more information about MTOM streaming for web services, see the Web Services Developer’s Guide.
12. If you want to use the Xerces Java parser to validate any schema elements in the WSDL document or any referenced XML Schema definitions before creating the web service descriptor, select the Validate schema using Xerces check box.
Note:Integration Server uses an internal schema parser to validate the schemas in or referenced by a WSDL document. However, the Xerces Java parser provides stricter validation than the Integration Server internal schema parser. As a result, some schemas that the internal schema parser considers to be valid might be considered invalid by the Xerces Java parser. While validation by the Xerces Java parser can increase the time it takes to create a web service descriptor and its associated elements, using stricter validation can help ensure interoperability with other web service vendors.
13. Under Enforce WS-I Basic Profile 1.1 compliance do one of the following:
*Select Yes if you want Designer to validate all the WSD objects and properties against the WS-I requirements before creating the WSD.
*Select No if you do not want Designer to enforce compliance for WS-I Basic Profile 1.1.
Note:
WS-I Basic Profile 1.0 supports only HTTP or HTTPS bindings. Consequently, WS-I compliance cannot be enforced if the WSDL contains a SOAP over JMS binding.
14. Click Next if you want to specify different prefixes than those specified in the XML schema definition. If you want to use the prefixes specified in the XML schema definition itself, click Finish.
15. On the Assign Prefixes panel, if you want the web service descriptor to use different prefixes than those specified in the XML schema definition, select the prefix you want to change and enter a new prefix. Repeat this step for each namespace prefix that you want to change.
Note:
The prefix you assign must be unique and must be a valid XML NCName as defined by the specification http://www.w3.org/TR/REC-xml-names/#NT-NCName.
16. Click Finish.
Designer creates the consumer web service descriptor and saves it to the specified folder. Designer also creates supporting IS elements, such as web service connectors, IS document types, and response services and places them in the same folder. For more information about what elements Integration Server creates, see Supporting Elements for a Consumer Web Service Descriptor.
If Designer cannot create or cannot completely generate a consumer WSD, Designer displays error messages or warning messages.
If Integration Server determines that an XML Schema definition included in or referenced by the WSDL document is invalid or cannot be generated according to the selected content model compliance option, Designer displays the validation error message at the top of the Select Document Type Generation Options panel. Click Cancel to abandon this attempt to create a consumer web service descriptor. Alternatively, click Back to navigate to previous panels and change your selections.
Notes:
*If the WSDL document contains a construct supported on the earlier web services implementation introduced in Integration Server 7.1, but not on the current Web Services Stack, Designer gives you the option of creating the web service descriptor using the earlier web services implementation. If the WSDL document contains any of the following, Designer prompts you to use the web services implementation introduced in 7.1:
*Mixed “use” values across bindings and operations referenced by services in the WSDL document.
*Mixed “style” values across bindings referenced by services in the WSDL.
*More than one operation with the same name in the same port type.
*Bindings that do not contain all of the operations declared in the port type.
*Services with multiple bindings that reference different port types.
If you create the web services descriptor using the earlier web services implementation, the Pre-8.2 compatibility mode property will be set to true for the resulting web service descriptor.
Note:
The Pre-8.2 compatibility mode property and the ability to run in pre-8.2 compatibility mode are deprecated as of Integration Server 10.4 due to the deprecation of the web services implementation introduced in Integration Server version 7.1.
*Integration Server does not create binders for unsupported bindings in the WSDL document. If the WSDL document does not contain any bindings supported by Integration Server, Integration Server does not create a consumer web service descriptor.
*When creating the document types for the consumer web service descriptor, Integration Server registers each document type with the complex type definition from which it was created in the schema. This enables Integration Server to provide derived type support for document creation and validation.
*Integration Server uses the internal schema parser to validate the XML schema definition associated with the WSDL document. If you selected the Validate schema using Xerces check box, Integration Server also uses the Xerces Java parser to validate the XML Schema definition. With either parser, if the XML Schema does not conform syntactically to the schema for XML Schemas defined in W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures (which is located at https://www.w3.org/TR/xmlschema11-1/), Integration Server does not create an IS schema or an IS document type for the web service descriptor. Instead, Designer displays an error message that lists the number, title, location, and description of the validation errors within the XML Schema definition.
Note:Integration Server uses Xerces Java parser version Xerces-J 2.12.1-xml-schema-1.1. Limitations for this version are listed at http://xerces.apache.org/xerces2-j/xml-schema.html.
*When validating XML schema definitions, Integration Server uses the Perl5 regular expression compiler instead of the XML regular expression syntax defined by the World Wide Web Consortium for the XML Schema standard. As a result, in XML schema definitions consumed by Integration Server, the pattern constraining facet must use valid Perl regular expression syntax. If the supplied pattern does not use proper Perl regular expression syntax, Integration Server considers the pattern to be invalid.
Note:
If the watt.core.datatype.usejavaregex configuration parameter is set to true, Integration Server uses the Java regular expression compiler instead of the Perl5 regular expression compiler. When the parameter is true, the pattern constraining facet in XML schema definitions must use valid syntax as defined by the Java regular expression.
*If you selected strict compliance and Integration Server cannot represent the content model in the complex type accurately, Integration Server does not generate any IS document types or the web service descriptor.
*For an IS document type from a WSDL document, Designer displays the location of the WSDL in the Source URI property. Designer also sets the Linked to source property to true which prevents any editing of the document type contents. To edit the document type contents, you first need to make the document type editable by breaking the link to the source. However, Software AG does not recommend editing the contents of document types created from WSDL documents.
*The contents of an IS document type with a Model type property value other than “Unordered” cannot be modified.
*Operations and binders cannot be added, edited, or removed from a consumer web service descriptor.
*The Message Exchange Pattern (MEP) that Integration Server uses for an operation defined in the WSDL can be In-Out MEP, In-Only MEP, or Robust In-Only MEP. Integration Server always uses In-Out MEP when the web service descriptor’s Pre-8.2 compatibility mode property is true. When this property is false, Integration Server uses:
*In-Out MEP when an operation has defined input and output.
*In-Only MEP when an operation has no defined output and no defined fault. The web service connector that Integration Server creates will no SOAP message-related output parameters and, when executed, will not return output related to a SOAP response.
*Robust In-Only MEP when an operation has no defined output, but has a defined fault. The web service connector that Integration Server creates will return no output related to a SOAP response if the operation executes successfully. However, if an exception occurs, the web service connector returns the SOAP fault information as output.
For more information about Integration Server MEP support, see the section About Consumer Web Service Descriptors in the Web Services Developer’s Guide .
*Integration Server creates response services for all In-Out and Robust In-Only MEP operations in the WSDL document.
*When creating a web service descriptor from a WSDL document, Integration Server treats message parts that are defined by the type attribute instead of the element attribute as an error and does not allow the web service descriptor to be created. You can change this behavior by setting the watt.server.SOAP.warnOnPartValidation parameter to true. When this parameter is set to true, Integration Server will return a warning instead of an error and will allow the web service descriptor to be created.
*If the WSDL document is annotated with WS-Policy:
*Integration Server enforces the annotated policy at run time. However, if you attach a policy from the policy repository to the web service descriptor, the attached policy will override the original annotated policy.
*Integration Server will only enforce supported policy assertions in the annotated policy. Currently Integration Server supports only WS-Security policies.
*Integration Server does not save the annotated policy in the policy repository.
*If an XML Schema definition referenced in the WSDL document contains the <!DOCTYPE declaration, Integration Server issues a java.io.FileNotFoundException. To work around this issue, remove the <!DOCTYPE declaration from the XML Schema definition.
*When creating a consumer web service descriptor from an XML Schema definition that imports multiple schemas from the same target namespace, Integration Serverthrows Xerces validation errors indicating that the element declaration, attribute declaration, or type definition cannot be found. The Xerces Java parser honors the first <import> and ignores the others. To work around this issue, you can do one of the following
*Combine the schemas from the same target namespace into a single XML Schema definition. Then change the XML schema definition to import the merged schema only.
*When creating the consumer web service descriptor, clear the Validate schema using Xerces check box to disable schema validation by the Xerces Java parser. When generating the web service descriptor, Integration Server will not use the Xerces Java parser to validate the schemas associated with the XML Schema definition.