Announcement Announcement Module
No announcement yet.
Transfer complex objects with JAX-RPC (.NET) Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Transfer complex objects with JAX-RPC (.NET)

    I just checked out the jPetStore Axis example and I'm impressed how easy the Axis integration works.

    But somewhere in the client source Jürgen mentions that you can't transfer complex objects via SOAP (like the Order/Item beans).

    But how can I integrate .NET and Java? What's the best strategy to transfer objects like Order/Items between the two worlds?

    I'm a newbie to WebServices and I bought "Apache Axis Live" from Sourcebeat. This book seems pretty useless at the moment, not one single line about heterogenous data exchange (which should be one of the key features of Web Services).

  • #2
    It is possible to transfer complex objects. Check out It explains how to add the type mappings required by the client. You will also need the mappings in the server-config.wsdd file for the web service.


    • #3
      You can integrate .Net and Java with relatively complex objects (beans, arrays of beans, beans containing arrays of beans, beans containing arrays of bean which contain arrays of beans, etc). But there will be a few issues to consider The main one is null values. I recommend two things:
      • - Use doc/literal web services (called "wrapped/literal" in Axis). Axis 1.2 support for this is much better than 1.1.
        - Use NullableTypes ( or something similar on the .Net side.

      jPetStore was using rpc/encoded if I remember correctly, and its Axis server-config.wsdd doesn't translate well to doc/literal. Here is a better example for doc/literal:

      I've written two blogs on the subject of .Net / Java introp:

      Be sure to check out:

      I have not bean able to get SoapFaults (serialized exceptions) to work from Java to .Net yet and would be interested if anyone has.


      • #4
        Nilesh, thanks a lot for your reply!

        I'll check out the links you mentioned. The main problem in our case is that we're not using 'pure .NET'. The whole thing has to work with BizTalk 2004 which has several issues (which of course maybe fixed in a future release).