Tema 4: Uso de Spring en la Capa Modelo

Transcripción

1 Tema 4: Uso de Spring en la Capa Modelo

2 Índice Introducción a Spring Declaración y Configuración de beans Excepciones de Persistencia Declaración de DataSources Integración con Hibernate 4 Gestión de Transacciones 4-2

3 Qué es Spring? Framework de código abierto creado por Rod Johnson Motivación: facilitar el desarrollo de aplicaciones Java EE, promoviendo buenas prácticas de diseño y programación Simplifica el uso de muchas de las APIs de Java EE Dispone de alternativas a algunas de las APIs de Java EE Internamente se apoyan en APIs de Java EE de más bajo nivel Soporte para capa modelo e interfaz Web Es modular: es posible usar algunos de los módulos sin comprometerse con el uso del resto Nosotros utilizaremos fundamentalmente el soporte de Spring para implementar casos de uso a nivel de capa modelo Inyección de dependencias Gestión declarativa de transacciones (mediante AOP) 4-3

4 Módulos/Paquetes (1) DAO Spring JDBC Transaction management ORM Hibernate JPA JDO TopLink OJB ibatis AOP Spring AOP Integración AspectJ JEE JMX JMS JCA Remotig EJBs Web Spring Web MVC Framework Integration Struts WebWork Tapestry JSF Rich View Support JSPs Velocity FreeMarker PDF Jasper Reports Excel Spring Portlet MVC Core IoC Container 4-4

5 Módulos/Paquetes (2) Core DAO Constituye la parte fundamental del framework y proporciona la característica de Inyección de Dependencias (DI) / Inversión de Control (IoC) Proporciona una manera de gestionar transacciones tanto programática como declarativamente También proporciona una capa de abstracción sobre JDBC que elimina la necesidad de codificar y analizar los códigos de error específicos de cada BBDD 4-5

6 Módulos/Paquetes (y 3) ORM AOP Proporciona capas de integración para las APIs de mapeadores objeto-relacionales más populares: Hibernate, JPA, JDO, ibatis Utilizando este paquete es posible utilizar cualquiera de estos mapeadores objeto-relacionales en combinación con las demás características que ofrece Spring (como por ejemplo con la gestión declarativa de transacciones) Proporciona una implementación del paradigma de la programación orientada a aspectos (conforme a la AOP Alliance), que es utilizada, transparentemente para el programador, por otros paquetes de Spring, pero que también puede ser usada directamente 4-6

7 El Contenedor (1) El contenedor de IoC es el núcleo del sistema Responsable de la creación y configuración de los Beans Nota: Un bean, en el contexto de Spring, es un POJO que es creado y manejado por el contenedor de IoC La interfaz BeanFactory o sus descendientes ListableBeanFactory y ApplicationContext representan la interfaz del contenedor Spring proporciona varias implementaciones E.g. ClassPathXmlApplicationContext 4-7

8 El Contenedor (2) Instanciación try { ApplicationContext ctx = new ClassPathXmlApplicationContext( new String[] {SPRING_CONFIG_FILE, SPRING_CONFIG_TEST_FILE}); AccountService accountservice = ctx.getbean(accountservice.class);... } catch (Exception e) { e.printstacktrace(); } 4-8

9 El Contenedor (y 3) ClassPathXmlApplicationContext Permite declarar los objetos que componen la aplicación, y las dependencias entre ellos en XML A partir de los metadatos de configuración en XML es capaz de crear y configurar los objetos que componen la aplicación Tiene métodos que permiten obtener referencias a los objetos declarados, a partir de su tipo o nombre. Algunos son T getbean(class<t> requiredtype) Devuelve un bean del tipo indicado solamente si hay exactamente uno de ese tipo. En otro caso lanza una excepción Object getbean(string name) Devuelven el bean que tiene el nombre indicado T getbean(string name, Class<T> requiredtype) Equivalente al anterior pero además proporciona type safety y lanza una excepción si el bean no es del tipo indicado 4-9

