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]
