Administración de recursos escasos en una aplicación MHP
Amaia Goñi
Silvia Larrayoz
10/04/2005 .2E.T.S de Ingenieros de Telecomunicación
Administración de recursos
La administración efectiva de los recursos escasos es muy importante:
De lo contrario no sería posible que:El máximo de aplicaciones se estuviesen
ejecutando al mismo tiempo.Las aplicaciones pudiesen utilizar todas sus
funcionalidades.
10/04/2005 .3E.T.S de Ingenieros de Telecomunicación
Administración de recursos
No es un nuevo problema.La solución que utiliza MHP está definida
en el proceso de estandarización DAVIC.Muchas de las APIs están basadas en la
API de Notificación de Recursos.Contenida en org.davic.resources
package.Informa a la aplicación de cuando otra
aplicación necesita el recurso o cuando el receptor ha revocado el acceso al recurso.
10/04/2005 .4E.T.S de Ingenieros de Telecomunicación
API de Notificación de recursos
Consiste en tres clases principales y no es en sí una completa API sino que otras APIs hacen uso de ella.MHP sigue el modelo exactamente en
muchos casos.OCAP realiza varios cambios.
10/04/2005 .5E.T.S de Ingenieros de Telecomunicación
Introduciendo la API de notificación de recursos
Basado en el modelo de cliente-servidor.DAVIC introduce varios cambios para
asegurar:Seguridad.Elasticidad para tratar las aplicaciones
maliciosas.La API en sí ,consiste en tres elementos
principales:
10/04/2005 .6E.T.S de Ingenieros de Telecomunicación
Introduciendo la API de notificación de recursos
Resource server: Parte de la API que procesa la petición de los recursos.
Resource client: Parte de la aplicación que actualmente utiliza el recurso.
Resource Proxy: Objeto intermedio que provee servicio del recurso y hace cumplir la política de seguridad.
10/04/2005 .7E.T.S de Ingenieros de Telecomunicación
ResourceStatusListenerstatusChanged(ResourceStatusEvent)
ResourceStatusEvent
recibe
ResourceServeraddResourceStatusEventListener()
removeResourceStatusEventListener()
ResourceClientrequestRelease(ResourceProxy)
release(ResourceProxy)
notifyRelease(ResourceProxy)
ResourceProxygetClient()
escuchaEl application manager, llamando a estos métodos, notifica a la aplicación que el recurso al que hace referencia el ResourceProxy necesita ser liberado
Cada API luego añade métodos específicos para el control del recurso
Diagrama de clases
10/04/2005 .8E.T.S de Ingenieros de Telecomunicación
ResourceServer
La clase que implementa el resource server está basada en la interface ResourceServer.
Public interface ResourceServer{
public abstract void addResourceStatusEventListener(ResourceStatusListener listener);
public abstract void removeResourceStatusEventListener(ResourceStatusListener listener);
}
Los métodos que define esta interface permiten a la aplicación registrarse como un listener para los eventos, indicando el cambio del estado del recurso.
La API que hace uso de esta interface proporciona eventos para observar como recursos específicos cambian su estado.
10/04/2005 .9E.T.S de Ingenieros de Telecomunicación
ResourceClient
La clase que implementa el ResourceClient está basada en la interface ResourceClient.
Public interface ResourceClient{
public abstract boolean requestRelease(ResorceProxy proxy,Object requestData);
public abstract void release(ResourceProxy proxy);
public abstract void notifyReleased( ResourceProxy proxy);
}
El receptor middleware hace uso de esta interface para notificar a la aplicación que alguien más necesita el recurso en el receptor.
La interface Resource Client contiene tres métodos:
10/04/2005 .10E.T.S de Ingenieros de Telecomunicación
RequestRelease
requestRelease() es el más educado de los tres métodos.
- Pide a la aplicación que renuncie al recurso de forma que pueda ser usado por alguien más en el receptor.
-Si este método devuelve el valor:
-false: el cliente todavía quiere el recurso
-true: no necesita más el recurso
10/04/2005 .11E.T.S de Ingenieros de Telecomunicación
Release
Release(): es el siguiente nivel en descortesía y ordena a la aplicación que debe dejar el recurso escaso.
El cliente no tiene elección.Cuando el método retorna, el receptor asume
que el recurso está disponible.Se asume que el cliente cooperará.Si no es así y tras un tiempo (periodo
timeout) no obtiene respuesta, el middleware asume que la aplicación ha caído o es maliciosa.
10/04/2005 .12E.T.S de Ingenieros de Telecomunicación
NotifyReleased
Si la aplicación ha caído o es maliciosa:El receptor llama al método
notifyReleased(), el cual informa al cliente de que debe “limpiar” todo, ya que el recurso ya no está a su alcance.
Se trata de una brutal operación por parte del cliente por lo que únicamente es utilizada cuando éste no coopera.
Si no se obtiene respuesta se elimina la aplicación.
10/04/2005 .13E.T.S de Ingenieros de Telecomunicación
ResourceProxy
La clase que implementa esta interface se sitúa entre el cliente y el recurso actual.
Función principal : seguridad Impidiendo que aplicaciones no fiables accedan al
recurso.
Resto de funcionalidades:Proveer a la aplicación un camino sencillo hasta el
recurso.• En caso de que el recurso sea complejo se establecerán
los parámetros en el proxy en vez de cargarlos en cada acceso, ganando tiempo y reduciendo errores.
10/04/2005 .14E.T.S de Ingenieros de Telecomunicación
ResourceProxy
Resto de funcionalidades:Como las instancias las crea el cliente es posible que
la fuente cree diferentes ResourceProxy-s con diferentes parámetros y elegir en cada caso el que más convenga.
El enlace entre el cliente y el recurso es un camino indirecto utilizando como intermediario el ResourceProxy.
• Ampliando la seguridad.• Facilitando el manejo adecuado de las aplicaciones
“maliciosas”.
10/04/2005 .15E.T.S de Ingenieros de Telecomunicación
Acceso a un recurso
Resource client Resource proxy
Resource server
Crea instancia
Petición de acceso al recurso
Acceso al recursoValidación del Proxy
10/04/2005 .16E.T.S de Ingenieros de Telecomunicación
Acceso a un recurso
1) La aplicación crea una instancia al ResourceProxy adecuado y le pasa los parámetros adecuados.
2) ResourceClient llama al método adecuado del ResourceServer y pide el acceso al recurso pasándole como parámetro el objeto ResourceProxy.
3) El ResourceServer llama a un método privado del ResourceProxy para validar al Proxy.
4) Se establece el enlace entre el recurso y el Proxy. 5) La aplicación para hacer uso del recurso llama a
métodos del ResourceProxy. 6) La aplicación nunca tendrá acceso directo al recurso.
10/04/2005 .17E.T.S de Ingenieros de Telecomunicación
Liberación de un recurso
Resource client Resource proxy
Resource server
Recurso en uso
Invalidación del Proxy
Petición finalizacióndel uso del recurso
Pérdida acceso recurso
10/04/2005 .18E.T.S de Ingenieros de Telecomunicación
Liberación de un recurso
1) ResourceClient llama al método adecuado del ResourceServer para abandonar el recurso, pasando el ResourceProxy como parámetro.
2) ResourceServer invalida el recurso llamando a un método privado del ResourceProxy que puede o no ser el anteriormente usado para validarlo.
3) El ResourceProxy destruye cualquier referencia al recurso, ya que el ResourceServer le ha avisado que no será válido en poco tiempo.
4) El ResourceServer actualiza su tabla interna de estados de los recursos y marca el recurso como libre.
10/04/2005 .19E.T.S de Ingenieros de Telecomunicación
Pérdida de un recurso
Resource client Resource proxy
Resource server
Recurso en uso
Invalidación del Proxy
Liberar recursoPérdida acceso recurso
La aplicación se niega a liberarel recurso
10/04/2005 .20E.T.S de Ingenieros de Telecomunicación
Pérdida de un recurso
1) El ResourceServer llama al método release() del ResourceClient.
2) El ResourceClient no responde a esta llamada. 3) Tras un periodo de timeout el middleware notifica
al ResourceServer que la llamada no ha sido contestada.
4) El ResourceServer llama a un método del ResourceProxy y le notifica que el enlace dejará de ser válido.
5) El ResourceProxy rompe el enlace. 6) El receptor llama al método NotifyReleased(), para
informar a la aplicación de que en breve no va a tener acceso al recurso.
7) La aplicación pierde el acceso al recurso.
10/04/2005 .21E.T.S de Ingenieros de Telecomunicación
Disputa por la manipulación de recursos
Cuando varias aplicaciones quieren acceder al mismo recurso se siguen unas normas para resolver la situación:1. Permiso: Si una aplicación no tiene permiso para
acceder al recurso, aunque éste esté libre, no puede acceder a él (mayor seguridad).
2. Petición de otras aplicaciones: Se invita a las aplicaciones a abandonar el recurso por orden de prioridad (de menor a mayor prioridad) mediante el método RequestRelease().
10/04/2005 .22E.T.S de Ingenieros de Telecomunicación
Disputa por la manipulación de recursos
El único problema sería si dos aplicaciones de la misma prioridad requieren el acceso al recurso.
En este caso, MHP define que debe hacer el administrador de recursos y que la petición sea denegada o aceptada depende de la elección que haga el “implementador del middleware”.
10/04/2005 .23E.T.S de Ingenieros de Telecomunicación
Recursos Escasos
Los recursos escasos son:Control de gráficosCambiar de transport streamAcceso canal retornoInteraccionar con el usuarioAcceso a módulos CAAcceso a secciones MPEG2
10/04/2005 .24E.T.S de Ingenieros de Telecomunicación
Acceso Bajo Nivel MPEG-2
Media Control
Application Lifecycle
Gráficos
Comunicación
Cambiar de Transport stream
Control de V/A
Intercambiar datos entre Xlets
Interaccionar con usuario
Control de Gráficos
Acceso AIT comunicar APP
Sincronizar Aplicaciones y
Media
Cambio de
servicio
Dentro de un
servicio
Acceso a ficheros
Almacenado Permanentemente
Ficheros de Broadcast
Acceso canal Retorno
Acceso a Tablas de SI
Acceso a Secciones MPEG2
Recursos escasos en receptor
Acceso a módulos CA
Ejemplo
Canal de retorno
10/04/2005 .26E.T.S de Ingenieros de Telecomunicación
Ejemplo: Canal de retorno
La API del manejo del canal de retorno se define en el paquete org.dvb.net.rc.
Contiene tres clases principales:RCInterface: Representa una interface del canal de
retorno.ConnectionRCInterface: Subclase de RCInterface y
representa una interface del canal de retorno que no tiene conexión permanente.
ConnectionParameters: Define los parámetros más importantes que se necesitan para establecer una conexión (número de teléfono, nombre de usuario y password).
10/04/2005 .27E.T.S de Ingenieros de Telecomunicación
RCInterface
Public class RCInterface{public int getType();
public int getDataRate();
}
10/04/2005 .28E.T.S de Ingenieros de Telecomunicación
Acceso a la interface del canal de retorno
Como el receptor puede soportar más de una interface de canal de retorno, se necesita alguna forma de tener un acceso correcto para nuestra aplicación.
La clase RCInterfaceManager
10/04/2005 .29E.T.S de Ingenieros de Telecomunicación
RCInterfaceManager
Sirve para:
Obtener acceso a la correcta interface del canal de retorno que la aplicación desea.
Administrar el recurso (canal de retorno).
10/04/2005 .30E.T.S de Ingenieros de Telecomunicación
RCInterfaceManager
Las aplicaciones pueden obtener una referencia a él mediante el método getInstance().
Una vez que la aplicación tiene referencia a RCInterfaceManager, puede obtener una interface al canal de retorno apropiado mediante getInterfaces() (nos devuelve las referencias de todas las interfaces de canales de retorno de las cuales la aplicación puede hacer uso).
Implementa el ResourceServer.
10/04/2005 .31E.T.S de Ingenieros de Telecomunicación
RCInterfaceManager
Public class RCInterfaceManagerimplements org.davic.resources.ResourceServer{public static RCInterfaceManager getInstance();public RCInterface [] getInterfaces();public RCInterface getInterface(
Java.net.InetAddress addr);public RCInterface getInterface(
java.net.Socket s);public RCInterface getInterface(
java.net.URLConnection u);public void addResourceStatusEventListener(
org.davic.resources.ResourceStatusListener listener);public void removeResourceStatusEventListener(
org.davic.resources.ResourceStatusListener listener);
10/04/2005 .32E.T.S de Ingenieros de Telecomunicación
Conexión con el canal de retorno
La clase ConnectionRCInterface:Extiende de RCInterface.Sirve para las interfaces de canal de retorno
que deben conectarse antes de su uso (no hay conexión permanente).
Incluye varios métodos para conectarse o desconectarse a un proveedor de servicio y para reservar acceso con el módem.
10/04/2005 .33E.T.S de Ingenieros de Telecomunicación
ConnectionRCInterface
Implementa el ResourceProxy.Reserve(): reserva de interface que otras
aplicaciones no podrán hacer uso de ella.SetTarget(): Muchos módems que no tienen
conexión permanente necesitan conectarse con un proveedor de servicio antes de que las aplicaciones puedan utilizarlo.
Cada tarjeta es definida con ciertos parámetros. Éstos son encapsulados en la clase: ConnectionParameters.
10/04/2005 .34E.T.S de Ingenieros de Telecomunicación
ConnectionRCInterface
Una vez definida la tarjeta para la interface, podemos conectarnos con el proveedor de servicio.
Connect(): Hace una conexión con la tarjeta específica para esa interface.
Disconnect(): Desconecta la interface, cuando hemos acabado la comunicación.
Release(): Permite a otras aplicaciones hacer uso de la interface.
10/04/2005 .35E.T.S de Ingenieros de Telecomunicación
ConnectionRCInterface
public class ConnectionRCInterfaceextends RCInterfaceimplements org.davic.resources.ResourceProxy{public boolean isConnected();public float getSetupTimeEstimate();public void reserve(
org.davis.resources.ResourceClient c,java.lang.Object requestData)
throws PermissionDeniedException;public void release();public void connect()
throws java.io.IOException,PermissionDeniedException;public void disconnect()
throws PermissionDeniedException;public void ConnectionParameters getCurrentTarget()
throws IncompleteTargetException;
10/04/2005 .36E.T.S de Ingenieros de Telecomunicación
ConnectionRCInterface
public void setTarget(ConnectionParameters target)
throws IncompleteTargetException,
PermisionDeniedException;
public void setTargetToDefault()
throws PermissionDeniedException;
public int getConnectedTime();
public org.davic.resources.ResourceClient getClient();
public void addConnectionListener(
ConnectionListener 1);
public void removeConnectionListener(
ConnectionListener 1);
}
10/04/2005 .37E.T.S de Ingenieros de Telecomunicación
ConnectionParameters
public class ConnectionParameters {
public ConnectionParameters(
java.lang.String number,
java.lang.String username,
java.lang.String password);
public ConnectionParameters(
java.lang.String number,
java.lang.String username,
java.lang.String password,
java.net.InetAddress[] dns);
public java.lang.String getTarget();
public java.lang.String getUsername();
Public java.lang.String getPassword();
Public java.net.InetAddress[] getDNSServer();
}
10/04/2005 .38E.T.S de Ingenieros de Telecomunicación
Diferencias con la API de notificación de recursos
RCInterfaceManager actúa como Resource Server. Se deben utilizar objetos ConnectionRCinterface para
reservar o liberar una interface. Las aplicaciones no pueden crear nuevas resource proxy-s.
Las resources proxy-s están implementadas por la clase ConnectionRCInterface.
Las instancias sólo pueden ser creadas por el middleware. Esto permite al middleware devolvernos la interface
apropiada del canal de retorno para una aplicación dada.
10/04/2005 .39E.T.S de Ingenieros de Telecomunicación
Ejemplo código:Conexión servidor remoto
//First,we get a refernce to the RCInterfaceManagerRCInterfaceManager rcm=RCInterfaceManager.getInstance();Boolean connectionMade = false;// Now,we get the list of return channel interfaces that are available to our
applications .This returns all the available interfacesRCInterface[] interfaces=rcm.getInterfaces();//Now choose which interface we use.Since we get all the interfaces,we
need to check that we get the right type.So we check if it was not,wecould do the same thing using another interface,but in this example we won´t fot the sake of simplicity.
If(interfaces[0] instanceof ConectionRCInterface){//If it is a ConnectionRCInterface,it´s not permanently connected,so we need to connect it first
ConnectionRCInterface myInterface;myInterface=(ConectionRCInterface) interfaces[0];
10/04/2005 .40E.T.S de Ingenieros de Telecomunicación
Ejemplo código:Conexión servidor remoto
//Now that we´ve got a reference to the interface ,we can star to use titry{//first , we reserve the connection myInterface.reserve(this,null);}catch (PermisionDeniredException e){
//we can´t reserve the interface so returnreturn;
}//Set up the connection parameters;ConnectionParameters myConnectionParameters;myConnectionParameters=new ConnectionParameters(“+ 0191”,”username”,”password”);
10/04/2005 .41E.T.S de Ingenieros de Telecomunicación
Ejemplo código:Conexión servidor remoto
//Them we set the targer to point to our phone numberTry{
myInterface.setTarget(myConnectionParameters);}Catch (IncompleteDeneitedException ite){
return;}Catch (PermissionDeneitedException e){
return;}//Now that we´ve done that,we can actually connectTry{
myInterface.connect();}Catch (IOExcepcion ioe){
return;}
10/04/2005 .42E.T.S de Ingenieros de Telecomunicación
Ejemplo código:Conexión servidor remoto
Catch(PermissionDeniedExcepcion e) {// we can´t reserve the interface,so return
Return;}
//set the flag that telles us we to disconnect after we are doneconnectionMade= true;
}//do whatever we want to now thar we´ve got a connectionIf (connectionMade){//Once we´re done,we disconnect the interface and relase the resource
try{myInterface.disconnect();
}catch(PermisionDeniedException e) {
return;}
myInterface.release();}
10/04/2005 .43E.T.S de Ingenieros de Telecomunicación
Bibliografía
Interactive TV Standards (A Guide to MHP,OCAP and Java TV). Steven Morris, Anthony Smith-Chaigneau
www.interactivetvweb.org
Top Related