This week's book giveaway is in the Other Languages forum.
We're giving away four copies of Functional Reactive Programming and have Stephen Blackheath and Anthony Jones on-line!
See this thread for details.
Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Single EAR versus Multiple EARs Deployment

 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can you think of benefits or drawbacks for:

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


  •  
    Sanjiv Joseph Chinnappan
    Greenhorn
    Posts: 10
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
     
    Darya Akbari
    Ranch Hand
    Posts: 1855
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    What about class visibility between two EARs?
     
    Sanjiv Joseph Chinnappan
    Greenhorn
    Posts: 10
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Classes won't be visible between .ears, we have to either refer using RMI or JMS or Web Services...
     
    Darya Akbari
    Ranch Hand
    Posts: 1855
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 10
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 254
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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?
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic