《J2EE技术》课程教学资源（书籍文献）EJB3 In Action（Debu Panda，Reza Rahman，Derek Lane）

CHAPTER 1 What's what in elb 3 metadata annotations,which are property settings that mark a piece of code,such as a class or method,as having particular attributes.This is a declarative style of programming,in which the developer specifies what should be done and the sys- tem adds the code to do it. In EJB,metadata annotations dramatically simplify development and testing of applications,without having to depend on an exteral file. It allows developers to declaratively add services to EJB components as and when they need.As figure 1.3 depicts.an annotation transforms a simple PolO into an EJB As you'll learn,annotations are used extensively throughout EJB,and not only to specify services.For example,an annotation can be used to specify the type of the EJB component. Although it's sometimes easy to forget,enterprise applications have one more thing in common with a house.Both are meant to last,often much longer than anyone expects.Being able to support high-performance,fault-tolerant,scalable applications isan up-front concern for the EJBplatform instead of being an after thought.Not only will you be writing good server-side applications faster,but also you can expect your platform to grow with the success of your application.When the need to support a larger number of users becomes a reality,you won't have to rewrite your code.Thankfully these concerns are taken care of by EJB container vendors.You'll be able to count on moving your application to a distributed,clus- tered server farm by doing nothing more than a bit of configuration. Last,but certainly not least,with a world that's crazy about service-oriented architecture (SOA)and interoperability,EJB lets you turn your application into a web services powerhouse with ease when you need to. The EJB framework is a standard Java technology with an open specification.If it catches your fancy,you can check out the real deal on the Java Community Proc- ess (JCP)website at www.jcp.org/en/jsr/detail?id=220.EJB is supported by a large number of companies and open source groups with competing but compatible implementations.On the one hand,this indicates that a large group of people will work hard to keep EJB competitive.On the other hand,the ease of portability Figure 1.3 Bs are regular Java objects d using POJO Annotation EJB

8 CHAPTER 1 What’s what in EJB 3 metadata annotations, which are property settings that mark a piece of code, such as a class or method, as having particular attributes. This is a declarative style of programming, in which the developer specifies what should be done and the sys￾tem adds the code to do it. In EJB, metadata annotations dramatically simplify development and testing of applications, without having to depend on an external XML configuration file. It allows developers to declaratively add services to EJB components as and when they need. As figure 1.3 depicts, an annotation transforms a simple POJO into an EJB. As you’ll learn, annotations are used extensively throughout EJB, and not only to specify services. For example, an annotation can be used to specify the type of the EJB component. Although it’s sometimes easy to forget, enterprise applications have one more thing in common with a house. Both are meant to last, often much longer than anyone expects. Being able to support high-performance, fault-tolerant, scalable applications is an up-front concern for the EJB platform instead of being an after￾thought. Not only will you be writing good server-side applications faster, but also you can expect your platform to grow with the success of your application. When the need to support a larger number of users becomes a reality, you won’t have to rewrite your code. Thankfully these concerns are taken care of by EJB container vendors. You’ll be able to count on moving your application to a distributed, clus￾tered server farm by doing nothing more than a bit of configuration. Last, but certainly not least, with a world that’s crazy about service-oriented architecture (SOA) and interoperability, EJB lets you turn your application into a web services powerhouse with ease when you need to. The EJB framework is a standard Java technology with an open specification. If it catches your fancy, you can check out the real deal on the Java Community Proc￾ess (JCP) website at www.jcp.org/en/jsr/detail?id=220. EJB is supported by a large number of companies and open source groups with competing but compatible implementations. On the one hand, this indicates that a large group of people will work hard to keep EJB competitive. On the other hand, the ease of portability Figure 1.3 EJBs are regular Java objects that may be configured using metadata annotations

