EJB or not EJB?? Please read...

Discussions

EJB design: EJB or not EJB?? Please read...

  1. EJB or not EJB?? Please read... (12 messages)

    Hi

    Ok, ok, I know, this question has been asked over and over before, but let me explain...

    I'm trying to convince my team (and me!) to go ahead with EJB for our service layer. We already ruled out EJB for our persistence layer, because CMP 2.0 is too limited and entity beans are too fat. We are going to use another O/R mapping tool (Toplink or some other tool), and simple java classes. Yet, I thought that session beans would make a great service layer. I'm not so sure anymore...

    Since we are going to deploy the application on a single server (meaning that calls are going to be local), is there anything left in EJB that is worth the astronomical pricetag of a Weblogic or Websphere??

    TIA

    Threaded Messages (12)

  2. EJB or not EJB?? Please read...[ Go to top ]

    Well, JBoss is free if you are worried about price, but:

    EJB gives you transactions, which you may want.

    Session beans are also a free implementation of a great design pattern for encapsulating business logic. If your app will ever need to have another client face to it, session beans are the way to go.

    Message-driven beans are good for encasulating business logic that executes, but doesn't need to send a response to the client.

    If you are just doing a one-off webapp that is totally self-contained, you could probably just get by with no EJBs and something else entirely.
  3. EJB or not EJB?? Please read...[ Go to top ]

    Yes, JBoss is free, but it's the only one. Others are like 10K per CPU...

    If I look at things objectively, in our context EJB would be a good thing on the technical side, but what we get is not enough to justify that kind of money.

    Transactions are not only a part of EJB, and the fact that they are managed by the container is not enough, again. And the O/R tool we are going to use already has support for pooling and transactions...

    Message-driven beans... Mmmm... That could be interesting. I will add that to my short list of things in favor of EJB.
  4. EJB or not EJB?? Please read...[ Go to top ]

    I'm just a beginner in EJB, but what about openEJB ?

    It's free, open source and maintained by a master of EJB ?
  5. EJB or not EJB?? Please read...[ Go to top ]

    True, I didn't think about it. The problem here is that if I assume that the server is free and move ahead with EJB, I could end up buying a commercial server (for whatever reason, even a political one). Then the company will have to pay 10K per cpu (more or less). I'm trying to figure out if it's worth it or not. I guess the easy answer is that it's not. Yes, a free server would be a solution, but I'm not convinced the management will buy into that. We are an ASP and we have very large customers that are not into open source very much. They believe in IBM, Oracle and others. I may not agree, but this is business, and I have to accept it or move on to another job. I choose to accept it. So, we will probably buy a commercial server. That means 10K per CPU if we want EJB. That's very expensive if we look at what we get for that price. We have something like 40 cpus. Get the picture? Ouch!
  6. EJB or not EJB?? Please read...[ Go to top ]

    I agree with you, but what are your other choices ?

    Any commercial solution will cost your company a lot, EJB or not EJB.

    You could also create your own application, in any language you like, but the money you keep without buying a EJB Server will be spent in development hours.

    I wish you good luck "dans ce choix cornélien".
  7. EJB or not EJB?? Please read...[ Go to top ]

    Well, you can buy a commercial server that doesn't include an EJB container. They cost less than their counterpart (like 3K vs 10K). BEA and IBM (among others) have such offerings. I'm not too sure about their value compared to Tomcat/Apache (for example) but again, this is more political than technical. It's true that we will have to develop some stuff ourselves...

    But:
    7K X 40 CPU = 280K + maintenance (which is something like 20%/year)

    The question is, can we develop what we need for less than that? I guess I have to figure that out. Only then will I get the answer...

    "Choix cornélien"... Mmmm... Peu utilisée ici comme expression... Probablement plus de la France, vrai? =)
  8. EJB or not EJB?? Please read...[ Go to top ]

    (1) I think you need to ask yourself what services can EJBs provide to you. Services like: Distribution (RMI/RMI-IIOP), Transactions, State Management, Persistence, Security typically come to mind.

    (2) How many of these services do you need? It sounds like you've already decided that you're going to use an alternate strategy for your persistence and that you "could" use an alternate strategy for your transactions. If you're only looking at using EJBs for 1 of their services then they probably aren't worth it. The real benefit is going to come in using a set of these services. So, if you're looking at using EJBs only for your transactions then no, it's probably not worth it.. but if find that you need the transaction support in addition to 1 or 2 other services then, yes, I believe EJBs to be worth it.

    (3) What does the future for this project look like? You said that it did not need to be distributive? Does this mean that it won't need to be distributive 12 months from now? As you know.. the EJB component framework allows EJBs to be easily deployed anywhere. Taking advantage of this architecture allows your application to easily be scaled both vertically and horizontally. How difficult will it be to achieve this re-usability or adaptability with plain Java Objects? Same thing for other interfaces/clients needing to plug into your application. Who might be using your application down the line? How well is your business logic encapsulated for other types of clients?
  9. EJB or not EJB?? Please read...[ Go to top ]

    Good points...

    (1) Did that...

    (2) The list is kind of short. Transaction, state managemement, security, monitoring. That's about it. And the security offered doesn't meet all our requirements.

    (3) That's one thing I can't be sure of. But if we do things right, I think it should be fairly easy to build our solution so it can be deployed with EJB if needed. What do you think?
  10. EJB or not EJB?? Please read...[ Go to top ]

    It's probably not that uncommon for companies to go ahead and develop their J2EE solution w/o EJB, with the intention of going back and adding the EJB layer at some future date. Just be sure that you have your model and business logic pieces pretty well abstracted out.

    Since you're finding certain services of the EJB container to be in-adequate or unnecessary for your particular needs then having the EJB container may not provide you much benefit right now; however, I believe that it will certainly add the benefit to you once you start looking at going into a more distributive environment where you can scale your app both vertically and horizontally in addition to providing fail-over services such as clustering.
  11. EJB or not EJB?? Please read...[ Go to top ]

    Effectivement,

    de Nanterre, plus particulièrement.

    Mais en anglais, c'est plus simple pour les autres lecteurs.

    A bientôt,

    peut-être de vive voix.

    Rien à ajouter sur la question, tu as les cartes en main.
  12. EJB or not EJB?? Please read...[ Go to top ]

    C'est bien. Je suis du Québec. C'est pour cette raison que je disais que l'expression "problème Cornélien" n'était pas très utilisée ici! ;-)

    Au plaisir!
  13. EJB or not EJB?? Please read...[ Go to top ]

    You can have transactions without using EJBs. If you use javax.transaction.UserTransaction from the web container you get the benefit of participating in JTS. Even straight JDBC will provide transactions. These statements of course assuming the underlying database supports transactions :)

    What EJBs would provide would be declarative transaction demarcation but the importance of that being available varies with each application.