JSR-043: JTAPI-1.4

javax.telephony.media
Interface RunnableMediaService

All Superinterfaces:
java.lang.Runnable

public interface RunnableMediaService
extends java.lang.Runnable

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:

Application classes can declare that they follow these conventions by implementing the RunnableMediaService interface.

Usage scenario:

Based on the call-type or other information, the framework assigns a (possibly unique) serviceName for the Call, and identifies the application class to provide that service for the Call. Because the application promises to be a RunnableMediaService, the framework can tell the application which 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.

Since:
JTAPI-1.3

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

setServiceName

public void setServiceName(java.lang.String serviceName)
Tell the RunnableMediaService application which serviceName it should use. A dynamic instantiation framework can use this to identify specific application instances.

A RunnableMediaService promises to:

 	bindToServiceName(ConfigSpec, serviceName);
 

Parameters:
serviceName - the String to be used in this application's subsequent bindToServiceName()
See Also:
bindToServiceName

JSR-043: JTAPI-1.4

Send comments to: JSR-43@ectf.org