Discussions

News: EJB - CORBA Interoperability and Performance

  1. EJB - CORBA Interoperability and Performance (9 messages)

    A lot of enterprise applications need to work with CORBA services. Sun has spent a lot of time and effort writing Corba interoperability into the J2EE spec. A new article from Sun discusses EJB-CORBA interoperability, hitting hard on the performance points

    If you work with, or care about CORBA then check out the article here:

    http://developer.java.sun.com/developer/technicalArticles/ebeans/corba/

    How many of you have found that your EJB apps need to talk to the CORBA world?

    Are you glad that EJB 2.0 requires RMI/IIOP (and hence restricts us a little)?
  2. Personally I like the idea of J2EE-CORBA interoperability. I like the ideathat legacy systems written in C++ can have their wrappers generated automatically by tools, and then a J2EE programmer who doesn't know CORBA can invoke that legacy system via RMI-IIOP.

    However I also think that these days there are more elegant ways to achieve legacy interoperability other than CORBA--such as web services, if you can deal with the XML parsing overhead.

    I also think the standardization on the IIOP protocol was unnecessary. There are simpler ways to achieve interoperability other than at the protocol level.

    Anyone disagree?
  3. Well,
    From an interoperability on the wire point of wire, there just are not that many other options than IIOP. We get cross language bindings, transactional interoperability with OTS and Sun is now using CSIv2 for security interoperability between J2EE vendors also.

    I did my critique on TSS a while ago regarding this and with the arrival of J2EE 1.3, it looks like many of the issues are now being resolved and hopefully we'll have lots of J2EE 1.3 certified and interoperable servers soon rendering most of the points mute in the paper.

    IBM, for example, will have fully interoperability across all platforms (390, PCs, Unix etc) by using OTS and CSI/Kerberos

    Web Services doesn't solve these issues. It's currently not suitable due to lack of standards and survives mainly because we're relying on the underlying transport to flow context info like security and transactions rather than anything web services actually provides natively.

    WSDL over RMI/IIOP or just IIOP could do the job but it's more a function of OTS and CSI that is carrying the day and not web services per say.

    What other ways did you have in mind for solving these problems?

    Billy
  4. Both CORBA and DCOM, or any language independant distributed object architecture have and always will face one big challenge: how do you specify and transport a chunk of structured data in such a way that is flexible, extensible, yet validated similarly in different languages on different platforms. RMI solved this by restricting developers to platform-independent Java and allowing pass by value semantics. CORBA is trying to solve it along similar lines, but implementing value objects in different languages is simply a ridiculous requirement.

    I honestly believe XML Schemas, SOAP and WSDL provide a better solution to this problem. I wish Sun would spend time finishing JAXB and JAXRPC rather than trying to revive CORBA.
  5. I am still trying to decipher why Sun and al those involved in the specifications felt it necessary to standardize on a protocol. Most of the other efforts in J2EE are based on APIs and required features. As long as the APIs and required behavior are provided, why does it matt what protocol is used? The reasons for this must have been political but I cannot even come up with a good on of those!

    Tendayi
  6. A paper specification for interfaces etc will not give you interoperability, it gives you application portability. Sun make a good decision here as without it and the work that lead to J2EE 1.3, it's doubtful we'd have J2EE interop now or legacy Corba connectivity.

    But, as the same time, if we can find alternatives then these protocols could be supported along side IIOP as protocols for poking J2EE servers.

    Even with web services, standards on the wire for propagating security, transactions, parameter marshalling etc are still required for interop. The various port types basically do this.

    WSDL does not imply XML. XSD is used as it's type specification system. SOAP implies XML and SOAP is just an option for web services. An xsd:string can be mapped just as easily to a Corba string and marshalled as such with no intermediate XML form.

    We could define a mapping from WSDL to DCE and feed WSDL requests using WSIF with an appropriate DCE plugin to an Encina system with no XML overhead what so ever if thats whats required. WSDL doesn't imply low performance or bulk XML messages. Those factors are primarily related to the port type being used to communicate with the web service.

    It's reasonable to see WSDL mapped to Corba IDL with no XML at all.

    The notion that web services requires XML is a false one. XML is only currently specified for SOAP. WSDL simply uses wsd as a type specification system and web services is built on wsdl, not SOAP.

    Billy
  7. I believe that J2EE 1.3 requires IIOP, but allows any protocol in addition to be used. There's no reason that a vendor could not support JRMP, or even SOAP, for example, as a transport mechansim. There are a few issues IIOP raises for the platform. For example, RMI interfaces do not map to IDL so C++ clients may have to work against very ugly interfaces with extensive name mangling to account for things like method overloading.

    There are two reasons for using IIOP. One is interoperability. The wire protocol is only interoperable to the extent that certified vendors can interoperate with the RI, so it's vendor-to-vendor interoperability cannot be guaranteed. This also applies to the system level infrastructure for transactions and security. The former, which means OTS 1.2 support with some additional information embedded in the IOR, is not required. I think it's fair to say we're headed in the right direction and interoperability on J2EE is probably better than has historically been the case in the pure CORBA space.

    The other reason to use IIOP is to leverage all of the work that's already gone on with respect to transactions, etc. Personally, I think it would have been a major error for Sun to try to reinvent the wheel.

    Greg
  8. Without the requirement for supporting RMI-IIOP, there would be no standard wire protocol providing for cross-vendor interoperability. For example, if your company uses
    Websphere and you buy another company whose J2EE server is WebLogic, how do you make the two servers interoperate?
    J2EE 1.2 is like CORBA 1.x, with different vendors using different wire protocols and so locking their customers into single-vendor solutions. Making RMI-IIOP support mandatory in J2EE 1.3 is like the introduction of the IIOP protocol in CORBA 2.0: providing true vendor independence for the first time.

    Two additional comments:
    1. I totally agree with the comment about the importance of CORBA/RMI-IIOP support for OTS and CSIv2. This is crucial in allowing EJB transparent TX (and access) controls to be passed to legacy systems as well as across servers from different vendors. Web services can't provide this. And it makes no sense to extend web services to do so. Why reinvent the wheel when we have one (RMI-IIOP) that works?
    2. It's a mistake to get hung up on the ugliness of valuetypes. The way to use them when interoperating with a C++ server is *NOT* to use them: use adapter classes instead. Write an IDL interface for the C++ object using standard structs/sequences and map that into Java stubs/skeletons as well as C++ stubs/skels. In your Java code, write a Java adapter class that maps serialized Java objects into structs and sequences. The result is cleaner, faster in performance, and avoids having to write C++ implementations of valuetypes.
  9. What about the asynchronous form of interoperability? The OMG has a draft on the table for CosNotification and JMS interoperability. With MDB you could have your C++ code make something happen in a bean or send a JMS Message and have a C++ CORBA server act on it. Plus you get some benefits of the messaging semantic - publish/subscribe, routing, etc.

    You dont get down to the protocol layer and stay within standard API.
  10. Interoperability over IIOP directly[ Go to top ]

    I am just concerning for the approach showing in the articles. Instead of using RMI-IIOP, it ues IIOP directly. Does this break the container management for resouces like sockets and threads?