EJB overview 9 means that you get to choose what implementation suits you best,making your application portable across EJB containers from different vendors. Now that we've provided a high-level introduction to EJB,let's turn our atten- tion to how EJB can be used to build layered applications. 1.1.3 Layered architectures and EJB Most enterprise applications contain a large number of components.Enterprise applications are designed to solve a unique type of customer problem,but they share many common characteristics.For example,most enterprise applications have some kind of user interface and they implement business processes,model a problem domain,and save data into a database.Because of these commonalities, you can a follow a common architecture or design principle for building enter- prise applications known as patterns. For server-side development,the dominant pattern is layered architectures.In a layered architecture,components are grouped into tiers.Each tier in the applica- tion has a well-defined purpose,sort of like a profession but more like a section of a factory assembly line.Each section of the assembly line performs its designated task and passes the remaining work down the line.In layered architectures,each layer delegates work to a layer underneath it. EJB allows you to build applications using two different layered architectures: the traditional four-tier architecture and domain-driven design(DDD).Let's take a brief look at each of these architectures. Traditional four-tier layered architecture Figure 1.4 shows the traditional four-tier server architecture.This architecture is pretty intuitive and enjoys a wide popularity.In this architecture,the presentation layer is responsible for rendering the graphical user interface (GUI)and handling user input.The presentation layer passes down each request for application functionality to the business logic laver.The business logic laver is the heart of the application and contains workflow and processing logic.In other words,business logic layer components model distinct actions or processes the application can perform,such as billing,searching,ordering,and user account maintenance. The business logic layer retrieves data from and saves data into the database by utilizing the persistence tier.The persistence layer provides a high-level object-ori- ented (OO)abstraction over the database layer.The database layer typically con- sists of a relational database management system(RDBMS)like Oracle,DB2,or SOL Server

EJB overview 9 means that you get to choose what implementation suits you best, making your application portable across EJB containers from different vendors. Now that we’ve provided a high-level introduction to EJB, let’s turn our atten￾tion to how EJB can be used to build layered applications. 1.1.3 Layered architectures and EJB Most enterprise applications contain a large number of components. Enterprise applications are designed to solve a unique type of customer problem, but they share many common characteristics. For example, most enterprise applications have some kind of user interface and they implement business processes, model a problem domain, and save data into a database. Because of these commonalities, you can a follow a common architecture or design principle for building enter￾prise applications known as patterns. For server-side development, the dominant pattern is layered architectures. In a layered architecture, components are grouped into tiers. Each tier in the applica￾tion has a well-defined purpose, sort of like a profession but more like a section of a factory assembly line. Each section of the assembly line performs its designated task and passes the remaining work down the line. In layered architectures, each layer delegates work to a layer underneath it. EJB allows you to build applications using two different layered architectures: the traditional four-tier architecture and domain-driven design (DDD). Let’s take a brief look at each of these architectures. Traditional four-tier layered architecture Figure 1.4 shows the traditional four-tier server architecture. This architecture is pretty intuitive and enjoys a wide popularity. In this architecture, the presentation layer is responsible for rendering the graphical user interface (GUI) and handling user input. The presentation layer passes down each request for application functionality to the business logic layer. The business logic layer is the heart of the application and contains workflow and processing logic. In other words, business logic layer components model distinct actions or processes the application can perform, such as billing, searching, ordering, and user account maintenance. The business logic layer retrieves data from and saves data into the database by utilizing the persistence tier. The persistence layer provides a high-level object-ori￾ented (OO) abstraction over the database layer. The database layer typically con￾sists of a relational database management system (RDBMS) like Oracle, DB2, or SQL Server

10 CHAPTER 1 What's what in elb 3 Presentation layer Business logic layer Figure 1.4 ona I enterp Persistence layer ntation laver is the actual user interface and can either be a browser or a top appli 2)he istence laver deals with inte Database layer with the database.4)The database layer consists of a rel nal dat base su the persistent object EJB is obviously not a presentation layer technology.EJB is all about robust sup port for implementing the business logic and persistence layers.Figure 1.5 shows how EJB supports these layers via its services. In section 1.3 we'll go into more detail on EJB services.And in section 1.2 we'll explore EJB bean types.For now,just note that the bean types called session beans and message-driven beans (MDBs)reside in and use the services in the Security Interceptors Business logic layer Thread-Safety Web Services State Mgt Transactions Messaging Figure 1.5 Note tat independent of the other,so Persistence layer most part tre for your application.You'll se

