This forum has been archived. Please start a new discussion on GitHub.

Compared with EJBs?

I'm thinking about suggesting ICE to a client.

Can someone give me a comparison of ICE to EJBs. I realize that they are not exactly going for the same functionality... but I think ICE does offer a valid alternative.

Actually... why so much about the comparison between ICE and CORBA on your website/docs. I would have thought that a more pertinent question these days, since CORBA died in most peoples minds years back, would be to compare it to EJBs, esp. since you support java?

At my work we have been looking for an alternative to EJBs for a few years now. For the type of work we do WebServices are too heavy.



  • bernard
    bernard Jupiter, FL
    In terms of abstraction level and programming model, Ice is much closer to CORBA than to EJB, so comparing Ice and CORBA seems more meaningful.

    EJB is 'higher level': you write your business logic in beans (components) according to a few patterns and the EJB container handles pretty much everything else. This is arguably easier to use, but also less flexible. EJB treats a subset CORBA as its underlying plumbing -- mainly IIOP, CORBA's protocol layered over TCP/IP.

    We took a different approach to make distributed object programming with Ice easier. Instead of wrapping CORBA, we addressed the problems: Ice has a simpler object model, a simpler API, a simpler protocol, and is nonetheless more flexible than CORBA. Ice also provides "helpers" that are not in CORBA, such as the Ice Application class (a simple container that handles initialization, shutdown and signals) and the Freeze Evictor (a simple automatic persistence mechanism). These helpers are convenient, but you don't have to use them if you need more flexibility.

    Now, it's possible to write a distributed object application with Ice or EJB (or CORBA obviously), so why pick one over the other?

    I think Ice makes sense:
    * if you want to write clients or servers in C++ (and soon C#) or clients in PHP. EJBs can be called through CORBA, but in practice the API is too ugly.
    * if you need more flexibility than EJB provides, for example for synchronization, object-lifecycle management, handle creation, asynchronous calls, asynchronous dispatching.
    * if you are concerned about the heaviness of EJB containers. In contrast, Ice is very lightweight.

    And EJB makes sense in a pure Java environment if it's flexible enough for your needs and some EJB features are useful for your application, e.g.:
    * container-managed persistence: the ability to store data in relational databases without making database calls in your code.
    * transactions (Ice does not provide transactions yet).
    * the ability to deploy your application/components in different EJB containers (JBoss, Weblogic, Websphere ...).

  • If the application does require storing data in relational database, obviously needs transactions too, but it's a crossplatform, EJB is too heavy, can these requirements (RDBMS, transaction) being easily integrated into ice? Or if there is any product around that created on top of ice and do just that?
  • bernard
    bernard Jupiter, FL
    By transactions, I meant distributed transactions, typically with 2 phase-commit. Ice currently does not provide the ability to start a transaction in a client, pass around a reference to this transaction with all requests, and coordinate a two-phase commit in case this distributed transaction "touches" several resource managers.

    Now, if you're just implementing a server that stores its data in a relational database (very common), you don't need distributed transactions: you can simply code using the Ice API and your database system API, and use the full range of features offered by the database system (for example transactions).
    Freeze is not involved in this scenario. You can see Freeze as a sophisticated "wrapper" for Berkeley DB: if you want a very simple way to store Ice objects in a Berkeley DB database, use Freeze. Otherwise, use directly your favorite database system.