Home arrow Java arrow J2EE Essentials
JAVA

J2EE Essentials


This article provides a high-level introduction to J2EE. It is taken from chapter one of the book Beginning J2EE 1.4 From Novice to Professional, written by James L. Weaver, Kevin Mukhar, and Jim Crume (Apress, 2004; ISBN: 1590593413).

Author Info:
By: Apress Publishing
Rating: 5 stars5 stars5 stars5 stars5 stars / 12
September 29, 2005
TABLE OF CONTENTS:
  1. · J2EE Essentials
  2. · Multi-Tier Architecture
  3. · Vendor Independence
  4. · Java Servlets
  5. · Enterprise JavaBeans
  6. · Web Services
  7. · Summary

print this article
SEARCH DEVARTICLES

J2EE Essentials
(Page 1 of 7 )

The word “enterprise” has magical powers in computer programming circles. It can increase the price of a product by an order of magnitude, and double the potential salary of an experienced consultant. Your application may be free of bugs, and cleanly coded using all the latest techniques and tools, but is it enterprise ready? What exactly is the magic ingredient that makes enterprise development qualitatively different from run-of-the-mill development?

Enterprise applications solve business problems. This usually involves the safe storage, retrieval, and manipulation of business data: customer invoices, mortgage applications, flight bookings, and so on. They might have multiple user interfaces: a web interface for consumers, and a GUI application running on computers in the branch offices, for example. They have to deal with communication between remote systems, co-ordination of data in multiple stores, and ensure the system always follows the rules laid down by the business. If any part of the system crashes, the business loses part of its ability to function, and starts to lose money. If the business grows, the application needs to grow with it. All this adds up to what characterizes enterprise applications: robustness in the face of complexity.

When we set out to build a GUI application, we don’t start out by working out how to draw pixels on the screen, and build our own code to track the user’s mouse around the screen; we rely on a GUI library, like Swing, to do that for us. Similarly, when we set out to create the components of a full-scale enterprise solution, we’d be crazy to start from scratch. Enterprise programmers build their applications on top   of systems called application servers. Just as GUI toolkits provide services of use to GUI applications, application servers provide services of use to enterprise applications – things like communication facilities to talk to other computers, management of database connections,   the ability to serve web pages, and management of transactions.

Just as Java provides a uniform way to program GUI applications on any underlying operating system, nowadays Java can provide a uniform way to program enterprise applications on any underlying application server. The set of libraries developed by Sun Microsystems and the Java Community Process that represent this uniform application server API is what we call the Java 2 Platform, Enterprise Edition, and is the subject of this book.

This chapter provides a high-level introduction to J2EE, and an introduction on how to get the most benefit from this book. After reading this chapter, you will:

  • Have an understanding of the reasons why the concepts underlying J2EE are compelling and enabling technologies for large-scale applications
  • Understand how J2EE relates to J2SE
  • Be introduced to the cornerstone technologies of J2EE
  • Be introduced to some of the essential architectural patterns that J2EE facilitates

So, without further ado, let’s get started!

What Is J2EE?

Since you’re reading this book you’ve got some interest in J2EE, and probably have some notion of what you’re getting into. For many fledgling J2EE developers, J2EE equates to Enterprise JavaBeans. J2EE is a great deal more than just EJBs, though.

While perhaps an oversimplification, J2EE is a suite of specifications for application programming interfaces, a distributed computing architecture, and definitions for packaging of distributable components for deployment. It’s a collection of standardized components, containers, and services for creating and deploying distributed applications within a well-defined distributed computing architecture.

As its name pretty much spells out, Java 2 Enterprise Edition is targeted at large-scale business systems. Software that functions at that level doesn’t run on a single PC—it requires significantly more computing power and throughput than that. For that reason, the software needs to be partitioned into functional pieces and deployed on the appropriate hardware platforms to provide the necessary computing power. That is the essence of distributed computing. J2EE provides a collection of standardized components that facilitate software deployment, standard interfaces that define how the various software modules interconnect, and standard services that define how the different software modules communicate.

How J2EE Relates to J2SE

J2EE isn’t a replacement for the Java 2 Standard Edition. The J2SE provides the essential language framework that the J2EE builds upon. It is the core upon which J2EE is based. As you’ll see, J2EE consists of several layers, and J2SE is right at the base of that pyramid for each component of J2EE.

As a Java developer, you’ve probably already learned how to build user interfaces with the JFC/Swing and AWT components. You’ll still be using those to build the user interfaces for your J2EE applications, as well as HTML-based user interfaces. Since J2SE is at the core of J2EE, everything that you’ve learned so far remains useful and relevant.

In fact, J2EE provides pretty much nothing in the way of user interfaces. You’ll also see that the J2EE platform provides the most significant benefit in developing the “middle tier” portion of your application—that’s the business logic and the connections to back-end data sources. You’ll use familiar J2SE components and APIs in conjunction with the J2EE components and APIs to build that part of your applications.

