J2EE Platform Overview
- Oct 5, 2001
A Brief Perspective
J2EE Patterns and J2EE Platform
This chapter presents a high level overview of the Java™ 2 Platform, Enterprise Edition (J2EE) and its technologies. If you already understand the J2EE platform and its technologies and APIs, you may wish to skip this chapter.
Read on if you wish to refresh your memory on J2EE.
A Brief Perspective
From its introduction to the world in 1994 to current day, the Java™ programming language has revolutionized the software industry. Java has been used in a myriad of ways to implement various types of systems. As Java started becoming more and more ubiquitous, spreading from browsers to phones to all kinds of devices, we saw it gradually hone in on one particular area and establish its strength and value proposition: That area is the use of Java on servers. Over time, Java has become the chosen platform for programming servers.
Java provides its Write Once Run Anywhere™ advantage to IT organizations, application developers, and product vendors. IT organizations leverage the benefits of vendor independence and portability of their applications. The increasing availability of skilled Java programmers promoted Java's adoption in the industry. Unbelievably, the number of Java programmers has rocketed to 2.5 million developers in only five years.
The simplicity of the language and the explosive growth of its use on the Internet and the intranet urged numerous developers and IT organizations to embrace Java as the de facto programming language for their projects.
The client-server application architecture, a two-tier architecture, over time evolved to a multitier architecture. This natural progression occurred as additional tiers were introduced between the end-user clients and backend systems. Although a multitier architecture brings greater flexibility in design, it also increases the complexity for building, testing, deploying, administering, and maintaining application components. The J2EE platform is designed to support a multitier architecture, and thus it reduces this complexity.
During this time, corporate Internet usage changed. Corporations transitioned from providing a simple corporate Web site to exposing some of their not-so-critical applications to the external world. In this first phase of Internet experimentation, IT managers were still skeptical and the security police were adamantly unfriendly to the idea of using the Internet to run and expose business services.
Before long, more and more companies started to embrace the power of the Internet. For example, customer service organizations began to provide service on the Web, in addition to the traditional methods of supporting customers by phone and email. Such organizations recognized the major cost implications of providing online service. Customers could now help themselves for most problems, and call a customer service agent only for more serious issues.
Customers liked using the Web too, as it improved their productivity. Soon, customers started expecting more and more online services from companies, and companies had to step up and provide these services. If they did not, someone else would.
Since then, almost everything has gone online—banking, bill payment, travel, ticketing, auctioning, car buying services, mortgages and loans, pharmacies, and even pet food! New companies were created that had no business model (now we know) other than opening shop online. They thrived and they thrashed. Established companies had to make their online presence felt to face the challenges of these new kids on the block. This tremendous growth fueled the need for a robust, enterprise class, Web-centric application infrastructure.
Application Servers—The New Breed
As the acceptance and adoption of Java on the server side became more established, and the demand for Web-centric application infrastructure rose, we saw an emergence of a new breed of infrastructure applications—application servers. Application servers provided the basic infrastructure required for developing and deploying multitiered enterprise applications.
These application servers had numerous benefits. One important benefit was that IT organizations no longer needed to develop their proprietary infrastructure to support their applications. Instead, they could now rely on the application server vendor to provide the infrastructure. This not only reduced the cost of their applications, but also reduced the time-to-market.
Each application server had its own benefits and disadvantages. Because there were no standards for application servers, no two application servers were completely alike. Some application servers were based on Java, and these allowed you to write only Java components to run on that server, while others used different languages for development.
Convergence of Java Technologies
In the area of Web applications, there were significant developments in Java as well. The Common Gateway Interface (CGI) approach for developing Web-centric applications was resource-intensive and did not scale well. With the introduction of servlet technology, Java developers had an elegant and efficient mechanism to write Web-centric applications that generated dynamic content. However, writing servlets still took some effort and Java expertise.
The standard approach for database access in Java applications is Java Database Connectivity (JDBC). The JDBC API (application programming interface) gives programmers the ability to make their Java applications independent of the database vendor. One can write a JDBC application that accesses a database using standard Structured Query Language (SQL). If the underlying database changes from one vendor's product to another, the JDBC application works without any code change, provided that the code is properly written and does not use any proprietary extensions from the first vendor. JDBC API is offered as part of the core APIs in the JavaTM 2 Platform, Standard Edition (J2SETM).
J2SE (formerly known as Java Development Kit or JDK) is the foundation for all Java APIs. J2SE consists of a set of core APIs that define the Java programming language interfaces and libraries. Java developers use the J2SE as the primary API for developing Java applications. As requirements expand and the Java language matures over the years, the J2SE offers additional APIs as standard extensions.
As Java established its permanent role on the server side, and the adoption of various Java APIs became widespread, Sun put together an initiative to unify standards for various Java technologies into a single platform. The initiative to develop standards for enterprise Java APIs was formed under the open Java Community Process (JCP). Enterprise Java APIs are a collection of various APIs that provide vendor-independent programming interfaces to access various types of systems and services. The enterprise Java APIs emerged as the JavaTM 2 Platform, Enterprise Edition (J2EE™).
The Rise of the J2EE Platform
The Enterprise Java Beans™ (EJB™) technology is one of the prominent, promising technologies in the J2EE platform. The EJB architecture provides a standard for developing reusable Java server components that run in an application server. The EJB specification and APIs provide a vendor-independent programming interface for application servers. EJB components, called enterprise beans, provide for persistence, business processing, transaction processing, and distributed processing capabilities for enterprise applications. In short, the EJB technology offers portability of business components.
Various application vendors, having come together with Sun under the open JCP to develop this standard, adopted and implemented the EJB specification into their application server products. Similar to JDBC application portability, EJB applications are portable from one application server vendor to another. Again, this is true if the application does not use any vendor-dependent feature of the application server. J2EE technologies are now a proven and established platform for distributed computing for the enterprise.
Java Message Service (JMS) is another standard API in the J2EE platform. It brings the same kind of standardization to messaging as JDBC brought for databases. JMS provides a standard Java API for using message-oriented middleware (MOM) for point-to-point and publish/subscribe types of enterprise messaging. As with the other technologies, JMS brings vendor independence in the MOM products for Java.
In each of these areas, Sun and other companies collaborated in coming up with an acceptable standard under the auspices of the open JCP. The JCP coordinated the activities to develop these standards. This cooperation is a foundation for the success of these APIs.
J2EE Value Proposition
The J2EE platform, built on the Java programming language and Java technologies, is the application architecture that is best suited for an enterprise-distributed environment. The J2EE platform is a standard that brings the following benefits to IT organizations, application developers, and product vendors:
Vendors develop products that can run on any system that supports the J2EE platform. With virtually no extra effort, their products are available on a wide range of system platforms.
Corporate IT developers benefit from the advantages of portable component technology. IT applications become vendor-independent and release the IT organizations from the clutches of vendor lock-in.
IT developers can focus on supporting business process requirements rather than building in-house application infrastructure. The application servers handle the complex issues of multithreading, synchronization, transactions, resource allocation, and life-cycle management.
IT organizations can take advantage of the best available products built on a standard platform. They can choose among products and select the most suitable and cost-effective development products, deployment products, and deployment platforms based on their requirements.
Adopting the J2EE platform results in a significant productivity increase. Java developers can quickly learn the J2EE APIs.
Companies protect their investment by adopting the J2EE platform, since it is an industry-supported standard and not a vendor-defined lock-in architecture.
Development teams can build new applications and systems more rapidly. This decreases time-to-market and reduces the cost of development.
A standard development platform for distributed computing ensures that robust applications are built on a proven platform.
The J2EE platform provides a clear, logical, and physical partitioning of applications into various tiers, thus naturally addressing multitiered application requirements.
Developers can either build their own J2EE component or procure it from the rapidly growing third-party components market. Vendors are able to offer their components individually, and customers are able to buy these software parts as needed.