1. ¿Qué significan las siglas MDB?

Message Driven Bean

2. ¿En qué consiste el funcionamiento de los MDB?

Este servicio funciona a través de colas de mensajes, que es donde los clientes envían sus peticiones, y estas colas son controladas por los Message Driven Beans, los cuales procesan los mensajes que hay en ellas y ejecutan ciertos servicios dependiendo del mensaje procesado.

3. ¿Cuál es el ciclo de vida de un MDB?

Para evitar errores de programación, un message-driven bean no puede ser ejecutado por más de un thread a la vez. Por esta razón y además por no guardar estados, el container puede crear un pool de este tipo de beans similar al existente para stateless session beans.

Debido a su naturaleza stateless el ciclo de vida de un message-driven es simple. Cuando el container desea agregar un nuevo message-driven bean al pool debe crear una nueva instancia, asignar el contexto para que obtenga parámetros de sistema y finalmente ejecutar el método ejbCreate(). Después el bean se encuentra en capacidad para recibir y procesar mensajes. Cuando el container decide reducir el número de instancias existentes invoca el método ejbRemove() terminando su ciclo de vida. Ver figura.

Debido a su reducido tiempo de vida y a la no persistencia de sus datos, un message-driven bean no sobrevive a fallas en el container o en el servidor, debiendo ser reinstanciado para continuar recibiendo mensajes luego de ésta.

4. ¿Cuál es la diferencia entre MDB y Beans Sesión?

La diferencia más visible entre beans controlados por mensajes y beans de sesión es que los clientes no tienen acceso a beans controlados por mensajes a través de interfaces. Las interfaces se describen en la sección de acceso de cliente Definición de Interfaces . A diferencia de un bean de sesión, un bean controlado por mensajes tiene sólo una clase de Bean.

En varios aspectos, un bean controlado por mensajes asemeja a un bean de sesión sin estado.

• A instancias bean controlado por mensajes de retener ningún dato o el estado de conversación para un cliente específico.
• Todas las instancias de un bean controlado por mensajes son equivalentes, permitiendo que el contenedor EJB para asignar un mensaje a cualquier instancia del bean controlado por mensajes. El recipiente puede agrupar estos casos para permitir flujos de mensajes que se procesan simultáneamente.
• Un solo bean controlado por mensajes puede procesar mensajes de varios clientes.

5. ¿Cómo se usa un MDB?

Los beans de sesión le permiten enviar mensajes JMS y recibirlos de forma sincrónica, pero no de forma asíncrona. Para evitar la inmovilización de los recursos del servidor, no usar el bloqueo sincrónico recibe en un componente del lado del servidor, y en general los mensajes JMS no deben ser enviados o recibidos de forma sincrónica. Para recibir mensajes de forma asincrónica, utilice un bean controlado por mensajes.

6. ¿Cuáles son las características de los MDB?

Beans controlados por mensajes con las siguientes características:

· Ejecutan a la recepción de un mensaje único cliente.

· Se invoca de forma asincrónica.

· Ellos son relativamente de corta duración.

· Ellos no representan directamente los datos compartidos en la base de datos, pero pueden acceder y actualizar estos datos.

· Pueden ser consciente de transacción.

· Ellos son apátridas.

¿Qué es el middleware orientado a mensajes (MOM)?

Middleware orientado a mensajes (MOM) es software o hardware que soporta la infraestructura de envío y recepción de mensajes entre sistemas distribuidos. MOM permite a los módulos de aplicación que se distribuye a través de plataformas heterogéneas y reduce la complejidad del desarrollo de aplicaciones que abarcan múltiples sistemas operativos y protocolos de red. El middleware crea una capa de comunicaciones distribuida que aísla el desarrollador de la aplicación de los detalles del sistema operativo y varias interfaces de red. API que se extienden a través de diversas plataformas y redes suelen ser proporcionada por MOM.

MOM proporciona elementos de software que residen en todos los componentes se comunican de una arquitectura cliente / servidor y suelen admitir llamadas asíncronas entre las aplicaciones cliente y servidor. MOM reduce la participación de los desarrolladores de aplicaciones con la complejidad de la naturaleza maestro-esclavo del mecanismo cliente / servidor.

