Persistence is a higher-level abstraction above JDBC. The persistence layer maps objects to database storage so that they can be queried, loaded, updated, or removed without having to go through a verbose（adj.詳細的, 冗長的） API such as JDBC. In older versions of EJB, persistence was part of the EJB platform. Starting with EJB 3.0, persistence has been spun off to its own specification, called the Java Persistence API.
The Java Persistence API defines a way to map regular, plain old Java objects (sometimes referred to as POJOs) to a database. These plain Java objects are called entity beans. Entity beans are like any other Java class, except that they have been mapped, using Java Persistence metadata, to a database. Therefore, they may be inserted and loaded from a database without the developer writing any JDBC connection code or reading from result sets. The Java Persistence API also defines a query language that has features that parallel those in SQL, but is tailored（adj.剪裁講究的） to work with Java objects rather than a raw relational schema.
In the EJB 2.1 specification, entity beans were very "heavyweight" and dependent on the application server and the entire Java EE runtime environment. In Java Persistence, entity beans are regular Java objects that are managed by a persistence service. Unlike their EJB 2.1 counterparts, entities in Java Persistence are not required to implement any special spec-defined interfaces or classes. Another weakness of the older specification was that it left individual vendors（n.賣主） to decide how an object should be mapped to a particular database representation. This made EJB 2.1 entity beans mostly nonportable between vendors. The new Java Persistence specification defines a complete object to relational mapping (ORM) so that entity beans can be ported easily from vendor to vendor. Furthermore, because entity beans are now plain Java objects, they are not just portable between application servers; they can be used in regular Java applications outside of an application server and can even be used to transfer data between a client and a server. This makes designs simpler and more compact.
In addition to supporting RMI-based distributed business objects, Enterprise JavaBeans supports asynchronous messaging. An asynchronous messaging system allows two or more applications to exchange information in the form of messages. A message, in this case, is a self-contained package of business data and network routing headers. The business data contained in a message can be anythingdepending on the business scenarioand usually contains information about some business transaction. In enterprise systems, messages inform an application of some event or occurrence in another system.
Asynchronous messages may be transmitted from one application to another on a network using message-oriented middleware (MOM). MOM products ensure that messages are properly distributed among applications. In addition, MOM usually provides fault-tolerance, load-balancing, scalability, and transactional support for enterprises that need to reliably exchange large quantities of messages. MOM vendors use different message formats and network protocols for exchanging messages, but the basic semantics（n.[語]語義學） are the same. An API is used to create a message, give it a payload (application data), assign it routing information, and then send the message. The same API is used to receive messages produced by other applications.
In modern enterprise-messaging systems, applications exchange messages through virtual channels called destinations. When you send a message, it's addressed to a destination, not to a specific application. Any application that subscribes to or registers an interest in that destination may receive that message. In this way, the applications that receive messages and those that send messages are decoupled. Senders and receivers are not bound to each other in any way and may send and receive messages as they see fit.
現在應用的消息機制不是application -> application，而是application -> destination -> application。採用發佈-訂閱方式。
Enterprise JavaBeans integrates the functionality of MOM into its component model. This integration extends the EJB platform so that it supports both RMI and asynchronous messaging. EJB 3.0 supports asynchronous messaging through the Java Message Service (JMS) and a new component called the message-driven bean. In addition to JMS, message-driven beans can support other synchronous and asynchronous messaging systems.
Each MOM vendor implements its own networking protocols, routing, and administration facilities, but the basic semantics of the developer API provided by different MOMs are the same. It's this similarity in APIs that makes the Java Message Service (JMS) possible.
消息服務可以有不同的實現方式（包括網絡協議、路由和一些相應的管理設施），相同的是消息服務的調用接口。
JMS is a vendor-agnostic（n.[哲]不可知論者） Java API that can be used with many different MOM vendors. JMS is very similar to JDBC in that an application developer can reuse the same API to access many different systems. If a vendor provides a compliant（adj.順從的, 適應的） service provider for JMS, the JMS API can be used to send messages to and receive messages from that vendor. For example, you can use the same JMS API to send messages with Progress's SonicMQ as with IBM's MQSeries.
Enterprise JavaBeans 2.0 introduced a new kind of component, called a message-driven bean, which is a kind of standard JMS bean. It can receive and send asynchronous JMS messages, and can easily interact with other EJBs.
EJB 2.1 extended the programming model of the message-driven bean beyond JMS to any messaging system. While EJB vendors must continue to support JMS-based message-driven beans (JMS-MDBs), other types of messaging systems are also allowed. It's likely that vendors will develop new message-driven bean types to support all kinds of protocols, including SMTP for email, SNMP for device control, peer-to-peer protocols (e.g., BEEP and Jabber), and many other open and proprietary messaging systems. In addition, the message-driven bean has become an elegant（adj.文雅的, 端莊的, 雅緻的, <口>上品的, 第一流的） option for serving connections to legacy（n.遺贈(物), 遺產(祖先傳下來)） transaction processing systems like CICS, IMS, openUTM, and others.
EJB2.0的MDB支持基於JMS的消息，EJB2.1的MDB在此基礎上進行了擴展，使得MDB支持更多（任何）的消息系統，本質就是支持更多的網絡協議。這也使得MDB成爲和一些遺留系統交互的優雅選擇。更重大的意義，基於MDB一種新的輕便靈活的JAVA連接器結構JCA1.5應運而生，對於一個企業級應用系統組件間交互方式的一種革新。
The expansion of message-driven beans in EJB 2.1 to other protocols was made possible by the new Java EE Connector Architecture (JCA 1.5), which defines a portable programming model for interfacing with enterprise information systems. The use of JCA in Java EE is analogous（adj.類似的, 相似的, 可比擬的） to the use of USB in computer hardware. A computer that supports USB can interface with just about any USB-compliant device. Similarly, an EJB 3.0 container that supports JCA 1.5 can interface with any JCA 1.5-compliant resource. For example, if Vendor XYZ creates a new message-driven bean component for its proprietary messaging system based on JCA 1.5, that component will be portable across all EJB 2.1 and higher-compliant servers. Figure 1-1 illustrates how a JCA connector for a messaging system integrates with EJB.
Message-driven beans in EJB 3.0 allow other applications to send messages that can be captured and processed by the EJB application. This feature allows EJB applications to better integrate with legacy and other proprietary systems.
（bandy ，vt.打來打去, 交換, 傳播） about quite a bit, arriving at a concrete definition is difficult because web services is, at the highest level, not specific to any particular technology or platform. It's often defined in fairly abstract terms, like "a substrate for building distributed applications using software running on different operating systems and devices" or "self-contained, self-describing, modular applications that can be published, located, and invoked across the Web." Of course, these quotes are taken out of context, but that's the essential point: you need some kind of context to define web services. Here's my definition of web services that has meaning in the context of Java EE, EJB, .NET, and most other web services platforms
Tim Ewald, "The Web Services Idea," July 12, 2002, Microsoft.com (http://msdn.microsoft.com/webservices/understanding/readme/default.asp).
Doug Tidwell, "Web servicesthe Web's next revolution," November 29, 2000, IBM.com (http://www-105.ibm.com/developerworks/education.nsf/webservices-onlinecourse-bytitle/BA84142372686CFB862569A400601C18?OpenDocument).
Web services are network applications that use SOAP and WSDL to exchange information in the form of XML documents.
To understand this definition, you need to understand SOAP and WSDL. Here are brief definitions of these terms:
SOAP 1.1
Simple Object Access Protocol (SOAP) is an XML grammar, developed by Microsoft, IBM, and others, that is currently under the auspices（auspices n.由...主辦及贊助） of the W3C. It's an application protocol used in both RPC and asynchronous messaging. SOAP is very flexible and extensible and, unlike its predecessors (DCE RPC, CORBA IIOP, Java RMI-JRMP, and DCOM), it's been endorsed and adopted by just about every major vendor. (If you're not familiar with XML, see Java and XML or XML in a Nutshell, both from O'Reilly.)
WSDL 1.1
The Web Service Description Language (WSDL) is another XML grammar, developed by Microsoft and IBM under the auspices of the W3C. It is an XML-based Interface Definition Language (IDL) that can be used to describe web services, including the kind of message format expected, the Internet protocol used, and the Internet address of the web service.
Web services are truly platform-independent. Although Java RMI and CORBA IIOP also claim to be platform-independent, in fact these older technologies require their own platforms. To use Java RMI, you need a Java virtual machine and the Java programming language; a program written in Visual Basic or C++ can't interact with a Java program using RMI. CORBA IIOP is also restrictive, because the IIOP protocol usually requires an elaborate infrastructure like a CORBA ORB, which limits developers to those few vendors that support CORBA or to the Java environment (which includes built-in support for CORBA IIOP).
Web services, on the other hand, are not tied to a specific platform like the JVM or to a technology infrastructure like CORBA because they focus on the protocols used to exchange messagesSOAP and WSDLand not on the implementation that supports those protocols. In other words, you can build web services on any platform using any programming language any way you please.
EJB 3.0 allows enterprise beans to be exposed as web services so that their methods can be invoked by other J2EE applications as well as applications written in other programming languages on a variety of platforms. Web services in EJB 3.0 support both RPC-style and document-style messaging. Support for web services is based on a web service API: JAX-WS. Web services and the use of JAX-WS are covered in detail in Chapters 18 and 19.
To make things easier and more fun, we discuss all the concepts in this book in the context of an imaginary business, a cruise line called Titan Cruises. A cruise line makes a particularly interesting example because it incorporates several different businesses: it has ship cabins that are similar to hotel rooms; it serves meals like a restaurant does; it offers various recreational opportunities; and it 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（adj.地理學的, 地理的） dispersed（adj.被驅散的, 被分散的, 散佈的）. Commercial travel agents, for example, who need to book passage on Titan ships need to access the reservation（n.保留, (旅館房間等)預定, 預約） system. Supporting manypossibly hundredsof travel agents requires a robust transactional system to ensure 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 exercise will give us an opportunity to develop Ship, Cabin, TravelAgent, ProcessPayment, and other enterprise and entity beans. 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.
To develop business objects using EJB and Java Persistence, you have to understand the life cycles and architectures of EJB components and entity bean objects. This means understanding the concepts of how EJB components are managed and made available as distributed objects. Developing an understanding of the EJB and Java Persistence architectures, and how they fit into the larger Java EE environment, is the focus of the next two chapters.