1. J2EE Overview

2. Objectives
After completing this lesson, you should be able to do the following:
Describe the Java™ 2, Enterprise Edition (J2EE) platform
Define the various components of J2EE
Describe the deployment options for a J2EE application
Describe the architecture of Oracle Application Server 10g Containers for J2EE (OC4J)
Describe the directory structure and the uses of the configuration files of OC4J
Objectives
This lesson discusses each of the components of the J2EE architecture and examines its purpose in a J2EE application. J2EE applications are deployed to a J2EE server such as Oracle Application Server 10g. This lesson also describes the configuration and structure of Oracle Application Server 10g Containers for J2EE.

3. Java 2, Enterprise Edition Platform
The Java 2, Enterprise Edition (J2EE) platform is a standard for developing and implementing enterprisewide applications:
It provides multitier applications support.
It is designed to help improve the process of developing, deploying, and implementing enterprisewide applications.
Java 2, Enterprise Edition Platform
J2EE is a complete application architecture for enterprise class applications. It was first proposed by Sun Microsystems and has been included in the Java Community Process to make it a part of the open systems movement.
J2EE emphasizes a portable, component-based approach to the creation, deployment, and management of complex applications. J2EE supports components on four tiers: client, Web, business, and the Enterprise Information System (EIS).

4. J2EE Platform Is a multitiered, distributed application model
Supports component-based J2EE applications
Middle tier
Web components
Servlet
Client tier
Web clients
Browser
JSP Page
EJB clients
EJB components
Enterprise Beans
Application
J2EE Platform
J2EE defines a platform for developing, deploying, and executing applications in a multitiered, distributed application model. That is, the application logic of a J2EE application can be divided into components based on their functions and distributed to the appropriate tier on the multitiered architecture.
The slide shows a standard multitiered J2EE application model where the application logic is distributed into the following tiers:
Client-tier components, such as a Web browser, run on the client machine.
Presentation logic is built with Web-tier components such as JavaServer Pages (JSP) and Java servlets that run on the J2EE server.
Server-side business logic is distributed as business-tier components that run on the J2EE server. Enterprise JavaBeans (EJB) and the J2EE framework Business Components for Java (BC4J) are examples of business-tier components.
Data is stored in the Enterprise Information System (EIS) tier that runs on the database server, such as Oracle Database 10g.
The J2EE application components are developed in Java programming language. When the J2EE platform is used, the J2EE components are assembled into a J2EE application, verified according to the J2EE specification, and deployed to the J2EE server. The deployed applications are run and managed by the J2EE server.
EIS tier

5. Benefits of the J2EE Platform
“Write once, run anywhere” provides simplified component development.
Multiple server products and vendors support the J2EE standard, thus giving more deployment choices.
Integration with legacy systems through standard APIs is possible.
J2EE separates client requirements from business logic.
J2EE provides multiple development and design scenarios.
Benefits of the J2EE Platform
J2EE takes advantage of many features of Java 2 Platform, Standard Edition (J2SE), such as the “write once, run anywhere” portability. This portability is ensured because there are multiple vendors who support the J2EE specification, making it easy to integrate distributed applications. J2EE separates business and presentation logic, making the applications easier to maintain. There are several design choices for J2EE development, including varied client access. This is discussed later in the course.
The vendors who provide the J2EE platform (Database, Application Server) are called “J2EE Product Providers.” A vendor or person who creates Web components, enterprise beans, or application clients for use in J2EE applications is called an “Application Component Provider.” A “Tool Provider” is a vendor who creates development, assembly, and packaging tools that are used by the Component Providers. These names are assigned along with various other J2EE roles that are discussed in the next slide.

6. Benefits of the J2EE Platform
J2EE separates development tasks into specific skill areas.
Web designers can create JSP components.
Application behavior is created by Java programmers.
Business logic and rules are created by Java programmers and business experts.
Assembly and deployment can be assigned to production environment teams.
Benefits of the J2EE Platform (continued)
The J2EE platform allows for developer specialization by component type and functionality. For example, an EJB developer can create business logic, focusing on the business rules of the enterprise. These EJBs are used by Web component developers, who focus on the presentation of data and the user interface. These components are assembled by an “Application Assembler,” who is responsible for the deployment and administration of the application.
An “Application Deployer” is the company or person who configures and deploys the J2EE application. An “Application Administrator” is a person who administers the computing and networking infrastructure where the J2EE applications run.

7. J2EE Components
J2EE is a component-based architecture for the development and deployment of enterprisewide applications.
A component is an application-level software unit.
Components can be easily updated as business needs change.
Components are reusable.
There are several types of components:
Client-side components
Web components
Business-tier components
J2EE Components
There are several types of J2EE components. This course focuses on the most widely used components, those of the Web and the business tier. These components are reusable, that is, they are available to other components and applications. For example, the business rules that are included in a software component called “Process Order” can be used by multiple applications that allow customers to order the products or services of a company.

8. J2EE 1.3 Components
The J2EE 1.3 Specification lists the following components:
Servlet 2.3
JavaServer Pages 1.2
Enterprise JavaBeans 2.0
JDBC 2.0
RMI-IIOP
JNDI 1.2
Web services 1.1
Java Message Service 1.0.2
Java Transaction API 1.0
Java Authentication and Authorization Service 1.0
J2EE Connector Architecture 1.0
SOAP with Attachments API for Java 1.1
J2EE 1.3 Components
The slide above shows many of the components that are listed in the J2EE 1.3 Specification. A description of these components is provided on the next page. Additionally, the following components are also included in the specification:
JavaMail 1.2
Java IDL 1.0
Java API for XML Parsing (JAXP) 1.1

9. J2EE Architecture J2EE Server Client Machine Web Container Browser
The J2EE architecture provides a component-based and platform-independent environment, in which each component is assembled and deployed into its corresponding container. The J2EE server provides services to handle transaction and state management, multithreading, resource pooling, and other complex low-level details, in the form of these containers. Because these underlying services are provided by the J2EE server, the developer can concentrate on solving business problems.
J2EE components communicate with each other by using several APIs. The J2EE architecture provides the following APIs to support remote procedure calls:
Java Naming and Directory Interface (JNDI): Provides naming and directory functionality to applications written in Java
Remote Method Invocation (RMI): Enables you to create distributed Java technology–based applications, in which the methods of remote Java objects can be invoked from other Java virtual machines, possibly on different hosts
Java Database Connectivity (JDBC): Enables you to access any tabular data source such as database, spreadsheets, or flat files from the Java programming language
Java Transaction API (JTA): Specifies standard Java interfaces between a transaction manager and the parties involved in a distributed transaction system: the resource manager, the application server, and the transactional applications
Java Messaging Services (JMS): Enables applications to create, send, receive, and read messages by defining a common set of interfaces and associated semantics that allow programs written in the Java programming language to communicate with other messaging implementations
JavaMail: Provides a set of abstract classes that model a mail system. The API provides a platform-independent and protocol-independent framework to build Java technology-based mail and messaging applications.
JavaBeans Activation Framework (JAF): Provides standard services to determine the type of an arbitrary piece of data, to encapsulate access to it, to discover the operations that are available on it, and to instantiate the appropriate bean to perform the said operations. For example, if a browser obtains a JPEG image, this framework enables the browser to identify that stream of data as a JPEG image. Then the browser can locate and instantiate an object that can manipulate or view that image. Additionally, the JavaMail API uses the JAF API for data content handling.
J2EE Architecture
J2EE Server
Client Machine
Web Container
Browser
Java Servlet/JSP
Application
Client
Container
Application
Client
EJB
EJB
Business container
APIs
JNDI
JTA
JMS
Database
RMI
JDBC
JAF
JavaMail

10. Client-Tier Components
A Web browser:
Is used for a Web-based J2EE application
Downloads static or dynamic Web pages from Web-tier components
Is a thin client
An application client:
Is used for a non-browser-based J2EE application
Executes on the client machine
Can contain a graphical or command-line interface
Is a thick client
Accesses business-tier components or a servlet on the Web tier
Client-Tier Components
Web Browser Client
For a Web-based J2EE application, the user’s Web browser is the client component. The Web browser downloads static or dynamic Web pages from the Web tier to a client machine.
Dynamic Web pages are generated by servlets and JSPs from the Web tier. JSPs do not require Java plug-ins or security policy files to be downloaded to the client machine.
A downloaded Web page can contain an embedded applet that executes in the Java Virtual Machine (JVM) in the Web browser. An applet may require a Java plug-in and a security file to successfully execute in the user’s Web browser.
Web-based clients are typically thin clients, which do not perform operations such as executing complex business rules, connecting to the database, and querying the database. These operations are generally performed by business-tier components.
Application Client
An application client executes on a client machine for a non-browser-based J2EE application. It can contain a graphical user interface (GUI) created from Swing or Abstract Window Toolkit (AWT) APIs or a command-line interface. Application clients can directly access business-tier components. They can also access a servlet that is running in the Web tier through an HTTP connection.

