IONA Announces Orbix E2A AppServer Platform 6

Discussions

News: IONA Announces Orbix E2A AppServer Platform 6

  1. IONA Announces Orbix E2A AppServer Platform 6 (17 messages)

    IONA today announced version 6.0 of its Orbix E2A AppServer Platform (ASP). The new release focuses on integration, adding new features such as a security service which interoperates across CORBA, J2EE, Web services and mainframe technology domains; a bridge between JMS and Corba Notification, the ability to aggregate multiple mixed-technology components into business-level Web services, etc.

    Read the press release and an article: Iona updates app server platform(infoworld).

    The product will be generally avaiable in 45 days.

    Threaded Messages (17)

  2. With SOAP capturing market so fast, where will you use CORBA and why ? Isnt CORBA quite complicated , need to learn new IDL etc..
    Please update me.
  3. Advantages of CORBA over WebServices are:

    1. Performance & scalability
    2. Maturity & Reliability
    3. CORBA Services (Transaction, Notification, Security...)

    Disadvantages:

    1. Relative complexity
    2. Problems with firewalls
    3. Deployment (ORB needs to be installed on every machine)
    4. Not supported by all vendors (M$).

    Mileta
  4. Isnt CORBA quite complicated , need to learn new IDL etc..


    CORBA is not much more complicated then web services. Maybe to write hello world with CORBA is more complicated than with web services. We can also say that web services are too complicated when we take a look on a monster XMLs needed for SOAP envelope and WSDL.
    And IDL is not more complicated than WSDL. On the contrary, it MUCH MUCH MORE READABLE then UGLY WSDL !

    Mileta
  5. I m not sure abt how "UGLY" u think web services/wsdl is, but u sound more like u hate web services than u like CORBA. Anyway ...
       For me Web services are pretty simple to implement. And I find WSDL a lot more readable than any any other language. Its more like english put in tags format.
       And as the first reply said, CORBA is fairly complex ... that explains why the popularity of corba has gone down so much in last 3 years.
       Wish U All Happy Holidays !!!
  6. I m not sure abt how "UGLY" u think web services/wsdl is, but u sound more like u hate web services than u like CORBA. Anyway ...
       For me Web services are pretty simple to implement. And I find WSDL a lot more readable than any any other language. Its more like english put in tags format.
       And as the first reply said, CORBA is fairly complex ... that explains why the popularity of corba has gone down so much in last 3 years.
       Wish U All Happy Holidays !!!
  7. CORBA is not much more complicated then web services


    I am afraid I have to disagree here.

    Assuming a C++ client to an EJB server, it is the hello-world app that suits CORBA more than SOAP.

    In particular, if you are using OBV (ie everything but the most trivial of clients) then the difference in CORBA and SOAP is stark.

    In SOAP, most toolkits (of which there are few good ones) will generate proxies from WSDL. Not only that, they generate Value Object factories + factory registration code.

    On the other hand, value objects in CORBA are horrendous. You have to remember to register each and every OBV factory on startup. If you forget one, then your app will crash with a MARSHAL exception.

    Now, a decent appserver will generate your IDL from your EJB-jar - but not all -leaving you to generate the IDL manually.
    (It is interesting to note here that Weblogic has the best support in this area. Last I looked at Websphere and Borland, you still had to do the IDL generation on a class-by-class basis.)

    Where it then gets really painful is in the area of Exceptions. The Java2IDL mapping spec maps a Java Exception onto a CORBA exception AND a CORBA Value Object (the VO gives you the object-behaviour that java.lang.Exception does.

    What is more, even if you have good tools for IDL generation, they will only generate the IDL as per the interface they are given. If you have any form of inheritance in your Value Objects OR Exceptions, then you have to make sure that you a) generate IDL for them and b)register the OBV factories.

    OBV CORBA is both complex, error-prone and full of pitfalls.

    The picture isnt entirely rosy on the SOAP side from a C++ client. The performance hit is large. The tools are not abundantly good either.

    The kind of C++ that WASPC++ generates is ugly, the latest Microsoft Tools require the .net runtime (I havent seen STK3 though - I hear its miles better than v2.0).
    The only decent tool we have seen here is RogueWave's Persian.

    Interestingly, Roguewave have a product called Bobcat. It is a C++ Servlet Engine - ie you write servlets in C++! It is very interesting. (What is most entertaining is the subsecond startup time compared to say, Tomcat)

    If you are only moving primitives (unlikely) then perhaps CORBA is the go. Otherwise, unless you *need* the performance, then steer clear of OBV CORBA.

    -Nick
  8. Nick,

    The thing is -- CORBA itself isn't that complicated. It's really not.

    BUT... OBV *is* really ugly. It's an abomination. And nobody in the pure CORBA world uses it. The fly in the ointment is the fact that the Java to IDL mapping requires it. Whoever wrote that spec should be shot -- it's wasteful, it's inefficient, and it works in a Java-ish way and not in a distributed systems way.

    So CORBA systems (nearly all of them) avoid OBV. And good applications that call into EJBs from CORBA typically avoid it, too -- they use a bridge... CORBA client to a Java corba server which is an RMI client to the EJB server. Works well, and is much simpler and faster (and flexible) than the OBV solution.

    CORBA is very good for IPC -- across language, across platform, in a secure, interoperable way. It's a bit tougher to use (especially on paper, when you're using security and persistence) but then again persistence with J2EE is mostly hand coded anyway (a la CORBA) so the paper/marketing advantages never really came true.

    CORBA really lost its way because it wasn't marketed well (the OMG is a joke for this, and the vendors aren't good, where J2EE has Sun pouring millions into it and telling all their server customers it's "the way forward"), and because some of the CORBA vendors burned their customers, more so than for technical reasons.
  9. CORBA really lost its way because it wasn't marketed well

    >> (the OMG is a joke for this, and the vendors aren't good,
    >> where J2EE has Sun pouring millions into it and telling all
    >> their server customers it's "the way forward"), and because
    >> some of the CORBA vendors burned their customers, more so
    >> than for technical reasons

    No, I cant agree with you here. Its not simply the result of a successful marketing ploy. CORBA is complex compared to RMI/EJB - with no upside to speak of (other than language independance - so long as the language is Java or C++...).

    The declarative security, declarative persistance, declarative transaction, seemless clustering and messaging integration features of EJB, really leave CORBA no place on the server side other than as a legacy integration technology (and even there, it is squeezed my MOM and J2EE Connector and SOAP).

    There is no way I would use CORBA over using EJB on the serverside.

    >> BUT... OBV *is* really ugly
    Agreed.
    Admittedly, some better IDL2Cpp tools would make a huge difference here for coding client-side CORBA access.
    Code generation for the registration of OBV factories is simple to do - and essential for any sort of reliablity.

    >> So CORBA systems (nearly all of them) avoid OBV
    I would too (if I were to ever work on another CORBA system). Trouble is, as you say, thats the only choice you have if using EJB on the serverside.

    >> CORBA client to a Java corba server which is an RMI client
    >> to the EJB server
    I certainly dont thing that hand-writing a CORBA-RMI bridge is better value for money than using SOAP or OBV.


    >> but then again persistence with J2EE is mostly hand
    >> coded anyway
    Not true at all.


    The only argument I see for using CORBA (over SOAP) for C++ client integration (to access EJB) is for performance.
    The other arguments of security and clustering are only true for single-vendor solutions.


    -Nick
  10. The declarative security, declarative persistance, declarative transaction, seemless clustering and messaging integration features of EJB, really leave CORBA no place on the server side other than as a legacy integration technology.


    How about the flexibility that CORBA offers? Unlike the cookie-cutter threading model offered by J2EE appservers, you can come up with your own.

    There are several niche areas that require more flexibility in building a system than J2EE offers.

    >> I would too (if I were to ever work on another CORBA system). Trouble is, as you say, thats the only choice you have if using EJB on the serverside.

    You can write CORBA friendly EJB's (assuming you are writing EJB's after you had developed your CORBA system..). Start with an IDL, generate an interface out of it and go from there. At least you will not end up with lot of sphagetti java objects to marshal.

    >> I certainly dont thing that hand-writing a CORBA-RMI bridge is better value for money than using SOAP or OBV.

    care to explain ?

    In the event that your system is transactional, CORBA-RMI bridge offers the best bang for your buck. You can propagate tx from corba to j2ee world and vice versa. The system scales better.

    >> The other arguments of security and clustering are only true for single-vendor solutions.

    ... even with CSIV2 ?

    -Srini
  11. How about the flexibility that CORBA offers?

    >> ... threading model ... you can come up with your own

    True.
    But how often do you need that?
    In my experience, not often. (And, dont worry, I had these same concerns when first moving to EJB. My concerns have not been realised so far...)

    Multi-threaded server applications are not trivial to write. I have worked on systems (already in production, mind) that had severe threading issues (data corruption and deadlocks). EJB, while seemingly restrictive, goes a long way to preventing that. The added reliabily you automatically have with EJB outweighs its "inflexibility".

    >> You can write CORBA friendly EJB's (assuming you are
    >> writing EJB's after you had developed your CORBA system..).
    >> Start with an IDL, generate an interface out of it and go
    >> from there

    I dont think so.
    The EJB and CORBA interfaces are completely different.
    The EJB interfaces have to extend EJBObject for a start.
    Am I missing something?

    >> >> I certainly dont thing that hand-writing a CORBA-RMI
    >> >> bridge is better value for money than using SOAP or OBV.
    >> care to explain ?

    Yes.
    a) You have to write a server (another reason why we dont use CORBA anymore. With EJB, you already have a server - the appserver). Not only do you have to write the server, but you have to write admin tools for it, documentation for it. Installation guides for it. etc etc etc.
    b) You are adding a proxy layer - which means you now have 4 points of interface contact (EJBServer-RMIClient-CORBAServer-CORBAClient) rather than 2. At least doubles the maintenance overhead.
    c) Its an added point of failure.
    d) Its an added server to monitor/support
    e) ...

    >>... even with CSIV2 ?

    Yes.
    a) There is no guarantee that the ORB vendor supports it or supports it properly. The fact that there is no certification process for CORBA (unlike J2EE) has been one of the reasons for its failure.
    b) Same goes for clustering. The clustering is meant to be implemented via INS - but there is no guarantee that they will work together.

    -Nick
  12. You can write CORBA friendly EJB's (assuming you are

    >> writing EJB's after you had developed your CORBA system..).
    >> Start with an IDL, generate an interface out of it and go
    >> from there

    >>>I dont think so. The EJB and CORBA interfaces are completely different. The EJB interfaces have to extend EJBObject for a start. Am I missing something?

    What I meant was, you have an ejb that takes in a vector as a parameter. Now try to invoke on this ejb from a CORBA client...

    Or take create an IDL, generate stubs and skeletons.

    Create an ejb remote interface similar to _XXXOperations interface. This will be your corba-friendly ejb.
    You wont have problems with the mapping.

    -Srini
  13. IONA Announces Orbix E2A AppServer Platform 6[ Go to top ]

    U guys seem to have cool knowledge abt CORBA and java too. One thing for sure, I had tried corba with C++ / Java / Vb long time back and I realized if i have to use CORBA I have to learn a lot new stuff, struggle with a lot of issues - be it simple network config or be it generating IDL and then limited data types to pass in cross platform calls. simply put it seemed like a pain in the neck.
      A hell lot of time is wasted on simple config issues and its so much frustating. Sometime I feel things are made unnecessarily complicated.
      I serioulsy dont see any good reason to go for CORBA when J2EE is sufficient for all the needs and it REALLY realitive simpler than Corba.
       Also the fact that this discussion thread has less than 15 messages till now shows the interest of the community in CORBA.
  14. A good reason to use CORBA is if you have existing systems that are written in something other than Java or J2EE. Examples could be C, C++, COBOL, PL/1 (all supported by IONA).

    That's still most of the systems.

    On your configuration comments -- this depends a lot on the ORB. Some ORBs are very simple to configure. Some are very difficult. Same goes for J2EE -- some app servers take a week or more to learn how to configure, deploy, manage, ... J2EE is often more complex than CORBA (because vendors include persistence, security, ... which some but not all ORBs provide)... so no way is configuration a cinch.

    And network configuration? Hmmm? How could that affect CORBA but not RMI?
  15. I had heard few years ago that an ORB can be a good backbone for an EJB server. May be this means CORBA is a good technology but it's not something we should "see" very often unless we are an EJB server developper. It becomes a low layer under J2EE or CCM stuff. Is IONA (still) building is appserver on its ORB ?

    Nevertheless I worked on real-time distributed systems where performance and fault-tolerance is important, WS won't be the solution today. Of course I understand CORBA may not be interesting for getting informations from google or a stock quote from somewhere.

    I have the impression some people want to only choose one technology for ever : WS is good, CORBA is good, depends on the problem. You don't use XML if you only have a very very small bandwidth, you use binary format, even if it's "ugly", it's compulsory.

    You don't see lot of people talking about CORBA here the same way you don't see people talking about C++ STL : it's J2EE world here.

    This was my 2 cents...
  16. Is IONA (still) building is appserver on its ORB ?


    Yes. IONA has a J2EE application server part of this Orbix E2A appserver platform and it is built on Orbix.

    >>I have the impression some people want to only choose one technology for ever : WS is good, CORBA is good, depends on the problem. You don't use XML if you only have a very very small bandwidth, you use binary format, even if it's "ugly", it's compulsory. You don't see lot of people talking about CORBA here the same way you don't see people talking about C++ STL : it's J2EE world here.

    Couldn't have put it better myself.
  17. J2EE is often more complex than CORBA


    What you mean is EJB (beacause JavaIDL is part of J2EE).

    THere is absolutely no way that EJB is more complex than CORBA.

    -Nick
  18. I agree that anything in J2EE including EJB is not as complicated as CORBA. CORBA has a hell lot of issues when I just want to call one machine from another - right from firewall - network , ip , protocol , config files, data marshalling datatypes and others .. anyway .. thats just my experience & i m never going CORBA way again.