ISD

Capacidad de soportar más usuarios, así como poder aumentar los recursos disponibles para ellos:!. Alta disponibilidad. Escalabilidad. Transaccionalidad. Seguridad.

Debe ser tolerante a los fallos, lo que permite que la aplicación esté disponible siempre para su uso. Una técnica común consiste en replicar los servidores que emplea la aplicación a nivel mundial, para facilitar el acceso a los recursos. Alta disponibilidad. Escalabilidad. Transaccionalidad. Seguridad.

Debe cumplir con las propiedades ACID:!. Alta disponibilidad. Escalabilidad. Transaccionalidad. Seguridad.

Debe tener en cuenta que no todos los usuarios pueden acceder a las mismas funcionalides del sistema. Consiste, generalmente, en distinguir entre un administrador y los usuarios.!. Alta disponibilidad. Escalabilidad. Transaccionalidad. Seguridad.

Las propiedades ACID son: Atomicidad, Control, Aislamiento, Durabilidad. Atomicidad, Control, Aislamiento, Distribución. Atomicidad, Consistencia, Aislamiento, Distribución. Atomicidad, Consistencia, Aislamiento, Durabilidad.

Debe ejecutar las sentencias completamente o no ejecutarlas en absoluto: Consistencia. Atomicidad. Aislamiento. Durabilidad.

Debe conservar la integridad de la BD durante las operaciones: Consistencia. Atomicidad. Aislamiento. Durabilidad.

Al finalizar una operación, los datos de la BD deben permanecer guardados:!. Consistencia. Atomicidad. Aislamiento. Durabilidad.

Ejecutar varias transacciones en paralelo debe ser equivalente a ejecutar dichas transacciones en serie: Consistencia. Atomicidad. Aislamiento. Durabilidad.

Las aplicaciones modernas funcionan de forma aislada: Verdadero. Falso.

Diseño por capas: Existencia de una capa inferior que conocemos su implementación pero no que proporciona un servicio a otra capa superior al que se le llama contrato de servicio. Existencia de una capa inferior de la cual no conocemos su implementación pero sí sabemos que proporciona un servicio a otra capa superior, el cual queda establecido mediante un contrato de servicio. Existencia de una capa superior que conocemos su implementación pero no que proporciona un servicio a otra capa inferior al que se le llama contrato de servicio. Existencia de una capa superior de la cual no conocemos su implementación pero sí sabemos que proporciona un servicio a otra capa inferior, el cual queda establecido mediante un contrato de servicio.

La arquitectura de un diseño por capas se divide en. Capa modelo y capa acceso a datos. Capa lógica de negocio y capa interfaz. Capa modelo y capa interfaz. Capa modelo y capa servicio.

Conjunto de clases que implementan la lógica del negocio y los casos de uso de la aplicación. Capa Interfaz. Capa Lógica de negocio. Capa Modelo. Capa Acceso a Datos.

Se encarga de leer y escribir los datos que manipula la aplicación. Hace uso de BD y puede necesitar emplear servicios de otras apps. Capa Interfaz. Capa Lógica de negocio. Capa Modelo. Capa Acceso a datos.

Capa que implementa el funcionamiento de la aplicación, pudiendo llamar a la capa Acceso a datos para leer/escribir los datos que necesite. Capa Interfaz. Capa Lógica de negocio. Capa Modelo. Capa Servicios.

Capa que permite la interacción de los usuarios con nuestra aplicación. Capa Interfaz. Capa Lógica de negocio. Capa Modelo. Capa Servicios.

Capa que implementa pantallas que permiten a los humanos emplear las funcionalidades que ofrece la Capa Modelo. Capa Interfaz. Capa Interfaz Gráfica. Capa Modelo. Capa Servicios.

Interfaz programa destinada a que aplicaciones remotas puedan usar las funcionalidades de la Capa Modelo. Es el API de nuestra aplicación. Capa Interfaz. Capa Interfaz Gráfica. Capa Modelo. Capa Servicio.

Los terminales se comunican directamente con el servidor de datos a través de la red. En cada máquina cliente está instalada la aplicación, que emplea la Capa Interfaz Gráfica y la Capa Modelo. Es la capa modelo de cada máquina cliente la encargada de acceder a la BD: Conexión directa. Servidor modelo. Servidor de Aplicaciones Web. Arquitectura en 4 capas.

En este modelo las máquina cliente actúan como clientes de escritorio. Necesitan acceder al nuevo servidor intermedio que implementa la Capa Modelo, por lo que se añade la Capa Acceso a Servicios. Se invoca a la capa modelo remotamente.!. Conexión directa. Servidor modelo. Servidor de Aplicaciones Web. Arquitectura en 4 capas.!.

Las aplicaciones Web se instalan en servidores de aplicaciones web. Los cambios en la capa interfaz gráfica o en la capa modelo solo requieren reinstalar la palicación en el servidor de aplicaciones. Permiten una mayor escalabilidad y disponibilidad, se pueden crear “clústeres de máquinas”. Conexión directa. Servidor modelo. Servidor de Aplicaciones Web. Arquitectura en 4 capas.

Podemos separar la capa modleo de la capa aplicación web. Distintas aplicaciones podrán hacer uso de las funcionalidades de nuestra capa modelo sin tener que emplear el mismo interfaz gráfico, esto aumenta enormemente la escalabilidad de nuestra aplicación. Conexión directa. Servidor modelo. Servidor de Aplicaciones Web. Arquitectura en 4 capas.

Emplearemos el API de Java para acceso a base de datos JDBC. Esta API permite acceder a BDs relacionales, permitiendo al programador abstraerse de los detalles de implementación del API que ofrezca cada BD. Tecnologías para Capa Lógica de Negocio. Tecnologías para Capa de Acceso a Datos. Tecnologías para Capa Interfaz Web. Tecnologías para Capa Servicios.

No emplearemos ninguna tecnología auxiliar para la implementación de esta capa. Existen tecnologías que ayudan a implementar las funcionalidades propias de esta capa, y que resultan útiles en temas como políticas de transacciones, seguridad o para facilitar la programación. Tecnologías para Capa Lógica de Negocio. Tecnologías para Capa de Acceso a Datos. Tecnologías para Capa Interfaz Web. Tecnologías para Capa Servicios.

Emplearemos el API de Java para diseño de interfaces web Servlets. Tecnologías para Capa Lógica de Negocio. Tecnologías para Capa de Acceso a Datos. Tecnologías para Capa Interfaz Web. Tecnologías para Capa Servicios.

Un servicio web expone varios endpoints, que son puntos de acceso a las funcionalidades de nuestra Capa Modelo, los cuales pueden ser invocados por procesos externos. Tecnologías para Capa Lógica de Negocio. Tecnologías para Capa de Acceso a Datos. Tecnologías para Capa Interfaz Web. Tecnologías para Capa Servicios.

Si nuestra aplicación cambiase de BD necesitaríamos cambiar el código y el driver que sea adecuado para la nueva BD. Verdadero. Falso.

Almacena la URL para conectarse a la BD, el usuario y la contraseña. Así como un método estático que nos devolverá la conexión. Connection. ConnectionManager. DriverManager. Ninguna es correcta.

El método getConnection llama al método DriverManager.getConnection que es el que realmente obtiene las conexiones y es la que proporciona el API de JDBC. Verdadero. Falso.

Interfaz que representa la conexión con la BD. Usando prepareStatement(String query) que recibe como argumento el texto con la cnsulta SQL parametrizada (?), nos devolverá un objeto de tipo PreparedStatement a través del cual ejecutaremos la consulta en la BD. Connection. PreparedStatement. Execute. Insert.

Contiene la consulta SQL parametrizada y lista para ejecutarse en la BD. Parametrizada significa que los caracteres “?” deben ser reemplazados por los datos a buscar en la BD. Connection. PreparedStatement. Execute. Insert.

En la interfaz PreparedStatement usamos los métodos getXXX donde XXX representa el tipo de dato que queremos sustitur. Verdadero. Falso.

En la interfaz PreparedStatement los parámetros “?” se numeran del 1 en adelante, de modo que en el método el primer argumento será la posición del parámetro a sustituir y el segundo es el valor por el cual reemplazar. Verdadero. Falso.

En la interfaz PreparedStatement podemos ejecutar las consultas SQL del tipo INSERT, UPDATE, DELETE… y nos devuelve el número de filas afectadas por la consulta. Usando executeUpdate(). Usando executeQuery(). Usando execute(). Ninguna de las anteriores.