11. J2EE Web-Tier Components
A Web tier may consist of:
Java servlets
JSPs
Servlets and JSPs:
Work on a request-response model
Generate HTML dynamically
Access the database through JDBC
Access the business-tier components
Handle user-centric events, such as an HREF link or form submission
Usually generate visual interfaces such as a Web page
Web-Tier Components
J2EE Web-tier components can be either servlets or JSPs that can statically and dynamically generate HTML, Wireless Markup Language (WML), or Extensible Markup Language (XML) pages. Java servlets provide a simple yet powerful API for generating Web pages by dynamically processing the client requests and constructing responses. JSPs simplify the process of dynamically generating the content, by allowing Java as the scripting language inside HTML pages. JSPs are translated and compiled into Java servlets, which are then run in a Web server like any other servlet.
Web components can access the business-tier components that access the database by using JDBC. Web components can handle requests from the client, such as form submission. Some advantages of using Web components are listed below:
The HTML interface that is generated by a Web component is lightweight when compared with the applets that require heavyweight downloads to the clients at run time. Also, the HTML interface does not require prior installation on the client machines, whereas the conventional clients require redeployment of the applications on the client machines.
The HTTP protocol, over which the client’s request for Web pages are served, can pass through most firewalls.

12. Web-Tier Components (continued)
Thus, a combination of Web components and EJBs allows:
Presentation logic for generating Web pages through Web components
Transactional business logic through EJBs

13. Format results and produce HTML Send page back to client
What Is a Servlet?
Browser
Servlet
Client info (host name,
form data)
Success or failure
Process results
(access database)
Format results and produce HTML
Send page back to client
Request
What Is a Servlet?
A servlet is a Java program that runs on a server, such as Oracle Application Server 10g, and produces dynamic pages typically in response to client requests. The pages are then sent back to the client’s Web browser. Typically, the output format for servlets is HTML, but any other output format, including XML, can be used.
Before returning HTML pages, a servlet can perform any operation that a Java application can perform. For example, in a business environment, servlets access the database through JDBC, so that you can send custom HTML pages and forms with embedded data to your end users.
Because servlets contain Java code, they are best suited for programs that perform more processing than presentation. Presentation is best left to JSPs, which are discussed in the next slide.
Response

14. What Is a JavaServer Page (JSP)?
A JSP:
Is a text-based document that includes:
HTML
JSP tags
Java code (including calls to JavaBeans and servlets)
Cleanly separates content creation from presentation logic
Focuses on rapid development and easy modification of the user interface
Provides presentation-centric method of developing servlets
What Is a JavaServer Page (JSP)?
JSPs are servlets that are written differently. The JavaServer Pages technology separates the user interface from dynamic content generation, so that designers can easily change the overall page layout without altering the dynamic content. JSP technology supports a reusable component-based design, making it easy and fast to build Web-based applications.
A key feature of the JavaServer Pages technology is simplified page generation: HTML-like tags and scriptlets written in the Java programming language encapsulate the logic that generates the content for the page. By separating the presentation design from the application logic that generates the data, JSP-enabled pages make it easier for organizations to reuse and share application logic through custom tags and JavaBeans-based components. This also separates the job responsibilities of the Web designer and the Java programmer. For example, custom tags and beans can be developed by the Java programmer and implemented by the Web designer.

15. Web-Tier Components: Summary
Web-tier components generate dynamic content.
Servlets:
Extend Web server functionality
Are designed more for processing than for presentation
JSPs:
Combine HTML (or other markup) and Java
Are designed to separate content creation from presentation logic
Are precompiled and converted to servlets at run time

16. Business-Tier Components
Are EJBs
Handle business logic
Receive data from client programs
Retrieve data from database storage
Process the data and communicate with the database and the client program
Can be invoked by the Web-tier components
Business-Tier Components
EJBs are the components that run in the business tier. These distributed components contain business logic that meets the needs of a particular business domain such as banking, order entry system, or human resources management. The business-tier components can receive data from client programs, process the data, and send the processed data to the database server for storage. The business-tier components can also retrieve data from the database, process it, and send it back to the client program.
The Web-tier components might invoke the business-tier components where the business logic is handled. For example, a servlet might invoke an enterprise bean to insert new customer details and return any processed data back to the client.

