Dejo la presentación de una charla que estoy dando de introducción a SOA y BPM
Vida y obra de un desarrollador
miércoles, 7 de julio de 2010
sábado, 29 de mayo de 2010
JBoss Seam
En estos momentos me toca trabajar con este de JBoss, y debo decir que le tenía cierta desconfianza y lo prejuzgue anticipadamente.
Luego de participar en una presentación de Gavin King hace un par de años sobre este framework me había quedado la idea de que era poco flexible y apuntaba a resolver la problematica común de las aplicaciones web desde la perspectiva de JSF/EJB/JPA haciendolo así un fullstack framework.
Justamente por lo recien mencionado, me quedo la idea de que JBoss Seam, era solo JSF, EJBs como BackingBean que usan JPA directamente, lo cual no me parecia mal para aplicaciones simples y/o pequeñas, pero para grandes sistemas web no me cerraba sobre todo por el hecho de las capas, en este sentido Seam según mi visión en aquel momento, tenia 2 capas, la vista (con JSF components) o el negocio (EJB como backing beans) cerrando así la posibilidad de tener independencia entre las capas (presentación, negocio, persitencia, integración).
Definitivamente, ahora veo que tenía un pre concepto erróneo de lo que realmente es Seam principalmente porque uno de los features principales de Seam es la flexibilidad.
Encontre en JBoss Seam un framework que resuelve los problemas típicos de las aplicaciones web en una manera simple como por ejemplo:
i18n: Usando .properties
navegación: Usando un mecanismo que extiende al mecanismo de navegación estandar de JSF y que provee muchas mas opciones, como ser condiciones. También soporta pageflows usando un proceso jBPM.
contextos: además de los contextos clásicos agrega contextos muy utilies sobre todo el contexto CONVERSATION.
Manejo de excepciones y paginas de error: Facilita la administración de las excepciones y provee opciones de configuración para las páginas de error de la aplicación.
Manejo de mensajes: Facilita el manejo de mensajes por medio de extensiones al FacesMessage de JSF e inyección del mismo.
Validaciones: Usando Hibernate-Validator
Exportación a varios formatos.
Templating y layout de páginas: Usando Facelets.
Como features que me encontre con los siguientes:
Fuertemente basado en anotaciones (adiós XMLs gigantes) con una gran cantidad de las mismas que permiten configuraciones de las mas variadas.
Gran cantidad de tipos de componentes: Interceptores, Beans, Logger, manejadores de eventos, FacesMessages, IdentityStore, etc.
Bijection: Permite la clásica inyección y agrega la outyección (publicando en algún contexto por ejemplo) de objetos.
Componentes visuales: Permite utilizar frameworks de componentes visuales como RichFaces o ICEFaces. También provee tags especializados que facilitan muchas tareas.
JPA: integración directa con JPA. Inyección del EntityManager.
Seguridad: Presenta un modelo de autenticación y autorización completo basado en clases y anotaciones. Extensible usando componentes Seam.
SpringFramework: Integración con Spring permitiendo inyectar en componentes Seam Spring-beans y definir Spring-beans como componentes Seam
Otros features que no estoy usando: email, caching, remoting
Luego de ver todos estos beneficios y ventajas de usar JBoss Seam, debo concluir en que estaba completamente equivocado sobre todo por la flexibilidad dado que en la implementación del proyecto podríamos haber usado Seam de diferentes maneras:
1. Tal cual lo vi hace año: JSF/RichFaces + EJB (como BackingBeans) + JPA.
2. Usando las mismas tecnologías pero separandolas en capas: JSF/RichFaces + Seam components (presentación) + EJB (negocio) + EJB/DAO + JPA (persistencia).
3. o finalmente como lo implementamos usando JSF/Facelets/Richfaces como componentes para construir las interfaces de usuario (*.xhtml) haciendo un fuerte uso de AJAX, luego componentes Seam (clases simplemente anotadas con @Name) para implementar la lógica de presentación a las cuales se les inyecta un servicio de negocio implementado y configurado con Spring Framework. A su vez Spring tiene otros componentes configurados dentro de su container como ser los Repositories que nos abstraen del acceso a los datos, que en nuestro caso son implementaciones que utilizar Hibernate. Las clases de dominio se mapean al modelo relacional usando anotaciones JPA (y alguna que otra extension de Hibernate-Annotations).
Para concluir podría decir que Seam provee una framework interesante y simple para llevar adelante desarrollos de aplicaciones web en gran escala y desde mi (nuevo) punto de vista podría decir que es mi primera elección (a otro frameworks que he usado como ser SpringMVC, Struts o Wicket) a la hora de comenzar con un nuevo desarrollo web en Java.
Luego de participar en una presentación de Gavin King hace un par de años sobre este framework me había quedado la idea de que era poco flexible y apuntaba a resolver la problematica común de las aplicaciones web desde la perspectiva de JSF/EJB/JPA haciendolo así un fullstack framework.
Justamente por lo recien mencionado, me quedo la idea de que JBoss Seam, era solo JSF, EJBs como BackingBean que usan JPA directamente, lo cual no me parecia mal para aplicaciones simples y/o pequeñas, pero para grandes sistemas web no me cerraba sobre todo por el hecho de las capas, en este sentido Seam según mi visión en aquel momento, tenia 2 capas, la vista (con JSF components) o el negocio (EJB como backing beans) cerrando así la posibilidad de tener independencia entre las capas (presentación, negocio, persitencia, integración).
Definitivamente, ahora veo que tenía un pre concepto erróneo de lo que realmente es Seam principalmente porque uno de los features principales de Seam es la flexibilidad.
Encontre en JBoss Seam un framework que resuelve los problemas típicos de las aplicaciones web en una manera simple como por ejemplo:
Como features que me encontre con los siguientes:
Luego de ver todos estos beneficios y ventajas de usar JBoss Seam, debo concluir en que estaba completamente equivocado sobre todo por la flexibilidad dado que en la implementación del proyecto podríamos haber usado Seam de diferentes maneras:
1. Tal cual lo vi hace año: JSF/RichFaces + EJB (como BackingBeans) + JPA.
2. Usando las mismas tecnologías pero separandolas en capas: JSF/RichFaces + Seam components (presentación) + EJB (negocio) + EJB/DAO + JPA (persistencia).
3. o finalmente como lo implementamos usando JSF/Facelets/Richfaces como componentes para construir las interfaces de usuario (*.xhtml) haciendo un fuerte uso de AJAX, luego componentes Seam (clases simplemente anotadas con @Name) para implementar la lógica de presentación a las cuales se les inyecta un servicio de negocio implementado y configurado con Spring Framework. A su vez Spring tiene otros componentes configurados dentro de su container como ser los Repositories que nos abstraen del acceso a los datos, que en nuestro caso son implementaciones que utilizar Hibernate. Las clases de dominio se mapean al modelo relacional usando anotaciones JPA (y alguna que otra extension de Hibernate-Annotations).
Para concluir podría decir que Seam provee una framework interesante y simple para llevar adelante desarrollos de aplicaciones web en gran escala y desde mi (nuevo) punto de vista podría decir que es mi primera elección (a otro frameworks que he usado como ser SpringMVC, Struts o Wicket) a la hora de comenzar con un nuevo desarrollo web en Java.
martes, 30 de marzo de 2010
Vista Contextual y Diagrama conceptual
La vista contextual de una arquitectura de software es una de las primeras vistas que debe ser creada y se basa en información suministrada por el área de ingeniería de requerimientos o de alguna otra área que pueda realizar una descripción del sistema en alto nivel.
Este vista es la encargada de mostrar el sistema, las entidades externas con las cuales el sistema interactua (junto con sus interfaces) y las interfaces que el sistema presenta a dichas entidades externas. El objetivo es crear una única vista en donde se pueda capturar el sistemas y todas las entidades externas con sus interfaces.
Este vista puede ser usada como revisión de diseño de alto nivel del sistema, para iniciar el entendimiento de los subsistemas y capturar sus interfaces, para entrenamiento inicial del equipo o para comunicar los limites y las interfaces externas del sistema. Esta vista es útil también para iniciar discusiones dentro del equipo de arquitectura, diseño y desarrollo como así también con grupos externos que proveen o implementan las mencionadas interfaces externas.
Por otro lado puede ser necesario tener que comunicar los elementos del sistema y sus relaciones con sistemas externos en una forma no técnica o menos formal a otras áreas de la organización. Para ellos podemos utilizar un diagrama conceptual que muestra los diversos aspectos de un sistema de manera menos formal.
Este diagrama puede ser usado para comunicar la organización del sistema a áreas involucradas que no estén familiarizadas con diagramas UML (preferentemente equipos externos no relacionados con el desarrollo del sistema).
Básicamente, ambos intentan expresar y comunicar la misma idea solo que uno es parte de la descripción de la arquitectura y será utilizado para crear otras vistas de la arquitectura y el otro no.
Este vista es la encargada de mostrar el sistema, las entidades externas con las cuales el sistema interactua (junto con sus interfaces) y las interfaces que el sistema presenta a dichas entidades externas. El objetivo es crear una única vista en donde se pueda capturar el sistemas y todas las entidades externas con sus interfaces.
Este vista puede ser usada como revisión de diseño de alto nivel del sistema, para iniciar el entendimiento de los subsistemas y capturar sus interfaces, para entrenamiento inicial del equipo o para comunicar los limites y las interfaces externas del sistema. Esta vista es útil también para iniciar discusiones dentro del equipo de arquitectura, diseño y desarrollo como así también con grupos externos que proveen o implementan las mencionadas interfaces externas.
Por otro lado puede ser necesario tener que comunicar los elementos del sistema y sus relaciones con sistemas externos en una forma no técnica o menos formal a otras áreas de la organización. Para ellos podemos utilizar un diagrama conceptual que muestra los diversos aspectos de un sistema de manera menos formal.
Este diagrama puede ser usado para comunicar la organización del sistema a áreas involucradas que no estén familiarizadas con diagramas UML (preferentemente equipos externos no relacionados con el desarrollo del sistema).
Básicamente, ambos intentan expresar y comunicar la misma idea solo que uno es parte de la descripción de la arquitectura y será utilizado para crear otras vistas de la arquitectura y el otro no.
jueves, 4 de febrero de 2010
Arquitectura de Software. Definiciones
El término "Arquitectura de software" esta ampliamente difundido pero no siempre correctamente definido. Lo mismo sucede con muchos otros términos asociados a la arquitectura de software. Aquí se presentan algunas definiciones de estos términos a fin de aclarar un poco el panorama:
Según IEEE 1471:
Arquitectura: Es la organización fundamental de un sistema comprendido en sus componentes, en las relaciones entre ellos y con el ambiente, y los principio que guían su diseño y evolución.
Descripcion de arquitectura: Es un conjunto de productos que documentan la arquitectura.
Vista de arquitectura: Es la representación de un sistema o parte de un sistema desde una perspectiva en particular.
"Viewpoint" arquitectural: Es un template que describe como crear y usar una vista de arquitectura. Una vista es el resultado de aplicar una viewpoint a un sistema en particular.
System Architecture: Es un conjunto de entidades, sus propiedades y relaciones entre ellas, que definen la estructura de un sistema.
Software Architecture: Es un conjunto de componentes de software, subsistemas, relaciones, interacciones y propiedades de cada uno de estos elementos, y un conjunto de principios que constituyen las propiedades y limitaciones fundamentales de un sistema de software.
Software architecting: Refiere al análisis, diseño, documentación, revisión, aprobación, y otras actividades relacionadas con la definición y management de una arquitectura de software.
Arquitectura de Referencia: Refiere a una definición de una arquitectura para un dominio en particular. Describe en alto nivel un conjunto de elementos involucrados en aplicaciones pertenecientes al dominio. Estos elementos deben intencionalmente ser dejados en alto nivel para poder aplicar a un gran número de sistemas. Las arquitecturas de referencia ahorran mucho tiempo de trabajo de arquitectos de software durante el diseño de una nueva aplicación del mismo dominio, además de proveer un lenguaje común entre arquitectos y desarrolladores, lo cual facilita la comunicación.
Atributos de la arquitectura de software.
Cultural adaptability: Soporte a múltiples lenguajes y culturas
Security: Previene accesos no autorizados
Data integrity: El sistema no corrompe datos ni suministra datos inconsistentes.
Maintainability:
Testability: ¿El software puede ser testeado eficientemente?
Usability: Es la medida de eficacia para la interface humana del software
Operational:
Performance
Safety: El sistema no crea riesgos en el mundo real.
Según IEEE 1471:
Arquitectura: Es la organización fundamental de un sistema comprendido en sus componentes, en las relaciones entre ellos y con el ambiente, y los principio que guían su diseño y evolución.
Descripcion de arquitectura: Es un conjunto de productos que documentan la arquitectura.
Vista de arquitectura: Es la representación de un sistema o parte de un sistema desde una perspectiva en particular.
"Viewpoint" arquitectural: Es un template que describe como crear y usar una vista de arquitectura. Una vista es el resultado de aplicar una viewpoint a un sistema en particular.
System Architecture: Es un conjunto de entidades, sus propiedades y relaciones entre ellas, que definen la estructura de un sistema.
Software Architecture: Es un conjunto de componentes de software, subsistemas, relaciones, interacciones y propiedades de cada uno de estos elementos, y un conjunto de principios que constituyen las propiedades y limitaciones fundamentales de un sistema de software.
Software architecting: Refiere al análisis, diseño, documentación, revisión, aprobación, y otras actividades relacionadas con la definición y management de una arquitectura de software.
Arquitectura de Referencia: Refiere a una definición de una arquitectura para un dominio en particular. Describe en alto nivel un conjunto de elementos involucrados en aplicaciones pertenecientes al dominio. Estos elementos deben intencionalmente ser dejados en alto nivel para poder aplicar a un gran número de sistemas. Las arquitecturas de referencia ahorran mucho tiempo de trabajo de arquitectos de software durante el diseño de una nueva aplicación del mismo dominio, además de proveer un lenguaje común entre arquitectos y desarrolladores, lo cual facilita la comunicación.
Atributos de la arquitectura de software.
- Portability: ¿Puede el software ser portado a otras plataformas?
- Changeability: Habilidad para agregar nuevas funciones y modificar funcionalidad existente
- Fragility: pequeños cambios tienden a romper funcionalidad existentes
- Rigidity: el software es difícil de modificar incluso cambios simples.
- Duplication: el software con duplicación es mas difícil de mantener porque es grande y porque el cambio no es localizado.
- Understandability: ¿Puede el software ser entendido de manera que sea facil realizar cambios?
- Debugging: ¿El software soporta debugging?
- Availability: Porcentaje de tiempo en el que el sistema esta funcionando.
- Manageability: Habilidad para inspeccionar y manejar componentes en ejecución
- Upgradeability: ¿Puede el software ser actualizado mientras ejecuta?
- Reliability: Habilidad para ejecutar funciones requeridas en un periodo de tiempo especificado.
- Recoverability: Tiempo requerido para recuperarse de una falla.
- Response: ¿Es la respuesta suficientemente rápida para escenarios de uso normal y extremo?
- Scalability: La capacidad del sistema puede ser incrementada si es necesario?
- Capacity/Throughput: Manejar grandes cargas y aún mantener la respuesta
Suscribirse a:
Entradas (Atom)