En la interfaz PreparedStatement para ejecutar consultas tipo SELECT y nos devuelve un objeto el tipo ResultSet. Usando executeUpdate(). Usando executeQuery(). Usando execute(). Ninguna de las anteriores.

Es el driver quien formatea los datos y no el programador. Verdadero. Falso.

ResultSet representa todas las filas que devuelve como resultado la BD. Para poder iterar sobre las filas resultado: La implementación de ResultSet mantiene dinámicamente un cursor sobre las filas que siempre apuntará antes de la primera fila al obtener el resultado. La implementación de ResultSet mantiene automáticamente un cursor sobre las columnas que siempre apuntará antes de la primera columna al obtener el resultado. La implementación de ResultSet mantiene dinámicamente un cursor sobre las columnas que siempre apuntará antes de la primera columna al obtener el resultado. La implementación de ResultSet mantiene automáticamente un cursor sobre las filas que siempre apuntará antes de la primera fila al obtener el resultado.

ResultSet también dispone de métdos getXX para acceder a los valores de las columnas de la fila a la que apunta el cursor. Verdadero. Falso.

Si no empleamos un bloque try-with-resources se cerrará automaticamente todas las conexiones al final dentro del bloque finally. Verdadero. Falso.

finalize() se ejecutará solo cuando no se llame a close(), y debe definir cómo cerrar la conexión con la BD. Verdadero. Falso.

Si cada thread que acceda a la BD no cierra su conexión al finalizar su trabajo, la conexió no será cerrada hasta que se ejecute el recoletor de basura en el servidor de aplicaciones y detecte que la conexión de ese thread no se está usando. Verdadero. Falso.

Qué excepción devuelve el DriverManager.getConnection si hay peticiones HTTP que tienen que esperar a obtener una conexión, ralentizando el funcionamiento de la aplicación?. SQLException. Segmentation Fault. InputError. Ninguna de las anteriores.

Pool de conexiones: Cuando se cree una nueva conexión a la BD, el servidor de aplicaciones no cerrará del todo la conexión cuando el thread la cierre, la mantendrá activa pero sin asignarla a ningún thread; cuando el servidor reciba una conexión HTTP, no creará una nueva conexión, le asignará alguna de las conexiones disponibles. Cuando se cree una nueva conexión a la BD, el servidor de aplicaciones cerrará del todo la conexión cuando el thread la cierre, la mantendrá activa pero sin asignarla a ningún thread; cuando el servidor reciba una conexión HTTP, no creará una nueva conexión, le asignará alguna de las conexiones disponibles. Cuando se cree una nueva conexión a la BD, el servidor de aplicaciones no cerrará del todo la conexión cuando el thread la cierre, la mantendrá activa asignándola a un thread; cuando el servidor reciba una conexión HTTP, no creará una nueva conexión, le asignará alguna de las conexiones disponibles. Cuando se cree una nueva conexión a la BD, el servidor de aplicaciones cerrará del todo la conexión cuando el thread la cierre, la mantendrá activa pero asignándola a un thread; cuando el servidor reciba una conexión HTTP, no creará una nueva conexión, le asignará alguna de las conexiones disponibles.

Empleando la interfaz DataSource el programador no tiene que indicar la URL, usuario y contraseña siempre que necesite pedir una conexión, porque todas las conexiones se realizarán a la misma BD. Verdadero. Falso.

El programador debe pedir conexiones a la BD a la instancia de DataSource, y para evitar saturar el pool de conexioines es recomendable combinar el: Patrón Singleton con el DataSource. Patrón Proxy. Patrón DataSource. Ninguna de las anteriores.

Para facilitar la obtención de conexiones: Usamos el patrón Proxy. Usamos el patrón singleton. Usamos el patrón ConnectionProxy. Ninguna de las anteriores.

No necesitamos crear todas las conexiones posibles a la BD tan pronto se inicie nuestro programa, sino que solo necesitaremos una conexión cada vez que realmente necesitemos acceder a la bd. Verdadero. Falso.

Si se produce una caída de la BD con el patrón Proxy no hay problema, las conexiones siguen siendo válidas incluso si se reinicia la BD. Verdadero. Falso.