10 Declaración de Beans en XML (1) <bean id="datasource" class="org.springframework.jdbc.datasource.drivermanagerdatasource" p:driverclassname="com.mysql.jdbc.driver" p:url="jdbc:mysql://localhost/pojo" p:username="pojo" p:password="pojo" /> <bean id="accountservice" class="es.udc.pojo.minibank.model.accountservice.accountserviceimpl" p:accountdao-ref="accountdao" p:accountoperationdao-ref="accountoperationdao" /> Es equivalente a <bean id="datasource" class="org.springframework.jdbc.datasource.drivermanagerdatasource" > <property name="driverclassname" value="com.mysql.jdbc.driver" /> <property name="url" value="jdbc:mysql://localhost/pojo" /> <property name="username" value="pojo" /> <property name="password" value="pojo" /> </bean> <bean id="accountservice" class="es.udc.pojo.minibank.model.accountservice.accountserviceimpl" > <property name="accountdao" ref="accountdao" /> <property name="accountoperationdao" ref="accountoperationdao" /> </bean> 4-10

11 Declaración de Beans en XML (2) Se declaran con la etiqueta bean Parámetros básicos id: Nombre o identificador del bean class: Clase de implementación del bean Inyección de dependencias basada en setters Permite inyectar valores u otros beans (a través de referencias), invocando al método set correspondiente del bean sobre el que se está realizando la inyección Se indica el nombre de la propiedad que se desea inyectar y el valor que se le desea proporcionar 4-11

12 Declaración de Beans en XML (y 3) Inyección de dependencias basada en setters (cont) Es posible especificarlas A través de un elemento anidado property, que acepta los siguientes atributos name: Nombre de la propiedad donde se desea inyectar el valor value: Para inyectar un valor constante ref: Para inyectar otro bean a partir de su nombre Con sintaxis abreviada (utilizando el espacio de nombres p) a través de los atributos p:nombrepropiedad: Para inyectar un valor constante en la propiedad indicada p:nombrepropiedad-ref: Para inyectar otro bean a partir de su nombre en la propiedad indicada El bean se crea a partir de su constructor vacío y a continuación se invocan los métodos set con los valores adecuados 4-12

13 Declaración de Beans Usando Anotaciones public class AccountDaoHibernate extends GenericDaoHibernate<Account, Long> implements AccountDao {... public class AccountOperationDaoHibernate extends GenericDaoHibernate<AccountOperation, Long> implements AccountOperationDao {... public class AccountServiceImpl implements AccountService {... } 4-13

14 Declaración de Beans Usando Anotaciones (2) Spring proporciona un mecanismo para detectar automáticamente clases anotadas y registrarlas como beans en el ApplicationContext Se puede utilizar la anotación sobre cualquier clase, o para anotar clases en las capas de persistencia, servicios y vista respectivamente La documentación de Spring aconseja utilizar las especializaciones porque otros frameworks o herramientas pueden aplicarles semántica especial y el propio Spring puede añadírsela en futuras versiones Si la anotación contiene el atributo value, entonces el valor de ese atributo será el que dé nombre al bean; en otro caso, se le dará el mismo nombre que la clase pero empezando por minúscula NOTA: Si una anotación sólo tiene un parámetro y se llama value, no hace falta basta 4-14

15 Declaración de Beans Usando Anotaciones (y 3) Spring proporciona un mecanismo para detectar automáticamente clases anotadas y registrarlas como beans en el ApplicationContext (cont) Además debe utilizarse el tag component-scan en el fichero de configuración de Spring indicando en el atributo base-package el o los paquetes (separados por comas) que incluyen las clases anotadas (puede ser un paquete padre, no es necesario que sean los paquetes que contienen las clases directamente) <beans xmlns=" xmlns:context=" xsi:schemalocation="... ">... <context:component-scan base-package="es.udc.pojo.minibank.model"/>... </beans> 4-15

16 Auto-inyección de Dependencias El contenedor de Spring es capaz de auto-inyectar dependencias entre beans según diferentes criterios Por tipo: Busca un bean con el mismo tipo que la propiedad Por nombre: Busca un bean con el mismo id que la propiedad Por constructor: Busca uno o más beans cuyos tipos coincidan con los parámetros de uno de los constructores de ese bean Cuando se usan metadatos de configuración en XML, la autoinyección de dependencias se especifica a través del atributo autowire de la etiqueta <bean/> También es posible realizar auto-inyección de dependencias utilizando la Ventajas La cantidad de configuración necesaria puede verse reducida significativamente, y también las necesidades de cambios en dicha configuración según avanza el desarrollo Desventajas Las relaciones entre los beans dejan de estar documentadas explícitamente Si hay varios beans con el mismo tipo no puede utilizarse la autoinyección por tipo (que es la que suele utilizarse) 4-16

17 Auto-Inyección de Dependencias Usando Anotaciones public class AccountServiceImpl implements AccountService { private AccountDao private AccountOperationDao accountoperationdao;

18 Auto-Inyección de Dependencias Usando Anotaciones (y 2) La puede ser aplicada a setters, pero también a métodos con nombres arbitrarios y múltiples argumentos, a constructores y a propiedades Por defecto la auto-inyección se realiza por tipo y si no hay ningún bean que la satisfaga entonces se produce un error Para poder utilizar esta anotación es necesario especificar la etiqueta annotation-config en el fichero de configuración de Spring <beans xmlns=" xmlns:context=" xsi:schemalocation="... ">... <context:annotation-config/>... </beans> 4-18

19 Beans de la capa modelo de MiniBank (pojo-minibank-spring-config.xml) <?xml version="1.0" encoding="utf-8"?> <beans xmlns=" xmlns:xsi=" xmlns:context=" xsi:schemalocation="..."> <!-- Enable usage --> <context:annotation-config/> <!-- Enable component scanning for defining beans with annotations. --> <context:component-scan base-package="es.udc.pojo.minibank.model"/>... <!-- Hibernate Session Factory --> <bean id="sessionfactory" class="org.springframework.orm.hibernate4.localsessionfactorybean"... />... </beans> 4-19

20 public class AccountServiceImpl implements AccountService { private AccountDao private AccountOperationDao accountoperationdao;

21 AccountDaoHibernate.java y public class AccountDaoHibernate extends GenericDaoHibernate<Account, Long> implements AccountDao { public class AccountOperationDaoHibernate extends GenericDaoHibernate<AccountOperation, Long> implements AccountOperationDao { }

22 GenericDaoHibernate.java public class GenericDaoHibernate<E, PK extends Serializable> implements GenericDao<E, PK> { } private SessionFactory public void setsessionfactory(sessionfactory sessionfactory) { this.sessionfactory = sessionfactory; }

23 Beans de la capa modelo de MiniBank Declaración: Se declaran los siguientes beans de usuario mediante anotaciones Un bean para cada DAO de Hibernate Un bean para la implementación del servicio Se declara un bean en XML para la SessionFactory (que usan los DAOs de Hibernate) Inyección de dependencias Las dependencias entre los beans se auto-inyectan mediante anotaciones La implementación del servicio usa los DAOs Se inyectan directamente sobre las propiedades privadas que los referencian y por tanto no son necesarios los setters Los DAOs usan la SessionFactory Se inyecta en GenericDaoHibernate sobre el setter correspondiente (el setter es necesario ya que es invocado desde las clases de prueba) 4-23

24 Beans: Inyección de Dependencias accountdao AccountDaoHibernate - sessionfactory : SessionFactory accountservice AccountServiceImpl - accountdao : AccountDao - accountoperationdao : AccountOperationDao sessionfactory accountoperationdao AccountOperationDaoHibernate - sessionfactory : SessionFactory 4-24

25 Ámbito de los Beans El ámbito de un bean se especifica a través del atributo scope de la etiqueta bean o a través de la (según se use configuración XML o basada en anotaciones) Algunos posibles valores son: singleton (valor por defecto) El contenedor usa siempre la misma instancia (ya sea cuando se le pide a través de la API o cuando necesita inyectarlo) prototype Indica que el contenedor debe crear una nueva instancia del bean cada vez que se precise una Puede ser necesario, por ejemplo, si el bean tiene estado OJO con los beans de tipo singleton con dependencias con beans de tipo prototype 4-25

26 Excepciones de Persistencia (1) En JDBC se lanza la excepción java.sql.sqlexception cuando se produce cualquier tipo de error en el acceso a los datos Problema: Hay que capturarla siempre y analizarla para saber de qué tipo de error se trata Algunos frameworks (e.g. Hibernate) ofrecen una jerarquía de excepciones más descriptiva (una excepción diferente para cada tipo de error) Ventaja: Permite diferenciar entre qué tipos de errores capturar Problema: Son específicas del framework utilizado para realizar la persistencia de los datos 4-26

27 Excepciones de Persistencia (y 2) Spring proporciona una jerarquía de excepciones de acceso a datos (heredan de DataAccessException) que resuelve ambos problemas Cada excepción representa un error concreto No son específicas del framework de persistencia de datos utilizado, que por tanto se oculta a las capas superiores Son excepciones unchecked Spring proporciona mecanismos para realizar la conversión entre las excepciones nativas del framework de persistencia utilizado y la jerarquía propia Para que Spring realice automáticamente la conversión, en clases anotadas es suficiente con declarar el siguiente bean en el fichero de configuración <bean class= "org.springframework.dao.annotation.persistenceexceptiontranslationpostprocessor"/> 4-27

28 DataSources Independientemente del framework de persistencia utilizado probablemente se necesitará configurar una referencia a un DataSource Spring proporciona, entre otras, las siguientes opciones para configurar un bean de tipo DataSource DataSources definidos directamente sobre un driver JDBC SingleConnectionDataSource DriverManagerDataSource DataSources que son localizados vía JNDI Cualquier contenedor Java EE puede poner accesible vía JNDI un DataSource (que normalmente implementará pool de conexiones) 4-28

29 SingleConnectionDataSource Cuando se crea, solicita una conexión a la base de datos El método getconnection siempre devuelve esa conexión (o un proxy) Este DataSource sólo es válido para entornos single-thread Es usual especificar suppressclose="true" para que devuelva un proxy de la conexión cuyo método close (el del proxy) no cierra la conexión Un DataSource con estas características es suficiente y eficiente para los tests de integración Suficiente: llega con disponer de una conexión Eficiente: la conexión a la base de datos sólo se pide cuando se crea el DataSource Además, hay que indicar también las siguientes propiedades El nombre de la clase del driver JDBC La URL de conexión a la BD El usuario para conectarse a la BD La contraseña del usuario indicado <bean id="datasource" class="org.springframework.jdbc.datasource.singleconnectiondatasource" p:driverclassname="com.mysql.jdbc.driver" p:url="jdbc:mysql://localhost/pojotest" p:username="pojo" p:password="pojo" p:suppressclose="true" /> 4-29

30 DriverManagerDataSource Implementación simple de la interfaz DataSource No implementa pool de conexiones El método getconnection devuelve una conexión nueva cada vez que es invocado Válido para entornos multi-thread Un DataSource con estas características es suficientemente eficiente y seguro para probar una aplicación Web a nivel de usuario Hay que indicar las siguientes propiedades El nombre de la clase del driver JDBC La URL de conexión a la BD El usuario para conectarse a la BD La contraseña del usuario indicado Es el que usamos con el plugin de Jetty para Maven (src/main/jetty/jetty-env.xml) 4-30

31 Acceso a DataSources mediante JNDI (1) JNDI (Java Naming and Directory Interface) Familia de paquetes javax.naming (Java SE) Es una API que abstrae el acceso a un servicio de nombres y directorios (e.g. LDAP) Es posible registrar objetos mediante un nombre jerárquico Los servidores de aplicaciones Java EE exponen diversos objetos mediante JNDI Los servidores de aplicaciones Java EE proporcionan implementaciones de DataSource Cada objeto DataSource es accesible a partir de un nombre JNDI de la forma java:comp/env/xxx/yyy, donde XXX suele (recomendado) ser jdbc e YYY el nombre de un DataSource concreto Habitualmente estos objetos DataSource implementan la estrategia de pool de conexiones Requiere configuración en el servidor (driver, URL, usuario, contraseña, parámetros específicos al pool, etc.) Ej.: En Tomcat se definen en conf/server.xml 4-31

32 Acceso a DataSources mediante JNDI (y 2) <bean id="datasource" class="org.springframework.jndi.jndiobjectfactorybean" p:jndiname="jdbc/pojo-examples-ds" p:resourceref="true" /> El atributo jndiname se utiliza para indicar el nombre del recurso accesible vía JNDI Si la aplicación está ejecutándose dentro de un servidor de aplicaciones Java EE El valor del atributo resourceref debe ser true El nombre indicado en jndiname es relativo al contexto java:comp/env/ JndiObjectFactoryBean implementa org.springframework.beans.factory.factorybean Los beans que implementan esta interfaz se definen igual que el resto de beans, pero cuando se referencian desde otros beans no se inyecta una instancia de ese tipo sino el objeto que devuelve su método getobject El método getobject de JndiObjectFactoryBean devuelve el objeto asociado al nombre JNDI especificado en la configuración 4-32

33 Integración con Hibernate 4 (1) Los DAOs implementados con Hibernate necesitan un objeto de tipo org.hibernate.sessionfactory del que obtener la sesión actual Como veremos más adelante, el gestor de transacciones de Hibernate también precisa un objeto de ese tipo La siguiente declaración permite definir un bean para obtener un SessionFactory que utiliza las anotaciones de Hibernate en las entidades <bean id="sessionfactory" class="org.springframework.orm.hibernate4.localsessionfactorybean" p:datasource-ref="datasource" p:configlocation="classpath:/pojo-minibank-hibernate-config.xml"/> datasource: indica el nombre de un bean de tipo DataSource (para obtener las conexiones a la BD) configlocation: Indica donde está el fichero de configuración de Hibernate (fichero llamado pojo-minibank-hibernateconfig.xml localizado en el classpath de ejecución) LocalSessionFactoryBean es un FactoryBean (igual que la clase JndiObjectFactoryBean explicada en la transparencia anterior) cuyo método getobject devuelve una instancia que implementa SessionFactory 4-33

34 Integración con Hibernate 4 (2) Como ya hemos visto con anterioridad el bean sessionfactory se inyecta en el DAO genérico public class GenericDaoHibernate<E, PK extends Serializable> implements GenericDao<E, PK> { } private SessionFactory public void setsessionfactory(sessionfactory sessionfactory) { this.sessionfactory = sessionfactory; }

35 Integración con Hibernate 4 (3) Fichero de configuración de Hibernate: pojominibank-hibernate-config.xml <hibernate-configuration> <session-factory> <property name="hibernate.dialect">org.hibernate.dialect.mysqldialect</property> <property name="hibernate.show_sql">true</property> <property name="hibernate.format_sql">true</property> <property name="hibernate.use_sql_comments">true</property> <mapping class="es.udc.pojo.minibank.model.account.account" /> <mapping class="es.udc.pojo.minibank.model.accountoperation.accountoperation" /> </session-factory> </hibernate-configuration> 4-35

36 Integración con Hibernate 4 (y 4) Fichero de configuración de Hibernate: pojominibank-hibernate-config.xml (cont) No contiene la configuración de la BD/pool porque al SessionFactory inyectado por Spring en el DAO genérico ya se le ha inyectado un DataSource Cuando se ejecuta la aplicación en un servidor de aplicaciones, se utiliza el DataSource (accesible vía JNDI) proporcionado por el servidor de aplicaciones Cuando se ejecutan las pruebas se utiliza un DataSource de tipo SingleConnectionDataSource declarado en el fichero de configuración de Spring para pruebas (pojo-minibankspring-config-test.xml) que sobrescribe al anterior No se utiliza la siguiente propiedad porque el SessionFactory inyectado por Spring en el DAO genérico ya implementa esa semántica <property name="current_session_context_class">thread</property> 4-36

37 Transacciones Spring no gestiona directamente las transacciones, sino que lo hace a través de una abstracción (patrón Strategy) Interfaz org.springframework.transaction.platformtransactionmanager Se puede trabajar con las transacciones independientemente de la implementación del gestor de transacciones concreto que se esté utilizando Spring proporciona una serie de gestores de transacciones que delegan la responsabilidad de la gestión de las transacciones a implementaciones específicas de la plataforma utilizada Se puede trabajar con transacciones a través de la API Java de Spring, pero también se pueden definir de forma declarativa haciendo uso del framework AOP de Spring, que incluye una implementación del aspecto de transaccionalidad Es posible hacerlo mediante XML o mediante anotaciones Java Utilizaremos la opción de las anotaciones porque simplifica la declaración de las transacciones 4-37

38 Transacciones con Hibernate 4 Si la capa de persistencia del modelo está implementada con Hibernate, entonces el gestor de transacciones a utilizar es el siguiente <bean id="transactionmanager class="org.springframework.orm.hibernate4.hibernatetransactionmanager" p:sessionfactory-ref="sessionfactory" /> Es preciso inyectarle un objeto SessionFactory de Hibernate Ya hemos declarado uno para utilizar en los DAOs HibernateTransactionManager delega la gestión de las transacciones a un objeto org.hibernate.transaction A partir del objeto SessionFactory obtiene la sesión Hibernate A partir de la sesión Hibernate obtiene el objeto Transaction 4-38

39 API Transacciones (1) public interface PlatformTransactionManager { TransactionStatus gettransaction(transactiondefinition definition) throws TransactionException; void commit(transactionstatus status) throws TransactionException; } void rollback(transactionstatus status) throws TransactionException; 4-39

40 API Transacciones (y 2) Un gestor de transacciones implementa la interfaz PlatformTransactionManager TransactionException es una excepción unchecked El método gettransaction devuelve un objeto de tipo TransactionStatus en función de un parámetro de tipo TransactionDefinition TransactionStatus es una interfaz que representa una transacción Puede ser la transacción actual o una nueva TransactionDefinition es una interfaz a través de la cual se pueden especificar las características de la transacción que se quiere obtener (propagación, nivel de aislamiento, timeout, propiedad read-only) Si se pasa null en gettransaction, se utilizan los valores por defecto Los métodos commit y rollback se utilizan para hacer un commit o un rollback de la transacción que se les pasa 4-40

41 AOP: Gestión de Transacciones public class AccountServiceImpl implements AccountService private PlatformTransactionManager private AccountDao private AccountOperationDao accountoperationdao; 4-41

42 AOP: Gestión de Transacciones (2) public Account createaccount(account account) { TransactionStatus transactionstatus = transactionmanager.gettransaction(null); Iniciar transacción try { accountdao.save(account); transactionmanager.commit(transactionstatus); } catch (RuntimeException Error e) { transactionmanager.rollback(transactionstatus); } throw e; Finalizar transacción return account; } 4-42

43 AOP: Gestión de Transacciones (3) public void removeaccount(long accountid) throws InstanceNotFoundException { TransactionStatus transactionstatus = transactionmanager.gettransaction(null); Iniciar transacción try { accountdao.remove(accountid); accountoperationdao.removebyaccountid(accountid); transactionmanager.commit(transactionstatus); } catch (RuntimeException Error e) { transactionmanager.rollback(transactionstatus); throw e; } catch (InstanceNotFoundException e) { transactionmanager.commit(transactionstatus); throw e; } Finalizar transacción } 4-43

44 AOP: Gestión de Transacciones (4) public void withdrawfromaccount(long accountid, double amount) throws InstanceNotFoundException, InsufficientBalanceException { TransactionStatus transactionstatus = transactionmanager.gettransaction(null); Iniciar transacción try { /* Find account. */ Account account = accountdao.find(accountid); /* Modify balance. */ double currentbalance = account.getbalance(); if (currentbalance < amount) { throw new InsufficientBalanceException(accountId, currentbalance,amount); } account.setbalance(currentbalance - amount); 4-44

45 AOP: Gestión de Transacciones (5) /* Register account operation. */ accountoperationdao.save(new AccountOperation(account, Calendar.getInstance(), AccountOperation.Type.WITHDRAW, amount)); transactionmanager.commit(transactionstatus); } catch (RuntimeException Error e) { transactionmanager.rollback(transactionstatus); throw e; } catch (InstanceNotFoundException InsufficientBalanceException e) { transactionmanager.commit(transactionstatus); throw e; } Finalizar transacción }... } 4-45

46 AOP: Gestión de Transacciones (6) El código para todos los casos de uso transaccionales es similar: Iniciar la transacción (con las propiedades adecuadas) a partir del gestor de transacciones utilizado Ejecutar la lógica propia del caso de uso Finalizar transacción (commit o rollback) en función de si se ha producido alguna excepción o no y de su tipo El código común para la gestión de las transacciones puede eliminarse de la implementación de todos los casos de uso que lo precisen, y declarativamente decir cuándo debe ejecutarse 4-46

47 AOP: Gestión de Transacciones (y 7) Declarativamente es posible indicar El gestor de transacciones a utilizar Que los métodos createaccount, removeaccount, withdrawfromaccount y todos los demás de la clase AccountServiceImpl son transaccionales Spring intercepta las invocaciones a los métodos declarados como transaccionales: [Antes de que se ejecute el método] Ejecuta el código necesario para comenzar la transacción Declarativamente pueden indicarse parámetros como, por ejemplo, el nivel de aislamiento deseado para la transacción [Después de que se ejecute el método] Ejecuta el código necesario para finalizar la transacción (ya sea con un commit o un rollback) Pueden indicarse qué excepciones deben provocar un rollback y cuales no 4-47

48 public class AccountServiceImpl implements AccountService private AccountDao private AccountOperationDao accountoperationdao; public Account createaccount(account account) {... = true) public Account findaccount(long accountid) throws InstanceNotFoundException {... } public void addtoaccount(long accountid, double amount) throws InstanceNotFoundException {... } 4-48

49 AccountServiceImpl.java (2) public void withdrawfromaccount(long accountid, double amount) throws InstanceNotFoundException, InsufficientBalanceException { } /* Find account. */ Account account = accountdao.find(accountid); /* Modify balance. */ double currentbalance = account.getbalance(); if (currentbalance < amount) { throw new InsufficientBalanceException(accountId, currentbalance,amount); } account.setbalance(currentbalance - amount); /* Register account operation. */ accountoperationdao.save(new AccountOperation(account, Calendar.getInstance(), AccountOperation.Type.WITHDRAW, amount)); 4-49

50 AccountServiceImpl.java = true) public AccountBlock findaccountsbyuserid(long userid, int startindex, int count) {... } public void removeaccount(long accountid) throws InstanceNotFoundException {... } public void transfer(long sourceaccountid, Long destinationaccountid, double amount) throws InstanceNotFoundException, InsufficientBalanceException {... = true) public int getnumberofaccountoperations(long accountid, Calendar startdate, Calendar enddate) throws InstanceNotFoundException {... = true) public List<AccountOperation> findaccountoperationsbydate( Long accountid, Calendar startdate, Calendar enddate, int startindex, int count) throws InstanceNotFoundException {... } } 4-50

51 Transacciones con Anotaciones Si se desean utilizar anotaciones para declarar las transacciones, el gestor de transacciones a utilizar se declara a través de la etiqueta annotation-driven, perteneciente al espacio de nombres tx <tx:annotation-driven transaction-manager="transactionmanager" /> El valor del atributo transaction-manager indica el nombre del bean que debe ser utilizado como gestor de transacciones Este atributo es opcional, y si no está presente toma el valor por defecto transactionmanager Por tanto en nuestro caso podríamos no haberlo especificado 4-51

52 (1) Puede utilizarse para anotar una clase o un método concreto En una clase se aplica a todos los métodos que contiene En un método sobrescribe el comportamiento especificado para la clase a la que pertenece Propiedades: propagation: Permite especificar la semántica de la creación de la transacción El enumerado org.springframework.transaction.annotation.prop agation define diversos valores Por defecto toma el valor Propagation.REQUIRED: el método debe ejecutarse dentro de una transacción; si ya existe una, se ejecuta en esa, y si no, se crea una nueva 4-52

53 (2) Propiedades (cont.): isolation: Nivel de aislamiento Isolation.DEFAULT (valor por defecto): El de la plataforma Isolation.READ_UNCOMMITED: Pueden ocurrir dirty reads, non-repeatable reads y phanton reads Isolation.READ_COMMITED: Pueden ocurrir nonrepeatable reads y phamton reads Isolation.REPETEABLE_READ: Pueden ocurrir phanton reads Isolation.SERIALIZABLE: Elimina todos los problemas de concurrencia readonly: Lectura/escritura (defecto) o solo lectura Importante indicarlo para poder hacer optimizaciones!! timeout: Timeout de la transacción (por defecto el de la plataforma) Si el timeout expira entonces se hace un rollback de la transacción 4-53

54 (y 3) Por defecto cualquier excepción de tipo unchecked (hija de RuntimeException) provocará un rollback, y cualquier excepción checked (hija de Exception) no Es posible modificar este comportamiento a través de propiedades de la rollbackfor: array de excepciones que deben causar un rollback Exception2.class}) norollbackfor: array de excepciones que no deben causar un rollback La utilizaremos en los servicios del modelo para declarar la transaccionalidad de sus métodos Es posible anotar la interfaz que declara las operaciones del servicio, pero es más recomendable anotar la clase de implementación del servicio 4-54

