The following procedure is the basic operation process using the
BTT Rich Client Channel:
- An operation requester requests to execute a client operation.
The requester can be a service, an operation step, another operation.
- The toolkit initializes the client operation. The toolkit also
initializes the operation's context and chains it to the operation context's
parent in the context hierarchy.
- The client operation performs its operation flow (operation steps). These
steps may validate the input data, execute a local service, send a
request to a remote server, or update the context with data to be
handled by the operation requester. The client operation unformats
the data resulting from executing the service and places the unformatted
data in the operation context.
- The client operation validates the data in the operation context
to ensure that it has the data it needs. This validation is a cross-field
validation.
- The client operation requests to execute the server operation
and then waits for the server operation to complete its flow. The
client operation definition identifies the server operation.
- The toolkit sends the request to the server.
- The toolkit initializes the server operation and the server operation's
context.
- The toolkit chains the server operation's context to another context
in the hierarchy. The client operation may identify the parent (using
the serverOperationParentContext attribute), or the toolkit may use
the default context for the client/server session as the parent.
- The client operation transfers the data in the client context
hierarchy to the server context hierarchy using the csRequestFormat.
- The server operation performs its operation flow.
- The toolkit formats the result of executing the server operation
flow using the csRequestFormat.
- The server operation transfers the data in the operation context
hierarchy to the client context hierarchy using the csRequestFormat. If
an error occurs while the server is sending the reply message to the
client, the toolkit throws a DSEReplyErrorException that
contains a CSS09 error code and also fires a CSReplyErrorEvent. The
server operation (provided it is a listener of this event) can perform
some sort of action such as resend the reply message or log the event.
- The client operation extracts the server operation's response
data from the context. The client operation can then use this data
in other tasks such as displaying the server operation's response
in an operation view.
When a requester on the client machine launches an operation, the
operation is expected to perform all necessary tasks before returning
to the originating requestor. The operation will usually use the data
located in its own context hierarchy to perform the required tasks. One
common task to be done at the beginning of the execution is to cross-validate
a business process to ensure that the set of data provided to the
operation is accepted by any constraining business rules. Once the
operation has been performed, which may entail a traversal of all
architectural tiers, the resulting data is available in the context
so the client operation can perform additional tasks, such as displaying
the reply in the operation view. All the tasks to be done on the server
must be performed by a remote ServerOperation, the server-side counterpart
to a ClientOperation. Therefore, the ClientOperation must know which
ServerOperation must be launched on the server when it sends a request
with the Rich Client Channel.
Another crucial set of data for the ClientOperation is the collection
of data elements, which must be transferred from the context hierarchy
on a client workstation to the context hierarchy on the server. This
data collection is specified through a format (csRequestFormat) in
the XML formats file. When the ServerOperation is instantiated on
the server by the Rich Client Channel, the instance needs to know
the context to which it will chain the created operation context.
This context name (serverOperationParentContext) is part of the client
operation definition. A default behavior is implemented by the system,
so that in case this parameter is not set in the ClientOperation,
the ServerOperation is chained to the current context, a default context
that is available for each client/server session.
Once the Rich Client Channel has chained the ServerOperation to
an existing context, the execute() method of the
operation is invoked and the Rich Client Channel blocks and waits
until the operation ends its whole flow. The Rich Client Channel then needs to
determine the data elements in the operation context to return to
the client. It therefore gets the format for the response data from
the ServerOperation. This format (csReplyFormat) must be known by
the ServerOperation. Once the Rich Client Channel has obtained the
data stream to be sent back to the client side, it asks the ServerOperation
to perform whatever housekeeping processes it may need. In this process,
the ServerOperation is responsible for unchaining its operation context
from the context hierarchy and destroying itself, or keeping the operation
context for possible reuse in subsequent processes.
In summary, the following parameters must be known by the business
operation in its client and server components:
ClientOperation:
- validation class to perform the cross-validation process for the
business operation
- context on the client side
- server operation name
- server operation parent context name
- client/server request format
ServerOperation:
- validation class to perform the cross-validation process for the
business operation
- context on the server side
- client/server reply format
The relationship between an operation and the Client/Server Mechanism
service is simple. The operation accesses the service through its
context. Then, a simple code line such as the following:
((CSClientService) getService("CSClient")).sendAndWait(this,10000);
sends the request to the server and waits 10 seconds for the response.
Some exceptions (for instance, when the timeout expires) have to be handled, but the direct call to perform an action on the
server is easy.
The following are the stages of the operation flow and the use
of the data formats:
1. The client operation invokes the remote server operation using CSClient, and sends the
required operation data to the server.
Client operations use
a CSClient instance on the client side to invoke a remote operation, and to indicate the csRequest format
to be used. CSClient is responsible for formatting the data contained
in the operationContext (formattedData) and sending it to the server
side.
2. On the server, CSServer instantiates and runs the operation.
CSServer
on the server side is responsible for receiving the data sent from
the client. It does the following:
- o Instantiates the operation indicated by the serverOperationName received
from the client. This process instantiates all objects defined in
the operation hierarchy.
- o Checks for an operation parent context, and assigns a parent
context if one does not exist. If the context of the server operation
has no parent after instantiation, then the operation has not defined
a parent context. The following sequence of steps is followed as far
as required to assign the parent context:
- Check the parentContext sent from the client. If it has a value
different from null, CSServer instantiates the server operation and
chains it to the parentContext.
- If the parentContext from the client was found to be null, check
for a valid application ID. If a valid application ID exists, CSServer instantiates the
server operation, maps the application ID to the operation, and chains
it to the operation context that corresponds to the application ID.
- If a valid application ID does not exist, CSServer instantiates
the server operation and chains it to the operation context that corresponds
to the session ID.
- Instantiates the specified csRequestFormat and
uses it to unformat the formattedData sent from
the client.
- Runs the server operation, passing the sessionId as
information.
- Creates a unique ID for support of application sessions. This is the responsibility of the application.
3. CSServer sends the resulting operation data to CSClient
on the client side. Once the server operation is finished, CSServer performs the following
steps:
- Formats the updated operation context using csReplyFormat. This produces the formattedResultData.
- Prepares the data to be sent to the client
- 4. CSClient receives the operation data on the client side and
updates the client operation. On the client side, the data is received
and CSClient performs the following steps:
- Instantiates the specified csReplyFormat.
- Unformats the formattedResultData. This updates the context of the client operation.
- Updates the client operation with the applicationId.