Other names for this are the Background Process, Attendant Process, or Daemon.
The classic example is printing. Rather than tying up
a foreground process with physically printing a document, the foreground process creates a
new background process that handles the logic and I/O for the printer.
It is when the application becomes mission-critical and/or
more complex that designing a full feature asynchronous process becomes a major
undertaking.
- Providing prioritized queues for the requests,
- providing multiple asynchronous tasks to process the queues and the management that goes
with it,
- providing synchronous access (wait until complete) and asynchronous access with
call-back,
- providing automated error recovery,
- providing back-out and restart,
- providing inquiry and modification to the execution environment.
This major design and implementation may cost so much in
time and resources that the team looks for easier alternatives.
It is for these reasons that there is Tymeac™.
Tymeac™ is an asynchronous
process / task manager.
Synchronous tasks are
the Client tasks started by CICS in response to input of some kind.
Asynchronous tasks are
the tasks either the application starts and controls or the tasks Tymeac™
starts and controls on a Backend Server. Tymeac™ relieves
you of the burden of managing asynchronous tasks.
You set up a Tymeac™ Queue
for each component application specifying the maximum number of asynchronous tasks.
- Tymeac™ balances work among those asynchronous tasks so
that they use the minimum amount of resources.
- Tymeac™ handles the recovery from anomalies (a huge
burden for applications.)
- Tymeac™ synchronizes all the asynchronous tasks (another
huge burden for applications.)
- Tymeac™ offers timing of requests (a synchronous request
is when you wait for completion of all Tymeac™ Queues.)
- Tymeac™ offers background processing (an asynchronous
request is when you schedule a request and do not wait for it to complete.)
- Tymeac™ links to your user-written application program to
execute the application logic.
Back-ends are the opposite of front-ends.
Front-ends are green screen, GUI services or any
application that one considers a client.
Back-ends are generally hidden from the user of the
application. These are any applications that one considers a server. In
addition, the server itself may require "services." This is where Tymeac™
fits in.
Anytime an asynchronous tasking is desirable. The list is only limited by
imagination.
See also Real World Examples
To make use of persistent storage on a Backend Server.
Tymeac™ is a Backend Server
environment. Once Tymeac™ starts, the storage acquired by
asynchronous tasks within this environment persists.
For parallel processing:
For example:
A process requires access to two databases, (customer and pricing).
Set up a Tymeac™ Queue for each database
access. Set up a Tymeac™ Function that uses these two
Queues. [This is as easy as filling in the blanks.] When the client application uses
this Tymeac™ Function, both Queues are active
simultaneously.
To time a request:
To run an autonomous request with call-back:
In the above example, tell Tymeac™ not to wait for
completion. The client is free to perform other work. When the last Queue finishes, it may
optionally schedule an Output Agent. The Agent may take the responses from the Queues
and send them anywhere.
To separate components:
See the key benefit, Gateway.
In the above example, the application requires two database accesses. Each of these may
be for a different vendor's database or even legacy applications. Incompatibilities
between products and/or applications is irrelevant. Tymeac™
segregates logical units of work.
To separate client from server:
One of the essentials of Tymeac™ is the ability to
separate the Web-based interface from the rest of the company.
In the above example, this 'process' may be the back-end for an Internet/Intranet
front-end. You can put security, or anything else, in each component without ever touching
the front-end.
To isolate failures:
See the key benefit, Containment.
In the above example, if one database access 'hangs' or abnormally terminates, recovery
is easier. There is no need to handle every possibility in relation to every other
possibility. Tymeac™ isolates components.
Resources: Less asynchronous tasks means less
memory and less cycles.
Competition: Asynchronous tasks compete with each other within a Tymeac™
Queue, with other task in CICS®, and with other processes in the
Box. Sometimes adding more tasks slows down overall processing because of resource
limits, (memory, cycle, network, locks, blocking, etc.)
Let's say you have an application that uses two (2) additional asynchronous tasks such
as the prior example.
In an n-tier application server you may have one hundred (100) of these applications
active at one time. That means that there are two hundred (200) tasks for these
applications competing with each other for resources.
Now the same application with Tymeac™.
You set up a Tymeac™ Queue for each database access
component. For this example we set ten (10) as the maximum number of asynchronous
tasks for each Queue.
When one hundred (100) applications are active, the maximum number of
asynchronous tasks for these processes is twenty (20), not two hundred (200). That means
that there are one hundred and eighty (180) LESS asynchronous tasks competing with each
other for resources.
When no asynchronous task is immediately available to process a request, Tymeac™
places the request in a prioritized wait list (your request designates the
priority). This assures that the "hot" request processes first. When
an asynchronous task finishes a request, it looks in the wait lists for more work.
Of course this means that requests "stack up". This is the balance: How many requests may stack up before it
is better to have another asynchronous task?
You have the option of specifying the maximum number of asynchronous tasks for
each Queue.
You have the option of specifying when a new asynchronous tasks becomes a
participant in processing through new task thresholds.
You have the option of specifying task creation time (at Tymeac™
start up or when first needed) and task destruction (after an idle period or never.)
You have the option of timing requests.
You have the option of prioritizing requests.
You are in control, not chance.
Tymeac™ keeps detailed information about each Queue and
Function. Tymeac™ provides tools to monitor, alter, and log
these statistics dynamically and statically.
No, Tymeac™ is a process now
system. Delaying the processing is outside the scope of an asynchronous process
manager.
However, there are numerous middleware, message-queuing systems on the market. The
scope of these systems is that one sends a message, (this could be the parameters for
Tymeac™), to a Queue with instructions to deliver the
message to another Queue at a later time.
