Note: if you are deploying to a cluster, you must either manually create the JMS queues on each managed server (as described below) or you can use the auto-configure feature with the domain Configuration Wizard. You can access the domain configuration wizard from Start-->BEA WebLogic Platform 8.1-->Configuration Wizard. Within the Configuration Wizard, specify a JMS server and the set of JMS queues before you create a cluster. The configuration wizard will automatically configure the distributed queues along with the corresponding physical queues for each managed server. Note that creating a cluster in the configuration wizard triggers this auto configuration process.
For each pair of <con:async-request-queue> and <con:async-request-error-queue> elements in the wlw-manifest.xml file you will need to create a pair of corresponding JMS queues on the production server. Make sure that the ErrorDestination attribute on each of the <con:async-request-queue> queues refers to the corresponding <con:async-request-error-queue> queue. (Note, you need to create these JMS queues only if the application contains buffered methods. If the application contains no buffered methods, the JMS queues do not need to be created, even if the JMS queues are listed in wlw-manifest.xml.)
The following procedure explains how to manually create a JMS queue using the WebLogic Server console.
(1) Using the WebLogic Server console, you can create these queues by the following procedure.
(2) On the left-hand side navigation pane, navigate to the Services-->JMS-->Servers-->[your JMS server]-->Destinations node.
(3) Right-click the Destinations node and select Configure a new JMSQueue.
(4) On the right-hand side content pane, enter the JNDI Name provided in the <con:async-request-queue> or <con:async-request-error-queue> element .
(5) Click Create.
(6) Error queues should have a Redelivery Limit set to zero.
If you have just created an error queue then complete this instruction, otherwise
skip this instruction. On the right-hand side content pane, click the Redelivery
tab. In the Redelivery Limit field, enter the integer 0.
Click Apply.
Associate Queue and Error Queue Pairs
The following procedure explains how to set the ErrorDestination attribute. You must create a queue pair before you can complete this procedure.(1) On the left-hand side navigation pane, navigate to a JMS queue entered for a <con:async-request-queue>: Services-->JMS-->Servers-->[your JMS server]-->Destinations-->[individual queue].
(2) Click the Redelivery tab for the individual queue.
(3) Use the Error Destination drop-down list to select the corresponding error delivery queue.
(4) Click Apply.
Conversational state
database tables
If the application contains Web Service or Timer controls, then you must
create database tables to store the conversational state. If the application
does not contain Web Service or Timer controls, these table do not need
to be created.
For each <con:conversation-state-table> element in the wlw-mainfest.xml
file, you will need to create a corresponding table on the production server.
The following SQL scripts can be used in the to create the necessary tables,
depending on whether the server is running against a MS SQL Server, Oracle,
Pointbase, DB2, or Sybase database. Substitute <TableName> with the
name of the table appearing in the <con:conversation-state-table>
element.
MS SQL Server
CREATE TABLE <TableName>(
CG_ID varchar(768) NOT NULL PRIMARY KEY,
LAST_ACCESS_TIME bigint,
CG_DATA IMAGE
)
Oracle
CREATE TABLE <TableName>(
CG_ID varchar(768) not null,
LAST_ACCESS_TIME number(19,0),
CG_DATA BLOB,
PRIMARY KEY (CG_ID)
)
Pointbase
CREATE TABLE <TableName>(
CG_ID varchar(768) not null,
LAST_ACCESS_TIME bigint,
CG_DATA BLOB(4M),
CONSTRAINT PK_<TableName>_ID PRIMARY KEY (CG_ID)
)
DB2
CREATE TABLE <TableName>(
CG_ID varchar(768) not null,
LAST_ACCESS_TIME bigint,
CG_DATA BLOB,
PRIMARY KEY (CG_ID)
)
Sybase
CREATE TABLE <TableName>(
CG_ID varchar(768) not null,
LAST_ACCESS_TIME int,
CG_DATA IMAGE,
CONSTRAINT PK_<TableName>_ID PRIMARY KEY (CG_ID)
)
NonStop SQL/MX Release 2.0
CREATE TABLE tablename (
CG_ID VARCHAR(107) NOT NULL,
LAST_ACCESS_TIME LARGEINT,
CG_DATA BLOB,
PRIMARY KEY (CG_ID)
)
Note: The size of the CG_ID column defaults to 768, as shown above in most cases. This size can be set in the jws-config.properties file, located in the domain root directory. In that file, see the property weblogic.jws.ConversationMaxKeyLength.
A single conversational database table may be shared by multiple applications and servers because values for CG_ID will be globally unique. System-generated values for CG_ID (also known as "conversation IDs") will be unique; values supplied by application code must also be unique, or there may be unexpected results.
Optionally, you many want to configure WebLogic Server to enforce the role restrictions placed on controls that can receive external callbacks. Your application will run without these role restrictions, but it will not behave exactly as the developer intended it in terms of the role restrictions placed on a control's callback methods.
Any control that can receive external callbacks is identified in the wlw-manifest.xml file with a <con:external-callbacks/> tag. For example the following <con:external-callbacks/> tag tells you that the the control async.HelloWorldAsyncControl, can receive external callbacks. The <con:security-roles> tag tells you that this control has a role restriction placed on it: only Managers are authorized to access this control. If such a control receives callbacks from an untrusted external location, you may want to enforce these role restrictions on the deployed application.
<con:top-level-component class-name="async.HelloWorldAsyncControl" component-type="Control">
<con:external-callbacks/>
<con:security-roles>
<con:role-name>Managers</con:role-name>
</con:security-roles>
</con:top-level-component>
In the compilation process each web service becomes a top-level EJB, and
each control on a web service becomes a single method on the corresponding
top-level EJB. In example, the control HelloWorldAsyncControl is used by
the web service Conversation, as can be seen by the following entry from
wlw-manifest.xml. Note that "helloAsync" refers to the control
HelloWorldAsyncControl, because HelloWorldAsyncControl is declared
on the Conversation web service with the name "helloAsync".
<con:top-level-component class-name="async.Conversation" component-type="JWS">
<con:conversation-state-table table-name="JWS_ERVICES_ASYNC_CONVERSATION"/>
<con:external-callbacks>
<con:control control-path="helloAsync$callback"/>
</con:external-callbacks>
<con:security-roles>
<con:role-name>Managers</con:role-name>
</con:security-roles>
</con:top-level-component>
The following procedure how to use the WebLogic Server console to associate
role restrictions with the methods compiled from controls that can receive
external callbacks.(1) Right-click the relevant top-level EJB and select Define Policies and Roles for individual beans. In the example above, the top-level EJB is "Conversation"
(2) Under Session, click Define Security Policies.
(3) Under Methods, select the method that requires a role restriction. In our example, the "helloAsync$callback" method.
(4) Under Policy Condition select Caller is granted the role, and click Add.
(5) Finally, complete the wizard for placing the security role restriction on the method.