Announcement Announcement Module
Collapse
No announcement yet.
howto return exceptions as soap faults Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • howto return exceptions as soap faults

    Hi,
    i posted my problem before in the remoting forum but it was maybe the wrong place.
    http://forum.springframework.org/showthread.php?t=25001
    It would be nice if someone can help me.
    Cheers,

    Ingo

  • #2
    Originally posted by res1st
    Hi,
    i'm using a web service (xfire) to call my business methods. My business methods invoke DAOs to retrieve data.

    I want to put execptions from my business logic and my DAOs into a "SOAP Fault" to give my clients some error feedback.
    How can i do this?
    Are there different ways to do it?
    I'm not sure whether it is possible with XFire. Perhaps someone else can help you with this.

    It is possible with Spring Web Services (the topic of this forum), however. Just as you would map an exception to an error page in your web.xml or -servlet.xml application context, you can do the same with Spring Web Services.

    You do so by using the SoapFaultMappingExceptionResolver. In the download is a sample airline application which shows you how to wire this up. See http://springframework.cvs.sourcefor...e=text%2Fplain, at the bottom of the file.

    Cheers,

    Comment


    • #3
      You can create XFireFault by yourselft and setup on it all information you needed to pass to client.
      Just create handler class with code to convert your custom exception to XFireFault and add it to faultHandlers list of xfire instnace.
      Handler can look like this :
      public class MyFaultHandler extends AbstractHandler {

      public void invoke(MessageContext context) throws Exception {

      Exception ex = (Exception) context.getProperty(DefaultFaultHandler.EXCEPTION) ;
      if( ex instanceof XFireFault){
      XFireFault w = (XFireFault)ex;
      String infoForClient = convertMyException( w.getCause());
      w.setMessage(infoForClient);

      }
      }
      If you are using default config - sevices.xml you need just add following to it:
      <xfire>
      <faultHandlers>
      <handler handlerClass="com.hp.webservices.handlers.MyFaultH andler"/>
      </faultHandlers>
      </xfire>

      Comment


      • #4
        Thanks for your answers.

        @poutsma
        I'm still considering spring-ws but it isn't released yet as a stable version and i heard to much bad things. That's why i use xfire and switch maybe later to spring-ws. But good to know how it would work with spring-ws. Thank you.

        @tomeks:
        Do i understand it right?
        The Business logic (and therefore DAO code) is invoked by xfire and that's why all exceptions can be cached by a xfire fault handler?

        Cheers,

        Ingo
        Last edited by res1st; May 18th, 2006, 06:43 AM.

        Comment


        • #5
          Yes, all exceptions thrown by your service are catched and converted to XFireFault by service invoker, which is then serialized to SOAP fault.

          Comment


          • #6
            Originally posted by res1st
            i heard to much bad things.
            Can you share with us the bad things that you heard?

            Comment


            • #7
              Hi Routis,

              i looked some weeks ago for web service technologies and found some bad blog entries and comments. Sorry, i didn't saved the links. But then i use goolge, i quickly find things like http://radio.weblogs.com/0112098/2005/11/23.html#a542.

              I also didn't understand what's the advantage using Spring-WS for me. Top-down development sounds interesting, but it's more easy to create java interfaces/classes then wsdl documents, right?
              At top-down the wsdl is constant. That's nice because ws-interfaces should be stable. But if i "freeze" my Java interfaces, the generated wsdl-file should also be constant. So, i stick with programming Java instead of WSDL.

              I also looked in the documentation of Spring-WS and i wasn't very satisfied with that.

              Cheers,

              Ingo

              Comment


              • #8
                Hi,

                Let's start by saying that I'm perfectly fine with people using XFire: it is a fine solution for creating web services. In fact, I did some work on it in the past :-). In my opinion, XFire and Spring-WS are just two different ways of doing web services.

                XFire is an integrated SOAP solution that is based on StAX, the fast Streaming API for XML. I would say that the focus of XFire lies on exposing Java classes as remote SOAP objects, using various XML bindings. For instance, it is really easy to expose a Spring-managed class as SOAP service using XFire, or to use JSR 181 annotations in it.

                Spring-WS really consists of two modules. First, there is a module that abstracts over various XML marshalling toolkits. You can use this module in various surroundings, Web Services being just one of them. Second, there is the Web Service module itself, which focusses on doing document-driven, contract-first SOAP with a design based on Spring-MVC. If you are already using Spring-MVC, you will feel right at home, and can even reuse the validation and binding logic you wrote for your mvc app.

                Given all this, allow me to "defend" Spring-WS against the points you mention.

                Originally posted by res1st
                i looked some weeks ago for web service technologies and found some bad blog entries and comments. Sorry, i didn't saved the links. But then i use goolge, i quickly find things like http://radio.weblogs.com/0112098/2005/11/23.html#a542.
                Ah yes. You must understand that this blog entry was written three months before Spring-WS was released. James wrote this post as a response to some blog entry I wrote on the subject. At the time, I thought it would be nice to blog about the features of Spring-WS, just to give people some idea about what's in there. Of course, the post didn't reflect the entire picture, it was just a little intro. One of the differences with other SOAP stacks it neglected to mention was the fact that the O/X mapping module is totally separate from the WS functionality. I believe there are many people who just use spring-oxm, routis being one of them.

                Originally posted by res1st
                I also didn't understand what's the advantage using Spring-WS for me. Top-down development sounds interesting, but it's more easy to create java interfaces/classes then wsdl documents, right?
                At top-down the wsdl is constant. That's nice because ws-interfaces should be stable. But if i "freeze" my Java interfaces, the generated wsdl-file should also be constant. So, i stick with programming Java instead of WSDL.
                It's interesting to see that a lot of Web service programmers want to stick with Java, while actually the SOAP/XML that is sent across the wire is most important. Clients of your web service don't care whether you use Java or not, they care about the XML. Compare it to Hibernate: you wouldn't expect to use Hibernate without knowing at least a little SQL, would you? Spring-WS allows you to use any XML handling technique you want, even XML marshalling techniques (such as JAXB) if that suits you. It's all about choice.

                Originally posted by res1st
                I also looked in the documentation of Spring-WS and i wasn't very satisfied with that.
                You are right here: the documentation isn't finished yet. While the chapter about XML marshalling is finished, the part about Web Services unfortunately isn't. I am working on it, however, and you can expect more documentation in the next release, planned for the end of this month.

                Once again, I am perfectly fine with people using other WS solutions, I just wanted to elaborate on the differences.

                Cheers,

                Comment


                • #9
                  BTW, Arjen, why your XFireExporter isn't part of spring dist ?

                  Comment


                  • #10
                    Originally posted by tomeks
                    BTW, Arjen, why your XFireExporter isn't part of spring dist ?
                    Why should it be? I really don't see any value, since you need the XFire jars anyway. People are complaining about the size of the Spring distribution enough as it is .

                    Comment


                    • #11
                      Thanks for your answers. I'll think about it. Maybe i'll switch the WS technolgy in a later phase of my project.

                      Comment


                      • #12
                        I work for a European Union Project that provides a central service (not web service) where each member country has to send information concerning the movement of all ships.
                        This information is sent in XML over HTTP using a home grown protocol (The project was started back in 2000 when the WS were not a option). There are XML Schemas that define the structure of the XML Messages.
                        Each member country has made big investments on software that produces this XML message large amounts (.Net, Java, PHP etc) . Thus, the XML Schema cannot change.
                        My job is to investigate the transition from the custom HTTP protocol to Web Services. I have looked Axis1, Axis2, J2EE WS etc, with no luck. None did give the option to begin my development from WSDL (and XML Schema).
                        Then sometime in October, I read a Poutsma's presentation that was talking for the development of "contract-first" web services. Among all the ambiguous things that you find about WS in the internet this was a clear path for me.

                        In my experience, when you have to build a system that inter-operates with others, you must pay attention to the interface that you provide.
                        The implementation of the interface is important but it also can change in time. The interface on the other hand cannot / should not change.

                        So, if you allow me to give you an advice:
                        Use whatever product, framework, soap stack best suits you, but invest on XML Schema and WSDL, because these are the essence of WS.

                        Friendly routis

                        Comment


                        • #13
                          Service contracts, data contracts are amended over time, this is the reality. One strategy for a service contract is to add a new contract but continue to support the original contract. Data contracts however have a build-in versioning system, assuming you use XML to describe the message body. I think my point is, yes I wholeheartedly agree that you need to invest in the service contract (WSDL) and data contract (XML), but I also want to stress the importance of a versioning strategy.

                          Comment


                          • #14
                            Service Contracts

                            Originally posted by paulgielens
                            Service contracts, data contracts are amended over time, this is the reality. One strategy for a service contract is to add a new contract but continue to support the original contract. Data contracts however have a build-in versioning system, assuming you use XML to describe the message body. I think my point is, yes I wholeheartedly agree that you need to invest in the service contract (WSDL) and data contract (XML), but I also want to stress the importance of a versioning strategy.
                            True, though some contracts are defined by another party. They may change as well, but hopefully not often. This doesn't change the necessity for having a versioning strategy, however.

                            Fact is that having a versioning strategy is pretty hard when you tie yourself directly to the contract. Basically, the only option is to create a new class that implements the new contract (AirlineService2.class), or to create an entirely new WS app (airlineservice2.war). You can imagine where this will end up .

                            If you put a layer in between, you will have much more room for handling different versions of the contract. Providing that layer is what Spring-WS is all about.

                            Cheers,

                            Comment

                            Working...
                            X