Arquitectura de Software - Stakeholders

Retomando las sobre notas arquitectura de software (ver otras notas abajo), en esta ocación voy a hablar de los stakeholders.

Los stakeholders (interesados) son todas aquellas personas o entidades que tienen alguna participación, injerencia o interés en el sistema. Ejemplo de stakeholders son: usuarios del sistema, programadores, diseñadores, dueño del producto, organizaciones con las cuales el sistema interactúa, gerente de la Software Factory, organización que desarrolla el sistema, etc. Cada uno de ellos tiene diferentes preocupaciones y necesidades y esperan que sean satisfechas o aun mejor, que sean óptimas.

Una de las tareas más importantes del arquitecto de software es poder lograr identificar con la mayor precisión posible el conjunto de stakeholders antes de comenzar a construir y diseñar la arquitectura, dado que estos producen un impacto directo sobre el sistema y en particular sobre la arquitectura. La correcta ejecución de esta tarea no es responsabilidad única del arquitecto de software, sino que debe trabajar conjuntamente con ingenieros a cargo de la ingeniería de requerimientos. Dicho esto, queda claro que los stakeholders influyen y restringen en las decisiones que un arquitecto debe tomar. La arquitectura de un sistema está influenciada por aspectos técnicos, por el negocio y por el contexto social que lo rodea. Así los stakeholders competirán entre sí, principalmente porque cada uno de ellos querrá que el arquitecto le de prioridad a sus necesidades y que la arquitectura tenga determinadas características que él desea, por sobre las que otros stakeholders.

Ejemplo:

Stakeholder	Intereses
Cliente	Costo, Calidad, Vida del proyecto, Posibilidad de hacer cambios
Usuarios	Facilidades de uso del sistema, seguridad, Personalización, configuración, etc.
Proveedor del sistema	Ganancia y amortización de los costos, adherencia a los procesos internos, calidad, reusabilidad.
Desarrolladores	Conocer la arquitectura, estándares de desarrollo y componentes reusables. Facilidades para hacer cambios.
Administrador del sistema	Simple configuración, monitoreo o administración de los servicios, disponibilidad, escalabilidad.

El arquitecto deberá siempre, en la medida de sus posibilidades, consensuar con los stakeholders las necesidades reales y compensarlas para lograr obtener un conjunto de características que por un lado deje contentos a todos los stakeholders y por otro permita construir la mejor arquitectura posible.

En este sentido las tareas que un arquitecto debe realizar son:

1. Entender las reales restricciones del sistema. 
2. Manejar las expectativas de los stakeholders. 
3. Negociar las prioridades del sistema. 
4. Identificar conflictos.

Otros notas: Vista Contextual y Diagrama conceptual
Definiciones básicas

Install BonitaBPM Community 6.1.1 on JBoss AS 7.1.1

Installation

Download JBoss AS 7.1.1 from JBoss site.

I downloaded jboss-as-7.1.1.Final.zip file

Download BonitaBPM 6.1.1 from BonitaSoft site

I downloaded the Bonita BPM Deployment bundle for JBoss 5.1 (BonitaBPMCommunity-6.1.1-JBoss-5.1.0.GA.zip file)

Note: you can download all the configuration files listed in this tutorial here

Unzip the jboss-as-7.1.1.Final.zip into a folder. In this tutorial I use: c:\opt\jboss-as-7.1.1.Final. This folder will be called as $JBOSS_HOME

Unzip the BonitaBPMCommunity-6.1.1-JBoss-5.1.0.GA.zip. In this tutorial I use: c:\opt\BonitaBPMCommunity-6.1.1-JBoss-5.1.0.GA.

Configuration

Copy the folder: "c:\opt\BonitaBPMCommunity-6.1.1-JBoss-5.1.0.GA\bonita" into $JBOSS_HOME.

Create the user (and schema) to Bonita in Oracle. Execute the following script (you must be logged as sysdba)

DROP user bonita cascade;
CREATE USER bonita IDENTIFIED BY bonita;
GRANT connect, resource TO bonita IDENTIFIED BY bonita;
GRANT select ON sys.dba_pending_transactions TO bonita;
GRANT select ON sys.pending_trans$ TO bonita;
GRANT select ON sys.dba_2pc_pending TO bonita;
GRANT execute ON sys.dbms_system TO bonita;

Note: BonitaBPM requires 2 datasources to run correctly. See http://documentation.bonitasoft.com/database-overview for details.

Create a module in jboss for Oracle JDBC driver. see this tutorial

See: bos6_jboss7.rar

Add the Oracle XA driver in standalone.xml file (added within the tag in subsystem: )

<driver module="com.oracle.driver" name="oracle">
      <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
</driver>

Create the bonita XA datasource. Add the following XML, modifying the text in bold, in the subsystem: in standalone.xml:

<xa-datasource enabled="true" jndi-name="java:/bonitaDS" pool-name="bonitaDS" use-ccm="false">
  <xa-datasource-property name="URL">
   jdbc:oracle:thin:@localhost:1521:orcl
  </xa-datasource-property>
  <driver>oracle</driver>
  <xa-pool>
   <is-same-rm-override>false</is-same-rm-override>
   <interleaving>false</interleaving>
   <pad-xid>false</pad-xid>
   <wrap-xa-resource>false</wrap-xa-resource>
  </xa-pool>
  <security>
   <user-name>bonita</user-name>
   <password>bonita</password>
  </security>
  <validation>
   <validate-on-match>false</validate-on-match>
   <background-validation>false</background-validation>
  </validation>
  <statement>
   <share-prepared-statements>false</share-prepared-statements>
  </statement>
 </xa-datasource>

