StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Since you are being so abstract I will do it as well. If we remove all buzzy words as "Portal", "Enterprise Apps" and so on... What we have at the end is three web apps and a common library or framework (The enterprise App). </p> <p>Seeing its app as simple as posible. You have three developers that need develop three web apps. You will provide some common code useful to build their apps. The model you will use will depends of what kind of code you will provide them.</p> <p>1.- You will only provide some utils, and common business code. May be the clasical library fit your needs. (In Java EE environments you must take in account how can you take the advantages of persistence cache level 2 sharing a Session Factory for a single datastore)</p> <p>2.- You will provide shared services as persistence, cache, security, audit, and so on... You will need a service layer as the first option. You will have a shared state so you need only one instance.</p> <p>3.- The more common case is both you provide some business API and a service layer to common services.</p> <p>You aren't indicating any requirement that force you to use a more complex solution for your scenario.</p> <p>EDIT:</p> <p>About if it is prefered rmi (the ejb-client) or webservices. I always use rmi to communicate applications geographically close. It use is simple and the protocol is much more faster that webservices (you can read a lot of comparison over this topic searching for rmi webservices performance on google). <br /> On the other hand rmi is more sensible to network latence, require special firewall configurations and it is more coupled that webservices. So if I pretend to offer services to a third party or connect geographically sparse servers I will prefer webservices or even REST.</p> <p>About the last question initially there is no any difference about deploy one or ten applications in the same server. The deploy fee will be insignificant over the overhead for the use of the application. Of course, you must take this as a generical assumption. Obviously the size and how you deploy your applications will have an impact about the memory consumption and others.</p> <p>You must take in account that this decisions can be easily changed as you will needed. So as I said you could start with the simple solution and if you encounter a problem deploying your applications your could restructure your ears easily. </p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload