Java Programming, Lecture Notes # 1306
October 16, 2000
This lesson, along with the previous lesson entitled Enterprise JavaBeans(TM), Java 2 Platform, Enterprise Edition (J2EE), Part 1, and the next lesson, together constitute a three-part miniseries designed to provide background information, and to explain where EJB fits in the grand scheme of things at Sun.
Subsequent lessons will show you how to write, deploy, and execute Enterprise JavaBeans(TM).
I will begin this lesson with a clarification of the difference between JavaBean Components(TM) and Enterprise JavaBeans(TM).
After defining enterprise beans, I will go into a discussion of the Java 2 Platform, Enterprise Edition (often referred to simply as J2EE).
I will discuss multi-tier systems, fat clients, and thin clients. I will provide some examples of why multi-tier systems with thin clients may be preferable to the use of two-tier systems with fat clients.
I will provide a preview of the J2EE Reference Implementation, which will be used extensively in many subsequent lessons.
I will discuss the need for standardization in multi-tier systems, and described Sun's approach to the needed standardization.
A clarification
Because of the likelihood of confusion regarding the use of the term beans, I will begin by telling you that an enterprise bean is not a JavaBean Component(TM), as discussed in my series of tutorial lessons beginning with lesson number 500.
What is an EJB?
Enterprise JavaBeans(TM) consist of reusable compiled code that is designed to be installed inside a special application server that is compliant with Sun's Java 2 Platform Enterprise Edition.
Use of Bean in this lesson
As mentioned above, Enterprise JavaBeans(TM) are not the same thing as JavaBean Components(TM). In this lesson, when I refer to beans, I will be referring to Enterprise JavaBeans(TM).
Why use J2EE?
One of the main goals of J2EE is to allow the enterprise software developer to reduce development cost and reduce time-to-market response time.
Multi-tier systems
In today's world, systems for delivering large-scale data processing services are often built as distributed systems consisting of several tiers or layers. Such systems usually include a client tier, a back-end data storage tier, and one or more tiers in the middle to implement business logic and processes.
Reducing cost and complexity of development
J2EE is designed specifically to accommodate the need to productively develop and upgrade the software in the middle tier of a multi-tier system.
The design is intended to reduce the cost and complexity of developing and upgrading multi-tier capability. The intent is to make it possible to quickly deploy and enhance such capability in response to competitive pressures.
What specifically is J2EE?
According to Sun, J2EE defines a standard architecture that is delivered as the following elements:
This set of lessons on Enterprise JavaBeans(TM) will make very heavy use of the APIs as well as the J2EE Reference Implementation.
What is the J2EE Reference Implementation?
The J2EE Reference Implementation is actually a downloadable server that you can use for testing your beans and other components such as servlets and Java Server Pages (JSP). It also supports database access via JDBC.
At some point along the way, these tutorial lessons may also make use of the Sun Blueprints Design Guidelines for J2EE.
Historical perspective
Two forces came together during the 90s that led to the need for systems such as J2EE.
Enterprise business on the web
One of these forces was widespread use of the Internet for business. As business developed on the Internet, it quickly became apparent that there was a need for thin clients (client systems that serve primarily as a communication mechanism between the human client and the enterprise).
Bursting the fat client bubble
Although it may have been believed early in the history of the Web that browser plugins and Java applets would be widely accepted for use as fat clients (client programs with lots of data processing capability and responsibility), in reality, this wasn't a very acceptable approach for a variety of reasons. This led to the need for systems that work well using thin clients.
The second force
The second force that emerged during the 90s was a movement away from the earlier client-server implementation (based on fat clients) to a multi-tier implementation using thin clients.
How does a fat client work?
In the traditional client-server implementation, fat clients with lots of processing capability interacted more or less directly with the back-end persistent database. This model experienced lots of problems, and led to a shift to a multi-tier model.
How does a multi-tier system work?
In the three-tier (or multi-tier) model, a thin client communicates with a middle tier, which provides a data processing bridge between the thin client and back-end persistent data storage.
The multi-tier approach is much more flexible. It is also safer, and easier to maintain than the earlier client-server approach involving fat clients.
Replacing the back-end database
For example, with the three-tier approach, the entire back-end database can be completely replaced with one of a new design so long as the software in the middle tier can accommodate the new database on one hand, and can continue to present the same interface to the thin client on the other hand. No changes would be required in the client software.
If this were attempted in a fat-client system where the clients interact directly with the back-end database, it might be necessary to upgrade the software in every client system. In today's world, this could easily involve thousands of client systems.
What does Sun have to say?
According to Sun, "The new models separated business logic from both system services and the user interface, placing it in a middle tier between the two."
The adoption of this new architecture was also strongly encouraged during the 90s by the development of new middleware services such as transaction monitors, message-oriented middleware, and object request brokers.
Multi-tier architecture makes development simpler
Early entries into the multi-tier arena made life simpler and more productive for the software developer, but they lacked standardization. Even without standardization, however, the use of a multi-tier design makes it easier to design, develop, deploy, and maintain large-scale enterprise applications than the earlier two-tier client-server systems.
Developers can specialize
By separating the application into well-defined layers, different developers can concentrate on what they do best. Then the results of those relatively independent efforts can be integrated into an operational system.
Concentrate on business logic
For example, once such a system is established, and application developers understand how to interface with it, they can concentrate on programming business logic without the requirement to deal (to any great extent) with the specifics of the back-end data storage infrastructure, or the specifics of the front-end client interface. This makes it possible for such developers to be more productive, and for such development to be more responsive and less costly.
The good news is ...
Once the software that implements the appropriate business logic has been developed, it can be deployed on different servers that are compatible with the software.
The bad news is ...
Software developed for one brand and model of multi-tier server may not be compatible with another brand and model from another vendor. Thus, without standardization, the enterprise becomes a captive customer of a particular multi-tier server vendor.
Sun says...
"despite these clear benefits, the model limits developers' ability to build applications from standardized components, to deploy a single application on a wide variety of platforms, or to readily scale applications to meet changing business conditions."
The need for standardization
Sun has recognized and responded to the need for standardization with J2EE.
For example, Enterprise JavaBeans(TM) that you develop to implement your business logic can be deployed on any server that is fully compliant with the J2EE specifications, regardless of the vendor, the brand, or the model of the server.
EJBs implement business logic
Your bean becomes a reusable software component that implements a specific set of business logic. Over time, you can combine that bean with other beans to build larger overall systems.
Beans for sale
You might find it attractive to sell the right to use your beans to someone else. You might also find it attractive to purchase the right to use beans developed by others rather than to develop your own.
Servlets, JDBC, and JSP
With standardization, Java servlets that you develop for use on one server can also be deployed on any server that meets the compatibility specifications.
The JDBC technology makes it possible for you to choose from among many different brands and model numbers of back-end persistent database products.
The JSP technology makes it possible for you to create "smart" web pages to support an increasingly sophisticated marketplace on the Web.
According to Sun, "The convergence of these three concepts -- server-side behaviors written in the Java language, connectors to enable access to existing enterprise systems, and modular, easy to deploy components -- led us and our industry partners to the J2EE standard."
So, once again, what is J2EE?
According to Sun, "J2EE is designed to support applications that implement enterprise services for customers, employees, suppliers, partners, and others who make demands on or contributions to the enterprise. Such applications are inherently complex, potentially accessing data from a variety of sources and distributing applications to a variety of clients."
J2EE is broader than EJB
Although the lessons in this series will concentrate mainly on Enterprise JavaBeans(TM), J2EE is much broader than just EJB. J2EE combines several components of enterprise data processing, only one of which is EJB.
Sun's J2EE Application Model
Sun's J2EE model is one in which the middle tier provides the business functions that support the various users. A dedicated server is often used to house the middle tier. This server has access to all of the necessary services of the enterprise, including persistent back-end data storage and the front-end client interface.
Now back to the need for standardization
Multi-tier server products have been available for some time. However, because each product had its own application model, it has been difficult to hire and train the necessary development staff because these developers were required to specialize on specific brands of multi-tier server products.
In addition, when it has been necessary to upgrade a multi-tier server for greater capacity, more services, or for other reasons, it has often been necessary to port the existing application to a different brand and model of multi-tier server.
Because the new server may use a different model, such porting operations have been costly, dangerous, and sometimes simply not feasible.
J2EE provides the needed standardization
By providing a standardized model, J2EE makes it possible to avoid these problems and to deliver the scalability, accessibility, and manageability that are needed in a dynamic enterprise business environment.
Separating the required efforts
According to sun, the J2EE model partitions the effort needed to implement a multi-tier system into two parts:
The easier part, involving the development of business and presentation logic, can be done in-house, or subcontracted out to others with EJB experience.
I talked a little about multi-tier systems, fat clients, and thin clients. I gave some examples of why multi-tier systems with thin clients may be preferable to the use of two-tier systems with fat clients.
I gave a preview of the J2EE Reference Implementation, which will be used extensively in many subsequent lessons.
I discussed the need for standardization in multi-tier systems, and described Sun's approach to the needed standardization.
Then I will continue with more background information in preparation for our encounter with Enterprise JavaBeans(TM).
Copyright 2000, Richard G. Baldwin. Reproduction in whole or in part in any form or medium without express written permission from Richard Baldwin is prohibited.
Richard has participated in numerous consulting projects involving Java, XML, or a combination of the two. He frequently provides onsite Java and/or XML training at the high-tech companies located in and around Austin, Texas. He is the author of Baldwin's Java Programming Tutorials, which has gained a worldwide following among experienced and aspiring Java programmers. He has also published articles on Java Programming in Java Pro magazine.
Richard holds an MSEE degree from Southern Methodist University and has many years of experience in the application of computer technology to real-world problems.
-end-