10 CHAPTER 1 What’s what in EJB 3 EJB is obviously not a presentation layer technology. EJB is all about robust sup￾port for implementing the business logic and persistence layers. Figure 1.5 shows how EJB supports these layers via its services. In section 1.3 we’ll go into more detail on EJB services. And in section 1.2 we’ll explore EJB bean types. For now, just note that the bean types called session beans and message-driven beans (MDBs) reside in and use the services in the Figure 1.4 Most traditional enterprise applications have at least four layers. 1) The presentation layer is the actual user interface and can either be a browser or a desktop application. 2) The business logic layer defines the business rules. 3) The persistence layer deals with interactions with the database. 4) The database layer consists of a relational database such as Oracle that stores the persistent objects. Figure 1.5 The component services offered by EJB 3 at each supported application layer. Note that each service is independent of the other, so you are for the most part free to pick the features important for your application. You’ll learn more about services in section 1.3

EJB overview business logic tier,and the bean types called entities reside in and use services in the persistence tier The traditional four-tier lavered architecture is not perfect One of the most common criticisms is that it undermines the oO ideal of modeling the business domain as objects that encapsulate both data and behavior.Because the tradi- tional architecture focuses on modeling business processes instead of the domain, the business logic tier tends to look more like a database-driven procedural appli- cation than an OO one.Since persistence-tier components are simple data hold- ers,they look a lot like database record definitions rather than first-class citizens of the OO world.As you'll see in the next section,DDD proposes an alternative architecture that attempts to solve these perceived problems. Domain-driven design The term domain-driven design(DDD)may be relatively new but the concept is no (see Domain-Driven Design:Tackling Complexity in the Heart of Software,by Eric Evans [Addison-Wesley Professional,20031).DDD emphasizes that domain objects should contain business logic and should not just be a dumb replica of database records.Domain objects are known as entities in EJB 3(see section 1.2 for a dis- cussion on entities).With DDD,the catalog and customer objects in a trading application are typical examples of entities,and they may contain business logic. In his excellent book Po/Os in Action (Manning,2006),author Chris Richard- son points out the problem in using domain objects just as a data holder. Some developers still view persistent objects simply as a means to get data in and out of the database and write procedural business logic. They develop what Fowler calls an"anemic domain model"....Just as anemic blood lacks vitality, anemic object models only superficially model the problem and consist of classes that implement little or no behavior. Yet,even though its value is clear,until this release of EJB,it was difficult to imple- ment DDD.Chris goes on to explain how EJB 2 encouraged procedural code theEB architecture,literature,and culture,which place great emp lopers write procedural-style code [because]it is encouraged by EJB components.EJB 2 components are not suitable for implementing an object model. Admittedly,implementing a real domain model was almost impossible with EJB 2 because beanswerenot POJOsand didnot supportmany features.suchas inher- itance and polymorphism.Chris specifically targets entity beans as the problem:

EJB overview 11 business logic tier, and the bean types called entities reside in and use services in the persistence tier. The traditional four-tier layered architecture is not perfect. One of the most common criticisms is that it undermines the OO ideal of modeling the business domain as objects that encapsulate both data and behavior. Because the tradi￾tional architecture focuses on modeling business processes instead of the domain, the business logic tier tends to look more like a database-driven procedural appli￾cation than an OO one. Since persistence-tier components are simple data hold￾ers, they look a lot like database record definitions rather than first-class citizens of the OO world. As you’ll see in the next section, DDD proposes an alternative architecture that attempts to solve these perceived problems. Domain-driven design The term domain-driven design (DDD) may be relatively new but the concept is not (see Domain-Driven Design: Tackling Complexity in the Heart of Software, by Eric Evans [Addison-Wesley Professional, 2003]). DDD emphasizes that domain objects should contain business logic and should not just be a dumb replica of database records. Domain objects are known as entities in EJB 3 (see section 1.2 for a dis￾cussion on entities). With DDD, the Catalog and Customer objects in a trading application are typical examples of entities, and they may contain business logic. In his excellent book POJOs in Action (Manning, 2006), author Chris Richard￾son points out the problem in using domain objects just as a data holder. Some developers still view persistent objects simply as a means to get data in and out of the database and write procedural business logic. They develop what Fowler calls an “anemic domain model”.... Just as anemic blood lacks vitality, anemic object models only superficially model the problem and consist of classes that implement little or no behavior. Yet, even though its value is clear, until this release of EJB, it was difficult to imple￾ment DDD. Chris goes on to explain how EJB 2 encouraged procedural code: … J2EE developers write procedural-style code [because] it is encouraged by the EJB architecture, literature, and culture, which place great emphasis on EJB components. EJB 2 components are not suitable for implementing an object model. Admittedly, implementing a real domain model was almost impossible with EJB 2 because beans were not POJOs and did not support many OO features. such as inher￾itance and polymorphism. Chris specifically targets entity beans as the problem:

