|
JSR-043: JTAPI-1.4 | ||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
SUMMARY: INNER | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
Interface for application classes that can be instantiated "on-demand" by a call management framework.
Some large server installations use statistical overloading techniques; installing and enabling access to many applications with the constaint that they cannot and will not all run simultaneously. Such installations cannot in general allocate a thread for every potential call-service.
Therefore, applications in these installations should not take the
initiative to instantiate a MediaService object and should not
invoke bindToServiceName
until the framework needs their service.
Frameworks that use this technique typically perform call-type or service-request discrimination, instantiate the implementation object for the requested service, and then create a thread to run that service for this call.
Applications can prepare for such environments by following these conventions:
serviceName
to use.
The following code sample demonstrates how the framework can
instantitate and run the application class:
// when framework wants appClassName to handle a Call // and that Call will be given to this serviceName runService(String appClassName, String serviceName) { RunnableMediaService rms; Class appClass = classForName(appClassName); // the application Class rms = (RunnableMediaService)(appClass.newInstance()); rms.setServiceName(serviceName); // serviceName determined by framework Thread thr = new Thread(rms).start(); }
The application must create a MediaService object (within the
appClass constructor or the run method), and must eventually
respond to the start/run method with:
bindToServiceName(initialConfigSpec, serviceName);The framework can rely on the specific
serviceName
to recognize
that the bind request is from the appClass
application.
Thereafter, the focus is on the MediaService, and in normal usage,
the framework does not directly manipulate the Runnable nor the Thread.
The well behaved RunnableMediaService should process the call, including release() and any cleanup or record keeping, and then return from run(). The whole purpose of this scheme is to limit/control the existance of outstanding threads; applications that subvert the framework by holding the thread or other resources beyond the expected lifetime for processing a call are considered non-conformant to this interface.
Method Summary | |
void |
setServiceName(java.lang.String serviceName)
Tell the RunnableMediaService application which serviceName it should use. |
Methods inherited from interface java.lang.Runnable |
run |
Method Detail |
public void setServiceName(java.lang.String serviceName)
serviceName
it should use.
A dynamic instantiation framework can use this to
identify specific application instances.
A RunnableMediaService promises to:
bindToServiceName(ConfigSpec, serviceName);
serviceName
- the String to be used
in this application's subsequent bindToServiceName()bindToServiceName
|
JSR-043: JTAPI-1.4 | ||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
SUMMARY: INNER | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |