Discussions

General J2EE: Confused - Why use EJB at all?

  1. Confused - Why use EJB at all? (10 messages)

    Hi,
    I have gone through a number of articles in the forums.

    Everyone says Entity Beans are bad, use Session Beans with JDBC (may be thru a DAO pattern).

    Let's say we have a web based environment.
    There is one web container (running separately) and another App Server.

    Now if my application has only session beans that access database through JDBC, what is the motivation for using an app server at all? Why not write normal beans that access the DB.. and JSPs call them? Let everything be at the web tier.

    Arguments for not using an app server in this case are:

    1. there are two JVMs running. Communication is over socket(RMI/ IIOP) which would anyway be slower than passing data between objects in same JVM.

    2. The app server will eat up lots of resources.

    3. why pay a huge license money to the app server company??

    The utility of an app server everyone talks abt is scalability.
    But in a model where there are no entity beans and just session beans making a DB call for each request from the web tier, it's the database that needs to be strong, rather than the app server.

    Another strong point of App server is that it provides a distributed transactions framework. But JTA can be used instead?!?

    Separation of business logic frm presentation : this too is taken care of by putting all database access in beans.. the DAO pattern can be applied here as well.

    Roles and security is another feature. Which can again be done outside the app server.

    Please advice me on this. I am thoroughly confused.

    regards
    Anant

    PS: I am VERY new to J2EE/ EJB, so pls explain me the things in detail.

    Threaded Messages (10)

  2. Confused - Why use EJB at all?[ Go to top ]

    Hi,
      When I started EJB I was going through all these ideas myself.Out of experience I can share this to you:
     Last month we got an assignment of converting the application from Oracle to DB2 and it was horrible experience people were doing labour for that writing the DB2 compatible queries,manipulating the logics and moreever slogging.Then I wonder if we could have developed the Application using CPM only we have to change the DataSource.
    Remember the application was too large to work on.So I understood the importance of EJB's.This is one geniune reason.
     Now your other queries regarding the allocations I do agree with you but we are able to get more memory and we have to see now how fast the development can be done,why we shifted from c to c++ to java to enhance the productivity.Why to reinvent the Wheel?
     Also there is just one JVM which runs the appserver.
    regards
    Vicky
  3. Confused - Why use EJB at all?[ Go to top ]

    Last month we got an assignment of converting the application from Oracle to DB2 and it was horrible experience people were doing labour for that writing the DB2 compatible queries,manipulating the logics and moreever slogging.Then I wonder if we could have developed the Application using CPM only we have to change the DataSource.


    A very naive assumption. It's not so easy. Different databases have different approaches, but I can tell you one thing - CMP (and entity beans themselves) is a nightmare on applications larger than small Web site. In most cases it's MUCH cheaper to rewrite stored procedures, than to tune performance of your application while using CMP (also, by considering the fact that CMP will never be faster than database SP).

    Forget about cache - containers will never invalidate it if the data has been changed by another application. The cache is a doubtful issue here as well. You can maintain your own cache of objects if you want, you can add invalidation features as well. It will not be slower than your container's cache if written properly. Otherwise, you've limited control over your container's cache - that's an issue to die for.

    The main feature of EJBs - is having distributed components with extra reusability issues - that can easily be integrated with any clients and legacy systems. Another feature is unlimited scalability - you can easily cluster your appservers without rewriting your application. The use of entity beans/JDO/any other O/R mapping stuff becomes a doubtful issue for applications that require outstanding performance on low resources or use shared databases (it's pity, that most of them do).

    The main feature of EJBs - is that programmers don't have to be very qualified - every newcomer can map table fields to attributes using super-ultra-new UI tools and then call methods on this objects, it's much harder to write optimized SQL code. So, you can pay less to your programmers - that's financial issue. The development speed is also an issue here - of course, it will be much more faster to develop using O/R mapper components, than writing custom SQL code, but it will take ages to debug CMP.

    Forget about database reusability issues - how often do you change the databases? Even if your application is required to work with several databases, it will be more effective to create a set of stored procedures for each rather than maintain the use of O/R mapping.

    I think that one should use EJBs (here I assume the use of session beans and message-driven beans only) if the application requires large scalability, but for performance issues all database-related logic should be kept in database itself - it will be much faster and more scalable solution. And there will not be any need of changing your application logic if you will need to change your database, just change the stored procedures on your database and that's all.

    It's good to use EJBs when you have multiple database and require single transaction manager to deal with them.

    MDBs are a good thing too, as well as a newly introduced Time service.

    But anyway, grasp a calculator an count all your expenses on either approach before you choose wether you should stick with EJBs or not.

    So, as you see, the main buzz about EJBs is that with every single line in EJB specification, the programmers can throw out a whole block of knowledge from their brain, so, it requires much less knowledge from a programmer to develop a complex enterprise application, that means that you can do it cheaper. But is there any good for the good programmer itself when everyone can do his work? May be this is why we have the terrible situation on the job market? Cheaper programmers, slower code, faster hardware... But limits exist everywhere, someday we'll face them, what will we do next?

    Alex
  4. Confused - Why use EJB at all?[ Go to top ]

    Alex,

    To say that CMP will never be faster thant database SP is very dangerous generalization. But we can discuss the whole day and reach nothing if we don't have the proper test to check it. I'm very interested in the issue as we develop an application to be used in 4 types of RDBMS: DB2, Oracle, SQL Server and MySql (we're not imposing the DB to our clients) and this topic arouse will all the clients that are using Oracle.

    About container cache, let me assume that you're talking about Entity EJB cache. Is part of the EJB specification that at the begining of the transaction the method ejbLoad() has to be called for each EJB involved to synchronize with the database, and at the end the method ejbStore() will be called. If you handle this mechanism the right way, your data will never be out of sync.

    Also most app server implement an optimization flag of "exclusivity on database use". If you set this flag off (and is off by default in a lot of them), the data will be synchronized using the method above. If you turn it on, the CMP will optimize it calls so only if the instance change it's synchronized with the database.
    And don't forget that the EJB are pooled, that is, only a limited number of objects are created and reused.

    Can you elaborate why you feel that you have limited control over the container cache?

    Also, I don't understand why the "use of EJB/JDO/any other O/R mapping is stuff becomes a doubtful issue for applicaions that required outstanding performance on low resources or use shared databased".. No, I think that I understand now that I wrote it... First, EJB != Entity Beans. You can still benefit from using Session Beans. You can code your DB access layer to be controlled by a Session Bean to manage transactions... Anyway, to do some development using EJB don't mean that you don't have to optimize your DB schema or tune up your database (been there, done that).

    Is a misinformation that the main feature of EJB is that programmers don't need to be very qualified... That's VERY far from the truth, and thats why there are few competent programmers in the EJB field. You need not only to know java (that's the easy part), but need to have very solid knowledge about OO design, understanding of concepts like concurrency (and there are lot of people that think that think that concurrency is something you solve easily using the syncrhonize keyword <sight>), what a pool or a cache is, how they work in the EJB world, what is the lifecycle of each kind of EJB, etc,etc,etc... Is not easy, and surely not for less than qualified programmers.

    If done right, you can benefit a lot from EJB... But only if they are the solution for you. There is no silver bullet in the Software world (not even database optimization to speed up the application).

    The CMP can be debugged (if needed) using a SQL Logger that sit between the driver and the database... Indeed, that's the only way to debug wny O/R mapping framework, or to know what your application is doing to the database.

    Entity Beans and store procedure can live together perfectly (in the BMP form, that is): Use the entity bean to represent a Coarse Grained entity, and store procedures to prepare the data to populate them... Later, as you said, if you need to optimize your schema your application won't suffer.


    In short, EJB are useful only if you have a group of persons that know how to work with them, not just someone that just happens to read a book. Most of the people who hate EJB had some project that explode in their faces because something was not done right, or DBA that got laid off by a short-brained executive because with EJB you don't need them (that's VERY VERY FAR from the truth). To the formers, check success histories and do a post-mortem of the project to know what really happened. To the laters, my condolences, they were wrong and they will pay for it.

    Hope this help,
    Rafael

    PS: I agree 100% with you about the use of Session Beans and that MDB are good :)
  5. Confused - Why use EJB at all?[ Go to top ]

    Alex,


    >To say that CMP will never be faster thant database SP is very dangerous generalization. But we can discuss the whole day and reach nothing if we don't have the proper test to check it. I'm very interested in the issue as we develop an application to be used in 4 types of RDBMS: DB2, Oracle, SQL Server and MySql (we're not imposing the DB to our clients) and this topic arouse will all the clients that are using Oracle.

    Database SP is always precompiled and allows to execute several queries or statements at once. Your code can't compete with database, admit it. It will always be faster than several SQL calls from JDBC (and remember that CMP queries will never be optimized for faster execution - you can't predict execution plan of database optimizer using CMP). MySQL doesn't support SP, so the comparison is meaningless. You can easily check the performance issues if you switch PetStore from CMP to SP - as Microsoft did when they claimed .NET performance advantages.

    >About container cache, let me assume that you're talking about Entity EJB cache. Is part of the EJB specification that at the begining of the transaction the method ejbLoad() has to be called for each EJB involved to synchronize with the database, and at the end the method ejbStore() will be called. If you handle this mechanism the right way, your data will never be out of sync.

    Well that's right, but in that case the use of cache becomes a performance overhead.

    The performance issue arises - how many database calls will be made for each transaction started (this number has linear dependency with the number of beans in cache - that means that the cache slows down the performance itself... ;) )?
    The better option will be not to use entity beans at all.

    >Also most app server implement an optimization flag of "exclusivity on database use". If you set this flag off (and is off by default in a lot of them), the data will be synchronized using the method above. If you turn it on, the CMP will optimize it calls so only if the instance change it's synchronized with the database.
    And don't forget that the EJB are pooled, that is, only a limited number of objects are created and reused.
     

    This is the stick with two ends. If you use the first option, you'll have interesting performance outcome, otherwise, you'll loose the "shared database" option.


    >Can you elaborate why you feel that you have limited control over the container cache?

    See above. The cache degrades performance and you can do nothing about it.


    >Also, I don't understand why the "use of EJB/JDO/any other O/R mapping is stuff becomes a doubtful issue for applicaions that required outstanding performance on low resources or use shared databased".. No, I think that I understand now that I wrote it... First, EJB != Entity Beans. You can still benefit from using Session Beans. You

    Yes, I meant entity beans in that passage, for sure.

    >can code your DB access layer to be controlled by a Session Bean to manage transactions... Anyway, to do some development using EJB don't mean that you don't have to optimize your DB schema or tune up your database (been there, done that).

    Yes, but it becomes a harder issue. While normalizing your database you've to consider your OO model as well, but not only OO model itself, but fine-grained OO model EJBs use. In other words, you have to stick with "Entity bean corresponds to table(view)" paradigm as frequent as possible.

    And that's no good in terms of proper database normalization.


    >Is a misinformation that the main feature of EJB is that programmers don't need to be very qualified... That's VERY far from the truth, and thats why there are few competent programmers in the EJB field. You need not only to know java (that's the easy part), but need to have very solid
    knowledge about OO design, understanding of concepts like


    OOD and OOA are inevitable attributes that come with the knowledge of any OO language. In other words, I think that you can't program Java/C++/Smalltalk well without good understanding of OOA/OOD concepts.

    > concurrency (and there are lot of people that think that think that concurrency is something you solve easily using the syncrhonize keyword <sight>), what a pool or a cache

    Knowledge of concurrency is another part of OOD (as Grady Booch states), as well as a part of Java language itself (let's recall the Java's concurrency mechanisms) . By the way, EJB container's main task is to make concurrency control as simple as possible, so the programmers with very surface knowledge of concurrency techniques can create complex applications easily.

    >is, how they work in the EJB world, what is the lifecycle of each kind of EJB, etc,etc,etc... Is not easy, and surely
    not for less than qualified programmers.

    Well, but why there is no lack for qualified J2EE programmers on a job market, but still it's so hard to find a qualified Java System Programmer with good knowledge of Hotspot JVM or a good certified Oracle DBA?

    >The CMP can be debugged (if needed) using a SQL Logger that sit between the driver and the database... Indeed, that's the only way to debug wny O/R mapping framework, or to know what your application is doing to the database.

    Well, you can easily trace how the actual queries look like. But how much time will it take for you to change the query to look exactly like you want? For how long will you fiddle with CMP settings of your appserver and with your deployment descriptors? What if you'll not be able to do it exactly like you need it to be done?


    >Entity Beans and store procedure can live together perfectly (in the BMP form, that is): Use the entity bean to represent a Coarse Grained entity, and store procedures to prepare the data to populate them... Later, as you said, if you need to optimize your schema your application won't suffer.


    Hmm. Why should one use this kind of approach if it is ten times easier to create a custom object with Store and Load methods to maintain the same? Why there should be need for coarse grained entity itself?

    >In short, EJB are useful only if you have a group of persons that know how to work with them, not just someone that just happens to read a book. Most of the people who hate EJB had some project that explode in their faces because something was not done right, or DBA that got laid off by a short-brained executive because with EJB you don't need them (that's VERY VERY FAR from the truth). To the formers, check success histories and do a post-mortem of the project to know what really happened. To the laters, my condolences, they were wrong and they will pay for it.

    In fact, you can do one project in many ways. I have nothing against EJBs if it's session beans or MDBs. I will always use them if my application requires good scalability and many other features J2EE offer (like JNDI, JMS, JCA, Web Services, etc.). But I still will be very cautious with entity beans (especially CMP). Frankly speaking, I don't trust the container in terms of persistence. You will have very limited possibilities to tune your persistence performance (and let's recall that in most applications persistence performance is the first bottleneck) even when having EJB unlimited scalability under your control.

    Alex
  6. Confused - Why use EJB at all?[ Go to top ]

    Alex,

    >Database SP is always precompiled and allows to execute >several queries or statements at once.
    >Your code can't compete with database, admit it.

    As usual, it always depends on what are you doing.
    But, anyway, even if it sound contradictory, using SP in a Database while using the J2EE platform is the last optimization I would do (see above my note about the need to run on multiple database).

    >It will always be faster than several SQL calls from JDBC
    >(and remember that CMP queries will never be optimized for
    >faster execution - you can't predict execution plan of
    >database optimizer using CMP). MySQL doesn't support SP,
    >so the comparison is meaningless.

    Agreed.

    > You can easily check the performance issues if you switch
    > PetStore from CMP to SP - as Microsoft did when they
    > claimed .NET performance advantages.

    You see, part of me say "yes, you're right". That's the part that use to be Oracle crazy. The other part, the one who got blown one to many times because "optimizations" and "this is faster than that" say "Do you have numbers?".

    >Well that's right, but in that case the use of cache >becomes a performance overhead.
    >The performance issue arises - how many database calls
    >will be made for each transaction started (this number has
    >linear dependency with the number of beans in cache - that
    >means that the cache slows down the performance
    >itself... ;) )?

    The whole idea of the cache is not to do any database call if the object is in the cache... which is defeated, of course, if you modify your database without using Entity Beans.

    Before I continue, let me state my big point: Using entity beans is, most of the time, as good as using a homebrew persistence framework (besides the syndrome "NotDoneHere") and saves you the time to program it. Look at all the persistence frameworks in the marked and all of them are more or less the same as EJB without N clases to define an entity. Please, if you (or any other) disagree with this, please post your point of view... (maybe a new thread is in order)

    >>Anyway, to do some development using EJB don't mean that
    >>you don't have to optimize your DB schema or tune up your
    >>database (been there, done that).
    >Yes, but it becomes a harder issue. While normalizing your
    >database you've to consider your OO model as well, but not
    >only OO model itself, but fine-grained OO model EJBs use.
    >In other words, you have to stick with "Entity bean
    >corresponds to table(view)" paradigm as frequent as
    >possible.

    First, you can do your Entity Beans as Coarse Grained as you want (is SUN recomendation, anyway).
    Second, the big problem in using a RDMBS as the storage for OO applications is known as "object-relational impedance". So you'll have the same problems matching your schema and your OO model even if you don't use Entity Beans.

    >And that's no good in terms of proper database
    >normalization.

    If one entity bean is one table (as you stated above), and you normalize your schema, I think that this is a problem of OO design, not a Database problem. If you don't normalize your database to have a good OO desing, then you're right.


    >OOD and OOA are inevitable attributes that come with the
    >knowledge of any OO language. In other words, I think that
    >you can't program Java/C++/Smalltalk well without good
    >understanding of OOA/OOD concepts.

    That's not true. You can program in Java/C++ (I won't talk about Smalltalk as I haven't used myself) without any knowledge of OOD. For examples of this look at any proyect that is very difficult to maintain. Knowing a OO language don't mean that you know about OO desing (I haven't found a book of Java with more than few pages on design). Concepts like "Cohesion" and "Coupling" are not taught. Instead the new OO programmer learn "Encapsulation" and "Inheritance".


    >Knowledge of concurrency is another part of OOD (as Grady
    >Booch states), as well as a part of Java language itself
    >(let's recall the Java's concurrency mechanisms) .

    Knowing what the synchronize statement do don't make you know how to use it effectively, or which are it's implications. As an example, the thread model in Java is flawed (that's why they deprecated alot of method on the Thread class). Is easy to have a deadlock if you're not careful. And the ones who programmed it were professional programmers.
    Even if it's true that sometime you have to design for concurrency, the meaning of concurrency is more OS related (or JVM related) that language related.

    >By the way, EJB container's main task is to make
    >concurrency control as simple as possible, so the
    >programmers with very surface knowledge of concurrency
    >techniques can create complex applications easily.

    True. But there are too many subtleness in the concurrency managment in Java that unless you know very well what you're doing you'll meet disaster (i.e: what happen when you do a concurrent modification on iterators that come from an ArrayList?)

    >Well, but why there is no lack for qualified J2EE
    >programmers on a job market, but still it's so hard to
    >find a qualified Java System Programmer with good
    >knowledge of Hotspot JVM or a good certified Oracle DBA?

    You can't be a qualified J2EE withoud being a qualified Java System Programmer. And AFAIK there is a lack of qualified J2EE developers. And the lack of Oracle DBA comes from two sources: Is quite challenging to be a competent Oracle DBA, and those who have one don't want to let them go. With Java, nearly every college student knows it because is not a difficult language and most universities are adopting it.

    As a test, ask the next person who say "I know J2EE" if he knows the lifecycle of some kind of EJB. If he doesn't know, he is not a J2EE qualified developer. The same is true (but not as strong) for the lifecycle of a servlet.

    >Well, you can easily trace how the actual queries look
    >like. But how much time will it take for you to change the
    >query to look exactly like you want? For how long will you
    >fiddle with CMP settings of your appserver and with your
    >deployment descriptors? What if you'll not be able to do
    >it exactly like you need it to be done?

    What if I can better the performance in some other place instead of fiddling with container and DB? What if the DB is not the issue?

    >>Entity Beans and store procedure can live together
    >>perfectly (in the BMP form, that is)
    >Hmm. Why should one use this kind of approach if it is ten
    >times easier to create a custom object with Store and Load
    >methods to maintain the same? Why there should be need for
    >coarse grained entity itself?

    Because you'll end up implementing more or less the same kind of EJB-like framework if you want to control the object creation and lifecycle.

    >Frankly speaking, I don't trust the container in terms of
    >persistence. You will have very limited possibilities to
    >tune your persistence performance (and let's recall that
    >in most applications persistence performance is the first
    >bottleneck) even when having EJB unlimited scalability
    >under your control.
    So, it's all a matter of trust. I respect that.
    Don't use anything that you don't trust.

    Rafael
  7. Confused - Why use EJB at all?[ Go to top ]

    The whole idea of the cache is not to do any database call if the object is in the cache... which is defeated, of course, if you modify your database without using Entity Beans.


    Yes, but on practice we have situation when cache provokes the calls to database (when the beans in cache sync themselves).

    If you don't use entity beans in most cases you can provide your own caching that will work exactly as you want it that will sync the only instances you want to be synced and only when you want it to happen. I know, that the development time will be faster, but you write frameworks once and use it through all the product lifecycle (save that you can use it in other projects as well).

    Okay, I'll tell you which self-grown framework I currently use in my project and you tell me what you think of it (see my new post).

    Alex
  8. Confused - Why use EJB at all?[ Go to top ]

    Alex,

    >Yes, but on practice we have situation when cache provokes
    >the calls to database (when the beans in cache sync
    >themselves).
    The sync of the cached object only happen if:
    1.- For CMP, the EJB container don't have exclusive write access to the database, or the container is not very smart.
    2.- For BMP, if you don't implement a kind of "dirty flag" so the ejbStore and ejbLoad don't hit the database if nothing changes.
     
    I'll check your new post :)

    Rafael
  9. Confused - Why use EJB at all?[ Go to top ]

    The sync of the cached object only happen if:


    >1.- For CMP, the EJB container don't have exclusive write access to the database, or the container is not very smart.

    Yes, I am talking about applications without exclusive write access to database - most of the projects I did use shared databases. In that case the cache is a performance overhead in CMP world. I am not sure if there is any container exists that allows you to manually point which Commit options (A, B or C - see EJB spec) for one or another bean. If you know any containers with such options - tell me than, may be I didn't study them to accurately.

    >2.- For BMP, if you don't implement a kind of "dirty flag" so the ejbStore and ejbLoad don't hit the database if nothing changes.

    Well, you can do that with BMP, but, it still not the thing I like. There is no need to store the beans in cache if you use shared databases and require them to be up-to-date. You'll save a lot of database requests if you stick with it in either world. But you can't specify which beans to cache and when to timeout them (if you need them up-to-date but on timely basis, for example). I can easily do that with my framework and the overall coding time of using my framework with code generators will be less... So, I get more flexibility+more performance at the same/smaller price.

    Alex
  10. Confused - Why use EJB at all?[ Go to top ]

    This is not a simple question to answer. It really depends on what you need. My advise in these case (when you don't know whether to use EJB or not) is not to use them. But design carefuly your application so the business logic is encapsulates and separated from the data layer. This way will be easier to migrate to EJB once you get a grip of them.

    That said, let me answer your questions, queries and concern.
    First, you don't want the app server and the web app server to run in different, specially if you're paying big bucks for using some of the lead app server that have all integrated in one single package, unless you want a distributed approach. If that is the case, you will benefit for the distributed nature of EJB.

    You are rigth when you say that if only session beans are used with JDBC the strength needs to be on the database... Session beans are there not to relieve the database, but to provide distributed capabilities (if needed) and the ability to manage transactions that spawn over multiple operations. You can use JTA explicitly or let the container manage it. BTW, to use JTA you need to have a concrete implementation of JTS for the domain you're working (like DataBase). All the containers provide this to you. Of course, if the only transactional resource you'll access is a Databse, managing transactions is pretty sinple (until you came across transactons that spawn over multiple calls)

    Database independancy (if you use CMP, that is) if a very good added thing.

    No let me defend one of the most attacked member of the EJB: The Entity Bean. What are they good for?
    First, they provide a caching mechanism of data. That is, if you use the same Entity Bean over and over you'll be using the cache of data instead of the Database data. This is good if you're sure that you are modifiying the database only over the Entity Bean layer.
    Second, and this is a property of good data layers, there is syncronization between different instances of the same data.

    Now, Entity Beans have two flawors: BMP and CMP. BMP are famous for not being very efficient, and they aren't if you take it out-of-the-box, mostly because on each transaction the ejbLoad and ejbStore are called, and that a findBy method requires n+1 calls to DB. But there are a lot of patterns to increase their performance (see "Fat Key" pattern in this site for a solution to the n+1 call problem, and use a dirty flag so ejbLoad and ejbStore don't hit the DB if the instance was not modified).
    CMP are famous for it lack of flexibility when a query over multiple tables is needed. EJB 2.0 solves this problem (well, is a step in the right direction, anyway), but they excel in velocity and gives you the precious DB independance (at expences of app dependancy but, believe me, it's easier to migrate a bunch of CMP from one container to another than to migrate an app from one database to another)

    Most of the advantages of Entity Beans can be achieved by using a good Persistance Manager (there are a few out there). Some of then even have more features than EJB, some of them lack distributability or a good JTS service. The true advantage (if we can call it so) is that EJB is a standard, that is, you're more likely to find a guy with EJB experience that a guy with experience in some other persistance manager.

    Another member of the EJB family, less named but useful sometimes, is the MessageDriven Bean. Basically is a bean that is listening to a JMS queue and triggers some action when some message is received. This allows asynchronous operations when needed. Haven't use them in real life so I can't give you a feeling of what they are good for.

    wow, this is a long post. Hope this help you to weight is EJB are the way to go for you. I can say that they were the way to go for me, twice.

    m2c

    Rafael
  11. Confused - Why use EJB at all?[ Go to top ]

    As I see it, the main benefit of session beans is in the area of transaction management. Yes, you can use JTA, but it's difficult and tedious to get it right in every piece of code. We did it that way at a previous company, and half your time and code was spent with these try/catch/finally blocks.

    Besides, you don't have to pay big money for app servers. Check out jonas or jboss. And communication is only over sockets if you're using remote interfaces. For what it's worth, we use all local EJB interfaces, so everything is run in the same JVM.

    So, yes, you can use EJBs remotely, use entity beans, etc. That's the "big model" of using EJBs, and it works. But you can also use them "writ small" and IMO there's still a benefit.