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

Question

As shown in the above figure, I have an EJB-3 Enterprise application (EAR file) that acts as a portal and contains 3 web applications (WAR files) that exchange data and perform a transaction with the same data store. These 3 web applications are not portlet implementations, but ordinary webapps that interact with the data warehouse through the Enterprise App Persistence persistence layer. These web applications are developed independently of each other, so some of them use web services from the Enterprise App, and some of them use EJB clients.

In addition, there is another possibility of replacing these web applications (Web App1, Web App2 and Web App3) and using independent Enterprise Apps to exchange data and conduct transactions with the database, as shown below:

Now my questions are:

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

2) How does this affect when we replace those web applications that act as clients in the Enterprise App with independent Enterprise Apps (EAR files)?

3) What is the best model for transaction processing, SSO functionality, scalability and other factors?

4) Are there any other better models?

EDIT

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

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

Answer 1

Since you are so abstract, I will do it too. If we remove all buzzy words like "Portal", "Enterprise Apps", etc. .... In the end, we have three web applications and a common library or framework (Enterprise App).

Seeing his application is as simple as possible. You have three developers who need to develop three web applications. You will provide some generic code useful for building your applications. The model you will use depends on what code you provide them.

1.- You will only provide some utilities and a common business code. Maybe the classic library fits your needs. (In Java EE environments, you should consider how you can take advantage of persistence level 2 caching, which shares a Factory session for a single data warehouse)

2.- You will provide general services like persistence, cache, security, audit, etc. For the first option, you will need a service level. You will have a general condition, so you only need one instance.

3.- More common is that you provide some business APIs and a service level for shared services.

You do not specify any requirements that force you to use a more complex solution for your scenario.

EDIT:

About whether rmi (ejb-client) or webservices is preferred. I always use rmi to geographically close applications. It is simple, and the protocol is much faster than web services (you can read a lot of comparisons on this topic, looking for rmi webservices performance on Google).

Rmi, on the other hand, is more sensitive to network latency, requires special firewall configurations, and this is more closely related to web services. Therefore, if I pretend to offer services to a third party or connect geographically sparse servers, I prefer web services or even REST.

Due to the last question, at the beginning there is no difference in deploying one or ten applications on one server. The deployment fee will be low compared to the overhead for using the application. Of course, you should accept this as a general assumption. Obviously, the size and deployment methods of your applications will affect memory consumption and others.

You must bear in mind that these decisions can be easily changed as necessary. Since I said that you can start with a simple solution, and if you have a problem deploying your applications, you can easily rebuild your ears.

Answer 2

I tend to agree with Fedox. If there is no reason to choose one solution over another (business reason, technical reasons, etc.), you can also choose the path of least resistance. In my opinion, this will be the first decision.

In general, start as simple and complex as you need. Your decisions do not make sense without context. A banking application needs various considerations for a blog.

Hope this helps

Answer 3

There is a new platform called Vitria BusinessWare , a very successful project that costs millions.
Now let's see how it works and what it does so that we can do the same in theory:
He combines projects with his databases, web services with his EJB. From their concept, we can learn the following:

• Create the main EJB stateless bean (API), whose task is to transfer messages from:

  • web services for other web services.
  • web services for webapps
  • webapps for other web services

• The purpose of this EJB is to first perform checks in the main database and then transfer calls to other modules.

• Only this EJB has access to the database for a more secure connection.
• This EJB will queue messages until the modules to send are free to accept
• This EJB will manage all processes in the DB.
• This EJB will determine where to send messages