What's the Buzz Behind EJB?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Welcome to the premiere article in the Java Solutions series! In this series, I'll discuss Java enterprise technologies specified in the Java 2 Enterprise Edition (J2EE): Enterprise JavaBeans (EJB), Servlets, JavaServer Pages (JSP), Java Transaction API (JTA), Java Messaging Service (JMS), and Java Database Connectivity (JDBC).
In the industry today, all of the hype is revolving around EJB; just survey a couple of the online job sites, search on Java, and count the number of six-figure salaries that companies are willing to offer for a little EJB experience. The hype is there, but why? What is EJB? Why are so many companies looking for EJB developers? How does EJB fit into the enterprise Web domain?
This article hopes to answer these questions and more. Throughout this series, I'll show you how to develop Enterprise JavaBeans of all flavors, how to use Enterprise JavaBeans effectively with other J2EE technologies, and how to architect your enterprise and enterprise Web solutions. But before we jump in, I want to talk about the buzz behind EJB, what it means to you, and how it meets the requirements of the dynamic Web-based world we're living in!
History
Applications have evolved over the past few decades, but none greater than in the last 5–10 years. In the beginning, applications were complete entities, sometimes including an operating system, but most probably managing data storage.
Because of the repetitious task of storing and retrieving data, and the complexity involved in transaction management and synchronization, database vendors evolved that provided an application-independent interface to an application's data. Applications started using databases, which solved the data storage issue, but soon applications grew complicated and nearly impossible to manage. As a result, developers started approaching software development from a different perspective: distributing the application across multiple processes that were responsible for a certain part of the application's business logic.
The advent of distributed programming was followed shortly by the birth of distributed component models. A distributed component model can be as simple as defining a mechanism for one component to locate and use the services of another component (sometimes referred to as an Object Request Broker or ORB) or as complicated as managing transactions, distributed objects, concurrency, security, persistence, and resource management (sometimes referred to as Component Transaction Monitors or CTMs.) Figure 1 shows the three-tier architecture that CTMs provide.
){kind=link}
Application servers.
CTMs are by far the most complicated of these component models; because they manage not only components but also database transactions, resources, and so on, they're referred to as application servers. The Enterprise JavaBeans technology is Sun's answer to an application server.
With the prevalence of the Internet, distributed technologies have added another tier to enterprise applications, as shown in Figure 2. In this case, Web browsers are thin clients that talk to Web servers (that in turn may be clustered.) Web servers communicate with the "middleware" layer (CTM) that in turn communicates with one or more databases.
){kind=link}
Application servers used in a Web environment.