17. Enterprise JavaBeans (EJB)
Are server-side components written in Java
Contain the business logic of an enterprise application
Are hosted in EJB containers
Are based on Remote Method Invocation (RMI) communication
Are platform independent
Provide remote services for clients
Can be exposed as Web services
Use JDBC to connect to a database
Enterprise JavaBeans (EJB)
Enterprise JavaBeans (EJB) is an architecture for developing transactional applications as distributed components in Java. EJB is a powerful development methodology for distributed application development. When applications are developed with enterprise beans, neither the bean developer nor the client application programmer needs to be concerned with details such as transaction support, security, remote object access, and many other complicated and error-prone issues. These are provided transparently for the developer by the EJB container.
EJBs offer portability. A bean that is developed on one EJB container will run on other EJB containers that meet the EJB specification. Oracle Application Server 10g implements the EJB specification by providing a server and a container that hosts the Enterprise JavaBeans.
EJB specifies Remote Method Invocation (RMI) as the transport protocol. EJBs access the EIS-tier database through JDBC.
EJBs are accessed using Java’s RMI (Remote Method Invocation) framework, which can be implemented with different network protocols. Oracle Application Server 10g provides the RMI/Internet Inter-ORB Protocol (IIOP) protocol, as well as a platform-specific, optimized protocol called Oracle Remote Method Invocation (ORMI).
Additionally, a stateless session EJB can be exposed as a Web service. Web services are a standard for building interoperable distributed applications that are platform and programming-language independent. Stateless session EJBs and Web services are discussed in detail later in this course.

18. J2EE Communication APIs
J2EE provides component communication through APIs.
The APIs include:
RMI
JNDI
JDBC
These APIs facilitate communication between the J2EE components.
J2EE Communication APIs
RMI, JNDI, and JDBC are Java communication APIs. RMI and JNDI allow J2EE components to communicate with one another, whereas JDBC allows J2EE components to interact with the database.

19. J2EE Server The J2EE server provides:
Containers for each component type of a J2EE application
System-level services to components:
Naming and directory services (JNDI)
Security services for Web components and EJBs (JAAS)
Transaction architecture (JTA)
Remote client connectivity:
– Enterprise beans (RMI/IIOP, ORMI)
– Servlet/JSP (HTTP, HTTPS, FTP)
J2EE Server
The J2EE server is the run-time portion of a J2EE product. A J2EE server provides EJB and Web containers. The Web-tier and business-tier components can themselves be clients for the other J2EE application components.
An advantage of the J2EE standard is that all the container providers must abide by the same J2EE standards. This is much easier for developers because the application assembly is the same in any J2EE-compliant environment.
The J2EE server provides system-level services to the J2EE application components:
J2EE naming services provide the J2EE application components with access to the Java Naming and Directory Interface (JNDI) lookup services. Using the JNDI lookup service, the components can locate user-defined objects, environment entries, enterprise beans, JDBC DataSource objects, and messaging connections.
The security services enable you to configure Web-tier and business-tier components so that only authenticated and authorized users can access the system resources.
The transaction architecture enables you to specify relationships among methods that make up a single transaction so that all methods in one transaction are treated as a single unit.

20. J2EE Server (continued)
The remote connectivity service manages the low-level communications between clients and J2EE components. This provides location transparency to the clients. The client accesses the components as if both of them (the client and the Web-tier or business-tier components) are on the same Java virtual machine.

21. Oracle Application Server 10g Containers for J2EE (OC4J)
OC4J is the J2EE server implementation in Oracle Application Server 10g
Key features:
Implements J2EE 1.3 Specification
Runs on standard JVM
Provides high performance and scalability
Is productive for developers to use
Is simple to manage and deploy
Provides clustering for high availability and failover
Oracle Application Server 10g Containers for J2EE (OC4J)
Oracle Application Server 10g provides a complete J2EE server, called Oracle Application Server 10g Containers for J2EE (OC4J). It is written in Java and executes on the standard Java Virtual Machine (JVM). OC4J is installed in three ways:
Is included in Oracle Application Server 10g
Is included in Oracle JDeveloper 10g
Is available as a stand-alone version (that is, without any other software)
In this class, OC4J is installed with Oracle Application Server 10g as well as Oracle JDeveloper 10g. This means that you can test applications on OC4J by using JDeveloper, and deploy them to Oracle Application Server 10g.

