*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Single EAR versus Multiple EARs Deployment Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Single EAR versus Multiple EARs Deployment" Watch "Single EAR versus Multiple EARs Deployment" New topic
Author

Single EAR versus Multiple EARs Deployment

Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Can you think of benefits or drawbacks for:

  • single EAR over multiple EAR deployment
  • or
  • multiple EAR over single EAR deployment



  • SCJP, SCJD, SCWCD, SCBCD
    Sanjiv Joseph Chinnappan
    Greenhorn

    Joined: Apr 11, 2009
    Posts: 10
    Benefits:

    Better manageability and availability
    Separation of functionality

    Drawbacks

    Cross ear method calls needs to be remote or distributed
    overhead involved in these calls
    Distributed transactions if required is complex / expensive


    -Sanjiv Joseph
    SCJP, SCEA 5

    Darya Akbari
    Ranch Hand

    Joined: Aug 21, 2004
    Posts: 1855
    What about class visibility between two EARs?
    Sanjiv Joseph Chinnappan
    Greenhorn

    Joined: Apr 11, 2009
    Posts: 10
    Classes won't be visible between .ears, we have to either refer using RMI or JMS or Web Services...
    Darya Akbari
    Ranch Hand

    Joined: Aug 21, 2004
    Posts: 1855
    Sanjiv Joseph Chinnappan wrote:Classes won't be visible between .ears, we have to either refer using RMI or JMS or Web Services...


    ... or fork out those classes into a separate archive.

    I think putting all classes into one big EAR maybe nice for development but in an production environment you are better off with multiple EARs as you said for manageability reason.
    Sanjiv Joseph Chinnappan
    Greenhorn

    Joined: Apr 11, 2009
    Posts: 10
    I would suggest to keep development .ear structure and PROD.ear structure as close as possible, may be you can use the same maven or ant scripts to take the build for both environments,

    the advantage keeping this way are,

    >If issues come up, replicating and fixing the same will be easy
    >If you want to do performance testing, you will have closer looking set up, same remote method invocation, resource allocation deallocation, JNDI references etc..
    >Security rules and deployment descriptor config details will be easy to maintain.

    & many more....
    J J Wright
    Ranch Hand

    Joined: Jul 02, 2008
    Posts: 254
    I'm not sure I'd want to take a minimum 30% performance hit by making local calls remote for the sake of manageability. Your application server may well optimize these calls but then you're not developing to the J2EE spec, which is rather vague on calls between EJBs in different EARs running in the same JVM.

    The only justification I can think of is if you're putting your Servlet and EJB containers onto different tiers to introduce load balancing between them for scalability, availability, or hardware utilization reasons (especially if most of your incoming requests can be handling entirely by the Servlet tier). On the downside the administration overhead goes up.

    That said, why not just use collocation and clustering?


    SCJP, SCWCD, SCBCD, SCEA 5
     
    It is sorta covered in the JavaRanch Style Guide.
     
    subject: Single EAR versus Multiple EARs Deployment
     
    Similar Threads
    Deployment Diagram and Part 2
    merge two war files into one
    General Deployement Questions...
    questions about EARs and Assembling and deploying multiple web applications
    Websphere 6.0 Rapid Deployment