¿Cuál es el propósito principal o funciones de middleware orientado a mensajes?

MOM es principalmente middleware que facilita la comunicación entre las aplicaciones distribuidas. Mientras MOM admite mensajería síncrona y asíncrona, que está más estrechamente identificado con la mensajería asincrónica mediante colas. MOM envía mensajes de una aplicación a otra utilizando una cola como un paso intermedio. Mensajes del cliente se envían a una cola y permanecer allí hasta que son recuperados por la aplicación de servidor. La ventaja de este sistema es que el servidor de aplicaciones no necesita estar disponible cuando el mensaje es enviado, en su lugar, el servidor puede recuperar el mensaje en cualquier momento. Además, ya que los mensajes pueden ser recuperados de la cola en cualquier orden, MOM también puede facilitar la recuperación de mensajes utilizando esquemas de prioridad o de balanceo de carga. MOM también puede proporcionar un nivel de tolerancia a fallos utilizando colas persistentes que permiten que los mensajes se recuperó cuando el sistema falla.

De acuerdo con un octubre de 1996, artículo en InfoWorld por Julie Bort, “Queue Server es una opción popular para los procesos donde cada paso es dependiente de la anterior, es también muy adecuado para aplicaciones diseñadas para la comunicación de fondo donde hay interacción directa del usuario es involucrados “. Muchos otros analistas describen la importancia de MOM en el apoyo a las aplicaciones heredadas y los sistemas dispersos.

¿Cómo se diferencia de otro tipo de middleware?

Middleware es la amplia gama de servicios en capas entre las aplicaciones y un sistema operativo que proporcionan servicios especializados y la interoperabilidad entre las aplicaciones distribuidas. Por una variedad de razones, incluyendo el hecho de que el middleware es una categoría relativamente nueva de software, la funcionalidad de los diferentes tipos de middleware no está estandarizada. Por ejemplo, la función primaria de middleware de procesamiento de transacciones tiene que ver con el control, pero muchos de los productos de procesamiento de transacciones también incluyen servicios de comunicación. Proveedores de middleware añadir funciones de garantizar que sus productos interactuar con una variedad de hardware y software, y para ayudar a diferenciar su producto de los competidores.

Debido a que cada producto dentro de una categoría de middleware incluye una variedad de funciones y porque las funciones “estándar” dentro de cada categoría cambian rápidamente, las distinciones útiles entre los servicios de middleware son difíciles de encontrar. Sin embargo, la siguiente es una de las muchas maneras de clasificar los productos de middleware que hemos encontrado útil. Tenga en cuenta que esta no es una lista completa de servicios de middleware.

Presentación Prestaciones: Formas gerente, gerente de gráficos, enlazador hipermedia, y administrador de impresión.

Servicios: Comunicación Peer-to-peer de mensajería, llamada a procedimiento remoto, paso de mensajes, colas de mensajes, correo electrónico e intercambio electrónico de datos.

Servicios de Control: administrador de subprocesos, administrador de transacciones, corredor de los recursos, de grano fino petición del planificador y de grano grueso Programador de tareas.

Servicios de Información: servidor de directorio, gerente de registro, administrador de archivos, gestor de registro, el sistema de base de datos relacional orientada a objetos de base de datos del sistema y gestor de repositorio.

MOM se inscribe en el middleware de servicios de comunicación y por lo general incluye el paso de mensajes y colas de mensajes. Muchos productos también soportan llamadas a procedimientos remotos, así como servicios de directorio.

¿Cuál es la diferencia entre los servicios de comunicación Momand otros?

MOM admite mensajes y por lo tanto se ha diseñado principalmente para apoyar la comunicación diferida mientras peer-to-peer y las llamadas a procedimiento remoto (RPC) están diseñados para soportar la comunicación síncrona. En RPC, el servidor receptor debe estar disponible para aceptar mensajes enviados. Si el servidor es baja, el mensaje no se puede entregar en ese momento. MOM, por otro lado, puede enviar mensajes a los servidores que están abajo sin tener que volver a enviarlo. Mensajes en un sistema de MOM se colocan en una cola y recuperar siempre que el servidor lo solicite. Si el servidor está disponible en el momento en que se envía el mensaje es irrelevante.

Actividad 1:

Validación

1. ¿Describe las razones por las cuales es necesaria la validación?

a. Costes de fallos de ejecución. Los costes y las consecuencias de los fallos de ejecución de los sistemas críticos son potencial mente mucho más grandes que para los sistemas no críticos. Pueden reducirse los riesgos de los fallos del sistema invirtiendo más en verificación y validación del sistema. Normalmente es más económico encontrar y eliminar defectos antes de que el sistema sea entregado que pagar por los consecuentes costes de accidentes o de un mal funcionamiento de los servicios del sistema.

b. Validación de los atributos de confiabilidad. Puede tenerse que hacer una demostración formal a los clientes de que el sistema satisface sus requerimientos especificados de confiabilidad (disponibilidad, fiabilidad, seguridad y protección). Para evaluar estas características de confiabilidad se requieren actividades específicas de V & V explicadas más adelante en este capítulo. En algunos casos, los reguladores externos, tales como autoridades de aviación nacionales, pueden tener que certificar que el sistema es seguro antes de que éste sea desplegado. Para obtener esta certificación, pueden tenerse que diseñar y llevar a cabo procedimientos de V & V especiales que recogen la evidencia sobre la confiabilidad del sistema.

2. Cuál es el proceso para medir la fiabilidad de un software

Pruebas estadísticas

a. Se comienza estudiando los sistemas existentes del mismo tipo para establecer un per- fil operacional. Un perfil operacional identifica las clases de entradas al sistema y la probabilidad de que estas entradas ocurran en un uso normal.

b. A continuación, se construye un conjunto de datos de prueba que reflejan el perfil operacional. Esto significa que se crean datos de prueba con la misma distribución de probabilidad que los datos de prueba para los sistemas que se han estudiado. Normalmente, se utiliza un generador de datos de prueba para soportar este proceso.

c. Se prueba el sistema utilizando estos datos y se contabiliza el número y tipo de fallos que ocurren. Los instantes en los que ocurren estos fallos también son registrados. Tal y como se indicó en el Capítulo 9, las unidades de tiempo que se elijan deberían ser adecuadas para la métrica de fiabilidad utilizada.

d. Después de que se ha observado un número de fallos significativos estadísticamente, se puede calcular la fiabilidad del software y obtener el valor adecuado de la métrica de fiabilidad.

3. Que es y porque es importante un perfil de operaciones

Consiste en la especificación de clases de entradas y la probabilidad de su ocurrencia. Cuando un nuevo sistema software reemplaza a un sistema existente manual o automatizado, es razonablemente fácil evaluar el patrón de uso probable del nuevo software. Éste debería corresponderse con el uso del sistema existente, con algunas adiciones para las nuevas funcionalidades que (presumiblemente) se incluyen en el nuevo software. Por ejemplo, puede especificarse un perfil operacional para sistemas de centralitas de telecomunicaciones debido a que las compañías de telecomunicaciones conocen los patrones de llamadas que estos sistemas tienen que manejar.

El perfil operacional del software es importante por que refleja cómo se utilizará éste en la práctica.

4. La dificultad para la construcción de un perfil operacional de un software nuevo ¿Es igual para uno que se creó para remplazar a otro?

NO por que cuando un sistema software es nuevo e innovador, es difícil anticipar cómo será utilizado y, por lo tanto, generar un perfil operacional preciso.

5. Cómo funciona el modelo de crecimiento de fiabilidad

Un modelo de crecimiento de fiabilidad es un modelo de cómo cambia la fiabilidad del sistema a lo largo del tiempo durante el proceso de pruebas. Para predecir la fiabilidad, el modelo conceptual de crecimiento de la fiabilidad debe ser traducido a un modelo matemático.