Create the sequenceManager datasource. Add the following XML, modifying the text in bold, in the subsystem: in standalone.xml:

 <datasource enabled="true" jndi-name="java:/bonitaSequenceManagerDS" jta="false" pool-name="bonitaSequenceManagerDS" use-ccm="false">
  <connection-url>jdbc:oracle:thin:@localhost:1521:orcl</connection-url>
  <driver-class>oracle.jdbc.OracleDriver</driver-class>
  <driver>oracle</driver>
  <security>
   <user-name>bonita</user-name>
   <password>bonita</password>
  </security>
  <validation>
   <validate-on-match>false</validate-on-match>
   <background-validation>false</background-validation>
  </validation>
  <statement>
   <share-prepared-statements>false</share-prepared-statements>
  </statement>
 </datasource>

Edit the bonita-platform.properties file located in $ JBOSS_HOME/server/platform/conf and replace the following entries:

 database.journal.datasource.name=${sysprop.bonita.database.journal.datasource.name:java:/bonitaDS}
 database.sequence.manager.datasource.name=${sysprop.bonita.database.sequence.manager.datasource.name:java:/bonitaSequenceManagerDS}

 db.vendor = oracle

 transaction.manager=${sysprop.bonita.transaction.manager:java:/TransactionManager}
 userTransaction=${sysprop.bonita.userTransaction:java:jboss/UserTransaction}

Copy the file c:\opt\BonitaBPMCommunity-6.1.1-JBoss-5.1.0.GA\server\default\deploy\bonita-all-in-one-6.1.1.ear to $JBOSS_HOME\standalone\deployments

Modify the startup script (in my case as I am under Windows, the file is $ JBOSS_HOME\bin\standalone.conf.bat).

Replace:

set "JAVA_OPTS =-Xmx512M-Xms64m-XX: MaxPermSize = 256M"

by:

set "JAVA_OPTS =-Xmx1024M-Xms1024m-XX: MaxPermSize = 256M-XX: + HeapDumpOnOutOfMemoryError"

The following lines are added:

 set "BONITA_OPTS=-Dbonita.home=C:\opt\jboss-as-7.1.1.Final\bonita"
 set "JAVA_OPTS=%JAVA_OPTS% %BONITA_OPTS%"
 goto :eof

Edit the file $ JBOSS_HOME/bonita/server/platform/conf/services/cfg-bonita-persistence-hibernate.xml, adding the following property in the bean: (line 27)

 <prop key="jta.UserTransaction">${userTransaction}</prop>

Startup the server with $ JBOSS_HOME/bin/standalone.bat

Go to: http://localhost:8080/bonita

Charla de introducción a SOA

Dejo la presentación de una charla que estoy dando de introducción a SOA y BPM

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.

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.

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:

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?

Testability: ¿El software puede ser testeado eficientemente?

Usability: Es la medida de eficacia para la interface humana del software

Operational:

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.

Performance

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

Safety: El sistema no crea riesgos en el mundo real.

Pasar un Array a un Stored Procedure en Oracle

Durante estos días tuve que hacer la prueba de pasar un array como parámetro a un Stored Procedure en un Oracle 8i desde Java. Al principio pense que era una tarea simple, pero luego encontre que no es tan así dado que me tope con 3 problemas que trataré de describir aquí.

Pero primero dejo dos URL que tienen información de como hacer esto:
* Muy buen foro
* Documentación Oficial de Oracle

Como mencione, al principio pense que usando JDBC podría lograr esto sin tener problemas pero me encontre con algunas limitaciones de JDBC y el tratamiento de los Array, así que tuve que trabajar directamente usando clases propietarias de Oracle. Quedando un código:

DriverManager.registerDriver(new OracleDriver());
  
String url = "jdbc:oracle:thin:@10.65.72.52:1521:BNPAIS";
Connection conn = DriverManager.getConnection(url, "*******", "*******");
 
String[] array = {"hola", "mundo"};
  
ArrayDescriptor descriptor =
 ArrayDescriptor.createDescriptor( "T_LISTAVARCHAR2", conn );
ARRAY array_to_pass =
 new ARRAY( descriptor, conn,  array);

CallableStatement ps = conn.prepareCall("{call TEST.TEST_ARRAY(?,?)}");
ps.setArray(1, array_to_pass);
ps.registerOutParameter(2, OracleTypes.VARCHAR);
 
ps.execute();
  
System.out.println( ps.getString(2) );
  
conn.close();

Ya en la base de datos, primero declaré el tipo de dato ARRAY que use para la prueba (un ARRAY de VARCHAR). Aquí tenia dos opciones, o bien declararlo dentro del package donde iba a tener mi SP o a nivel del schema.

CREATE OR REPLACE TYPE t_listavarchar2 IS TABLE OF varchar2(300)

Opte por la primer opción y enseguida me encontre con el sigueinte error:

java.sql.SQLException: invalid name pattern:

Basicamente, no me encontraba el tipo de dato declarado.:

ArrayDescriptor descriptor = ArrayDescriptor.createDescriptor( "T_LISTAVARCHAR2", conn );

Buscando la solución encontré 2 soluciones posibles, una (la mas simple) es declarar el tipo de datos a nivel del esquema y la otra es crear un sinónimo publico para el tipo (T_LISTAVARCHAR2) con los accesos y permisos correspondientes al usuario que intente acceder.

Una vez solucionado este problema, me encontre por un par de errores de NoClassDefFoundError por falta de algunos JARs. Para solucionarlo además de classes12.jar puse en mi classpath: nls_charset12.jar

Además aquí dejo otro link con información valiosa sobre los jar a colocar en nuestro classpath.

La verdad que no fue complicado, pero tampoco fue tan simple como esperaba.