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. 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"> 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"> type="tns:PurchaseOrder" /> ... 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. 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"> http://java.sun.com/blueprints/ns/po" schemaLocation="PurchaseOrder.xsd"/> ... ... ... Code Example 2: Snippet from the WSDL Showing a Purchase Order Schema Being Imported Now lets consider the Java files that would be generated from these types of WSDL files. Just as the WSDL file must have all the details specified for the purchase order, the Java Interface would also need to reflect the types to represent a purchase order. Make sure you choose type as wrapped when generating the WSDL. So that when u generated the java files using WSDL2Java you'll get a method signature like this: public void purchaseOrder(String item, int quantity, String description) So the endpoint will need a WSDL file, a Java interface, a Java implementation class with a submitPO method that accepts the PurchaseOrder with the structure and types defined in the PurchaseOrder schema, and also possibly some helper Java classes to represent the PurchaseOrder. This seems like a natural interface for many Java programmers since it is similar to passing objects, which makes it a comfortable strategy for many developers. This strategy app
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. type="tns:PurchaseOrder" /> ... 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. 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"> ... ... ... Code Example 2: Snippet from the WSDL Showing a Purchase Order Schema Being Imported Now lets consider the Java files that would be generated from these types of WSDL files. Just as the WSDL file must have all the details specified for the purchase order, the Java Interface would also need to reflect the types to represent a purchase order. Make sure you choose type as wrapped when generating the WSDL. So that when u generated the java files using WSDL2Java you’ll get a method signature like this: public void purchaseOrder(String item, int quantity, String description) So the endpoint will need a WSDL file, a Java interface, a Java implementation class with a submitPO method that accepts the PurchaseOrder with the structure and types defined in the PurchaseOrder schema, and also possibly some helper Java classes to represent the PurchaseOrder. This seems like a natural interface for many Java programmers since it is similar to passing objects, which makes it a comfortable strategy for many developers. This strategy applies well for scenarios where there is a well defined schema for a document and a service needs to be built based on that schema. For example, building a service around a vertical industry standard Invoice document. This strategy benefits from being able to leverage the automatic schema validation of JAX-RPC. For example, when a PurchaseOrder document is received, the JAX-RPC runtime automatically validates an incoming PurchaseOrder against the PurchaseOrder schema before dispatching to the service implementation class, which can save the developer some coding. Also, this strategy can benefit form the automatic binding to Java objects provided by JAX-RPC. For instance, in the purchase order example above, the XML PurchaseOrder document is automatically bound to PurchaseOrder.java objects which are available in the signature of the submitPO method. This can save
Re: Confused about more advanced WSDD usage
It sounds to me like you didn't define the 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: 1
2approach 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:
I would like to return this from my webservice call. It will accept a different document type to define the order:
I 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:
I 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 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.
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: 1
2approach 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:
I would like to return this from my webservice call. It will accept a different document type to define the order:
I 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:
I 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 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:
I 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 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