Cuando se crea una conexión con la BD está en modo auto-commit: Cada consulta lanzada se ejecutará en transacciones distintas. Cada consulta lanzada se ejecutará en su propia transacción. Cada consulta lanzada no se ejecutará en transacciones como tal. Ninguna es correcta.

Solución para la lectuar fantasma es: Agrupar varias consultas en una misma transacción. Agrupar la misma consulta en la misma transacción. Agrupar varias consultas en transacciones distintas. Agrupar la misma consulta en transacciones distintas.

En el aislamiento de transacciones, aquella que no permite ejecutar transacciones: TRANSACTION_NONE. TRANSACTION_READ_UNCOMMITED. TRANSACTION_READ_COMMITED. TRANSACTION_REPEATABLE_READ. TRANSACTION_SERIALIZABLE.

Lecuras sucias, lecturas no repetibles y lecturas fantasma. TRANSACTION_NONE. TRANSACTION_READ_UNCOMMITED. TRANSACTION_READ_COMMITED. TRANSACTION_REPEATABLE_READ. TRANSACTION_SERIALIZABLE.

Lecturas no repetibles y lecturas fantasma. TRANSACTION_NONE. TRANSACTION_READ_UNCOMMITED. TRANSACTION_READ_COMMITED. TRANSACTION_REPEATABLE_READ. TRANSACTION_SERIALIZABLE.

Elimina todos los problemas de concurrencia porque crea una transacción serializable!. TRANSACTION_NONE. TRANSACTION_READ_UNCOMMITED. TRANSACTION_READ_COMMITED. TRANSACTION_REPEATABLE_READ. TRANSACTION_SERIALIZABLE.

Lecturas fantasma!. TRANSACTION_NONE. TRANSACTION_READ_UNCOMMITED. TRANSACTION_READ_COMMITED. TRANSACTION_REPEATABLE_READ. TRANSACTION_SERIALIZABLE.

A mayor nivel de aislamiento, la BD realizará más bloqueos sobre los recursos que necesita para ejecutar la consulta, lo cual reduce drásticamente la concurrencia y hace más lentas las consultas.!. Verdadero. Falso.

La capa modelo no oculta detalles de implementación, así es posible modificar la capa sin afectar a las capas superiores. Verdadero. Falso.

Módulo que contiene clases reusables. ws-app-model. ws-properties. ws-service. ws-util.

Errores del usuario. Errores Lógicos. Errores Graves. Errores unchecked. Errores checked.

Dentro de los errores lógicos, la capa modelo notifica este tipo de errores lanzando excepciones checked: Deben capturarse con bloques try-catch. Declarar que el método puede lanzar estas excepciones en su cabecera. Estas excepciones se capturan en la interfaz el usuario y se muestran mensajes de error. Ws-util incluye dos excepciones: InstanceNotFoundExceptoin y InputValidationException. Todas son correctas.

Excepción que se lanza cuando se intenta realizar una operación sobre un objeto persistente que no existe. InputValidationException. InstanceNotFoundException. RuntimeException. SQLException.

Excepción que se lanza cuando se ha insertado información en un formato erróneo. InputValidationException. InstanceNotFoundException. RuntimeException. SQLException.

Error en la infraestructura de la aplicación. Errores Lógicos. Errores Graves. Errores unchecked. Errores checked.

Los errores graves los trataremos como errores de ejecución: Lanzando excepciones unchecked como RuntimeException. Pasándole como argumento la excepción original que ha causado el error. Lanzando excepciones unchecked como RuntimeException. y Pasándole como argumento la excepción original que ha causado el error. son correctas. Lanzando excepciones unchecked como RuntimeException. y pasándole como argumento el parámetro de ws-util que soluciona el error.

Dónde se guardan los parámetros de configuración de la aplicación?. ConfigurationParameterManager. ConfigurationParameter.properties. ConfigurationParametersManager. ConfigurationParameters.properties.

Para diseñar abstracción emplearemos un patrón DAO. En qué consiste?. Diseñar una interfaz. Diseñar una interfaz y añadir una clase que implemente la interfaz, por lo menos. Diseñar una clase y añadir una interfaz que implemente la clase, por lo menos. Diseñar una clase.

