EJB3 Enterprise Application As Portal & Client Web Apps - Architecture/Design

Question

As shown in the above pic, I have a EJB-3 Enterprise application (EAR file), which acts as a portal and holds 3 web applications (WAR files) that communicate and transact with the same datastore. These 3 webapps are not portlet implementations, but normal webapps which interact with the datastore through the Enterprise App's Persistence Layer. These webapps are developed independently and so, some of 'em use Webservices from the Enterprise App and some of 'em use EJB-Clients.

Also, there is an other option of replacing these webapps (Web App1, Web App2 and Web App3) and using independent Enterprise Apps to communicate and transact with the database, as shown below:

Now, my questions are:

1) What is the best Option among the listed 2 options (above)?

2) How does it affect when we replace those webapps acting as clients to the Enterprise App, as independent Enterprise Apps (EAR files)?

3) What is a better model for Transaction handling, SSO functionality, Scalability and other factors?

4) Are there are any other better models?

EDIT:

1) In the first model, which method is a preferred way to interact with the EAR file - webservices or ejb-client jar file/library (interfaces and utility classes)?

2) How do both models differ in memory usage (server RAM) and performance. Is there any considerable difference?

Ugrian

Why are you considering these 2 options? eg is it for different deployment options? Also, how do you split data access in option 2 - does each EAR have "ownership" for it's own data, or would they each have full read/write access across the whole dataset? If separate, where are the transactional boundaries? Would each EAR only need to be concerned with it's own boundaries? What type of datastore do you have and will it be a bottleneck. Is your application predominantly read, or write. Sorry, for all the questions - I hope these don't reflect my own ignorance! – Bipolar

Romski: I'm considering these 2 options, out of my own curiosity and just to find out what are best practices and which is better suited for our needs. As for your questions, yes each EAR has ownership. They are designed/developed that way, as they handle different functionality and for other business reasons. All applications are predominantly both read&write and use RDBMS, at the moment. – Ugrian

Also, please check the 'Edit' part of my original post. – Ugrian

Answer 1

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).

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.

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)

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.

3.- The more common case is both you provide some business API and a service layer to common services.

You aren't indicating any requirement that force you to use a more complex solution for your scenario.

EDIT:

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).
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.

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.

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.

Mildred

FidoX: Thanks for the answer. Please check the 'Edit' part of my original post. – Ugrian

Answer 2

I'm inclined to agree with Fedox. If there is no reason for choosing one solution over the other ( business reason, technical reason, etc) then you might as wel choose the path of least resistance. To my mind that would be the first solution.

In general terms start simple and add complexity as you need to. Your solutions have no meaning without context. A banking app needs different considerations to a blog.

Hope this helps

Bipolar

Answer 3

There is a new platform called Vitria's BusinessWare, it's a very successful project which is worth millions.
Now let's see how does it work and what it does so that we can do the same in theory:
It interconnects projects with their databases, web-services with their EJBs..etc. From their concept we can learn the following:

1. Create main EJB stateless bean (API), whose job is to pass messages from:

   • web-services to other web-services
   • web-services to webapps
   • webapps to other web-services

2. The purpose of this EJB is first do validations in the main database and then pass the calls to the other modules.

3. Only this EJB has access to the DB to more secure the connections
4. This EJB will queue the messages until the modules to sent are free to accept
5. This EJB will control all the processes in the DB
6. This EJB will decide where to send the messages

Drouin

Mike: I upvoted your answer for the effort, although it wasn't what I was looking for. So, I cannot upvote you again. :( – Ugrian