Frequently Asked Questions
Contents:
- What is an Asynchronous Process?
- What is an Asynchronous Thread?
- What is a backend service?
- When would I use it?
- Why limit the number of threads in a Queue?
- How can my component application execute inside a thread?
- How can we control which applications run on each machine?
- RMI is too slow. How can we speed this up?
- Does Tymeac support call-back?
- Is Tymeac activatable?
- Does Tymeac support IIOP?
- Does Tymeac support Jini™
- Does Tymeac support delayed processing?
- I can do this myself. Why should I get this product?
Q. What is an Asynchronous Process?
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 threads to process the queues and the thread 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.
Q. What is an Asynchronous Thread?
Tymeac is an asynchronous process / thread manager.
Synchronous threads are the threads you control yourself.
A simple thread class: ... MyThread extends Thread ...
Instantiated: new MyThread().start();
That is as easy as it is to multi-thread in Java™. What is not so easy is synchronizing the threads, timing the threads, recovering from thread errors, etc.
Tymeac solves these problems with asynchronous threads.
Asynchronous threads are the threads Tymeac controls on a Backend Server. (These are similar to Daemons or any thread that runs in the background.) Tymeac relieves you of the burden of managing threads.
You set up a Tymeac Queue for each component application specifying the maximum number of threads.
- Tymeac balances work among those threads so that they use the minimum amount of resources.
- Tymeac handles the recovery from anomalies (a huge burden for applications.)
- Tymeac synchronizes all the threads (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 invokes your user-written application class to execute the application logic.
Most developers see threading as part of the application. That is, where the application class extends java.lang.Thread or implements the java.lang.Runnable interface. Handling the thread logic in addition to the application logic requires two different thought patterns to merge as one. Tymeac separates the thread logic from the application logic so that any application class may easily plug-in to a thread structure.
Q. What is a backend service?
Back-ends are the opposite of front-ends.
Front-ends are 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", (similar to Beans.) This is where Tymeac fits in.
Tymeac may run as either a remote object service, an embedded service or a micro edition embedded service.
As a remote object, the Tymeac Server Class uses java.rmi.server methods. Tymeac runs in a separate Java™ Virtual Machine than your application, (hence the "remote".) Communication from your application to Tymeac is by your application executing a [remote] method on the Tymeac Server.
As an embedded service, Tymeac uses local methods to Queue and Thread your requests.
As a micro edition service, Tymeac uses local methods to Queue and Thread your requests.
Q. When would I use it?
Anytime an asynchronous process and/or threading is desirable. The list is only limited by imagination. [See also the details for segregating an application.]
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 threads within this environment persists as long as a reference to the storage is active. [We demonstrate how to do this in our sample classes.]
As a backend, activatable remote object in a Jini™ Service.
See our example of a Document Service.
For parallel processing:
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:
In the above example, simply tell Tymeac how long to wait for completion of all Queues before purging the 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.
Q. Why limit the number of threads in a Queue?
Resources: Less threads means less memory and less cycles.
Competition: Threads, whether operating system threads or logical threads, compete with each other within a Tymeac Queue, with other threads in Java™, and with other processes in the Box. Sometimes adding more threads 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 threads 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) threads 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 threads for each Queue.
When one hundred (100) applications are active, the maximum number of threads for these processes is twenty (20), not two hundred (200). That means that there are one hundred and eighty (180) LESS threads competing with each other for resources.
When no thread 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 a thread 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 thread?
You have the option of specifying the maximum number of threads for each Queue.
You have the option of specifying when a new thread becomes a participant in processing through new thread thresholds.
You have the option of specifying thread creation time (at Tymeac start up or when first needed) and thread 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.
Q. Ok. Functions contain Queues. Queues have wait lists and threads. How can my application component execute inside a thread?
For the standard edition, reflection is the answer. You set up a base Class with a static main method that accepts an Object array and optionally returns an Object.
public static Object main(Object[] args) ...
Tymeac Queue Threads invoke your main method with Java™ Reflection.
Your base class may extend a Class, implement any interface, and have instances of other Classes. It is just a starting point.
Tymeac provides a new version capability, (the "hot" change.) There is no need to shut down the Tymeac System to change a Tymeac Queue from one base Class to another. For the Enterprise environment, this is mandatory. For testing environments, this saves time.
For the micro edition, an interface is the answer. You set up a base Class that implements the application interface.
public Object doWork(Object in, TymeacInterface Ti)
Tymeac Queue Threads call your doWork method.
Q. If RMI is for remote locations on network servers, then how can we control what application components run on each machine?
The "R" in RMI stands for remote. The definition of remote is any object that is not in the same Java™ Virtual Machine. Tymeac runs as another Virtual Machine on the same Server as your requesting client. Tymeac uses the local host option for all Remote Object functions. Tymeac Server does not communicate with other Tymeac Servers, anywhere.
All requests for loading application classes are for the local system, only. The Method is findSystemClass(). This ensures that no foreign code may infect your system.
Tymeac is secure.
Q. Our requirement is to process a request in no more than two seconds. RMI is too slow. How can we speed this up?
RMI has overhead. The naming lookup itself has overhead. However, it is the thread creation on both the RMI Registry, (or CosNaming server), and the Tymeac Server connection, for each request, that takes the bulk of the time.
The solution is the proverbial Front End, (FE).
Build a process, (FE), that establishes an RMI link to Tymeac and is kept alive by a thread that never ends. The client passes the request to the FE. The FE quickly passes the request to Tymeac and receives the response. This is fast because no thread creation/destroy is necessary.
If the client is not in the same Virtual Machine as the FE, then you can build a native interface between the two.
You can even build a full body FE that handles multiple clients and multiple connections to Tymeac.
Q. Does Tymeac support call-back?
Yes, Tymeac standard edition supports call-back programmatically. That is, Tymeac does not limit call-back to RMI.
Tymeac provides an Asynchronous Request, (schedule the request and do not wait for it to complete). Within the request is how to contact the client when the request completes. Upon request completion, Tymeac schedules an Agent. It is within this Agent that one may put the code to perform a call-back either with RMI or any other method.
See our example of an Asynchronous Request.
Q. Is Tymeac activatable?
Absolutely.
You may run Tymeac standard edition as a non-activatable remote object or as an activatable remote object. We supply the implementation of the Tymeac Interface for both. We also supply detail set-up classes so you may be up and running quickly even if you have never developed activatable remote objects before.
Q. Does Tymeac support IIOP?
Yes. CORBA support is through the Internet Inter-Orb Protocol.
You may use the JNDI Registry to store the remote object for Clients. For pure CORBA Clients, you may use the Java™ IDL to build a front end, convert the IDL to Java with the IDLtoJAVA compiler and then use the standard Remote Method Invocation to communicate with the Tymeac Server.
Q. Does Tymeac support Jini™?
Tymeac is not a Jini™ Service.
Tymeac is an activatable Remote Object.
This means that you may wrap a reference to this activatable Remote Object in a Jini™ proxy and pass the proxy to a Jini™ Lookup Service. Jini™ Clients may retrieve this reference and use Tymeac the same as if the reference came from the Java™ Remote Object Registry.
You may also embed a reference to this activatable Remote Object in your own Jini™ Service, back-end activatable Remote Object. The Jini™ Service, back-end, may use Tymeac the same as if the reference came from the Java™ Remote Object Registry. (Like a back-end to the back-end.) In this way, Jini™ Clients are unaware of Tymeac processing.
You may use the embedded server within your Jini™ Service, back-end activatable Remote Object. In this way, Jini™ Clients are unaware of Tymeac processing.
We supply demonstration source for all these scenarios.
Q. Does Tymeac support delayed processing?
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.
Q. I can do this myself. Why should I get this product?
Tymeac is not rocket science. Tymeac is grunt software.
Any reasonably capable programming team can write software that manages queues and threads. What Tymeac does is:
- Manage the asynchronous-process environment very, very well.
- Provide a generalized management framework for all your asynchronous-process work so that you do not have to write custom code for each application.
- It is written -- saving you months or years of development time.
- The price is right.
