Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Mastering Enterprise JavaBeans™ and the Java 2 Platform, Enterprise Edition - Roman E

..pdf
Скачиваний:
41
Добавлен:
24.05.2014
Размер:
6.28 Mб
Скачать

340 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

Current currentTX = CurrentHelper.narrow (orb.resolve_initial_references("TransactionCurrent"));

/*

* Begin the transaction */

currentTX.begin();

/*

* Use the home object to create an EJB object */

Hello hello = helloHome.create();

/*

* Call a business method */

System.out.println(hello.hello());

/*

* Remove the EJB object */

hello.remove();

/*

* Commit the transaction */ currentTX.commit(true);

}

}

Source 11.2 Example CORBA EJB client (continued).

As you can see, CORBA clients are a bit more complex than RMI-IIOP clients. We first need to initialize the ORB before beginning any CORBA operations. Next, we get a reference to a naming context via COS Naming, which we use to look up home objects. Once we’ve retrieved the home object, calling methods on enterprise beans is syntactically similar to Java RMI. We also get a reference to the OTS Current interface, which is used to demarcate transactional boundaries (analogous to the JTA UserTransaction interface we retrieved in Source 11.1). The begin() and commit() calls have the same semantic meaning as their JTA equivalents.

Go back to the first page for a quick link to buy this book online!

CORBA and RMI-IIOP 341

Summary

In this chapter, you’ve experienced a whirlwind tour of CORBA and IIOP. We’ve displayed CORBA’s advantages and the reasons why CORBA is a useful technology. We then delved into the inner workings of CORBA and explored its architecture. We also glanced at CORBA’s services and touched on the IDL-to-Java mapping.

We then compared RMI to CORBA and reasoned why the two worlds need cohesion. We designed the requirements for RMI-IIOP interoperability and dived into several scenarios illustrating RMI and CORBA working in unison. We wrapped up our discussion of RMI-IIOP by illustrating the steps necessary for you to write RMI-IIOP code, and we examined the details of the javax.rmi package.

In the last section of this chapter, we caught a glimpse of the future: EJB and CORBA interoperability. Although it wasn’t possible at the time of this writing, by the time you read this, EJB and CORBA should be showing their first signs of coexisting in deployments.

For more information about the topics in this chapter, see these resources:

The OMG Home Page: www.omg.org. This is the home of the Object Management Group, a consortium of companies that invented CORBA and IIOP. You can download the CORBA-related specifications here.

Client/Server Programming with Java and CORBA by Robert Orfali and Dan Harkey (John Wiley & Sons, 1998, ISBN 047124578X). This book is great for those new to CORBA, with an emphasis on broad exposure to CORBA concepts, rather than depth of examples.

Java Programming with CORBA by Andreas Vogel and Keith Duddy (John Wiley & Sons, 1998, ISBN 0471-24765-0). This book goes into a bit more depth and explores concepts such as security and events in CORBA.

Programming with VisiBroker by Doug Pedrick, Jonathan Weedon, Jon Goldberg, and Erik Bleifield (John Wiley & Sons, 1998, ISBN 0471-23901-1). This book is extremely useful for programmers using Inprise’s VisiBroker for Java CORBA-compliant product.

Sun Microsystems’ RMI-IIOP package. The book’s accompanying Web site includes a link to download the RMI-IIOP package from the Sun Web site. The RMI-IIOP download comes with two complete examples of RMI-IIOP, which illustrate converting an existing RMI application to use IIOP rather than JRMP as the protocol, and interoperability between RMI clients/servers and CORBA clients/servers. I encourage you to try out RMI-IIOP for yourself by playing with the examples included with the download.

Go back to the first page for a quick link to buy this book online!

P A R T FOUR

J2EE in the Real World: A

Sophisticated E-Commerce

Deployment

he previous sections of this book provided you with insight into the concepts Tbehind EJB, and you’ve seen a number of relatively straightforward examples of EJB in use. Now we’re going to bolster our basic knowledge with some practical applications. You’ll get to put everything you’ve learned together in a so-

phisticated real-world e-commerce deployment.

We’ll take the basics that we learned about session beans and entity beans and combine them. You’ll see how every different kind of bean has its own role in a sophisticated object model. Our deployment will make use of the following:

■■Stateful session seans

■■Stateless session beans

■■Bean-managed persistent entity beans

■■Container-managed persistent entity beans

In total, we’ll have nine different enterprise beans working together. This should prove to you that the Java 2 Platform, Enterprise Edition (J2EE) has the potential for serious work.

The transaction concepts you learned in Chapter 10 will come into practice in this section. Our deployment will make use of both client-demarcated and declarative transactions. If you’re itching to see how transactions can be used in the EJB world, the e-commerce solution we put together will demonstrate just that.

Once we’ve designed our object model, we’ll put it all together with a Web-based graphical user interface. Here’s your chance to get up to speed with how to tie a Web-based GUI to an EJB system. Specifically, we’ll learn about how to write

343

Go back to the first page for a quick link to buy this book online!

344 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

a GUI layer on top of enterprise beans with Java servlets in a Web-based Internet deployment.

When our deployment is complete, we’ll examine tuning and optimizing it in several ways, including surveying mechanisms to generate globally unique primary keys for entity beans, lazy-loading enterprise beans for enhanced performance, and more.

Inventing this e-commerce solution will be a blast. You’ll get a chance to use J2EE to solve real-world problems. And if you have e-commerce needs, you can leverage the code from this example as a basis for your own deployments. We’ll put the basic framework together, leaving room for extensibility. At the end of our discussion, we’ll look at future enhancements you may want to make.

Go back to the first page for a quick link to buy this book online!

C H A P T E R12

J2EE in the Real World: Designing

an E-Commerce Object Model

asmine’s Computer Parts, Inc. is a fictitious manufacturing company that makes Ja wide variety of computer equipment, including motherboards, processors, and memory. Jasmine, the company’s owner, has been selling her products using

direct mail catalogs, as well as a network of distributors and resellers.

Jasmine wants to lower the cost of doing business by selling her computer parts directly to the end customer, through an e-commerce Web-based sales model. Jasmine has given us a high-level description of the functionality of the e-com- merce solution. She’d like the following features in the system we provide for her:

User authentication. Registered users would first log in to the Web site to access the complete catalog. Only registered users should be able to browse and purchase from her online store.

An online catalog. Users should be able to browse her complete product line on the Web and view details of each product.

Online quote generation. While browsing the catalog, a user should be able to pick and choose the products he or she wants. The user should then be able to view the current shopping basket (we’ll call this a quote). The user should be able to, for example, change quantities of items he or she has already picked out.

Specialized pricing functionality. Users who order items in bulk should get a percentage discount. For example, if I order five memory modules, I might get a 10 percent discount on that memory. In addition, registered users who frequent the store often should get additional discounts.

Order generation. Once the user is happy with his or her selections and has committed to ordering the products, a permanent order should be generated. A separate fulfillment application (which we won’t write) would use the data

345

Go back to the first page for a quick link to buy this book online!

346 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

in the orders to manufacture the products and ship them. The user would be able to return to the Web site later to view the status of current orders.

Billing functionality. Once the user has placed the order, we should bill it to him or her. If the user does not have enough funds to pay, the order should be cancelled.

This is definitely going to be a full-featured deployment! Over the next several chapters, we will implement these requirements. By the time we’re done, you should have a solid understanding of how you can use EJB and the Java 2 Platform, Enterprise Edition for e-commerce solutions. We kick things off in this chapter by designing a high-level object model for our deployment.

A Preview of the Final Product

To give Jasmine an idea of what the final product should be like, our sales team has put together a series of screenshots. The screenshots show what the e-com- merce system will look like when an end user hits the Web site.

Figure 12.1 shows a user logging into the system initially. Our authentication will be through login names and passwords.

When the user has been recognized, he or she is presented with a Web storefront. The Web storefront is the main page for Jasmine’s online store. This is shown in Figure 12.2. From the Web storefront, the user can jump to the catalog of products that Jasmine offers, shown in Figure 12.3. If the user wants to view

Figure 12.1 A user logging into Jasmine’s Computer Parts.

Go back to the first page for a quick link to buy this book online!

J2EE in the Real World: Designing an E-Commerce Object Model 347

Figure 12.2 The Web storefront for our online store.

details about a product, he or she can check out the product detail screen, shown in Figure 12.4. The user can also add the product to the current shopping cart, or quote. A quote is a temporary selection of products that the user has made.

Figure 12.3 Browsing the online catalog.

Go back to the first page for a quick link to buy this book online!

348 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

Figure 12.4 Viewing a particular product.

Quotes are temporary because the user has not committed to purchasing the goods yet.

Once the user has made his or her choices, the user can view a quote for the current selections (and make any last-minute changes), as shown in Figure 12.5. When the user clicks the button to purchase the selection, he or she is billed and a new order is generated. Finally, the user is given the order number for future reference (Figure 12.6).

Scoping the Technical Requirements

While meeting Jasmine’s requirements, we’d like to develop an extensible infrastructure that she can add to in the future. That means making the right abstractions to loosen the coupling between our components. Ideally, Jasmine should be able to plug in a different implementation of any part of the system with very few modifications.

Our deployment will be partitioned into three tiers:

The business logic tier will consist of multiple Enterprise JavaBeans, running under the hood of an EJB container/server. These will be reusable components

Go back to the first page for a quick link to buy this book online!

J2EE in the Real World: Designing an E-Commerce Object Model 349

Figure 12.5 Viewing and modifying a quote.

Figure 12.6 Making a purchase.

Go back to the first page for a quick link to buy this book online!

350 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

that are independent of any user interface logic. We should be able to, for example, take our business tier and port it to a different presentation tier (such as an independent laptop) with no modifications. Our business tier will be made up of persistent entity bean objects that represent data being modified, as well as session beans to provide application rules for interacting with that data.

The presentation tier will involve one or more Web servers, each responsible for interacting with the end user. The presentation tier displays the requested information in HTML to the end user; it also reads in and interprets the user’s selections and makes invocations to the business tier’s enterprise beans. The implementation of the presentation tier will use Java servlets—networked objects that know how to interact with a user on a specific protocol. We’ll see how servlets work a bit later. And, of course, our choice of using servlets could easily be replaced with a different presentation package.

The data tier is where our permanent data stores reside. The databases aggregate all persistent information related to the e-commerce site.

Object Model for the Business Logic Tier

Let’s begin designing our EJB object model. To fulfill Jasmine’s requirements, we make abstractions in our business’s object model.

Products

First, we will need to model the products that Jasmine is selling. A product could be a motherboard, a monitor, or any other component. Products should be persistent parts of the deployment that last forever. Our product abstractions should represent the following data:

■■The unique product ID

■■The product name

■■A description of the product

■■The base price of the product (indicating the price of the product, with no discounts or taxes applied)

Jasmine should be able to add and delete products from the system using a maintenance tool. Because products are permanent, persistent parts of the system, they are best modeled as entity beans. Our Product entity bean should have methods to get and set the above fields.

In fact, in Chapter 9, we wrote this exact bean to illustrate container-managed persistent entity beans. That Product bean fits this purpose quite well, and we’ll reuse it in our deployment.

Go back to the first page for a quick link to buy this book online!