Additional SOA Patterns –Supporting Composition Controllers - Applied SOA Patterns on the Oracle Platform - page 587

Pattern Problem Implementation

a single parameter: ExecutionEnvironment . This is where the context is
encapsulated, and Context Manager is responsible for maintaining it.

To be distributable and replicable within the data grid, context and command
objects must be serializable

mand in the context of the object's data. Com-
mand must clearly provide a method for execut-
ing the task.

( ExternalizableLite or PortableObject would be even better).

This pattern does not always return a value back to the task submitter (client).
If a return value is expected, the Functor pattern must be allied. This pattern is
an extension of Command and should be omitted for brevity.

The previous pattern (Command) is responsible
for creating an executable object based on the
data object's context (as depicted in the 3D com-
posite event matrix's figure, for instance), but this
is just a prerequisite (although critical) for distrib-
uted computing. We must make sure that the cli-
ent will see the fabric as one big computer with a
unified way to submit, start, pause, and resume
the predefined task with the associated data ob-
ject. This processing framework must seamlessly
support not only computers assembled into the
Coherence grid, but also the ones that are plugged
using Coherence Extend (TCP or JMS connectors
to remote systems).

Coherence as a virtually unlimited distributed network of data storage buckets
and associated data processing nodes represents the possibility of asynchron-
ously processing (almost) everything that is called or run by Java. This pattern
allows the client to use the fire-and-forget submission model for the pre-
defined object (with the data structure declared in the key-value form and
standard executable method). This pattern is capable of reporting back to the
sender about the task submission's outcome to keep the submitter informed
about the progress of the execution. Based on the status (or even without it),
the submitter has the ability of canceling the processing if submission doesn't
reach the final stage of processing. Due to the asynchronous nature of the exe-
cution, the client has the ability to disconnect from the processing grid and
connect later to collect the results or even delegate it to another client. The
last option is possible because the client will decide on the ID that is associ-
ated with submission.

Processing
pattern

There are more patterns in the incubator ( https://java.net/projects/cohinc/ ), including Co-
herence Commons (similar to Apache Commons) that holds lots of useful utilities.
However, of all the patterns, the Processing pattern is arguably of paramount importance
and is available for implementation on Coherence. This pattern is so full of functionalities
and covers so many requirements that sometimes it is very rightfully called a framework.
This pattern will require the following components:

• Submission dispatchers, polling the individual submission from local submission
caches and registering them on Dispatch Controller, which in turn passes this re-
gistration to logging.
• A registered and logged task passed to the task dispatcher. The client is notified
about the submission's outcome.
• The task dispatcher dispatches the task (executable submissions with the imple-
mentation of the Task interface) to the Task processor. Here, we can have differ-
ent variations of the tasks. If a submission contains Java runnables and callables,
it will be executed locally by LocalDispatcher , but this is not desirable due
to limited distribution capabilities. The task can also be resumable, which means
that it can be suspended during the execution.