You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Russell Butek <bu...@us.ibm.com> on 2002/03/06 14:12:15 UTC
Re: WSDL4J import problem
axis-dev folks, we have a problem with WSDL4J that affects WSDL2Java
imports. I presented the problem to the WSDL4J folks, but I lost my
argument. I'm posting this chain of mail here to see whether anyone thinks
I should reopen my argument (I still think it's a bug), or whether I should
just drop it. The first note in the chain was posted to axis-dev a few
weeks ago. You can work bottom up through the discussion.
Russell Butek
butek@us.ibm.com
Russell Butek
02/22/2002 07:24 AM
To: Francisco Curbera/Watson/IBM@IBMUS
cc: Matthew Duftler/Watson/IBM@IBMUS, Sam Ruby/Raleigh/IBM@IBMUS,
Sanjiva Weerawarana/Watson/IBM@IBMUS
From: Russell Butek/Austin/IBM@IBMUS
Subject: Re: WSDL4J import problem (Document link: Russell Butek)
Sam, are you OK with this? It was your WSDL that found the problem.
I still think it's wrong. The Definition for tutorial.wsdl should have all
the pertinent info and all references should be properly resolved. It
really really bothers me that asking for a Binding's PortType, which
happens to be named "uri:diy:tutorialSoap", I get a different PortType then
if I asked the Definition that contains that Binding for PortType named
"uri:diy:tutorialSoap".
Russell Butek
butek@us.ibm.com
Francisco Curbera
02/21/2002 08:37 PM
To: Russell Butek/Austin/IBM@IBMUS
cc: Matthew Duftler/Watson/IBM@IBMUS, Sam Ruby/Raleigh/IBM@IBMUS,
Sanjiva Weerawarana/Watson/IBM@IBMUS
From: Francisco Curbera/Watson/IBM@IBMUS
Subject: Re: WSDL4J import problem (Document link: Russell Butek)
Russel,
The interpretation that Matt is describing follows the semantics of
<import> in XML Schema, which was the model for WSDL <import>. There you
only import definitions from namespaces different from the one the document
belongs to. There are a few differences, in fact, because in XML Schema the
"location" is optinal... So WSDL is at least little more helpful.
It is true that the spec is not very explicit, but I take that to be the
correct interpretation of the WSDL spec (all 4 original authors agree on
this).
The problem your example brings up is that of splitting a single
"targetNamespace" into multiple documents. The correct mechanism to deal
with that one would be the equivalent of XML Schema <include>. This may be
a good addition to WSDL, but it is not supported at this time.
Matt's interpretation is the only one consistent with WSDL 1.1 in my view.
Regards,
Paco
Russell Butek
02/21/2002 06:47 PM
To: Matthew Duftler/Watson/IBM@IBMUS
cc: Sam Ruby/Raleigh/IBM@IBMUS, Sanjiva Weerawarana/Watson/IBM@IBMUS,
Francisco Curbera/Watson/IBM@IBMUS
From: Russell Butek/Austin/IBM@IBMUS
Subject: Re: WSDL4J import problem (Document link: Francisco Curbera)
If this is not a bug (I still think it is), then it is inconsistent. See
<rjb>...</rjb>
Russell Butek
butek@us.ibm.com
MATTHEW DUFTLER
02/21/2002 03:54 PM
To: Russell Butek/Austin/IBM@IBMUS
cc: Sam Ruby/Raleigh/IBM@IBMUS, Sanjiva Weerawarana, Francisco
Curbera/Watson/IBM@IBMUS
From: Matthew Duftler/Watson/IBM@IBMUS
Subject: Re: WSDL4J import problem (Document link: Russell Butek)
Hi Russell,
Ok, I've worked through what you've described, and I don't believe it's a
bug.
I've also discussed it with Sanjiva and Paco to make sure that we all have
the same understanding of the import semantics in WSDL.
Since all three files define items in the same namspace, you should
theoretically be able to refer to any item in one file, from the items in
the other files. Basically, it is legal WSDL to refer to the portType from
the binding file, even though the binding file does not import the portType
file. The same three WSDL files would also be perfectly legal if they
contained no import statements whatsoever. However, a WSDLReader would have
no way to resolve referenced items, unless they were defined in the same
file. For any system to support referring to items contained in the same
namespace as the referring definition, without explicit import statements,
the system must have some out-of-band information.
<rjb>
I agree with these statements when they refer to the Definitions in
binding.wsdl. The items in that Definition refer to items that are
undefined. Specifically, binding.wsdl's Definition contains a Binding
object which refers to an undefined PortType. That makes sense to me since
there's no import in binding.wsdl for it to find the portType.
But what about tutorial.wsdl's Definition? All the necessary info is
available. The Definition contains a Binding. That Binding refers to a
PortType. If both imports are in tutorial.wsdl, that PortType is
undefined. If the portType.wsdl import is moved to binding.wsdl, then that
PortType IS defined. Inconsistent.
I understand what's happening in tutorial.wsdl's Definition. Its Binding
object is the one from binding.wsdl's Definition. And it's PortType object
is the one from portType.wsdl's Definition. Unfortunately, what that means
is that the Binding in the Definition refers to a PortType that is NOT in
the same Definition. Bad news.
</rjb>
As it stands today, the WSDLReader provided with WSDL4J does not hand off
one definition's imports to another to serve as out-of-band information.
<rjb>
It certainly seems to when the imports are chained (tutorial.wsdl imports
binding.wsdl imports portType.wsdl).
</rjb>
In the case you describe, the reader would have to hand off the imports
from tutorial.wsdl to be used as out-of-band information when processing
binding.wsdl.
I suppose this is a feature that could be added to WSDL4J. If we were to
add this, I think we would also have to make sure that the only imported
documents which are handed off are ones which define items for the same
targetNamespace as the definition the documents are being handed off to
(since all namespaces being referred to must be explicitly imported, with
the exception of the targetNamespace).
Thanks,
-Matt
Russell Butek
To: Matthew Duftler/Watson/IBM@IBMUS, axis-dev@xml.apache.org
02/16/2002 09:58 cc:
AM From: Russell Butek/Austin/IBM@IBMUS
Subject: WSDL4J import problem
Sam, this is the bug you found.
Matt, we have an import scenario where a binding's portType is undefined
when it shouldn't be: .
tutorial.wsdl
---------------
<import ... location="portType.wsdl">
<import ... location="binding.wsdl">
<service...>
portType.wsdl
-----------------
<portType ...>
binding.wsdl
---------------
<binding ...>
When I run "java Test tutorial.wsdl" I get:
Retrieving document at 'tutorial.wsdl'.
Retrieving document at 'porttype.wsdl', relative to 'file:tutorial.wsdl'.
Retrieving document at 'binding.wsdl', relative to 'file:tutorial.wsdl'.
definition = uri:diy:tutorial.wsdl
Binding portType isUndefined? true
PortType isUndefined? false
definition = uri:diy:portType.wsdl
PortType isUndefined? false
definition = uri:diy:binding.wsdl
Binding portType isUndefined? true
PortType isUndefined? true
Notice that whereever the binding refers to a portType, that portType is
undefined, even though that portType DOES exist. I can understand that the
binding.wsdl's definition's binding's portType is undefined, but the
tutorial.wsdl's definition's binding's portType should not be undefined.
If I change the wsdl files slightly, the portType isn't undefined:
tutorial.wsdl
---------------
<import ... location="binding.wsdl">
<service...>
portType.wsdl
-----------------
<portType ...>
binding.wsdl
---------------
<import ... location="portType.wsdl">
<binding ...>
> java Test tutorial.wsdl
Retrieving document at 'tutorial.wsdl'.
Retrieving document at 'binding.wsdl', relative to 'file:tutorial.wsdl'.
Retrieving document at 'porttype.wsdl', relative to 'file:binding.wsdl'.
definition = uri:diy:tutorial.wsdl
Binding portType isUndefined? false
PortType isUndefined? false
definition = uri:diy:binding.wsdl
Binding portType isUndefined? false
PortType isUndefined? false
definition = uri:diy:portType.wsdl
PortType isUndefined? false
Russell Butek
butek@us.ibm.com
#### import.problem.zip has been removed from this note on February 21 2002
by Matthew Duftler