Enterprise Java and Rational Rose -- Part I by Khawar Ahmed Technical Marketing Engineer Rational Software Loïc Julien Software Engineer Rational Software "We believe that the Enterprise JavaBeans component model and associated Java 2 Enterprise Edition standards will dominate the application server market and drive a potential market growth rate of almost 180 percent yearto-year." Mike Gilpin, Giga Information Group In this two-part series, we explore the synergistic relationship between Java 2 Enterprise Edition (J2EE), a popular development platform for distributed enterprise applications, and Rational Rose, the industry's leading CASE modeling tool. Part I provides an introduction to J2EE from an architectural perspective. Part II will begin by explaining how Servlets and JSPs work within the J2EE architecture and then go on to show how Rational Rose can help developers build better J2EE applications. With the advent of a "the network is the computer" application paradigm, the popularity of distributed applications has grown dramatically, and J2EE has quickly become one of the dominant distributed applications environments. If its adoption rate to date is any indication, J2EE, which includes the Enterprise JavaBeans (EJBs) technology, should prove to be a promising means for achieving component-based software development. Of course, component-based development will be effective only if it can be used to build distributed systems with contemporary n-tier application architectures, and if those systems are portable across different hardware and runtime environments: servers, underlying databases, etc. We believe that using Rational Rose greatly simplifies the task of developing J2EE applications.
J2EE: Responding to Enterprise Application Needs 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. Figure 1: The Relationship Among J2EE Roles (View full size graphic in new window) 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.
J2EE and Other Java Platforms You are probably wondering if there's a relationship between J2EE and the other Java platforms. In fact, there is! Sun has defined three platforms, all derived from the core Java technologies. They are targeted to three specific domains in order to provide specialized solutions for each: The consumer domain and the embedded market. The "general" application domain that uses core Java technologies. The enterprise application domain and the e-business market. J2EE and Multi-Tier Architecture An enterprise application may (but does not necessarily) consist of several tiers. Tiers are primarily abstractions to help us understand the architecture. The J2EE architecture usually involves four distinct tiers, as shown in Figure 2. Figure 2: Multi-Tier Architecture Say you are doing some shopping on the Net. Your browser is in the Client Tier displaying applets, HTML, etc. When you press "Submit," it invokes a servlet to run on the Web server, which resides in the Web Tier. The servlet may need to get some data via an EJB residing on the App Server in the Business Tier. The EJB may then need to access a database and retrieve the information you want in the Enterprise Information Systems (EIS Tier).
More precisely, the tiers are distinguished as follows: The Client Tier -- The Client Tier provides for the interaction between the Web application and the end users, typically through a thin client such as a browser. The technologies involved in this configuration are D/HTML, XML, XSL, Java Applet, etc. A client may also be an "application-based" client that connects to an Enterprise Information System client. Such clients are commonly referred to as think clients. The Web Tier -- The Web Tier is the interface between the end user and the business logic of your application. By separating the presentation logic from the business logic in this fashion, you can update the look and feel of your application without any modification to the business logic itself. This also allows you to have a throw-away facade that lets you stay in sync with the latest Internet technologies. At this level, you typically find the JSPs (Java Server Pages) and Java Servlets technologies, as well as use of XML, XSL, HTML, DHTML, GIF images, JPEG images, etc. The 1.2 specification of J2EE also introduced the notion of a Web Application, which means that your Web-tier application can be packaged in a Java Archive called a Web Archive (.war file). The Business Tier -- This is where you implement the business logic, that is, the actions that make up your application. These actions are encapsulated within components called Enterprise JavaBeans (EJBs). By far the most popular technology of the J2EE family, the Enterprise JavaBeans architecture brings to your application all the system-level services it might require, such as transactions, security, persistence, or multi-threading. These aspects of EJBs are handled by the EJB container, which we will discuss shortly. The EIS Tier -- In this tier, you provide persistent storage for the resources required by your application. Although an application does not have to have all these tiers as independent entities, it helps to conceptualize an application component as belonging to a specific tier so you can structure it appropriately. Such an approach is recommended for achieving a sound architecture. The J2EE Conceptual Model Let's now visualize J2EE as an onion with several layers of skin. The outermost layer is the server software, which enables application software to run on the physical hardware. The container is the next layer in. It provides generic services and hosting for the enterprise application.
The enterprise application consists of EJBs, servlets, and JSPs. Each container provides services to the EJBs and servlets it is hosting. These services are provided via the J2EE APIs, as specified by the J2EE specification. To understand the container model within a more familiar context, consider this. If you, as a developer, want to access a relational database, you probably don't really want to know what kind of caching architecture the database provider is using. Nor is there likely a strong desire on your part to implement all the access details. Given that all databases are conceptually similar, what you need is an abstraction for the database that easily provides access to the data and associated services. A container that holds your data with a set of services is that abstraction. The J2EE simply extends this container/data architecture to the enterprise application domain. Figure 3 shows the J2EE Conceptual Model. Figure 3: J2EE Conceptual Model The J2EE platform defines four containers: a Client Container and an Applet Container (Client Tier), a Servlet and JSP Container (Web Tier) and an EJB Container (Business Tier). These containers provide deployment and runtime support for the associated tier components. A container is located within a server. The relationship between a server and the containers within it is illustrated in Figure 4.
Figure 4: Relationship Between a Server and the Containers Within It What Are Enterprise JavaBeans? The primary purpose of Enterprise JavaBeans (EJBs) is to simplify the development of business logic. EJBs, which are non-visible, server-side beans, fulfill this purpose by specifying a general, server-side framework for building distributed and secure components, which support transactions out of the box. So, you may ask, who provides all this distribution and security infrastructure? The answer is vendors such as IBM and BEA. When vendors indicate their compliance with the J2EE EJB specification, they are signaling that they conform to the specifications. EJBs fall into two very distinct categories: Session beans. Think of these as beans that implement workflows or processes (for example: making a hotel reservation, transferring funds from one account to another, etc). These are by nature transient activities. Once the task is complete, the bean has no reason to exist. Entity beans. These are object-oriented representations of persistent data residing in relational databases (for example: a representation of hotels in Seattle, a business's customers, your bank accounts). Each EJB has a remote interface as well as a home interface, as shown in Figure 5. EJBObject and EJBHome implement these interfaces, respectively. The client never actually interacts with the bean directly; instead it calls methods on some objects that you, as the bean creator, had nothing to do with.
Figure 5: The Enterprise JavaBean Interfaces The primary purpose of the home interface is to provide a "factory" interface for the EJBs. Clients use the home interface to address questions such as how to locate an EJB, how to create an EJB, or how to delete an EJB. For example, a client creates an EJB by using the home interface's create methods. Remember that these are methods that the developer of the EJB provided. The create() methods, of course, are not implemented by the EJB. Instead, they simply correspond to "ejbcreate" methods in the EJB itself, which get called in response to a create method call. The remote interface covers everything else. It is implemented by the EJBObject, which, in essence, wraps the EJB and knows all about networking, transactions, security, and so on. EJBObject, through the remote interface, exposes the business methods implemented by the bean and delegates them when the business methods are invoked. The EJBObject provides other services, such as a way to test whether two EJBObjects are identical, identify the corresponding home object for the EJBObject, etc. What is the upside of such a complex architecture? Well, for one thing, it means that no matter where the bean is located, the client doesn't need to do anything differently. So you can easily change things without breaking the application. Second, it enables the container to intercept the requests so that it can provide all those services that you get from your runtime environment. Do you want only a certain group of people to access a specific business method? No problem. If the deployer specifies security attributes at deployment time, then, when the method is invoked, the container can intercept it to make sure only the authorized people are trying to access it. The same is true for transactions, persistence, etc. Session Beans
As we mentioned earlier, a session bean exists to carry out a specific task on your behalf. Think of it as an extension of a client program that executes on the server side. Now imagine that you are doing some bank transactions and using a session bean. Would it make sense for the bean also to perform tasks on behalf of another client who may be online at the same time? Obviously not, because your account information, etc., is specific to you. So session beans are typically private and cannot be shared. In essence, there is an ongoing interaction strictly between you and the session bean, and it maintains what is called "conversational state." Typically, there is no persistence associated with your session, meaning that if your session ends abruptly, it is usually not possible to recover and continue on. The EJB specification allows you to differentiate between the session beans as either stateless or stateful. Stateless session beans typically carry out "atomic" operations. That is, the bean is asked to do something, and once the bean has fulfilled that request, the conversation between the client and the bean is over. A good example is a bean that implements a credit card authorization. You enter a number, the bean obtains the authorization, and it's done. Another party could then request another credit card authorization, and a new session could be started using the same bean. In other words, the container does not save any value for the bean attributes during the session. Stateful session beans are useful for more complex activities. These beans remember things from one method call to another, so you could call a bean repeatedly and continue your "conversation" or session. For example, if you were to go shopping on the Net and use a shopping cart to keep track of your purchases, a stateful session bean could represent that. Entity Beans The other type of EJB is called an entity bean. Entity beans were actually introduced in the first EJB spec, but the container providers were not required to support entity beans. That changed with the EJB 1.1 spec, and support for entity beans is now required for J2EE compliant application servers. Entity beans provide an object-oriented view of the persistent data in a database. Things such as customer, employee, and account, as well as things such as banks, tickets, and reservations, all map nicely to entity beans, allowing you to work with objects rather than database records. There are many advantages to using entity beans. For one, you can simply call methods (e.g., mybean.setdestination()) instead of dealing with obscure SQL queries. In addition, objectification allows you to reuse the entity bean concept throughout your system consistently.
Since an entity bean refers to database records, it needs to be uniquely identified. That's why you have a primary key for each entity bean. For example, for an employee entity bean, the primary key may be the employee ID. From a user perspective, all the details of database access, synchronization, and so on, are all taken care of, and things become much simpler. For instance, the container ensures that the same method is not called concurrently, unless explicitly specified by the bean provider. Since entity beans deal with databases, there has to be coordination between the two to keep things in sync. This process of coordination is referred to as "persistence." Two types of persistence schemes are available for entity beans.the simpler one is called Container Managed Persistence (CMP). This is attractive because, as a bean developer, you simply tell the container to take care of things. You can have it take care of business logic, specify how entity bean attributes map to fields in the database, and then sit back and relax while the deployment utility actually generates all the SQL calls at deployment time. The nice thing is that, by using CMP, your entity bean doesn't have to embed direct database queries. So it remains independent of the database, and hence easily portable. But say you want more control over how the persistence is handled (e.g., you want to do it more efficiently than the auto-generated code). In that case, you can specify Bean Managed Persistence (BMP) and write all the database access logic as part of your bean. Of course, the disadvantage of bean-managed persistence is that you now have to understand the database structure, know SQL, and do a lot more coding, too! Working with EJBs In order to create an EJB, the first thing you need to do is find its home object. You do this by using the "nickname" for the bean and querying the Java Naming and Directory Service (JNDI), such as Novell NDS, LDAP, etc. Once you have a reference to the home object, you can invoke a create method on it. When a create is invoked on the home interface: The EJBHome creates an instance of the EJBObject and gives it the bean instance of the appropriate type to work with. Once the bean instance is associated with the EJBObject, the instance's ejbcreate() method is called. For entity beans, if a matching record already exists in the database, then the entity bean is populated from it; otherwise, a new record is inserted into the database.
For session beans, the instance is simply initialized. Upon completion of the ejbcreate() method, EJBHome returns a remote reference for the EJBObject to the client. Remember that since we are dealing with remote objects, a remote reference is actually a stub. The client can now call business methods on the stub. The stub relays the methods to the EJBObject, which in turn delegates those methods to the bean instance (of the class we created), and the result is relayed back through the chain when the method returns This sequence of events is shown graphically in Figure 6. Figure 6: Using an EJB (View full size graphic in new window) Next Month: Servlets, JSPs, and Building Better J2EE Applications with Rational Rose We hope that we've given you a good basic understanding of the J2EE architecture and its benefits, as we conclude Part I of this article with an invitation to join us next month. In Part II, we will first take a look at how servlets and JSPs work within the J2EE architecture. Then, we will discuss in detail some of the ways you can harness the visual modeling power of
Rational Rose to build better J2EE applications. Please click here to go to Part II! For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you! Copyright Rational Software 2001 Privacy/Legal Information