22. J2EE Applications
J2EE applications consist of J2EE components and are deployed in the form of modules:
Web modules contain the user interface: HTML, JSP, and servlets.
EJB modules contain reusable EJB components.
Client modules provide access to remote application code.
Packaging information identifies dependencies between modules.
J2EE Applications
J2EE applications are server-side applications that contain standard components such as servlets, JSPs, and EJBs. Applications are deployed in the form of modules that package all necessary code for deployment to a J2EE server such as Oracle Application Server 10g. Modules are archive files in a standard format, specified by the J2EE architecture.

23. Packaging J2EE Application Components
1. ejb.jar
Bean class, Home and Remote interfaces, other supported files, DD
2. webtier.war
Java servlets, JSP files, HTML, GIF files, DD (references to EJBs)
J2EEapplication.ear
3. J2EEappClient.jar
J2EE application client (Java class), DD (references to EJBs)
4. DD for J2EE application (.xml)
J2EE Application Components
The diagram in the slide shows the components of a J2EE application. A J2EE application is typically archived into an Enterprise Archive (EAR) file. This file contains the following:
A Java Archive (JAR) file that contains the archive of EJB components—EJB class files, Home and Remote interfaces, and EJB deployment descriptor that contains information about transaction attributes, security roles, and so on.
A Web Archive (WAR) file that contains the archive of Web components—Java servlets, JSP files, HTML, GIF files, and a deployment descriptor that contains references of the EJBs being accessed, in ejb-ref tags.
A JAR file that contains the archive of a J2EE application client in the form of a Java class, and a deployment descriptor that contains references to the EJBs from which the business methods are being accessed. The J2EE application client is a Java application that runs in an environment that allows it to access J2EE services.
A deployment descriptor of the J2EE application, which is a reference file for deployment, that contains information about the .war, .jar files, and security information.
An optional resource adapter archive (RAR), which is a driver that either an application server or an application client uses to connect to a specific EIS. Examples of resource adapters are JDBC drivers to connect to a relational database, or an ERP resource adapter to connect to an ERP system.
DD = XML Deployment Descriptor
5. Resource adapter (.rar)

24. JARs Are simple Java Archive files
Are used to package application files together (for example, classes, images, and so on)
Can be included in Web Archives (WARs) and Enterprise Archives (EARs)
Can be included in library paths
JARs
A standard JAR file has the following structure:
| META-INF
| manifest.mf
| Java classes
Typically, JAR files are used to hold groups of related Java packages (such as JDBC or Swing). To simplify deployment or make operational access more efficient, you may want to include them in EJB-JAR files, WAR files, or EAR files.

25. WARs
Are specialized archives for packaging J2EE-compliant Web applications
Have a fixed directory structure
Have a deployment descriptor for the Web application
WEB-INF
web.xml
Contain servlet code and JavaBeans not in standard JAR files
classes
lib
Contains required classes that are packaged in standard JAR files
WARs
Each WAR file is created with the Web application and its XML files, which are structured as follows:
| WEB-INF
| | web.xml
| | classes
| | Servlet classes (may be included inside packages)
| | lib
| index.html
| JSPs
Note that a WAR file may contain both HTML and JSPs, as well as many other supporting files.
index.html
welcome.jsp

26. EJB JARs Are specialized JARs for packaging EJBs
Have a fixed directory structure
Have a deployment descriptor for the EJB components
myEJB
META-INF
ejb-jar.xml
Contain the class files for the EJBs, usually in a package directory structure
EJB Classes
EJB JARs
Each EJB file is created with the EJB application classes and XML files, which are structured as follows:
| META-INF
| | ejb-jar.xml
| | orion-ejb-jar.xml |
| EJB classes
J2EE specifications recommend the use of an application directory to locate all application-specific XML files. This is recommended because it keeps the global and default configuration files separate from the application-specific configuration files. The orion-ejb-jar.xml file is used by OC4J to deploy EJBs. Its use is discussed in detail later in the course.
Remote, Home and
Bean classes

27. EARs
The EAR files:
Are specialized archives for packaging J2EE-compliant enterprise applications for deployment
Have a deployment descriptor
May have Web modules
May have EJB modules
May have client modules
EARs
As J2EE applications became larger and more complex, there was a need to simplify distribution. The J2EE specification addresses this issue. Organizations can use EAR files to package all the client modules—HTML pages, JSPs, Servlets, EJBs, manifest files, and XML configuration files—that are needed to distribute an entire application. All these files are contained in a single archive file with a standard organization.

