|
Oracle® Containers for J2EE Services Guide
10g Release 3 (10.1.3) B14427-01 |
|
 Previous |
 Next |
|
Oracle® Containers for J2EE Services Guide
10g Release 3 (10.1.3) B14427-01 |
|
|
Previous |
Next |
Oracle Containers for J2EE (OC4J) supports the following technologies, each of which has its own chapter in this book:
This chapter gives a brief overview of each technology in the preceding list and a link to the relevant chapter.
|
Note: In addition to these technologies, OC4J supports the JavaMail API, the JavaBeans Activation Framework (JAF), and the Java API for XML Processing (JAXP). For information about these technologies, see the Sun Microsystems J2EE documentation. |
The Java Naming and Directory Interface (JNDI) service that is implemented by OC4J provides naming and directory functionality for Java applications. JNDI is defined independently of any specific naming or directory service implementation. As a result, JNDI enables Java applications to access different, possibly multiple, naming and directory services using a single API. Different naming and directory service provider interfaces (SPIs) can be plugged in behind this common API to handle different naming services.
See Chapter 2, "Oracle JNDI", for details.
Java Message Service (JMS) provides a common way for Java programs to access enterprise messaging products. JMS is a set of interfaces and associated semantics that define how a JMS client accesses the facilities of an enterprise messaging product.
In past releases, Oracle has used the terms "OracleAS JMS" and "OJMS" when describing the In-Memory, File-Based, Database persistence options. "OracleAS JMS" referred to the In-Memory and File-Based options while "OJMS" referred to JMS interface to Streams Advanced Queuing (AQ). To avoid any confusion regarding JMS, the term "OEMS JMS" is used instead of the terms "OracleAS JMS" and "OJMS". This reflects the fact that Oracle offers a single JMS interface to the three message persistence options. Your JMS application code will not have to change if you decide to change message persistence between any of the three quality of service choices.
See Chapter 3, "Oracle Enterprise Messaging Service (OEMS)", for details.
A data source is the instantiation of an object that implements the javax.sql.DataSource interface. A data source enables you to retrieve a connection to a database server.
See Chapter 4, "Data Sources", for details.
EJBs use Java Transaction API (JTA) 1.0.1 for managing transactions. These transactions involve single-phase and two-phase commits.
See Chapter 5, "OC4J Transaction Support", for details.
Remote Method Invocation (RMI) is one Java implementation of the remote procedure call paradigm, in which distributed applications communicate by invoking procedure calls and interpreting the return values.
OC4J supports RMI over both the Oracle Remote Method Invocation (ORMI) protocol and over the Internet Inter-ORB Protocol (IIOP).
By default, OC4J uses RMI/ORMI. In addition to the benefits provided by RMI/IIOP, RMI/ORMI provides additional features such as invoking RMI/ORMI over HTTP, a technique known as "RMI tunneling."
Version 2.0 of the Enterprise Java Beans (EJB) specification uses RMI over the Internet Inter-ORB Protocol (IIOP) to make it easy for EJB-based applications to invoke one another across different containers. You can make your existing EJB interoperable without changing a line of code: simply edit the bean's properties and redeploy. J2EE uses RMI to provide interoperability between EJBs running on different containers.
For details on RMI/ORMI and interoperability (RMI/IIOP), see Chapter 6, "Using Remote Method Invocation in OC4J".
The Java Object Cache (formerly OCS4J) is a set of Java classes that manage Java objects within a process, across processes, and on a local disk. The primary goal of the Java Object Cache is to provide a powerful, flexible, easy-to-use service that significantly improves server performance by managing local copies of objects that are expensive to retrieve or create. There are no restrictions on the type of object that can be cached or the original source of the object. The management of each object in the cache is easily customized. Each object has a set of attributes associated with it to control such things as how the object is loaded into the cache, where the object is stored (in memory, on disk, or both), how it is invalidated (based on time or by explicit request), and who should be notified when the object is invalidated. Objects can be invalidated as a group or individually. See Chapter 7, "Java Object Cache", for details.
XML Query Service (XQS), a new service in the OC4J 10.1.3 implementation built upon XQuery (the XML query language) that provides a convenient user model for the retrieval, analysis, integration, and transformation of enterprise data. Generally, without a service such as XQS, XQuery is limited to accessing XML documents. With XQS, you can also retrieve data from non-XML documents, relational databases, and other possibly non-XML enterprise information systems, through access mechanisms such as SOAP or SQL. See Chapter 8, "XML Query Service", for details.
This appendix lists the licensing agreements that pertain to the third-party products included with Oracle Application Server. See Appendix A, "Third Party Licenses", for details.
