Enterprise Java Beans for the Oracle Internet Platform

Transcription

1 Enterprise Java Beans for the Oracle Internet Platform Matthieu Devin, Rakesh Dhoopar, and Wendy Liau, Oracle Corporation Abstract Enterprise Java Beans is a server component model for Java that will dramatically simplify how you build transactional enterprise applications in Java. This presentation explains what Enterprise JavaBeans are, how they work, and how they can simplify a common class of distributed applications. It will also illustrate using case examples, best practices in how to design and deploy Enterprise Java Bean applications including tips on application design for scalability, manageability, and performance. Introduction Since the birth of the Internet and the World Wide Web (WWW), many infrastructure vendors have offered a completely new breed of application deployment platforms in Application Servers. These different application server vendors offer different features and different levels of support for programming environments, protocols, and development tools. However most application server vendors are converging towards the Java 2 Enterprise Edition model which includes servlets and Enterprise JavaBeans. The Enterprise JavaBeans component model, proposed by Sun with support from the majority of the other software vendors, has become the industry leading standard server component model for Java that promises to dramatically simplify how you build transactional enterprise applications. With the release of the Oracle s first Internet database, Oracle8i, Oracle has significantly enhanced support for open standards in its database. Primarily, Oracle8i has tightly integrated a highly scalable and reliable server side Java Virtual Machine (VM) that enables application developers to deploy Java applications on the Internet. Oracl8i s Java VM supports a variety of application programming models. In addition to supporting Java Stored Procedures and standard CORBA servers implemented in Java, Oracle8i also supports a component development paradigm for pure Java developers - Enterprise JavaBeans. With the most recent introduction of the Internet Application Server, Enterprise JavaBeans is also included as part of the J2EE platform which allows the deployment of J2EE compliant EJBs. Why does Oracle support EJBs? Conceptually, EJB has significant advantages for distributed systems developers: High level of abstraction which does not require advanced systems programming skills. EJBs have a simple declarative transaction model which allows users to specify transactional operations such as COMMIT, ROLLBACK etc. declaratively. They happen automatically when methods of the Bean are executed. EJB provides a declarative security model that allows users to specify an Access Control List for the bean. This acl is enforced by the EJB container when the bean is accessed. EJBs are simplest for the Java developer since they have a pure Java definition which avoids dependency upon foreign distributed objects systems such as CORBA and D/COM. EJBs are portable across a range of Application Servers. The EJB specification describes how to develop Java components and deploy them in an Application Server called an "EJB Container". The implementation of the EJB Container is however not described and that allows Container vendors to add value in the form of scalability, reliability, atomic transactions. Oracle8i and IAS have the same EJB Container, and it supports the EJB 1.1 specification. It provides a number of features ensuring that its implementation is fast, highly scaleable and secure. This paper will discuss the support for Enterprise JavaBeans for both Oracle8i and IAS. All EJB concepts introduced to you in the context of Oracle8i apply to IAS also. The paper is divided into five parts. Oracle #471 / Page 1

2 The first section discusses the EJB interfaces and classes that you need to be aware of and implement to develop any EJBs. It also describes the different types of EJBs an application developer can implement and the typical scenarios under which these types of Beans are used including session beans and entity beans. The second section discusses how Enterprise JavaBeans are developed and deployed in the Oracle8i and the IAS environment. It also gives you an overview of how you access the data in the Oracle database using JDBC and/or SQLJ. The third section discusses the tools support that Oracle provides you to make development and deployment of Enterprise JavaBeans easy in the Oracle8i and the IAS environment. You can use a variety of wizards to simplify the variety of deployment steps. The fourth section discusses the benefits of using Enterprise JavaBeans and specifically the benefits of deploying Enterprise JavaBeans in Oracle8i and IAS. Finally, the fifth section provides you with some tips and techniques that help you develop more robust EJBs and how to best leverage the Oracle Internet platform for EJB deployment. This section also gives you a brief overview of future directions of Oracle s EJB implementation. Overview of Enterprise JavaBeans Now that we have understood what EJBs are and why they are useful, let us look at EJB application development in greater detail. An EJB consists of 4 related components The Bean Remote Interface The Bean Home Interface The Bean itself The Bean Deployment Descriptor. Let us look at each of these components in greater detail. The Bean Remote Interface The Bean Remote Interface provides the client-side view of the Bean. It lists all the methods or public interfaces of the Bean that clients can call. To describe the EJB, users can introspect the Bean Remote Interface to understand the EJB s public interfaces. While the Bean Remote Interface is defined as a standard Java RMI (Remote Method Invocation) interface in the EJB specification, the actual communication is independent of RMI - Oracle8i uses IIOP as the wire protocol for communication. Below is an example of a remote interface. It describe a Bean of class BankAccount that has a two remote methods: The first method returns the balance of the account and the second debits some money from the account. The interface is described like an RMI interface that extends the EJBObject class. // Bean Remote Interface package bank; public interface BankAccount extends EJBObject { float getbalance () throws RemoteException; void debit (float amount) throws RemoteException; } Oracle #471 / Page 2

3 The Bean Home Interface The Bean Home Interface provides a set of "create" methods that are used to activate the beans. Typically each EJB client will start by looking up an implementation of the Bean Home Interface and ask it to activate an instance of the Bean for private use by the client. It's the existence of the Home interface that provides scalability in the EJB model: Each client gets a different instance of the Bean which minimizes the competition for resources in the Container. This is similar to a CORBA Factory pattern. The server-side implementation classes for the Bean HomeInterface which are EJB server-specific are generated at deployment time. In Oracle8i they are generated when the EJB is loaded onto Oracle8i using an automated facility provided by Oracle. Here is an example of a Home Interface. It provides a single "create" method that gets the name of the bank account as an argument and returns an activated BankAccount Bean for that account. // Bean Home Interface package bank; public interface BankAccountHome extends EJBHome { BankAccount create (String account) throws RemoteException, CreateException; } The Bean Implementation Finally, there is the Bean itself which is a standard Java Class implementing the application business logic. It provides implementations for the methods of the Remote interface and the Home interface. The Home interface methods are renamed "ejbcreate" instead of just "create" by convention. The bean implementation typically uses JDBC or SQLJ to access some underlying database. EJB Containers that run as standalone applications usually provide a mechanism for Bean implementations to share access to pools of database connections. In Oracle8ithe Bean is already running inside a database session and can access the local SQL storage directly using JDBC: No connection pools are needed. The following is an example of a bean implementation. The getbalance method selects from an accounts table and the debit method updates the accounts table. The ejbcreate method just initializes the account attribute with the name of the account passed as an argument. The bean implementation extends the SessionBean class. It uses SQLJ in our example: // The Bean Itself package bankserver; public class BankAccountBean extends SessionBean { String account; // The name of the account } // Bean Interface methods float getbalance () { float balance; #SQL { select bal into :balance from accounts where name = :account; } return balance; }h void debit (float amount) { #SQL { update accounts set bal = bal - :amount where name = :account; } } // Home Interface methods void ejbcreate (String account) { this.account = account;} // Some other "lifecyle" methods omitted for clarity Oracle #471 / Page 3

4 Bean Deployment Descriptor The bean deployment descriptor ties all the various components of the bean together. It allows the user to specify the Bean s transactional and security attributes declaratively simplifying the process of building transactional applications with the database. In addition to these attributes being specified at the bean level, the user also has the ability to specify finer grained transaction and security at the method level of the Bean using method descriptors. Furthermore, users can specify environment entries that the beans can look up via JNDI. In the EJB specification, the deployment descriptor is an XML file that describes these attributes. The following is an example of a bean deployment descriptor in the Oracle8i environment. The deployment descriptor indicates that this is a session bean, and includes the name of the Java classes implementing the EJB s RemoteInterface and the EJB s HomeInterface. The security descriptor, defined in the assembly descriptor section, specifies the identities of users allowed access privileges to the Bean - in this case it is specified as any PUBLIC user has access to the Bank. Further, the example also demonstrates the user of per method descriptors to specify security and transactional features declaratively at the method level. This descriptor essentially specifies that only users with identity of TELLER or MANAGER can run getbalance() and that the method can be called in a transaction. On the other hand debit() must be called by a client running as MANAGER and requires a transaction. The EJB specification does not say where the identities come from. It's the responsibility of the EJB Container to define a domain for the identities and to provide tools to manage them. For Oracle8ithe EJB identities are just database usernames or roles. <?xml version="1.0"?> <!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems Inc.//DTD Enterprise JavaBeans 1.1//EN" "ejb_jar.dtd"> <ejb-jar> <enterprise-beans> <session> <description>this is an BankAccount session bean</description> <ejb-name>/test/mybank</ejb-name> <home>bank.bankaccounthome</home> <remote>bank.bankaccount</remote> <ejb-class>bankserver.bankaccountbean</ejb-class> <reentrant>false</reentrant> <env-entry> <env-entry-name>customerbean.databaseurl</env-entry-name> <env-entry-type>java.lang.string</env-entry-type> <env-entry-value>jdbc:oracle:kprb:</env-entry-value> </env-entry> </session> </enterprise-beans> <assembly-descriptor> <security-role> <description>public includes everyone</description> <role-name>public</role-name> </security-role> <security-role> <description> </description> <role-name>teller</role-name> </security-role> <security-role> <description> </description> <role-name>manager</role-name> </security-role> <method-permission> <description>no description</description> <role-name>public</role-name> <method> <ejb-name>/test/mybank</ejb-name> <method-name>*</method-name> </method> </method-permission> <method-permission> Oracle #471 / Page 4

5 <description>only MANAGER can debit the account</description> <role-name>manager</role-name> <method> <ejb-name>/test/mybank</ejb-name> <method-name>debit</method-name> </method> </method-permission> <method-permission> <description>only TELLER and MANAGER can get the balance on the account</description> <role-name>teller</role-name> <role-name>manager</role-name> <method> <ejb-name>/test/mybank</ejb-name> <method-name>getbalance</method-name> </method> </method-permission> <container-transaction> <description>no description</description> <method> <ejb-name>/test/mybank</ejb-name> <method-name>*</method-name> </method> <trans-attribute>supports</trans-attribute> </container-transaction> <container-transaction> <description>to debit an account we require a transaction</description> <method> <ejb-name>/test/mybank</ejb-name> <method-name>debit</method-name> </method> <trans-attribute>required</trans-attribute> </container-transaction> </assembly-descriptor> </ejb-jar> Types of Enterprise JavaBeans The Enterprise Java Bean specification describes four types of Beans: Stateless session beans Stateful session beans Bean Managed Persistence entity beans Container Managed Persistence entity beans These different types of beans primarily relate to how Beans persist their state and how they maintain conversational state. The EJB container manages the state of the Bean referring to the data contained within the Bean. In some cases, Bean data are transient and pertain only to the execution of a specific activation. In other cases, the data are persistent and pertain to multiple activations potentially across restarts of the EJB Container. Enterprise JavaBeans supports both transient and persistent Beans. A transient Bean is called a session Bean, and a persistent Bean is called an entity Bean. Session Beans: A session Bean is created by a client and in most cases exists only for the duration of a single client/server session. A session Bean performs operations on behalf of the client such as accessing a database or performing calculations. Session Beans can be transactional, but they are not recoverable following a system crash. There are two kinds of session Beans: A stateless session Bean which maintains no state across methods and transactions - the EJB Container could transparently reuses instances of the Bean to service different clients. Stateful session Beans maintain conversational state across methods and transactions -as a result, the EJB Container binds the the Enterprise Bean instances to clients directly. Session Beans, by definition, are not persistent, although they may contain information that needs to be persisted. Session Beans can implement persistence operations directly in the methods in the enterprise bean. Session Beans often maintain a cache of database information that must be synchronized with the database when Oracle #471 / Page 5

6 transactions are started, committed, or aborted. With Oracle8i, such state synchronization is done using JDBC or SQLJ and can happen automatically if the SessionBean implements the Synchronization interface. Entity Bean: EntityBeans are Session beans with a stronge sense of identity. Like Session Beans they are primarily remote objects accessed over a network by some clients. However, instead of being created for each client by the Home interface, EntityBeans are "found" by a primary key. This primary key lets Clients identify single Entity Beans across restarts of the EJB Container. When an EntityBean is "found" some of its persistent state is loaded automatically from persistent storage by the EJB Container. The EJB specification does not indicate how the state itself is stored (how Entity Bean attributes are mapped to SQL tables or OODB entities). The Bean developer can use 2 models of storage: Bean Managed Persistence, where the developer provides code in callback methods to explicitly load and store the Entity Bean attributes, or Container Managed Persistence where the EJB Container finds a reasonable way to load and store the object. Container Managed Persistence is usually best achieved by the use of Object-Relational mapping tools that generate code or meta-information that is used by the Container to load and store the object. Differences in Implementing Entity Beans vs. Session Beans Entity Bean Home Interface In an entity home interface, in addition to the create methods, you have to specify one or more finder methods that allows you find one or more entity beans that were created previously. The findbyprimarykey() method has to be declared. Here is an example of a Home Interface for an Entity Bean. It has one single create method that gets an account and returns a new entity bean with this account. It also has a findbyprimarykey method which takes in an account and returns an BankAccount entity bean already associated with that account. In our example, account is the primary key for the BankAccount entity bean. A primary key uniquely identifies an entity bean and you can use a primary key to find an entity bean. This home interface also contains another finder method called findaccountslargerthan. This should return an enumeration of BankAccounts that have balance greater than the balanced passed in the parameter. // Bean Home Interface public interface BankAccountHome extends EJBHome { BankAccount create (String account) throws RemoteException, CreateException; BankAccount findbyprimarykey (String account) throws RemoteException, FinderException; Enumeration findaccountslargerthan (int balance) throws RemoteException, FinderException; } Entity Bean Deployment Descriptor In general, the entity bean deployment descriptor is similar to the session bean deployment descriptor. You will need to specify the persistence type: CMP or BMP, the primary key, and container managed persistence fields if you have a CMP bean. Container Managed Persistence fields For CMPs, you need to specify a list of container managed fields within your bean that you want the container to manage for you. The container restores the fields for you at the beginning of a transaction, and persists them at the end of a transaction. These fields are specified at the deployment descriptor and must be public attributes of the bean. Bean Managed Persistence(BMP) entity Bean Implementation In a BMP implementation, you have to implement an ejbcreate() and an ejbpostcreate() method that corresponds to a create method specified in the home interface. This ejbcreate() should create a persistent representation of this bean and manufacture a primary key that uniquely identifies this bean. The ejbpostcreate() method allows you to further initialize the entity bean. In addition to the create methods, the corresponding finder methods must also be implemented in BMP. In our example, the implementation would include ejbfindbyprimarykey() and ejbfindaccountslargerthan(). The persistence of the data is done through the following call back methods: ejbload() and ejbstore(). ejbload() is called whenever the container wishes to refresh/synchronize the state of the bean with what s in the database. ejbstore() is called when a transaction is committed and at this time, the bean should write its state back to the persistence storage. Oracle #471 / Page 6

7 Container Managed Persistence Bean Implementation In a CMP implementation, the ejbcreate() should initialize all the container managed persistence fields so the container can manage and persist the bean for you. You do not need to implement the finder methods because they are implemented by the container for you. You do not necessarily have to implement the ejbstore() and the ejbload() methods. You can prepare the container managed persistence fields for the container to persist in ejbstore(). The ejbload() method can be used to manipulate or initialize the attributes after the container restores the container managed fields for you. Please refer to the Oracle Enterprise Java Bean documentation for more details on how to develop an EJB. Oracle #471 / Page 7

8 Developing and Deploying Enterprise JavaBeans in Oracle8i and ias Both Oracle8i and ias have an EJB Container: You can deploy Enterprise Java Beans to either Oracle8ior IAS and clients can activate and execute them there. The process of "deploying" a Bean is not specified by the EJB specification but depends on the particular EJB Containers. In Oracle8I and IAS you can deploy the bean either with the command line tool "deployejb" or with one of the deployment wizards provided with JDeveloper. If you use the deployejb tool to deploy the Bean you first have to compile the Bean code and put it in a Jar file. You can then imvoke the tool which provides an automated, single step deployment process for EJBs generating several pieces of code required by our EJB server. There are three related actions that the tool automates: First, the tool automatically generates EJB server-side runtime. It then uploads the server-side runtime on to the EJB container. Since the EJB itself has been packaged as a standard Java.jar file, this process is automated by using the loadjava utility that Oracle provides. Second, the tool automatically generates the client-side classes required to access the EJB server. It implements server independent interfaces and puts it in a new jar file. Third it executes the additional set up steps required to deploy the EJBs automatically, Populates JNDI accessible name service described in EJB s deployment descriptor and enforces security for the RunAs propertiesof the Bean. Here is an example of how you invoke deployejb: // Deploying EJBs using ejbdeploy tool % deployejb -u scott -p tiger -temp temp -s sess_iiop://localhost:2481:orcl -descriptor bank.xml bank.jar Writing Client Programs To Access the EJBs Once you have developed and deployed the EJB application, you can develop an EJB client application that accesses and invokes the EJBs. Today, Oracle only supports pure Java clients to invoke EJBs. Let us look at the steps involved in developing the EJB client. In developing the Enterprise Java Bean Client, there are three important steps that the user needs to go through. [i] First, the user must authenticate the EJB client, [ii] Next, the client must lookup the EJB object using JNDI, [iii] Finally, the client can access the server Bean and invoke methods defined in the remote interface of the bean. Let us examine each of these steps one by one: Client Authentication: The user can authenticate the EJB Client with the EJB container in two ways: the user can use explicit login using the Oracle supplied login Object. The login object is the only object that can be activated without any authentication. However, the only method that the login object implements is the authenticate method. Alternatively, the user can use the OracleCredential Object for implicit authentication by passing a username/password/role to the Credential Object along with the service content. The OracleCredential Object implicitly authenticates the user with the database taking as arguments the username, password and role. With each of these two methods, We also supports SSL enabled authentication (see Figure 1). SSL authentication allows you to authenticate using industry standard SSL protocol. With Oracle 8.1.5, you can use SSL encryption and SSL server autentication. Release also supports SSL client authentication. The Non-SSL credential mechanism is turned off by default because it sends the user credentials in clear text. The Login mechanism always encrypts the user credentials. Oracle #471 / Page 8

