Discussions

EJB design: Do most apps need the 'distributed' portion of EJB's?

  1. Hi, I wanted to follow up on a comment on the EJB 3.1 discussion the other day. Noel wrote on 2009-03-22:
    At the end of the day, EJB in whatever form is a distributed access framework.
    I ask the question. How many application requirements actually need them to be truly distributed?
    My experience has been not many.
    From our experience, we initially built our app with the ability to put ejb's and servlets on separate servers. This was in the era of 500Mhz servers. In practice when we've done clustering, we use an apache front end (mod_jk, mod_weblogic, etc) forwarding to multiple app server instances, where each app server has the whole stack (servlet's, ejb's etc). The overhead of sending all service calls over the wire (i.e. serializing all objects) etc. does not seem to provide much benefit in the era of 3gz multicore servers, large heap sizes, and distributed caches. As developers we 'pretend' that the 'servlet jvm' differs from the 'ejb server jvm'. In practice we have only one jvm. My question: Ejb's allow software to "make very clear" the transactional boundaries/requirements. This is great. But they also are "inherently distributed", i.e. putting service implementations on separate machienes. Does this 'distributed' aspect of ejb's still matter? What are best practices? thanks, bill
  2. Whether a specific application "needs" remote access or not doesn't really have an impact on whether the framework should provide it. Basically, while Remote EJBs may well be less popular than they were years ago, I don't think that the platform should abandon the capability. For example, the Remote model is necessary even for co-deployed components. Notably, if you have an EJB and a WAR, the only supported access is through the Remote Intereface, unless the EJB and WAR are deployed together in an EAR. Now, most containers will allow you to use Local call semantics on co-deployed components, but they still go through the Remote interface. They could, down the road, "officially" deprecate the Remote calling method, but, frankly, at this point why throw out the feature? That technology is effectively amortized and "free" today. It's a "burden" to someone creating a container from scratch, perhaps, but they can write to EJB Lite and punt on full EJB altogether. Today, I like the deployment options manifested through the Remote interface, I think they give a lot of flexibility to the system.
  3. EJBs do a couple of things well[ Go to top ]

    EJBs do a couple of things well, most especially stateless session beans, which can be an efficient avenue for distributed transactions.

    <a href="writing" rel="nofollow">http://www.writingpearl.co.uk/assignment-writing-service/">writing homework help online</a>

  4. It is a definitely a type of literature, but it is not exactly possible to be analyzed, and that is the reason for which literary men and critics differ widely in their assessment of the nature of an essay.http://www.rushmyessay.com/samples/hamlet-soliloquy-analysis/

     

     

  5. The iphone app categories help you to create the folders in your iphone, ipod touch etc. This helps you to sorganize your iphone homescreen in order to keep it organized in the manner that you require whether that is alphabetical or buy App genre. As these apps have a iconit is not necessary to edit the files. When the app is inserted in to a category then it will be removed from the spring board.

    writing service