Why J2EE?

J2EE defines a number of services that, to someone developing enterprise-class applications, are as essential as electricity and running water. Life is simple when you simply turn the faucet and water starts running, or flip the switch and lights come on. If you have ever been involved with building a house, you’ll know that there is a great deal of effort, time, and expense in building in that infrastructure of plumbing and wiring that is then so nicely hidden behind freshly painted walls. At the points where that infrastructure is exposed, there are standard interfaces for controlling (water faucets and light switches, for example) and connecting (power sockets, lamp sockets, and hose bibs, for example).

In the same vein, there is a great deal of infrastructure required to write enterprise-class applications. There are a bunch of different system-level capabilities that you need in order to write distributed applications that are scaleable, robust, secure, and maintainable. Some vital pieces of that infrastructure include security, to ensure that a user is who they claim to be, and can only access the parts of the application that they’re entitled to access. Database access is also a fundamental component so that your application can store and retrieve data. Transaction support is required to make sure that the right data is updated at the right time. If you’re not familiar with some of these concepts, don’t worry—you’ll be introduced to them one at a time throughout this book.

Suppose, though, that the wiring and plumbing in your home wasn’t there. You’d need to put in your own plumbing and electricity. Without standard components and interfaces, though, you’d have to fabricate your own pipes, wiring, and so on—it’d be terrifically expensive and an awful lot of work.

Putting in a distributed computing infrastructure—the plumbing and wiring of an architecture that supports enterprise applications—is no simple feat. That’s why J2EE-based architectures are so compelling—the hard system-level infrastructure is already in place. But why not custom build (or pay someone to custom build) an infrastructure that is designed around your particular application? Well, for starters, it would take a fantastic amount of time, money, and effort. And even if you were to build up that infrastructure, it would be different from anyone else’s infrastructure, so you’d not be able to share components or interoperate with anyone else’s distributed computing model. That’s a lot of work for something that sounds like a dead end. Even if you were lucky enough to find a vendor that could sell you a software infrastructure, you should be wary about any solution that would lock you into any single vendor’s implementation that would preclude you from switching vendors at some point in the future.

The good news is, no surprise, that J2EE defines a set of containers, connectors, and components that fill that gap. J2EE not only fills the gap, but it’s based on well-known, published specifications. That means that applications written for J2EE will run on any number of J2EE-compliant implementations. The reference implementation supplied with the J2EE Software Development Kit from Sun (J2SDKEE) provides a working model that we’ll use throughout this book, since it’s the implementation that Sun has built from the specification, and is freely available. In the next chapter you’ll get an introduction to installing and testing the J2SDKEE.

It’s important to note that the reference implementation is a working model but it’s not designed to be used for enterprise-level deployment. It doesn’t provide some of the enterprise-level features that are outside of the scope of the J2EE specification, such as clustering (the ability to have multiple servers handling requests at the same time) or failover (the ability to have a group of servers that can recover when one crashes). Working with the reference implementation, though, ensures that you’ll get exposure to the core J2EE concepts that apply to ALL vendor implementations, and you won’t get bogged down with vendor-specific details.

For production deployment, you’ll want to select one of a number of J2EE solutions available from a number of different vendors, which have been optimized for high volume throughput and are designed for your particular application. Sun (http://www.sun.com/software), IBM (http://www.ibm.com/websphere), Borland (http://www. borland.com/besappserver) and BEA (http://www.bea.com/ products/weblogic/server) are high-profile examples—but certainly not all—of the commercial implementations. JBoss (http:// www.jboss.org) is an open source implementation that has a huge following. You get to choose which one works best for you—that’s an exercise that’s beyond the scope of this book.

Building a J2EE application for one J2EE implementation and deploying it on another is cheap, but it’s not free, nor is each vendor’s implementation of J2EE completely free of defects and operational quirks. Although Java and J2EE go a long way towards providing platform independence, that isn’t a guarantee that you can develop on one platform and deploy on another without any hiccups or surprises. Bugs, differences in performance, and other little “gotchas” can seriously delay or derail your project. When you are developing systems that will be deployed in a production environment, it is always a good idea to do your development and staging using the same platforms and technologies that the production environment is based upon. This will help to avoid unnecessary surprises during and after the rollout.


blog comments powered by Disqus
JAVA ARTICLES

- Java Too Insecure, Says Microsoft Researcher
- Google Beats Oracle in Java Ruling
- Deploying Multiple Java Applets as One
- Deploying Java Applets
- Understanding Deployment Frameworks
- Database Programming in Java Using JDBC
- Extension Interfaces and SAX
- Entities, Handlers and SAX
- Advanced SAX
- Conversions and Java Print Streams
- Formatters and Java Print Streams
- Java Print Streams
- Wildcards, Arrays, and Generics in Java
- Wildcards and Generic Methods in Java
- Finishing the Project: Java Web Development ...

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2017 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials