Java Programming, Lecture Notes # 1307
October 30, 2000
This lesson, along with Part 1 and Part 2, 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).
In this lesson, I will continue the discussion of the Java 2 Platform Enterprise Edition (J2EE), and will further justify the need for standardization in multi-tier systems.
I will introduce the need for standard services by providing a very simple example involving your saving account and your checking account. Hopefully, those two accounts are protected by a standard service commonly referred to as transaction processing.
I will discuss the fact that with multi-tier systems, it is not necessary for the application programmer to be an expert in the programming of standard services. Rather, the responsibility for programming such services is shifted to the programmers who do this sort of thing on a daily basis in the development of multi-tier server products.
I will introduce the topic of deployment, which is a topic that will consume a lot of time, effort, and discussion in future lessons.
Many of the future lessons that provide workable code will make use of the J2EE Reference Implementation for a variety of reasons, not the least of which is the fact that it is available free of charge for academic research and other non-commercial use.
A clarification
Because of the likelihood of confusion regarding the use of the term beans, I will begin by telling you that an EJB 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 the Java 2 Platform Enterprise Edition.
Use of Bean in this lesson
In this lesson, when I refer to beans, I will be referring to Enterprise JavaBeans(TM).
J2EE is a high-productivity, multi-tier system
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.
Systems for delivering large-scale data processing services often include a thin-client tier, a back-end data storage tier, and one or more tiers in the middle to implement business logic and processes.
J2EE is designed specifically to accommodate the need to productively develop and upgrade the software in the middle tier of a multi-tier system.
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 need for standardization
Standardization makes it possible to build applications from standardized components and to deploy a single application on a wide variety of platforms. Standardization also makes it possible to readily scale applications to meet changing business conditions.
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 server vendor.
Your bank account and transaction processing
Consider a simple example. You decide to transfer $10,000 from your savings account into your checking account. How happy would you be if there was a computer failure at the bank after the funds had been removed from the database that represents your savings account and before they had been posted into the database that represents your savings account?
You probably wouldn't be very happy!
Transaction processing
This scenario falls in a programming technology area commonly referred to as transaction processing. Transaction processing is only one several essential services provided by a J2EE platform-compliant server.
Transaction expertise required
The bottom line is, neither operation in the above example should be allowed unless both operations are successful. The ability to write programs that reliably perform such transactions is not something that a programmer learns overnight. The programmers who write and test the code for such transactions typically require quite a lot of specialized experience.
Business logic is easier
On the other hand, the code to extract $10,000 from one database and add a like amount to another database isn't very complicated. This is what is commonly referred to as business logic.
Separation of responsibility
J2EE makes it possible to separate the code required to perform business logic from the code required to implement the required infrastructure such as transaction processing.
Do what you do best
The development of business logic can be assigned to programmers who understand the business and who know how to program in Java. Although they must know how to interface their code with the infrastructure provided by the J2EE server, they don't have to know how to reliably implement such infrastructure.
Infrastructure programmers needed
The development of the required infrastructure of services is assigned to the programmers who develop the application server product. They, in turn, don't need to understand the business for which the server will be used. Their requirement is that the server that they develop will comply with the specifications of J2EE, however they choose to implement it.
Write once, run anywhere
According to Sun, "The J2EE application model provides the benefits of Write Once, Run Anywhere portability and scalability for multi-tier applications. This standard model minimizes the cost of developer training while providing the enterprise with a broad choice of J2EE servers and development tools."
Also, according to Sun, "The J2EE application model is a major step forward in simplifying and expediting application development, by minimizing the complexity of building multi-tier applications."
The client tier
J2EE is designed to support different implementations of client software including web browsers, applets, applications, RMI objects, CORBA objects, etc.
Because the primary thrust of this series of lessons is to teach you how to write beans that properly interface with a J2EE platform-compliant server, most of the early lessons in this series will use relatively simple Java applications to implement the client tier.
Later in the series, I may illustrate some of the other approaches to implementing the client tier as well.
Shifting responsibility
One of the goals of J2EE is to minimize the requirements and difficulty of application programming. One way to accomplish this is to shift as many common tasks as possible to the infrastructure services provided by the server. Such common tasks might include:
J2EE provides a mechanism for separating these behaviors from component code. Declarations specifying these behaviors are stored in a deployment descriptor, which is an XML document. The XML document is stored in a jar file along with all of the component parts of the application.
According to Sun, "A J2EE application is packaged into one or more standard units for deployment to any J2EE platform-compliant system. Each unit contains a functional component or components (enterprise beans, JSP page, servlet, applet, etc.), a standard deployment descriptor that describes its content, and the J2EE declarations which have been specified by the application developer and assembler."
Deployment
Servers that meet the J2EE compatibility specifications provide software tools that are used to deploy the application. These deployment tools know how to read the deployment descriptor and how to modify the behavior of the application accordingly without any requirement to modify the class files that constitute the components of the application.
The deployment tools can also be used to specify location-specific information such as a list of local users that can access it, or the name of a local database.
Vendor specific deployment tool
The deployment information provided by the component developer should be the same regardless of the server vendor. However, the manner in which the deployment tool is implemented, as well as its user interface, will likely vary from one vendor to the next.
Most of the lessons in this series will be illustrated using the deployment tool that can be downloaded from Sun in its reference implementation of J2EE.
J2EE Reference Implementation
The reference implementation is a J2EE platform-compliant server that can be downloaded from Sun to fulfill several roles.
According to Sun, "Its primary role is as an
operational
definition of the J2EE platform. In this role,
it is used by vendors as the J2EE platform's "gold standard" to determine
what their implementation must do under a particular set of application
circumstances. It is also used by developers to verify the portability
of an application. Most importantly, it is used as the standard platform
for running the J2EE Compatibility Test Suite."
The role for this series of lessons
In this series of lessons, the J2EE Reference Implementation will be used as a J2EE platform-compliant server that is available free of charge. It can be used to test and illustrate the variety of programming opportunities provided by the use of Enterprise JavaBeans(TM).
Sun describes this role as follows: "A secondary, but more visible, role for the reference implementation is as a freely available platform for popularizing Java 2 platform, Enterprise Edition. Although it is not a commercial product and its licensing terms will prohibit its commercial use, it will be freely available in binary form for demonstrations, prototyping and academic research."
A word of gratitude
As a college professor, teaching at a publicly supported college, whose academic software budget must survive the whims of the government bureaucracy, I am particularly pleased that Sun has made this reference implementation available. This will make it possible for me to teach EJB to my students, and possibly to you as well. This would not be possible if it were necessary for me to pay the price of a full-scale EJB-compliant application server from one of the major vendors.
A plug for another vendor
I also want to mention the Unify eWave product. This is another EJB compliant product that is also available for restricted use at no cost, I will probably also make use of the eWave product for deploying and testing some of the beans that I develop for teaching purposes.
I gave a very simple example involving your saving account and your checking account as an example of the need for transaction processing. I mentioned that enterprise applications require a variety of standard services, of which transaction processing is only one.
I discussed the fact that with multi-tier systems, it is not necessary for the application programmer to be an expert in the programming of standard services, such as transaction processing. Rather, the responsibility for programming standard services is shifted to the experts who do this sort of thing on a daily basis in the development of multi-tier server products.
The standardization of multi-tier systems provided by Sun's J2EE extends the benefits of Write Once, Run Anywhere to multi-tier enterprise applications, making it possible for application programmers to develop software for a variety of brands and models of multi-tier servers without having to learn the peculiarities of each.
I introduced the topic of deployment, which is a topic that will consume a lot of time, effort, and discussion in future lessons.
I explained that many of the future lessons that provide workable code will make use of the J2EE Reference Implementation for a variety of reasons, not the least of which is the fact that it is available free of charge for academic research and other non-commercial use.
The next lesson will become more specific with the discussion centered
on 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-