Enterprise Java and Rational Rose -- Part I - J2EE: Responding to Enterprise Application Needs
(Page 2 of 6 )
Enterprise applications have grown more complex over the past several years, reflecting evolutionary changes in software technology. Let's start off by looking at some common characteristics of these applications:
- Enterprise applications are often mission critical, meaning they have a direct impact on the bottom line. Think about businesses like EBay or Etrade: their Web site IS their business!
- Enterprise applications are often distributed; they are deployed either on multiple machines in the same general area or on geographically separated machines. These days, the typical distribution vehicle is an intranet or the Internet.
- Enterprise applications typically require the ability to handle a large number of users (or flexibility to expand quickly should the need arise).
- Enterprise applications require certain services, such as security (to prevent unauthorized access) and complex transaction processing (an Internet bank would require both withdrawal and deposit transactions to complete a fund transfer transaction, for example), as well as database access.
- Enterprise applications often have a large user base. System administrators should be able to upgrade, maintain, and redeploy the application with minimal effort.
These are exactly the kinds of challenges J2EE is designed to address. Every new technology is created in response to certain needs, and J2EE is no exception. Essentially, it is a unified release of various Java specifications developed and popularized by Sun over the last few years. The J2EE specification focuses on two basic categories: technology and API specifications.
The technologies within J2EE address server-side development needs. These include:
- Enterprise JavaBeans, which are used for building components that live on the server.
- Java Servlets, which provide the means for interactions with Web clients.
- JavaServer Pages, which allow developers to create dynamic content for thin clients.
The primary purpose of the J2EE APIs is to enable developers to write J2EE applications in a vendor independent, portable fashion. The following J2EE APIs are available:
- J2EE connector -- to link an enterprise application to one or many EISs (Enterprise Information Systems).
- JDBC Standard Extension -- to link an application to a relational database.
- Java Message Service (JMS) -- to bring the power of messaging to an application.
- Java Transaction API (JTA) -- for transactional enterprise applications.
- JavaMail -- to bring a mail mechanism to enterprise applications.
- JavaBeans Activation Framework (JAF) -- to be used within JavaMail.
- Java™ API for XML Parsing (JAXP) -- for any XML-based enterprise application.
- Java Authentication and Authorization Service (JAAS) -- to bring a security layer to enterprise applications.
What really makes the J2EE packaging work are the new things Sun Microsystems has added:
- An Application Model. This development guide helps you understand how to use the various pieces of J2EE.
- A standard platform for enterprise application development.
- A compatibility test suite. Vendors of J2EE products use this suite to test their products for J2EE compliance.
- A reference implementation. This is an implementation of the platform described above. It gives you an operational perspective of J2EE: something you can actually run and see in action. It's great for hands-on learning about J2EE, demonstrating J2EE capabilities, and so on.
Simply put, J2EE makes it easier for mere mortals to write some very complex software. Essentially, you don't need to be an expert in distribution issues, scalability issues, and all the nuances of security. That is all built into the specification. Vendors of J2EE runtime environments provide the underlying technology for you to use out of the box. To a large degree, you can mix and match tools, vendors, and technologies. That means you are not hostage to a single vendor. Plus, you can leverage existing investments instead of starting from scratch when you make an infrastructure change.
Another advantage of J2EE is that it decouples application development from deployment and execution. You can defer the details of deployment to the Deployer, a new role defined by the J2EE specification. The deployer specializes in, and is responsible for, deploying J2EE software to specific servers. Separating this function allows the developer, or Application Component Provider, as J2EE refers to the role, to create a generic application. The deployer is then free to customize the application for the target execution environment, in accordance with what database will be used, who is allowed to access the application, etc.
Finally, using J2EE makes it easier for a developer to build, maintain, and update an enterprise application. It allows you to use third party or Common Off The Shelf (COTS) components in your application. If something changes, then you can modify just that specific component rather than the whole application, and so on. To do the work of putting together components from different sources, J2EE defines another new role: an Application Assembler. Figure 1 shows the relationship among the different roles that J2EE specifies.
In a nutshell, J2EE brings together the pieces and players required for building scalable, distributed systems, and provides a comprehensive platform for building enterprise applications in Java.
Next: More J2EE >>
More Development Cycles Articles
More By The Rational Edge
