See inline...
On 1/17/07, Jeff Greif <[EMAIL PROTECTED]> wrote:
> Anne,
>
> As usual, you are a fount of useful information. Thanks for all you
> do to explain the various SOA standards to the world.
>
> Questions:
>
> 1. What schema is supposed to be provided by ?xsd.
Keep in mind that the URL query is a non-standard convention. Most
systems support the "?wsdl" query, but very few support either "?xsd"
or "?policy".
But, assuming that an endpoint does support the "?xsd" query
convention, then it should return a schema that defines the input and
output messages supported by the endpoint. (This convention would be
especially helpful for RESTful services that don't provide a WSDL
definition.)
>
> a. Is it the schema containing the declarations of the types or
> elements used as message parts?
It should define the complete body message structures, which ought to
be defined as root elements. Types or message parts aren't sufficient.
If you are using RPC style, then you would have to depend on the WSDL
to provide the information required to define the message structure.
(RPC style only defines types, not the root element of the message.)
>
> b. What if that information is contained in several schemas?
A message contains a single element ( a root element); therefore, that
element must be defined in a single schema (although it can certainly
import or include other schemas). For this convention to work, though,
all message structures supported by the endpoint must be defined in a
single schema. For efficiency sake, you probably want to make sure
that the "?xml" query returns the actual schemas and doesn't return a
bunch of imports that then requires a bunch more queries.
> c. Does this access schemas contained in the types section of the
> wsdl and/or imports from those schemas?
The convention is that it returns a schema that describes the input
and output messages. How it goes about getting that schema is an
implementation feature of the system supporting the convention. If
Axis2 chose to implement this convention, it might require the
developer to provide the schema as a configuration parameter, or it
might automatically generate the schema by extracting the appropriate
info from the WSDL.
>
> 2. Starting from a correct and consistent wsdl descriptor, is there a
> deterministic algorithm that finds all the policy metadata?
Only if the WSDL embeds all policy information via
WS-PolicyAttachment. There is no requirement that the policies must be
attached to the WSDL. The preferred method for retrieving all metadata
is to use WS-MetadataExchange.
> a. If the policies are embedded in the wsdl and/or referenced in
> the wsdl, does extracting all the embedded ones and retrieving all the
> references (recursively if that's necessary), will that be all of the
> policies that apply?
Again, only if the WSDL embeds all policy information.
> b. Will there be any policies that apply that are not referenced
> or embedded in the wsdl?
It's possible. As a best practice, it's a good idea to attach all
applicable policies to the WSDL.
> c. If policies must be retrieved from a UDDI repository, is that
> repository referenced in the wsdl or is there some out-of-band process
> that must be followed to determine its existence?
I've never seen an extension to WSDL that provides a means to
reference a UDDI bindingTemplate (the UDDI entry that represents a
service endpoint). Keep in mind that typically, you're querying UDDI
to find a service, its endpoints, and its metadata. If you already
have the endpoint, then you should be able to query the endpoint to
get its metadata using WS-MetedataExchange.
I suppose we could define another query convention: append "?uddi" to
the access point URL, and it should return a link to the UDDI
bindingTemplate that describes it.
(FYI: UDDI is a registry, not a repository. It does not host the
policies (or WSDLs or XSDs), it simply provides pointers to all the
metadata that apply to the service.
> d. Similarly for access via ?policy.
If the service endpoint follows this convention, then the "?policy"
query should return a WS-Policy file that contains all policies that
apply to the service.
> 3. Do the queries service-endpoint?policy and service-endpoint?xsd
> produce exceptions when not implemented, or do they produce some empty
> result? If they produce a result, is it guaranteed that the result
> contains or references (perhaps recursively) all the policies or
> schemas needed to consume the web service?
The convention hasn't been standardized. What happens today when you
issue a "?wsdl" query to a service that doesn't support the
convention? My guess is that you would get a 404 Not Found.
> 4. Do you ever need to use more than one of the various methods
> (query-url, wsdl-cracking, Ws-MetadataExchange or UDDI) of obtaining
> the metadata, or is any one that doesn't fail equivalent to any other
> that doesn't fail?
If the service follows the conventions properly, then you should be
able to get all metadata using any one of the methods. But I
absolutely would not depend on any service implementing any of these
conventions properly today. None of these conventions has been
standardized yet.
The one closest to standardization is WS-PolicyAttachment (which
enables "WSDL-cracking" and UDDI), but keep in mind that only a few
systems support WS-Policy at this time, and most systems that do
support WS-Policy only use it for security and maybe reliability
policies.
WS-MetadataExchange has not yet been submitted to a standards body.
I've never seen anyone attempt to document the url-query convention.
>
> Jeff
>
> On 1/17/07, Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
> > The way it supposed to work is thus:
> >
> > - A web service has various metadata files associated with it:
> > - WSDL defines the supported interfaces, MEPs, and bindings
> > - XSD defines the message formats
> > - WS-Policy defines its constraints and capabilities
> > (policies can be embedded in the WSDL or attached via UDDI)
> > - You have various means to locate the metadata
> > - Look it up via UDDI (all metadata should be registered,
> > WS-PolicyAttachment defines how policies are attached via UDDI)
> > - Query the service for its metadata using WS-MetadataExchange
> > - Query the service access point, appending "?wsdl", "?xsd", and
"?policy"
> > to the URL and hope that the service supports this convention
> >
> > Anne
> > On 1/17/07, Jeff Greif <[EMAIL PROTECTED]> wrote:
> > > Anne,
> > >
> > > So if you want to dynamically consume web services based on the wsdl
> > > alone, the WS-Policy constructs have to be embedded there and the
> > > client machinery has to know how to process them to determine what
> > > headers are required, if any? Is this the way it's supposed to work?
> > >
> > > Is the alternative to get the WS-Policy requirements from some
> > > different repository? Is there a regular scheme related to UDDI or
> > > something that provides this?
> > >
> > > Jeff
> > >
> > > On 1/17/07, Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
> > > > Bruce,
> > > >
> > > ...
> > > > But I reiterate my earlier comment. I strongly discourage you from
> > > > defining headers in the WSDL. The WSDL represents the information that
> > > > the application should be responsible for. Typically headers are added
> > > > to the message and processed by the middleware, not by the
> > > > application. Therefore the requirement for headers should be specified
> > > > separately -- preferably using WS-Policy, even though it isn't final
> > > > yet.
> > > >
> > > > I also *strongly* recommend that you not define your own header
> > > > formats, but rather that you conform to standard SOAP extensions -- in
> > > > your case WS-Addressing and WS-Security. (You've used standard element
> > > > definitions from WS-Addressing and XML Signature, but you haven't
> > > > followed the standard header formats for using these elements.)
> > > >
> > > > Axis2 can automatically manage WS-Addressing and WS-Security headers
> > > > for you, and they will do so in an interoperable way. But you mustn't
> > > > define the headers in the WSDL -- you must configure them in the
> > > > config file.
> > > >
> > > > Anne
> > > >
> > > > On 1/17/07, R Bruce Hoffman <[EMAIL PROTECTED]> wrote:
> > > > > First, let me sincerely thank you for your rapid response.
> > > > >
> > > > > I had originally questioned the other developers on that repeated
import
> > > > > of the namespace and been told it was ok. I probably have to be more
> > > > > forceful when my gut says it's wrong... but, as you can probably
tell, I
> > > > > am new to this WSDL stuff.. previous services I have deployed were
from
> > > > > POJOs and not defined by or through WSDL, and I am no xml expert
either.
> > > > >
> > > > > At least I have ammo to go back to them and have their manager apply
the
> > > > > "2 by 4" process... ;-)
> > > > >
> > > > > Next here are the other two xsd's that I had left off.
> > > > >
> > > > > again, thanks.
> > > > >
> > > > >
> > > > > On Wed, 2007-01-17 at 08:50 -0500, Anne Thomas Manes wrote:
> > > > > > Bruce,
> > > > > >
> > > > > > Giving the WSDL a quick look, I noticed that it is not valid. I
don't
> > > > > > know if this is what's causing your problem, but it's a good place
to
> > > > > > start.
> > > > > >
> > > > > > In your WSDL <types> section, you attempt to import the same
namespace
> > > > > > twice. This is not allowed. If the namespace is defined in multiple
> > > > > > schemas, and your goal is to import both schemas, then you must
define
> > > > > > a schema with the same target namespace and <xs:include> the schemas
> > > > > > into the namespace. e.g.:
> > > > > >
> > > > > > <xs:schema
targetNamespace="urn:/fih/c-efm/purchase-order/1.0"
> > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema";
> > > > > > elementFormDefault="qualified">
> > > > > > <xs:include
> > > > > >
schemaLocation="1.0/receive-purchase-order-request.xsd"/>
> > > > > > <xs:include
> > > > > >
schemaLocation="1.0/receive-purchase-order-reply.xsd"/>
> > > > > > </xs:schema>
> > > > > >
> > > > > > Another error that I found: you must not specify the parameterOrder
> > > > > > attribute in the <wsdl:operation> definition when using document
> > > > > > style. (It is only used with RPC style.)
> > > > > >
> > > > > > As a general practice, it's a bad idea to define headers in your
WSDL,
> > > > > > especially if you are using standard headers. (The XMLBeans error
> > > > > > indicates that you are using WS-Addressing and DSIG.) You should
> > > > > > define your header requirements using WS-Policy and configuration
> > > > > > files.
> > > > > >
> > > > > > Also, in regards to schema you did provide
> > > > > > (targetNamespace="urn:/fih/purchase-order"), some best practices
> > > > > > advice:
> > > > > >
> > > > > > - Avoid using anonymous types. Rather than defining structures as
> > > > > > elements, define them as named types, and then define elements as
> > > > > > those types. e.g.:
> > > > > >
> > > > > > Do this:
> > > > > >
> > > > > > <xs:complexType name="baselineItemDataLoop">
> > > > > > <xs:sequence>
> > > > > > <xs:element ref="BaselineItemDataSegment"
minOccurs="0"/>
> > > > > > <xs:element ref="ReferenceIdentificationSegment"
minOccurs="0"/>
> > > > > > </xs:sequence>
> > > > > > </xs:complexType>
> > > > > > <xs:element name="BaselineItemDataLoop"
type="baselineItemDataLoop"/>
> > > > > >
> > > > > > Rather than this:
> > > > > >
> > > > > > <xs:element name="BaselineItemDataLoop">
> > > > > > <xs:complexType>
> > > > > > <xs:sequence>
> > > > > > <xs:element ref="BaselineItemDataSegment"
minOccurs="0"/>
> > > > > > <xs:element ref="ReferenceIdentificationSegment"
minOccurs="0"/>
> > > > > > </xs:sequence>
> > > > > > </xs:complexType>
> > > > > > </xs:element>
> > > > > >
> > > > > > And I recommend being cautious about defining each element as a
global
> > > > > > element. The only elements that really should be defined as global
> > > > > > elements are those elements that will be the root of a document.
i.e,
> > > > > > rather than defining "BaselineItemDataSegment" as a gloal element
and
> > > > > > referencing it from the type definition, define the element within
the
> > > > > > type definition and reference its type, e.g.:
> > > > > >
> > > > > >
> > > > > > We also need to see the "unr:/fih/c-efm/purchase-order/1.0" schema
files.
> > > > > > (You sent us the "http://www.fih.org/XML/WD0"; namespace schema,
instead.)
> > > > > >
> > > > > > <xs:complexType name="baselineItemDataLoop">
> > > > > > <xs:sequence>
> > > > > > <xs:element name="BaselineItemDataSegment"
> > > > > > type="baselineItemDataSegment
> > > > > > minOccurs="0"/>
> > > > > > <xs:element
name="ReferenceIdentificationSegment"
> > > > > > type="referenceIdentificationSegment"
> > > > > > minOccurs="0"/>
> > > > > > </xs:sequence>
> > > > > > </xs:complexType>
> > > > > >
> > > > > > Anne
> > > > > >
> > > > > > On 1/17/07, R Bruce Hoffman <[EMAIL PROTECTED]> wrote:
> > > > > > > Sure... sorry.
> > > > > > >
> > > > > > > Also, when using xmlbeans binding, I get the following error:
> > > > > > >
> > > > > > > Using AXIS2_HOME: /usr/local/axis2
> > > > > > > Using JAVA_HOME: /usr/lib/jvm/java-1.5.0-sun
> > > > > > > Retrieving schema at '../../../../fih/1.0/fih-header.xsd',
relative to
> > > > > > >
'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > > > Retrieving schema at
> > > > > > >
'http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd', relative to
'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > > > > > > Retrieving schema at
> > > > > > > 'http://schemas.xmlsoap.org/ws/2004/08/addressing/', relative to
> > > > > > > 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > > > > > > Retrieving schema at '1.0/receive-purchase-order-request.xsd',
relative
> > > > > > > to
> > > > > > >
'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > > > Retrieving schema at 'LimitedPurchaseOrder.xsd', relative to
> > > > > > >
'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/1.0/receive-purchase-order-request.xsd'.
> > > > > > > Retrieving schema at '1.0/receive-purchase-order-reply.xsd',
relative to
> > > > > > >
'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > > > > > > Jan 16, 2007 1:39:58 PM
org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > INFO: Resolving schema with publicId [urn:/fih/1.0] and systemId
> > > > > > > [/fih/1.0/fih-header.xsd]
> > > > > > > Jan 16, 2007 1:39:58 PM
org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > INFO: Resolving schema with publicId
[urn:/fih/c-efm/purchase-order/1.0]
> > > > > > > and systemId [/1.0/receive-purchase-order-request.xsd]
> > > > > > > Jan 16, 2007 1:39:58 PM
org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > INFO: Resolving schema with publicId
[urn:/fih/c-efm/purchase-order/1.0]
> > > > > > > and systemId [/1.0/receive-purchase-order-reply.xsd]
> > > > > > > Jan 16, 2007 1:39:58 PM
org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > INFO: Resolving schema with publicId
> > > > > > > [http://www.w3.org/2000/09/xmldsig#] and systemId
> > > > > > >
[/http:/www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd]
> > > > > > > Jan 16, 2007 1:39:58 PM
org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > INFO: Resolving schema with publicId
> > > > > > > [http://schemas.xmlsoap.org/ws/2004/08/addressing] and systemId
> > > > > > > [/http:/schemas.xmlsoap.org/ws/2004/08/addressing]
> > > > > > > Jan 16, 2007 1:39:58 PM
org.apache.axis2.xmlbeans.CodeGenerationUtility
> > > > > > > $Axis2EntityResolver resolveEntity
> > > > > > > INFO: Resolving schema with publicId [http://www.fih.org/XML/WD0]
and
> > > > > > > systemId [/1.0/LimitedPurchaseOrder.xsd]
> > > > > > > Exception in thread "main"
> > > > > > > org.apache.axis2.wsdl.codegen.CodeGenerationException:
> > > > > > > java.lang.RuntimeException:
java.lang.reflect.InvocationTargetException
> > > > > > > at
> > > > > > >
org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224)
> > > > > > > at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32)
> > > > > > > at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:21)
> > > > > > > Caused by: java.lang.RuntimeException:
> > > > > > > java.lang.reflect.InvocationTargetException
> > > > > > > at
> > > > > > >
org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:92)
> > > > > > > at
> > > > > > >
org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177)
> > > > > > > ... 2 more
> > > > > > > Caused by: java.lang.reflect.InvocationTargetException
> > > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
> > > > > > > at
> > > > > > >
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > > > > > at
> > > > > > >
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > > > > > at java.lang.reflect.Method.invoke(Method.java:585)
> > > > > > > at
> > > > > > >
org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:82)
> > > > > > > ... 3 more
> > > > > > > Caused by: java.lang.RuntimeException:
org.apache.xmlbeans.XmlException:
> > > > > > > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > > > > > > cvc-enumeration-valid: string value 'none' is not a valid
enumeration
> > > > > > > value for type of processContents attribute in xs:wildcard
> > > > > > > at
> > > > > > >
org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:242)
> > > > > > > ... 8 more
> > > > > > > Caused by: org.apache.xmlbeans.XmlException:
> > > > > > > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > > > > > > cvc-enumeration-valid: string value 'none' is not a valid
enumeration
> > > > > > > value for type of processContents attribute in xs:wildcard
> > > > > > > at
> > > > > > >
org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:225)
> > > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
> > > > > > > at
> > > > > > >
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > > > > > at
> > > > > > >
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > > > > > at java.lang.reflect.Method.invoke(Method.java:585)
> > > > > > > at
> > > > > > > org.apache.xmlbeans.XmlBeans.compileXmlBeans(XmlBeans.java:667)
> > > > > > > at
> > > > > > >
org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:160)
> > > > > > > ... 8 more
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, 2007-01-17 at 10:41 +0530, Amila Suriarachchi wrote:
> > > > > > > > Can you attach your fih-header.xsd file?
> > > > > > > >
> > > > > > > > On 1/16/07, R Bruce Hoffman <[EMAIL PROTECTED]> wrote:
> > > > > > > > I just can't seem to get Axis2 1.1.1 wsdl2java.sh to
properly
> > > > > > > > create
> > > > > > > > skeleton code and Axiom or XmlBeans artifacts correctly
for,
> > > > > > > > what seems
> > > > > > > > to be, relatively simple wsdl and xsd's.
> > > > > > > >
> > > > > > > > Below is the xsd and wsdl information. I have used FC4,
FC5,
> > > > > > > > Ubuntu and Debian Sarge. I have tried 1.1, a snapshot
before
> > > > > > > > 1.1.1 and 1.1.1 releases. Sun java 1.5.0_09 and 10.
> > > > > > > >
> > > > > > > > I am being told that the wsdl and xsd information is
valid (by
> > > > > > > > the
> > > > > > > > original developers). Both NetBeans 5.5 and Eclipse
(under
> > > > > > > > WDSCi) seem
> > > > > > > > to agree that they are at least valid.
> > > > > > > >
> > > > > > > > When I run wsdl2java with ADB binding, the message
parts all
> > > > > > > > end up in
> > > > > > > > the default package with empty package statements
> > > > > > > > ("package ;"). The
> > > > > > > > ExtensionMapper.java ends up in an (invalid) null
package.
> > > > > > > > (It's named
> > > > > > > > "null" and on the output src path.)
> > > > > > > >
> > > > > > > > All of the types, after the first array type, are
listed with
> > > > > > > > "This was
> > > > > > > > an array!" in the comments, but have no array
declarations in
> > > > > > > > their
> > > > > > > > _type_nn classes... the [] markers are not produced
after the
> > > > > > > > first
> > > > > > > > repeating element.
> > > > > > > >
> > > > > > > > I have looked at trying to clean up this code to make it
> > > > > > > > usable, but I
> > > > > > > > would think that Axis2 should be producing code that,
at the
> > > > > > > > very least,
> > > > > > > > would compile through the ant build if the wsdl2java
succeeds,
> > > > > > > > which it
> > > > > > > > does complete in this case. If not, it should probably
give me
> > > > > > > > an error
> > > > > > > > in the generation of the ADB code.
> > > > > > > >
> > > > > > > > Maybe its something simple or I'm just a dope, or both,
but I
> > > > > > > > am lost.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Amila Suriarachchi,
> > > > > > > > WSO2 Inc.
> > > > > > >
> > > > > > >
> > > > > > >
---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
