The architecture of the Java EJB and how it achieves distributed system features.
What are distributed systems?
Computing systems started as centralized systems and evolved toward distributed systems. In centralized systems, processing/computation is done on a single powerful server machine. Clients are connecting to the central server machine to get certain tasks processed. Distributed systems have evolved from simple client-server architecture-based applications running on LANs (Local Area Networks) to complex systems involving a huge number of machines across WANs (Wide Area Networks).
Definition:
“A distributed system consists of a collection of autonomous computers, connected through a network and distribution middleware, which enables computers to coordinate their activities and to share the resources of the system so that users perceive the system as a single, integrated computing facility.” [1]
When we talk about the distributed systems there are several common characteristics that the system would need to fulfil.
· Resource sharing — the system should be able to share its resources (hardware, software, data) throughout the system.
· Openness — this is mainly considered about the improvements and the extensions of the system. How the components and the data should be represented and published.
· Concurrency — components should be executed in a concurrent process.
· Scalability — The ability of the system to handle more users and faster response without changing its initial structure or components.
· Fault tolerance — the system should be able to maintain availability even in a low level of hardware, software, and network reliability by using recovery and redundancy techniques.
· Transparency — this was defined using several dimensions. Even though the location of the service is not known by the user or developer transfer of the service should be transparent to them.
What is EJB and its Infrastructure?
According to the documentation of the Oracle, they define the EJB as follows,
“Enterprise JavaBeans is an architecture for transactional, component-based distributed computing. The specification for EJBs lays out not just the format of a bean itself, but also a set of services that must be provided by the container in which the bean runs. This makes EJBs a powerful development methodology for distributed application development. Neither the bean developer nor the client application programmer needs to be concerned with service details such as transaction support, security, remote object access, and many other complicated and error-prone issues. The EJB server and container furnishes these features for you.” [2]
To get a clear idea about this definition I would like to map this definition with the architecture of the EJB.
When it comes to the architecture of the EJB we can see that they follow a three their architecture in their system. According to IBM,
“Three-tier architecture is a well-established software application architecture that organizes applications into three logical and physical computing tiers: the presentation tier, or user interface; the application tier, where data is processed; and the data tier, where the data associated with the application is stored and managed.” [3]
In the above architecture,
· Applet container, application client container, web container works as the presentation layer.
· EJB container works as the application tire (business logic).
· Database as the data tire.
Sometimes it can be introduced as four-tire layered architecture by adding the persistence layer between the business logic layer and the database layer.
To sum up, now we have gone through the distributed systems and their characteristics, EJB and its infrastructure. In this next section, I would build up my analysis with the help of the area that we covered as the background of the context.
How EJB accomplish the properties of the distributed systems.
1. Resource sharing
In the architectural diagram, we can see there is various kind of services that are provided by the EJB. Even though these services are supplied if the system doesn’t have a clear method to share these resources throughout the system its main disadvantage to develop a distributed application.
In the EJB the resource sharing happens mainly in two ways. Those are,
· Dependency Injection
· JNDI lookup
With the usage of these two mechanisms, EJB can deliver resources anywhere in the application. Here I’m not going to analyze these techniques because it would be additional content. With the help of JNDI, this process makes it easy for the developer because to use the resource they only need to know about the name of the JNDI resource.
2. Openness
When it comes to openness according to the architecture of the EJB it provides a layered architecture that will help to decouple the connection between the layers so the developers can modify or develop a layer without affecting too much for the other layers.
Even in the data sharing as mentioned in the services java RMI and web services make it possible for the developers to even remove the entire presentation layer from the application and redesign it even if they want without affecting the rest of the application.
Normally developers tend to go react, react-native based presentation layer and a java EJB for backend because of this facility.
3. Concurrency
Even though there are many services included in the EJB for the developers each service has a dedicated location to be placed in the server. Moreover, these services will work and execute concurrently using multi-threading and other server-side techniques. Especially when it comes to the EJB, containers provide, object initiation using container-managed thread pools which allows it to use the EJB platform services. [4]
However, if the developer wants a separate thread created by own, this process is highly discouraged. Because it can affect the server performance and sometimes those threads wouldn’t be able to access platform services as well.
4. Scalability
Java EJB application server platform vendors supply all the necessary tools for platform scalability. Here the main concept is clustering. Clustering applications will give the load balancing ability for the application while adding resources.
The other term that needs to be considered with scalability is throughput. The research done in this area shows that it can vary from the total processing power (TPP) of the system but if we consider a normalized middle tire TPP it would give a linear relationship with the throughput. In summary, while scaling the application if we can keep up the processing power at an average level, the application server platform will help to keep the maximum throughput up to the level it can provide while providing its services. [5]
With the EJB infrastructure, Tire architecture will guarantee the scalability of each layer most probably the scalability of the business logic layer and the data layer with the above-mentioned clustering techniques and load balancing it provides.
Even though here I haven’t discussed the bean types, in general, there are different techniques for balancing those beans (stateful, stateless) because of their behaviours. And I would like to discuss that part in the fault tolerance.
When it comes to the data tire scalability persistence layer and techniques like distributed cache synchronization is used to provide the scalability of the data tire.
5. Fault tolerance
With the clustering provided by the server platform vendors that they maintain the availability of the application while simplifying the configurations of the clustering. Furthermore, it can be discussed with stateless and stateful sessions and how clustering effects for each bean and from that how these support for the availability of the application.
Stateless session bean
When it comes to the stateless it won’t give much trouble because these session beans don’t keep up the state according to the user. Because of that user can be directed to any stateless bean clustered by the server to complete its tasks
Stateful session beans
Clustering stateful session beans can be a little resource extensive. Because it needs expensive serialization, propagation of the serialization and deserialization of the state. It’s all because a stateful session maintains a conversation state between the client and the server.
For this there are several mechanisms are used. Such as IP multicasting peers and peer-to-peer.
With all these techniques java EJB accomplishes fault tolerance.
6. Transparency
In the EJB architecture, one of the most valuable support it provides for the developers is the transparency of its services and resource calling transparency. Developers no need to take care of the TCP/IP sockets by handling those sockets manually. With Java RMI (Remote Method Invocation) developers can invoke remote methods without caring about its underlying plumbing. It’s like invoking the remote method as if the remote method is located in the same virtual machine.
Here JNDI works like a root node where any stub can access any service through it by only using the service registered JNDI name.
Up to now, I have shown you the basic needs of a distributed server and how Java EJB accomplish each with its infrastructure and services like JNDI, etc.
References
[1]W. Emmerich. [Online]. Available: http://www0.cs.ucl.ac.uk/staff/w.emmerich/lectures/ds98-99/dsee3.pdf .
[2]“Enterprise JavaBeans,” [Online]. Available: //https://docs.oracle.com/cd/A81042_01/DOC/java.816/a81356/ejb.htm.
[3]I. C. Education, “Three-Tier Architecture,” [Online]. Available: https://www.ibm.com/cloud/learn/three-tier-architecture.
[4]“Container Types,” [Online]. Available: https://docs.oracle.com/cd/E19316-01/819-3669/6n5sg7as0/index.html.
[5][Online]. Available: http://J2EE_infrastructure_scalability_and_throughput_est.pdf.