55 Invocación de casos de uso Clase WithdrawFromAccount Paquete es.udc.pojo.minibank.test.experiments.spring Ilustra cómo obtener una referencia a un servicio implementado con Spring y llamar a un caso de uso... try { /* Get service object. */ ApplicationContext ctx = new ClassPathXmlApplicationContext( new String[] {SPRING_CONFIG_FILE, SPRING_CONFIG_TEST_FILE}); AccountService accountservice = ctx.getbean(accountservice.class); accountservice.withdrawfromaccount(accountid, amount); } catch (InstanceNotFoundException e) { e.printstacktrace(); } catch (InsufficientBalanceException e) { e.printstacktrace(); }

56 Implementación de Servicios (1) Los casos de uso se implementan en términos de DAOs (tal como se vio en el tema 2) En los DAOs se inyecta un objeto de tipo org.hibernate.sessionfactory creado por Spring (al que a su vez se le inyecta un DataSource) Los DAOs se inyectan en la clase de implementación del Servicio Se utiliza un mecanismo proporcionado por Spring para convertir las excepciones de persistencia nativas a una jerarquía propia, independiente del framework utilizado para la persistencia 4-56

57 Implementación de Servicios (y 2) Para indicar la transaccionalidad de los casos de uso utilizamos la sobre la clase de implementación del Servicio Se declara un gestor de transacciones que delega en el gestor de transacciones de Hibernate Se le inyecta el mismo SessionFactory que el creado para inyectar en los DAOs, para que pueda acceder a través de él al gestor de transacciones de Hibernate La implementación de los Servicios es independiente del software utilizado para el acceso a datos (en nuestro caso Hibernate) 4-57