Los DAO que definiremos reciben la conexión para poder agrupar en la misma transacción las operaciones de dicho DAO. Verdadero. Falso.

Qué metodo(s) implementa Jdbc3CcSqlAppDao?. Create. Find. Delete. Todas.

Los objetos PreparedStatment son recursos: Implementan el interfaz AutoCloseable automáticamente. Usa bloques try-with-resources en cada método del Dao. Usa bloques try-with-resources en AutoCloseable. Implementan el interfaz AutoCloseable automáticamente y Usa bloques try-with-resources en cada método del Dao.

Cual es la principal ventja de usar una interfaz ?. Mientras se implementan los casos de uso correctamente, puede existir ""otra clase que aporte una implementación superficial. Se realizan operaciones de inserción de manera más sencilla. Permite que los desarrolladores de las capas superiores puedan seguir """desarrollando su capa y hacer uso de los servicios de la capa Modelo. Mientras se implementan los casos de uso correctamente, puede existir ""otra clase que aporte una implementación superficial. y Permite que los desarrolladores de las capas superiores puedan seguir """desarrollando su capa y hacer uso de los servicios de la capa Modelo.

A la hora de getionar las transacciones, si las operaciones solo leen la BD. Que haremos?. Poner el auto-commit a false por defecto y dejar el nivel de aislamiento """por defecto. Poner el auto-commit a true por defecto y dejar el nivel de aislamiento por defecto. Poner elauto-commit a true por defecto y dejar el nivel de aislamiento a ""true. Poner el auto-commit a false por defecto y dejar el nivel de aislamiento a ""false.

Los pasos que hay que seguir si las operaciones modifican la BD son. Validar los datos de entrada con un PropertyValidator. Establecer el nivel de aislamiento a TRANSACTION_SERIALIZABLE y " ""deshabilitar el modo auto-commit a false. Comprobar si el caso de uso es ejecutable, implementar la lógica de " ""negocio del caso de uso y si se produce un error grave ejecutar rollback y ""lanzar la excepción correspondiente. Por último, ejecutar un commit para """reflejar las modificaciones de la BD. Todas son correctas.

Qué pasa al encender el servidor?. Se comienza a ejecutar java. Se crea la máquina virtual JVM. La aplicación debe ser capaz deobtener referencias al DataSource. Todas son correctas.

En las referencias al DataSource, la aplicación se ejecuta dentro de un entorno concreto, dentro de la misma JVM, de modo que proporcionará una referencia a DataSource de manera sencilla. Capa modelo se ejecuta dentro de una app web. Capa modelo es invocada por pruebas de integración. Capa modelo es invocada por pruebas web. Todas son correctas.

En las referencias al DataSource, las pruebas no están ejecutándose en el mismo servidor que la aplicación, así que es responsabilidad del programador obtener referencias a los DataSource. Se usa abstracción y delegamos ea responsabilidad en otra clase para que nos devuelva una referencia al DataSource. Capa modelo se ejecuta dentro de una app web. Capa modelo es invocada por pruebas de integración. Capa modelo es invocada por pruebas web. Todas son correctas.

Para poder obtener una referencia a un DAO sin conocer la clase que lo mplementa hacemos uso del patrón: Singleton. Factoría. Sql. Singleton y Sql.

Cuando la factoría devuelve un objeto que no tiene estado, se hace uso del patrón. Singleton. Factoría. Sql. Singleton y Sql.

El método getDao() es synchronized, esto significa que. Se pueden crear dos instancias d ela misma factoria a la vez. Se puedn crear 3 instancias de la misma factoria a la vez. No se pueden crear dos instancias de la misma factoria a la vez. No se pueden crear 3 instancias de la misma factoria a la vez.

En las referencias al propio servicio desde la Capa Cliente, para evitar que las capas superiores a la capa modelo no estén acopladas a la implementacion, se hace uso del patrón. Singleton. Factoría. Sql. Singleton y Sql.

Análogamente a los DAO, la factoría trata al servicio como una única instancia, por lo que usa el patrón. Singleton. Factoría. Sql. Singleton y Sql.

Para implementar las pruebas de integración se hace uso de:!. JUnit. TestUnit. JavaUnit. Ws-unit.