Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / ASP.NET / Web Services / September 2004

Tip: Looking for answers? Try searching our database.

How to have a "fault" element in generated WSDL?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Arnold Huygens - 02 Aug 2004 13:35 GMT
I have a standard web method in a standard asmx web service. Say:

[WebMethod(Description="A simple method.")]
public string mySimpleMethod(string data){
try {
 . . .
 [do something smart here]
 . . .
}
catch (Exception e) {
 throw new MySimpleException(e);
}
}

The MySimpleException translates the standard exception into a
SoapException, following the guidelines described in the article
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cp
conhandlingraisingexceptionsinxmlwebservices.asp
: I
create a new SoapException, and I set the message, code, actor, and details.

Now, what I would like (actually my client is who would like), is some
information about this appearing as a "fault" element in the WSDL generated
by the asmx web service:

 <portType name="aSimpleWebServiceSoap">
   <operation name="mySimpleWebMethod">
     <documentation>A simple method.</documentation>
     <input message="s0:aSimpleWebServiceSoapIn" />
     <output message="s0:aSimpleWebServiceSoapOut" />
     <fault message="s0:aSimpleWebServiceSoapFault" />
   </operation>

How to achieve this?

Regards,
   A. H.
Jeffrey Hasan - 03 Aug 2004 18:12 GMT
This is an interesting question that may not currently have a satisfactory
answer because of the way that ASP.NET manages exceptions from Web services.
And I should point out that wsdl.exe ignores fault messages in the
<portType> operations. You can manually insert them, but the wsdl tool will
ignore them when it generates classes. There is currently no way that I know
of to have VS .NET or the command line tools automatically generate wsdl
that includes fault message references.

That being said, as you know, Web service exceptions are raised as SOAP
faults, which are encapsulated by the .NET SoapException class. If you are
trying to raise a custom fault message then ASP.NET still requires the
message class representation to inherit from the SoapException class. If you
throw a custom SoapException class then you should be able to capture the
custom properties as the InnerException. You should be able to map this
InnerException to your custom exception class. This of course assumes that
the client understands what this custom class is (which you are trying to
do, based on the WSDL).

Alternatively, you can simply use a standard SoapException class, but set
its detail to a custom XML fragment. You would do this by setting the node
property of the SoapException class to the custom XML (and set the fault
code to client). Then on the client you can reference the exception's detail
property, and pull its OuterXML to view the custom XML. At that point your
client can transform the information into a more useful format or message.

Jeffrey Hasan, MCSD
President, Bluestone Partners, Inc.
-----------------------------------------------
Author of: Expert SOA in C# Using WSE 2.0 (APress, 2004)
http://www.bluestonepartners.com/soa.aspx

> I have a standard web method in a standard asmx web service. Say:
>
[quoted text clipped - 12 lines]
> The MySimpleException translates the standard exception into a
> SoapException, following the guidelines described in the article

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cp
conhandlingraisingexceptionsinxmlwebservices.asp
: I
> create a new SoapException, and I set the message, code, actor, and details.
>
[quoted text clipped - 14 lines]
> Regards,
>     A. H.
Arnold Huygens - 04 Aug 2004 16:34 GMT
Thanks for your answer. After days searching a solution, even somebody
saying "there is no solution" is a relief.

So, if I understood right, the situation with the SoapException is the
following:
- .NET web services raise any exception they encounter as a SoapException.
- SoapException is translated into Soap world in a perfectly standard way.
- In a SoapException there is a taylorable section: the "detail" section.
- But .NET generated WSDLs don't say a word about all this, and the web
services are described as if they didn't raise any exception (although they
actually do!).

Anyway, as long your clients are using .NET platforms, they don't care,
because .NET platforms ignore all about "<fault>" element. On the other
hand, Java clients will be laughing at you. Or worse: sending emails about
you to your boss.

Regards,
  Jean-Michel Gonet.

> This is an interesting question that may not currently have a satisfactory
> answer because of the way that ASP.NET manages exceptions from Web services.
[quoted text clipped - 26 lines]
> Author of: Expert SOA in C# Using WSE 2.0 (APress, 2004)
> http://www.bluestonepartners.com/soa.aspx
Ann - 27 Sep 2004 17:45 GMT
Are there any plans to change this in a future SOAP Toolkit or in subsequent
versions of the .Net Framework?

WSDL.exe generates the other domain classes. If a webservice operation is
requesting or responding with a Product bean. .Net generates a product class.
It seems to be that wsdl.exe should generate an exception class.

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.