Aquí no se entra en este nivel de detalle, sino que simplemente se plantea el principio del crecimiento de la fiabilidad.

6. ¿Es garantía de que la fiabilidad mejorara en cada entrega después de corregir fallos? ¿Por qué?

SI, por que a medida que se descubren los fallos del sistema, los defectos subyacentes que provocan estos fallos son reparados para que la fiabilidad del sistema mejore durante las pruebas y depuración.

Aunque los defectos del software no siempre se reparan durante la depuración, y cuando se cambia un programa, a menudo se introducen nuevos defectos. La probabilidad de ocurrencia de estos defectos puede ser mayor que la probabilidad de ocurrencia del defecto que ha sido reparado. Por lo tanto, la fiabilidad del sistema a veces puede empeorar en una nueva entrega en lugar de mejorar.

Por lo tanto no es garantía

7. ¿Hasta cuando las pruebas y depuración deben continuar?

Las pruebas pueden detenerse cuando se alcance el nivel requerido de fiabilidad del sistema.

8. Ventajas de la predicción de la predicción a partir de un modelo

Planificación de las pruebas. Dado el calendario actual de pruebas, puede predecirse cuándo se completarán las pruebas. Si el final de las pruebas tiene lugar después de la fecha planificada de entrega del sistema, entonces puede tenerse que desplegar recursos adicionales para probar y depurar, y así acelerar la tasa de crecimiento de fiabilidad.

Negociaciones con el cliente. Algunas veces el modelo de fiabilidad muestra que el crecimiento de la fiabilidad es muy lento y que se requiere una cantidad de esfuerzo de pruebas desproporcionada para obtener un beneficio relativamente pequeño.

Puede merecer la pena renegociar los requerimientos de fiabilidad con el cliente. De forma alternativa, puede ocurrir que el modelo prediga que la fiabilidad requerida probablemente nunca será alcanzada. En este caso, se tendrán que renegociar con el cliente los requerimientos de la fiabilidad del sistema.

9. Tipos de revisiones propuestas por el autor para ser obligatorias y garantizar la seguridad de un sistema

1. revisión para corregir la función que se pretende;

2. revisión para una estructura comprensible y mantenible;

3. revisión para verificar que el algoritmo y el diseño de las estructuras de datos son consistentes con el comportamiento especificado;

4. revisión de la consistencia del código y del diseño del algoritmo y de las estructuras de datos;

5. revisión de la adecuación de los casos de prueba del sistema

10. En qué consiste la técnica más efectiva para demostrar la seguridad del sistema (contradicción)

La técnica más efectiva para demostrar la seguridad de un sistema es la demostración por contradicción. Se comienza suponiendo que se está en un estado no seguro, el cual ha sido identificado por un análisis de contingencias del sistema, y que puede ser alcanzado ejecutando el programa. Se describe un predicado que define este estado no seguro.

A continuación, se analiza el código de forma sistemática y se muestra que, para todos los caminos del programa que conducen a ese estado, la condición de terminación de estos caminos contradice el predicado no seguro.

Si éste es el caso, la suposición inicial de un estado inseguro es incorrecta.

Si se repite esto para todas las contingencias identificadas, entonces el software es seguro.

a. Ejemplo:

Como ejemplo, consideremos el código de la Figura 24.6, que podría ser parte de la implementación del sistema de suministro de insulina. Desarrollar un argumento de seguridad para este código implica demostrar que la dosis de insulina administrada nunca es mayor que algún nivel máximo establecido para cada individuo diabético. Por lo tanto, no es necesario probar que el sistema suministra la dosis correcta, sino simplemente que nunca suministra una sobredosis al paciente.