28. EAR File Structure for a J2EE Application: Example
<appname>
| META-INF
| | application.xml
| <ejb_module>
| | EJB classes
| | META-INF
| | ejb-jar.xml
| <web_module>
| | index.html
| | JSP pages
| | WEB-INF
| |----web.xml
| |----classes
| | Servlet classes
| <client_module>
| | Client classes
| | META-INF
| | application-client.xml
EAR File Structure for a J2EE Application: Example
The diagram in the slide indicates a suggested directory path for deploying your J2EE applications.
The names of the META-INF and WEB-INF directories and application.xml, ejb-jar.xml, web.xml, and application-client.xml files are predefined in the OC4J server according to the J2EE specifications. There are separate directories to clearly separate modules of the application. The application.xml file, which acts as the manifest file, defines these modules.
In this example, the directories containing the separate modules (ejb_module, web_module, and client_module), and the directory that contains the modules (appname), may have arbitrary names. These names must match the values in the manifest file (application.xml).
For EJB modules, the top of the module represents the start of a search path for classes. As a result, classes belonging to packages are expected to be located in a nested directory structure beneath this point. For example, a reference to a class in a package myapp.ejb.demo is expected to be located in the <appname>/ejb_module/myapp/ejb/demo directory.

29. OC4J Architecture Web container EJB
Oracle HTTP Server
AJP13
Web container
JNDI
HTTP
JMS
AJP
mod_oc4j
JDBC
JTA
Client
ORMI
EJB
container
JAAS
JCA
JavaMail
ORMI
JAF
OC4J Architecture
OC4J implements the J2EE infrastructure. The OC4J Web container and the OC4J EJB container use the J2EE virtual machine.
The J2EE containers perform services for applications, such as providing access to the APIs and life-cycle management.
When Oracle HTTP Server receives a request, such as from the URL, it determines the modules that are configured to handle this request, based on the mapping in the configuration file (httpd.conf or mod_oc4j.conf).
In this case, Oracle HTTP Server resolves that mod_oc4j is responsible for this request, because the /j2ee virtual path is mapped to the OC4J server. mod_oc4j then contacts a specified OC4J instance by using Apache JServ Protocol (AJP). AJP is faster than HTTP, through the use of binary formats and efficient processing of message headers.
Oracle Remote Method Invocation (ORMI) is the protocol through which EJB clients access EJBs that are deployed to the container. This and the other APIs shown in the slide are discussed in detail later in the course.
Additionally, HTTP is available directly to the OC4J process for development purposes.
EJB client
OC4J server process

30. OC4J Server Configuration Files
OC4J Server XML Files
Server Configuration
server.xml
Web site
Web site
Web site
jazn.xml*
default-web-site.xml
jazn-data.xml*
data-sources.xml
rmi.xml
jms.xml
Oracle HTTP Server configuration files
OC4J Server Configuration Files
The OC4J server is configured by using XML-based configuration files. These files are standard for J2EE servers. In later lessons, you see how OC4J extends these files.
These configuration files provide a way of integrating components with the OC4J framework. There is no need to modify the XML files that are contained in JARs, WARs, and EARs while they are being deployed.
There is an implied hierarchy to these configuration files:
server.xml
|------>rmi.xml
|------>jms.xml
|------>application.xml
| |------>principals.xml
| |------>data-sources.xml
|------>global-web-application.xml
|------>default-web-site.xml
|------>default-web-app
|------>web-app
*The jazn.xml and jazn-data.xml files describe the security configuration by using the OC4J JAAS provider. If Java Authentication and Authorization Service (JAAS) is not used, then these files need not be configured.
mod_oc4j.conf

31. Relation of Configuration Files
When an application is deployed, an entry is made in the \config\server.xml file:
<application name="lesson02" path="../applications/lesson02.ear" />
For each Web module within the application, a context root is defined in \config\default-web-site.xml:
<web-app application="lesson02" name="webapp1" root="/lesson02"/>
The modules of the application are defined in \applications\lesson02\META-INF\application.xml:
Relation of Configuration Files
The server.xml, default-web-site.xml, and application.xml files work together to define the configuration for an application. If an application named “lesson02” is deployed by using a lesson02.ear file (which contains webapp1.war), the deployment will create entries in the corresponding files, as shown in the slide above. Note that the default-web-site.xml file is used for those applications that are deployed to Oracle Application Server 10g installations. If the applications are deployed to the embedded OC4J server that is installed with Oracle JDeveloper 10g, then the http-web-site.xml file is used instead. The mod_oc4j.conf configuration file is used to specify which OC4J instance will handle requests for each context root.
<web><web-uri>webapp1.war</web-uri></web>

