Distributed Applications (RMI/JDBC) Copyright UTS Faculty of Information Technology 2002 EJB EJB-3

Transcription

1 Advanced Java programming (J2EE) Enterprise Java Beans (EJB) Part 1 Architecture & Session Beans Chris Wong chw@it.uts.edu.au [based on prior course notes & the Sun J2EE tutorial] Enterprise Java Beans Today we will briefly cover Introduction to EJB EJB basics EJB Architecture Session Beans EJB Clients EJB Development Process Next lesson we will cover Entity Beans Message Driven Beans EJB issues Copyright UTS 2002 EJB EJB-1 Copyright UTS 2002 EJB EJB-2 Introduction to EJB So far we have developed multi-tier applications: Web-based Applications (Servlets/JSPs/JDBC) thin client using browser Model-View-Controller architecture simple business logic Some services provided by web container Distributed Applications (RMI/JDBC) fat client using Java application Simple client/server architecture You have to write all other services EJB Introduction Copyright UTS 2002 EJB EJB-3 Copyright UTS 2002 EJB EJB-4 Why EJB? HOWEVER what about: Reusability of components? Security? Resource management? Scalability Load Balancing, Clustering? Fault tolerance? Error handling? Deployment in other environments? Persistence? Independence from specific databases? J2EE architecture With web applications & RMI, we have to program this. EJB containers provide the above functions. Copyright UTS 2002 EJB EJB-5 Copyright UTS 2002 EJB EJB-6

2 EJB Introduction EJB is the J2EE server-side component model The component software model is based on the idea of creating reusable components that plug in to containers It addresses some important software development goals: reuse high level development focus development automation via tools simplified deployment J2EE Architecture JavaBeans, EJB and ActiveX/COM are examples of component models Copyright UTS 2002 EJB EJB-7 Copyright UTS 2002 EJB EJB-8 EJB Introduction Component models come in two basic flavours client-side; and enterprise EJB Introduction Component developers write component building blocks that implement business logic Client-side component models such as JavaBeans are specialised to handle presentation and user-interface issues Enterprise component models such as Enterprise Java Beans are specialised to provide a framework for developing, deploying and executing distributed, transaction-aware middleware components Application developers hook up these pre-built components into finished applications (which may be components themselves) This building block approach facilitates off-the-shelf reuse of code packaged as components Copyright UTS 2002 EJB EJB-9 Copyright UTS 2002 EJB EJB-10 Enterprise Java Beans Today we will briefly cover Introduction to EJB EJB Basics EJB Architecture Session Beans EJB Clients EJB Development Process Next lesson we will cover Entity Beans Message Driven Beans EJB issues EJB Types of Beans There are 3 types of Enterprise Java Bean: 1. Session beans stateless stateful 2. Entity beans BMP bean managed persistence; or CMP container managed persistence 3. Message Driven beans This lesson focuses on session beans Next lesson on entity beans and intro to message beans Copyright UTS 2002 EJB EJB-11 Copyright UTS 2002 EJB EJB-12

