| Creation Date: | November 28, 2003 |
| Status: | Production |
| Version: | PDK Release 9.0.4 |
This article explains how to package up your PDK-Java provider implementation into a portable format suitable for deployment on OracleAS or other J2EE Appplication server. It goes on to explain how to deploy the resulting EAR file in an OracleAS environment and subsequently register it with one or more OracleAS Portal instances.
WAR and EAR files are used to deploy applications in a J2EE application server, such as OracleAS. The purpose of the WAR and EAR files is to encapsulate all the components necessary to run an application in a single file. This makes the deployment of an application packaged this way very easy and very consistent, reducing the possibility of errors due when an application needs to be moved from development to test, to production. However, this does require a little more work from developers to create the files.
WAR files represent a web application and include all the components of that web application including java libraries or classes, servlet definitions and parameter settings, JSP files, static HTML files and any other resources the application might need.
EAR files represent an "enterprise application". This is primarily an EJB concept, but also provides a grouping mechanism for web applications.
The PDK-Java allows you to deploy multiple providers under a single adapter servlet. The providers are identified by a service name or service identifier. When you deploy a new provider you must assign a service name to the provider and use that service name when creating your provider WAR file.
Once your provider has been deployed, the correct service name must be used when registering your provider in OracleAS Portal to ensure that requests are sent to the correct provider. For 3.0.x releases of OracleAS Portal that do not understand the concept of a service name, you can choose one of your providers to be the default. If the adapter servlet receives a request that does not specify a service name, the request will be forwarded to the default provider.
The first step in deploying your provider is to create the WAR file that contains the provider and all the resources it needs to execute. The steps below represent manual configuration of a WAR file. If you are familiar with one of the various utilities for assembling WAR files, you are free to use it, but the following manual steps should also suffice.
The default service is the provider that should receive any request that does not specify a service name. This feature is provided to allow you to register your provider on release 3.0.9 of OracleAS Portal.
The default provider is specified by editing the _default.properties file in the deployment directory of your WAR file. The _default.properties file looks something like this:
serviceClass=oracle.webdb.provider.v2.adapter.soapV1.ProviderAdapter
loaderClass=oracle.portal.provider.v2.http.DefaultProviderLoader
showTestPage=true
definition=providers/sample/provider.xml
autoReload=true
Edit the "definition" entry so it points to the provider definition file that represents your default provider. The directory path should be based on the contents of you WAR file, not the physical location of the file on the filesystem.
If you are not using a provider definition file to define your provider, you need to create an implementation of the ProviderLoader interface and edit the "loaderClass" entry.
Once you have specified the contents of your WAR file, you are ready to create the WAR file itself. To create the WAR file:
The steps below represent manual configuration of an EAR file. If you are familiar with one of the various utilities for assembling EAR files, you are free to use it.
<?xml version "1.0">
<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN"
"http://java.sun.com/j2ee/dtds/application_1_3.dtd">
<application>
<display-name>this is the display name of the application</display-name>
<description>this is a description of the application</description>
<module>
<web>
<web-uri>yourwarfile.war</web-uri>
<context-root>/</context-root>
</web>
</module>
</application>
Your provider application is now deployed to your OracleAS instance. You should see the newly deployed application in the list of applications for the OC4J instance you selected. Please proceed to Testing the Deployment
Warning: Before using dcmctl to manage an OracleAS instance, make sure there are no OEM processes managing that same instance. If multiple processes are managing the same instance, there is a risk of inconsistencies or corruption of the data used to manage the instance.
$IAS_HOME/dcm/bin/dcmctl deployApplication -v -a $application_name -co $oc4j_instance -f $ear_file_path
where:Your provider application is now deployed to your OracleAS instance. Please proceed to Testing the Deployment
where:
Note: the -Xmx256m option specifies a 'maximum heap size' of 256 Megabytes for the OC4J process, which is the recommended setting. However, you may raise or lower this setting to suit your application. If you encounter java.lang.OutOfMemoryError exceptions, you should raise this setting.
java -jar admin.jar ormi://localhost admin $admin_password -deploy -deploymentName $application_name -file $ear_file_path
where:
java -jar admin.jar ormi://localhost admin $admin_password -bindWebApp $application_name $web_app_name file:$oc4j_home/j2ee/home/config/http-web-site.xml $context_root
where:
Your provider application is now deployed. Please proceed to Testing the Deployment
Access the provider test page using the following URL:
http://$host:$port$context_root/providers
where:
An example URL is
http://my.host.com:7777/newProvider/providers
Verify that the provider has been deployed and is accessible. You should see the familiar test page for your default provider (assuming your .properties file specifies showTestPage=true). To view the test page for specific provider service, append the service name to the above URL. For example:
http://my.host.com:7777/newProvider/providers/myService
In the PDK-Java there are a number of deployment properties that are specified as JNDI variables. You may wish to alter the values of these properties for your particular deployment. The level of logging to be used is one such variable and is global to all providers in the PDK-Java war file. Other variables are defined (see list below) but are provider-specific, therefore each provider will have its own variable for each of the properties declared as JNDI variables.
These properties can be used to control each deployed provider service individually, and hence require you to specify a $service_name in the corresponding JNDI path. If you want to set one of these properties for all services at once, you can use the special keyword global as the $service_name.
Note: For more information about HMAC authentication, see the article "Securing Your Web Provider".
This method should be used wherever OEM is not available. Changes to JNDI variable values at deployment should be declared in the PDK-Java's orion-web.xml file. This file can be found in the following location:
For a full OracleAS install:
$ias_home\j2ee\$oc4j_instance\application-deployments\$application_name\$web_app_name
For a standalone OC4J install:
$oc4j_home\j2ee\home\application-deployments\$application_name\$web_app_name
If the file does not exist then you should create it.
For each deployment property that you want to set a value for, add the following:
<env-entry-mapping name="$jndi_variable_name">$deployment-value</env-entry-mapping>
For example, your orion-web.xml might look like this:
<?xml version = '1.0'?>
<!DOCTYPE orion-web-app PUBLIC "-//Evermind//DTD Orion Web Application
2.3//EN" "http://xmlns.oracle.com/ias/dtds/orion-web.dtd">
<orion-web-app deployment-version="9.0.4.0.0"
jsp-cache-directory="./persistence" temporary-directory="./temp"
servlet-webdir="/servlet/">
<env-entry-mapping name="oracle/portal/sample/rootDirectory">D:\prefs</env-entry-mapping>
<env-entry-mapping name="oracle/portal/sample/definition">D:\definitions\def.xml</env-entry-mapping>
</orion-web-app>
When using the PDK-Java framework in a production environment, it is recommended to secure access to your Provider machine or more specifically, your Provider. There are a number of different ways you can secure a Web Provider. For more information please review An Overview of Portlet Security
As mentioned earlier in this document, web providers now have service names or identifiers as well as a URL. The URL represents the location of the adapter servlet and the service name identifies a provider deployed on that adapter. Since service names did not exist in release 3.0.9 of OracleAS Portal, the registration process is slightly different.
When registering your web provider on OracleAS Portal, the registration wizard now includes fields for both the provider URL and service name. The URL is the URL of the adapter servlet and the service name is the name of the provider service you want to register. You should specify both the URL and the service name. If you omit the service name, you will, in effect, be registering the default provider. You are encouraged to always use the service name so you are sure which provider you are registering.
When registering on OracleAS Portal 3.0.9, the service name is specified by appending it to the adapter URL
For example:
service name: myService
servlet URL: http://my.host.com:7777/newProvider/providers
registration URL: http://my.host.com:7777/newProvider/providers/myService
If you omit the service name from the registration URL then any requests will be forwarded to the provider specified in _default.properties (see Specifying Your Default Service). This feature is provided so you can upgrade existing providers to the new version of PDK-Java and deploy them using the original URL, without impacting any portals that were using the provider.
| Revision History: |
|
| Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065, USA http://www.oracle.com/ |
Worldwide Inquiries: 1-800-ORACLE1 Fax 650.506.7200 |
Copyright and Corporate Info |