If applications that are developed in one location are to be usable at another (just think of differences in national laws, languages, notation, and on and on), then there must be a high degree of configurability, so that the applications can be adapted without the necessity of being recompiled. As a further alternative one might imagine (thinking again of the building-block approach) replacing building blocks that cannot be implemented at a particular location by location-optimized building blocks.
Stepwise Migration and Data Storage
Rome, as has often been observed, was not built in a day (and it is still under construction!), and neither can a system redesign and reconfiguration take place overnight. Therefore, the step-by-step changeover to a new system is an important topic. It should be simple to create interfaces to existing systems, a requirement that results in something even more important: In the ideal case it should make no difference to a particular application where data is stored. It can be located in a database belonging to the new system, in a database belonging to an old system, or indeed in an external database that does not belong to the system at all.
The number of considerations that are required in order to produce the solution to our problem can easily exceed the capabilities of a normally endowed application developer. However, today a number of software companies offer solutions to developers that provide ways of overcoming the problems inherent in a project such as the one that we have described, and a great deal of the thought and design required to handle the issues listed above have been collected into a number of industry standard platforms. This book discusses one of these platforms in great detail: Enterprise JavaBeans (or EJB for short). So wake up and smell the coffee, and let's get started.
So Now What?
In Chapter 2 we discuss the fundamentals of Enterprise JavaBeans and place them in the context of the technologies for software development. In Chapter 3 we devote our attention to the fundamental architecture of Enterprise JavaBeans as well as the roles that the development team can play during the development, deployment, and management stages of the system. The different varieties of components (known as beans), namely, entity, session, and message-driven beans, are discussed in Chapters 4, 5, and 6. Building on this we go on in Chapter 7 to discuss the topic of transactions, while Chapter 8 is devoted to security. In each of these chapters extensive examples are introduced to clarify the discussion. In Chapter 9 we discuss several aspects of the practical application of the principles discussed (again with extensive examples). Finally, in Chapter 10, we discuss web services and the integration of Enterprise JavaBeans to other platforms that exist within common enterprises.
After you have read this book you should have a firm grasp of the capabilities of the Enterprise JavaBeans platform. Furthermore, you should be in a position to translate the knowledge you have gained from theory into practice.
Chapter 2: Fundamentals
Enterprise JavaBeans is an architecture (Framework) for component-oriented distributed applications. Enterprise Beans are components of distributed, transaction-oriented business applications.
—Sun Microsystems, 2001
The programming language Java is known primarily for two features: its platform independence and its ability to beautify web pages by means of applets. However, Java has many capabilities to offer above and beyond the decoration of web pages. Java is a full-fledged object-oriented programming language that is increasingly being used for the development of enterprise-critical applications. As Figure 2-1 shows, Enterprise JavaBeans is a building block in the product and interface catalog of Sun Microsystems for the development of enterprise applications.
Figure 2-1: The place of Enterprise JavaBeans in Sun's enterprise concept [J2EE-APM, 2000.]
In the figure, J2EE stands for Java 2 Platform, Enterprise Edition, JSP for JavaServer Pages, and EJB for Enterprise JavaBeans.
Enterprise JavaBeans is not a product, but merely a specification. Any individual who feels the calling may bring to market an implementation of the Enterprise JavaBeans specification.
That Enterprise JavaBeans involves a client–server architecture should be no cause for wonderment (Sun has positioned Enterprise JavaBeans in the domain of server-side applications logic. Three-tiered architecture is currently the one favored by most system architects (the trend is in the direction of multitiered, or multilayered, architectures).
Three-tiered systems are distinguished in that the actual program logic (in relation to enterprise applications often called "business logic") is located in the middle layer (on an application server); see Figure 2-2.
Figure 2-2: Three-tiered architecture.
The bundling of the application logic on its own server in a layer between the clients and the database offers the following advantages over traditional two-tiered systems:
The client programs become significantly smaller (and therefore are often called "thin clients") and thus require fewer resources of the client computer.
The database is transparent to the client developer. The middle layer (application layer) is completely abstracted from access to the data and concerns itself with data stability (which simplifies considerably the development of client programs).
Applications are more easily scalable, since a division of tasks can already take place on the application layer (for example, in the case of server overload a client query can be passed to another server).
A particular application logic is programmed only once and made available to all clients centrally in the middle layer, and so the system is easy to maintain and extend. If there is a change in the application logic, then only a central component is affected and not a large number of individual client applications.
If we were to attempt to classify existing system architectures in order to locate Enterprise JavaBeans, then we might end up with a picture like that shown in Figure 2-3.
Figure 2-3: Classification of Enterprise JavaBeans in a system portfolio.
Enterprise JavaBeans is at its best in the domain of enterprise, intranet, and Internet applications, which are built primarily on a three-tiered, or even n-tiered, architecture and are developed in an object-oriented language (in this case Java). One speaks of a multitiered architecture (also called n-tiered) if in addition to the client, application, and database layers there are additional layers for increasing the level of abstraction or to improve scalability, or else when several three-tiered systems are arranged in a cascade.
Since the word "enterprise" appears explicitly in the name, one feels compelled to ask what the Enterprise JavaBeans specification provides to assist developers in meeting the demands of business today. To answer this question we must first consider on what criteria a decision for or against a given technology should be based.
Economic viability refers to the domains of development, acquisition, maintenance, and adaptation. Economic viability in development exists when the technology actively supports a shortening of the development cycle. An increase in productivity thus leads to reduced costs, which can then be passed along (this is what economic viability in acquisition means to nondevelopers). Economic viability in maintenance is the result of stability, which results in lower servicing requirements. Economic viability as it relates to further development and adapation is offered by a technology that enables a system to be extended or adapted without great expense and risk.
The question of security must be examined with extreme care. In relationship to an investment, such security exists if the technology promises a certain minimum life span and is assured of long-term support. Security also refers to security against breakdown, that is, to availability. Its purpose is to avoid costs due to failure in parts of the system or to system breakdowns. Security means as well the capability of a technology to protect sensitve data from prying eyes and to protect the system from unwelcome intruders.
The deployment of a particular technology is justified only at the point where there is a requirement for the capabilities that it offers. An enterprise will not institute a technology or product merely on account of its current popularity without experiencing a genuine need.
In the following chapters this book will lay out in detail how the Enterprise JavaBeans specification attempts to deal with the requirements of modern enterprises for a stable system.