3 EJB Basics EJB interfaces and classes are defined in the javax.ejb package EJB Standards Evolution The EJB specification is an evolving API EJB 1.0 was originally defined as a Java extension in 1998, including definitions for Session beans and (optional) Entity beans EJBs are configured and deployed in a similar manner to web applications using deployment descriptors in XML form META-INF/ejb-jar.xml and others... discussed later We will focus on EJB 2.0 beware, many books/tutorials look at EJB 1.1 main difference is in the way you build entity beans Copyright UTS 2002 EJB EJB-13 EJB 1.1 is the J2EE 1.2 was defined in December 1999 as part of the first J2EE platform specification. EJB 1.1 included: Mandatory support for entity beans Enhancements to the deployment descriptor, including support for an XML format Significant tightening of the specification to improve EJB-based application portability EJB 2.0 is the J2EE 1.3 standard. JMS (Java Message Service) integration with Message Driven beans Improved support for container-managed persistence (CMP) Support for RMI/IIOP protocol for network interoperability EJB 3.0 is the Java EE 5 standard Significantly simplifed EJB development. Now use Java 5 annotations Replaced Entity EJB with JPA Copyright UTS 2002 EJB EJB-14 EJB Containers Containers provide services to deployed components so that component developers can concentrate on writing business logic instead of software infrastructure EJB Runtime Environment The EJB specification defines an EJB runtime environment as a server and a set of containers An EJB container is an environment in which Enterprise Java Beans execute. Its primary role is to serve as a buffer between EJBs and the outside world The container simplifies component development by providing services: Transactions Scalability (management of multiple instances) Persistence Security Synchronisation Distributed object invocation Monitoring and management of EJB instances Copyright UTS 2002 EJB EJB-15 This is usually implemented as a single application server that combines the server and container functions The services provided by the server and containers are defined by contracts between the various parts of the EJB architecture, such as the contract between the container and the beans in it Copyright UTS 2002 EJB EJB-16 EJB and application servers We are using a "web application server" EJB and application servers Note that it has two different types of container: Web container (for servlets and JSPs) Business-logic container (for EJBs) They are logically two separate "tiers" In some cases they are implemented by two separate products, e.g. Tomcat + JBoss Each type of container provides different services Copyright UTS 2002 EJB EJB-17 Copyright UTS 2002 EJB EJB-18

4 EJB Containers - services EJB Containers must provide the following services Transaction management Security services Multiple instance support Container Services Transactions Declarative transaction management: An application's use of transactions can be declared in the XML deployment descriptor, rather than having a programmer write code to manage transactions Less code to write Less chance of programmer-generated errors Allows container to manage resources efficiently Copyright UTS 2002 EJB EJB-19 Copyright UTS 2002 EJB EJB-20 Container Services Security Declarative security management: Container Services Instances Management of multiple instances: An application's use of authentication (login) and confidentiality (encryption) can be declared in the XML deployment descriptor, rather than having a programmer write code to manage security Less code to write Less chance of programmer-generated errors Allows system administrator to manage user access externally to the application code EJBs are written as if they are single threaded classes being accessed by only one client This is true for some beans (stateful session beans in particular), however other beans may be used concurrently by multiple clients The EJB container must ensure that each client s requests are serviced in a timely manner Copyright UTS 2002 EJB EJB-21 Copyright UTS 2002 EJB EJB-22 Container services - Instances In order to accomplish the goal of timely responses to client requests, the server may perform several tasks: Instance passivation the temporary swapping of an EJB out to storage. If a container needs resources, it may choose to temporarily passivate a bean Instance pooling the creation of a pool of bean instances, so that beans can be shared between multiple clients, rather than a new bean being created for every client request (not possible in the case of stateful session beans) Database connection pooling the creation of a pool of database connections, so that connections can be shared between multiple beans, rather than a new connection being created every time the database is accessed Tasks containers perform (2) Pre-cached instances the caching of EJB state information to accelerate the initial creation of EJBs Optimised method invocations the short-circuiting of method calls between two beans in the same container in order to avoid the overhead of a full-blown remote method call (this is done by the container, not by the EJBs themselves - not strictly true as local interfaces in EJB 2.0 achieve the same) Instance passivation is the only optimisation required by the EJB specification, none of the others are explicitly required Copyright UTS 2002 EJB EJB-23 Copyright UTS 2002 EJB EJB-24

5 Enterprise Java Beans Today we will briefly cover Introduction to EJB EJB Basics EJB Architecture Session Beans EJB Clients EJB Development Process Next lesson we will cover Entity Beans Message Driven Beans EJB issues client JNDI lookup EJB Architecture EJB container Remote business methods eg: - deposit() - withdraw() Home Bean management eg: - Create() - Remove() - Find() Implementation Business logic Bean mgmt Container services Transaction mgmt security instance mgmt DB Copyright UTS 2002 EJB EJB-25 Copyright UTS 2002 EJB EJB-26 EJB Architecture The client side of the EJB architecture contains the EJB interfaces needed to invoke business-specific methods on an EJB, and for maintaining handles to server-side objects The server side of the EJB architecture contains the instances of the actual EJB components, along with the container they reside in. The container maps calls from clients to EJB instances after the appropriate service management infrastructure code has been executed RMI remote interface semantics are implied by the interfaces to EJBs Copyright UTS 2002 EJB EJB-27 EJB Architecture pieces (1) The primary application-specific elements of the EJB architecture shown in the diagram are: EJB Client: EJB clients use JNDI to look up home interfaces, and use home and remote interfaces to utilise all EJB-based functionality. EJB clients can be external to the application server (standalone Java client applications or components running in another application server) or running in the same application server EJB Home interfaces (and Stubs): EJB home interfaces provide operations for clients to create, remove and find handles to EJB remote object interfaces. Underlying stubs marshal home interface requests and unmarshal home interface responses for the client Copyright UTS 2002 EJB EJB-28 EJB Architecture pieces (2) Application-specific elements (continued): EJB Architecture pieces (3) Application-specific elements (continued): EJB Remote interfaces (and Stubs): EJB remote interfaces provide the business-specific methods defined for a particular EJB. Underlying stubs marshal remote interface requests and unmarshal remote interface responses for the client EJB implementations: EJB implementations are the application components implemented by developers to provide any application specific business logic, including business methods and EJB creation, removal, finding, activation, passivation, storage and loading Copyright UTS 2002 EJB EJB-29 Container EJB implementations (Skeletons and Delegates): The container manages the distributed communication skeletons used to marshal and unmarshal data sent to and from the client. Containers may also store EJB implementation instances in a pool, and use delegates to perform any service management operations related to a particular EJB before calls are delegated to the EJB implementation instance Copyright UTS 2002 EJB EJB-30

6 Enterprise Java Beans Today we will briefly cover Introduction to EJB EJB Basics EJB Architecture Session Beans EJB Clients EJB Development Process Next lesson we will cover Entity Beans Message Driven Beans EJB issues Session Beans Session beans are EJBs that are created to perform some action on the enterprise system, and possibly return a result set to the client. They model a connection (session) with a single client Session beans can be thought of as controllers for the system that are exposed to the client for manipulation Session beans can thus be thought of as the verbs of the particular problem domain that they are implemented to solve Session beans are well suited to encapsulate coarse-grained front line service entry points into a system Copyright UTS 2002 EJB EJB-31 Copyright UTS 2002 EJB EJB-32 Entity Beans Entity beans are EJBs that are created to encapsulate some data contained by the system (such as a row in the database or, more generally, to an entry that exists in persistent storage) Entity beans can be thought of as the nouns of a particular problem domain that they are implemented to solve The data can be created, searched for (found) or removed by clients Client (e.g. servlet) Session & Entity Beans EJB container BankTeller - deposit() - withdraw() BankManager - openaccount() Account - acctnum = getbalance() - setbalance() Account - acctnum = getbalance() - setbalance() Account - acctnum = getbalance() - setbalance() DBMS The data can also be retrieved and updated by clients Session Beans ("actions") Entity Beans ("data") Copyright UTS 2002 EJB EJB-33 Copyright UTS 2002 EJB EJB-34 Session Beans Now we focus on session beans Session Beans Session beans can be grouped into 2 distinct classifications: Session beans exist for the duration of one interaction with the client stateless interaction (no state) stateful interaction (remembers previous state) Session beans provide the "public" business logic methods of your application Session beans may be modelled on UML use cases or equivalent Copyright UTS 2002 EJB EJB-35 Stateless session beans: Stateless session beans represent session EJBs that are created with no regard for the maintenance of any state between calls by a client. Stateless session beans represent pure input / output engines Stateful session beans: Stateful session beans represent session beans that are created and maintain state during a session maintained with a client. The session is subject to time-out. Stateful session beans represent input / output engines that can utilise state information maintained for a client Session beans persist only for the life of the connection with the client if the server crashes, the session bean dies Copyright UTS 2002 EJB EJB-36

