1 / 39

Resource Management and Primary Services

Learn about resource management techniques and primary services in large business systems, including instance pooling, activation mechanism, and Java EE Connector Architecture.

loridennis
Download Presentation

Resource Management and Primary Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Resource Management and Primary Services

  2. Resource Management • A large business system with many users can easily have thousands or even millions of objects in use simultaneously. • As the number of interactions among these objects increases, concurrency and transactional concerns can degrade the system's response time and frustrate users. • EJB servers increase performance by synchronizing object interactions and sharing resources.

  3. Instance Pooling • The concept of pooling resources is not new. It's common to pool database connections so that the business objects in the system can share database access. • This trick reduces the number of database connections needed, which reduces resource consumption and increases throughput.

  4. Instance Pooling • Instance pooling is possible because clients never access beans directly. Therefore, there's no fundamental reason to keep a separate copy of each enterprise bean for each client. • The server can keep a much smaller number of enterprise beans around to do the work, reusing each enterprise bean instance to service different requests. • Although this sounds like a resource drain, when done correctly, it greatly reduces the resources required to service all the client requests.

  5. The stateless session bean and instance pooling Stateless session beans in a swapping strategy

  6. Message-driven beans and instance pooling JMS-MDB instance pooling

  7. The Activation Mechanism • Unlike other enterprise beans, stateful session beans maintain state between method invocations. • Stateful session beans, unlike stateless session and message-driven beans, do not participate in instance pooling. Instead, stateful session beans use activation to conserve resources.

  8. The Activation Mechanism • Passivation is the act of disassociating a stateful bean instance from its EJB object and saving its state. • Activating a bean is the act of restoring a stateful bean instance's state relative to its EJB object. • Since a stateful bean class does not have to be serializable, the exact mechanism for activating and passivating stateful beans is up to the vendor.

  9. The Activation Mechanism The passivation and activation processes

  10. Java EE Connector Architecture • The Java EE Connector Architecture defines an interface between Enterprise Information Systems (EISs) and Java EE container systems (i.e., EJB and Servlet containers). • EIS is a generic term for any information system, including relational database servers, message-oriented middleware (e.g., MQSeries and SonicMQ), CORBA, ERP systems (e.g., SAP, PeopleSoft, and JD Edwards), and legacy systems (e.g., IMS and CICS).

  11. Java EE Connector Architecture • Java EE defines a number of standard enterprise APIs, including JDBC, JMS, JNDI, Java IDL, and JavaMail, in addition to EJB. • Each API provides a vendor-neutral API for a specific kind of enterprise information system.

  12. Java EE Connectors 1.5 • EJB 2.0 required support for the new Java EE Connector Architecture, which went a long way toward solving this problem. • However, it didn't go far enough. In particular, it didn't support the push model for messaging, which is needed because several EISs push data to clients, without the clients explicitly making a request—for example, JMS.

  13. Java EE Connectors 1.5 • Both EJB 2.1 and 3.0 require support for Java EE Connector Architecture 1.5, which supports the push model. • To support the push model, JCA 1.5 uses the message-driven bean programming model.

  14. Primary Services • Many value-added services are available for distributed applications. • This course looks at eight value-added services that are called the primary services because they are required to complete the Enterprise JavaBeans platform. • The primary services include concurrency, transactions, persistence, distributed objects, asynchronous messaging, a timer service, naming, and security.

  15. Concurrency • Session beans do not support concurrent access. This limitation makes sense if you consider the nature of stateful and stateless session beans. • Because EJB servers handle concurrency, a bean's methods do not have to be made thread-safe. • In fact, the EJB specification prohibits the use of the synchronized keyword.

  16. Concurrency • Entity beans represent data that is shared and may be accessed concurrently. Entity beans are shared components. • In Titan Cruises' EJB system, for example, there are three ships: the Paradise, the Utopia, and the Valhalla. At any given moment, the Ship entity bean that represents the Utopia might be accessed by hundreds of clients. • In the Java Persistence specification, the persistence container protects shared entity data by making a copy of the entity bean instance on a per-transaction basis.

  17. Concurrency • Since each transaction has a snapshot of the entity, concurrent multithreaded access is possible. • In message-driven beans, concurrency refers to the processing of more than one message at a time. • If message-driven beans could process only a single message at a time, they would be practically useless in a real-world application because they couldn't handle heavy message loads.

  18. Concurrency Concurrent processing with message-driven beans

  19. Transactions • A transaction is a unit of work or a set of tasks that are executed together. • Transactions are atomic; in other words, all the tasks in a transaction must be completed together for the transaction to be considered a success. • Transactions are managed automatically, so, as a bean developer, you don't need to use any APIs to manage a bean's involvement in a transaction. • Simply declaring the transactional attributes at deployment time tells the EJB server how to manage the bean at runtime.

  20. Persistence • Entity beans represent the behaviour and data associated with real-world people, places, or things. Unlike session and message-driven beans, entity beans are persistent, which means that the state of an entity is saved in a database. • Persistence in EJB 3.0 has been totally revamped and re-architected within the Java Persistence specification. • While the EJB 2.1 model was component-based persistence, the Java Persistence model is a plain Java-based model (often called POJO Persistence).

  21. Persistence • Entities can be created outside the scope of the EJB container. They are allocated as any other Java object using the new( ) operator. • Object-to-relational (O/R) persistence involves mapping an entity bean's state to relational database tables and columns. • Since relational databases are used in 99 percent of database applications, the EJB 3.0 Expert Group realized that it is better to focus on object-to-relational mapping than to try to create a persistence architecture that is one-size-fits-all.

  22. Persistence • As a result, the Java Persistence specification provides rich relational database mapping with advanced features such as inheritance, multi-table mappings, versioning, and expanded EJBQL support. • Since O/R mapping is mandated by the specification now, this makes EJB applications much more portable between vendors, as there will be a lot less vendor-specific metadata. • Let's give a simple overview of O/R mapping. In Titan's system, Cabin models the concept of a ship's cabin.

  23. Persistence • Cabin defines three fields: name, deckLevel , and id. The definition of Cabin looks like this: @Entity @Table (name="CABIN") public class Cabin { private int id; private String name; private int deckLevel;

  24. Persistence @Column (name="NAME") public String getName( ) { return name; } public void setName(String str) { name = str; } @Column(name="DECK_LEVEL") public int getDeckLevel( ) { return deckLevel; public void setDeckLevel(int level) { deckLevel = level; } @Id @Column(name="ID") public int getId( ) { return id; } public void setId(int id) { this.id = id; }}

  25. Distributed Objects • As far as a remote client is concerned, a bean is defined by its remote interface or endpoint interface. • Everything else is invisible, including the mechanism used to support distributed objects. As long as the EJB server supports the EJB client view, any distributed object protocol can be used. • EJB 3.0 requires that every EJB server support Java RMI-IIOP, but it doesn't limit the protocols an EJB server can support to just Java RMI-IIOP (the Java RMI API using the CORBA IIOP protocol).

  26. Distributed Objects • It also requires support for SOAP 1.2 via the JAX-RPC API. • EJB also allows servers to support access to beans by clients written in languages other than Java. An example of this capability is the EJB-to-CORBA mapping defined by Sun. • This document describes the CORBA Interface Definition Language (IDL) that can be used to access enterprise beans from CORBA clients. A CORBA client can be written in any language, including C++, Smalltalk, Ada, and even COBOL.

  27. Asynchronous Enterprise Messaging • Prior to EJB 2.0, asynchronous enterprise messaging was not considered a primary service because it wasn't necessary in order to have a complete EJB platform. • However, with the introduction of message-driven beans, asynchronous enterprise messaging with JMS has become so important that it has been elevated to the status of a primary service.

  28. EJB Timer Service • The EJB Timer Service can be used to schedule notifications that are sent to enterprise beans at specific times. Timers are useful in many different applications. • For example, a banking system may set timers on mortgage accounts to check for past-due payments.

  29. EJB Timer Service • A stock-trading system might allow timers to be set on "buy limit orders." • A medical claims system may set timers for automatic fraud audits of individuals' medical records. • Timers can also be used in applications like self-auditing systems and batch processing.

  30. Naming • All naming services do essentially the same thing: they provide clients with a mechanism for locating distributed objects or resources. To accomplish this, a naming service must provide two things: object binding and a lookup API. • Enterprise JavaBeans mandates the use of JNDI as a lookup API on Java clients. JNDI supports just about any kind of naming and directory service.

  31. Naming • Although JNDI can become extraordinarily complex, the way it's used in Java EE applications is usually fairly simple. • The following code shows how the JNDI API might be used to locate and obtain a reference to the TravelAgentRemote EJB: javax.naming.Context jndiContext = new javax.naming.InitialContext( );

  32. Naming Object ref = jndiContext.lookup("TravelAgentRemote"); TravelAgentRemote agent = (TravelAgentRemote) PortableRemoteObject.narrow(ref, TravelAgentRemote.class); Reservation res = agent.bookPassage(...);

  33. Security • Enterprise JavaBeans servers can support as many as three kinds of security: • Authentication Simply put, authentication validates the identity of the user. The most common kind of authentication is a simple login screen that requires a username and a password.

  34. Security • Authorization Authorization (a.k.a. access control) applies security policies that regulate what a specific user can and cannot do. Access control ensures that users access only those resources for which they have been given permission.

  35. Security • Secure communication Communication channels between a client and a server are frequently the focus of security concerns. A channel of communication can be secured by encrypting the communication between the client and the server.

  36. Primary Services and Interoperability • Interoperability is a vital part of EJB. The specification includes the required support for Java RMI-IIOP for remote method invocation and provides for transaction, naming, and security interoperability. • EJB also requires support for JAX-RPC, which itself requires support for SOAP 1.1 and WSDL 1.1; these are the standards of the web services industry.

  37. IIOP • EJB requires vendors to provide an implementation of Java RMI that uses the CORBA 2.3.1 IIOP protocol. • The goal of this requirement is that Java EE application servers will be able to interoperate so that Java EE components (enterprise beans, applications, servlets, and JSPs) in one Java EE server can access enterprise beans in a different Java EE server. • The Java RMI-IIOP specification standardizes the transfer of parameters, return values, and exceptions, as well as the mapping of interfaces and value objects to the CORBA IDL.

  38. SOAP and WSDL • SOAP (Simple Object Access Protocol) is the primary protocol used by web services today. It's based on XML and can be used for both RPC- and document (asynchronous)-style messaging. • The fact that SOAP is based on XML means that it's fairly easy to support. • Any platform (operating system, programming language, software application, etc.) that can create HTTP network connections and parse XML can handle the SOAP protocol.

  39. SOAP and WSDL • WSDL (Web Service Description Language) is the IDL of the web services. • WSDL documents are highly structured, so they can be used to auto-generate RPC stubs and other software interfaces for communicating with web services. • Although WSDL documents are open enough to describe any type of service, they are typically used to describe web services that use the SOAP protocol.

More Related