Advanced Java EE Development for Rational Application Developer 7.5: Developers' Guidebook
877
Advanced Java EE Development for Rational Application Developer 7.5: Developers' Guidebook
877eBookSecond Edition, Second edition (Second Edition, Second edition)
Available on Compatible NOOK devices, the free NOOK App and in My Digital Library.
Related collections and offers
Overview
Product Details
| ISBN-13: | 9781583475652 |
|---|---|
| Publisher: | MC Press, LLC |
| Publication date: | 06/01/2011 |
| Sold by: | Barnes & Noble |
| Format: | eBook |
| Pages: | 877 |
| File size: | 51 MB |
| Note: | This product may take a few minutes to download. |
About the Author
Read an Excerpt
Advanced Java EE Development for Rational Application Developer 7.5
Developers' Guidebook
By Kameron Cole, Robert McChesney, Richard Raszka
MC Press Online, LLC
Copyright © 2011 Kameron Cole, Robert McChesney, Richard RazkaAll rights reserved.
ISBN: 978-1-58347-565-2
CHAPTER 1
Introduction to Java EE for IBM WebSphere Application Server, Version 7.0
Chapter Topics
• What is WebSphere?
• A brief history of Java EE
• Java EE architecture
• Introducing WebSphere
Business and machines have been partners since the Industrial Revolution. As with any other business machine, businesses incorporated computers as a means to extend the productivity of workers, complete long-running tedious tasks without complaint, and maintain business records — the lifeblood of the business — with the net result being reduced operational costs. Computers were thus used only within the business — they were not intended for the customer.
The innovation IBM termed e-business in the 1990s added to the tasks of business computers that of interfacing with the customer. Since then, as companies the world over struggle to remain competitive, e-business has emerged as a way to reach a potential global marketplace, while drastically reducing costs.
Take a moment to consider the significance of this: When customers think of a business, they most likely think of the services that business offers, the reliability of these services, how readily accessible they are, and how quickly the business renders the services. Taken together, these aspects of a business represent, in the minds of its customers, the quality of service the business offers.
Inevitably, customers derive their perception of this quality through the "face" of the business. In the beginning, that face was human: The carrier delivered the newspaper; a banker granted the loan; and at the better grocery stores, courteous grocery staff carried the groceries to the car.
The substitution of the human face with the Web interface is perhaps the most delicate and most critical of all business transitions. Customers certainly will not expect fewer services or reduced quality from e-business, but, rather, more services and higher quality. Furthermore, the success of a business is now measured in mouse-clicks, not miles to the mall. Indeed, it is becoming very difficult to imagine a business that is not an e-business, or at least not substantially enabled by the Internet.
Change is inevitable and rapid. This is a given in the world of information technology (IT). The enterprise developer is now at the center of the most significant change in IT since the advent of the enterprise application: the widespread adoption of service-oriented architecture (SOA) as the model for e-business.
While enterprise developers still develop and deploy distributed enterprise-level applications that model an organization's processes and practices, they must also incorporate multiple applications into a higher-level architecture. In other words, the application is no longer the overarching architecture that models the business; rather, the application itself has become (perhaps) just another component.
Enterprise developers work more closely than ever before with business analysts, modelers, application architects, application assemblers, and systems administrators to apply sound object-oriented analysis and design techniques to a business model, without altering that model in any way. Developers understand application assembly within the business domain across a multitier architecture, and they must assess carefully the need for new components, the reuse of existing components, and the integration of existing computing resources that are not Java related as services. Finally, developers require system administration skills to tune the application at the code/design level to meet performance requirements.
The systems we design and build should be limited only by our imagination, not by lack of interoperability between proprietary technologies, or, worse, our ignorance of the very existence of an enabling technology. Most importantly, the technologies we use must be extremely flexible, to match the flexibility required of modern business. IBM has recognized that the open-source and open-standards movements in the IT industry best meet the needs of business, and that the merger of open-standards computing with creative business analysis is the correct formula to make businesses grow. The WebSphere Software group has evolved to enable this merger.
What Is WebSphere?
WebSphere is a software platform for e-business and a comprehensive suite of software offerings to support this platform. The focus of this book is the creation, using the IBM Rational Software Delivery Platform, of enterprise applications and services that will run on any server product in the WebSphere suite. In addition to Web Services creation and enterprise application development and deployment to WebSphere Application Server, the Rational Software Delivery Platform supports the most comprehensive range of tooling in the industry — a list too long to include here. Because this book addresses the role of the enterprise developer, most of the focus will be on the composite set of tooling known as IBM Rational Application Developer (hereafter referred to as Application Developer).
Beginning with Version 4 and continuing through Version 7.0, WebSphere Application Server and Application Developer are fully compliant with the Java Enterprise Edition (Java EE) specification (formerly known as J2EE), thus delivering both open-standard interoperability beyond the Java programming language and the platform independence of Java. Furthermore, Java EE allows developers to focus on the integration of IT with business processes, instead of on low-level implementation details. A brief history of Java EE can help us understand how WebSphere supports modern enterprise computing.
A Brief History of Java EE
Java EE is the convergence of the Java Programming Language, the Common Object Request Broker Architecture (CORBA), and X/Open transaction specifications. Thus, work on Java EE really began with Sun, IBM, and others in the Object Management Group in 1989. However, the specification called J2EE did not emerge until the late 1990s in an effort to make distributed enterprise computing more agile by simplifying the tasks of development and deployment. At the heart of the roadmap to enterprise computing, Java EE promised to separate the programming logic from the technology plumbing. Developers could focus on the design aspects of computing as they developed Java components, and the infrastructure would provide the necessary transport and transaction services in an open, platform-independent way.
Major challenges of e-business include security, dynamic processing, and growth. These are real business requirements, rather than computing concepts.
First, to conduct e-business, organizations must make information usable, available, and secure. A traditional storefront business achieves security in physical ways, such as with locks and keys. To do e-business, our computing model must emulate those physical security mechanisms.
Second, data that just sits there is not business: The data needs to be manipulated — manipulated in such a way as to resemble actual, intuitively satisfying business processes (e.g., transactions). A transaction models the concept of an indivisible unit of work that supports the business.
Once we have secure transactions involving business data, we still need one ingredient to complete an e-business application: growth. Businesses that do not grow do not survive. Because growth implies that each new customer receives the same, if not improved, quality of service, a business often must acquire new physical property and hire new employees to support that growth. In computing terms, this means that throughput must be scalable, to accommodate increased demand.
CORBA led the way to vendor-independent distributed computing. Many of the good ideas of Java EE, such as services, which we will be discussing shortly, actually appeared in CORBA first.
The Java solution for the incorporation of CORBA functionality was Enterprise JavaBeans (EJBs), a way to incorporate the robustness of the CORBA Object Request Broker (ORB)'s transactional and secure services into a standard architecture. Existing CORBA implementations, although based on the same, robust CORBA standards, were not "standard" (i.e., portable and interoperable). But EJB went beyond CORBA: The designer of Java wanted the remote procedure-calling architecture to be more intuitive than the complicated and nongenial CORBA code. Incorporating the intuitiveness and ease of use of JavaBeans technology into CORBA-compliant components was the deciding factor in the industry acceptance of EJB over CORBA as the e-business solution of choice.
With EJB, Java provided a technological basis for implementing robust e-business solutions, addressing and going beyond the technologies CORBA provided. However, the picture was not complete. As programmers began to incorporate the new Java technologies into their solutions, it became apparent that there was no true architectural standard to which programmers could apply the new technologies. In other words, Java needed to evolve from a set of technologies into a framework that would standardize not only the technologies used but also the way in which they were used in architecture. This standard would become the J2EE specification, which is the basis for this entire book.
Java EE Architecture
When the Java EE specification mentions architecture, it clearly refers to runtime architecture. (Note: Henceforth, although not always stated explicitly, this discussion is limited to the Java EE 5 framework specification.) Every discussion of this architecture must begin with the figure from the specification itself that you see in Figure 1–1.
Although the diagram in the figure may imply a programming architecture, at some level, its main purpose is to outline two things:
1. That there are specific components such as servlets, JSPs, and EJBs.
2. That those components need specific runtime support, which containers such as the Web container and the EJB container provide.
Also implied in the figure is a connectivity specification (those arrows that connect the containers/components to one another). Although they are obviously blank in this diagram — in fact, absent from any diagram in the actual specification — the transports are "filled in" in the text of the Java EE specification.
We will use this diagram to provide an outline for most of the rest of this chapter: We will characterize the Java EE platform as being divided (implicitly) into application components, system components, and standard services (yet to come). We will begin this discussion of these three architectural elements with the application components, because their definition really implies, and was ultimately responsible for, the services that the containers, as well as the transport protocols, provide. We will treat the notion of application roles as part of the platform architecture — once again, a kind of pedagogical choice in this book, although certainly implied within the Java EE specification.
Java EE Architecture: Application Components
This might be a good time to bring out a salient point in the definition of Java EE application components: The Java Platform, Enterprise Edition specification, v5 (Java EE 5 specification) says, "Application components can be divided into three categories according to their dependence on a Java EE server":
• Components that are deployed, managed, and executed on a Java EE server. These components include Web components and Enterprise JavaBeans components.
• Components that are deployed and managed on a Java EE server, but are loaded to and executed on a client machine. These components include HTML pages and applets embedded in HTML pages.
• Components whose deployment and management is not completely defined by this specification. Application Clients fall into this category. (Java EE 5 specification)
The Application Client
Instead of starting in the upper left-hand corner of the Figure 1–1 diagram, as is typical in these reviews, we'll begin with the component labeled Application Client. Historically, this is what we've always known, simply, as a computer program. Before Java EE was released, the name for this component in Java terms was just application: a set of related methods, linked together by a runable method; namely, the mainO method. At other times, this component was referred to as standalone, which implied that it required only the Java Virtual Machine (JVM) — no container — to execute: The JVM was given the name of the class, as an argument, which contained the main() method, and the JVM executed that method. At some point, the Java EE architecture designers realized that the fact that the application was standalone was inconsistent with the component model, which already had been applied to servlets and EJBs. In other words, everything, including the application, should be a component, which by definition, was a software element that required a container. Thus was born the client container, which was to run application client components.
In the Java EE 5 architecture, the application client is a largely graphical program, which gets its data from EJBs, running in an application server, via access to the Java Naming and Directory Interface (JNDI) namespace. So, put another way, the application that formerly could stand alone will now be a client to a Java EE server, with the client container providing access to both the JNDI namespace of that server and the necessary libraries (e.g., javax.naming).
Application clients also require a JVM to execute in — not the JVM of the application server variety, but a basic JVM that resides on the client side. We will try to flesh out the nature of these components in both the container section to follow and in the packaging/deployment discussion of chapter 16. (If, on the whole, you find the treatment of application clients "vague," it is. The Java EE 5 specification says, "Future versions of this specification may more fully define deployment and management of Application Clients.")
The Applet
The applet (the name implies "little application") is often compared to the application (the application client, which we have just discussed above) in early literature. In fact, many texts contained exercises that asked the developer to convert an application into an applet, and vice versa.
The Servlet
Servlets are among the "Web components" in the first category of components mentioned at the beginning of this section. We will cover servlets in detail in chapter 3. The strength of servlets lies in their ability to generate and deliver dynamic content in response to requests.
The JavaServer Pages (JSP)
JavaServer Pages (JSP) were a response to the problems inherent in embedding HTML in servlet code that was ultimately to be compiled by an ordinary Java compiler. Escape characters need to be included to differentiate between similar notions the compiler recognizes. Also, the compiler, or the Java editor in Rational Application Developer, cannot check the validity of the HTML. JSP technology, in contrast, enables an enterprise developer to write the functionality of a servlet in purely HTML form; the servlet's syntax is protected by the system's HTML editor, such as the Page Designer in IBM Rational Application Developer.
Moreover, a best-practice idea has been developing that recognizes a design pattern from SmallTalk called Model-View-Controller (MVC). Simply put, MVC requires that the code in each element of an application restrict itself solely to the role of that element in the overall architecture of the application. In other words, code that processes business data (fulfilling the role of model) should remain separate from code that displays the results of that processing (fulfilling the role of view). Code that delegates and coordinates between functions in the view and model — i.e., code that controls the flow between other functions — falls into the role of controller. The JSP fulfills the role of view. When used as part of MVC, the JSP page is commonly referred to as a display page. We include a more complete discussion of JSPs in the MVC pattern in chapter 4.
The Filter
Often, servlets and JSP pages require preprocessing, such as logging and security checking. The filter is used to perform any preprocessing that a servlet or JSP requires.
JavaServer Faces (JSF)
JavaServer Faces (JSF) technologies have been added to the Java EE specification to facilitate Web application development. JSF is a framework that provides developers with components to develop Web interfaces and gives tool providers a specification in Java EE that they can build tools around.
The Web Event Notifier
The Java Standard Edition (JSE) provides an event-notification system, which allows components to be notified of events fired by other components. For a time, this mechanism was absent from Java EE. As of J2EE 1.3, however, at the Web component level, an event-notification system, which allows Web components to trigger functions in other Web components via event notification, was added to the Web container's functions.
(Continues...)
Excerpted from Advanced Java EE Development for Rational Application Developer 7.5 by Kameron Cole, Robert McChesney, Richard Raszka. Copyright © 2011 Kameron Cole, Robert McChesney, Richard Razka. Excerpted by permission of MC Press Online, LLC.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
Contents
Chapter 1: Introduction to Java EE for IBM WebSphere Application Server, Version 7.0,Chapter 2: Introduction to IBM Rational Application Developer for WebSphere Software, Version 7.5,
Chapter 3: Servlets,
Chapter 4: JavaServer Pages,
Chapter 5: JavaServer Faces (JSF),
Chapter 6: Struts,
Chapter 7: Java Persistence API,
Chapter 8: Session Enterprise JavaBeans,
Chapter 9: Message-Driven Enterprise JavaBeans,
Chapter 10: EJB Client Programming,
Chapter 11: Transactions,
Chapter 12: Security,
Chapter 13: Web Services,
Chapter 14: Web Services Client Programming,
Chapter 15: Profiling and Debugging,
Chapter 16: Packaging and Deployment,
Chapter 17: WebSphere Administration,