7 Session Beans You need to create three files: Remote interface (declares your business logic) Home interface (methods to create the bean) EJB implementation class (method implementations) Let's start with a stateless session bean the easiest kind package bank; import java.rmi.*; import javax.ejb.*; Remote interface interface BankTeller extends EJBObject { String sayhello() throws RemoteException; void deposit(string acctnum, Float amount) throws RemoteException; void withdraw(string acctnum, Float amount) throws RemoteException; These declare your bean's business logic methods! Copyright UTS 2002 EJB EJB-37 Copyright UTS 2002 EJB EJB-38 package bank; import java.rmi.*; import javax.ejb.*; Home interface Bean implementation class (1) package bank; import javax.ejb.*; public class BankTellerBean implements SessionBean { interface BankTellerHome extends EJBHome { public BankTeller create () throws RemoteException, CreateException; This defines the create() method, which will create an instance of a BankTeller bean when it is called Copyright UTS 2002 EJB EJB-39 SessionContext sessioncontext; // "Standard" session bean methods public void setsessioncontext (SessionContext sc) { this.sessioncontext = sc; public void ejbremove() { public void ejbactivate() { public void ejbpassivate() { // Argument list must match create() method in home interface public void ejbcreate() { // continued on next page Copyright UTS 2002 EJB EJB-40 Bean implementation class (2) // continued from previous page // Now the business logic methods (as defined in the Remote interface) public String sayhello () { String message; if (Math.random() > 0.5) { message = "Hi, how are you today?"; else { message = "Yeah, whaddya want?"; return (message); public void deposit (String acctnum, Float amount) { // do something clever here Stateless Bean code notes (1) The Remote interface defines the business methods of the bean The remote interface extends javax.ejb.ejbobject The Home interface defines the "create" methods for the bean, which are used to obtain the remote interface to the bean The home interface extends javax.ejb.ejbhome public void withdraw (String acctnum, Float amount) { // do something clever here Copyright UTS 2002 EJB EJB-41 Copyright UTS 2002 EJB EJB-42

8 Stateless Bean code notes (2) Your bean implementation class must implement the javax.ejb.sessionbean interface (which extends javax.ejb.enterprisebean) Stateless Bean code notes (3) one or more ejbcreate() methods called by the container to initialise the bean with the parameters from the client when it is created. A stateless session bean can only have a single, no-parameter method. This requires you to implement to implement the following methods (as well as your business methods) which are used by the container to create and manage your bean during its life: a parameterless constructor called by the container to create a new instance of the bean (Class.newInstance()) setsessioncontext() called by the container to pass environment context information to the bean Copyright UTS 2002 EJB EJB-43 ejbremove() called by the container to remove the bean. Stateless session beans are removed by the container at its own discretion ejbpassivate() called by the container when about to passivate the bean to conserve resources (passivated beans may be removed completely if a time-out period elapses). This method has no meaning for a stateless session bean, and is generally left empty ejbactivate() called by the container when about to activate a passivated bean (passivated beans are activated if a client request is received). This method has no meaning for a stateless session bean, and is generally left empty Copyright UTS 2002 EJB EJB-44 Stateful Session Beans Implementation-wise, a stateful session bean is basically identical to a stateless session bean The difference? For stateful beans: you should define some state, i.e. instance variables inside your business methods, you can manipulate the state (read and change the variable values) When a client create()'s a stateful session bean, that client is given their own personal instance of the bean that is used by the same client on successive method calls Stateful beans same basic rules To implement a stateful session bean, you need to create the bean s home interface, its remote interface and the bean implementation the same as for a stateless session bean Again, your bean implementation class must implement the javax.ejb.sessionbean interface (which extends javax.ejb.enterprisebean) Again, your bean implementation class must implement the methods from SessionBean (as well as your business methods) which are used by the container to create and manage your bean during its life Copyright UTS 2002 EJB EJB-45 Copyright UTS 2002 EJB EJB-46 Stateful Beans differences! For stateful session beans, you may wish to perform some state management tasks in the ejbpassivate() and ejbactivate() methods e.g. save the state to a disk file (or DBMS) during passivation, and load it back again during re-activation Stateful session beans are only removed when the client calls ejbremove() the container will not remove stateful session beans unless they time-out ejbremove() not called if the bean is in the passive state (container may simply reclaim the secondary storage) may call ejbremove() (not required) if not in passive state Copyright UTS 2002 EJB EJB-47 Stateful Beans how not to use Stateful session beans do NOT represent the data in your application data is represented by Entity Beans stateful session beans are transient they come and go. Data is meant to be persistent if a server crashes unexpectedly, a stateful session bean will be destroyed with the crash (same for stateless session beans). Data is meant to be persistent. Copyright UTS 2002 EJB EJB-48

9 Session Beans modelling When do you use stateless beans vs. stateful beans? In most cases, it depends on how you choose to model your application Consider the bank teller examples on the next two slides one is stateful, one is stateless Client (e.g. servlet) EJB container create(1234) deposit($100) Stateful Scenario BankTeller - deposit() - withdraw() account# = 1234 Copyright UTS 2002 EJB EJB-49 Copyright UTS 2002 EJB EJB-50 Teller Example 1 stateful Scenario: When you walk up to a bank teller, you tell him/her your account number. You can then perform any number of deposits and withdrawals with that teller, without having to tell him/her the account number again each time he/she remembers it When you create() the BankTeller EJB, you supply: the account number Client (e.g. servlet) EJB container create() deposit(1234,$100) Stateless Scenario BankTeller - deposit() - withdraw() When you call deposit() and withdraw(), you pass only one parameter: the amount When you call deposit() or withdraw(), it uses ("remembers") the account number that you specified at creation time Copyright UTS 2002 EJB EJB-51 Copyright UTS 2002 EJB EJB-52 Teller Example 2 stateless Scenario: When you walk up to a bank teller, you don't give him/her any information. You can perform any number of deposits and withdrawals, but each time, you must specify your account number. He/she does NOT remember your account number from one transaction to the next When you create() the BankTeller EJB, you supply: nothing When you call deposit() and withdraw(), you pass two parameters every time: account number and amount Stateless vs. stateful implications With the stateless teller, each time you perform a transaction, you can go to any teller The teller you go to doesn't "remember" anything about you, so you can go to a different one each time EJB containers create a pool of stateless session beans, and every time a client calls a method, that method is directed to any bean in the pool With the stateful teller, you must go back to the same teller each time because that teller knows your account number. If you go to a different teller, they won't know what your account number is EJB containers assign one stateful session bean to every client There is a one-to-one correspondence between clients and stateful session beans no pooling! Copyright UTS 2002 EJB EJB-53 Copyright UTS 2002 EJB EJB-54

10 Enterprise Java Beans Today we will briefly cover Introduction to EJB EJB Basics EJB Architecture Session Beans EJB Clients EJB Development Process Next lesson we will cover Entity Beans Message Driven Beans EJB issues EJB Clients In the EJB architecture, the client undertakes the following tasks: 1. Finding the bean (get the Home interface) 2. Getting access to the bean (get the Remote interface) 3. Calling the bean s methods (call Remote interface methods) 4. Getting rid of the bean A client can be co-located with the bean, e.g. another EJB, Java class or web application component running in the same application server or remote, e.g. a standalone Java application or a component running in another application server Copyright UTS 2002 EJB EJB-55 Copyright UTS 2002 EJB EJB Finding the bean The first thing a client needs to do to use a bean is to find the bean This is done using JNDI to look for the advertised name of the bean's home interface When the EJB is looked up, the call returns an object implementing the EJB s home interface, which can be used to gain access to the EJB itself 2. Getting access to the bean The client can now use the home interface to either: create a new instance of the bean find an existing instance of the bean Session beans are always created "fresh" when you need one (finding existing instances is for entity beans later!) These actions return an object implementing the bean s remote interface, which can be used to interact with the EJB Copyright UTS 2002 EJB EJB-57 Copyright UTS 2002 EJB EJB Calling the bean's methods Now the client has a remote interface, it can invoke the methods the bean has made public i.e. the methods defined in the Remote interface 4. Getting rid of the bean Stateless session beans are automatically removed by the container at its discretion no problem they don't hold any state info Stateful session beans must be removed explicitly by the client by calling the remove() method on the object The remove() method is defined on the Home interface Container won't remove these automatically because they contain valuable state information your application needs to decide when it is finished with the state info Copyright UTS 2002 EJB EJB-59 Copyright UTS 2002 EJB EJB-60

11 Enterprise Java Beans Today we will briefly cover Introduction to EJB EJB Basics EJB Architecture Session Beans EJB Clients EJB Development Process Next lesson we will cover Entity Beans Message Driven Beans EJB issues EJB Development Process Checkpoint! Until now we have considered: what EJBs are, what the different kinds are what containers do and why they're a "good thing" what session beans look like and how they're used Now we change focus and look at the EJB development process same process for all kinds of EJBs Copyright UTS 2002 EJB EJB-61 Copyright UTS 2002 EJB EJB-62 EJB Development Steps The steps to be followed when developing an EJB can be partitioned into 2 streams server side and client side development Server-side development of EJBs is simpler than it is for RMI, as much of the communications, state management, resource allocation and thread management infrastructure coding is provided by the container It may not look simpler, but it is (trust me) EJB Development Steps (1) 10 steps involved in server-side EJB development: 1. Create the remote interface - Defines business methods 2. Create the home interface - Defines create/find methods 3. Create the EJB implementation class - implements the bean 4. Compile the java code Copyright UTS 2002 EJB EJB-63 Copyright UTS 2002 EJB EJB-64 EJB Development Steps (2) EJB Development Steps (3) 5. Write the EJB deployment descriptor - create an ejb-jar.xml file and maybe others 6. Package the EJB into a JAR file - EJBs get packaged in JAR files 7. Compile the EJB stubs - use an EJB compiler tool 8. Configure the J2EE application deployment descriptor - deployment descriptor for the whole application, not the EJB 9. Package the EJB JAR into an EAR file (optional) - "applications" are packaged in EAR files 10. Deploy the EJB JAR or J2EE application EAR - deploy to the application server Copyright UTS 2002 EJB EJB-65 Copyright UTS 2002 EJB EJB-66

12 Client Development Steps 4 steps for writing EJB clients: 1. Establish the proper EJB client libraries make available the correct versions of appropriate libraries for the client JNDI, EJB, RMI/IIOP and possibly JMS and JDBC if required 2. Generate EJB client interfaces make available the compiled interfaces and stubs for the EJB to the client 3. Implement client code create your client application using the EJB client libraries and your EJB client interfaces 4. Compile / package / deploy the client as appropriate for the client type 1. Create Remote interface package bank; import java.rmi.*; import javax.ejb.*; interface BankTeller extends EJBObject { String sayhello() throws RemoteException; void deposit(string acctnum, Float amount) throws RemoteException; void withdraw(string acctnum, Float amount) throws RemoteException; (Same as previous example) Copyright UTS 2002 EJB EJB-67 Copyright UTS 2002 EJB EJB-68 package bank; import java.rmi.*; import javax.ejb.*; 2. Create Home interface interface BankTellerHome extends EJBHome { public BankTeller create () throws RemoteException, CreateException; 3. Create EJB implementation package bank; import javax.ejb.*; public class BankTellerBean implements SessionBean { //... same as before... (Same as previous example) (Same as previous example) Copyright UTS 2002 EJB EJB-69 Copyright UTS 2002 EJB EJB Compile Java code javac d. *.java 5. Write EJB deployment desc. Standard deployment descriptor (META-INF/ejb-jar.xml) EJB name Java class names for remote interface, home interface and bean implementation class Whether bean is session or entity For session beans, whether bean is stateful or stateless Container-specific deployment descriptor (META-INF/weblogic-ejb-jar.xml) For WebLogic stateless session beans, size of pool JNDI name (name by which the bean is advertised to clients) Copyright UTS 2002 EJB EJB-71 Copyright UTS 2002 EJB EJB-72

13 <?xml version="1.0"?> 5a. ejb-jar.xml 5b. weblogic-ejb-jar.xml <?xml version="1.0"?> <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN' ' <ejb-jar> <enterprise-beans> <session> <ejb-name>banktellerejb</ejb-name> <home>bank.banktellerhome</home> <remote>bank.bankteller</remote> <ejb-class>bank.banktellerbean</ejb-class> <session-type>stateless</session-type> <transaction-type>container</transaction-type> </session> </enterprise-beans> <assembly-descriptor> <container-transaction> <method> <ejb-name>banktellerejb</ejb-name> <method-intf>remote</method-intf> <method-name>*</method-name> </method> <trans-attribute>required</trans-attribute> </container-transaction> </assembly-descriptor> </ejb-jar> Copyright UTS 2002 EJB EJB-73 <!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic EJB//EN' ' <weblogic-ejb-jar> <weblogic-enterprise-bean> <ejb-name>banktellerejb</ejb-name> <stateless-session-descriptor> <pool> <max-beans-in-free-pool>100</max-beans-in-free-pool> </pool> </stateless-session-descriptor> <jndi-name>ejb/bankteller</jndi-name> </weblogic-enterprise-bean> </weblogic-ejb-jar> Copyright UTS 2002 EJB EJB Package EJB as a JAR file Same concept as for WAR files but EJBs are packaged in JAR files EJB deployment descriptors must be contained in a sub-directory off the root called "META-INF" Directory structure in JAR must mirror Java package structure (as per normal Java rules) jar cf../myejb.jar * 7. Compile EJB stubs Run appc (weblogic EJB compiler) on the EJB JAR file - this generates and compiles stubs and skeletons java weblogic.appc MyEJB.jar Different development tools may have different ways of compiling the EJB code and generating stubs/skeletons Copyright UTS 2002 EJB EJB-75 Copyright UTS 2002 EJB EJB Configure app deployment desc. 9. Package app as an EAR file In J2EE terms, an "application" consists of: We'll come back to this next session (see next slide for a brief outline) one or more WAR files containing servlets and JSPs Suffice to say that this is an optional step, and for now, we're going to leave it out! one or more JAR files containing EJBs A collection of WARs and JARs that comprise a single application may be packaged in an EAR file EAR = Enterprise Application Archive We'll come back to this next session Copyright UTS 2002 EJB EJB-77 Copyright UTS 2002 EJB EJB-78

14 10. Deploy Deploy your JAR file into the application server In WebLogic, either: copy the JAR file into your autodeploy" subdirectory run the command line tool to deploy the file upload the file via the management console Exactly the same process as deploying WAR files If all goes well, in the management console you should see: a new EJB appear under the "Deployments > EJB" menu a new entry appear in the JNDI tree EJB Development There are quite a few steps, but each is simple You will probably find it useful to create a short shell script / batch file to run the various commands (I use ant to do this) what is ant? - a build tool similar to makefiles on Unix The most common error is typos in the XML deployment descriptor Running appc will pick up many errors Use an XML editor to reduce syntax errors Copyright UTS 2002 EJB EJB-79 Copyright UTS 2002 EJB EJB-80 Naming Conventions Item Syntax Example Enterprise bean name <name>ejb BankTellerEJB EJB JAR deploy name <name>jar BankTellerJAR Enterprise bean class <name>bean BankTellerBean Home Interface <name>home BankTellerHome Remote Interface <name> BankTeller Local home interface Local<name>Home LocalBankTellerHome Local interface Local<name> LocalBankTeller Abstract Schema <name> BankTeller EJB 3.0 Part of Java EE 5 Significantly simplifies EJB development Use Java 5 annotations. Assumes common defaults for most infrastructure classes/methods Removes the need to develop separate Home/Remote interfaces You write your bean as a POJO (Plain Ol Java Object). You put one of the following annotations before the Stateless session bean Statefull session bean Message bean Entity bean (See JPA) Copyright UTS 2002 EJB EJB-81 Copyright UTS 2002 EJB EJB-82 EJB 3.0 Just plain old Java Objects! Eg: public interface BankTellerRemote { public string sayhello(string BankTeller ) public class BankTeller implements BankTellerRemote { public string sayhello(string name) { return Hello, + name; Note: no XML, no housekeeping code! Summary EJB Part 1 Reflect on how little code was required only 3 Java files, 2 of them very simple plus 2 deployment descriptors EJB 3 makes this even simpler Hard part about EJB is understanding: the J2EE architecture and how to model the real world how EJBs are invoked / loaded / etc. what the container does Copyright UTS 2002 EJB EJB-83 Copyright UTS 2002 EJB EJB-84