Re: Confused about more advanced WSDD usage
Did you have a question?Note that Example 1 is invalid WSDL for a document/literal service. When using document/literal, the message part definition must always reference an element rather than a type. You may reference a type only when using RPC style. AnneOn 3/9/06, Mohit_Goyal [EMAIL PROTECTED] wrote: Lets consider some of the issues when using a schema-defined type to represent the XML document being exchanged between a client and service. In describing this strategy, we will use an example of passing a PurchaseOrder XML document from a client to a service which receives the purchase order. The purchase order document being exchanged is a typical purchase order which includes data such as the order id, the contact information, and the line items for the goods being purchased. Strategy: Using a Type Defined in Schema to Represent the XML Document In this strategy the service interface artifacts (WSDL file, Java interface and implementation) would contain all the details of the PurchaseOrder structure since it would be exposed as part of the interface. A Web Service such as this when deployed with a document-literal formatting passes the XML document in the body of the SOAP message. For the WSDL file this means that all the elements of the schema would be embedded in the WSDL file or alternatively the schema of the document can be defined in a separate schema file and imported into the WSDL file. For the corresponding Java interface this means that all PurchaseOrder schema elements would need corresponding Java types to represent the PurchaseOrder. From the WSDL point of view, there is a coupling of WSDL to the schema for the document being exchanged for this operation. For the choice of embedding the schema defenition directly into the WSDL file, this means that your interface would contain all the details of the fields and types for the structure of the document. The snippet of the WSDL in Code Example 1 below, the interface and implementation class below illustrate the purchase order details being embedded in the interface. This can be tricky to maintain since the purchase order type is actually part of the WSDL. ?xml version=1.0 encoding=UTF-8 ? definitions xmlns=http://schema.xmlsoap.org/wsdl/ xmlns:tns=urn:ObjectPurchaseOrderService xmlns:xsd=http://www.w3.org/2001/XMLSchema xmlns:soap=http://schema.xmlsoap.org/wsdl/soap/ name=ObjectPurchaseOrderService targetNamespace=urn:ObjectPurchaseOrderService types schema xmlns:soap11-enc=http://schema.xmlsoap.org/soap/encoding/ xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xmlns:wsdl=http://schema.xmlsoap.org/wsdl/ xmlns=http://www.w3.org/2001/XMLSchema targetNamespace=urn:ObjectPurchaseOrderService xsd:complexType name=Address xsd:sequence xsd:element name=street type=xsd:string nillable=false/ xsd:element name=city type=xsd:string nillable=false/ xsd:element name=state type=xsd:string nillable=false/ xsd:element name=postalCode type=xsd:string nillable=false/ /xsd:sequence /xsd:complexType xsd:complexType name=LineItem xsd:sequence xsd:element name=itemId type=xsd:string nillable=false/ xsd:element name=price type=xsd:float nillable=false/ xsd:element name=quantity type=xsd:int nillable=false/ /xsd:sequence /xsd:complexType xsd:complexType name=PurchaseOrder xsd:sequence xsd:element name=poId type=xsd:string nillable=false/ xsd:element name=createDate type=xsd:date nillable=false/ xsd:element name=shipTo type=Address nillable=false/ xsd:element name=billTo type=Address nillable=false/ xsd:element name=items type=LineItem nillable=false minOccurs=0 maxOccurs=unbounded/ /xsd:sequence /xsd:complexType /schema /types message name=PurchaseOrderServiceSEI_submitPO part name=PurchaseOrder_1 type=tns:PurchaseOrder / /message ... /definitions Code Example 1: WSDL File Snippet Showing a Purchase Order Schema Definition as a Parameter Type Definition Embedded in the WSDL An alternative to embedding the document schema definition inside the WSDL is to define a type in a separate file and import it into the WSDL file. This makes it easier to maintain. In this strategy a purchaseorder.xsd schema file would be created. And then the WSDL file would import this type into the WSDL. Then just use it for the input parameter to service operations. Code Example 2 illustrates this strategy. types schema targetNamespace=urn:SchemaDefinedPurchaseOrderService xmlns:soap11-enc=http://schemas.xmlsoap.org/soap/encoding/ xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/ xmlns=http://www.w3.org/2001/XMLSchema xsd:import namespace=http://java.sun.com/blueprints/ns/po schemaLocation=PurchaseOrder.xsd/ element name=submitPO complexType sequence element name=inputDoc type=pons:PurchaseOrder nillable=true/ /sequence /complexType /element ... /schema /types message name=SchemaDefinedPurchaseOrderServiceSEI_submitPO part name=parameters element=tns:submitPO/
Re: Confused about more advanced WSDD usage
Lets consider some of the issues when using a schema-defined type to represent the XML document being exchanged between a client and service. In describing this strategy, we will use an example of passing a PurchaseOrder XML document from a client to a service which receives the purchase order. The purchase order document being exchanged is a typical purchase order which includes data such as the order id, the contact information, and the line items for the goods being purchased. Strategy: Using a Type Defined in Schema to Represent the XML Document In this strategy the service interface artifacts (WSDL file, Java interface and implementation) would contain all the details of the PurchaseOrder structure since it would be exposed as part of the interface. A Web Service such as this when deployed with a document-literal formatting passes the XML document in the body of the SOAP message. For the WSDL file this means that all the elements of the schema would be embedded in the WSDL file or alternatively the schema of the document can be defined in a separate schema file and imported into the WSDL file. For the corresponding Java interface this means that all PurchaseOrder schema elements would need corresponding Java types to represent the PurchaseOrder. From the WSDL point of view, there is a coupling of WSDL to the schema for the document being exchanged for this operation. For the choice of embedding the schema defenition directly into the WSDL file, this means that your interface would contain all the details of the fields and types for the structure of the document. The snippet of the WSDL in Code Example 1 below, the interface and implementation class below illustrate the purchase order details being embedded in the interface. This can be tricky to maintain since the purchase order type is actually part of the WSDL. ?xml version=1.0 encoding=UTF-8 ? definitions xmlns=http://schema.xmlsoap.org/wsdl/ xmlns:tns=urn:ObjectPurchaseOrderService xmlns:xsd=http://www.w3.org/2001/XMLSchema xmlns:soap=http://schema.xmlsoap.org/wsdl/soap/ name=ObjectPurchaseOrderService targetNamespace=urn:ObjectPurchaseOrderService types schema xmlns:soap11-enc=http://schema.xmlsoap.org/soap/encoding/ xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xmlns:wsdl=http://schema.xmlsoap.org/wsdl/ xmlns=http://www.w3.org/2001/XMLSchema targetNamespace=urn:ObjectPurchaseOrderService xsd:complexType name=Address xsd:sequence xsd:element name=street type=xsd:string nillable=false/ xsd:element name=city type=xsd:string nillable=false/ xsd:element name=state type=xsd:string nillable=false/ xsd:element name=postalCode type=xsd:string nillable=false/ /xsd:sequence /xsd:complexType xsd:complexType name=LineItem xsd:sequence xsd:element name=itemId type=xsd:string nillable=false/ xsd:element name=price type=xsd:float nillable=false/ xsd:element name=quantity type=xsd:int nillable=false/ /xsd:sequence /xsd:complexType xsd:complexType name=PurchaseOrder xsd:sequence xsd:element name=poId type=xsd:string nillable=false/ xsd:element name=createDate type=xsd:date nillable=false/ xsd:element name=shipTo type=Address nillable=false/ xsd:element name=billTo type=Address nillable=false/ xsd:element name=items type=LineItem nillable=false minOccurs=0 maxOccurs=unbounded/ /xsd:sequence /xsd:complexType /schema /types message name=PurchaseOrderServiceSEI_submitPO part name=PurchaseOrder_1 type=tns:PurchaseOrder / /message ... /definitions Code Example 1: WSDL File Snippet Showing a Purchase Order Schema Definition as a Parameter Type Definition Embedded in the WSDL An alternative to embedding the document schema definition inside the WSDL is to define a type in a separate file and import it into the WSDL file. This makes it easier to maintain. In this strategy a purchaseorder.xsd schema file would be created. And then the WSDL file would import this type into the WSDL. Then just use it for the input parameter to service operations. Code Example 2 illustrates this strategy. types schema targetNamespace=urn:SchemaDefinedPurchaseOrderService xmlns:soap11-enc=http://schemas.xmlsoap.org/soap/encoding/ xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/ xmlns=http://www.w3.org/2001/XMLSchema xsd:import namespace=http://java.sun.com/blueprints/ns/po schemaLocation=PurchaseOrder.xsd/ element name=submitPO complexType sequence element name=inputDoc type=pons:PurchaseOrder nillable=true/ /sequence /complexType /element ... /schema /types message name=SchemaDefinedPurchaseOrderServiceSEI_submitPO part name=parameters element=tns:submitPO/ /message ... portType name=SchemaDefinedPurchaseOrderServiceSEI operation name=submitPO input message=tns:SchemaDefinedPurchaseOrderServiceSEI_submitPO/ ... /operation /portType Code Example 2: Snippet from the WSDL Showing a Purchase Order Schema Being Imported Now lets consider the Java files that would
Re: Confused about more advanced WSDD usage
It sounds to me like you didn't define the wsdl:service definition properly. If you can post your WSDL, I'd be happy to look at it for you.AnneOn 2/7/06,
Scott McCoy [EMAIL PROTECTED] wrote:This is quite close to what I am after, I want a properly marked up XML Document fragement to be my message.
Imagine your example, except with a few attributes :) The:item attr1/attr
attr2/attr/itemapproach to XML I find painful.We already have documents defined, and I am trying to model our services around them.For instance, we have an invoice document, with an xsd of:
xsd:element name=invoice type=invoice/ !-- An invoice is the result of an order -- xsd:complexType name=invoice
xsd:attribute name=date type=xsd:date/
xsd:attribute name=id type=xsd:integer/ xsd:attribute name=accountid type=xsd:integer/ !-- An invoice may have one or more line items --
xsd:sequence xsd:element name=item minOccurs=0 maxOccurs=unbounded xsd:complexType xsd:attribute name=purchase type=xsd:float/
xsd:attribute name=cardnumber type=xsd:string/ /xsd:complexType /xsd:element !-- An invoice returns an existing balance --
xsd:element name=balance type=xsd:float/ /xsd:sequence /xsd:complexTypeI would like to return this from my webservice call. It will accept a different document type to define the order:
xsd:element name=order type=order/ xsd:complexType name=order xsd:element name=item minOccurs=0 maxOccurs=unbounded
xsd:complexType xsd:attribute name=cardid type=xsd:integer/ xsd:attribute name=amount type=xsd:float/
/xsd:complexType /xsd:element /xsd:complexTypeI would like to map these, attributes, etc, to service calls in the cleanest fasion possible with the most behind the scenes action from Axis available.
However, your example seems to not agree with wsdl2java so I'm having difficulty seeing how it really works. After the changes made (Which I stumbled upon myself but noticed someone had already posted about) that are required to make it a valid XML document, it seems to still not be a valid WSDL document:
java.io.IOException: Emitter failure. Invalid endpoint address in port addSoapPort in service AddServiceLocator: ... at org.apache.axis.wsdl.toJava.JavaServiceImplWriter.writeFileBody(JavaServiceImplWriter.java
:242) at org.apache.axis.wsdl.toJava.JavaWriter.generate(JavaWriter.java:127) at org.apache.axis.wsdl.toJava.JavaServiceWriter.generate(JavaServiceWriter.java:112) at org.apache.axis.wsdl.toJava.JavaGeneratorFactory$Writers.generate
(JavaGeneratorFactory.java:421) at org.apache.axis.wsdl.gen.Parser.generate(Parser.java:476) at org.apache.axis.wsdl.gen.Parser.access$000(Parser.java:45) at org.apache.axis.wsdl.gen.Parser$WSDLRunnable.run
(Parser.java:362) at java.lang.Thread.run(Thread.java:595)On 2/7/06, Anne Thomas Manes
[EMAIL PROTECTED]
wrote:I don't understand what you mean. The messaging API (i.e., provider=java:MSG) is a low-level API in which the application programmatically constructs and processes XML messages using DOM. If you don't want to work with DOM, then you shouldn't use the messaging API.
To produce a method like this:public invoice handler (Calendar date, int id, int accountid, Item[] lineItems, float balance) {}you need to use the RPC API (
i.e., provider=java:RPC). The RPC API does automagic mapping of Java objects to XML types. (Note that per the JAX-RPC spec, you should use Calendar instead of Date)Perhaps what you want is to use document style messages as opposed to rpc/encoded? Well -- you still use the RPC API. (Don't you hate these overloaded terms?) The RPC API supports four message styles: rpc/encoded, rpc/literal, wrapped doc/literal, and unwrapped doc/literal. I suspect you want wrapped doc/literal. If you are generating the WSDL then specify style=WRAPPED in the WSDD. If you are generating code from WSDL, then you have to follow the wrapped convention in your WSDL. See my blog entry for instructions:
http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html
Anne
On 2/7/06, Scott McCoy [EMAIL PROTECTED] wrote:
Hello All, I am trying to implement a message-style API (as opposed to the automagical RPC stuff I've seen). I'd like, however, to write my java service handlers in a more traditional fasion rather than accepting document fragments and handling them with a bunch of DOM code. So I was doing some reading about WSDD/WSDL and Schema, and this should be possible. But I'm not quite sure how it works, and the more I read and look at examples the more I spin my wheels.
Basically, I have a document fragment like this: xsd:complexType name=invoice xsd:attribute name=date type=xsd:date/ xsd:attribute name=id type=xsd:integer/
xsd:attribute name=accountid type=xsd:integer/ !-- An invoice may have one or more line items -- xsd:sequence xsd:element name=item minOccurs=0 maxOccurs=unbounded
xsd:complexType xsd:attribute name=purchase type=xsd:float/ xsd:attribute name=cardnumber type=xsd:string/
/xsd:complexType /xsd:element
xsd:element name=balance
Confused about more advanced WSDD usage
Hello All, I am trying to implement a message-style API (as opposed to the automagical RPC stuff I've seen). I'd like, however, to write my java service handlers in a more traditional fasion rather than accepting document fragments and handling them with a bunch of DOM code. So I was doing some reading about WSDD/WSDL and Schema, and this should be possible. But I'm not quite sure how it works, and the more I read and look at examples the more I spin my wheels.
Basically, I have a document fragment like this: xsd:complexType name=invoice xsd:attribute name=date type=xsd:date/ xsd:attribute name=id type=xsd:integer/
xsd:attribute name=accountid type=xsd:integer/ !-- An invoice may have one or more line items -- xsd:sequence xsd:element name=item minOccurs=0 maxOccurs=unbounded
xsd:complexType xsd:attribute name=purchase type=xsd:float/ xsd:attribute name=cardnumber type=xsd:string/
/xsd:complexType /xsd:element
xsd:element name=balance type=xsd:float/
/xsd:sequence /xsd:complexTypeI would like to both return and accept this.It seems it should be possible, through some magic I don't quite yet understand, to map a service call to it with the following form:
public ? Dunno handler (Date date, int id, int accountid, Item[] lineItems, float balance) {}Also, there should be some way to return this from a webservice handler as well.Can someone clear up how this works, exactly? Simply defining this complexType as mapping to a specific method, as above, and being able to return such a thing.
My next question, is how can I stuff a handler in my request flow that will read the header and determine weither or not the main service handler is allowed to be called? I would like to use this for a custom form of authentication, in which I check the soap envelopes Header before allowing the soap body elements to get mapped to method calls.
Thanks.Scott S. McCoy
Re: Confused about more advanced WSDD usage
I don't understand what you mean. The messaging API (i.e., provider=java:MSG) is a low-level API in which the application programmatically constructs and processes XML messages using DOM. If you don't want to work with DOM, then you shouldn't use the messaging API.
To produce a method like this:public invoice handler (Calendar date, int id, int accountid, Item[] lineItems, float balance) {}you need to use the RPC API (
i.e., provider=java:RPC). The RPC API does automagic mapping of Java objects to XML types. (Note that per the JAX-RPC spec, you should use Calendar instead of Date)Perhaps what you want is to use document style messages as opposed to rpc/encoded? Well -- you still use the RPC API. (Don't you hate these overloaded terms?) The RPC API supports four message styles: rpc/encoded, rpc/literal, wrapped doc/literal, and unwrapped doc/literal. I suspect you want wrapped doc/literal. If you are generating the WSDL then specify style=WRAPPED in the WSDD. If you are generating code from WSDL, then you have to follow the wrapped convention in your WSDL. See my blog entry for instructions:
http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.htmlAnne
On 2/7/06, Scott McCoy [EMAIL PROTECTED] wrote:
Hello All, I am trying to implement a message-style API (as opposed to the automagical RPC stuff I've seen). I'd like, however, to write my java service handlers in a more traditional fasion rather than accepting document fragments and handling them with a bunch of DOM code. So I was doing some reading about WSDD/WSDL and Schema, and this should be possible. But I'm not quite sure how it works, and the more I read and look at examples the more I spin my wheels.
Basically, I have a document fragment like this: xsd:complexType name=invoice xsd:attribute name=date type=xsd:date/ xsd:attribute name=id type=xsd:integer/
xsd:attribute name=accountid type=xsd:integer/ !-- An invoice may have one or more line items -- xsd:sequence xsd:element name=item minOccurs=0 maxOccurs=unbounded
xsd:complexType xsd:attribute name=purchase type=xsd:float/ xsd:attribute name=cardnumber type=xsd:string/
/xsd:complexType /xsd:element
xsd:element name=balance type=xsd:float/
/xsd:sequence /xsd:complexTypeI would like to both return and accept this.It seems it should be possible, through some magic I don't quite yet understand, to map a service call to it with the following form:
public ? Dunno handler (Date date, int id, int accountid, Item[] lineItems, float balance) {}Also, there should be some way to return this from a webservice handler as well.Can someone clear up how this works, exactly? Simply defining this complexType as mapping to a specific method, as above, and being able to return such a thing.
My next question, is how can I stuff a handler in my request flow that will read the header and determine weither or not the main service handler is allowed to be called? I would like to use this for a custom form of authentication, in which I check the soap envelopes Header before allowing the soap body elements to get mapped to method calls.
Thanks.Scott S. McCoy
Re: Confused about more advanced WSDD usage
This is quite close to what I am after, I want a properly marked up XML Document fragement to be my message.Imagine your example, except with a few attributes :) The:item attr1/attr
attr2/attr/itemapproach to XML I find painful.We already have documents defined, and I am trying to model our services around them.For instance, we have an invoice document, with an xsd of:
xsd:element name=invoice type=invoice/ !-- An invoice is the result of an order -- xsd:complexType name=invoice xsd:attribute name=date type=xsd:date/
xsd:attribute name=id type=xsd:integer/ xsd:attribute name=accountid type=xsd:integer/ !-- An invoice may have one or more line items --
xsd:sequence xsd:element name=item minOccurs=0 maxOccurs=unbounded xsd:complexType xsd:attribute name=purchase type=xsd:float/
xsd:attribute name=cardnumber type=xsd:string/ /xsd:complexType /xsd:element !-- An invoice returns an existing balance --
xsd:element name=balance type=xsd:float/ /xsd:sequence /xsd:complexTypeI would like to return this from my webservice call. It will accept a different document type to define the order:
xsd:element name=order type=order/ xsd:complexType name=order xsd:element name=item minOccurs=0 maxOccurs=unbounded
xsd:complexType xsd:attribute name=cardid type=xsd:integer/ xsd:attribute name=amount type=xsd:float/
/xsd:complexType /xsd:element /xsd:complexTypeI would like to map these, attributes, etc, to service calls in the cleanest fasion possible with the most behind the scenes action from Axis available.
However, your example seems to not agree with wsdl2java so I'm having difficulty seeing how it really works. After the changes made (Which I stumbled upon myself but noticed someone had already posted about) that are required to make it a valid XML document, it seems to still not be a valid WSDL document:
java.io.IOException: Emitter failure. Invalid endpoint address in port addSoapPort in service AddServiceLocator: ... at org.apache.axis.wsdl.toJava.JavaServiceImplWriter.writeFileBody(JavaServiceImplWriter.java
:242) at org.apache.axis.wsdl.toJava.JavaWriter.generate(JavaWriter.java:127) at org.apache.axis.wsdl.toJava.JavaServiceWriter.generate(JavaServiceWriter.java:112) at org.apache.axis.wsdl.toJava.JavaGeneratorFactory$Writers.generate
(JavaGeneratorFactory.java:421) at org.apache.axis.wsdl.gen.Parser.generate(Parser.java:476) at org.apache.axis.wsdl.gen.Parser.access$000(Parser.java:45) at org.apache.axis.wsdl.gen.Parser$WSDLRunnable.run
(Parser.java:362) at java.lang.Thread.run(Thread.java:595)On 2/7/06, Anne Thomas Manes [EMAIL PROTECTED]
wrote:I don't understand what you mean. The messaging API (i.e., provider=java:MSG) is a low-level API in which the application programmatically constructs and processes XML messages using DOM. If you don't want to work with DOM, then you shouldn't use the messaging API.
To produce a method like this:public invoice handler (Calendar date, int id, int accountid, Item[] lineItems, float balance) {}you need to use the RPC API (
i.e., provider=java:RPC). The RPC API does automagic mapping of Java objects to XML types. (Note that per the JAX-RPC spec, you should use Calendar instead of Date)Perhaps what you want is to use document style messages as opposed to rpc/encoded? Well -- you still use the RPC API. (Don't you hate these overloaded terms?) The RPC API supports four message styles: rpc/encoded, rpc/literal, wrapped doc/literal, and unwrapped doc/literal. I suspect you want wrapped doc/literal. If you are generating the WSDL then specify style=WRAPPED in the WSDD. If you are generating code from WSDL, then you have to follow the wrapped convention in your WSDL. See my blog entry for instructions:
http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html
Anne
On 2/7/06, Scott McCoy [EMAIL PROTECTED] wrote:
Hello All, I am trying to implement a message-style API (as opposed to the automagical RPC stuff I've seen). I'd like, however, to write my java service handlers in a more traditional fasion rather than accepting document fragments and handling them with a bunch of DOM code. So I was doing some reading about WSDD/WSDL and Schema, and this should be possible. But I'm not quite sure how it works, and the more I read and look at examples the more I spin my wheels.
Basically, I have a document fragment like this: xsd:complexType name=invoice xsd:attribute name=date type=xsd:date/ xsd:attribute name=id type=xsd:integer/
xsd:attribute name=accountid type=xsd:integer/ !-- An invoice may have one or more line items -- xsd:sequence xsd:element name=item minOccurs=0 maxOccurs=unbounded
xsd:complexType xsd:attribute name=purchase type=xsd:float/ xsd:attribute name=cardnumber type=xsd:string/
/xsd:complexType /xsd:element
xsd:element name=balance type=xsd:float/
/xsd:sequence /xsd:complexTypeI would like to both return and accept this.It seems it should be possible, through some magic I don't quite yet understand, to map a service call to it
