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.
a. Is it the schema containing the declarations of the types or
elements used as message parts?
b. What if that information is contained in several schemas?
c. Does this access schemas contained in the types section of the
wsdl and/or imports from those schemas?
2. Starting from a correct and consistent wsdl descriptor, is there a
deterministic algorithm that finds all the policy metadata?
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?
b. Will there be any policies that apply that are not referenced
or embedded in 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?
d. Similarly for access via ?policy.
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?
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?
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]