9 Oracle Security Mechanisms Login NON_SSL_ LOGIN SSL_LOGIN AUTHENTICATION MODE Credential X No SSL SSL_CRE DENTIAL SSL TYPE OF NETWORK CONNECTION Figure 1. Oracle Supported Security Mechanisms for Enterprise JavaBeans Lookup the EJB using JNDI: Once the user has authenticated with the database, the next step is to locate the Bean using JNDI. Upon lookup of the named EJB, the JNDI implementation returns a handle to a remote object that implements the Home Interface. The Home Interface serves as a factory for the EJB objects that implement the actual remote interface. Once you have obtained the handle to the HomeInterface, you can use it to either create (in case of session beans) or lookup (in case of entity beans) the actual bean that implements the remote methods. Invoke the methods on the Bean: Having created or found the Bean instances, users can execute methods of the instance by invoking the Bean s methods which are published in the RemoteInterface. Clients get the Bean Interface and the Bean home from the Jar generated at EJB deployment time. Clients can drive transactions in two ways: either they can depend on the declarative transactions specified as part of the EJB s deployment descriptor; or they can use Java Transaction Service to explicitly drive transactions from the Bean client. Here is an example that shows how you can develop an EJB client: Hashtable env = new Hashtable (); env.put(context.url_pkg_prefixes, "oracle.aurora.jndi"); env.put(context.security_principal, scott ); env.put(context.security_credentials, tiger ); env.put(context.security_authentication, ServiceCtx.NON_SSL_LOGIN); Context ic = new InitialContext(env); BankAccountHome home = (BankAccountHome) ic.lookup( sess_iiop://localhost:2481:orcl/test/mybank ); BankAccount account = home.create(" "); account.debit(285); EJB in Internet Application Server(IAS) EJB is supported in both the IAS Standard Edition and in the Enterprise Edition. We recommend that you call EJBs from the servlets running inside the Oracle Servlet Engine(OSE). It is very efficient because both the servlet and the EJB are Oracle #471 / Page 9

10 running in the same session, therefore no networking roundtrip overheads are involved. Http clients can access servlets running in OSE through the Apache modose. Activating EJBs from Servlets running in the Oracle Servlet Engine(OSE) The coding for activating EJBs from servlets running in the OSE is simplified because the servlet is already running in the session. Therefore, there isn t a need for authentication(unless you explicitly want to do so) and the JNDI setup is much simplier. Here s a segment of code of what you need to do from a servlet to activate an EJB: InitialContext ic = new InitialContext(); BankAccountHome home = (BankAccountHome)ic.lookup ("/test/mybank"); BankAccount account = home.create ( ); account.debit(300); Persistence Service Interface for Entity Beans Different entity bean has different expectations on how persistence should be handled by the container because the usage model is not the same for all entity beans. Some beans would want a very light weight persistence layer that has limited functionality, while others require much richer set of object relational mappings. Some require that the persistence back end to perform well, while others would prefer high scalability. Therefore, it is clear that we need to have a pluggable interface that allows different persistence layer to be used with the 8i EJB container. This approach allows the bean deployer to choose between different persistence back ends. The interface that allows this to happen is called the Persistence Service Interface. It is an internal interface that specifies the contract between the EJB container and the persistence layer. Currently for 8.1.7, a CMP developer has two persistence choices: PSI Reference Implementation, and BC4J through Jdevelopoer. The Reference Implementation of PSI provides a limited set of functionality for handling entity bean persistence. You use an oracle specific deployment descriptor to define how the bean should be mapped to a table. BC4J has a much richer and complex set of object/relational mapping functionality that you can use through the Jdeveloper tool. Development Tools Support for EJBs in Oracle8i and IAS Oracle provides an IDE in JDeveloper that makes Java application development in general and EJB development and deployment in particular very easy. The JDeveloper Integrated Development Environment, excels in creating, debugging, and deploying component-based solutions. While adhering to open industry standards, JDeveloper Suite provides unparalleled support for building applications on Oracle's server stack. JDeveloper is tightly integrated with Oracle s Internet Platform and provides you several features including wizard driven EJB deployment tools to simplify EJB deployment easy. These applications could use JDBC,SQLJ and Servlets in conjunction with EJBs. There are two EJB related wizards in JDeveloper (as shown in Figure 2): [i] EJB Wizard and [ii] EJB Deployment profile Wizard. The EJB Wizard provides many ways to develop EJBs. It generates the required EJB files based on the options chosen by the user. The EJB Wizard greatly simplifies the process of creating an EJB. Based on the developer s choices, the EJB Wizard steps the developer through the process of encapsulation of the business logic, generation of the home and remote interfaces and generation of the Deployment Descriptor. Once the EJB application is ready to be deployed to the server, you can use the EJB Deployment Profile Wizard. The EJB Deployment Profile Wizard can be invoked from the EJB wizard. The EJB Deployment Profile Wizard archives the various EJB files so that they can be installed on the EJB server as a single EJB-JAR The wizard also provides a facility to include in the EJB-JAR any other dependent class files that need to be deployed to the server. The result of the deployment process is The EJB is installed in the database The client side stubs are generated. The client stubs act as a proxy to the remote EJB object. This makes the location of the server transparent to the EJB client. The deployment profile wizard also creates a deployment profile file (.prf extension) which stores the information supplied to the profile wizard when it was first invoked. This.prf profile file allows the wizard to be brought up in re-entrant mode. This allows for incremental development and deployment of EJBs thus boosting the developer s productivity. Oracle #471 / Page 10

11 JDeveloper s Role Package and Deploy to Oracle8i Oracle8i Build EJBs using the EJB Wizard EJB Server Container EJB SQL and PL/SQL Figure 2. Use of JDeveloper in Developing and Deploying EJBs in Oracle8i Benefits of Using Enterprise JavaBeans Enterprise JavaBeans offer several benefits for application developers. For Java programmers, EJBs are significantly easier to program than other Bean systems such as CORBA or D/COM for the following reasons: Easy for Programmers: Since Enterprise Beans have pure Java definition, users do not need to learn another Interface Definition Language. EJB supports the notion of Objects by value for any valid RMI type allowing arguments to be passed by value rather than necessarily as pointers. Also, the EJB developer does not need to deal with low level system programming issues such as thread-aware programming - scalability requirements are automatically addressed by the EJB server implementation. Declarative Transaction Rules: The transaction rules for EJBs can be defined at application assembly or deployment time rather than programmatically at application development time. The EJB server automatically manages the start, commit, and rollback of transactions on behalf of the EJB according to the transaction attribute specified in the deployment descriptor associated. The EJB specification describes six different transaction policies allowing an EJB to adopt different types of behavior. Declarative Security: Similarly the security policies on the EJB can be specified declaratively. Further, EJBs are very easy to deploy in a multi-tier distributed environment for these reasons: Portability: EJB Clients are independent of server implementations. The deployment process automatically generates EJB client classes and stubs. Clients implement server independent interfaces and as a result, are agnostic about the specific EJB server implementation chosen. Customizability: EJBs are highly Customizable. Declarative programming mechanisms to specify security and transaction semantics allows the attributes to be modified when the EJB is deployed. Similar to JavaBeans, the EJB component model supports customization without requiring access to source code. Scalability: Another aspect of why EJBs are particularly easy to use is that they allow server applications to scale since the EJB definition was specifically restricted to allow server scalability. The Enterprise JavaBeans environment automates the Oracle #471 / Page 11

12 use of complex infrastructure services such as thread management. Component developers and application builders do not need to implement complex service functions within the application programming logic. Now that we have examined the various elements of EJBs, the benefits they offer and how Oracle8i can be used as an EJB server, let us examine the specific benefits that Oracle8i offers EJB developers. Oracle8i makes EJBs fast, scalable, secure, and easy-to-use. How does Oracle8i provide these benefits? Performance: Most importantly, EJBs are standard Java applications and the various elements that the Java VM provides to make Java execution fast such as RDBMS integration and native compilation also benefit EJBs. Further, since EJB s access persistent state in the RDBMS via the embedded JDBC Driver, SQL Data access is very efficient from EJBs deployed in Oracle8i. Hence, Oracle8i provides an ideal EJB server platform for data intensive EJBs. In the future, the Java VM s object memory architecture will provide fast initialization, activation and rollback for EJBs. Loading these object memories will become a very fast operation essentially linear with respect to the size of the object memory. In contrast, other EJB implementations essentially use a deserialization process which is a graph traversal operation upon activating an EJB that has been passivated - this is significantly slower because it requires fine-grained allocations and the execution of user specific code. Scalability: Oracle s implementation of Java VM in Oracle8i provides a very scalable platform for running any Java applications. Since EJBs are standard Java applications, they can exploit the Java VM s shared memory optimizations to achieve scalability to 1000s of concurrent clients. Secure: Again, since Oracle s EJB implementation is tightly integrated with the Oracle RDBMS, it can leverage all the security features available with the database. Users can use a variety of mechanisms, as described earlier, to authenticate to the database. Users can use SSL to encrypt all the data traffic to the EJB server. In addition, users can develop sophisticated access control mechanisms using database roles that allow or restrict who can invoke the EJBs or specific methods on EJBs. Oracle already supports the RunAs mechanism from the EJB 1.0 specification and will continue to do so in subsequent releases. The RunAs mechanism provides a very good access control mechanism without having to give explicit privileges to every user who invokes the methods on an EJB. Easy-to-Use: There are a variety of features in Oracle s implementation of EJBs that make them very easy to use. First, EJB transactions map to traditional RDBMS transactions providing a familiar and high performance transaction coordination mechanism for users. Using EJBs as a programming paradigm, therefore, users can now specify RDBMS transactions declaratively instead of programmatically. Second, EJB security maps to traditional RDBMS users and roles. The mechanisms described earlier with CORBA for network encryption using SSL, authentication using traditional database users and roles, and access control at a variety of levels all apply to EJBs as well. Oracle therefore provides a highly secure EJB server. Third, the automated EJB Deployment Tools make it very easy to package and deploy EJBs on Oracle8i. Further, these tools are also being integrated in Oracle s Jdeveloper Application Development Tool to further facilitate and simplify the application development process with EJBs. Oracle #471 / Page 12

13 Tips and Techniques for Deploying EJBs in Oracle8i Here is a grab-bag of things you should think of if you are considering using EJBs with Oracle8i. ARCHITECTURE CONSIDERATIONS Because they are distributed objects, EJBs are very appropriate for any application where you want to separate the business logic from the presentation layer. The business logic is the core of the application, it's the code that make things happen: check inventory, place orders, compute taxes, etc. The presentation layer is the user interface. Separating the business logic from the presentation layer is good for many reasons: The 2 parts gain some independence and can be updated more or less independently. Completely different styles of user interfaces can be put on top of the same business logic: Clerk-level and Manager-level interfaces can invoke different subsets of the same business logic. The same business logic can be invoked by GUI-less interfaces like command line tools or batch processes, etc. The component interfaces can also be a good base for integrating different applications together. EJBs provide a good way to separate business logic from presentation: EJBs are used to implement the business logic. The Remote Interface of the EJB is the list of the entrypoints that invoke the various business operations. The presentation clients can be any kind of Java clients that activate the EJBs. Typically you will have Java GUIs, Java Servlets (Java code running within a Web server) or Java command line tools as presentation clients. All these clients reuse the same business logic implemented by the same EJBs. See figure3. for an architecture diagram. If you have deployed the EJBs inside Oracle8I you get the additional following benefits: The business logic executes close to the SQL data, right in the database. The Clients are authenticated as database users. As different database users have different rights for running the EJB methods some clients may be enable to only run a subset of the business logic while more advanced users can run the full logic. The application is secure. EJBs can benefit from calling Java Stored Procedures for doing some of the more complex SQL-related operations. You can even pass a reference to an EJB and have its methods invoked from within a SQL statement. The system scales extremely well. In Oracle8I each database client (GUI, Servlet or command line) gets a different database session with a different set of Java objects. There is little contention between the clients which guarantees that each client sees the same performance until all the server CPUs are fully utilized. Other EJB servers typically pool many clients in single process Java VMs and the performance degrades badly when the number of clients increases. Oracle #471 / Page 13

14 EJBs for Business Logic Classic Clients EJBs JDBC SQL Servlets Web Clients HTTP Batch Processes Other App Figure 3. Using EJBs for the business logic DESIGN INTERFACES CAREFULLY The benefits of separating business logic from presentation can only be realized if you spend enough time designing the interface to your business logic. It will be extremely hard, or even impossible, to independently evolve the presentation and the business logic if the interfaces were not well designed. Interface design is still a bit of a black art and require a lot of common sense, a good feel for finding the correct abstractions and a strong discipline to avoid traps. Here are some guidelines but of course your mileage may vary. Remember that the design of the component interfaces is a crucial part of the application. Be terse: Avoid the tendency to add many entrypoints in your interface just because it seems a good idea at the time. Multiplication of entrypoints make the interface extremely hard to evolve as new revisions will have to be backward compatible. Be clear: Each entrypoint needs to have a very clearly defined semantic. Avoid strange side-effects on server side data that is also manipulated by other entrypoints. Ill-defined entrypoints are impossible to use and evolve. Be coarse: Remember that the business logic will typically run on a different server than the presentation clients. If the interface if too chatty the application will spend too much time doing network round-trips. You want to have coarse entrypoints that do a decent amount of well defined work. Delegate things to the UI: The developers of the User Interface may have a tendency to ask the server side logic to do a lot of fine-grain maintenance that should actually belongs to the presentation layer. Undos, Completions, field-validation are often best done on the client side, using list of values provided once from the server. Think "Network Protocol": A remote interface is indeed akin to a network protocol. Method calls are a network roundtrips, arguments and return values are passed by value and not by reference: Data is copied back and forth over the network. Good protocol designers make good interface designers. Oracle #471 / Page 14

15 Session Management The EJB specification talks about Session Beans but does not have an all-encompassing concept of a Session. Database servers have had this concept for a long time and Oracle8I brings this concept explicitly to EJBs. In Oracle8I the database session contains the open cursors, the PL/SQL global variables, the Java static variables and all the EJBs activated on behalf of the Client who started the session. Calls between all these objects are extremely fast: They are all in the same memory space and can point directly to each other. For example call between EJBs activated in the same session do not cause any network round-trips and the arguments are passed by reference instead of by value. This slightly violates the pure EJB specification at the price of much better performance. The concept of a session is good and useful. However this is only the default behavior: Oracle8I provides complete client side and server side control over sessions creation and activation of EJBs. EJB clients can create one or more sessions in the database, each logged-in as a different user if desired. EJBs can be programmatically activated in any session created by the client. On the server side a bean can activate a second EJB either in the same session or in another session created on the fly within the same server. In that case you effectively get a loop-back network connection to the same server. Finally an EJB can also activate another EJB in a different server. This flexibility lets you group related EJBs in the same session as needed. Sessions also have a time-out computed as the minimum of the TimeOut attributes of all the EJBs activated within the session. The TimeOut attribute is specified in the EJB deployment descriptor. You can also programmatically change the time-out or kill the session as you wish. By providing explicit session management Oracle8I gives application developers full control on the scalability and performance of their distributed application. See examples of explicit session and transaction management for EJBs and CORBA objects on-disk in an Oracle8I installation. Future Directions EJB 2.0 We will be working towards the EJB 2.0 specification which has much better support for CMP entity beans and a new type of bean called Message Driven Beans(MDB). MDB is an attempt to integrate EJBs with JMS that allows JMS messages to be sent to EJBs. However, in the MDB model, the client has to be JMS clients, and EJBs have to know how to parse JMS messages. We believe that a more useful and sensible approach for EJB programmers to leverage off of asynchronous messaging would be to use what we called asynchronous EJB. Asynchronous EJB The idea here is that an EJB client would be making asynchronous EJB calls, while the EJB would be receiving method invocations as if it is being called normally. The client doesn t need to know how to construct JMS messages, and the EJB won t need to know how to parse JMS messages. From both the client and the EJB s perpective, they are sending and receiving normal EJB invocations. The underlying transport mechanism will be asynchronous, using JMS, instead of IIOP. Summary The Enterprise Java Beans specification provides a vendor independent model for implementing an application as a set of distributed components. EJBs are easier to program than older component models because they rely on a very modern language (Java) and support declarative security and transactions. With EJBs you don't get locked-up in a proprietary system as already more than 20 competing vendors provide EJB implementations. Oracle has implemented an EJB container directly within the database server and in the Internet Application Server. This server reuses the market proven scalability and reliability technologies from the database to provide one of the most scalable EJB containers on the market. Deciding to architecture an application with distributed components is a worthwhile investment that effectively increase the application life span as it will be easier to evolve the application as the User Interfaces or Business logic requirements evolve. However any component architecture can be successful only if you are careful about designing your interfaces! Oracle #471 / Page 15