[OASIS Issue Tracker] Created: (CMIS-12) Non-operability of Draft0.50 WSDL with IBM WebSphere Integration Developer (WID) Tooling

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

Non-operability of Draft 0.50 WSDL with IBM WebSphere Integration Developer (WID) Tooling
-----------------------------------------------------------------------------------------

                 Key: CMIS-12
                 URL: http://tools.oasis-open.org/issues/browse/CMIS-12
             Project: OASIS Content Management Interoperability Services TC
          Issue Type: Bug
          Components: Web Services Binding
    Affects Versions: Draft 0.50
            Reporter: Gary Gershon


The Draft 0.50 WSDL files fail cross-WSDL file validation using the IBM WebSphere Integration Developer (WID) tool due to their current structure which utilizes the same target namespace in multiple WSDL files.

Because of this, these WSDL files cannot be utilized in a WebSphere Process Server (WPS) or WebSphere ESB (WESB) environment to orchestrate (via BPEL) or mediate (via the enterprise service bus) CMIS Web services.

WPS and WESB are the current standards-based IBM enterprise product offerings that support orchestration using BPEL and the ESB integration pattern.

WID is the Eclipse-based IDE for programming WPS and WESB and is based on IBM's Rational Application Developer (RAD) product for Java (and other language) development.  I am using the most current version of WID: 6.1.2.

It appears that while each CMIS WSDL file is valid by itself, when more than one WSDL is imported into a development project then each CMIS WSDL-defined fault (e.g. all the CMIS "Exceptions" that are defined for the service) results in an error:

(From the IBM Help facility...)
CWZXT0102E: There are messages that have the same name ({0}) in the same namespace ({1}).
Explanation: For the project that uses this file to run on WebSphere Process Server, each message name in a namespace must be unique.
User Action: Edit the WSDL file to ensure that the message names are unique in each namespace.

such as:

"There are messages that have the same name (ConstraintViolationException) in the same namespace (http://www.cmis.org/2008/05)."

I was able to eliminate these errors by specifying a unique target namespace for each WSDL file, however, this solution will impact interoperability with the Draft 0.50 vendor test environments.

Employing a unique target namespace for each WSDL file is common practice, as shown in the samples in the WSDL 1.2 specification (http://www.w3.org/TR/2003/WD-wsdl12-20030303/) Example 2:

<?xml version="1.0" encoding="UTF-8"?> 
<definitions name="TicketAgent" 
    targetNamespace="http://airline.wsdl/ticketagent/"; 
    xmlns="http://schemas.xmlsoap.org/wsdl/"; 
    xmlns:tns="http://airline.wsdl/ticketagent/"; 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:xsd1="http://airline/";> 
    <import location="TicketAgent.xsd" namespace="http://airline/"/> 

where the WSDL file has a target namespace suffixed with the name of the service, which is thus a different namespace from the domain model namespace.

(This naming pattern appears to be why some of the CMIS 0.50 WSDL files had developer notes indicating they could not use <import> for the schema -- which was due to the schema requirement to use <include> when the namespaces are the same, and <import> when the namespaces are different.)

I think this is a significant issue because I don't think CMIS could go to market if it could not be used to access documents for customers in IBM BPM or EAI environments.

Pending further discussion, my recommendation would be that CMIS should adopt the common pattern of using a unique target namespace in each WSDL file.





-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira