Designer 10.7 | webMethods Service Development Help | Working with Web Services | About Provider Web Service Descriptors | Creating a WSDL First Provider Web Service Descriptor
 
Creating a WSDL First Provider Web Service Descriptor
You can create a WSDL first provider web service descriptor from a WSDL document accessed via a URL, from a UDDI registry, or from a service asset in CentraSite.
Keep the following points in mind when creating a WSDL first provider web service descriptor:
*You must have Write access to the folder in which you want to store the provider 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.
*Before you can create a provider web service descriptor from a WSDL document that contains a JMS binding, you must have at least one valid web service endpoint alias that specifies the JMS transport. When you create a provider web service descriptor from a WSDL document that specifies a SOAP over JMS binding, Designer automatically assigns the first valid provider web service endpoint alias for JMS to the web service descriptor binder. If there is not valid endpoint alias for JMS, the web service descriptor cannot be created. For example, if the only web service endpoint alias that exists for JMS specifies a SOAP-JMS trigger that no longer exists, Integration Server does not consider the endpoint to be valid and does not create the web service descriptor.
*To create a WSDL first provider web service descriptor from a web service in a UDDI registry, Designer must be configured to connect to that UDDI registry.
*To create a WSDL first provider web service descriptor from a service asset in CentraSite, Designer must be configured to connect to CentraSite.
*You can also create a provider 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.
*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 WSDL first provider 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 WSDL first provider 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 provider web service descriptor. Click Next.
3. In the Element Name field, specify a name for the provider web service descriptor using any combination of letters, numbers, and/or the underscore character. Click Next.
4. Under Create web service descriptor as, select Provider (Inbound Request).
5. Under Web service source, select WSDL. Click Next.
6. Under Source location, do one of the following:
Select...
To generate a provider 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. Click Next.
8. If you selected 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.
9. If you selected 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.
10. If you selected 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.
11. 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 provider 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.
12. 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.
13. If you want Integration Server 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 automatically uses the 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.
14. 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.
15. 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.
16. 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.
17. Click Finish.
Designer creates the provider web service descriptor and saves it to the folder you specified. Designer also creates supporting IS elements, such as flow services, IS document types, and IS schemas.
If Designer cannot create or cannot completely generate a provider web service descriptor, Designer displays error messages or warning messages.
18. 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.
19. If the WSDL document contains constructs that the current web services stack does not support, Designer displays a message identifying the reasons the web service descriptor cannot be created on the current web services stack. Designer then prompts you to create the web service descriptor using an earlier version of the web services stack. If you want to create the web service descriptor using the earlier version of the web services stack, click OK. Otherwise, click Cancel.
Notes:
*If the WSDL document contains a construct supported on the 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 version of the web services stack, 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 a provider web service descriptor if the WSDL document contains any bindings that are not supported by Integration Server.
*Integration Server will create duplicate operations in case the WSDL document has multiple port names for the same binding. To ensure that duplicate operations are not created, modify the WSDL to make the port name unique for each binding.
*When creating the binders for a WSDL first provider web service descriptor generated from a WSDL document with an HTTP or HTTPS binding, Integration Server assigns the default provider endpoint alias for HTTP or HTTPS to the binder. Integration Server uses the information from the default provider endpoint alias during WSDL generation and run-time processing. Integration Server determines whether to use the HTTP or HTTPS default provider endpoint alias by selecting the default alias for the protocol specified in the soap:addressLocation attribute of the wsdl:port element. If a default provider endpoint alias is not specified for the protocol used by the binding in the WSDL document, Integration Server uses its own hostname as the host and the primary port as the port. If the binding transport protocol is not the same as the primary port protocol, the web service descriptor has a protocol mismatch that you must resolved before making a WSDL generated from the descriptor available to consumers. For more information about a protocol mismatch, see Protocol Mismatch Between Transport and Primary Port.
Note:
The default provider endpoint alias also determines security, WS-Addressing, and WS-Reliable Messaging information for the web service descriptor and resulting WSDL document.
*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.
*When creating the document types for the provider 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.
*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.
*The contents of an IS document type with a Model type property value other than “Unordered” cannot be modified.
*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.
*If the source 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. For information about supported assertions, see the Web Services Developer’s Guide.
*Integration Server does not save the annotated policy in the policy repository.
*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 set to true. When this property is set to 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.
*Robust In-Only MEP when an operation has no defined output, but does have a defined fault.
For more information about Integration Server MEP support, see the section How Integration Server Determines the MEP Type to Use in the Web Services Developer’s Guide .
*If the WSDL is annotated with WS-Policy, Integration Server will only enforce supported policy assertions. Currently Integration Server supports only WS-Security policies. Also be aware that Integration Server does not save the WS-Policy that is in the WSDL in the policy repository. Integration Server will enforce the annotated policy unless a policy that resides in the Integration Server policy repository is specifically attached to the web service descriptor. If you attach a policy to the web service descriptor, the attached policy will override the original annotated policy.
*Integration Server creates the docTypes and services folders to store the IS document types, IS schemas, and skeleton services generated from the WSDL document. These folders are reserved for elements created by Integration Server for the web service descriptor only. Do not place an custom IS elements in these folders. During refresh of a web service descriptor, the contents of these folders will be deleted and recreated.
*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 WSDL first provider web service descriptor from an XML Schema definition that imports multiple schemas from the same target namespace, Integration Server throws 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 WSDL first provider 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.