Para construir un argumento de seguridad, se identifica la precondición para el estado in- seguro que, en este caso, es que currentDose > maxDose. Después se demuestra que todos los caminos del programa conducen a una contradicción de esta aserción no segura. Si éste es el caso, la condición no segura no puede ser cierta. Por lo tanto, el sistema es seguro. Se pueden estructurar y presentar los argumentos de seguridad de forma gráfica tal y como se muestra en la Figura 24.7. Los argumentos de seguridad, según se refleja en la citada figura, son mucho más cortos que las verificaciones formales de sistemas. Primero se identifica todos los posibles caminos que conducen a! estado potencial mente inseguro. Se trabaja hacia atrás a partir de este estado no seguro y se considera la última asignación de todas las variables de estado en cada camino que conduce a él. Pueden omitirse los cálculos previos (como la sentencia if 1 en la Fi- gura 24.7) en el argumento de seguridad. En este ejemplo, todo lo que se necesita saber es el conjunto de posibles valores de currentDose inmediatamente antes de que el método administerlnsulin sea ejecutado. En el argumento de seguridad mostrado en la Figura 24.7, existen tres posibles caminos en el programa que conducen a la llamada al método administerlnsulin. Queremos demostrar que la cantidad de insulina suministrada nunca excede del valor de maxDose. Se consideran todos los posibles caminos hasta administerlnsulin:

Fuente: ingeniería del software lan Sommenville

Se preguntarán para que sirve una bitácora en en una Aplicación Web. Bueno les diré, es muy útil, ya que va guardando los movimientos de los usuarios y en  caso de reclamo por parte de los usuarios de que el sistema que hemos desarrollado no funciona por que han perdido datos pero en realidad ellos los borraron por razones privadas, nosotros podremos defendernos con esta bitácora de movimientos que dirá a que hora se realizo cierta acción y quien la realizo ejemplo:

Como pueden ver se puede visualizar la acción realizada, el usuario al que se le hizo el cambio luego al usuario que realizo

el cambio, la fecha y hora en que se realizo la acción y valor anterior y el valor nuevo

A continuación les mostrare parte del código

Vista de la bitácora “bitacora.php”

<?php

function estado($edo){

    if($edo==1){

        return "Administrador";

        }

    else {

        return "Usuario";

    }

    }

$eliminar = base_url()."imagenes/eliminar.fw.png";

$actualizar = base_url()."imagenes/modificar.png";

function estadoImg($edo){

    $palomita = base_url()."imagenes/v.fw.png";

    $x = base_url()."imagenes/eliminar.png";

    if($edo==1){

        return "<img src=".$palomita.">";

    }

    else{

        return "<img src=".$x.">";

    }

}

?>

        <script type="text/javascript">

        <!--

        function confirmacion(id) {

        var answer = confirm("Esta seguro que desea eliminar")

        if (answer){

        alert("Ha confirmado eliminar")

        location.href="deleteUserId/"+id

        }

        else{

        alert("Cancelado")

        }

    }

    function actualizar(id) {

        location.href="updateUserId/"+id

    }

//-->

        <?php echo $_SESSION['nombre'];?>

        
Bitacora

<div id="container">

    <div id="body" align="center">

            <table border="0" align="center">

            <form id="b" name="b" action="index.php/welcome/buscarBitacora" method="POST">

            <label for="buscar">Buscar 

            <input type= "text" id="buscar" name="buscar" >

            <input type="submit" id="arre" name="arre" value="buscar"

            <table border="0" align="center" id="tabla">

            <tr bgcolor="#7362ec" align="center">

            Acción

            Usuario administrado 

            Usuario administrador  

            Fecha

            Valor Anterior

            Valor nuevo

            <?php

            $colorfila=0;

            if($users!=false){

               foreach($users->result() as $row){

                   if ($colorfila==0){ 

                   $color= "#b5b5b5"; 

                   $colorfila=1; 

                    }else{ 

                   $color="#f7f7f7"; 

                   $colorfila=0; 

                }    

                echo "<tr bgcolor='".$color."' align='center' ";?> onmouseover="this.style.backgroundColor='#E13300'"

                                                                   onmouseout="this.style.backgroundColor=''"><?php

                echo " ".$row->accion."";

                echo "".$row->UsuarioAdministrado. "";

                echo " ".$row->usuarioAdministrador."";

                echo "".$row->fecha."";

                echo "".$row->valor_anterior."";

                echo "".$row->valor_nuevo."";

                echo "";

            }

        }

        ?>