32. Data Sources
A data source is the instantiation of an object that implements the javax.sql.DataSource interface, which enables you to retrieve a connection to a database server.
OC4J data sources are defined in data-sources.xml.
J2EE applications use JNDI to look up these DataSource objects.
Data Sources
Data sources are a portable method for creating JDBC connections. The data-sources.xml file is preinstalled with a default data source named OracleDS. However, you can also add your own customized data source definitions. The default data source from data-sources.xml is listed below:
<data-source class="com.evermind.sql.DriverManagerDataSource" name="OracleDS"
location="jdbc/OracleCoreDS"
xa-location="jdbc/xa/OracleXADS"
ejb-location="jdbc/OracleDS"
connection-driver="oracle.jdbc.driver.OracleDriver" username="scott" password="tiger"
inactivity-timeout="30"
/>

33. Application Logging
Application logging in Oracle Application Server 10g is configured by specifying the location of a log file in the application.xml file:
To create a log file formatted in XML, use Oracle Diagnostic Logging (ODL):
<log>
<file path="practice02-oc4j-app.log"/>
</log>
<log>
<odl path="practice02-oc4j-app.log"/>
</log>
Application Logging
In Oracle Application Server 10g, you can use the OC4J application.xml configuration file to specify that a log file be created. The path attribute is relative to the location of the application.xml file. The resulting log file is useful for debugging applications during development, as well as tracing run-time errors. An example of the output generated in a log file is as follows:
04/02/25 01:04:35 Started
04/02/25 01:04:36 practice02-login-webapp: JDevOJSP: init
04/02/25 01:04:36 practice02-login-webapp: Started
04/02/25 01:04:36 practice02-login-webapp: LoginServlet: init

34. J2EE Application Deployment to Oracle Application Server 10g
Deploying to OC4J can be done in multiple ways:
Step 1: Create WAR, EAR file
Step 2: Deploy
Step 2: Deploy
Use a command-line tool (such as ANT).
Use Oracle Enterprise Manager (installed with Oracle Application Server 10g): Access the Enterprise Manager Web site (requires login).
Use JDeveloper – specify an Application Server and click 'Deploy'
Use JDeveloper.
Use JDeveloper: Specify an application server and click “Deploy.”
J2EE Application Deployment to Oracle Application Server 10g
A J2EE application can be deployed by using a command-line tool to copy WAR, EAR, and JAR files to the proper location on the J2EE server. However, several tools are available to make this process easier. JDeveloper supports the deployment of a J2EE application to a J2EE server (such as Oracle Application Server 10g) by using a deployment profile. Additionally, OC4J can be administered and applications can be deployed to an OC4J instance by using Oracle Enterprise Manager Application Server Control. You can also deploy by using a command-line deployment tool, such as ANT.

35. Oracle Enterprise Manager
localhost
Oracle Enterprise Manager
The slide above shows the OC4J home page, where you can stop and restart OC4J instances, and also deploy applications. You can access the OC4J home page by following the OC4J_home link from the Oracle Enterprise Manager home page on the default port 1810.

36. JDeveloper and J2EE JDeveloper provides:
Integrated development, deployment, and testing support for Web-tier and business-tier components
A J2EE framework for rapid development
Application Development Framework (ADF) business components
Data tags
Integration with Struts
UML modeling
Visual editors for Web clients
Easy deployment to Oracle Application Server 10g
JDeveloper
JDeveloper and J2EE
JDeveloper is an Integrated Development Environment (IDE) that is used to build, test, and debug J2EE applications. In Oracle JDeveloper 10g, workspaces and projects are used to organize the files that you need for your application. To effectively work with the files in JDeveloper, you can use projects to work with individual files, and workspaces to manage one or more projects. You must have a workspace before you can create projects. It is a common practice to create workspaces around functions of applications, such as human resources management; and to separate technologies into projects, such as having separate projects for the model, view, and controller. By using the UML Modeler, you can model business processes, build J2EE components, test and debug them, and easily deploy the business processes to Oracle Application Server 10g or other J2EE servers.

37. Oracle JDeveloper 10g Environment
Customizable code editor
Wizards for JSPs, servlets, and EJBs
Error checking for HTML and JSP
EAR, WAR deployment to J2EE server
Oracle JDeveloper 10g Environment
JDeveloper provides you with several helpful development features. Wizards for creating servlets, JSPs, and EJBs make it easy to start building a Web application. The code editor is customizable and code insight makes it easy to develop code without having to remember each package and class name. Debugging is provided in both local and remote modes, and errors in HTML and JSPs are identified within the IDE. Additionally, JDeveloper automates the packaging of J2EE applications into WAR or EAR files for deployment to a J2EE server. Oracle Application Server 10g Containers for J2EE (OC4J) is provided within the tool to test and debug the J2EE applications.
Code insight