12 CHAPTER 1 What's what in elb 3 beans,which are intended to make it extremely i sent business objects,have to use them to implemen a persistent object model The good news is that EJB 3 enables you to easily follow good object-oriented design or DDD.The entities defined by EJB 3 Java Persistence API (JPA)support oo features,such as inheritance or polymorphism.It's easy to implement a per sistence object model with the EJB 3 JPA.More importantly,you can easily add business logic to your entities,so that implementing a rich domain model with EJB 3 is a trivial task Note,though,that many people don't like adding complex business logic in the domain object itself and prefer creating a layer for procedural logic referred to as the service layer or application layer (see Patterns of Enterprise Application Architec- ture,by Martin Fowler [Addison-Wesley Professional,20021).The application layer is similar to the business logic layer of the traditional four-tier architecture,but is much thinner.Not surprisingly,you can use session beans to build the service layer.Whether you use the traditional four-tier architecture or a layered architec- ture with DDD,you can use entities to model domain objects,including modeling state and behavior.We'll discuss domain modeling with IPA entities in chapter 7. Despite its impressive services and vision,EJB3 is not the only act in town.You can combine various technologies to more or less match EIB services and infra- structure.For example,you could use Spring with other open source technologies such as Hibernate and Aspect]to build your application,so why choose EJB 3? Glad you asked.. 1.1.4 Why choose EJB 3? At the beginning of this chapter,we hinted at EJB's status as a pioneering technol- ogy.EJB is a groundbreaking technology that has raised the standards of server- side development.Just like Java itself,EJB has changed things in ways that are here to stay and inspired many innovations.In fact,up until a few years ago the only serious competition to EJB came from the Microsoft.NET framework. In this section,we'll point out a few of the compelling EJB 3 features that we feel certain will have this latest version at the top of your short list. Ease of use Thanks to the unwavering focus on ease of use,EIB 3 is probably the simplest server-side development platform around.The features that shine the bright est are POJO programming,annotations in favor of verbose XML,heavy use of

12 CHAPTER 1 What’s what in EJB 3 EJB 2 entity beans, which are intended to represent business objects, have numerous limitations that make it extremely difficult to use them to implement a persistent object model. The good news is that EJB 3 enables you to easily follow good object-oriented design or DDD. The entities defined by EJB 3 Java Persistence API (JPA) support OO features, such as inheritance or polymorphism. It’s easy to implement a per￾sistence object model with the EJB 3 JPA. More importantly, you can easily add business logic to your entities, so that implementing a rich domain model with EJB 3 is a trivial task. Note, though, that many people don’t like adding complex business logic in the domain object itself and prefer creating a layer for procedural logic referred to as the service layer or application layer (see Patterns of Enterprise Application Architec￾ture, by Martin Fowler [Addison-Wesley Professional, 2002]). The application layer is similar to the business logic layer of the traditional four-tier architecture, but is much thinner. Not surprisingly, you can use session beans to build the service layer. Whether you use the traditional four-tier architecture or a layered architec￾ture with DDD, you can use entities to model domain objects, including modeling state and behavior. We’ll discuss domain modeling with JPA entities in chapter 7. Despite its impressive services and vision, EJB 3 is not the only act in town. You can combine various technologies to more or less match EJB services and infra￾structure. For example, you could use Spring with other open source technologies such as Hibernate and AspectJ to build your application, so why choose EJB 3? Glad you asked... 1.1.4 Why choose EJB 3? At the beginning of this chapter, we hinted at EJB’s status as a pioneering technol￾ogy. EJB is a groundbreaking technology that has raised the standards of server￾side development. Just like Java itself, EJB has changed things in ways that are here to stay and inspired many innovations. In fact, up until a few years ago the only serious competition to EJB came from the Microsoft .NET framework. In this section, we’ll point out a few of the compelling EJB 3 features that we feel certain will have this latest version at the top of your short list. Ease of use Thanks to the unwavering focus on ease of use, EJB 3 is probably the simplest server-side development platform around. The features that shine the bright￾est are POJO programming, annotations in favor of verbose XML, heavy use of