In 1997, Sun Microsystems was developing the most promising standard for server-side components called Enterprise JavaBeans. Sun offered some key advantages. First, Sun was respected and was known for working with vendors to define Java-based and vendor-agnostic APls for common services. Sun had a habit of adopting the best ideas in the industry and then making the Java implementation an open standard-usually successfully. The Java database connectivity APl, called JDBC, was a perfect example. Based largely or Microsofts own ODBC, JDBC offered vendors a more flexible model for plug in their own database access drivers. In addition, developers found the JDBC API much easier to work with. Sun was doing the same thing directory technologies like the JavaMail TM API and the Java Naming and Interface (JNDI). These technologies were still being defined, but the collaboration among vendors was encouraging and the openness of the APls was attractive Although CORBA offered an open standard, it attempted to standardize very low-level facilities like security and transactions. Vendors could not justify rewriting existing products such as TUXEDO and CiCs to the CORBa standards EJB got around that problem by saying it doesn't matter how you implement the low-level services; all that matters is all the facilities be applied to the components according to the specification-a much more palatable solution for existing and prospective CTM vendors. In addition, the Java language offered some pretty enticing advantages, not all of them purely technical. First, Java was a hot and sexy technology and simply making your product Java-compatible seemed to boost your exposure in the market. Java also offered some very attractive technical benefits. Java was more or less platform independent. A component model defined in the Java language would have definite marketing and technical benefits As it turned out, Sun had not been idle after it announced Enterprise Java Beans Sun's engineers had been working with several leading vendors to define a flexible and open standard to which vendors could easily adapt their existing products. This was a tall order because vendors had different kinds of servers including web servers, database servers, relational database servers, application servers, and early CTMs. It's likely that no one wanted to sacrifice their architecture for the common good, but eventually the vendors agreed on a model that was flexible enough to accommodate different implementations yet solid enough to support real mission-critical development. In December of 1997, Sun Microsystems released the first draft specification of Enterprise JavaBeans, EJB 1.0, and vendors have been flocking to the server-side component model ever
DRAFT, 10/21/017/6/20016/9/2001 22 In 1997, Sun Microsystems was developing the most promising standard for server-side components called Enterprise JavaBeans. Sun offered some key advantages. First, Sun was respected and was known for working with vendors to define Java-based and vendor-agnostic APIs for common services. Sun had a habit of adopting the best ideas in the industry and then making the Java implementation an open standard—usually successfully. The Java database connectivity API, called JDBC, was a perfect example. Based largely on Microsoft’s own ODBC, JDBC offered vendors a more flexible model for plugging in their own database access drivers. In addition, developers found the JDBC API much easier to work with. Sun was doing the same thing in its newer technologies like the JavaMail™ API and the Java Naming and Directory Interface (JNDI). These technologies were still being defined, but the collaboration among vendors was encouraging and the openness of the APIs was attractive. Although CORBA offered an open standard, it attempted to standardize very low-level facilities like security and transactions. Vendors could not justify rewriting existing products such as TUXEDO and CICS to the CORBA standards. EJB got around that problem by saying it doesn’t matter how you implement the low-level services; all that matters is all the facilities be applied to the components according to the specification—a much more palatable solution for existing and prospective CTM vendors. In addition, the Java language offered some pretty enticing advantages, not all of them purely technical. First, Java was a hot and sexy technology and simply making your product Java-compatible seemed to boost your exposure in the market. Java also offered some very attractive technical benefits. Java was more or less platform independent. A component model defined in the Java language would have definite marketing and technical benefits. As it turned out, Sun had not been idle after it announced Enterprise JavaBeans. Sun’s engineers had been working with several leading vendors to define a flexible and open standard to which vendors could easily adapt their existing products. This was a tall order because vendors had different kinds of servers including web servers, database servers, relational database servers, application servers, and early CTMs. It’s likely that no one wanted to sacrifice their architecture for the common good, but eventually the vendors agreed on a model that was flexible enough to accommodate different implementations yet solid enough to support real mission-critical development. In December of 1997, Sun Microsystems released the first draft specification of Enterprise JavaBeans, EJB 1.0, and vendors have been flocking to the server-side component model ever since
Benefits of a Standard Server-Side Component ode So what does it mean to be a standard server-side component model? Quite simply, it means that you can develop business objects using the Enterpri JavaBeans(EJB)component model and expect them to work in any Ctm that supports the complete EJB specification. This is a pretty powerful statement because it largely eliminates the biggest problem faced by potential customers of CORBA-based CTM products: fear of vendor"lock-in. With a standard server side component model, customers can commit to using an EJB-compliant CTM ith the knowledge that they can migrate to a better CTm if one becomes available. Obviously, care must be taken when using proprietary extensions developed by vendors, but this is nothing new. Even in relational database industry-which has been using the SQL standard for a couple of decades- optional proprietary extensions abound Having a standard server-side component model has benefits beyond implementation independence. A standard component model provides a vehicle for growth in the third- party products. If numerous vendors support EJB, then creating add-on products and component libraries is more attractive to software vendors. The IT industry has seen this type of cottage industry grow up around other standards like SQL, where hundreds of add-on products can be purchased systems whose data is stored in databases. Report generating tools and data warehouse products are typica examples. The GUl component industry has seen the growth of its own third party products. A healthy market for component libraries already exists for GUI component models like Microsofts ActiveX and Suns original Java Beans There are many examples of third-party product for Enterprise JavaBeans today Add-on products that provide services to EJB-compliant systems like credit card processing, legacy database access, and other business services have been introduced. These types of products make development of EJB systems simpler and faster than the alternatives, making the EJB component model attractive to corporate IS and server vendors alike. The industry has market grow for education. web content management. collaboration and other areas Titan Cruises: An Imaginary business fun we will concepts in this book in the context of one imaginary business, a cruise line called Titan. A cruise line makes a particularly interesting example because it incorporates several different businesses: a cruise has cabins that are similar to
DRAFT, 10/21/017/6/20016/9/2001 23 Benefits of a Standard Server-Side Component Model So what does it mean to be a standard server-side component model? Quite simply, it means that you can develop business objects using the Enterprise JavaBeans (EJB) component model and expect them to work in any CTM that supports the complete EJB specification. This is a pretty powerful statement because it largely eliminates the biggest problem faced by potential customers of CORBA-based CTM products: fear of vendor “lock-in.” With a standard serverside component model, customers can commit to using an EJB-compliant CTM with the knowledge that they can migrate to a better CTM if one becomes available. Obviously, care must be taken when using proprietary extensions developed by vendors, but this is nothing new. Even in relational database industry— which has been using the SQL standard for a couple of decades— optional proprietary extensions abound. Having a standard server-side component model has benefits beyond implementation independence. A standard component model provides a vehicle for growth in the third- party products. If numerous vendors support EJB, then creating add-on products and component libraries is more attractive to software vendors. The IT industry has seen this type of cottage industry grow up around other standards like SQL, where hundreds of add-on products can be purchased to enhance business systems whose data is stored in SQL-compliant relational databases. Report generating tools and data warehouse products are typical examples. The GUI component industry has seen the growth of its own thirdparty products. A healthy market for component libraries already exists for GUI component models like Microsoft’s ActiveX and Sun’s original JavaBeans component models. There are many examples of third-party product for Enterprise JavaBeans today Add-on products that provide services to EJB-compliant systems like credit card processing, legacy database access, and other business services have been introduced. These types of products make development of EJB systems simpler and faster than the alternatives, making the EJB component model attractive to corporate IS and server vendors alike. The industry has market grow for prepackaged EJB components in several domains including sales, finance, education, web content management, collaboration and other areas. Titan Cruises: An Imaginary Business To make things a little easier, and more fun, we will attempt to discuss all the concepts in this book in the context of one imaginary business, a cruise line called Titan. A cruise line makes a particularly interesting example because it incorporates several different businesses: a cruise has cabins that are similar to
otel rooms, serves meals like a restaurant, offers various recreational opportunities, and needs to interact with other travel busnesses This type of business is a good candidate for a distributed object system because many of the systems users are geographically dispersed. Commercial travel agents, for example, who need to book passage on Titan ships, will need access the reservation system Supporting many-possibly hundreds-of travel agents requires a robust transactional system to ensure that agents have access and reservations are completed properly Throughout this book we will build a fairly simple slice of Titan's EJB system that focuses on the process of making a reservation for a cruise. This will give us an opportunity to develop enterprise beans like Ship, Cabin, TravelAgent ProcessPayment, and so forth. In the process, you will need to create relational database tables for persisting data used in the example. It is assumed that you are familiar with relational database management systems and that you can create tables according to the SQL statements provided. EJB can be used with any kind of database or legacy application, but relational databases seem to be the most commonly understood database so we have chosen this as the persis tence layer. What's Next? In order to develop business objects using EJB, you have to understand the life cycle and architecture of EJB components. This means understanding onceptually how EJBs components are managed and made available as distributed objects. Developing an understanding of the EJB architecture is the focus of the next two chapters
DRAFT, 10/21/017/6/20016/9/2001 24 hotel rooms, serves meals like a restaurant, offers various recreational opportunities, and needs to interact with other travel businesses. This type of business is a good candidate for a distributed object system because many of the system’s users are geographically dispersed. Commercial travel agents, for example, who need to book passage on Titan ships, will need to access the reservation system. Supporting many—possibly hundreds—of travel agents requires a robust transactional system to ensure that agents have access and reservations are completed properly. Throughout this book we will build a fairly simple slice of Titan’s EJB system that focuses on the process of making a reservation for a cruise. This will give us an opportunity to develop enterprise beans like Ship, Cabin, TravelAgent, ProcessPayment, and so forth. In the process, you will need to create relational database tables for persisting data used in the example. It is assumed that you are familiar with relational database management systems and that you can create tables according to the SQL statements provided. EJB can be used with any kind of database or legacy application, but relational databases seem to be the most commonly understood database so we have chosen this as the persistence layer. What’s Next? In order to develop business objects using EJB, you have to understand the life cycle and architecture of EJB components. This means understanding conceptually how EJB’s components are managed and made available as distributed objects. Developing an understanding of the EJB architecture is the focus of the next two chapters
Architectural overview As you learned in Chapter 1, Enterprise JavaBeans is a component model for component transaction monitors, the most advanced type of business application server available today. To effectively use Enterprise JavaBeans, you need to understand the eJB architecture, so this book includes two chapters on he subject. This chapter explores the core of EJB: how enterprise beans distributed as business objects. Chapter 3 explores the services and resor management techniques supported by EJB To be truly versatile, the EJB component design had to be smart. For application ng enterprise beans is simple, requiring litt in the complex system-level issues that often plague three-tier development efforts. While EJB makes it easy for application developers, it also provides ystem developers (the people who write EJB servers) with a great deal of flexibility in how they support the EJB specification The similarities among different component transaction monitors(CTMs)allow the EJB abstraction to be a standard component model for all of them. Each vendor's CTM is implemented differently, but they all support the same primary services and similar resource management techniques. The primary services and resource management techniques are covered in more detail in Chapter 3, but some of the infrastructure for supporting them is addressed in this chap Copyright(c)2001 OReilly Associates
DRAFT, 10/21/017/6/2001 Copyright (c) 2001 O'Reilly & Associates 1 2 Architectural Overview As you learned in Chapter 1, Enterprise JavaBeans is a component model for component transaction monitors, the most advanced type of business application server available today. To effectively use Enterprise JavaBeans, you need to understand the EJB architecture, so this book includes two chapters on the subject. This chapter explores the core of EJB: how enterprise beans are distributed as business objects. Chapter 3 explores the services and resource management techniques supported by EJB. To be truly versatile, the EJB component design had to be smart. For application developers, assembling enterprise beans is simple, requiring little or no expertise in the complex system-level issues that often plague three-tier development efforts. While EJB makes it easy for application developers, it also provides system developers (the people who write EJB servers) with a great deal of flexibility in how they support the EJB specification. The similarities among different component transaction monitors (CTMs) allow the EJB abstraction to be a standard component model for all of them. Each vendor’s CTM is implemented differently, but they all support the same primary services and similar resource management techniques. The primary services and resource management techniques are covered in more detail in Chapter 3, but some of the infrastructure for supporting them is addressed in this chapter
The Enterprise Bean Component Enterprise Java Beans server-side components come in three fundamentally different types: entity, session, and message-driven beans. Both session and entity beans are RMI based server-side components that are accessed using distributed object protocols. The message-driven bean, which is new to EJB 2.0, is an asynchronous server-side component that responds to JMS asyncrhonous a good rule of thumb is that entity beans model business concepts that can be expressed as nouns. For example, an entity bean might represent a customer, a piece of equipment, an item in inventory, or beans model real-world objects; these objects are usually persistent records in ome kind of database. Our hypothetical cruise line will need entity beans that mers, ship Session beans are an extension of the client application and are responsible for managing processes or tasks. A Ship bean provides methods for doing things directly to a ship but doesn't say anything about the context under which those actions are taken. Booking passengers on the ship requires that we use a Ship bean, but also requires a lot of things that have nothing to do with the Ship itself: we'll need to know about passengers, ticket rates, schedules, and so on. A session bean is responsible for this kind of coordination. Session beans tend to manage particular kinds of activities, for example, the act of making a reservation ey have a lot to do with the relationships between different enterprise beans A TravelAgent session bean, for example, might make use of a Cruise, a Cabin, and a Customer-all entity beans-to make a reservation Similarly, the message-driven beans in EJB 2.0 are responsible for coordinating tasks involving other session and entity beans. The major difference between a message-driven bean and a session bean is how they are accessed. while a session bean provides a remote interface that defines which methods can be invoked a message-driven bean does not. Instead the message driven bean subscribes or listens for specific asynchronous messages to which it respond by processing the message and managing the activities of other beans in response to those messages. For example, a TravelAgent message-driven bean would receive to a asynchronous messages--perhaps from a legacy reservation ystem--from which it would coordinate the interactions of the Cruise, Cabin, and Customer beans to make a reservation The activity that a session or message-driven bean represents is fundamentally transient: you start making a reservation, you do a bunch of work, and then it's finished. The session and message-driven beans do not represent things in the database. Obviously, session and message-driven beans have lots of side effects on the database: in the process of making a reservation, you might create a new Reservation by assigning a Customer to a particular Cabin on a particular Ship All of these changes would be reflected in the database by actions on the Copyright(c)2001 OReilly Associates
DRAFT, 10/21/017/6/2001 2 Copyright (c) 2001 O'Reilly & Associates The Enterprise Bean Component Enterprise JavaBeans server-side components come in three fundamentally different types: entity, session, and message-driven beans. Both session and entity beans are RMI based server-side components that are accessed using distributed object protocols. The message-driven bean, which is new to EJB 2.0, is an asynchronous server-side component that responds to JMS asyncrhonous messages. A good rule of thumb is that entity beans model business concepts that can be expressed as nouns. For example, an entity bean might represent a customer, a piece of equipment, an item in inventory, or even a place. In other words, entity beans model real-world objects; these objects are usually persistent records in some kind of database. Our hypothetical cruise line will need entity beans that represent cabins, customers, ships, etc. Session beans are an extension of the client application and are responsible for managing processes or tasks. A Ship bean provides methods for doing things directly to a ship but doesn’t say anything about the context under which those actions are taken. Booking passengers on the ship requires that we use a Ship bean, but also requires a lot of things that have nothing to do with the Ship itself: we’ll need to know about passengers, ticket rates, schedules, and so on. A session bean is responsible for this kind of coordination. Session beans tend to manage particular kinds of activities, for example, the act of making a reservation. They have a lot to do with the relationships between different enterprise beans. A TravelAgent session bean, for example, might make use of a Cruise, a Cabin, and a Customer—all entity beans—to make a reservation. Similarly, the message-driven beans in EJB 2.0 are responsible for coordinating tasks involving other session and entity beans. The major difference between a message-driven bean and a session bean is how they are accessed. While a session bean provides a remote interface that defines which methods can be invoked, a message-driven bean does not. Instead, the message driven bean subscribes or listens for specific asynchronous messages to which it responds by processing the message and managing the activities of other beans in response to those messages. For example, a TravelAgent message-driven bean would receive to a asynchronous messages—perhaps from a legacy reservation system—from which it would coordinate the interactions of the Cruise, Cabin, and Customer beans to make a reservation. The activity that a session or message-driven bean represents is fundamentally transient: you start making a reservation, you do a bunch of work, and then it’s finished. The session and message-driven beans do not represent things in the database. Obviously, session and message-driven beans have lots of side effects on the database: in the process of making a reservation, you might create a new Reservation by assigning a Customer to a particular Cabin on a particular Ship. All of these changes would be reflected in the database by actions on the