Why use a manager?

Why are CICS^® applications so successful?  Because they run inside a container; a framework that manages persistence, messaging, task management, logging, the user interface and much more.

A Backend Server doesn't have a similar application container to manage queues and asynchronous tasks.

Developers who construct backend applications know that it is first necessary to build a framework in which the application lives.

[need more details?]

-- Essence --

Asynchronous tasks  |   Parallelism  |   Persistence  |   Recursion  |   Debugging, Recovery, Tuning   |   Overall Picture

  Two common uses for asynchronous tasks on a Backend Server are the timing of requests and the autonomous request.

Timing:

When timing a request, the Client task cannot time itself.  If it gets caught in a long or never ending loop then it may not be able to break out of the code when the time expires. Therefore, it is necessary for the Client task to start a new asynchronous task. The Client task may time the new task and if the time expires the request does not complete.

This seems simple enough. However, there are serious problems with this approach.

For every request there is a new asynchronous task. CICS^® must create and destroy every task. This overhead puts a severe strain on resources. There may come a time when CICS^® cannot sustain any more tasks and the entire address space becomes unusable.

[Some developers may put the timing code in the client. Rather than have a standard timing mechanism on the server, each client application must add proprietary timing code.]

What happens to the tasks that time-out? If there is problem with a resource that the tasks require before completing, then, once again, there may come a time when CICS^® cannot sustain any more tasks and the entire address space becomes unusable.

[Even with the timing code in the client, the Client tasks still hang.]

Autonomous requests:

The only way to schedule this background task is to start a new asynchronous task and inform the client that the request is pending.

Again, this seems simple enough. Again, there are serious problems with this approach.

The task overload problem is the same as with the timed request, above.

The task stall problem, as above, is even more serious. Since there is no time-out, the clients never know there is a problem.

Clients waiting for a notification need a way to inquire of the status of their request.

To handle these problems one must manage the application environment.

• There must be a task-limit parameter to avoid task overload. There should be a queuing mechanism with task initiation according to load, not chance.
• There must be a way to notify clients before the situation gets out of control.
• There must be a way to dynamically alter the parameters as business needs change.

Tymeac^™ is that manager.

  Another use for asynchronous tasks on a Backend Server is parallelism.

Parallelism:

Often a request requires more than a simple compute or fetch from a resource. The request may need several methods. For linear programming, one method simply follows the other. However, by making each method a task, one may take advantage of multi-programming and multi-processing capable machines.

Creating a task for each method in CICS^® is very easy.

However, all the problems with tasks mentioned above are relevant here as well. In addition, the Client task must now monitor multiple asynchronous tasks and concatenate any return values from these tasks for the client.

To handle these problems one must design a full-feature application manager.

Tymeac^™ is that manager.

  The Backend Server environment is persistent. Applications can take advantage of this persistence to store common variables that drive processing

Persistence:

Could you use connection pools for your RDBMS work thereby saving cycles and memory? Could you use common storage to keep track of how many messages are outstanding within a Message Queuing start/stop sequence? Could you use common storage as a work area between tasks?

Managing the common variables including how tasks access and update that storage requires a great deal of time and effort outside the pure application development area.

To handle persistent storage properly one must manage the Backend Server environment.

Tymeac^™ is that manager.

  Recursion is one of the most useful techniques and sometimes the most difficult to implement.

Recursion:

When the current process itself requires another asynchronous process, the effort required in keeping track of allocated storage, time-out, back-out, etc., means that designers usually chose some other, less efficient method.

To handle recursion one must manage the entire application environment.

Tymeac^™ is that manager.

  Debugging, Recovery and Tuning on a Backend Server can be a developer's worst nightmare.

Debugging:

How does one trap the asynchronous task when one doesn't know which task is currently handling this request? There is always trial and error. There is always setting a breakpoint at the beginning of the code and walking all the way through.

Recovery:

Recovery assumes that one is in control of the situation, catches the error, backs-out valuable resources and restores the proper state. Without a proper management facility, the assumption is false.

Tuning:

Tuning starts with designing for tuning. Without tuning as a prime thought in the design phase, there is no tuning in the execution stage. Throwing hardware at the problem, (E.G. adding more memory, more file space, etc.), only works for a while.

To handle these problems requires a total management package.

Tymeac^™ is that manager.

  A picture is worth a thousand words.

Picture:

What is the status of an autonomous request? What requests are stalled? What is the current task load? How many requests are currently backed up? Can we get a "snap shot" of the overall queuing environment usage? Is there a log? Etc.

Building these pictures requires so much effort on the part of the development team that it overshadows the service it is meant to serve.

Tymeac^™ is a manager that provides logging and statistics as well as dozens of Screens to give administrators not only a picture of the environment but the means to alter that environment.