1 CS 483 Enterprise and Web Application Programming Week 4 Deploying Enterprise JavaBeans

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

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 thebean such as its persistence type and transaction attributes. The deploytool 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 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 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. It is only important that you know enough XML to be able to understand the examples introduced this week.

7 XML Consider the following data: UML 2 and the Unified Process Jim Arlow and Ila Neustadt 2nd 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 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=” ”> <Address city=”Upper Saddle River” state=”NJ”/>

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 nomenclature and format to structure the data, albeit one invented by the author of this course.

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=” ”> 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 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 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. Sun (2006) notes that “the role of the deployment descriptor is to capture declarative information that is not included directly in the enterprise bean’s code and that is intended for the consumer of the ejb-jar file.2006

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 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 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 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 Application Deployment Descriptor: ejb-jar.xml

18

19

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

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

22 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.

23 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.

24 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.

25 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.

26 J2EE and EJB Resources Sun’s Resources: EJB Specification - Want the EJB 2.1 Spec J2EE 1.4 Tutorial (Update 7) J2EE Documentation API Bean Training ml ml Other: