IBM Branch Transformation Toolkit 5.1 Migration and Usage Guidelines

Running H/F 1 307

value="com.ibm.websphere.naming.WsnInitialContextFactory"/>

<field id="PureEJBProxy_jndiName"

value="com/ibm/btt/formatter/server/CHAFormatterServiceServiceHome"/>

<field id="PureEJBProxy_providerURL" value="iiop://localhost:2809/"/>

</kColl>

3. Press Ctrl+S to save it.

8.3.7 Creating a Single Action EJB

This section describes the creation of Single Action EJB as the withdrawal

business operation. In the toolkit’s architecture, the Single Action EJB is a little

different from pure EJB in J2EE. The Single Action EJB’s main function is like an

Decorator or an Adapter. Single Action EJB is used to wrap the operation

provided by the back-end host. It can include journaling or message

transformation services as well. Thus, Single Action EJB

should not handle data

persistence as per the toolkit design. The table and journal services are better

candidates for this purpose.

Client operation, invoker, and server SAE strategy

This section looks at how invokers and server Single Action EJB work with client

operation.

In a client/server environment, a business operation is composed of a flow being

executed in three phases, that is, a client operation, an Invoker, and a Single

Action EJB, as shown in Figure 8-56.

Figure 8-56 Components joined in the client/server communication

The client operation must know the name of the corresponding Invoker. This

should be stored as an attribute of client operation, as shown in Figure 8-57.

Figure 8-57 Client 0peration should know information about the Bean Invoker

Client Operation Bean Invoker Single Action EJB

Client Operation

• Bean Invoker

Bean Invoker Single Action EJB

308 IBM Branch Transformation Toolkit 5.1 Migration and Usage Guidelines

Each operation needs a set of data. Data elements are stored as collections

inside the context hierarchy. By simply passing the operation and the name of a

context, the operation can access the data of the entire context hierarchy. See

Figure 8-58.

Figure 8-58 Client operation and SAE have knowledge of underlying contexts

You should now let both ends communicate with each other. The Branch

Transformation Toolkit provides the Client/Server Communication Service for

this purpose. The Client/Server Communication Service requires two specific

message formats to work correctly. To send a request message from Client

Operation, the csRequestFormat will be used. Likewise, it uses csReplyFormat

to reply back to the client.

Thus, the scenario of the overall operation can be as follows:

Using the Client/Server Communication service, the client will prepare and send

a request message to the server for processing. The server will process the

operation, produce a reply, and send that reply back to the client. See

Figure 8-59.

Figure 8-59 The scenario of client/server communication service

Client Operation

• Bean Invoker

•Context

Bean Invoker

Single Action EJB

•CHA

SystemData

• sessionID

• subSessionId

• InstanceId

Client Operation

• Bean Invoker

• Context

Client/Server

communication

Bean Invoker

Single Action EJB

• CHA

csRequestFormat

csReplyFormat

Running H/F 1 309

The Client/Server Communication service relies on three key configuration files

to work correctly, that is, client operation definition, server operation definition,

and bean invoker registry mapper.

򐂰 Client operation definition

There are two types of clients, a Java client and a Web client. For Java client,

the client operation definition typically resides in dseoper.xml. Use

Example 8-6 to define a client operation.

Example 8-6 Client operation definition for Java client

<ClientOperation id="clientOp" serverOperation="serverOp"

context="clientCtx">

<refFormat name="csRequestFormat" refId="clientRequestFmt"/>

</ClientOperation>

For a Web client, the client operation definition resides in the configuration file

of a Struts Module in bold font, as shown in Example 8-7.

Example 8-7 Client operation definition for Web client

<?xml version="1.0" encoding="ISO-8859-1" ?>

<struts-config>

<data-sources />

<form-beans>

<form-bean name="signInForm"

type="btt.bank.ui.struts.forms.SignInForm"/>

</form-beans>

<global-exceptions />

<global-forwards />

<action-mappings>

<action name="signInForm"

path="/signIn"

className="com.ibm.btt.struts.config.BTTEJBActionMapping"

type="com.ibm.btt.struts.actions.EJBSignInAction"

input="/signin.jsp"

invokerId="signInInvoker"

validator="btt.bank.ui.struts.forms.SignInXVal"

validate="true"

parameter="signIn">

<forward name="success" contextRelative="true"

path="/btt/bank/ui/struts/withdrawal/prepareWithdrawal.do"/>

<forward name="signin" path="/signin.jsp"/>

</action>

</action-mappings>

<flowcontext contextName="signInCtx" local="true" />

<plug-in className="com.ibm.btt.struts.plugins.BTTDefaultNotifier" />

<finals>

<final type="forward"