1. 1 Java EE Programming Deploying Enterprise JavaBeans

2. 2 Topics Deployment XML Enterprise Entity Beans Case Study How to deploy the Advisor Bean

3. 3 The Contents of an Enterprise Bean To develop an enterprise bean, you must provide the following files: Deployment descriptor: An XML file that specifies information about the bean such as its persistence type and transaction attributes. The deploy tool utility creates the deployment descriptor when you step through the New Enterprise Bean wizard. Enterprise bean class: Implements the methods defined in the following interfaces. Interfaces: The remote and home interfaces are required for remote access. For local access, the local and local home interfaces are required. For access by web service clients, the web service endpoint interface is required. Helper classes: Other classes needed by the enterprise bean class, such as exception and utility classes.

5. 5 Deployment Descriptors Involves packaging the byte-code (.class) files together with an EJB Deployment Descriptor Deployment Descriptor is represented using XML Let’s look at some basic XML concepts...

6. 6 XML The EXtensible Markup Language (XML) provides a convenient modeling language for representing declarative data within a computer application. XML provides a domain independent way of representing data that is easy for humans to read and software to parse. The particular representation of data used in any XML document requires an a priori agreement among the producers and consumers of the data and in the case of EJB Deployment Descriptors is defined by the EJB specification. As a complete description of XML is beyond the scope of this course and tutorials are readily available on the Internet, we will use a simple example to introduce the basics of XML.

7. 7 XML Consider the following data: UML 2 and the Unified Process Jim Arlow and Ila Neustadt 2nd 2005 0-321-321278 Pearson Education, Inc. Upper Saddle River, NJ Take a moment to look at the example data again, but this time consider how is it that you already understand what this data means and how easy it is for you to answer questions such as who are the authors or what is the copyright date? Simplistically, you might suggest that the structural format of this data, your understanding of the tokens/words and their combinations, and your prior experience with similar examples contribute to your ability to understand this data.

8. 8 Simple XML Example XML provides this alternative approach by marking up the data with pre-defined tags that label the data. Here’s an XML version of the previous data: <Book title=”UML 2 and the Unified Process” edition=”2” copyright=”2005” isbn=”0-321-321278”> <Address city=”Upper Saddle River” state=”NJ”/>

9. 9 Simple XML Example Although this XML version of the data is more cumbersome to read, it does have a number of useful features: It is reasonable easy for a human to read and understand the data It is very easy to write a computer program that can parse this data (e.g., locating the authors or the copyright date of the book, or for that fact, even knowing that the data represents a book), It uses a standardize format to structure the data.

10. 10 XML Basics XML represents data using elements and attributes of these elements. Consider the following XML fragment from the example in the preceding slide: <book title=”UML 2 and the Unified Process” edition=”2” copyright=”2005” isbn=”0-321-321278”> The XML element in this example is a book and this book element contains four attributes. The syntax of XML dictates that elements begin with a start tag that consists of a less-than sign immediately followed by the name of the element, an optional list of unique attributes, and a greater than sign. Each attribute in an element, if any, consists of an attribute name followed by an equal sign and the value of the attribute, which is typically enclosed in double quotes.

11. 11 XML Basics The semantics of XML require that the starting tag of all elements be followed an end tag that consists of a less than sign, followed by a slash, the name of the element and a greater than sign, e.g.,. The information, if any, between an element’s start and end tag is referred to as the element’s content. If an element has no content, referred to as being empty, then for convenience XML allows an empty element tag. That is, for all practical purposes, the following two XML statements are equivalent: and

12. 12 Deployment Descriptors As you may recall, one of the goals of middleware EJB environments is to allow software engineers to focus primarily on business solutions by freeing them from the tedious details required to deploy large-scale enterprise applications. One way to help simplify the deployment of enterprise beans is to make certain aspects of the deployment process data driven and, consequently, declarative in nature. For example, as opposed to writing the code required to support transaction process within, and among beans, it is simpler to simply declare that a bean has a certain transactional processing capability and let the EJB container automatically generate the code required to support this capability. Within an EJB environment, these declarations are made in an XML file containing a Deployment Descriptor.

13. 13 Deployment Descriptors Java 2 platform, Enterprise Edition (J2EE) enterprise applications are made up of one or more individual J2EE modules. J2EE modules have deployment descriptors specific to the module type, and J2EE enterprise applications also have their own deployment descriptor format. J2EE EJB application module deployment descriptors are defined in XML files named ejb-jar.xml.

14. 14 Deployment Descriptors – EJB JAR Files The top-level elements of an EJB deployment descriptor are elements used to define EJB application metadata EJB structure assembly information and the archive filename for any EJB client files

15. 15 EJB JAR Files An EJB JAR file represents the deployable JAR library that contains the server-side code and configuration of the EJB module. During deployment, the ejb-jar.xml file is placed in the META-INF directory of the EJB JAR file. Any entity and session beans defined within the ejb-jar.xml file must have the.class files for their implementations, home interfaces, and remote interfaces, as well as any dependent classes, archived inside the EJB JAR file.

16. 16 EJB JAR Files Any client stub and interface classes needed to access the EJBs in a particular EJB JAR file can be placed in a separate EJB client JAR file. The URL of this EJB client JAR file can then be specified in the ejb-jar.xml file's element. Any EJB clients of the EJBs in the associated server- side EJB JAR file can then automatically receive downloaded interface and stub classes as they are needed if the EJB client's class loader can reach the URL defined within the element. If no automatic class-downloading mechanism is supported or used by the client, the EJB client JAR libraries should be installed on the EJB client's machine.

17. 17 Application Deployment Descriptor: ejb-jar.xml

