Download Administración de recursos

Administración de recursos escasos en una
aplicación MHP
Amaia Goñi
Silvia Larrayoz
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
E.T.S de Ingenieros de Telecomunicación
.2
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
E.T.S de Ingenieros de Telecomunicación
.3
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
E.T.S de Ingenieros de Telecomunicación
.4
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
E.T.S de Ingenieros de Telecomunicación
.5
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
E.T.S de Ingenieros de Telecomunicación
.6
Diagrama de clases
ResourceClient
ResourceServer
requestRelease(ResourceProxy)
addResourceStatusEventListener()
release(ResourceProxy)
removeResourceStatusEventListener()
notifyRelease(ResourceProxy)
El application manager, llamando
a estos métodos, notifica a la
aplicación que el recurso al que
hace referencia el ResourceProxy
necesita ser liberado
escucha
ResourceStatusListener
statusChanged(ResourceStatusEvent)
ResourceProxy
getClient()
Cada API luego añade
métodos específicos
para el control del
recurso
10/04/2005
recibe
ResourceStatusEvent
E.T.S de Ingenieros de Telecomunicación
.7
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
E.T.S de Ingenieros de Telecomunicación
.8
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
E.T.S de Ingenieros de Telecomunicación
.9
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
E.T.S de Ingenieros de Telecomunicación
.10
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
E.T.S de Ingenieros de Telecomunicación
.11
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
E.T.S de Ingenieros de Telecomunicación
.12
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
E.T.S de Ingenieros de Telecomunicación
.13
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
E.T.S de Ingenieros de Telecomunicación
.14
Acceso a un recurso
Resource client
Petición de
acceso al recurso
Crea instancia
Resource proxy
Validación del Proxy
Acceso al recurso
Resource server
10/04/2005
E.T.S de Ingenieros de Telecomunicación
.15
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
E.T.S de Ingenieros de Telecomunicación
.16
Liberación de un recurso
Resource client
Recurso en uso
Petición finalización
del uso del recurso
Resource proxy
Pérdida
acceso recurso
Invalidación
del Proxy
Resource server
10/04/2005
E.T.S de Ingenieros de Telecomunicación
.17
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
E.T.S de Ingenieros de Telecomunicación
.18
Pérdida de un recurso
Resource client
La
aplicación
se niega a
liberar
el recurso
Recurso en uso
Resource proxy
Pérdida
acceso recurso
Liberar recurso
Invalidación
del Proxy
Resource server
10/04/2005
E.T.S de Ingenieros de Telecomunicación
.19
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
E.T.S de Ingenieros de Telecomunicación
.20
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
E.T.S de Ingenieros de Telecomunicación
.21
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
E.T.S de Ingenieros de Telecomunicación
.22
Recursos Escasos
Los recursos escasos son:
Control de gráficos
Cambiar de transport stream
Acceso canal retorno
Interaccionar con el usuario
Acceso a módulos CA
Acceso a secciones MPEG2
10/04/2005
E.T.S de Ingenieros de Telecomunicación
.23
Application
Lifecycle
Gráficos
Acceso AIT
comunicar APP
Control de
Gráficos
Interaccionar
con usuario
Sincronizar
Aplicaciones y
Media
Cambio
de
servicio
Media
Control
Intercambiar
datos entre Xlets
Acceso a
módulos CA
Acceso a
Secciones MPEG2
Control de V/A
10/04/2005
Acceso canal
Retorno
Recursos
escasos en
receptor
Cambiar de
Transport stream
Dentro
de un
servicio
Comunicación
Acceso a ficheros
Ficheros de Broadcast
Acceso a
Tablas de SI
Almacenado
Permanentemente
Acceso Bajo
Nivel MPEG-2
E.T.S de Ingenieros de Telecomunicación
.24
Ejemplo
Canal de retorno
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
E.T.S de Ingenieros de Telecomunicación
.26
RCInterface
Public class RCInterface{
public int getType();
public int getDataRate();
}
10/04/2005
E.T.S de Ingenieros de Telecomunicación
.27
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
E.T.S de Ingenieros de Telecomunicación
.28
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
E.T.S de Ingenieros de Telecomunicación
.29
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
E.T.S de Ingenieros de Telecomunicación
.30
RCInterfaceManager
 Public class RCInterfaceManager
implements 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
E.T.S de Ingenieros de Telecomunicación
.31
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
E.T.S de Ingenieros de Telecomunicación
.32
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
E.T.S de Ingenieros de Telecomunicación
.33
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
E.T.S de Ingenieros de Telecomunicación
.34
ConnectionRCInterface
 public class ConnectionRCInterface
extends RCInterface
implements 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
E.T.S de Ingenieros de Telecomunicación
.35
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
E.T.S de Ingenieros de Telecomunicación
.36
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
E.T.S de Ingenieros de Telecomunicación
.37
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
E.T.S de Ingenieros de Telecomunicación
.38
Ejemplo código:Conexión
servidor remoto
 //First,we get a refernce to the RCInterfaceManager
RCInterfaceManager 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 interfaces
RCInterface[] 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
E.T.S de Ingenieros de Telecomunicación
.39
Ejemplo código:Conexión
servidor remoto
 //Now that we´ve got a reference to the interface ,we can star to use
ti
try{
//first , we reserve the connection
myInterface.reserve(this,null);
}catch (PermisionDeniredException e){
//we can´t reserve the interface so return
return;
}
//Set up the connection parameters;
ConnectionParameters myConnectionParameters;
myConnectionParameters=new ConnectionParameters
(“+ 0191”,”username”,”password”);
10/04/2005
E.T.S de Ingenieros de Telecomunicación
.40
Ejemplo código:Conexión servidor remoto
 //Them we set the targer to point to our phone number
Try{
myInterface.setTarget(myConnectionParameters);
}
Catch (IncompleteDeneitedException ite){
return;
}
Catch (PermissionDeneitedException e){
return;
}
//Now that we´ve done that,we can actually connect
Try{
myInterface.connect();
}
Catch (IOExcepcion ioe){
return;
}
10/04/2005
E.T.S de Ingenieros de Telecomunicación
.41
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 done
connectionMade= true;
}
//do whatever we want to now thar we´ve got a connection
If (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
E.T.S de Ingenieros de Telecomunicación
.42
Bibliografía
Interactive TV Standards (A Guide to
MHP,OCAP and Java TV).
Steven Morris, Anthony Smith-Chaigneau
www.interactivetvweb.org
10/04/2005
E.T.S de Ingenieros de Telecomunicación
.43