File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Web Services and the fly likes Apache Axis versus JbossWS Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "Apache Axis versus JbossWS" Watch "Apache Axis versus JbossWS" New topic
Author

Apache Axis versus JbossWS

Sandeep saahil
Greenhorn

Joined: Jan 09, 2008
Posts: 12
Hi Friends, I m new to webservices and would like to know what are the basic problems that one face when using Apache Axis 1.X with JbossWS. I have some service developed using Apache Axis and want to create client stubs using wstools/wsconsume. I m getting different issues when using these tools.

wstools : It generates the stubs but only some java classes are generated and also the package structure is not correct.
wsconsume : I m able to generate the stubs only if i remove entries for faults from the WSDL(i guess since faults extends AxisFault)

I want to know:
  • Is Apache Axis compatible with JBossWS
  • If not, what can be done to make them compatible
  • Any other thing that i should take care in this scenario


  • i can provide all the files used if anybody is interested.

    thanks in advance


    Dreams are not what you get when you sleep...It is something which don't let you sleep
    Peer Reynders
    Bartender

    Joined: Aug 19, 2005
    Posts: 2922
        
        5
    Sandeep saahil wrote:wstools : It generates the stubs but only some java classes are generated and also the package structure is not correct.
    wsconsume : I m able to generate the stubs only if i remove entries for faults from the WSDL(i guess since faults extends AxisFault)


    This seems to indicate that you are approaching this with an inappropriate set of expectations. There is no attempt made to have exactly the same set of java objects on the consumer side as there are on the provider side. The consumer side tools will generate java classes that are just sufficient to contain the data that is embedded in the XML that goes over the wire. So the fact that Axis uses AxisFaults should be irrelevant as SOAP Faults are simply SOAP Faults in the WSDL and wsconsume should simply map it to the Java class that it uses to represent SOAP Faults.

    And hopefully the Axis web services do not use the rpc/encoded messaging mode - that tends to cause all sorts of trouble. Document/literal is preferrable.
    Which style of WSDL should I use?
    Service Styles - RPC, Document, Wrapped, and Message
    Sandeep saahil
    Greenhorn

    Joined: Jan 09, 2008
    Posts: 12
    Thanks Peer for your answer. I understood the difference but i was talking about the classes generated through wstools and wsconsume. Since both of them are generating stubs so the generated stubs should be similar. please correct me if i m wrong.
    I totally agree with the faults part that you told but then why wsconsume successfully generated the stubs if I delete the faults part from WSDL. The WSDL is automatically generated and I successfully generated artifacts using Axis. My configuration file and WSDL is specified at

    Javaranch link

    Please guide me where m i going wrong. Thanks again for helping me.

    regards
    Sandy
    Peer Reynders
    Bartender

    Joined: Aug 19, 2005
    Posts: 2922
        
        5
    Sandeep saahil wrote:Since both of them are generating stubs so the generated stubs should be similar.

    It seems that wstools is JAX-RPC based and wsprovide/wsconsume is based on JAX-WS. So the artifacts would actually be quite different.
    JAX-WS is more mature, JAX-RPC is for all intents and purposes deprecated. Axis 1.x however is JAX-RPC based.

    I totally agree with the faults part that you told but then why wsconsume successfully generated the stubs if I delete the faults part from WSDL.

    I'm not doubting that you are have interoperability problems with the Axis 1.x generated WSDL. Either
  • the WSDL is wrong
  • or the tool cannot interpret the WSDL as rendered even though the WSDL is valid as per spec


  • As to the fault maybe the tool can't deal with the fault as defined (it doesn't like the empty sequence?).


    With JAX-WS as included in the JDK 1.6 you would typically find

    Note that the message portion is optional. Reasonably speaking the Axis version should have prompted wsconsume to create an InvalidPageUrlKeyFault_Exception extending Exception with a default constructor. But tools aren't perfect. There are other things that can confuse tools - even when they shouldn't.

    The problem with the parsing failure of your WSDL is that the error message isn't helpful - it doesn't even narrow down the area of the WSDL that is causing the problem.
    Which means that you basically have to strip down the WSDL to one simple operation, removing faults and information that isn't essential to supporting that operation and see if the WSDL is processed properly. Then you add things back, little by little, until the problem occurs again. At that point you can play with any possible permutations that may be able to bypass the problem.
    Sandeep saahil
    Greenhorn

    Joined: Jan 09, 2008
    Posts: 12
    Thanks Peer for the detailed description. Please have a look at my findings so far.

    1) Since the WSDL was generated using Axis1.x so I used wstools(JBoss4.0.x) but that generated incomplete stubs but i got no error in terms of invalid WSDL or similar error

    2) I validated the WSDL with eclipse and got error that WSDL is not valid with multiple errors.

    3) I tried creating artifacts from WSDL using Axis and was successful in generating them.

    4) I used wsconsume to generate artifacts without modifying the WSDL and got the error

    [ERROR] in message "InvalidPageUrlKeyFault", part "fault" must specify a "element" attribute
    line 95 of file:/C:/BupaEnv/jboss-4.0.4.GA/bin/BupaWebService.wsdl


    My faults are nothing fancy . they just inherit AxisFault

    5) I added the element part to the sequence manually with only message as element. It again gave the same error.

    6) I removed the faults from WSDL and successfully generated artifacts but they are kind of useless as they lack faults.

    My next steps would surely be narrowing down things a bit as advised by you. Thanks Peer again for your time and valuable thoughts.

    regards
    Sandy
    Sandeep saahil
    Greenhorn

    Joined: Jan 09, 2008
    Posts: 12
    Hi Friends,

    I was able to resolve the error that I was getting earlier. I changed


    <wsdl:message name="InvalidSiteIdFault">
    <wsdl:part name="fault" type="tns3:InvalidSiteIdFault"/>
    </wsdl:message>


    to


    <wsdl:message name="InvalidSiteIdFault">
    <wsdl:part name="fault" element="tns3:InvalidSiteIdFault"/>
    </wsdl:message>


    so the error was resolved. But nowi m getting a different error.

    [ERROR] Schema descriptor {http://fault.service.infra.dummy.com}InvalidPageUrlKeyFault in message part "fault" is not defined and could not be bound to Java. Perhaps the schema descriptor {http://fault.service.infra.bupa.com}Invali
    dPageUrlKeyFault is not defined in the schema imported/included in the WSDL. You can either add such imports/includ
    es or run wsimport and provide the schema location using -b switch.
    line 108 of file:/D:/R2KaKaam/4Feb/DummyWebService.wsdl



    Wsdl is specified at Wsdl

    I have double checked and to me it appears that schema is correctly specified. Could somebody help me?

    Thanks in advance
    Sandy
    Peer Reynders
    Bartender

    Joined: Aug 19, 2005
    Posts: 2922
        
        5
    Sandeep saahil wrote:
    so the error was resolved.

    Interesting. So apparently Axis is wrong. While "rpc/literal" parameters for input/output use "type", parameters for faults have to use "element".
    But now I'm getting a different error.
    [ERROR]Schema descriptor {http://fault.service.infra.dummy.com}InvalidPageUrlKeyFault in message part "fault" is not defined

    Well, the problem is that you are no longer referring to a type but an element.
    In the schema change

    to

    If that compiles - test it by causing the the fault and see if it is processed correctly.

    You can use Apache TCPMon (Tutorial) or java.net tcpmon to capture/view the HTTP request/response pairs. This might be useful to capture the SOAP Fault sent back by Axis in case some further tweaking of the WSDL is necessary for the consumer to process it properly.
    Sandeep saahil
    Greenhorn

    Joined: Jan 09, 2008
    Posts: 12
    Thanks Peer, That worked.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Apache Axis versus JbossWS