18. 18 Other Method – use * AdvisorEB * Required Instead of defining one for each method – use the “*” – much easier!

19. sun-ebj-jar.xml (Vendor-Specific Jar file)

20. 20 EJB Deployment Procedures (Vendor Independent) The process for deploying J2EE applications involves establishing: environment variables, configuring server properties, compiling Java code, creating XML-based deployment descriptors, packaging archive files, and deploying archives to a J2EE server environment.

21. 21 EJB Deployment Procedures (Vendor Independent) 1.Set J2EE server environment variables—Environment variables must be set for running a J2EE server environment and vary per vendor implementation and operating-system platform. 2.Configure J2EE server properties—Configuration properties for most J2EE server implementations can be set to suit your particular network and operating environment. 3.Compile J2EE EJB application code—All J2EE EJB implementation, home, remote, and dependent utility code must be compiled using a standard Java compiler. 4.Create a J2EE EJB application deployment descriptor—An XML-based deployment descriptor is created according to the EJB application DTD. Some vendor products can create this file for you from a GUI-based configuration tool.

22. 22 EJB Deployment Procedures (Vendor Independent) 5.Create vendor-specific deployment descriptors—Because no standard means exists to bind J2EE standard EJB reference names to a J2EE server's JNDI-based naming service, a vendor-specific deployment descriptor mechanism is required to perform this mapping. This deployment descriptor must map EJB reference names used by J2EE components to the actual JNDI names associated with EJB home interfaces. Other vendor-specific properties may also be set for customizing both session and entity beans. Vendors may provide a GUI-based means to configure these files. 6. Package J2EE EJB application code—The EJB deployment descriptors, all compiled J2EE EJB implementation classes, all compiled J2EE EJB implementation interfaces, and all other compiled classes dependent on your EJBs need to be packaged into an EJB JAR file with a.jar extension. J2EE-based products might supply command-line or GUI- based utilities for this purpose. 7. Start the J2EE server—The J2EE-compliant server must generally be started at this stage. The exact mechanism for starting a server is often vendor-dependent but can be as simple as invoking a single startup command from the command line.

23. 23 EJB Deployment Procedures (Vendor Independent) 8.Create a J2EE application deployment descriptor—A J2EE application deployment descriptor must be created to collect one or more Web, EJB, and application client modules into a cohesive J2EE application. Many products will create this file for you automatically or via a GUI-based configuration tool. 9.Package J2EE application code—The application and JNDI mapping deployment descriptor, Web applications, EJB applications, and application clients need to be packaged into an enterprise archive (EAR) file with an extension of.ear. Many products also create this archive for you automatically or via GUI- based development tools. 10.Deploy the J2EE enterprise application code—Finally, the integrated J2EE application is deployed to the J2EE server environment for access by enterprise application clients. This step is also often automated via GUI tools.

24. 24 SEN 974 Client/Sever and the Internet Session Beans JSP Tutorial

25. 25 Session Beans (SB) Session Beans are a set of objects that implement the business logic of an application SBs tend to be responsible for a group of related functionality Not using persistent storage

26. 26 Types of Session Beans Stateless Beans Do not care declare any instance (class-level) variables so that the methods contained within can only act upon any local parameters There is no way to maintain state across method calls Provide excellent scalability because EJB container does not have to keep track of their state across method calls Ex: Provide some generic service to clients like signing in or a Catalog bean – browsing different products and categories – generic to any client

27. 27 Types of Session Beans Stateful Beans Can hold client state across method invocations – contains conversational state on behalf of the client Possible with the use of instance variables declared in the class definition of session bean Client will then set the values for these variables and then use these values in other method calls Storing the state of an EJB is very resource intensive – therefore does not scale as well as stateless beans Ex: Shopping Cart for an online store

28. 28 Decisions, Decisions... How do you decide whether a given enterprise bean should be a session or entity bean? Session beans are great at implementing business logic, processes, and workflow Ex: StockTrader bean with buy() and sell() methods Entity bean are the persistence data objects of the EJB application Ex: getPrice() and setPrice() StockTrader SB could call the above methods in the EB

29. 29 Decisions, Decisions... It is good practice to have the client only interface with session beans and the session beans interface with the entity beans for these reasons: Single point of entry for the client Calling entity beans directly tends to push the business logic into the UI logic UI doesn’t have to be as dependent upon changes to the entity beans – session beans shield the UI from these changes There are usually many more entity beans so restricting client access to session beans conserves server and network resources considerably

30. 30 Anatomy of a Session Bean UI calls the methods of the session bean as it requires the functionality they provide. Session beans can call other session beans and entity beans

31. 31

32. 32 Java Server Pages Overview

33. 33 JSP Resources Sun’s website http://java.sun.com/products/jsp/docs.html J2EE 1.4 Tutorial Search the site for JSP – there are whitepapers, articles, blueprints (best practices), etc. Free Online Books http://www.coreservlets.com Free Online books – they are the previous rev but most of the information is relevant and the author indicates where it is not. Register with email address Others: http://www.jsptut.com http://www.theserverside.com/articles/index.tss

34. 34 J2EE and EJB Resources Sun’s Resources: EJB Specification http://java.sun.com/products/ejb/ - Want the EJB 2.1 Spec http://java.sun.com/products/ejb/ J2EE 1.4 Tutorial (Update 7) http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html J2EE Documentation http://java.sun.com/j2ee/1.4/docs/index.html API http://java.sun.com/j2ee/1.4/docs/api/index.html Bean Training http://java.sun.com/developer/onlineTraining/Beans/bean01/index.ht ml http://java.sun.com/developer/onlineTraining/Beans/bean01/index.ht ml Other: http://my.execpc.com/~gopalan/java/ejb.html www.javaworld.com