Leverage existing legacy system investments with J2EE

Discussions

News: Leverage existing legacy system investments with J2EE

  1. The ability to interface seamlessly with large legacy systems and to gain real-time control of automation systems is often considered the final frontier for applying today's agile Java 2 Platform, Enterprise Edition (J2EE) servers. This article from IBM's developerWorks site shows you how you can use Geronimo and it's CORBA interoperation to leverage existing legacy system investments while integrating heterogeneous solutions, a frequently-occurring task in modern enterprises.
  2. Good article! I guess this is the same CORBA stack that was donated from the Trifork appserver?
  3. more CORBA is good![ Go to top ]

    Anything that promotes CORBA is good thing!
    Here is the action plan to stop SOAP opera:
    - start using CORBA today for interoperability, convenience and performance;
    - help stopping the insanity :“we will not open IIOP port because we are safe only when we allow port 80”;
  4. Anything that promotes CORBA is good thing!Here is the action plan to stop SOAP opera:- start using CORBA today for interoperability, convenience and performance;- help stopping the insanity :“we will not open IIOP port because we are safe only when we allow port 80”;

    I agree.
    CORBA isnt that difficult as it is portrayed to be.
    Again, FUD camp has won.
    CORBA is superior (IMHO). It can be MUCH faster than SOAP
    SOAP/WS can be really slow when trying to exchange larrge documents.
    And then add the XML-Encryption, XML-Signature standards on top of it - and you have got a big hot enchilada in your hands.
    The same security functionality can be achieved with CORBA/EJB over IIOP. CSIv2, if implmented correctly can give the same kind of security - authentication, confidentiality and integrity all of them - with or without transport level SSL. (Avoiding end-to-end transport SSL is the very reason for all the WS- Security specs)
    And we are talking much less traffic, faster performance gentlemen!!!

    But then if one looks at the computing history technological superiority and speed hasnt always gauranteed technology adoption.

    You only need to look further at XML itself.
    When XML first came around the block, there was so much talk about how human readable it is and so on.
    However as it turns out, the only XML that humans read is the configuration xml that we write.
    And all the rest of xmls is exchanged between computers themselves.
    What is that ASN.1 cannot achieve and that only XML does ?(apart from the human readability aspect)
    With appropriate tools, it isnt diffcult to get the same benefits of XML from ASN.1
    ASN.1 is compact, lesser parsing overheads.
    Plus it isnt difficult to coneive Xml-Encryption like standards for ASN.1. And yet, XML has become the lingua franca for communications among disparate systems.

    Disclaimer: I dont hate SOAP, I dont hate XML. Each of them have their place. But IMHO they are stretched far beyond their core strength. Similar things can be achieved with other superior technolgies - that can make things easier and better in the long run. But it is not going to happen!!

    Cheers,
    Srikanth
  5. But then if one looks at the computing history technological superiority and speed hasnt always gauranteed technology adoption.
    Absolutely. It is all about convenience. Performance just has to be good enough.

    However in case of SOAP I fail to see any traces of convenience! Everybody screams “give me framework that does mundane plumbing work for me” and in the same time gladly code and fill SOAP functionality gaps again and again.
    And reinvent inferior analogs of CORBA services with XML and HTTP.
  6. It is all about convenience. Performance just has to be good enough.However in case of SOAP I fail to see any traces of convenience!

    In Java Corba development is very easy (http://java.sun.com/docs/books/tutorial/idl/hello/index.html), especially if you can use the corbaloc notation to access a server: corbaloc::mymachine:8009/GoodDay/POA/Server

    The thing lacking in Corba implementations are human readable messages. But it should be very easy to enhance IDL compilers so they generate stubs that log messages in cleartext (or even xml, why not). At IDL compile time there is all semantic information available and you could generate stubs that log something like:

    mymodule/myinterface/mystub/mystruct/mystring: got "hello world"
  7. The thing lacking in Corba implementations are human readable messages. But it should be very easy to enhance IDL compilers so they generate stubs that log messages in cleartext

    It is definitely matter of opinion but IMO CORBA’s IDL is infinitely more human friendly and readable than WSDL. There is nothing prevents developers from putting comments for humans in IDL to convey subtle semantic details and those comments are available for reading in IDL via CORBA Interface Repository or simple web page that lists all th IDLs (yes, it would be nice if they were copied by IDL compiler to stubs, by not that necessary IMO).

    Using schema definition for interfaces is probably readable, but does not make much sense because it is:
    - ridiculously verbose;
    - extremely slow to verify at runtime (try turn on schema validation in your favorite framework and enjoy your favorite beverage while messages are passing by like heard of turtles);
    - schema validation still cannot validate everything (like availability of the funds in the account or presence of the given account) that leads to splitting of the validation logic that is not a good thing from the maintenance and reliability perspective;

    Just for fun you may look at the nice schema for ISBN number (10 digits)
    http://www.xfront.com/isbn.xsd
  8. The thing lacking in Corba implementations are human readable messages. But it should be very easy to enhance IDL compilers so they generate stubs that log messages in cleartext
    It is definitely matter of opinion but IMO CORBA’s IDL is infinitely more human friendly and readable than WSDL.

    Aha! Another fine thread hijacking on the part of the usual CORBA advocates. I cannot restrain from partecipating.

    CORBA IDL (as well as DCOM IDL) is definitely more readable for a programmer. Maybe the user may find it easier to read an XSD, but a .idl file is definitely more readable, for a Java programmer, than a WSDL file.

    The reason why many argued that WSDL was more human-readable was the opinion, that spread in the years 2000-2003, that programmers would become less important in the Web Services area, as a consequence of the introduction of automated tools that could handle all the syntax and semantics. So, if application are to be managed by customers and system integrators only, the logical consequence is that WSDL is more suitable than IDL (markup language vs. imperative language) for this purpose.

    I have been hearing this story about "Getting rid of programmers" or "becoming free of developers' tyranny" or "decreasing the importance of coding" since I started professional programming. It has always turned out to be FUD, so far.

    Epilogue: there are again less Java programmers than needed, so the decreased importance of programmers has been proved a lie, again. And, as a malicious thinker, I cannot help but think that the mess of XML-handling code that must be included in every "trendy" application [I have three skilled programmers wrestling with JAXB instead of writing application logic in the room besides mine, at present] is one of the suspects for this fact.

    Now we are waiting for RVKB's comment only and we are done :)
  9. Yes, IDL is readable. But the guy was talking about actual message content being transfered, not its structure definition. Sometimes one needs to actually see (in a humanly readable form) what's going through to help in debug.
  10. C'mon, lets be serious.
    How often do you need to see TCP/IP packages content?
    How often do you need to see class bytecode?
    How often do you need to see instance serialized bytes?
    How often do you need to see JDBC exchange packages between driver and database?

    Certain things can be, and should be done in a way that allows majority of developers do not worry about correctness of the thing.

    Necessity to see wire data is a boogie man of XML zealots. There is no need for that – frameworks delivers data, and you see appropriate data structure in your language of choice. That is it, you simply look at the class, struct, tuple, whatever and simply know that this is your data, nothing was lost, nothing was misinterpreted.
  11. Epilogue: there are again less Java programmers than needed,
    I would say differently: there is definitely much more Java(C, C++, wthatever) programmers than needed,
    but less than wanted.