38. Oracle JDeveloper 10g Visual Design Tools
Drag JSP and HTML
elements
Modify values
in property
inspector
Design in visual
or code views
Oracle JDeveloper 10g Visual Design Tools
Oracle JDeveloper 10g enables you to choose between editing in code or visual views for JSP and HTML documents. You can drag JSP and HTML elements from the component palette to the visual or code views, and elements can be modified directly in the code or visual editor, or in the property inspector. The code editor, visual editor, property inspector, and another visual tool, the structure pane, are all synchronized so that a change in one propagates immediately to all other representations of the data.

39. Summary In this lesson, you should have learned that:
J2EE is a set of Java technologies that support end-to-end application development
Components are the foundation of the J2EE architecture
Web components (servlets, JSPs) generate dynamic content
Business components (EJBs) are server-side components that contain business logic
Applications can be built by using Oracle JDeveloper 10g and deployed to a J2EE server, such as Oracle Application Server 10g
Summary
J2EE components include servlets, JSPs, and EJBs. These components are divided into functions of business and presentation logic. J2EE applications can be built by using Oracle JDeveloper 10g and deployed by using JDeveloper, Oracle Enterprise Manager Application Server Control, or other tools.

40. Practice 2-1: Overview This practice covers the following topics:
Navigating to the OC4J console by using Oracle Enterprise Manager
Mapping a data source in OC4J
Restarting the OC4J server instance from Oracle Enterprise Manager
Deploying an EAR file by using Oracle Enterprise Manager

41. In Datasource Username:
Practice 2-1
In this practice, you navigate to the Oracle Enterprise Manager console, modify the default
data source, and restart the OC4J server. Additionally, this practice gives you the
opportunity to view the files that OC4J uses to configure a J2EE application. You also
deploy an existing application by using Oracle Enterprise Manager.
1. Navigate to the Oracle Enterprise Manager console.
a. Open a browser and navigate to
b. Enter the username ias_admin and the password welcome1.
c. Navigate to the home instance page by clicking the home link.
2. Create a data source reference.
a. Click the Administration tab and click the Data Sources link.
b. Click Create and enter these details:
Name: hrDS
Description: hr
Data Source Class: com.evermind.sql.DriverManagerDataSource
JDBC URL: The URL provided to you by your instructor
JDBC Driver: oracle.jdbc.driver.OracleDriver
In Datasource Username:
Username: oraxx (as provided to you by your instructor)
Use a cleartext password of oracle
In JNDI Locations:
Location: jdbc/hrCoreDS
Transactional location: jdbc/xa/hrXADS
EJB location: jdbc/hrDS
Leave all other fields blank or set to the default.
c. Click Create and restart OC4J when prompted.
3. Verify the change that you made to the data source.
a. Navigate to the oraas10g directory and locate the j2ee\home\config directory.
b. Open data-sources.xml in WordPad. Note that the data source that you added in step 2 is defined here.
c. You may also want to view application.xml, server.xml, and other configuration files that are discussed in this lesson.
4. Deploy an existing J2EE application by using Oracle Enterprise Manager. The application you deploy in this step is actually the application that you will build in practice 17.
a. Click the applications tab from the OC4J home page and click Deploy EAR File.
b. Browse to the <JDEV_HOME>\jdev\mywork\practice02 directory and select application1.ear.
c. Name the application practice02 and click Continue.
d. Modify the URL Mapping as /practice02 and click Next.
e. Enter jdbc/hrCoreDS for the JNDI location name and click Next.

42. Practice 2-1 (continued)
f. Because there is no user security defined for this application, click Next in the following page.
Click Deploy to deploy the application.
Click OK after the application has been deployed.
5. Access the application.
a. Enter the following URL in the browser:
b. Enter 100 in the Employee ID field and King in the Employee Name field and click Login.
c. View the Employees in King’s department and click the Insert link.
d. Enter the following information in the form.
ID: 500
First Name: Your first name
Last Name: Your last name
Your account
Hire Date: A date in the format of “dd-mon-yy”
Job ID: AD_VP
e. Verify whether the employee was inserted by using SQL*Plus to query the EMPLOYEES table.