You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Sudhakar Dharwada <su...@wipro.com> on 2003/06/24 13:40:02 UTC
Help in using commons HTTP sender
Hi,
Can any one tell me how to use CommonsHTTPSender?
Thanks in advance,
Sudhakar.
**************************Disclaimer************************************
Information contained in this E-MAIL being proprietary to Wipro Limited is
'privileged' and 'confidential' and intended for use only by the individual
or entity to which it is addressed. You are notified that any use, copying
or dissemination of the information contained in the E-MAIL in any manner
whatsoever is strictly prohibited.
***************************************************************************
Re: Howto : w3c.dom.Element to SOAPHeader
Posted by Anne Thomas Manes <an...@manes.net>.
MessageSince you have an immediate requirement, I suggest you use WASP 4.6 beta. As far as I know it's the only Java implementation that support WS-Security. See http://www.systinet.com/products/beta/overview.
Anne
----- Original Message -----
From: Kai Unewisse
To: axis-user@ws.apache.org
Sent: Tuesday, June 24, 2003 8:34 AM
Subject: Howto : w3c.dom.Element to SOAPHeader
Hi all !
Thanks to Dims and Anne for your help in WS-Security,but I need WS-Security instantly (my thesis ends in 4 weeks ...)
My challange is right now transforming an w3c.dom.Element Object to an SOAPHeader Object.
I use Verisigns WS-Security and it produces a signed Document. But how can I put it back to the MessageContext ???
My Code :
Document doc = context.getCurrentMessage().getSOAPEnvelope().getAsDocument();
WSSecurity sec = new WSSecurity();
sec.sign(doc, signingKey, signingKeyInfo);
Element soapHeaderElement = (Element) ((Element) doc.getFirstChild()).getElementsByTagNameNS("*", "Header").item(0);
// context.getCurrentMessage().getSOAPEnvelope().setHeader( ???? );
It is probably very easy, but I can`t find out.
Thanks for any hint,
Kai
RE: Message Style and WSDL
Posted by Bhanu Pabreja <pa...@infigroup.com>.
I just had a look at your wsdl file and it says that the style=Document ...
so this makes me wonder is it really message style service.
Have a look at my deploy.wsdd and just try to create a method and install
the service and see how is shows up in your engine ...
BTW: How do we bypass the ?wsdl and insert our own handwritten wsdl file so
that next time the client tries to access the file it shows the newly
created self edtited wsdl file.
Thanx in advance ...
Bhanu
-----Original Message-----
From: remko de knikker [mailto:remko.deknikker@yale.edu]
Sent: Tuesday, June 24, 2003 3:10 PM
To: axis-user@ws.apache.org
Subject: Re: Message Style and WSDL
You can also handwrite your wsdl-file and include it in the wsdd file
provided of course your webservice is actually working message-style.
This way you bypass the generation of your wsdl by axis.
r
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
targetNamespace="http://biryani.med.yale.edu:8081/axis/services/GetXSLIM"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl="http://biryani.med.yale.edu:8081/axis/services/GetXSLIM"
xmlns:intf="http://biryani.med.yale.edu:8081/axis/services/GetXSLIM"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><wsdl:types><xsd:schema
xmlns:tns="http://biryani.med.yale.edu"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="method1Request">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="element-id" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="x-slim">
<xsd:complexType>
<xsd:element name="join_paths">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="path" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="table">
<xsd:complexType>
<xsd:element name="table_title" type="xsd:string"/>
<xsd:element name="columns">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="table_column" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="table_fields">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="field" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:complexType>
</xsd:element>
</xsd:complexType>
</xsd:element>
</xsd:element>
</xsd:schema><schema targetNamespace=""
xmlns="http://www.w3.org/2001/XMLSchema"><import
namespace="http://schemas.xmlsoap.org/soap/encoding/"/><element
name="method1" type="xsd:anyType"/><element name="method1Return"
type="xsd:anyType"/></schema></wsdl:types>
<wsdl:message name="method1Response">
<wsdl:part element="method1Return" name="method1Return"/>
</wsdl:message>
<wsdl:message name="method1Request">
<wsdl:part element="method1" name="part"/>
</wsdl:message>
<wsdl:portType name="GetXSLIM">
<wsdl:operation name="method1">
<wsdl:input message="impl:method1Request" name="method1Request"/>
<wsdl:output message="impl:method1Response" name="method1Response"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="GetXSLIMSoapBinding" type="impl:GetXSLIM">
<wsdlsoap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="method1">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="method1Request">
<wsdlsoap:body
namespace="http://biryani.med.yale.edu:8081/axis/services/GetXSLIM"
use="literal"/>
</wsdl:input>
<wsdl:output name="method1Response">
<wsdlsoap:body
namespace="http://biryani.med.yale.edu:8081/axis/services/GetXSLIM"
use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="GetXSLIMService">
<wsdl:port binding="impl:GetXSLIMSoapBinding" name="GetXSLIM">
<wsdlsoap:address
location="http://biryani.med.yale.edu:8081/axis/services/GetXSLIM"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Bhanu Pabreja wrote:
still does not work your server.
Once you run your server and I hope it is visible on the internet I will
have a look at your wsdl.
Can u also post your wsdl file in the thread
Thanx in advance,
Bhanu
-----Original Message-----
From: remko de knikker [mailto:remko.deknikker@yale.edu]
Sent: Tuesday, June 24, 2003 2:06 PM
To: axis-user@ws.apache.org
Subject: Re: Message Style and WSDL
Bhanu,
the only other thing that I know of, is that I need to restart my
server, to make it work...?
sorry,
r
Bhanu Pabreja wrote:
This what my deployment descriptor looks like :
<deployment name="test" xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance">
<!-- note that either style="message" OR provider="java:MSG" both
work -->
<service name="FirmTaxonomyModelService" style="message">
<parameter name="className"
value="com.dumdum.taxonomy.ws.FirmTaxonomyModelMessageStyleService" />
<parameter name="allowedMethods" value="*" />
</service>
</deployment>
and my wsdl file looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
targetNamespace="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyMode
l
Service" xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServ
i
ce"
xmlns:intf="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServ
i
ce" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><wsdl:types/>
<wsdl:message name="fetchDocumentResponse">
<wsdl:part name="fetchDocumentReturn" type="xsd:anyType"/>
</wsdl:message>
<wsdl:message name="fetchDocumentRequest">
</wsdl:message>
<wsdl:portType name="FirmTaxonomyModelMessageStyleService">
<wsdl:operation name="fetchDocument">
<wsdl:input message="intf:fetchDocumentRequest"
name="fetchDocumentRequest"/>
<wsdl:output message="intf:fetchDocumentResponse"
name="fetchDocumentResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="FirmTaxonomyModelServiceSoapBinding"
type="intf:FirmTaxonomyModelMessageStyleService">
<wsdlsoap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="fetchDocument">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="fetchDocumentRequest">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServi
c
e" use="encoded"/>
</wsdl:input>
<wsdl:output name="fetchDocumentResponse">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServi
c
e" use="encoded"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="FirmTaxonomyModelMessageStyleServiceService">
<wsdl:port binding="intf:FirmTaxonomyModelServiceSoapBinding"
name="FirmTaxonomyModelService">
<wsdlsoap:address
location="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServic
e
"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Now this thing clearly says that this is RPC style service and everything
looks to be encoded.
BTW I dont think so your server is up since I could not access your
webservice's wsdl file.
Have a look and tell me where I am wrong.
Bhanu.
-----Original Message-----
From: remko de knikker [mailto:remko.deknikker@yale.edu]
Sent: Tuesday, June 24, 2003 9:01 AM
To: axis-user@ws.apache.org
Subject: Re: Message Style and WSDL
Bhanu,
here's my example for a message-style ws, which works for me.
<deployment name="GetXSLIM" xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance">
<handler name="handlerXSLIM" type="java:ws.xslim.BasicHandler_XSLIM"/>
<service name="GetXSLIM" style="message">
<requestFlow>
<handler type="handlerXSLIM"/>
</requestFlow>
<responseFlow>
<handler type="handlerXSLIM"/>
</responseFlow>
<parameter name="className" value="ws.xslim.GetXSLIM" />
<parameter name="allowedMethods" value="method1" />
<parameter name="wsdlInputSchema"
value="http://biryani.med.yale.edu:8081/axis/files/xslim/GetXSLIM_method1Re
q
uest.xsd"/>
</service>
</deployment>
Look at the result at
http://biryani.med.yale.edu:8081/axis/services/GetXSLIM?wsdl
remko
Date: Mon, 23 Jun 2003 18:39:30 -0400
From: Bhanu Pabreja <pa...@infigroup.com>
To: axis-user@ws.apache.org
Reply-to: axis-user@ws.apache.org
Subject: Message Style and WSDL
One step beyond .jws files
I have made a message style service with one method
public Document fetchData(Document doc){
// logic
}yl
Then I deployed the service using the deploy.wsdd. I could not use the
Java2WSDL utitily to generate "Message" style service so I hand edited one
of the provided examples.
But once I deploy it to the /servlet/AxisServlet and try to browse the
generated .wsdl file it is totally a different version of what I have made
.. I mean the wsdl says that it is a RPC style service and the operation is
encoded.
Now the questions I can figure out is :
(a) How to make a message style service and create a wsdl file which says
that it is a Message style service.
thanx in advance
dumdum420
Re: Message Style and WSDL
Posted by remko de knikker <re...@yale.edu>.
You can also handwrite your wsdl-file and include it in the wsdd file
provided of course your webservice is actually working message-style.
This way you bypass the generation of your wsdl by axis.
r
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://biryani.med.yale.edu:8081/axis/services/GetXSLIM" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://biryani.med.yale.edu:8081/axis/services/GetXSLIM" xmlns:intf="http://biryani.med.yale.edu:8081/axis/services/GetXSLIM" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><wsdl:types><xsd:schema xmlns:tns="http://biryani.med.yale.edu" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="method1Request">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="element-id" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="x-slim">
<xsd:complexType>
<xsd:element name="join_paths">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="path" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="table">
<xsd:complexType>
<xsd:element name="table_title" type="xsd:string"/>
<xsd:element name="columns">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="table_column" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="table_fields">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="field" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:complexType>
</xsd:element>
</xsd:complexType>
</xsd:element>
</xsd:element>
</xsd:schema><schema targetNamespace="" xmlns="http://www.w3.org/2001/XMLSchema"><import namespace="http://schemas.xmlsoap.org/soap/encoding/"/><element name="method1" type="xsd:anyType"/><element name="method1Return" type="xsd:anyType"/></schema></wsdl:types>
<wsdl:message name="method1Response">
<wsdl:part element="method1Return" name="method1Return"/>
</wsdl:message>
<wsdl:message name="method1Request">
<wsdl:part element="method1" name="part"/>
</wsdl:message>
<wsdl:portType name="GetXSLIM">
<wsdl:operation name="method1">
<wsdl:input message="impl:method1Request" name="method1Request"/>
<wsdl:output message="impl:method1Response" name="method1Response"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="GetXSLIMSoapBinding" type="impl:GetXSLIM">
<wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="method1">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="method1Request">
<wsdlsoap:body namespace="http://biryani.med.yale.edu:8081/axis/services/GetXSLIM" use="literal"/>
</wsdl:input>
<wsdl:output name="method1Response">
<wsdlsoap:body namespace="http://biryani.med.yale.edu:8081/axis/services/GetXSLIM" use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="GetXSLIMService">
<wsdl:port binding="impl:GetXSLIMSoapBinding" name="GetXSLIM">
<wsdlsoap:address location="http://biryani.med.yale.edu:8081/axis/services/GetXSLIM"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Bhanu Pabreja wrote:
>still does not work your server.
>
>Once you run your server and I hope it is visible on the internet I will
>have a look at your wsdl.
>
>Can u also post your wsdl file in the thread
>
>Thanx in advance,
>
>Bhanu
>
>
>
>-----Original Message-----
>From: remko de knikker [mailto:remko.deknikker@yale.edu]
>Sent: Tuesday, June 24, 2003 2:06 PM
>To: axis-user@ws.apache.org
>Subject: Re: Message Style and WSDL
>
>
>Bhanu,
>the only other thing that I know of, is that I need to restart my
>server, to make it work...?
>sorry,
>r
>
>Bhanu Pabreja wrote:
>
>
>
>>This what my deployment descriptor looks like :
>>
>><deployment name="test" xmlns="http://xml.apache.org/axis/wsdd/"
>> xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"
>> xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance">
>> <!-- note that either style="message" OR provider="java:MSG" both
>>
>>
>work -->
>
>
>> <service name="FirmTaxonomyModelService" style="message">
>> <parameter name="className"
>>value="com.dumdum.taxonomy.ws.FirmTaxonomyModelMessageStyleService" />
>> <parameter name="allowedMethods" value="*" />
>> </service>
>></deployment>
>>
>>
>>and my wsdl file looks like this:
>>
>><?xml version="1.0" encoding="UTF-8"?>
>><wsdl:definitions
>>targetNamespace="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyMode
>>
>>
>l
>
>
>>Service" xmlns="http://schemas.xmlsoap.org/wsdl/"
>>xmlns:apachesoap="http://xml.apache.org/xml-soap"
>>xmlns:impl="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServ
>>
>>
>i
>
>
>>ce"
>>xmlns:intf="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServ
>>
>>
>i
>
>
>>ce" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
>>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>>xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
>>xmlns:xsd="http://www.w3.org/2001/XMLSchema"><wsdl:types/>
>> <wsdl:message name="fetchDocumentResponse">
>> <wsdl:part name="fetchDocumentReturn" type="xsd:anyType"/>
>> </wsdl:message>
>> <wsdl:message name="fetchDocumentRequest">
>> </wsdl:message>
>> <wsdl:portType name="FirmTaxonomyModelMessageStyleService">
>> <wsdl:operation name="fetchDocument">
>> <wsdl:input message="intf:fetchDocumentRequest"
>>name="fetchDocumentRequest"/>
>> <wsdl:output message="intf:fetchDocumentResponse"
>>name="fetchDocumentResponse"/>
>> </wsdl:operation>
>> </wsdl:portType>
>> <wsdl:binding name="FirmTaxonomyModelServiceSoapBinding"
>>type="intf:FirmTaxonomyModelMessageStyleService">
>> <wsdlsoap:binding style="rpc"
>>transport="http://schemas.xmlsoap.org/soap/http"/>
>> <wsdl:operation name="fetchDocument">
>> <wsdlsoap:operation soapAction=""/>
>> <wsdl:input name="fetchDocumentRequest">
>> <wsdlsoap:body
>>encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
>>namespace="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServi
>>
>>
>c
>
>
>>e" use="encoded"/>
>> </wsdl:input>
>> <wsdl:output name="fetchDocumentResponse">
>> <wsdlsoap:body
>>encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
>>namespace="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServi
>>
>>
>c
>
>
>>e" use="encoded"/>
>> </wsdl:output>
>> </wsdl:operation>
>> </wsdl:binding>
>> <wsdl:service name="FirmTaxonomyModelMessageStyleServiceService">
>> <wsdl:port binding="intf:FirmTaxonomyModelServiceSoapBinding"
>>name="FirmTaxonomyModelService">
>> <wsdlsoap:address
>>location="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServic
>>
>>
>e
>
>
>>"/>
>> </wsdl:port>
>> </wsdl:service>
>></wsdl:definitions>
>>
>>Now this thing clearly says that this is RPC style service and everything
>>looks to be encoded.
>>
>>BTW I dont think so your server is up since I could not access your
>>webservice's wsdl file.
>>
>>Have a look and tell me where I am wrong.
>>
>>Bhanu.
>>
>>
>>
>>-----Original Message-----
>>From: remko de knikker [mailto:remko.deknikker@yale.edu]
>>Sent: Tuesday, June 24, 2003 9:01 AM
>>To: axis-user@ws.apache.org
>>Subject: Re: Message Style and WSDL
>>
>>
>>
>>Bhanu,
>>
>>here's my example for a message-style ws, which works for me.
>>
>><deployment name="GetXSLIM" xmlns="http://xml.apache.org/axis/wsdd/"
>> xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"
>> xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance">
>> <handler name="handlerXSLIM" type="java:ws.xslim.BasicHandler_XSLIM"/>
>> <service name="GetXSLIM" style="message">
>> <requestFlow>
>> <handler type="handlerXSLIM"/>
>> </requestFlow>
>> <responseFlow>
>> <handler type="handlerXSLIM"/>
>> </responseFlow>
>> <parameter name="className" value="ws.xslim.GetXSLIM" />
>> <parameter name="allowedMethods" value="method1" />
>> <parameter name="wsdlInputSchema"
>>value="http://biryani.med.yale.edu:8081/axis/files/xslim/GetXSLIM_method1Re
>>
>>
>q
>
>
>>uest.xsd"/>
>> </service>
>></deployment>
>>
>>Look at the result at
>>http://biryani.med.yale.edu:8081/axis/services/GetXSLIM?wsdl
>>
>>remko
>>
>>
>>Date: Mon, 23 Jun 2003 18:39:30 -0400
>>From: Bhanu Pabreja <pa...@infigroup.com>
>>To: axis-user@ws.apache.org
>>Reply-to: axis-user@ws.apache.org
>>Subject: Message Style and WSDL
>>One step beyond .jws files
>> I have made a message style service with one method
>>
>> public Document fetchData(Document doc){
>> // logic
>> }yl
>>
>> Then I deployed the service using the deploy.wsdd. I could not use the
>>Java2WSDL utitily to generate "Message" style service so I hand edited one
>>of the provided examples.
>>
>> But once I deploy it to the /servlet/AxisServlet and try to browse the
>>generated .wsdl file it is totally a different version of what I have made
>>.. I mean the wsdl says that it is a RPC style service and the operation is
>>encoded.
>>
>> Now the questions I can figure out is :
>>
>> (a) How to make a message style service and create a wsdl file which says
>>that it is a Message style service.
>>
>>
>> thanx in advance
>>
>>
>> dumdum420
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
Re: Exception handling strategy question
Posted by Anne Thomas Manes <an...@manes.net>.
Remko,
If you're working with the low-level API, then I guess you need to construct your SOAP fault manually (someone correct me if I'm wrong). A SOAP fault element must be the first and only child of the SOAP body element. You want to use addFault () to create a SOAPFault object and add it to the SOAPBody. Then you want to set the fault code and fault string and add the detail.
(This is using the SAAJ API).
Anne
----- Original Message -----
From: remko de knikker
To: axis-user@ws.apache.org
Sent: Friday, June 27, 2003 2:29 PM
Subject: Re: Exception handling strategy question
Response:
Anne, thanks for your response. The reason why I am returning a Document is because I need to return XML, this is just the way I defined/need to format my response(1). Because I must also be able to be invoked from all languages, I can't expect the clients to catch the Java Exceptions(2).
For these two reasons, I am trying to solve it by appending the mapped SOAPFault (created when the Exception was thrown) to the Document to be returned.
Question:
But how to append the SOAPFault object with 'appendChild(Node f)' which takes a Node?
I keep getting castExceptions when I try to cast the SOAPFault.
or maybe I am on the wrong track here, and this isn't the way to do it?
remko
Anne Thomas Manes wrote:
Remko,
You don't have to return a Document in order to ensure language-neutrality. The whole point of SOAP and WSDL is to provide a layer of abstraction between your object model and your message structure that ensures language-neutrality. Axis lets you return whatever your application would like to return, and then Axis will convert that return into a document for you. No matter how you define your service (RPC or Document -- whether you marshal the message or you let Axis marshal the message), the client SOAP processing engine (e.g., .NET, MS SOAP, PocketSOAP, SOAP::Lite, Axis, etc) will receive a document, and that SOAP processing engine can automatically transform that document into the appropriate language objects on the client side (VB, C#, Java, Perl, etc).
It's fine if you want your application to work directly with the XML -- the Axis Messaging style lets you do so -- but I want to make sure that you understand that you don't have to do so to ensure language-neutrality.
When you return a fault, you don't return a response message -- you return a fault message. Axis can automatically capture an exception and return that exception to the client in a fault message, but that doesn't help much if the client isn't Java. Therefore you need to define a fault message for each of your exceptions, and then tell Axis to map the exceptions to the faults accordingly.
Anne
----- Original Message -----
From: remko de knikker
To: axis-user@ws.apache.org
Sent: Friday, June 27, 2003 1:31 PM
Subject: Re: Exception handling strategy question
Situation:
OK, so far this helped, and pointed out the right direction in which to go. I had seen the SOAP Faults and understand now when to use them.
I use the document/literal or message style of web services in axis, since I am sending XML only.
I use the
'public Document method(Document doc)'
signature, and I need to be language neutral, and therefor have to return a Document regardless. The Java Exceptions are indeed caught by the client, but I can't use this method.
I managed to add a Fault to the SOAPBody object from the MessageContext and set its parameters, but as mentioned I need to return the Document, eg responseDoc, so the/any client can query this for Faults.... or do I have to deal with it differently??
Question:
How do I append the Fault object to the Document to be returned??
Anne Thomas Manes wrote:
There are four defined reasons to return a SOAP fault [1]:
- VersionMismatch: the request didn't specify the correct SOAP namespace
- MustUnderstand: a SOAP node did not understand a SOAP header that said
mustUnderstand='1'
- Client: the request failed either because it was malformed or contained
invalid data
- Server: the request failed because of some type of server error
Remko's example requires an error code of Client. The error report should be
returned in the fault <details> element. As long as you have Java on both
sides of the wire, the SOAP system on the client should be able to simply
rethrow the original exception (assuming that it has the exception class
installed). But if you intend to support non-Java clients, you should map
your various exceptions to specific SOAP fault messages.
[1] http://www.w3.org/TR/SOAP/#_Toc478383510
Regards,
Anne
----- Original Message -----
From: "George Jagodzinski" <ge...@fusionapps.com>
To: <ax...@ws.apache.org>
Sent: Tuesday, June 24, 2003 3:22 PM
Subject: RE: Exception handling strategy question
if you are refering to business logic that happens after the request has
been accepted I would say that the best way is to return some type of
error
report. I could be wrong but it seems like soap fault should only be
thrown
if there was a conformance issue. Someone please correct me if I am wrong.
--George
-----Original Message-----
From: remko de knikker [mailto:remko.deknikker@yale.edu]
Sent: Tuesday, June 24, 2003 3:22 PM
To: axis-user@ws.apache.org
Subject: Exception handling strategy question
when implementing a web service and a ws client, what is the general
design principle for exception handling, when
1. when user entered a non-valid input value, for instance it doesn't
exist in the database?
Do I simply through a SOAPFault or is it better to append my own
<doesnotexist> tag?
2. as a client, do I catch an xxxxException/Fault, do I look for the
soapenv:Fault tag or do I have to look the webservice specific <wserror>
tag??
What is the best design strategy here??
thanks,
r
Re: Exception handling strategy question
Posted by remko de knikker <re...@yale.edu>.
Response:
Anne, thanks for your response. The reason why I am returning a Document
is because I need to return XML, this is just the way I defined/need to
format my response(1). Because I must also be able to be invoked from
all languages, I can't expect the clients to catch the Java Exceptions(2).
For these two reasons, I am trying to solve it by appending the mapped
SOAPFault (created when the Exception was thrown) to the Document to be
returned.
Question:
But how to append the SOAPFault object with 'appendChild(Node f)' which
takes a Node?
I keep getting castExceptions when I try to cast the SOAPFault.
or maybe I am on the wrong track here, and this isn't the way to do it?
remko
Anne Thomas Manes wrote:
> Remko,
>
> You don't have to return a Document in order to ensure
> language-neutrality. The whole point of SOAP and WSDL is to provide a
> layer of abstraction between your object model and your message
> structure that ensures language-neutrality. Axis lets you return
> whatever your application would like to return, and then Axis will
> convert that return into a document for you. No matter how you define
> your service (RPC or Document -- whether you marshal the message or
> you let Axis marshal the message), the client SOAP processing engine
> (e.g., .NET, MS SOAP, PocketSOAP, SOAP::Lite, Axis, etc) will receive
> a document, and that SOAP processing engine can automatically
> transform that document into the appropriate language objects on the
> client side (VB, C#, Java, Perl, etc).
>
> It's fine if you want your application to work directly with the XML
> -- the Axis Messaging style lets you do so -- but I want to make sure
> that you understand that you don't have to do so to ensure
> language-neutrality.
>
> When you return a fault, you don't return a response message -- you
> return a fault message. Axis can automatically capture an exception
> and return that exception to the client in a fault message, but that
> doesn't help much if the client isn't Java. Therefore you need to
> define a fault message for each of your exceptions, and then tell Axis
> to map the exceptions to the faults accordingly.
>
> Anne
>
>
> ----- Original Message -----
> From: remko de knikker <ma...@yale.edu>
> To: axis-user@ws.apache.org <ma...@ws.apache.org>
> Sent: Friday, June 27, 2003 1:31 PM
> Subject: Re: Exception handling strategy question
>
> Situation:
> OK, so far this helped, and pointed out the right direction in
> which to go. I had seen the SOAP Faults and understand now when to
> use them.
> I use the document/literal or message style of web services in
> axis, since I am sending XML only.
> I use the
> 'public Document method(Document doc)'
> signature, and I need to be language neutral, and therefor have to
> return a Document regardless. The Java Exceptions are indeed
> caught by the client, but I can't use this method.
> I managed to add a Fault to the SOAPBody object from the
> MessageContext and set its parameters, but as mentioned I need to
> return the Document, eg responseDoc, so the/any client can query
> this for Faults.... or do I have to deal with it differently??
>
> Question:
> How do I append the Fault object to the Document to be returned??
>
>
>
>
>
>
> Anne Thomas Manes wrote:
>
>>There are four defined reasons to return a SOAP fault [1]:
>>- VersionMismatch: the request didn't specify the correct SOAP namespace
>>- MustUnderstand: a SOAP node did not understand a SOAP header that said
>>mustUnderstand='1'
>>- Client: the request failed either because it was malformed or contained
>>invalid data
>>- Server: the request failed because of some type of server error
>>
>>Remko's example requires an error code of Client. The error report should be
>>returned in the fault <details> element. As long as you have Java on both
>>sides of the wire, the SOAP system on the client should be able to simply
>>rethrow the original exception (assuming that it has the exception class
>>installed). But if you intend to support non-Java clients, you should map
>>your various exceptions to specific SOAP fault messages.
>>
>>[1] http://www.w3.org/TR/SOAP/#_Toc478383510
>>
>>Regards,
>>Anne
>>
>>----- Original Message -----
>>From: "George Jagodzinski" <ge...@fusionapps.com>
>>To: <ax...@ws.apache.org>
>>Sent: Tuesday, June 24, 2003 3:22 PM
>>Subject: RE: Exception handling strategy question
>>
>>
>>
>>
>>>if you are refering to business logic that happens after the request has
>>>been accepted I would say that the best way is to return some type of
>>>
>>>
>>error
>>
>>
>>>report. I could be wrong but it seems like soap fault should only be
>>>
>>>
>>thrown
>>
>>
>>>if there was a conformance issue. Someone please correct me if I am wrong.
>>>
>>>--George
>>>
>>>-----Original Message-----
>>>From: remko de knikker [mailto:remko.deknikker@yale.edu]
>>>Sent: Tuesday, June 24, 2003 3:22 PM
>>>To: axis-user@ws.apache.org
>>>Subject: Exception handling strategy question
>>>
>>>
>>>when implementing a web service and a ws client, what is the general
>>>design principle for exception handling, when
>>>1. when user entered a non-valid input value, for instance it doesn't
>>>exist in the database?
>>>Do I simply through a SOAPFault or is it better to append my own
>>><doesnotexist> tag?
>>>
>>>2. as a client, do I catch an xxxxException/Fault, do I look for the
>>>soapenv:Fault tag or do I have to look the webservice specific <wserror>
>>>tag??
>>>
>>>What is the best design strategy here??
>>>
>>>thanks,
>>>r
>>>
>>>
>>>
>>
>>
>>
>>
>
Re: Exception handling strategy question
Posted by Anne Thomas Manes <an...@manes.net>.
You don't *need* to define the SOAP faults, but you *should* do so if you want to ba able to support non-Java clients. If you don't define the faults, Axis will simply return the Java exception, and a VB.NET client has no idea what to do with a Java exception.
You define the SOAP fault <detail> information as a message <part>. A fault message is always formating using the document style.
Anne
----- Original Message -----
From: remko de knikker
To: axis-user@ws.apache.org
Sent: Monday, June 30, 2003 4:48 PM
Subject: Re: Exception handling strategy question
I am not a 100% sure, but as far as I understand it now, you don't need to specify the SOAP Faults in your xsd, these are SOAP specific, not part of your response message.
r
Tony Opatha wrote:
>Therefore you need to define a fault message for each of your exceptions, and then tell >Axis to map the exceptions to the faults accordingly.
So, this means that AXIS supports application-specific Faults for both document-style
and RPC-style so long as the .xsd schema for the custom Fault messages is specificied
as part of the WSDL, right?
thanks,
Tony
Anne Thomas Manes <an...@manes.net> wrote:
Remko,
You don't have to return a Document in order to ensure language-neutrality. The whole point of SOAP and WSDL is to provide a layer of abstraction between your object model and your message structure that ensures language-neutrality. Axis lets you return whatever your application would like to return, and then Axis will convert that return into a document for you. No matter how you define your service (RPC or Document -- whether you marshal the message or you let Axis marshal the message), the client SOAP processing engine (e.g., .NET, MS SOAP, PocketSOAP, SOAP::Lite, Axis, etc) will receive a document, and that SOAP processing engine can automatically transform that document into the appropriate language objects on the client side (VB, C#, Java, Perl, etc).
It's fine if you want your application to work directly with the XML -- the Axis Messaging style lets you do so -- but I want to make sure that you understand that you don't have to do so to ensure language-neutrality.
When you return a fault, you don't return a response message -- you return a fault message. Axis can automatically capture an exception and return that exception to the client in a fault message, but that doesn't help much if the client isn't Java. Therefore you need to define a fault message for each of your exceptions, and then tell Axis to map the exceptions to the faults accordingly.
Anne
----- Original Message -----
From: remko de knikker
To: axis-user@ws.apache.org
Sent: Friday, June 27, 2003 1:31 PM
Subject: Re: Exception handling strategy question
Situation:
OK, so far this helped, and pointed out the right direction in which to go. I had seen the SOAP Faults and understand now when to use them.
I use the document/literal or message style of web services in axis, since I am sending XML only.
I use the
'public Document method(Document doc)'
signature, and I need to be language neutral, and therefor have to return a Document regardless. The Java Exceptions are indeed caught by the client, but I can't use this method.
I managed to add a Fault to the SOAPBody object from the MessageContext and set its parameters, but as mentioned I need to return the Document, eg responseDoc, so the/any client can query this for Faults.... or do I have to deal with it differently??
Question:
How do I append the Fault object to the Document to be returned??
Anne Thomas Manes wrote:
There are four defined reasons to return a SOAP fault [1]:
- VersionMismatch: the request didn't specify the correct SOAP namespace
- MustUnderstand: a SOAP node did not understand a SOAP header that said
mustUnderstand='1'
- Client: the request failed either because it was malformed or contained
invalid data
- Server: the request failed because of some type of server error
Remko's example requires an error code of Client. The error report should be
returned in the fault <details> element. As long as you have Java on both
sides of the wire, the SOAP system on the client should be able to simply
rethrow the original exception (assuming that it has the exception class
installed). But if you intend to support non-Java clients, you should map
your various exceptions to specific SOAP fault messages.
[1] http://www.w3.org/TR/SOAP/#_Toc478383510
Regards,
Anne
----- Original Message -----
From: "George Jagodzinski" <ge...@fusionapps.com>
To: <ax...@ws.apache.org>
Sent: Tuesday, June 24, 2003 3:22 PM
Subject: RE: Exception handling strategy question
if you are refering to business logic that happens after the request has
been accepted I would say that the best way is to return some type of
error
report. I could be wrong but it seems like soap fault should only be
thrown
if there was a conformance issue. Someone please correct me if I am wrong.
--George
-----Original Message-----
From: remko de knikker [mailto:remko.deknikker@yale.edu]
Sent: Tuesday, June 24, 2003 3:22 PM
To: axis-user@ws.apache.org
Subject: Exception handling strategy question
when implementing a web service and a ws client, what is the general
design principle for exception handling, when
1. when user entered a non-valid input value, for instance it doesn't
exist in the database?
Do I simply through a SOAPFault or is it better to append my own
<doesnotexist> tag?
2. as a client, do I catch an xxxxException/Fault, do I look for the
soapenv:Fault tag or do I have to look the webservice specific <wserror>
tag??
What is the best design strategy here??
thanks,
r
----------------------------------------------------------------------------
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
Re: Exception handling strategy question
Posted by remko de knikker <re...@yale.edu>.
I am not a 100% sure, but as far as I understand it now, you don't need
to specify the SOAP Faults in your xsd, these are SOAP specific, not
part of your response message.
r
Tony Opatha wrote:
> >Therefore you need to define a fault message for each of your
> exceptions, and then tell >Axis to map the exceptions to the faults
> accordingly.
>
> So, this means that AXIS supports application-specific Faults for both
> document-style
> and RPC-style so long as the .xsd schema for the custom Fault messages
> is specificied
> as part of the WSDL, right?
>
> thanks,
> Tony
>
>
>
>
>
>
> Anne Thomas Manes <an...@manes.net> wrote:
>
> Remko,
>
> You don't have to return a Document in order to ensure
> language-neutrality. The whole point of SOAP and WSDL is to
> provide a layer of abstraction between your object model and your
> message structure that ensures language-neutrality. Axis lets you
> return whatever your application would like to return, and then
> Axis will convert that return into a document for you. No matter
> how you define your service (RPC or Document -- whether you
> marshal the message or you let Axis marshal the message), the
> client SOAP processing engine (e.g., .NET, MS SOAP, PocketSOAP,
> SOAP::Lite, Axis, etc) will receive a document, and that SOAP
> processing engine can automatically transform that document into
> the appropriate language objects on the client side (VB, C#, Java,
> Perl, etc).
>
> It's fine if you want your application to work directly with the
> XML -- the Axis Messaging style lets you do so -- but I want to
> make sure that you understand that you don't have to do so to
> ensure language-neutrality.
>
> When you return a fault, you don't return a response message --
> you return a fault message. Axis can automatically capture an
> exception and return that exception to the client in a fault
> message, but that doesn't help much if the client isn't Java.
> Therefore you need to define a fault message for each of your
> exceptions, and then tell Axis to map the exceptions to the faults
> accordingly.
>
> Anne
>
>
> ----- Original Message -----
> From: remko de knikker <ma...@yale.edu>
> To: axis-user@ws.apache.org <ma...@ws.apache.org>
> Sent: Friday, June 27, 2003 1:31 PM
> Subject: Re: Exception handling strategy question
>
> Situation:
> OK, so far this helped, and pointed out the right direction in
> which to go. I had seen the SOAP Faults and understand now
> when to use them.
> I use the document/literal or message style of web services in
> axis, since I am sending XML only.
> I use the
> 'public Document method(Document doc)'
> signature, and I need to be language neutral, and therefor
> have to return a Document regardless. The Java Exceptions are
> indeed caught by the client, but I can't use this method.
> I managed to add a Fault to the SOAPBody object from the
> MessageContext and set its parameters, but as mentioned I need
> to return the Document, eg responseDoc, so the/any client can
> query this for Faults.... or do I have to deal with it
> differently??
>
> Question:
> How do I append the Fault object to the Document to be returned??
>
>
>
>
>
>
> Anne Thomas Manes wrote:
>
>>There are four defined reasons to return a SOAP fault [1]:
>>- VersionMismatch: the request didn't specify the correct SOAP namespace
>>- MustUnderstand: a SOAP node did not understand a SOAP header that said
>>mustUnderstand='1'
>>- Client: the request failed either because it was malformed or contained
>>invalid data
>>- Server: the request failed because of some type of server error
>>
>>Remko's example requires an error code of Client. The error report should be
>>returned in the fault <details> element. As long as you have Java on both
>>sides of the wire, the SOAP system on the client should be able to simply
>>rethrow the original exception (assuming that it has the exception class
>>installed). But if you intend to support non-Java clients, you should map
>>your various exceptions to specific SOAP fault messages.
>>
>>[1] http://www.w3.org/TR/SOAP/#_Toc478383510
>>
>>Regards,
>>Anne
>>
>>----- Original Message -----
>>From: "George Jagodzinski" <ge...@fusionapps.com>
>>To: <ax...@ws.apache.org>
>>Sent: Tuesday, June 24, 2003 3:22 PM
>>Subject: RE: Exception handling strategy question
>>
>>
>>
>>
>>>if you are refering to business logic that happens after the request has
>>>been accepted I would say that the best way is to return some type of
>>>
>>>
>>error
>>
>>
>>>report. I could be wrong but it seems like soap fault should only be
>>>
>>>
>>thrown
>>
>>
>>>if there was a conformance issue. Someone please correct me if I am wrong.
>>>
>>>--George
>>>
>>>-----Original Message-----
>>>From: remko de knikker [mailto:remko.deknikker@yale.edu]
>>>Sent: Tuesday, June 24, 2003 3:22 PM
>>>To: axis-user@ws.apache.org
>>>Subject: Exception handling strategy question
>>>
>>>
>>>when implementing a web service and a ws client, what is the general
>>>design principle for exception handling, when
>>>1. when user entered a non-valid input value, for instance it doesn't
>>>exist in the database?
>>>Do I simply through a SOAPFault or is it better to append my own
>>><doesnotexist> tag?
>>>
>>>2. as a client, do I catch an xxxxException/Fault, do I look for the
>>>soapenv:Fault tag or do I have to look the webservice specific <wserror>
>>>tag??
>>>
>>>What is the best design strategy here??
>>>
>>>thanks,
>>>r
>>>
>>>
>>>
>>
>>
>>
>>
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> SBC Yahoo! DSL
> <http://pa.yahoo.com/*http://rd.yahoo.com/evt=1207/*http://promo.yahoo.com/sbc/>
> - Now only $29.95 per month!
Re: Exception handling strategy question
Posted by Tony Opatha <to...@yahoo.com>.
>Therefore you need to define a fault message for each of your exceptions, and then tell >Axis to map the exceptions to the faults accordingly.
So, this means that AXIS supports application-specific Faults for both document-style
and RPC-style so long as the .xsd schema for the custom Fault messages is specificied
as part of the WSDL, right?
thanks,
Tony
Anne Thomas Manes <an...@manes.net> wrote:
Remko,
You don't have to return a Document in order to ensure language-neutrality. The whole point of SOAP and WSDL is to provide a layer of abstraction between your object model and your message structure that ensures language-neutrality. Axis lets you return whatever your application would like to return, and then Axis will convert that return into a document for you. No matter how you define your service (RPC or Document -- whether you marshal the message or you let Axis marshal the message), the client SOAP processing engine (e.g., .NET, MS SOAP, PocketSOAP, SOAP::Lite, Axis, etc) will receive a document, and that SOAP processing engine can automatically transform that document into the appropriate language objects on the client side (VB, C#, Java, Perl, etc).
It's fine if you want your application to work directly with the XML -- the Axis Messaging style lets you do so -- but I want to make sure that you understand that you don't have to do so to ensure language-neutrality.
When you return a fault, you don't return a response message -- you return a fault message. Axis can automatically capture an exception and return that exception to the client in a fault message, but that doesn't help much if the client isn't Java. Therefore you need to define a fault message for each of your exceptions, and then tell Axis to map the exceptions to the faults accordingly.
Anne
----- Original Message -----
From: remko de knikker
To: axis-user@ws.apache.org
Sent: Friday, June 27, 2003 1:31 PM
Subject: Re: Exception handling strategy question
Situation:
OK, so far this helped, and pointed out the right direction in which to go. I had seen the SOAP Faults and understand now when to use them.
I use the document/literal or message style of web services in axis, since I am sending XML only.
I use the
'public Document method(Document doc)'
signature, and I need to be language neutral, and therefor have to return a Document regardless. The Java Exceptions are indeed caught by the client, but I can't use this method.
I managed to add a Fault to the SOAPBody object from the MessageContext and set its parameters, but as mentioned I need to return the Document, eg responseDoc, so the/any client can query this for Faults.... or do I have to deal with it differently??
Question:
How do I append the Fault object to the Document to be returned??
Anne Thomas Manes wrote:
There are four defined reasons to return a SOAP fault [1]:- VersionMismatch: the request didn't specify the correct SOAP namespace- MustUnderstand: a SOAP node did not understand a SOAP header that saidmustUnderstand='1'- Client: the request failed either because it was malformed or containedinvalid data- Server: the request failed because of some type of server errorRemko's example requires an error code of Client. The error report should bereturned in the fault <details> element. As long as you have Java on bothsides of the wire, the SOAP system on the client should be able to simplyrethrow the original exception (assuming that it has the exception classinstalled). But if you intend to support non-Java clients, you should mapyour various exceptions to specific SOAP fault messages.[1] http://www.w3.org/TR/SOAP/#_Toc478383510Regards,Anne----- Original Message -----From: "George Jagodzinski" <ge...@fusionapps.com>To: <ax...@ws.apache.org>Sent: Tuesday, June 24, 2003 3:22
PMSubject: RE: Exception handling strategy question
if you are refering to business logic that happens after the request hasbeen accepted I would say that the best way is to return some type of
error
report. I could be wrong but it seems like soap fault should only be
thrown
if there was a conformance issue. Someone please correct me if I am wrong.--George-----Original Message-----From: remko de knikker [mailto:remko.deknikker@yale.edu]Sent: Tuesday, June 24, 2003 3:22 PMTo: axis-user@ws.apache.orgSubject: Exception handling strategy questionwhen implementing a web service and a ws client, what is the generaldesign principle for exception handling, when1. when user entered a non-valid input value, for instance it doesn'texist in the database?Do I simply through a SOAPFault or is it better to append my own<doesnotexist> tag?2. as a client, do I catch an xxxxException/Fault, do I look for thesoapenv:Fault tag or do I have to look the webservice specific <wserror>tag??What is the best design strategy here??thanks,r
---------------------------------
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
Re: Exception handling strategy question
Posted by Tony Opatha <to...@yahoo.com>.
>Therefore you need to define a fault message for each of your exceptions, and then tell >Axis to map the exceptions to the faults accordingly.
So, this means that AXIS supports application-specific Faults for both document-style
and RPC-style so long as the .xsd schema for the custom Fault messages is specificied
as part of the WSDL, right?
thanks,
Tony
Anne Thomas Manes <an...@manes.net> wrote:
Remko,
You don't have to return a Document in order to ensure language-neutrality. The whole point of SOAP and WSDL is to provide a layer of abstraction between your object model and your message structure that ensures language-neutrality. Axis lets you return whatever your application would like to return, and then Axis will convert that return into a document for you. No matter how you define your service (RPC or Document -- whether you marshal the message or you let Axis marshal the message), the client SOAP processing engine (e.g., .NET, MS SOAP, PocketSOAP, SOAP::Lite, Axis, etc) will receive a document, and that SOAP processing engine can automatically transform that document into the appropriate language objects on the client side (VB, C#, Java, Perl, etc).
It's fine if you want your application to work directly with the XML -- the Axis Messaging style lets you do so -- but I want to make sure that you understand that you don't have to do so to ensure language-neutrality.
When you return a fault, you don't return a response message -- you return a fault message. Axis can automatically capture an exception and return that exception to the client in a fault message, but that doesn't help much if the client isn't Java. Therefore you need to define a fault message for each of your exceptions, and then tell Axis to map the exceptions to the faults accordingly.
Anne
----- Original Message -----
From: remko de knikker
To: axis-user@ws.apache.org
Sent: Friday, June 27, 2003 1:31 PM
Subject: Re: Exception handling strategy question
Situation:
OK, so far this helped, and pointed out the right direction in which to go. I had seen the SOAP Faults and understand now when to use them.
I use the document/literal or message style of web services in axis, since I am sending XML only.
I use the
'public Document method(Document doc)'
signature, and I need to be language neutral, and therefor have to return a Document regardless. The Java Exceptions are indeed caught by the client, but I can't use this method.
I managed to add a Fault to the SOAPBody object from the MessageContext and set its parameters, but as mentioned I need to return the Document, eg responseDoc, so the/any client can query this for Faults.... or do I have to deal with it differently??
Question:
How do I append the Fault object to the Document to be returned??
Anne Thomas Manes wrote:
There are four defined reasons to return a SOAP fault [1]:- VersionMismatch: the request didn't specify the correct SOAP namespace- MustUnderstand: a SOAP node did not understand a SOAP header that saidmustUnderstand='1'- Client: the request failed either because it was malformed or containedinvalid data- Server: the request failed because of some type of server errorRemko's example requires an error code of Client. The error report should bereturned in the fault <details> element. As long as you have Java on bothsides of the wire, the SOAP system on the client should be able to simplyrethrow the original exception (assuming that it has the exception classinstalled). But if you intend to support non-Java clients, you should mapyour various exceptions to specific SOAP fault messages.[1] http://www.w3.org/TR/SOAP/#_Toc478383510Regards,Anne----- Original Message -----From: "George Jagodzinski" <ge...@fusionapps.com>To: <ax...@ws.apache.org>Sent: Tuesday, June 24, 2003 3:22
PMSubject: RE: Exception handling strategy question
if you are refering to business logic that happens after the request hasbeen accepted I would say that the best way is to return some type of
error
report. I could be wrong but it seems like soap fault should only be
thrown
if there was a conformance issue. Someone please correct me if I am wrong.--George-----Original Message-----From: remko de knikker [mailto:remko.deknikker@yale.edu]Sent: Tuesday, June 24, 2003 3:22 PMTo: axis-user@ws.apache.orgSubject: Exception handling strategy questionwhen implementing a web service and a ws client, what is the generaldesign principle for exception handling, when1. when user entered a non-valid input value, for instance it doesn'texist in the database?Do I simply through a SOAPFault or is it better to append my own<doesnotexist> tag?2. as a client, do I catch an xxxxException/Fault, do I look for thesoapenv:Fault tag or do I have to look the webservice specific <wserror>tag??What is the best design strategy here??thanks,r
---------------------------------
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
Re: Exception handling strategy question
Posted by Anne Thomas Manes <an...@manes.net>.
Remko,
You don't have to return a Document in order to ensure language-neutrality. The whole point of SOAP and WSDL is to provide a layer of abstraction between your object model and your message structure that ensures language-neutrality. Axis lets you return whatever your application would like to return, and then Axis will convert that return into a document for you. No matter how you define your service (RPC or Document -- whether you marshal the message or you let Axis marshal the message), the client SOAP processing engine (e.g., .NET, MS SOAP, PocketSOAP, SOAP::Lite, Axis, etc) will receive a document, and that SOAP processing engine can automatically transform that document into the appropriate language objects on the client side (VB, C#, Java, Perl, etc).
It's fine if you want your application to work directly with the XML -- the Axis Messaging style lets you do so -- but I want to make sure that you understand that you don't have to do so to ensure language-neutrality.
When you return a fault, you don't return a response message -- you return a fault message. Axis can automatically capture an exception and return that exception to the client in a fault message, but that doesn't help much if the client isn't Java. Therefore you need to define a fault message for each of your exceptions, and then tell Axis to map the exceptions to the faults accordingly.
Anne
----- Original Message -----
From: remko de knikker
To: axis-user@ws.apache.org
Sent: Friday, June 27, 2003 1:31 PM
Subject: Re: Exception handling strategy question
Situation:
OK, so far this helped, and pointed out the right direction in which to go. I had seen the SOAP Faults and understand now when to use them.
I use the document/literal or message style of web services in axis, since I am sending XML only.
I use the
'public Document method(Document doc)'
signature, and I need to be language neutral, and therefor have to return a Document regardless. The Java Exceptions are indeed caught by the client, but I can't use this method.
I managed to add a Fault to the SOAPBody object from the MessageContext and set its parameters, but as mentioned I need to return the Document, eg responseDoc, so the/any client can query this for Faults.... or do I have to deal with it differently??
Question:
How do I append the Fault object to the Document to be returned??
Anne Thomas Manes wrote:
There are four defined reasons to return a SOAP fault [1]:
- VersionMismatch: the request didn't specify the correct SOAP namespace
- MustUnderstand: a SOAP node did not understand a SOAP header that said
mustUnderstand='1'
- Client: the request failed either because it was malformed or contained
invalid data
- Server: the request failed because of some type of server error
Remko's example requires an error code of Client. The error report should be
returned in the fault <details> element. As long as you have Java on both
sides of the wire, the SOAP system on the client should be able to simply
rethrow the original exception (assuming that it has the exception class
installed). But if you intend to support non-Java clients, you should map
your various exceptions to specific SOAP fault messages.
[1] http://www.w3.org/TR/SOAP/#_Toc478383510
Regards,
Anne
----- Original Message -----
From: "George Jagodzinski" <ge...@fusionapps.com>
To: <ax...@ws.apache.org>
Sent: Tuesday, June 24, 2003 3:22 PM
Subject: RE: Exception handling strategy question
if you are refering to business logic that happens after the request has
been accepted I would say that the best way is to return some type of
error
report. I could be wrong but it seems like soap fault should only be
thrown
if there was a conformance issue. Someone please correct me if I am wrong.
--George
-----Original Message-----
From: remko de knikker [mailto:remko.deknikker@yale.edu]
Sent: Tuesday, June 24, 2003 3:22 PM
To: axis-user@ws.apache.org
Subject: Exception handling strategy question
when implementing a web service and a ws client, what is the general
design principle for exception handling, when
1. when user entered a non-valid input value, for instance it doesn't
exist in the database?
Do I simply through a SOAPFault or is it better to append my own
<doesnotexist> tag?
2. as a client, do I catch an xxxxException/Fault, do I look for the
soapenv:Fault tag or do I have to look the webservice specific <wserror>
tag??
What is the best design strategy here??
thanks,
r
Re: Exception handling strategy question
Posted by remko de knikker <re...@yale.edu>.
Situation:
OK, so far this helped, and pointed out the right direction in which to
go. I had seen the SOAP Faults and understand now when to use them.
I use the document/literal or message style of web services in axis,
since I am sending XML only.
I use the
'public Document method(Document doc)'
signature, and I need to be language neutral, and therefor have to
return a Document regardless. The Java Exceptions are indeed caught by
the client, but I can't use this method.
I managed to add a Fault to the SOAPBody object from the MessageContext
and set its parameters, but as mentioned I need to return the Document,
eg responseDoc, so the/any client can query this for Faults.... or do I
have to deal with it differently??
Question:
How do I append the Fault object to the Document to be returned??
Anne Thomas Manes wrote:
>There are four defined reasons to return a SOAP fault [1]:
>- VersionMismatch: the request didn't specify the correct SOAP namespace
>- MustUnderstand: a SOAP node did not understand a SOAP header that said
>mustUnderstand='1'
>- Client: the request failed either because it was malformed or contained
>invalid data
>- Server: the request failed because of some type of server error
>
>Remko's example requires an error code of Client. The error report should be
>returned in the fault <details> element. As long as you have Java on both
>sides of the wire, the SOAP system on the client should be able to simply
>rethrow the original exception (assuming that it has the exception class
>installed). But if you intend to support non-Java clients, you should map
>your various exceptions to specific SOAP fault messages.
>
>[1] http://www.w3.org/TR/SOAP/#_Toc478383510
>
>Regards,
>Anne
>
>----- Original Message -----
>From: "George Jagodzinski" <ge...@fusionapps.com>
>To: <ax...@ws.apache.org>
>Sent: Tuesday, June 24, 2003 3:22 PM
>Subject: RE: Exception handling strategy question
>
>
>
>
>>if you are refering to business logic that happens after the request has
>>been accepted I would say that the best way is to return some type of
>>
>>
>error
>
>
>>report. I could be wrong but it seems like soap fault should only be
>>
>>
>thrown
>
>
>>if there was a conformance issue. Someone please correct me if I am wrong.
>>
>>--George
>>
>>-----Original Message-----
>>From: remko de knikker [mailto:remko.deknikker@yale.edu]
>>Sent: Tuesday, June 24, 2003 3:22 PM
>>To: axis-user@ws.apache.org
>>Subject: Exception handling strategy question
>>
>>
>>when implementing a web service and a ws client, what is the general
>>design principle for exception handling, when
>>1. when user entered a non-valid input value, for instance it doesn't
>>exist in the database?
>>Do I simply through a SOAPFault or is it better to append my own
>><doesnotexist> tag?
>>
>>2. as a client, do I catch an xxxxException/Fault, do I look for the
>>soapenv:Fault tag or do I have to look the webservice specific <wserror>
>>tag??
>>
>>What is the best design strategy here??
>>
>>thanks,
>>r
>>
>>
>>
>
>
>
>
RE: Exception handling strategy question
Posted by George Jagodzinski <ge...@fusionapps.com>.
oh....so thats why they keep writing all of these standards. I guess I
actually have to read them.
Thanks
-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Tuesday, June 24, 2003 3:53 PM
To: axis-user@ws.apache.org; george@fusionapps.com
Subject: Re: Exception handling strategy question
There are four defined reasons to return a SOAP fault [1]:
- VersionMismatch: the request didn't specify the correct SOAP namespace
- MustUnderstand: a SOAP node did not understand a SOAP header that said
mustUnderstand='1'
- Client: the request failed either because it was malformed or contained
invalid data
- Server: the request failed because of some type of server error
Remko's example requires an error code of Client. The error report should be
returned in the fault <details> element. As long as you have Java on both
sides of the wire, the SOAP system on the client should be able to simply
rethrow the original exception (assuming that it has the exception class
installed). But if you intend to support non-Java clients, you should map
your various exceptions to specific SOAP fault messages.
[1] http://www.w3.org/TR/SOAP/#_Toc478383510
Regards,
Anne
Re: Exception handling strategy question
Posted by Anne Thomas Manes <an...@manes.net>.
There are four defined reasons to return a SOAP fault [1]:
- VersionMismatch: the request didn't specify the correct SOAP namespace
- MustUnderstand: a SOAP node did not understand a SOAP header that said
mustUnderstand='1'
- Client: the request failed either because it was malformed or contained
invalid data
- Server: the request failed because of some type of server error
Remko's example requires an error code of Client. The error report should be
returned in the fault <details> element. As long as you have Java on both
sides of the wire, the SOAP system on the client should be able to simply
rethrow the original exception (assuming that it has the exception class
installed). But if you intend to support non-Java clients, you should map
your various exceptions to specific SOAP fault messages.
[1] http://www.w3.org/TR/SOAP/#_Toc478383510
Regards,
Anne
----- Original Message -----
From: "George Jagodzinski" <ge...@fusionapps.com>
To: <ax...@ws.apache.org>
Sent: Tuesday, June 24, 2003 3:22 PM
Subject: RE: Exception handling strategy question
> if you are refering to business logic that happens after the request has
> been accepted I would say that the best way is to return some type of
error
> report. I could be wrong but it seems like soap fault should only be
thrown
> if there was a conformance issue. Someone please correct me if I am wrong.
>
> --George
>
> -----Original Message-----
> From: remko de knikker [mailto:remko.deknikker@yale.edu]
> Sent: Tuesday, June 24, 2003 3:22 PM
> To: axis-user@ws.apache.org
> Subject: Exception handling strategy question
>
>
> when implementing a web service and a ws client, what is the general
> design principle for exception handling, when
> 1. when user entered a non-valid input value, for instance it doesn't
> exist in the database?
> Do I simply through a SOAPFault or is it better to append my own
> <doesnotexist> tag?
>
> 2. as a client, do I catch an xxxxException/Fault, do I look for the
> soapenv:Fault tag or do I have to look the webservice specific <wserror>
> tag??
>
> What is the best design strategy here??
>
> thanks,
> r
>
RE: Exception handling strategy question
Posted by George Jagodzinski <ge...@fusionapps.com>.
if you are refering to business logic that happens after the request has
been accepted I would say that the best way is to return some type of error
report. I could be wrong but it seems like soap fault should only be thrown
if there was a conformance issue. Someone please correct me if I am wrong.
--George
-----Original Message-----
From: remko de knikker [mailto:remko.deknikker@yale.edu]
Sent: Tuesday, June 24, 2003 3:22 PM
To: axis-user@ws.apache.org
Subject: Exception handling strategy question
when implementing a web service and a ws client, what is the general
design principle for exception handling, when
1. when user entered a non-valid input value, for instance it doesn't
exist in the database?
Do I simply through a SOAPFault or is it better to append my own
<doesnotexist> tag?
2. as a client, do I catch an xxxxException/Fault, do I look for the
soapenv:Fault tag or do I have to look the webservice specific <wserror>
tag??
What is the best design strategy here??
thanks,
r
Exception handling strategy question
Posted by remko de knikker <re...@yale.edu>.
when implementing a web service and a ws client, what is the general
design principle for exception handling, when
1. when user entered a non-valid input value, for instance it doesn't
exist in the database?
Do I simply through a SOAPFault or is it better to append my own
<doesnotexist> tag?
2. as a client, do I catch an xxxxException/Fault, do I look for the
soapenv:Fault tag or do I have to look the webservice specific <wserror>
tag??
What is the best design strategy here??
thanks,
r
exception on testing Axis Service
Posted by Samir Shaikh <ss...@worldres.com>.
Hi All,
I see the following exception in catalina.out every now and then. The server
doesn't seem to die because of this but I am curious what causes this. I
also run into certain OutOfMemory errors if I hit my service hard enough.
Any pointers to make my Axis service more stable will be very appreciated.
- java.io.IOException:
java.net.SocketException: Socket closed
at java.net.SocketOutputStream.socketWrite0(Native Method)
at
java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:126)
at
org.apache.coyote.http11.InternalOutputBuffer$OutputStreamOutputBuffer.doWri
te(InternalOutputBuffer.java:652)
at
org.apache.coyote.http11.InternalOutputBuffer.doWrite(InternalOutputBuffer.j
ava:521)
at org.apache.coyote.Response.doWrite(Response.java:513)
at
org.apache.coyote.tomcat4.OutputBuffer.realWriteBytes(OutputBuffer.java:380)
at
org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:360)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:346)
at
org.apache.coyote.tomcat4.OutputBuffer.writeBytes(OutputBuffer.java:407)
at
org.apache.coyote.tomcat4.OutputBuffer.write(OutputBuffer.java:394)
at
org.apache.coyote.tomcat4.CoyoteOutputStream.write(CoyoteOutputStream.java:1
10)
at
sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(StreamEncoder.java:334)
at
sun.nio.cs.StreamEncoder$CharsetSE.implWrite(StreamEncoder.java:394)
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:134)
at java.io.OutputStreamWriter.write(OutputStreamWriter.java:191)
at java.io.BufferedWriter.flushBuffer(BufferedWriter.java:111)
at java.io.BufferedWriter.write(BufferedWriter.java:206)
at java.io.Writer.write(Writer.java:126)
at org.apache.axis.SOAPPart.writeTo(SOAPPart.java:280)
at org.apache.axis.Message.writeTo(Message.java:441)
at
org.apache.axis.transport.http.AxisServlet.sendResponse(AxisServlet.java:825
)
at
org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:744)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at
org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:
335)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:260)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2396)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180
)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
java:170)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172
)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:405)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
ction(Http11Protocol.java:380)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:508)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:533)
at java.lang.Thread.run(Thread.java:536)
Jun 24, 2003 10:32:27 AM
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler
processConnection
INFO: SocketException reading request, ignored
Thanks,
Samir
WorldRes Inc.
RE: Message Style and WSDL
Posted by Bhanu Pabreja <pa...@infigroup.com>.
still does not work your server.
Once you run your server and I hope it is visible on the internet I will
have a look at your wsdl.
Can u also post your wsdl file in the thread
Thanx in advance,
Bhanu
-----Original Message-----
From: remko de knikker [mailto:remko.deknikker@yale.edu]
Sent: Tuesday, June 24, 2003 2:06 PM
To: axis-user@ws.apache.org
Subject: Re: Message Style and WSDL
Bhanu,
the only other thing that I know of, is that I need to restart my
server, to make it work...?
sorry,
r
Bhanu Pabreja wrote:
>This what my deployment descriptor looks like :
>
><deployment name="test" xmlns="http://xml.apache.org/axis/wsdd/"
> xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"
> xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance">
> <!-- note that either style="message" OR provider="java:MSG" both
work -->
> <service name="FirmTaxonomyModelService" style="message">
> <parameter name="className"
>value="com.dumdum.taxonomy.ws.FirmTaxonomyModelMessageStyleService" />
> <parameter name="allowedMethods" value="*" />
> </service>
></deployment>
>
>
>and my wsdl file looks like this:
>
><?xml version="1.0" encoding="UTF-8"?>
><wsdl:definitions
>targetNamespace="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyMode
l
>Service" xmlns="http://schemas.xmlsoap.org/wsdl/"
>xmlns:apachesoap="http://xml.apache.org/xml-soap"
>xmlns:impl="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServ
i
>ce"
>xmlns:intf="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServ
i
>ce" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
>xmlns:xsd="http://www.w3.org/2001/XMLSchema"><wsdl:types/>
> <wsdl:message name="fetchDocumentResponse">
> <wsdl:part name="fetchDocumentReturn" type="xsd:anyType"/>
> </wsdl:message>
> <wsdl:message name="fetchDocumentRequest">
> </wsdl:message>
> <wsdl:portType name="FirmTaxonomyModelMessageStyleService">
> <wsdl:operation name="fetchDocument">
> <wsdl:input message="intf:fetchDocumentRequest"
>name="fetchDocumentRequest"/>
> <wsdl:output message="intf:fetchDocumentResponse"
>name="fetchDocumentResponse"/>
> </wsdl:operation>
> </wsdl:portType>
> <wsdl:binding name="FirmTaxonomyModelServiceSoapBinding"
>type="intf:FirmTaxonomyModelMessageStyleService">
> <wsdlsoap:binding style="rpc"
>transport="http://schemas.xmlsoap.org/soap/http"/>
> <wsdl:operation name="fetchDocument">
> <wsdlsoap:operation soapAction=""/>
> <wsdl:input name="fetchDocumentRequest">
> <wsdlsoap:body
>encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
>namespace="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServi
c
>e" use="encoded"/>
> </wsdl:input>
> <wsdl:output name="fetchDocumentResponse">
> <wsdlsoap:body
>encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
>namespace="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServi
c
>e" use="encoded"/>
> </wsdl:output>
> </wsdl:operation>
> </wsdl:binding>
> <wsdl:service name="FirmTaxonomyModelMessageStyleServiceService">
> <wsdl:port binding="intf:FirmTaxonomyModelServiceSoapBinding"
>name="FirmTaxonomyModelService">
> <wsdlsoap:address
>location="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServic
e
>"/>
> </wsdl:port>
> </wsdl:service>
></wsdl:definitions>
>
>Now this thing clearly says that this is RPC style service and everything
>looks to be encoded.
>
>BTW I dont think so your server is up since I could not access your
>webservice's wsdl file.
>
>Have a look and tell me where I am wrong.
>
>Bhanu.
>
>
>
>-----Original Message-----
>From: remko de knikker [mailto:remko.deknikker@yale.edu]
>Sent: Tuesday, June 24, 2003 9:01 AM
>To: axis-user@ws.apache.org
>Subject: Re: Message Style and WSDL
>
>
>
>Bhanu,
>
>here's my example for a message-style ws, which works for me.
>
><deployment name="GetXSLIM" xmlns="http://xml.apache.org/axis/wsdd/"
> xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"
> xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance">
> <handler name="handlerXSLIM" type="java:ws.xslim.BasicHandler_XSLIM"/>
> <service name="GetXSLIM" style="message">
> <requestFlow>
> <handler type="handlerXSLIM"/>
> </requestFlow>
> <responseFlow>
> <handler type="handlerXSLIM"/>
> </responseFlow>
> <parameter name="className" value="ws.xslim.GetXSLIM" />
> <parameter name="allowedMethods" value="method1" />
> <parameter name="wsdlInputSchema"
>value="http://biryani.med.yale.edu:8081/axis/files/xslim/GetXSLIM_method1Re
q
>uest.xsd"/>
> </service>
></deployment>
>
>Look at the result at
>http://biryani.med.yale.edu:8081/axis/services/GetXSLIM?wsdl
>
>remko
>
>
>Date: Mon, 23 Jun 2003 18:39:30 -0400
>From: Bhanu Pabreja <pa...@infigroup.com>
>To: axis-user@ws.apache.org
>Reply-to: axis-user@ws.apache.org
>Subject: Message Style and WSDL
>One step beyond .jws files
> I have made a message style service with one method
>
> public Document fetchData(Document doc){
> // logic
> }yl
>
> Then I deployed the service using the deploy.wsdd. I could not use the
>Java2WSDL utitily to generate "Message" style service so I hand edited one
>of the provided examples.
>
> But once I deploy it to the /servlet/AxisServlet and try to browse the
>generated .wsdl file it is totally a different version of what I have made
>.. I mean the wsdl says that it is a RPC style service and the operation is
>encoded.
>
> Now the questions I can figure out is :
>
> (a) How to make a message style service and create a wsdl file which says
>that it is a Message style service.
>
>
> thanx in advance
>
>
> dumdum420
>
>
>
>
>
>
>
>
>
>
>
>
>
Re: Message Style and WSDL
Posted by remko de knikker <re...@yale.edu>.
Bhanu,
the only other thing that I know of, is that I need to restart my
server, to make it work...?
sorry,
r
Bhanu Pabreja wrote:
>This what my deployment descriptor looks like :
>
><deployment name="test" xmlns="http://xml.apache.org/axis/wsdd/"
> xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"
> xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance">
> <!-- note that either style="message" OR provider="java:MSG" both work -->
> <service name="FirmTaxonomyModelService" style="message">
> <parameter name="className"
>value="com.dumdum.taxonomy.ws.FirmTaxonomyModelMessageStyleService" />
> <parameter name="allowedMethods" value="*" />
> </service>
></deployment>
>
>
>and my wsdl file looks like this:
>
><?xml version="1.0" encoding="UTF-8"?>
><wsdl:definitions
>targetNamespace="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModel
>Service" xmlns="http://schemas.xmlsoap.org/wsdl/"
>xmlns:apachesoap="http://xml.apache.org/xml-soap"
>xmlns:impl="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServi
>ce"
>xmlns:intf="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServi
>ce" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
>xmlns:xsd="http://www.w3.org/2001/XMLSchema"><wsdl:types/>
> <wsdl:message name="fetchDocumentResponse">
> <wsdl:part name="fetchDocumentReturn" type="xsd:anyType"/>
> </wsdl:message>
> <wsdl:message name="fetchDocumentRequest">
> </wsdl:message>
> <wsdl:portType name="FirmTaxonomyModelMessageStyleService">
> <wsdl:operation name="fetchDocument">
> <wsdl:input message="intf:fetchDocumentRequest"
>name="fetchDocumentRequest"/>
> <wsdl:output message="intf:fetchDocumentResponse"
>name="fetchDocumentResponse"/>
> </wsdl:operation>
> </wsdl:portType>
> <wsdl:binding name="FirmTaxonomyModelServiceSoapBinding"
>type="intf:FirmTaxonomyModelMessageStyleService">
> <wsdlsoap:binding style="rpc"
>transport="http://schemas.xmlsoap.org/soap/http"/>
> <wsdl:operation name="fetchDocument">
> <wsdlsoap:operation soapAction=""/>
> <wsdl:input name="fetchDocumentRequest">
> <wsdlsoap:body
>encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
>namespace="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServic
>e" use="encoded"/>
> </wsdl:input>
> <wsdl:output name="fetchDocumentResponse">
> <wsdlsoap:body
>encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
>namespace="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServic
>e" use="encoded"/>
> </wsdl:output>
> </wsdl:operation>
> </wsdl:binding>
> <wsdl:service name="FirmTaxonomyModelMessageStyleServiceService">
> <wsdl:port binding="intf:FirmTaxonomyModelServiceSoapBinding"
>name="FirmTaxonomyModelService">
> <wsdlsoap:address
>location="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelService
>"/>
> </wsdl:port>
> </wsdl:service>
></wsdl:definitions>
>
>Now this thing clearly says that this is RPC style service and everything
>looks to be encoded.
>
>BTW I dont think so your server is up since I could not access your
>webservice's wsdl file.
>
>Have a look and tell me where I am wrong.
>
>Bhanu.
>
>
>
>-----Original Message-----
>From: remko de knikker [mailto:remko.deknikker@yale.edu]
>Sent: Tuesday, June 24, 2003 9:01 AM
>To: axis-user@ws.apache.org
>Subject: Re: Message Style and WSDL
>
>
>
>Bhanu,
>
>here's my example for a message-style ws, which works for me.
>
><deployment name="GetXSLIM" xmlns="http://xml.apache.org/axis/wsdd/"
> xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"
> xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance">
> <handler name="handlerXSLIM" type="java:ws.xslim.BasicHandler_XSLIM"/>
> <service name="GetXSLIM" style="message">
> <requestFlow>
> <handler type="handlerXSLIM"/>
> </requestFlow>
> <responseFlow>
> <handler type="handlerXSLIM"/>
> </responseFlow>
> <parameter name="className" value="ws.xslim.GetXSLIM" />
> <parameter name="allowedMethods" value="method1" />
> <parameter name="wsdlInputSchema"
>value="http://biryani.med.yale.edu:8081/axis/files/xslim/GetXSLIM_method1Req
>uest.xsd"/>
> </service>
></deployment>
>
>Look at the result at
>http://biryani.med.yale.edu:8081/axis/services/GetXSLIM?wsdl
>
>remko
>
>
>Date: Mon, 23 Jun 2003 18:39:30 -0400
>From: Bhanu Pabreja <pa...@infigroup.com>
>To: axis-user@ws.apache.org
>Reply-to: axis-user@ws.apache.org
>Subject: Message Style and WSDL
>One step beyond .jws files
> I have made a message style service with one method
>
> public Document fetchData(Document doc){
> // logic
> }yl
>
> Then I deployed the service using the deploy.wsdd. I could not use the
>Java2WSDL utitily to generate "Message" style service so I hand edited one
>of the provided examples.
>
> But once I deploy it to the /servlet/AxisServlet and try to browse the
>generated .wsdl file it is totally a different version of what I have made
>.. I mean the wsdl says that it is a RPC style service and the operation is
>encoded.
>
> Now the questions I can figure out is :
>
> (a) How to make a message style service and create a wsdl file which says
>that it is a Message style service.
>
>
> thanx in advance
>
>
> dumdum420
>
>
>
>
>
>
>
>
>
>
>
>
>
RE: Message Style and WSDL
Posted by Bhanu Pabreja <pa...@infigroup.com>.
This what my deployment descriptor looks like :
<deployment name="test" xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance">
<!-- note that either style="message" OR provider="java:MSG" both work -->
<service name="FirmTaxonomyModelService" style="message">
<parameter name="className"
value="com.dumdum.taxonomy.ws.FirmTaxonomyModelMessageStyleService" />
<parameter name="allowedMethods" value="*" />
</service>
</deployment>
and my wsdl file looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
targetNamespace="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModel
Service" xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServi
ce"
xmlns:intf="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServi
ce" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><wsdl:types/>
<wsdl:message name="fetchDocumentResponse">
<wsdl:part name="fetchDocumentReturn" type="xsd:anyType"/>
</wsdl:message>
<wsdl:message name="fetchDocumentRequest">
</wsdl:message>
<wsdl:portType name="FirmTaxonomyModelMessageStyleService">
<wsdl:operation name="fetchDocument">
<wsdl:input message="intf:fetchDocumentRequest"
name="fetchDocumentRequest"/>
<wsdl:output message="intf:fetchDocumentResponse"
name="fetchDocumentResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="FirmTaxonomyModelServiceSoapBinding"
type="intf:FirmTaxonomyModelMessageStyleService">
<wsdlsoap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="fetchDocument">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="fetchDocumentRequest">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServic
e" use="encoded"/>
</wsdl:input>
<wsdl:output name="fetchDocumentResponse">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelServic
e" use="encoded"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="FirmTaxonomyModelMessageStyleServiceService">
<wsdl:port binding="intf:FirmTaxonomyModelServiceSoapBinding"
name="FirmTaxonomyModelService">
<wsdlsoap:address
location="http://localhost:8080/FTAToolWeb/services/FirmTaxonomyModelService
"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Now this thing clearly says that this is RPC style service and everything
looks to be encoded.
BTW I dont think so your server is up since I could not access your
webservice's wsdl file.
Have a look and tell me where I am wrong.
Bhanu.
-----Original Message-----
From: remko de knikker [mailto:remko.deknikker@yale.edu]
Sent: Tuesday, June 24, 2003 9:01 AM
To: axis-user@ws.apache.org
Subject: Re: Message Style and WSDL
Bhanu,
here's my example for a message-style ws, which works for me.
<deployment name="GetXSLIM" xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance">
<handler name="handlerXSLIM" type="java:ws.xslim.BasicHandler_XSLIM"/>
<service name="GetXSLIM" style="message">
<requestFlow>
<handler type="handlerXSLIM"/>
</requestFlow>
<responseFlow>
<handler type="handlerXSLIM"/>
</responseFlow>
<parameter name="className" value="ws.xslim.GetXSLIM" />
<parameter name="allowedMethods" value="method1" />
<parameter name="wsdlInputSchema"
value="http://biryani.med.yale.edu:8081/axis/files/xslim/GetXSLIM_method1Req
uest.xsd"/>
</service>
</deployment>
Look at the result at
http://biryani.med.yale.edu:8081/axis/services/GetXSLIM?wsdl
remko
Date: Mon, 23 Jun 2003 18:39:30 -0400
From: Bhanu Pabreja <pa...@infigroup.com>
To: axis-user@ws.apache.org
Reply-to: axis-user@ws.apache.org
Subject: Message Style and WSDL
One step beyond .jws files
I have made a message style service with one method
public Document fetchData(Document doc){
// logic
}yl
Then I deployed the service using the deploy.wsdd. I could not use the
Java2WSDL utitily to generate "Message" style service so I hand edited one
of the provided examples.
But once I deploy it to the /servlet/AxisServlet and try to browse the
generated .wsdl file it is totally a different version of what I have made
.. I mean the wsdl says that it is a RPC style service and the operation is
encoded.
Now the questions I can figure out is :
(a) How to make a message style service and create a wsdl file which says
that it is a Message style service.
thanx in advance
dumdum420
Multipart related mime parts throws null pointer exception in wsdl2java
Posted by George Jagodzinski <ge...@fusionapps.com>.
here is the part of my bindings that throws a null pointer error when I try
to run wsdl2java. Everything works fine if I take the
<mime:multipartRelated> node completely out.
Does anyone know what I am doing wrong here?
<wsdl:binding name="MyNamespace" type="tns:MyNamespace">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc"/>
<mime:multipartRelated>
<mime:part>
<soap:body use="encoded"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="nsMyNamespace"/>
</mime:part>
<mime:part>
<mime:content part="document" type="application/binary"/>
</mime:part>
</mime:multipartRelated>
thank you,
George
Re: Message Style and WSDL
Posted by remko de knikker <re...@yale.edu>.
Bhanu,
here's my example for a message-style ws, which works for me.
<deployment name="GetXSLIM" xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance">
<handler name="handlerXSLIM" type="java:ws.xslim.BasicHandler_XSLIM"/>
<service name="GetXSLIM" style="message">
<requestFlow>
<handler type="handlerXSLIM"/>
</requestFlow>
<responseFlow>
<handler type="handlerXSLIM"/>
</responseFlow>
<parameter name="className" value="ws.xslim.GetXSLIM" />
<parameter name="allowedMethods" value="method1" />
<parameter name="wsdlInputSchema" value="http://biryani.med.yale.edu:8081/axis/files/xslim/GetXSLIM_method1Request.xsd"/>
</service>
</deployment>
Look at the result at http://biryani.med.yale.edu:8081/axis/services/GetXSLIM?wsdl
remko
Date: Mon, 23 Jun 2003 18:39:30 -0400
From: Bhanu Pabreja <pa...@infigroup.com>
To: axis-user@ws.apache.org
Reply-to: axis-user@ws.apache.org
Subject: Message Style and WSDL
One step beyond .jws files
I have made a message style service with one method
public Document fetchData(Document doc){
// logic
}yl
Then I deployed the service using the deploy.wsdd. I could not use the
Java2WSDL utitily to generate "Message" style service so I hand edited one
of the provided examples.
But once I deploy it to the /servlet/AxisServlet and try to browse the
generated .wsdl file it is totally a different version of what I have made
.. I mean the wsdl says that it is a RPC style service and the operation is
encoded.
Now the questions I can figure out is :
(a) How to make a message style service and create a wsdl file which says
that it is a Message style service.
thanx in advance
dumdum420
Howto : w3c.dom.Element to SOAPHeader
Posted by Kai Unewisse <ka...@innovations.de>.
MessageHi all !
Thanks to Dims and Anne for your help in WS-Security,but I need WS-Security
instantly (my thesis ends in 4 weeks ...)
My challange is right now transforming an w3c.dom.Element Object to an
SOAPHeader Object.
I use Verisigns WS-Security and it produces a signed Document. But how can I
put it back to the MessageContext ???
My Code :
Document doc =
context.getCurrentMessage().getSOAPEnvelope().getAsDocument();
WSSecurity sec = new WSSecurity();
sec.sign(doc, signingKey, signingKeyInfo);
Element soapHeaderElement = (Element) ((Element)
doc.getFirstChild()).getElementsByTagNameNS("*", "Header").item(0);
// context.getCurrentMessage().getSOAPEnvelope().setHeader( ???? );
It is probably very easy, but I can`t find out.
Thanks for any hint,
Kai