|
Oracle® Application Server Concepts
10g Release 2 (10.1.2) B13994-02 |
|
 Previous |
 Next |
|
Oracle® Application Server Concepts
10g Release 2 (10.1.2) B13994-02 |
|
|
Previous |
Next |
This chapter describes the Java 2 Platform, Enterprise Edition (J2EE), Web Services, and Internet application development and deployment environment in Oracle Application Server, explaining its features and concepts. The topics include:
Oracle Application Server provides an integrated, standards-based environment that provides for both developing applications and then deploying them, reliably delivering the applications to users across an enterprise. The following sections describe how this environment aids application development and deployment.
Oracle Application Server allows Web application developers to develop their sites in a variety of languages and technologies:
Table 2-1 lists the different technologies and programming languages that you can use to build applications for deployment with Oracle Application Server.
Table 2-2 lists application development and deployment recommendations and requirements for various application types.
Table 2-2 Application Development and Deployment Recommendations and Requirements
| Application Type | Programming Language/Methodology | Build Time Recommendation | Deploy Time Installation Requirement |
|---|---|---|---|
|
Java |
JSP, Swing, Applets |
JDeveloper |
OC4J Standalone or J2EE and Web Cache |
|
J2EE |
JMS, Servlet, EJB/Persistence Management, with JAZN-XML, with JAZN-LDAP, with JAZN-SSO |
JDeveloper, TopLink Workbench |
J2EE and Web Cache, J2EE and Web Cache associated with Infrastructure |
|
J2EE |
ADF/SOA |
JDeveloper |
J2EE and Web Cache, Portal and Wireless if you need UDDI |
|
non-J2EE |
PL/SQL, Perl, PHP, C/C++ |
PL/SQL Web Toolkit for PL/SQL; otherwise use development tool of choice |
J2EE and Web Cache, if using PSP and mod_plsql also need OWA packages in the database (can get through OracleAS Metadata Repository Creation Assistant) |
|
Portal |
Portal, portlets, omniportlet |
Portal, JPDK |
Portal and Wireless |
|
Wireless |
Wireless applications |
Wireless SDK (part of OracleAS Developer Kits) |
Portal and Wireless |
|
Business Intelligence |
Discoverer or BI Beans with Java |
Discoverer Plus OLAP/Relational; JDeveloper with BI Beans (included in Oracle Developer Suite); Portal with Discoverer Portlets |
Oracle Business Intelligence; OracleAS Portal (optional) |
|
Integration |
Data Integration Modeler, Business Process Integration Modeler, BPEL Designer, XSLT Mapping Tool, JCA Adapter Wizards |
JDeveloper, OracleAS InterConnect iStudio |
Oracle Application Server middle tier plus Integration installation (with appropriate install types) |
The following sections explain how Oracle Application Server supports these technologies and programming languages.
Oracle HTTP Server is the underlying deployment platform for all programming languages and technologies that Oracle Application Server supports. It provides a Web listener for Oracle Application Server Containers for J2EE (OC4J) and the framework for hosting static and dynamic pages and applications over the Web. Based on the proven technology of the Apache HTTP Server, Oracle HTTP Server includes significant enhancements that facilitate load balancing, administration, and configuration. It also includes a number of enhanced modules, or mods, which are extensions to the HTTP server that extend its functionality for other enterprise applications and services.
Oracle HTTP Server allows developers to program their sites in a variety of languages and technologies, such as Java, Perl, C, C++, PHP, and PL/SQL. Additionally, it can serve as either a forward or reverse proxy server. The following sections describe how Oracle HTTP Server provides a robust deployment platform for dynamic Web sites and applications.
|
Note: The version of Oracle HTTP Server that is installed as part of the standard Oracle Application Server installation types is built on Apache 1.3. Additionally, Oracle HTTP Server is available as a standalone installation in two versions: one based on Apache 1.3, and one based on Apache 2.0. |
Oracle HTTP Server consists of several components that run within the same process. These components provide the extensive list of features that Oracle HTTP Server offers when handling client requests. Major components include the following:
HTTP listener: Oracle HTTP Server is based on an Apache HTTP listener to serve client requests.
Modules (mods): Many of the standard Apache mods are included with Oracle HTTP Server. Oracle also includes several internal modules that are specific to Oracle HTTP Server components. Table 2-3 lists some of the Oracle HTTP Server modules.
Perl Interpreter: A persistent Perl runtime environment embedded in Oracle HTTP Server through mod_perl.
Table 2-3 Prominent Oracle HTTP Server Modules
| Module | Description |
|---|---|
|
Supports PHP version 4.3.9, an open source client-side scripting language that is embedded in standard HTML. |
|
|
Increases Web application security by protecting Web applications from known and unknown attacks. |
|
|
Supports FastCGI, which allows C, C++, and Java CGI programs to run in a performant environment |
|
|
Routes requests to the Perl Interpreter |
|
|
Routes requests for stored procedures to the database server |
|
|
Supports communication with Oracle Application Server Containers for J2EE and also performs some load balancing tasks |
|
|
Supports file as well as database distributed authoring and versioning |
|
|
Supports Secure Sockets Layer (SSL) and certificate sharing |
|
|
Routes requests to Oracle Application Server Single Sign-On server |
Figure 2-0 shows the path of various requests through Oracle HTTP Server components.
Figure 2-1 Oracle HTTP Server Request Flow
At startup, the Web server parent process loads the entire configuration and the associated mods, and spawns a preconfigured number of child processes.
|
Note: On Windows systems, the Web server main process is a child process that spawns multiple threads. |
Figure 2-2 shows the process architecture of Oracle HTTP Server in a UNIX environment.
Figure 2-2 Oracle HTTP Server Process Architecture
The parent process does not listen to HTTP requests. Its sole job is to ensure that the child processes are running or that new ones are started when the load requires it.
On UNIX platforms, each child process handles a single HTTP request. The child processes determine who should take the next request based on a mutex mechanism that you can configure.
|
Note: On Windows platforms, threads handle HTTP requests instead of child processes. |
The architecture of Oracle HTTP Server is modular. The core HTTP listener is very small, and all capabilities are implemented as modules that plug in and are invoked at the appropriate place during the HTTP request lifecycle. Figure 2-3 shows the lifecycle of an HTTP request in Oracle HTTP Server.
Figure 2-3 Oracle HTTP Server HTTP Request–Response Cycle
A child process guides the request through this entire lifecycle. The modules register their application programming interfaces (APIs), which are then either invoked automatically when the request reaches a certain stage in its lifecycle, or can be configured to be invoked only in certain situations.
In addition to the standard Web server functionality of serving client requests to other Oracle Application Server components, Oracle HTTP Server provides the necessary features for both creating dynamic applications and implementing enterprise support. It also contains security enhancements that help protect important business resources. Key features of Oracle HTTP Server include the following:
PHP support through mod_php: Oracle HTTP Server now supports PHP (recursive acronym for PHP: Hypertext Preprocessor), an open source, client-side scripting language used to generate dynamic HTML pages. PHP support is provided through mod_php.
Increased application security with mod_security: mod_security is an open source intrusion detection and prevention engine for Web applications, which protects against known and unknown attacks.
Security through Secure Sockets Layer: Secure Sockets Layer (SSL) is required to run any Web site securely. Oracle HTTP Server supports SSL encryption based on patented, industry standard algorithms. SSL works with both Internet Explorer and Netscape browsers. Oracle HTTP Server also provides support for dedicated SSL hardware, session renegotiation, and communication with OC4J using the AJP protocol over SSL.
Single Sign On Support: Oracle HTTP Server supports the standard basic authentication features of Web servers. In addition, the mod_osso module is included to support single sign on across sites and across applications, improving the end-user experience.
Virtual Host Support: A virtual host is a Web site that may share its Web server with other similar sites. Oracle HTTP Server provides a "container" environment for a virtual host, providing the virtual host with its own set of security and configuration directives. It also provides the location from which files are served. This allows ISPs to save on hardware and administrative costs by enabling multiple sites to be served from a single runtime instance of Oracle HTTP Server. However, due to technology limitations, only one virtual host can enable SSL.
Dynamic monitoring services (DMS): These services automatically measure runtime performance statistics for both Oracle HTTP Server and Oracle Application Server Containers for J2EE (OC4J) processes. As applications run, DMS collects detailed performance statistics. This data allows you to monitor the duration of important request processing phases and status information. With this information, you can locate performance bottlenecks and tune the application server to maximize throughput and minimize response time.
Request ID: To enhance request tracking through various components, a request ID is now attached to each request. This provides more detailed tracking information, allowing you to see how much time a particular request spends in any component or layer.
External API for performance monitoring: This API allows you to use external, third-party performance monitoring tools to monitor Oracle Application Server-based J2EE components, such as servlets and JSPs, as well as J2EE containers.
Proxy Plug-In: To accommodate requirements for non-Oracle HTTP listeners, Oracle HTTP Server provides a proxy plug-in that can be plugged directly into Sun ONE or Microsoft Internet Information Server (IIS). This proxy plug-in is used to forward requests for Oracle Application Server component services to Oracle HTTP Server, which is placed behind the non-Oracle listener.
OC4J Plug-In: The OC4J Plug-In provides a way for you to use Apache as well as the IIS and Sun ONE third-party listeners to access servlets running in OC4J without having to use the Oracle HTTP Server as a proxy. The OC4J Plug-In routes requests directly from the third-party HTTP listener to OC4J.
Oracle Application Server Single Sign-On Plug-in: This plug-in is the Oracle single sign-on solution for third-party listeners such as Sun ONE and IIS. The plug-in is designed to protect native third-party listener applications using the single sign-on infrastructure. Using this plug-in, you can be authenticated to different third-party listener applications using only one password. You can integrate these protected third-party listener applications with other single sign-on enabled applications as long as they are all protected by the same single sign-on server.
Requests that are sent to a common gateway interface (CGI) program may invoke two new processes—the child process that handles the HTTP request and the CGI program itself. It is possible to avoid this overhead by configuring Oracle HTTP Server to pre-start child processes and keep them running, leveraging the Perl module to run the CGI programs in memory, or using the FastCGI mechanism.
The following Oracle HTTP Server features support CGI:
FastCGI: FastCGI supports applications written with Perl, C, C++, and Java. Each CGI application runs in a single child process of the Web server. This improves server performance because it eliminates the need to start a new process for every application request.
Perl Interpreter: The Perl Interpreter supports Perl applications and runs them inside of the Web server process. This allows for greater performance because running applications does not start new processes. Since the interpreter runs inside of the Web server process, it has access to Web server services such as log files.
Oracle Application Server Containers for J2EE (OC4J) is a fast, lightweight, and scalable J2EE 1.3 certified server implementation that is written in Java and runs on a standard Java Virtual Machine (JVM). It has been designed to support the standard APIs in Table 2-4.
Table 2-4 Oracle Application Server Containers for J2EE Supported APIs
| API | Version |
|---|---|
|
1.2 |
|
|
2.3 |
|
|
2.0 |
|
|
2.0 Extensions |
|
|
1.0 |
|
|
1.0.2b |
|
|
1.2 |
|
|
1.0 |
|
|
1.1 |
|
|
1.0 |
|
|
1.0 |
The following sections provide introductory definitions and summaries of application programming technologies that Oracle Application Server supports. For detailed information on the technologies introduced in this section, refer to the following information sources.
|
See Also:
|
A J2EE application is an application that is written in Java using the J2EE APIs. It can be deployed, managed, and executed on a J2EE-compatible server. The J2EE application itself is composed of a set of components, such as Web presentation modules, business logic modules, and data access modules. Each component is assembled into the overall application with all of its related classes and XML deployment descriptors.
The J2EE platform provided in Oracle Application Server uses a multi-tiered distributed application model. A multi-tiered distributed application model divides application logic into components according to function, and the various application components that make up J2EE applications can be installed on different machines, depending on which tier in the multi-tiered J2EE environment the application component belongs. Figure 2-4 shows two multi-tiered J2EE applications divided into the client, Web, business logic, and enterprise data tiers.
Figure 2-4 J2EE Distributed Multi-tiered Application Architecture
You can distribute J2EE applications across the four tiers shown in this figure, but generally they are considered to be three-tier applications because they are usually distributed over the following machine locations:
client machines
J2EE Server machines hosting presentation services, like JSPs and servlets, and business logic components, like EJBs
database servers or legacy machines at the back end
Three-tiered applications that run in this way extend the standard two-tiered client and server model by placing an application server between the client and the back-end storage.
J2EE applications support the following clients:
Application Clients: Applications running on a client machine that directly access enterprise beans that are running in the business logic tier. Application clients can also open an HTTP connection to establish communication with a servlet running on the Web tier if a J2EE application requires it.
Dynamic HTML and XML Pages: In the context of J2EE applications, dynamic HTML and XML pages are either generated by servlets or created with JavaServer Pages technology running in the Web tier. These pages can be extensions to traditional static HTML pages, allowing application developers to offer customized and personalized pages to the client.
You can use the following components in J2EE applications:
Servlets: A servlet is a Java class that executes behind a Web server and can extend the capability of the Web server to provide services for dynamic page creation or application logic. The servlet works in the standard HTTP request-response model.
JavaServer Pages: JavaServer Pages (JSPs) are text files that contain two types of information: static template data, which can be expressed in any text-based format, such as HTML, XML, or WML (Wireless Markup Language); and JSP elements, which construct dynamic content.
Enterprise Beans: Enterprise beans are server-side components that encapsulate the business logic of an application.
A container provides the runtime support for J2EE application components. Containers provide a federated view of the underlying J2EE APIs to the application components. J2EE application components never interact directly with other J2EE application components. They use the protocols and methods of the container for interacting with each other and with platform services. Interposing a container between the application components and the J2EE services allows the container to transparently inject the services defined by the components' deployment descriptors, such as declarative transaction management, security checks, resource pooling, and state management.
Before a Web or enterprise bean component can run, it must be assembled into a J2EE application and deployed into a J2EE container. The assembly process involves specifying container settings for each component, which customize the underlying support provided by the J2EE server. These settings can be standard J2EE settings or container-specific settings, depending on your application requirements. Some of the container settings that you can specify include security services, transaction model, naming and directory lookup, and remote connectivity model.
There are two primary types of J2EE container:
Enterprise JavaBeans Container: The Enterprise JavaBeans container (EJB container) manages the execution of all enterprise beans for J2EE applications. Enterprise beans and their container run on the J2EE server.
Web Container: Web components such as JSP pages and servlets are managed and executed in the servlet container. The container provides services such as request dispatching, security, concurrency, and life cycle management. The Web container also gives Web components, typically JSPs and servlets, access to the J2EE APIs such as naming, transactions, and JDBC.
J2EE components are packaged separately and bundled into a J2EE application. Each component, with its related files such as GIF and HTML files or server-side utility classes, are packaged together with a deployment descriptor (DD), and are assembled into a module that is added to the J2EE application. Typically, a J2EE application is composed of one or more enterprise beans and Web or application client component modules.
Figure 2-5 shows the architecture of OC4J within Oracle Application Server.
Figure 2-5 Oracle Application Server Containers for J2EE Architecture
OC4J is supported by the Java 2 Platform, Standard Edition (J2SE) infrastructure as shown in Figure 2-5. This means that the OC4J Web container and OC4J EJB container use the J2SE virtual machine. J2EE applications are modularized for reuse of application components, such as:
User interfaces, which can be composed of JavaServer Pages (JSPs), dynamic HTML, and so on
Business logic, which is usually contained in an Enterprise JavaBean (EJB) or normal Java classes
The J2EE containers also perform services for applications, such as providing access to the APIs and lifecycle management.
Oracle Application Server Containers for J2EE (OC4J) has the following features.
OC4J supplies the following J2EE containers:
A servlet container that complies with the servlet 2.3 specification
A JSP container that complies with the Sun JSP 1.2 specification
An EJB container that complies with the EJB 2.0 specification
A servlet is a Java program that runs on a J2EE server, such as OC4J. A servlet is one of the application component types of a J2EE application. It must execute under the control of a servlet container, which is part of the OC4J Web container. The servlet container calls the servlet's methods and provides services that the servlet needs when running.
About the Servlet Container
The servlet container executes and manages servlets. It provides the servlet with access to properties of the HTTP request, such as headers and parameters. Also, the container provides the servlet with access to other Java APIs, such as JDBC to access a database, remote method invocation (RMI) to call remote objects, or JMS to perform asynchronous messaging.
How the Servlet Container Works
When a request is mapped to a servlet, the servlet container performs the following steps:
If an instance of the servlet does not exist, the container does the following:
Loads the servlet class
Instantiates an instance of the servlet class
Initializes the servlet instance
The container then invokes the servlet, passing request and response objects. The request object contains information about the client, request parameters, and HTTP headers. The response object returns the servlet's output to the client.
The servlet extracts information from the client request, accesses external resources, and then populates the response based on that information.
JavaServer Pages provide a convenient way to generate dynamic content in Web pages. JSP technology, which is closely coupled with servlet technology, allows you to include Java code fragments and make calls to external Java components (in the form of tags and directives) from within your Web pages. Typically, the markup code used to compose your Web pages is HTML or XML. JSPs work well as a front-end for business logic and dynamic functionality in JavaBeans or Enterprise JavaBeans (EJBs).
A JSP is translated into a Java servlet before being run, and it processes HTTP requests and generates responses like any servlet. However, JSP technology provides a more convenient way to code a servlet. Translation occurs the first time the application is run. A JSP translator is triggered by the .jsp file name extension in a URL.
JSPs are fully interoperable with servlets. You can include output from a servlet or forward the output to a servlet, and a servlet can include output from a JSP or forward output to a JSP.
About the JSP Translator
The JSP translator has a translator and a compiler. The JSP translator translates a JSP into a Java source file. The container compiles the source file into a Java bytecode (.class) file, which executes as a servlet in the servlet container using the JSP runtime library. The servlet container provides access to Java APIs and other services.
How the JSP Translator Works
When a user requests a URL that maps to a JSP file, such as http://host/Hello.jsp, the following steps occur:
The Web server invokes the JSP translator, which translates Hello.jsp and produces the file Hello.java.
The Java compiler is invoked, creating a Hello.class servlet.
Hello.class runs, using the JSP runtime library, which contains the supporting files to interpret the tags and directives from the JSP.
If the Hello class requires information from a database, then the servlet container provides JDBC access to the class so it can retrieve the information and return its output to the client browser.
The OC4J EJB container manages the execution of enterprise beans for J2EE applications. Like the OC4J Web container, the EJB container uses the J2SE virtual machine. The following sections describe what services the EJB container provides to J2EE applications and how it works.
Enterprise beans are the J2EE components that implement Enterprise JavaBeans technology. Enterprise beans run in the EJB container. An enterprise bean is a portable server-side component that encapsulates the business logic of an application. There are three types of EJBs: session beans, entity beans, and message-driven beans.
About the Oracle Application Server Containers for J2EE EJB Container
The OC4J EJB container provides system-level services to EJBs similar to the services that the Web container provides to servlets and JSPs. The container has configurable settings that customize the underlying support provided by OC4J, the J2EE server. The configurable settings include security, transaction management, Java Naming and Directory Interface (JNDI) lookups, and remote connectivity. In addition to the configurable settings, the container also manages EJB life cycles, database connection resource pooling, data persistence, and access to the J2EE APIs.
How the EJB Container Works
How the EJB container works depends on what type of enterprise bean you are using. The container manages the execution of the enterprise bean for one J2EE application.
For session beans, the EJB container provides all of the services that the Web container provides to Web components, such as access to APIs and the virtual machine, transaction services like Container Managed Transactions (CMTs), and secure and authorized EJB method invocation.
For entity beans, which represent business objects in a persistent storage mechanism, there are models for how the persistence is performed. You can have either bean-managed persistence (BMP) beans or container-managed persistence (CMP) beans. With bean-managed persistence, the entity bean code contains the calls that access the database and the EJB container triggers callback methods on your code. Entity beans with bean-managed persistence execute in the EJB container with the typical container support and services. However, if you are using container-managed persistence, then the EJB container automatically generates the necessary database access calls. The EJB methods do not require any JDBC code to manage EJB data persistence.
Java 2 Platform Enterprise Edition (J2EE) provides core services for writing J2EE components. The J2EE containers manage access to these services for the application components. The services are as follows:
Java Database Connectivity (JDBC): This service lets you invoke SQL commands from Java programming methods. You use the JDBC API in an enterprise bean when you override the default container-managed persistence or have a session bean access the database. You can also use the JDBC API from a servlet or a JSP to access a database directly without going through an enterprise bean.
Oracle Application Server includes the following drivers to provide highly scalable and reliable connectivity to both Oracle and non-Oracle data sources:
Oracle JDBC drivers: The Oracle JDBC drivers, in addition to providing standard JDBC API support, have extensions to support Oracle-specific datatypes and to enhance their performance. They are meant to be used with the Oracle database.
J2EE Connectors: The J2EE Connector architecture, part of the J2EE platform, provides a Java-based solution for connecting various application servers and enterprise information systems that are already in place.
DataDirect Connect Type 4 JDBC drivers: DataDirect JDBC drivers are meant specifically for connecting to non-Oracle databases, such as Microsoft SQL Server and Sybase.
Java Message Service (JMS): This service is a messaging standard that allows J2EE application components to create, send, receive, and read messages. It enables distributed communication that is loosely coupled, reliable, and asynchronous.
For this release, JMS support has been enhanced by the addition of a lightweight JMS provider in addition to the Oracle JMS offered in previous versions. The new lightweight JMS is fully JMS 1.0 compatible and can support durable messaging through a file-based persistence mechanism, which provides improved stability and performance. Support for Message Driven Beans is also now available for both Oracle JMS (AQ) and the lightweight OC4J JMS.
Java Transaction API (JTA): This service provides a standard demarcation interface for demarcating transactions. Typically, it is used in J2EE applications that use two or more separate database access operations that depend on each other to demarcate where the entire transaction begins, rolls back, and commits.
OC4J provides additional support for two-phase commits for applications that require commit coordination across machines and containers. The two-phase commit engine is responsible for ensuring that when a distributed transaction ends, changes to all participating databases are all either committed or rolled back.
Java Naming and Directory Interface (JNDI): This service provides a standard interface to naming and directory services. J2EE applications use JNDI to find other distributed objects. The JNDI Interface has two parts: an application-level interface used by application programs to access naming and directory services, and a service provider interface to attach a provider of naming and directory services.
JavaMail Technology: This service provides J2EE applications with a JavaMail API and a JavaMail service provider with which to send e-mail notifications.
Java API for XML (JAXP): This service provides support for the industry standard SAX and DOM APIs for parsing XML documents, as well as support for XSLT transform engines. It enables applications running in a J2EE container to make use of XML.
J2EE Connector Architecture: This service provides an interface for resource adapters that allow J2EE applications to access and interact with databases and other enterprise information systems (EIS). Oracle Application Server provides several out-of-the box adapters, and also allows you to build your own.
Java Authentication and Authorization Service (JAAS): This service provides a way for a J2EE application to authenticate users against different security provider systems and authorize a specific user or group of users to run J2EE applications under role permission and control enforcement.
Oracle Application Server provides an implementation of Java Authentication and Authorization Service (JAAS) that integrates with the Oracle Application Server J2EE security infrastructure to enforce security constraints for Web components (servlets and JSPs) and EJB components. The Oracle Oracle Application Server Java Authentication and Authorization Service (JAAS) Provider implementation does the following:
Integrates Java-based applications with Oracle Application Server Single Sign-On, including authentication, thereby giving you extensible security for Java-based applications
Manages access control policies centrally in Oracle Internet Directory, controls access by role, and partitions security policy by subscriber
Supports impersonation of a specific user, allowing an enterprise bean, servlet, or JSP to run with the permissions associated with the current client or a specified user
|
See Also: The Sun Microsystems, Inc. published specifications for these services, and The J2EE Tutorial for instructions on how to use them in J2EE applications, at:http://java.sun.com |
In addition to the standard J2EE Services, Oracle also provides the following services to Java developers:
Java Object Cache stores frequently accessed or resource-intensive objects in memory or on disk. It is a low-level object caching API, supporting generic object types such as memory objects, disk objects, pooled objects, and StreamAccess objects. Java Object Cache uses distributed object management to coordinate updates and invalidations of Java objects.
Objects are loaded using a user-defined CacheLoader object and accessed through the easy-to-use API. This eliminates the need to repeatedly create and load information within a Java application. The Java Object Cache retrieves content quickly and greatly reduces the load on Oracle Application Server.
Java Object Cache provides caching for expensive or frequently used Java objects when the application servers use a Java program to supply their content. Cached Java objects may contain generated pages, or they may provide support objects within the program to assist in creating new content. Java Object Cache automatically loads and updates objects as specified by the Java applications and includes APIs to manage the cached Java objects. The generic nature of Java Object Cache makes it an ideal cache repository for higher level caches such as Web Object Cache, easing the development effort and reducing complexity.
Oracle Application Server TopLink is an advanced object-to-relational persistence framework, suitable for a wide range of Java 2 Enterprise Edition (J2EE) and Java application architectures. OracleAS TopLink development tools and runtime capabilities reduce development and maintenance efforts, and increase enterprise application functionality. Use OracleAS TopLink to build high-performance applications that store persistent data in a relational database.
The following sections introduce OracleAS TopLink and include discussions on these topics:
Enterprise applications rely on Java-to-database integration to implement objects and logic. OracleAS TopLink enables developers to efficiently develop and refine enterprise applications. To fully understand OracleAS TopLink, you must understand the problems that enterprise application developers face and how OracleAS TopLink resolves them.
Java-to-database integration is a widely underestimated problem in enterprise Java applications. This complex problem involves more than reading from and writing to a database. The database world includes elements such as tables, rows, columns, and primary and foreign keys; the Java and J2EE world contains entity classes (regular Java classes or Enterprise JavaBeans (EJB) entity beans), business rules, complex relationships, and inheritance. Bridging these two fundamentally different technologies is a challenging and resource-intensive problem.
The process of translating object-oriented data into relational data is referred to as object-relational (O-R) mapping. To enable an O-R solution, developers must resolve the following O-R bridging issues:
Fundamentally different technologies
Different skill sets
Different staff and ownership for each of the technologies
Different modeling and design principles
Application developers need a product that enables them to integrate Java applications and relational databases, without compromising ideal application design or database integrity. In addition, Java developers need the ability to store (or persist) and retrieve business domain objects using a relational database as a repository.
The OracleAS TopLink solution is a persistence framework that manages O-R mapping in a seamless manner and enables developers to rapidly build applications that combine the best aspects of object technology and relational databases.
OracleAS TopLink provides a mature and powerful solution that addresses the disparity between Java objects and relational databases. OracleAS TopLink enables developers to:
Persist Java objects in virtually any relational database supported by a JDBC 2.0 compliant driver
Map any object model to any relational schema, using the Oracle Application Server TopLink Mapping Workbench graphical mapping tool
Use OracleAS TopLink successfully, even if they are unfamiliar with SQL or JDBC, because OracleAS TopLink provides a clean, object-oriented view of relational databases
In addition to providing industry-leading O-R mapping capabilities, OracleAS TopLink provides flexibility, increases performance and maximizes the productivity of your applications. OracleAS TopLink provides the following features:
Advanced object caching that improves performance by minimizing database access.
Rich query support that provides easy access to sophisticated, dynamic query languages and tools such as query by example, Java expression-based queries, EJB QL, and SQL.
A transactional framework that enables developers to easily create and modify mapped objects. This framework integrates the complexities of a shared memory space and caches, and provides scalability that supports multiple server instances (clustering). Although the mechanisms involved are complex, OracleAS TopLink makes it easy to leverage this functionality by simplifying the task of writing transactional code that complies with database referential integrity and optimal access patterns.
At its core, OracleAS TopLink is a runtime engine that provides Java or J2EE applications with access to persistent entities stored in a relational database. In addition to runtime capabilities, the Oracle Application Server TopLink Foundation Library includes the OracleAS TopLink Application Programming Interface (API). This API enables applications to access OracleAS TopLink runtime features, as well as development tools that simplify application development. The tools capture mapping and runtime configuration information in metadata files that TopLink passes to the runtime.
Figure 2-6 shows how the OracleAS TopLink components relate to one another throughout the development cycle.
Figure 2-6 TopLink Components in the Development Cycle
OracleAS TopLink application development comprises three elements: the development environment, the OracleAS TopLink runtime, and the metadata that ties them together.
To create an OracleAS TopLink application, map the object and relational models using the OracleAS TopLink Mapping Workbench, and capture the resulting mappings and additional runtime configurations in the OracleAS TopLink project file (the project.xml file). Then build a session configuration file (the sessions.xml file) in the OracleAS TopLink Sessions Editor. These files together represent your entire OracleAS TopLink project.
During development, developers leverage the OracleAS TopLink API to define query and transaction logic. When developers use EJB entity beans, there is generally little or no direct use of the OracleAS TopLink API.
The OracleAS TopLink Foundation Library provides the OracleAS TopLink runtime component. Access the runtime component either directly through the OracleAS TopLink API, or indirectly through a J2EE container when using EJB entity beans. The runtime engine is not a separate or external process; instead, it is embedded within the application. Application calls invoke OracleAS TopLink to provide persistence behavior. This function allows for transactional and thread-safe access to shared database connections and cached objects.
OracleAS TopLink metadata is the bridge between the development of an application and its deployed runtime. Capture the metadata using the OracleAS TopLink Mapping Workbench and OracleAS TopLink Sessions Editor, and pass the metadata to the runtime using deployment project.xml and sessions.xml files. It is also possible to hand-code these files using Java and the OracleAS TopLink API, but this approach is more labor-intensive.
The metadata, encapsulated in the project.xml file and the sessions.xml file, allows developers to pass configuration information into the runtime environment. The runtime uses the information in conjunction with the persistent entities (Java objects or EJB entity beans), and the code written with the OracleAS TopLink API, to complete the application.
The OracleAS TopLink Mapping Workbench is a graphical development tool that enables developers to map between the object and relational models, and configure many of the OracleAS TopLink Foundation Library features. The OracleAS TopLink Mapping Workbench creates an OracleAS TopLink project, the primary object in the OracleAS TopLink metamodel. Export the project as a single deployment XML file (the project.xml file), which OracleAS TopLink uses in conjunction with the OracleAS TopLink runtime to provide the application-specific persistence capabilities. Figure 2-7 shows how the OracleAS TopLink Mapping Workbench fits into the OracleAS TopLink environment.
Figure 2-7 The OracleAS TopLink Mapping Workbench in a TopLink Environment
The OracleAS TopLink Mapping Workbench can import compiled entity classes (Java objects or EJB entity beans), as well as relational schema through a JDBC driver that the developer configures. Because OracleAS TopLink imports the object and relational models for mapping, developers can develop the two models relatively independently from the O-R mapping phase of project development.
Most OracleAS TopLink applications include a session configuration file, the sessions.xml file, to simplify the application deployment process. The OracleAS TopLink Sessions Editor provides a graphical environment in which to configure the sessions.xml file.
Use the sessions.xml file to configure one or more sessions for the OracleAS TopLink project, and associate the sessions with the project. This approach allows developers to specify individual configurations for each session and to add or modify the following:
Database (JDBC) login information different from the login information used during development (for example, external data sources for the host application server's connection pools)
JTA/JTS transaction usage
Cache synchronization
Session broker (enables client applications to view multiple databases and projects as a single OracleAS TopLink session)
The Oracle Application Server TopLink Foundation Library includes a Java library that forms the runtime component of the product. It provides support and the API for the components that make up an OracleAS TopLink application. The API enables developers to interact with OracleAS TopLink to retrieve and modify their application persistent entities. Figure 2-8 shows the interaction of the parts of an OracleAS TopLink application.
Figure 2-8 OracleAS TopLink Application Components
|
Note: Although this section describes how these components fit into J2EE architectures, note that OracleAS TopLink also supports non-J2EE solutions. The Oracle Application Server TopLink Application Developer's Guide describes these solutions in more detail. |
A session is the primary interface between the client application and OracleAS TopLink, and represents the connection to the underlying relational database. OracleAS TopLink offers several different session types, each optimized for different design requirements and architectures. The session manager configures and manages the session as a singleton within the application.
The most commonly-used session is the server session, a singleton session that clients access on the server through a client session. The server session provides a shared cache and shared JDBC connection resources. OracleAS TopLink also supports sessions for two-tier architectures, distributed applications, and multiple databases.
The OracleAS TopLink data access component provides access to JDBC connections through connection pooling, provided either by OracleAS TopLink or a host application server. This component manages the SQL generation required by the various query operations and reconciles any differences between JDBC drivers and SQL dialects. OracleAS TopLink offers many performance tuning options that optimize its data access capabilities.
OracleAS TopLink supplies an object level cache that guarantees object identity and provides performance enhancement. Developers can configure the OracleAS TopLink cache and maximize the application efficiency by reducing the number of times the application accesses the database. In a clustered environment, developers can configure OracleAS TopLink to synchronize changes with other instances of the deployed application.
The OracleAS TopLink query framework provides developers with the flexibility necessary to manage the complex persistence requirements of enterprise applications. The key features of this query framework include:
A rich set of query types to allow object retrieval, summary results, and raw data retrieval
The ability to specify the search criteria using OracleAS TopLink Expressions (for object model based queries), EJB QL, SQL, stored procedures, or query by example
Configuration options that enable developers to specify how the query is executed, and customize many of its performance optimizing features
Developers can define OracleAS TopLink queries using the OracleAS TopLink Mapping Workbench, in Java code using the OracleAS TopLink API, or, in the case of EJB entity beans, through EJB Finders.
OracleAS TopLink provides the ability to write transactional code isolated from the underlying database and schema. OracleAS TopLink achieves this functionality through the Unit of Work.
The Unit of Work isolates changes in a transaction from other threads until it successfully commits the changes to the database. Unlike other transaction mechanisms, the Unit of Work automatically manages changes to the objects in the transaction, the order of the changes, and changes that might invalidate other OracleAS TopLink caches. The Unit of Work manages these issues by calculating a minimal change set, ordering the database calls to comply with referential integrity rules and deadlock avoidance, and merging changed objects into the shared cache. In a clustered environment, the Unit of Work also synchronizes changes with the other servers in the cluster.
If an application uses EJB entity beans, developers do not access the Unit of Work API directly, but they still benefit from its features: the integration between the OracleAS TopLink runtime and the J2EE container leverages the Unit of Work automatically.
JTA/JTS Integration: By default, OracleAS TopLink allows the application to create transaction boundaries for all object-level changes. OracleAS TopLink explicitly manages the database transaction, and if it encounters problems, safely rolls back both the database changes and the object-level changes.
In the case of a J2EE application, developers can configure OracleAS TopLink to synchronize with the JTA/JTS subsystem of the host application server. This feature allows an application to use container-managed transactions, rather than the default user-managed transactions.
Note that this functionality is not limited to EJB architectures. Developers can configure any OracleAS TopLink architecture to use container-managed transactions.
The OracleAS TopLink approach to persistence is based on metadata that defines the class structure (objects) and relational schema, along with other configuration information used by OracleAS TopLink at runtime. Developers can use the OracleAS TopLink Mapping Workbench to define this metadata, and the OracleAS TopLink runtime component uses the metadata to provide the necessary persistence capabilities, using Java's reflective and introspective capabilities.
The TopLink application metadata model is based around the OracleAS TopLink project. The project includes descriptors, mappings, and various policies that customize the runtime capabilities. Figure 2-9 shows this metadata model.
Use the sessions.xml file to configure sessions for the project. Developers can build and edit these files with the OracleAS TopLink Sessions Editor. The session manager uses the sessions.xml configuration file during application initialization.
The OracleAS TopLink deployment project is the primary container for the metadata. A project generally represents an application and contains the mapping information for all persistent classes and their relationships. Each session (excluding the session broker) in the deployed application references a single project. Although developers can build a project by coding it using the OracleAS TopLink API, we recommend that developers create and manage the project in the OracleAS TopLink Mapping Workbench, and use the OracleAS TopLink Mapping Workbench to generate either an XML or Java source version of the project for use at runtime.
A descriptor represents the association between a persistent Java class and a relational table or tables. The descriptor contains configuration information for the class level within a project, as well as a set of mappings for each of its persistent attributes. Many of the more advanced configuration options are set at the descriptor level. The OracleAS TopLink Mapping Workbench supports most of these options, but there are a few that developers must set using the OracleAS TopLink API.
Mappings describe how the attributes of a mapped class are associated with columns in the database. OracleAS TopLink provides a sophisticated set of flexible and customizable mappings that allow for complex mapping scenarios between the object and relational models.
There are two types of mappings: direct mappings and relationship mappings.
Direct Mappings: Direct mappings relate an attribute or attributes to a column or columns in the relational schema. OracleAS TopLink provides several direct mappings that allow for conversions between the types from the database and the object model's attribute types. Here are the direct mappings and their functions:
Direct-to-field mappings map a Java attribute directly to a value database column.
Type conversion mappings explicitly map a database type to a Java type.
Object type mappings match a fixed number of database values to Java objects.
Serialized object mappings store large data objects, such as multimedia files and BLOBs, in the database.
Transformation mappings offer specialized translations between how a value is represented in Java and in the database, such as when developers map multiple fields into a single attribute.
Relationship Mappings: OracleAS TopLink offers sophisticated relationship mapping, which enables developers to represent object relationships based on the database table columns and foreign keys. Here are the relationship mappings and their functions:
One-to-one mappings represent simple pointer references between two Java objects. The references use any of foreign keys, target foreign keys, or variable classes to define the pointer.
Aggregate object mappings represent the relationship between a given object and a target object. The objects have a strict one-to-one relationship, and all the attributes of the second object are retrievable from the same table as the owning object.
Aggregate collection mappings represent the relationship between a single-source object and a collection of target objects. Unlike one-to-many mappings, in which there must be a one-to-one back reference mapping from the target objects to the source object, there is no back reference required for the aggregate collection mappings, because the foreign key relationship is resolved by the aggregation (object and collection).
One-to-many mappings represent the relationship between a single source object and a collection of target objects.
Many-to-many mappings represent the relationships between a collection of source objects and a collection of target objects. They require an intermediate table for managing the associations between the source and target records.
Object-relational mappings are mappings that leverage databases that support object-relational entity storage within tables.
Using OracleAS TopLink to build an application does not affect the choice of development tools or the creative process. However, OracleAS TopLink does influence how developers approach development. This section highlights some of the key areas in which using OracleAS TopLink affects application development. These areas exist, regardless of whether developers are building an application to support Java objects, EJB entity beans, or both.
OracleAS TopLink maps the application's persistent entities to the database, using the descriptors and mappings developers build with the OracleAS TopLink Mapping Workbench. The OracleAS TopLink Mapping Workbench supports several approaches to project development, including:
Importing classes and tables for mapping
Importing classes and generating tables and mappings
Importing tables and generating classes and mappings
Creating both class and table definitions with mapping creation and model generation
The OracleAS TopLink Mapping Workbench supports all these options; however, the most common solution is to develop the persistent entities using a development tool, such as an integrated development environment (IDE) or modeling tool, and to develop the relational model through appropriate relational design tools. Developers then use the OracleAS TopLink Mapping Workbench to construct mappings that relate these two models.
The OracleAS TopLink Mapping Workbench does offer some facilities for generating persistent entities or the relational model components for an application; however, these utilities are intended only to assist in rapid initial development strategies, rather than complete round-trip application development.
Sessions are the primary interface between the application and OracleAS TopLink persistence capabilities. When developing an OracleAS TopLink application, developers must ensure that they properly initialize and manage the sessions.
When using EJB entity beans with container-managed persistence (CMP) or bean-managed persistence (BMP), the client code that modifies the entity beans does not access the OracleAS TopLink session directly. Instead, changes occur transparently, through integration with the container or through EJB callbacks.
Well-designed applications that employ Java objects as persistent entities use the session manager provided in the OracleAS TopLink API. This class initializes and manages the singleton session. Developers configure the session manager in the sessions.xml file, which allows for easy configuration and customization of the deployed application.
OracleAS TopLink furnishes several object and data query types, and offers flexible options for query selection criteria, including:
OracleAS TopLink expressions
EJB QL
SQL
Stored procedures
Query by example
With these options, developers can build any type of query. We recommend that developers use predefined queries to define application queries. Predefined queries are held in the project metadata and referenced by name. This simplifies application development and encapsulates the queries to reduce maintenance costs.
The OracleAS TopLink Mapping Workbench provides the simplest way to define queries. Developers can also build queries in code, using the OracleAS TopLink API.
If the application includes EJB entity beans, developers can code finders completely using EJB QL, which enables the application to comply with the J2EE specification. Alternatively, developers can use any of the other OracleAS TopLink query options. All querying options are available, regardless of the architecture or persistent entity type.
In an OracleAS TopLink application, the Unit of Work ensures that OracleAS TopLink transactions comply with the transactional requirements of the application.
The Unit of Work is one of the most sophisticated and powerful components of the OracleAS TopLink Foundation Library. Although developers that use CMP or BMP entity beans do not use the OracleAS TopLink API to apply transactional changes to their persistent entities, the Unit of Work is used behind the scenes. Understanding how the Unit of Work behaves, and developing simple coding patterns to use it, are the keys to building efficient, maintainable applications.
Application packaging (for deployment in the host Java or J2EE environment) influences OracleAS TopLink use and configuration. For example, developers package a J2EE enterprise application in an Enterprise Archive (EAR) file. Within the EAR file, there are several ways to package persistent entities within Web Application (WAR) and Java libraries (JAR). How developers configure OracleAS TopLink depends, in part, on how they package the application and how they use the host application server class loader.
OracleAS TopLink enables developers to monitor functionality and performance throughout application development, testing, and quality assurance cycles. OracleAS TopLink offers many textual logging features, as well as the API required to implement custom logging strategies. Developers can use these features to ensure that the application behaves and performs as they expect.
OracleAS TopLink includes a performance profiler feature, available through the OracleAS TopLink Foundation Library API. This runtime feature tracks query execution time, which developers can use for performance analysis. This tool provides the information necessary to identify bottlenecks that hinder application performance.
OracleAS TopLink also offers a rich set of performance enhancement features. Understanding how to configure these features can have a strong influence on application performance, especially in the later phases of application development.
OracleAS TopLink is designed to work in both Java and J2EE applications. Since it was first introduced, the flexibility OracleAS TopLink provides has led to its use in many architectural styles. This section introduces the five most common architectures associated with OracleAS TopLink. Although this section describes the architectures in relation to J2EE, OracleAS TopLink continues to fully support non-J2EE and Java applications as well.
The three-tier (or J2EE Web) application is one of the most common OracleAS TopLink architectures. This architecture is characterized by a server-hosted environment in which the business logic, persistent entities, and the OracleAS TopLink Foundation Library all exist in a single Java virtual machine (JVM).
The most common example of this architecture is a simple three-tier application in which the client browser accesses the application through servlets, Java Server Pages (JSPs), and HTML. The presentation layer communicates with OracleAS TopLink through other Java classes in the same JVM, to provide the necessary persistence logic. This architecture supports multiple servers in a clustered environment, but there is no separation across JVMs from the presentation layer and the code that invokes the persistence logic against the persistent entities using OracleAS TopLink.
A popular variation on the three-tier application involves wrapping the business logic, including the OracleAS TopLink access, in EJB session beans. This architecture provides a scalable deployment and includes integration with transaction services from the host application server. Communication from the presentation layer occurs through calls to the EJB session beans. This architecture separates the application into different tiers for the deployment.
The session bean architecture can persist either Java objects or EJB entity beans.
OracleAS TopLink provides CMP support for applications that require the use of EJB entity beans. This support is available on the leading application servers. OracleAS TopLink CMP support provides the developer with an EJB 1.1 and 2.1 CMP solution transparent to the application code, but still offers all the OracleAS TopLink runtime benefits.
Applications can access OracleAS TopLink-enabled EJB entity beans using CMP directly from the client, or from within a session bean layer. OracleAS TopLink also offers the ability to use regular Java objects in relationships with EJB entity beans.
Another option for using EJB entity beans is to leverage OracleAS TopLink BMP in the application. This architecture enables developers to access the persistent data through the EJB API, but is platform-independent.
The BMP approach is portable—that is, after a developer creates an application, you can move it from one application server platform to another.
A two-tier (or client-server) application is one in which the OracleAS TopLink application accesses the database directly. Although less common than the other architectures discussed here, OracleAS TopLink supports this architecture for smaller or embedded data processing applications.
Oracle JDeveloper is a J2EE and XML development environment with end-to-end support for developing, debugging, and deploying business applications and Web services. To maximize developer productivity, JDeveloper provides a comprehensive set of integrated tools to support the complete development life cycle, including the industry's fastest Java debugger and innovative profiler, and CodeCoach tools for code performance analysis and improvement. JDeveloper simplifies J2EE development by providing wizards, editors, visual design tools, and deployment tools to create high-quality, standard J2EE components, including applets, JavaBeans, JavaServer pages, servlets, and Enterprise JavaBeans.
Oracle JDeveloper is written entirely in Java and is certified for use with all major platforms, including Windows, Solaris, and Unix. The following some key features of Oracle JDeveloper.
CodeCoach Utility and Profiling Tools: To assist developers with optimizing Java code, JDeveloper provides a code coaching utility and three integrated profiling tools. With CodeCoach, you can increase the robustness of your code by optimizing system resources. The three profiling modes enable you to create a statistical analysis of the performance of your application with respect to it functionality, both at compile time and runtime. You can also analyze your application's memory use in the Java heap, and the occurrence and duration of various events.
Extensible and Pluggable Integrated Development Environment: JDeveloper provides a public Extension SDK, enabling its development environment to be extended and customized. Using this SDK, customers and partners can develop extensions and integrate them directly into the JDeveloper IDE. Developers can also share the technologies written with the Extension SDK at the JDeveloper Extensions Exchange at:
http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/index.html
Support for SQL, PL/SQL, and XML: In addition to Java, JDeveloper provides native support for SQL, PL/SQL, and XML. This support includes syntax highlighting and code insight, as well as PL/SQL development, PL/SQL debugging, and SQL tuning. Additionally, JDeveloper provides direct access to the database, allowing you to view, create, modify, and delete tables, views, triggers, indexes, sequences, and more.
Debugging Support: JDeveloper offers robust debugging support for both Java and PL/SQL. Debugging in these two environments is seamlessly integrated when using an Oracle database, providing the ability to step from Java code directly into PL/SQL code within the same debugging session. Other features include remote debugging, debugging multiple processes on multiple servers, tracking relevant data members in a smart data window, and a count of instantiations per class.
Business Intelligence Beans: To allow the development of highly analytical business intelligence applications, JDeveloper has integrated Oracle Business Intelligence Beans (BI Beans) into its environment. BI Beans enable developers to build applications that take advantage of the new analytic capabilities available in the Oracle database. Using modular components and intuitive wizards, developers can build sophisticated BI applications quickly and easily.
Oracle Application Development Framework (Oracle ADF) is a runtime framework included with Oracle JDeveloper. Together with the design time tools JDeveloper provides, Oracle ADF allows J2EE application developers to partition application layers.
While developing and deploying J2EE applications involves many technologies and a diverse infrastructure, many of the design patters are common to distributed applications, and can be abstracted into a runtime framework. Without such a framework, the various J2EE and Web services technologies must be defined at the interface level.
One of the roles of Oracle ADF is to support deployed applications that fit into the robust, scalable, and flexible architecture of the J2EE platform. When developers work with Oracle ADF and develop applications in JDeveloper, they can work with these familiar technologies to write code while benefiting from the J2EE platform infrastructure:
Presentation tier: JSP pages for Web applications and Swing UI components for the standalone Java client
Business tier: JavaBeans, EJB Session Beans, and Web services
Integration tier: EJB Entity Beans
The Model-View Controller (MVC) pattern is a J2EE architectural design pattern useful for developing applications that combine distributed application logic and a complex user interface. The goal when using MVC is to enforce partitioning between the application logic and the user interface.
Generally, the model is the underlying logical representation, the view is the visual representation, and the controller specifies how to handle user input. When the data model changes, it notifies all of the views that depend on it. This separation of state and presentation means that multiple views can be based on the same model, and views can be created and modified without affecting the underlying model.
Together with JDeveloper design-time tools, Oracle ADF allows J2EE application developers to partition application layers based on desired technologies. Developers are able to do the following:
Partition applications based on J2EE-compliant objects using the Oracle ADF technology stack, including Oracle ADF Business Components, Oracle ADF Model, Struts Web application controller, and Oracle ADF view technologies.
Partition applications based on the components of J2EE BluePrints (such as JSP, Jakarta Struts, and EJBs) while using only the data binding services of the Oracle ADF Model layer to simplify access to your existing business services from both the view and controller.
Partition applications that combine your existing business services with Oracle ADF views, Struts Web applications controller, and the Oracle ADF Model data-binding layer.
Developers can use as much or as little of Oracle ADF as they choose when building components using the MVC architectural design pattern for J2EE applications. Oracle ADF does not prevent an application development team from mixing any layer of Oracle ADF with any J2EE component or any legacy business service.
To enable e-businesses to work effectively, the Internet needs to support a standards-based infrastructure that enables companies and their enterprise applications to communicate with other companies and their applications more efficiently. These standards should allow discrete business processes to expose and describe themselves on the Internet, allow other services to locate and invoke them, and provide a predictable response.
Web services drive this transformation by promising a fundamental change in the way businesses function and enterprise applications are developed and deployed. A Web service is a discrete business process that does the following:
Exposes and describes itself: A Web service defines its functionality and attributes so that other applications can understand it. A Web service makes this functionality available to other applications.
Allows other services to locate it on the Web: A Web service can be registered in an electronic Yellow Pages, so that applications can easily locate it.
Can be invoked: Once a Web service has been located and examined, the remote application can invoke the service using an Internet standard protocol.
Returns a response: When a Web service is invoked, the results are passed back to the requesting application over the same Internet standard protocol used to invoke the service.
Web services provide a standards-based infrastructure through which any business can do the following:
Offer appropriate internal business processes as value-added services that can be used by other organizations
Integrate its internal business processes and dynamically link them with those of its business partners
Oracle Application Server Web Services run as servlets in the OC4J servlet container. This gives Web services the same scalability, availability, and load balancing facilities that all J2EE applications have in Oracle Application Server.
Oracle Application Server Web Services support both Remote Procedure Call (RPC) style exchange and message oriented, or Document Style, exchange. Supported RPC Web services include Java classes, stateless session EJBs, and stateless PL/SQL stored procedures. Supported Document Style Web services include Java Class Document Style Web Services and JMS Document Style Web Services.
Oracle Application Server Web Services use a different J2EE standards-compliant servlet for each implementation type to provide an entry point into the Web services implementation. Figure 2-10 illustrates the Oracle Application Server Web Services runtime architecture, including the servlet entry points.
Figure 2-10 Oracle Application Server Web Services Architecture
For a detailed discussion of the Oracle Application Server Web Services architecture, see the Oracle Application Server Web Services Developer's Guide.
Oracle Application Server Web Services provides advanced runtime features and comprehensive support for developing and deploying Web services.
Key Oracle Application Server Web Services development features include:
Development Environment: Oracle Application Server Web Services allows application developers to implement Web services using J2EE components. In addition, you can use Java classes or PL/SQL stored procedures to implement Web services. Web services inherit all the runtime and lifecycle management elements of J2EE applications.
Development Tools and Wizards: Oracle Application Server Web Services developers can use the same set of command line utilities to create, package, and deploy Web services that they use for other Oracle Application Server Containers for J2EE (OC4J) applications. In addition, Oracle Application Server Web Services provides the Web Service HTML/XML Streams Processing Wizard that assists developers in creating an EJB whose methods access and process XML or HTML streams.
Automatically Generates WSDL: Oracle Application Server Web Services can generate Web Services Description Language (WSDL) and client-side proxy stubs. This generation occurs when the Web service is assembled using the Web Services Assembly tool or, for a deployed Web service, the first time the WSDL or the client-side stubs are requested. After the first request, the previously generated WSDL or client-side proxy stubs are sent when requested.
Registration, Publishing, and Discovery: Oracle Application Server Web Services provides a standards-compliant UDDI registry where Web services can be published and discovered. The Oracle UDDI registry supports both a private and public UDDI registry and can also synchronize information with other UDDI nodes.
Developer Simplicity: Using Oracle Application Server Web Services, developers do not need to learn a completely new set of concepts. Web services are developed, deployed, and managed using the same programming concepts and tools as J2EE applications.
Business Logic Reuse: Application developers can transparently publish their J2EE applications to new Web services clients with no change in the application itself. The existing business logic developed in J2EE can be transparently accessed from existing J2EE/EJB clients.
Common Runtime Services: Oracle Application Server has a common runtime and brokering environment for J2EE applications and Web services. As a result, Web services transparently inherit various services available with the J2EE container, including transaction management, messaging, naming, logging, and security services.
Key Oracle Application Server Web Services deployment and management features include:
Packaging and Assembly: The Web Services Assembly Tool assists with assembling Web services and producing a J2EE .ear file.
Deployment: Oracle Enterprise Manager provides a comprehensive set of facilities for deploying Web services to Oracle Application Server through Oracle Enterprise Manager Application Server Control. Application Server Control provides a single, consistent Deploy Application page for deploying Web services to Oracle Application Server. It accepts a J2EE .ear file, and takes you through the steps to specify information about the application you are deploying, and then deploys the application.
Register Web Service: The Deploy Application page also provides access to facilities for registering Web services in the UDDI registry.
Browse the UDDI Registry: The Oracle UDDI registry provides the UDDI standards-compliant, pre-defined, hierarchical categorization schemes. Oracle Enterprise Manager can drill down through these categories and look up specific Web services registered in any category.
Monitoring and Administration: Once deployed, Oracle Enterprise Manager provides facilities to deinstall a Web service, and also to monitor Web service performance as measured by response time and throughput, and to monitor status as measured by up time, CPU consumption, and memory consumption. Oracle Enterprise Manager also provides facilities to identify and list all of the Web services deployed to a specific Oracle Application Server instance.
Oracle Forms applications combine interactive graphical interfaces with strong support for data validation. Forms developers can quickly create applications with powerful data manipulation features.
An Oracle Forms application gives you the power of a desktop application deployed in a browser. It provides a very rich and productive user interface by allowing the following:
Immediate data validation as clients enter data into the form instead of after submitting the form
Automatic completion and list of value searches for fields that enable users to enter correct information quickly
An Oracle Forms application is analogous to a traditional HTML form application. In the traditional application, the user enters data into a form on a Web page and submits the data. The Web server processes the data from the form in a CGI application. The application then performs any necessary transactions and returns feedback to the user's browser. JavaScript and the database perform data validation tasks to ensure that the data from the form is correct and complete.
Oracle Application Server Forms Services deploys Forms applications to Java clients in a Web environment. Oracle Application Server Forms Services automatically optimizes class downloads, network traffic, and interactions with the Oracle database. Applications are automatically load-balanced across multiple servers and, therefore, can easily scale to service any number of requests.
Oracle Application Server Forms Services consists of four components:
Forms Servlet: The Forms Servlet is used to establish the initial connection when a user starts a Forms application. It returns to the client the HTML file that contains the Forms Client applet.
Forms Client Applet: A Java applet running in the client browser. It provides the user interface for the corresponding Forms Runtime Process.
Forms Listener Servlet: A servlet running in the OC4J servlet container. It manages the lifecycle of the Forms Runtime Process and network connections to the runtime process.
Forms Runtime Process: A process running in an Oracle Application Server instance. The process maintains the connection between the client applet and the database.
When a client requests an Oracle Application Server Forms Services application, the request has the following flow:
The user launches a browser and navigates to the URL for the Forms application.
The HTTP Listener interprets the URL and displays an HTML page containing an <APPLET> tag that describes the Forms Java Client to the browser. The URL calls the Forms servlet to create the HTML page dynamically.
The client receives the HTML file served by the HTTP Listener. The HTML file supplies the information required to locate the Java class files that make up the Forms Java Client. The HTML file also contains information about the requested Forms application, as well as parameters that get passed to the Forms session, such as login information.
The browser downloads the Forms Java Client and the Java applet starts.
The Forms Java Client applet sends a request to start a Forms session through the HTTP Listener to the Forms Listener Servlet.
After receiving the connection request from the Forms Java Client, the Forms Listener Servlet starts a new Forms Runtime process for the client.
The Forms Runtime process allocated to the client loads the module specified in the HTML file and any libraries and menus that are required by that form. All communication between the Forms Java Client and the Forms Runtime process is passed through the Forms Listener Servlet.
The user is prompted for database login information, and the connection to the database server is established.
The user is now ready to work with the Forms application.
Table 2-4 illustrates this flow in terms of the Oracle Application Server Forms Services architecture.
Figure 2-11 Oracle Application Server Forms Services Request Flow
Oracle Application Server Forms Services provides the following features to allow a robust and standard deployment of Forms applications on the Internet.
Oracle Application Server Forms Services is an optimized framework for deploying Oracle Forms applications to a multi-tiered environment. OracleAS Forms Services delivers out-of-the-box functionality and native services to ensure that Forms applications automatically scale and perform over any network. OracleAS Forms Services allows organizations to re-deploy existing applications to the Internet without changing the application code.
With OracleAS Forms Services, the scalability and high performance of Internet deployment do not rely on the quality of the application or on the developers' skills; applications developed with Oracle Forms automatically scale and perform through the use of built-in services that Oracle Forms provides. These services natively deliver the building blocks and the infrastructure of an e-business solution. Business developers do not have to implement complex, low-level infrastructure code and therefore can focus on implementing business requirements. Examples of these native services include record caching and record locking, database management, exception handling, and load balancing.
As a fully-integrated component of Oracle Application Server, OracleAS Forms Services utilizes the Oracle Application Server Infrastructure. The deployment architecture of OracleAS Forms Services uses Oracle Application Server Containers for J2EE (OC4J). Codeless integration with Oracle Application Server Single Sign-On Server eliminates the need for users to remember multiple passwords. And leveraging the power of Oracle Enterprise Manager Application Server Control means that system administrators can use a single point of control to start, shutdown, monitor, trace, and diagnose OracleAS Forms Services runtime processes.
OracleAS Forms Services is highly optimized to reduce network traffic and to minimize database response time. For example, OracleAS Forms Services renders application interfaces as highly-optimized generic Java applets and uses mechanisms such as message diffing, message bundling, and JAR file caching to reduce the number of round trips between the client and the middle tier. At the same time, OracleAS Forms Services leverages the capabilities of the Oracle database to minimize interactions with the database server.
The deployment with OracleAS Forms Services is optimized for corporate intranets, extranets, and for the Internet using socket connections or HTTP/HTTPS communications between the client and the middle tier. The support for HTTP/HTTPS allows Oracle Forms applications to be deployed across industry firewalls in a highly secure and optimized fashion.
Ensuring that your application has no single point of failure is essential to guaranteeing your application is highly available. The OracleAS Forms Services runtime architecture is based on standard servlets, meaning you can use standard load balancing techniques such as hardware load balancing, reverse proxy servers, and standard load balancing through Oracle Application Server.
Through code-based integration, OracleAS Forms Services gives you the flexibility to leverage emerging standards, including Java and XML, within your Oracle Forms applications. This gives you the advantages of both the application framework and built-in scalability and performance of OracleAS Forms Services, along with the flexibility to leverage Java and XML to extend your applications.
OracleAS Forms Services gives you the ability to access components written in Java and make use of them from Oracle Forms applications on the middle tier. Using this feature, OracleAS Forms Services is able to communicate and integrate with other applications or technologies, such as Web services, XML, Enterprise JavaBeans, and non-standard devices.
OracleAS Forms Services renders the application presentation as a generic and optimized Java applet. This applet can be extended using Java components (such as JavaBeans and Pluggable Java Components) so that business developers can quickly and easily deliver sophisticated interfaces that maximize end user productivity. The Java client extensibility, along with the new look and feel, leverages the strength of Java without the need for business developers to learn the language.
Access control through URL parameters: This feature allows developers and administrators to define which parameters are valid for a particular URL and those which are not allowed. This ensures that end-users cannot access forms using parameters that may be valid but that, for security reasons, are not allowed. For example, a developer could restrict the usage of the USERID parameter, thereby forcing the end-user to log in using the default login window.
Runtime Pre-Start: This feature improves Forms startup times by pre-starting runtimes for different applications.
Management and monitoring: Through Forms you can manage environment configuration, trace configuration files, and manage the Runtime Pre-Start capability. Monitoring features include start/stop tracing, viewing trace outputs, and searching for processes through Oracle Enterprise Manager.
Supports a broad range of firewalls and proxies: Because the client browser always communicates with the HTTP Listener using HTTP or HTTPS, the Forms architecture supports any firewall or proxy that can work with a standard servlet using servlet sessions.
Supports both HTTP/1.0 and HTTP/1.1: Since standard communication is used, both HTTP protocols are supported. Using HTTP/1.1 results in better performance, while using HTTP/1.0 consumes fewer resources on the server.
No specific security requirements for SSL deployment: In the case of deployment using secure sockets layer (SSL), the HTTPS connection occurs between the client browser and the HTTP Listener. Therefore, there are no specific security configuration requirements at the Forms Server level.
Standard load balancing support: The Forms Services architecture allows you to use standard load balancing techniques, such as hardware load balancing, reverse proxy, and standard servlet load balancing.
Support for JDK 1.4 for the Forms Java Client: The Forms Java Client is now able to use version 1.4 of the Java Runtime Environment (JRE). You can use all of the Java 1.4 APIs when writing pluggable Java components or integrating the Forms Java Client with other Java applets or Javabeans.
Support for JRE 1.4 in the Middle Tier: The Java Importer provides easy-to-use Java integration from PL/SQL. The Java Importer can be used with version 1.4 of the Java Runtime Environment, making it possible to integrate Forms applications with the latest external programs and services.
Run applications on any network: The Forms Listener Servlet architecture allows you to deploy your Forms applications to run on any network: Internet, intranet, or extranet. Only standard ports in your firewall need to be opened and authenticating proxies are supported.
Single Sign-On Support: Forms Services can use the authentication services provided by the Login Server and mod_osso included with Oracle Application Server, which are integrated with the Oracle Internet Directory and are LDAP-compatible.
Deploy to multiple languages: To assist you in translating your Forms applications to other languages, Oracle TranslationHub keeps a repository of your translations and lets you preview the Forms while they are being translated. Using Forms Services, you can deploy a Forms application in many different languages with a single installation.
Universal time awareness: Forms Services supports the ability to define time zones at all levels of your application so that the correct time is stored in the database. This helps eliminate confusion that may arise when dealing with time, such as whether a time entered in a Forms application is relative to the user, the database server, or the location of the Forms Services deployment.
Browser language detection: Forms Services can automatically detect a client's browser language setting. You can use this feature to allow users to access an application through one URL and automatically redirect them to the translation that matches the language set in their browser.
XML makes data portable and interoperable across heterogeneous systems. XML is a metamarkup language that supports markup tags that have been defined by the user to encapsulate and describe data in a Web page. Because it is a self-defined language, it is extremely flexible.
Oracle Application Server includes the Oracle XML Developer Kit (XDK) to support development of any applications that use XML. The XDK provides basic XML infrastructure components for manipulating and transforming XML documents. The XDK contains component libraries and utilities that are based on World Wide Web Consortium (W3C) specifications. You can use these components to generate, manipulate, render, and store XML-formatted data in an Oracle database or to share data between applications written in diverse programming languages.
The following sections describe the tools included in the Oracle XML Developer's Kit.
The XML parser APIs are defined by the W3C specifications so that application developers can use standard programming interfaces. However, if some functionality is not specified, then Oracle Corporation may implement its own enhancements to the specifications.
The Oracle XML and XSLT parsers provide international character set and multithreaded support, allow optional validation, and cache document type definitions (DTDs) and stylesheets for performance.
Oracle XML Developer's Kit provides the following APIs:
Document Object Model (DOM) APIs: Because an XML document is structured, in the sense that "start" tags have corresponding "end" tags and these tags are nested in an ordered fashion, an XML document can be viewed as a tree whose hosts consist of these tags and information between and corresponding to the tags. When the DOM APIs are used to navigate an XML document, the XML parser parses the document and forms a tree representation of it in memory.
Simple APIs for XML (SAX) APIs: SAX APIs are event-based, meaning that notification of certain events and data encountered during the parsing of an XML document can be reported with callback functions to the application program. One advantage over DOM is that an in-memory representation of the parse tree does not have to be built, thus saving memory and improving performance. When application programs are notified of these events, then they must handle them.
Namespace APIs: These interfaces resolve namespace prefixes that are used to qualify element and attribute names in XML documents. XML document namespaces are identified by uniform resource identifier (URI) references that qualify element or attribute names and locate resources that may be on different machines or in different XML documents. Namespaces make it possible to have identical names for elements and attributes by qualifying them with URIs that differentiate the names.
Parser APIs: Application programmers invoke the parser API to read an XML document and to provide access to its content and structure through DOM or SAX APIs. Typically, initialization and termination functions must also be invoked in association with the parse function. Various flags, such as to discard whitespace and turn on validation, can be set with initialization functions before the application program invokes the parse function.
XSLT APIs: These interfaces read the input stylesheet file and transform the input XML document according to the stylesheet. A command-line interface to the integrated XSLT processor is provided. This allows application programmers to specify the number of threads to use to parse and transform XML documents and other useful options. To enhance performance, the XSLT engines allow caching of both stylesheets and Document Type Definitions (DTDs) so they can be reused for multiple XML documents.
Oracle XML schema processors comply with the Structures and Datatypes sections of the W3C XML Schema Working Drafts, except for certain features (such as unique, key and keyref constraints) when the SAX parser is used. XML schemas are a superset of DTDs, except for the support of primitive and complex datatypes in XML schemas. This allows you to validate XML documents, with embedded datatype information, against XML schemas.
The XML class generators create a set of Java or C++ classes that create XML documents corresponding to a DTD or to XML schema definitions. This is useful when an application wants to send an XML message to another application based on an agreed-upon DTD, or as the back end of a Web form to construct XML documents. You can use the generated classes to programmatically construct XML documents that comply with the DTD or schema definition.
XSQL Servlet is a tool that processes SQL queries and outputs the result set as an XML document. This processor uses an XML file with embedded SQL queries as its input. You can use XSQL Servlet to perform the following tasks:
XML transviewer beans are a set of XML components that constitute XML for Java beans. These are used by Java applications or applets to view and transform XML documents.
These beans are visual and non-visual Java components that are integrated into Oracle JDeveloper to enable the fast creation and deployment of XML-based database applications.
Oracle Application Server provides support for building PL/SQL-based applications on the Web. PL/SQL stored procedures retrieve data from a database and generate HTTP responses containing data and code to display in a Web browser. There are many techniques for coding dynamic pages, but PL/SQL is particularly suited for producing dynamic pages based on database processing. Its support for DML statements, dynamic SQL, cursors, and tight server integration provide both power and flexibility for Web applications. The dynamic pages can contain links and HTML forms that call more stored procedures, for example to drill down on the displayed data. The set of interlinked HTML pages forms the user interface of the Web application. Producing dynamic content using PL/SQL stored procedures gives you the flexibility and interactive behavior of CGI programs, without the memory overhead of starting a new CGI process each time.
Oracle Application Server PL/SQL developers can create applications using either Oracle PL/SQL Server Pages or Oracle PL/SQL Web Toolkit.
Mod_plsql is an Apache plug-in that provides support for building PL/SQL-based applications on the Web. It maps browser requests into PL/SQL stored procedures, which retrieve data from a database and generate HTTP responses containing data and code to display in a Web browser.
To include dynamic content inside Web pages, including the results of SQL queries, you can use server-side scripting through PL/SQL Server Pages (PSPs). You can author the Web pages in a script-friendly HTML authoring tool and drop the pieces of PL/SQL code into place. You may find this technique more convenient than using the HTP and HTF packages to write out HTML content line by line.
Because the processing is done on the database server rather than the Web server, the browser receives a plain HTML page with no special script tags, and you can support all browsers and browser levels equally. It also makes network traffic efficient by minimizing the number of server roundtrips.
Embedding the PL/SQL code in the HTML page that you create lets you write content quickly and follow a rapid, iterative development process. You maintain central control of the software, with only a Web browser required on the client machine.
The PL/SQL Web Toolkit contains PL/SQL packages that allow you to create applications that generate dynamic HTML. Using the toolkit, you can access data and insert it into Web pages. The packages remove the need for you to know the specifics of HTML syntax and allow you to focus on writing applications.
Oracle Application Server PL/SQL leverages the mod_plsql module to deliver Web content, as follows:
Visiting a Web page, following a hypertext link, or submitting an HTML form causes the database server to run a stored procedure.
Any choices that a user makes on an HTML form are passed as parameters to the stored procedure. Parameters can also be hardcoded in the URL used to invoke the stored procedure.
The results of the stored procedure are printed as tagged HTML text and are displayed in the browser as a Web page. Web pages generated this way are dynamic: code runs inside the database server, producing HTML that varies depending on the database contents and the input parameters.
This kind of dynamic content is different from dynamic HTML (DHTML). With DHTML, the code is downloaded as JavaScript or some other scripting language, and processed by the browser along with the HTML. A PL/SQL Web application can print JavaScript or other script code in its output to produce complex DHTML that would be tedious to produce manually.
Oracle Application Server includes the Oracle Content Management Software Development Kit (CM SDK), a robust document lifecycle system that is built in Java and integrated with other Oracle content management API products. Oracle customers and partners have built successful solutions on this Java-based platform that leverages the features and capabilities of the Oracle platform.
Oracle CM SDK provides, out of the box, the content and metadata repository, protocol servers, and class libraries that allow developers to quickly create content management solutions.
Figure 2-12 shows the basic architecture of Oracle CM SDK. Once installed, developers can immediately start storing content into the repository via standard file system protocols such as FTP or WebDAV. They can then provide the business logic for their specific requirements and create a Web-based user interface. Also included with the Oracle CM SDK installation is a Web starter application that demonstrates how to create Web-based content management applications.
Figure 2-12 Oracle Content Management SDK Architecture
Important features and capabilities of Oracle CM SDK include the following:
Integration with Oracle Text, Oracle Workflow, and Oracle interMedia
Complete document lifecycle API with a variety of options for security, check-in/check-out, versioning, searching, extensible metadata, and other standard content management operations
Easy extensibility to help you develop and deploy your content management solutions faster
Managed through Oracle Enterprise Manager Application Server Control
Synchronous and asynchronous trigger mechanisms to enforce business rules
Built-in support for standard protocols such as HTTP/WebDAV, SMB/NTFS, FTP, NFS, and IMAP4/SMTP
Support for standard Oracle performance, scalability, and high availability features such as RAC
Oracle Application Server MapViewer is a programmable tool for rendering maps using spatial data managed by Oracle Spatial or Oracle Locator. MapViewer provides tools that hide the complexity of spatial data queries and cartographic rendering, while providing customizable options for more advanced users. These tools can be deployed in a platform-independent manner and are designed to integrate with map-rendering applications.
The following concepts are fundamental to understanding MapViewer:
Style: A style defines the rendering properties for features that are associated with the style. For example, a text style determines how a feature is labeled on a map, while a line style determines the rendition of a linear feature such as a road.
Theme: A theme is a collection of features (entities with spatial and nonspatial attributes) that are associated with styles through the use of styling rules.
Base map: A base map consists of one or more themes.
Mapping metadata: Mapping metadata consists of a repository of styles, themes, and base maps stored in a database.
Map: A map is one of the components that MapViewer creates in response to a map request. The map can be an image file, the object representation of an image file, or a URL referring to an image file.
When an application uses MapViewer, it applies specific styles, such as colors and patterns, to specific themes, such as cities, rivers, and highways, to render a map. For example, the application might display a map in which state parks appear in green and restaurants are marked by red stars. A map typically has several themes representing political or physical entities, or both. For example, a map might show national and state boundaries, cities, mountain ranges, rivers, and historic sites. When the map is rendered, each theme represents a layer in the complete image.
MapViewer lets you defines styles, themes, and base maps, including the rules for applying one or more styles to each theme. These styles, themes, base maps, and associated rules are stored in the database in map definition tables under the MDSYS schema, and they are visible through metadata views. All styles in a database instance are shared by all users. The mapping metadata that you can access is determined by MapViewer metadata views. The set of map definition objects that a given user can access is sometimes called that user's mapping profile.
With MapViewer, the basic flow of action involves two steps, regardless of whether the client requests a map or a MapViewer administrative action.
For a map request, the following occurs:
The client requests a map, passing in the map name, data source, center location, map size, and optional other data to be plotted on top of a map.
The server returns the map image (or a URL for the image), the minimum bounding rectangle (MBR) of the map, and the status of the request.
For a MapViewer administrative request, the following occurs:
The client requests a MapViewer administrative action, passing in the specific type of request and appropriate input values.
The server returns the status of the request and the requested information.
Figure 2-13 shows the MapViewer architecture, which supports this flow of action.
As shown in Figure 2-13:
MapViewer is part of the Oracle Application Server middle tier.
MapViewer includes a rendering engine.
MapViewer can communicate with a client Web browser or application using the HTTP protocol.
MapViewer performs spatial data access (reading and writing Oracle Spatial and Locator data) through JDBC calls to the database.
The database includes Oracle Spatial or Locator, as well as mapping metadata.
MapViewer includes the following main components:
A rendering engine (Java class library) that provides cartographic capabilities (a map renderer)
An XML API that provides a programmable interface to MapViewer
The rendering engine connects to the Oracle database through Java Database Connectivity (JDBC). It also loads the map metadata from the database, and applies it to the retrieved spatial data.
The XML API provides high-level application developers with a convenient interface for submitting a map request to the middle-tier MapViewer and handling its map response.
