J2EE and .NET Webservices Integration Problems

Discussions

News: J2EE and .NET Webservices Integration Problems

  1. J2EE and .NET Webservices Integration Problems (25 messages)

    Weaving together Web services to create cross-organizational business processes requires all partners to program to the same standard model and to avoid exposing proprietary implementations. After many years of promoting the interoperability among vendors through joint efforts on standardizing protocols, significant progress has been made. However, the ultimate goal of making Web services interact seamlessly is still a frequent concern and a hot discussion topic. Explore the source of some common interoperability challenges facing Web services integration across platforms and join the author in analyzing a number of interoperability problems resulting from interaction styles, basic data types and structures, and namespace issues between .NET and J2EE technology. Wangming Ye offers best practices that you can use to avoid problems and improve the chances of successful integration. The first part of the series stresses the importance of WSDL design and analyzes the strength and pitfalls of the traditional RPC/encoded style in Web services interoperability.

    Web services programming tips and tricks: Improve interoperability between J2EE technology and .NET, Part 1

    Threaded Messages (25)

  2. Hahahaha[ Go to top ]

    And thus is why the 25+ WS-* standards will never interoperate.
    SOA we hardly knew yee!
  3. SoA is good![ Go to top ]

    If you do Java Client side (JDNC) talking to Java Server Side.

    Interop is just old CORBA issues... new to some.

    .V
    SandraSF.com
  4. Simply does not WORK[ Go to top ]

    I have using WebServices about 2 years and 95% of the projects
    that have success was implemented Web Services on ONLY ONE PLATFORM (J2EE or .NET).
    The other 5% was in implemented with methods of components that return an String only, because the limitation of the architecture to deal with complex types.

    I Hope that the vendors make our life easy very soon.

    But, I still using and see WebServices an excelent idea.

    Rogerio
  5. Simply does not WORK[ Go to top ]

    ...I still using and see WebServices an excelent idea.Rogerio
    I am curious why WS still look as good idea for you?
    IMO it fails miserably as a way of comp-to-comp interactions. (http://kgionline.com/articles/protocol_compare/doc/index.jsp )
    Document oriented style has its merits, but it does not have to be XML format, just about anything will fly if involved parties are really interested in document exchange.
  6. Simply does not WORK[ Go to top ]

    I have using WebServices about 2 years and 95% of the projects that have success was implemented Web Services on ONLY ONE PLATFORM (J2EE or .NET).The other 5% was in implemented with methods of components that return an String only, because the limitation of the architecture to deal with complex types.

    We use use webservices in our application about a year, both Java (AXIS-based) and .NET. We transfer complex objects often, but not the following restrictions:

    1) Its difficult to transfer Hibernate-instrumented objects. Actually, its difficult to transfer any object that has server-side code and value objects are the only solution for us.

    2) Its possible to use SOAP for composite objects with some restrictions on field types (only String, Integer, boolean, etc).

    3) For .NET integration conversion from Collection to arrays (and back) is required. .NET doesn't support java collections.

    4) I don't know good solution to transfer binaries, seems like .NET doesn't support http://xml.apache.org/xml-soap:DataHandler

    Note that most web services samples show it only for VERY simple functionality. Our application implements 15+ services and ~200 methods and the perfomance is the major problem for us, I don't belive in ESB future.

    PS. tried GLUE too, but got a lot of classloader issues.
     
    Maxim Kramarenko
    TrackStudio Enterprise - Hierarchical Bug Tracking Software.
  7. Curious[ Go to top ]

    We use use webservices in our application about a year, both Java (AXIS-based) and .NET. We transfer complex objects often, but not the following restrictions:
    1) Its difficult to transfer Hibernate-instrumented objects. Actually, its difficult to transfer any object that has server-side code and value objects are the only solution for us.
    2) Its possible to use SOAP for composite objects with some restrictions on field types (only String, Integer, boolean, etc).
    3) For .NET integration conversion from Collection to arrays (and back) is required. .NET doesn't support java collections.
    4) I don't know good solution to transfer binaries, seems like .NET doesn't support http://xml.apache.org/xml-soap:DataHandlerNote that most web services samples show it only for VERY simple functionality.
    Our application implements 15+ services and ~200 methods and the perfomance is the major problem for us, I don't belive in ESB future.PS. tried GLUE too, but got a lot of classloader issues. Maxim KramarenkoTrackStudio Enterprise - Hierarchical Bug Tracking Software.

    it sounds like you've come across some of the problems I experienced. On the binary data issue, I believe the recommended approach is to use base64 encoding. I know that is how MapPoint.NET handles it when the server is .NET and the client is Java.

    on the collections issue, was it the generated XML returned from .NET? I'm curious, since I haven't come across that problem. By default, XSD generates object arrays, but you can make it load unbounded choice to an ArrayList. the way that I've worked around this in the past was to change the model. In some cases, you can change the XML serialization attribute to make it load the elements to an ArrayList, instead of object arrays.

    if you can describe the problem you see, I'd like to hear more details.

    peter
  8. Curious[ Go to top ]

    it sounds like you've come across some of the problems I experienced. On the binary data issue, I believe the recommended approach is to use base64 encoding. I know that is how MapPoint.NET handles it when the server is .NET and the client is Java.

    Thank you, I'll check.
    on the collections issue, was it the generated XML returned from .NET? I'm curious, since I haven't come across that problem. By default, XSD generates object arrays, but you can make it load unbounded choice to an ArrayList. the way that I've worked around this in the past was to change the model. In some cases, you can change the XML serialization attribute to make it load the elements to an ArrayList, instead of object arrays.if you can describe the problem you see, I'd like to hear more details.peter

    Primary we need to return Java collections to the .NET client. We solve this problem by implementing additional layer that convert parameters to .NET-compatible.

    For example, the following method

        public TaskBean[] getTaskChain(String sessionId, String startTaskId, String stopTaskId) throws GranException {
            List list = new LinkedList();
            for (Iterator it = manager.getTaskChain(SessionManager.getInstance().getSessionContext(sessionId), startTaskId, stopTaskId).iterator(); it.hasNext();)
                list.add(((SecuredTaskBean) it.next()).getSOAP());
            if (list.isEmpty())
                return null;
            else
                return (TaskBean[]) list.toArray(new TaskBean[]{new TaskBean()});
        }

    get collection of SecuredTaskBean and convert them to the SOAP-compatible TaskBean[]. We have similar methods for each API call. Its quite common to convert both Collection<->Array and POJO<->SOAP-compatible-POJO in the same method, so I don't think that any attributes help us simplify it :-(

    TrackStudio Enterprise - Hierarchical Issue Tracking Software.
  9. Curious[ Go to top ]

    Primary we need to return Java collections to the .NET client. We solve this problem by implementing additional layer that convert parameters to .NET-compatible.For example, the following method&nbsp;&nbsp;&nbsp;&nbsp;public TaskBean[] getTaskChain(String sessionId, String startTaskId, String stopTaskId) throws GranException {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;List list = new LinkedList();&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for (Iterator it = manager.getTaskChain(SessionManager.getInstance().getSessionContext(sessionId), startTaskId, stopTaskId).iterator(); it.hasNext();)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;list.add(((SecuredTaskBean) it.next()).getSOAP());&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if (list.isEmpty())&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return null;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return (TaskBean[]) list.toArray(new TaskBean[]{new TaskBean()});&nbsp;&nbsp;&nbsp;&nbsp;}get collection of SecuredTaskBean and convert them to the SOAP-compatible TaskBean[]. We have similar methods for each API call. Its quite common to convert both Collection<->Array and POJO<->SOAP-compatible-POJO in the same method, so I don't think that any attributes help us simplify it :-(TrackStudio Enterprise - Hierarchical Issue Tracking Software.

    Ok, now I see the problem you're having. In java the API returns List, but .NET doesn't understand java collections. I try to avoid that problem by not return collections and always return a simple or complex type. Though one would think it is rather trivial for XSD to take the WSDL and realize it should convert it to an object array and generate the appropriate Xml serialization attribute. I just added support for conversion from object arrays to System.Collection.ArrayList to Dingo last weekend for an user. It should be rather simple to handle the conversion in the schema compiler. Atleast it wouldn't take more than a few hours to provide that kind of functionality. If you send me the WSDL or schema, I'd be happy to try implementing support for it.

    peter
  10. Curious[ Go to top ]

    Ok, now I see the problem you're having. In java the API returns List, but .NET doesn't understand java collections. I try to avoid that problem by not return collections and always return a simple or complex type.

    This way seems like difficult for us, because application has a complex API and it was much simpler to wrap it than re-design it.
    Though one would think it is rather trivial for XSD to take the WSDL and realize it should convert it to an object array and generate the appropriate Xml serialization attribute. I just added support for conversion from object arrays to System.Collection.ArrayList to Dingo last weekend for an user. It should be rather simple to handle the conversion in the schema compiler. Atleast it wouldn't take more than a few hours to provide that kind of functionality. If you send me the WSDL or schema, I'd be happy to try implementing support for it.peter


    Hmm, seems like I missed something. What is XSD in your message, standard or product ? Why you need to convert from object arrays to System.Collection.ArrayList ? Please give me some hints/links.

    Maxim Kramarenko
  11. clarification[ Go to top ]

    I totally understand your situation. In my case the object model wasn't an existing one, so we could change the model to accomodate .NET.

    sorry for the vague reference. I was refering to .NET's XSD tool which will generate C# classes from schema. I wrote my own schema compiler named dingo http://dingo.sourceforge.net/. It allows me to generate JAXB style C# code and do simple conversion of unbounded elements within a complexType to ArrayList instead of the default object arrays that MS XSD generates. For example,

    <xsd:complexType name="SalesRates">
    <xsd:sequence>
    <xsd:element name="SalesRatesID" type="inttype" />
    <xsd:element name="StageRate" type="StageRate" maxOccurs="unbounded" />
    </xsd:sequence>
    </xsd:complexType>

    normally "StageRate" would be converted to an object array when XSD generates the C# class. An alternative is to generate the code so it uses ArrayList.

    XSD: StageRate[] stageRate;
    Dingo: ArrayList stageRate;

    what I was thinking is, if your Java webservice generates a schema, it should be simple to generate code that handles the XML by substituting java.util.ArrayList with System.Collections.ArrayList.

    peter
  12. clarification[ Go to top ]

    MS XSD.exe?

    I've had much better luck with MS XSDObjectGen.exe - just google and download it from the Internet.

    It's not perfect as it's not nearly as capable a tool as Sun's JAXB reference implementation. But I managed to use it quite successfully with various XSD schemas in which the MS XSD.exe tool could not support correctly.
  13. clarification[ Go to top ]

    MS XSD.exe?I've had much better luck with MS XSDObjectGen.exe - just google and download it from the Internet.It's not perfect as it's not nearly as capable a tool as Sun's JAXB reference implementation. But I managed to use it quite successfully with various XSD schemas in which the MS XSD.exe tool could not support correctly.

    I took a look at the code XSDObjectGen generates. I'm not sure if it's better or worse than XSD.exe. Rather than use the standard Xml Serialization attributes, it looks like the generated code is using the Xml Serializable attributes. The addition of add/remove methods isn't necessarily better in my mind and may not make integration across platforms easier. Having the generated classes extend ArrayList in my mind isn't a good idea for portability. Why not just make the field an arraylist without having the object extend System.Collections.ArrayList. XSDObjectGen still isn't pluggable and doesn't allow you to provide different logic for the methods.

    have to say I'm not impressed with XSDObjectGen at all. I'm totally bias, but one of the things I like about JAXB style code generation is that I can have the objects defined with interfaces. That means I can have a real class for production and a mock version for functional testing. maybe one day MS will change their mind and make a Xml Schema compiler that does more than simple stuff.
  14. REST: document centric WS[ Go to top ]

    Consider REST.
    It is a WS but based on simple and working ideas instead of complicated standarts.

    Tero Vaananen:
    Aaah, WS again. I do not know why people think that WS is going to solve the problems that CORBA had to face, for example, with a wave of the magic wand. It just does not happen that way, period.

    Of course it does not happen the way CORBA tried to do it. I mean RPC way. RPC is obviously a failure regardles of its implementation (CORBA, RMI or SOAP WS)

    But it happens document/message centric way. The way Internet evolved and succeed via HTML.
  15. Payload, Simply does not WORK[ Go to top ]

    For .NET integration conversion from Collection to arrays (and back) is required. .NET doesn't support java collections.

    Arrays transfer well in WSDL, and every Java collection has a toArray() method.
    I don't know good solution to transfer binaries, seems like .NET doesn't support...

    WSDL's base64 encoding is automatic and works well for payload of a few megabytes or less. For huge BLOBs, SOAP has DIME.
  16. Payload, Simply does not WORK[ Go to top ]

    For .NET integration conversion from Collection to arrays (and back) is required. .NET doesn't support java collections.
    Arrays transfer well in WSDL, and every Java collection has a toArray() method.
    I don't know good solution to transfer binaries, seems like .NET doesn't support...
    WSDL's base64 encoding is automatic and works well for payload of a few megabytes or less. For huge BLOBs, SOAP has DIME.

    I think the problem is the result of a class or interface that uses java.util.ArrayList, which obviously does not exist in C#. one could use J#, but it would be easier in my mind to generate the correct C# code from the schema. This would reduce the need to wrap ArrayList to return object array. Assuming of course the java-to-xml produces the correct format.
  17. Saaj for binaries[ Go to top ]

    I don't know if SOAP has DIME or usoft has DIME. The J2EE standard APIs for Web Services don't have DIME support. Axis, however has DIME support. I just send byte arrays as a soap attachment to interoperate with a usoft Web Service and transfer binary data. Pretty confusing as to why the J2EE standard APIs do not allow Soap with Attachments to interoperate with usoft Web Services. With saaj I don't have to worry about the 4 or 500k limit where SOAP baloons exponentially. I was able to send and return 128mb byte arrays without using all available virtual memory and CPU cycles
  18. SOA we hardly knew yee!

    If you really want to do Distributed SOA, use Jini, everything else pales into insignificance.

    --Calum
  19. A Globus grid uses WSDL, so we had similar discussions a year ago. XML.com covered severe usability problems for doing WSDL by hand. WSDL should be completely hidden under tooling, which is why IBM's claim is so disturbing:
    Programmers must learn to program against raw XML messages, and at least learn to read XSD, WSDL, and SOAP messages.
    The rest of IBM's article is a lecture on the importance of WS-I.
  20. A Globus grid uses WSDL, so we had similar discussions a year ago. XML.com covered severe usability problems for doing WSDL by hand. WSDL should be completely hidden under tooling, which is why IBM's claim is so disturbing:
    Programmers must learn to program against raw XML messages, and at least learn to read XSD, WSDL, and SOAP messages.
    The rest of IBM's article is a lecture on the importance of WS-I.
    I would not be surprised to see: programmers must (re)learn to program against raw IP packages!
    Agrrr
    No wonder IBM has such agenda: they need to sell consulting services, there is no need for consulting if stuff simply works.
  21. We have had good luck with GLUE
  22. Aaah, WS again. I do not know why people think that WS is going to solve the problems that CORBA had to face, for example, with a wave of the magic wand. It just does not happen that way, period.

    Are there really any compelling advantages for using WS over some other technology like CORBA? I mean reasons that are groundbreaking? There are none, period.
  23. Are there really any compelling advantages for using WS over some other technology like CORBA? I mean reasons that are groundbreaking?

    There are three big reasons to favor WSDL instead of IIOP:

    1) Few languages have an ORB, especially scripting languages. Any language that crunches text is suitable for WSDL.

    2) I've never been able to get IIOP tunnelled exclusively through port 80, the world's most universal port. So IIOP is unsuited for the extranet.

    3) SOAP doesn't care if it's posted by HTTP or SMTP. GIOP is a false promise.
  24. Because native data types and XSD data types do not share
    >a one-to-one mapping, information or precision can be
    >lost during the translation.
    Why it is so?

    Dmitry
    http://www.servletsuite.com
  25. It seems that a lot of problems that people are experiencing are related to trying to use Web services just like CORBA. This is probably not a good way to think about things. Web services are best for passing around self-contained XML documents. Trying to map object structures to XML documents is a source of great deal of frustration. In some respects, it's a bit like the impedence mismatch between object models and relational databases (in fact, this is a reasonable area to apply O-X technologies); it's also a problem for interoperability between different systems. In some sense, it can be misleading to have API standardization in this space (eg, JAXRPC) that encourages this "RMI approach" by design.

    Web services protocols and packaging are particularly useful for integration solutions that favor self contained messages and asyncronous interactions; in general the stack is optimizing around these kinds of high value solutions. People expecting a silver bullet for all kinds of distributed programming are going to be disappointed. Not just by Web services protocols, but by anything.

    Greg
  26. web services considered harmful[ Go to top ]

    Every time I see these items about all the angst of web services development I tend to break out snickering.

    I use Tibco EMS messaging for my hetrogeneous glue. I define msg objects in XSD, use JAXB on Java (server-side), and XSDObjectGetn on .NET (client-side). Plus we have some C/C++ end-points. And we'll have some wireless handhelds running .NET Compact Framework (wich Tibco EMS supports too - with SSL).

    Has all worked quite fine for months and months.

    In the mean time the web services dudes continue to founder.

    The first rule is that RPC in itself is fundamentally evil (yes, have years of arrows in the back from DCOM projects). But web services is a monstrocity - which won't be improved any even when eventually done on a messaging substrate.