DEFINICIÓN DE LA ARQUITECTURA. - · PDF fileNB29_ARQ_Definición de la...

NB29_ARQ_Definición de la Arquitectura (1.0).doc

DEFINICIÓN DE LA ARQUITECTURA.

Fecha: 05/10/2006 Referencia:

EJIE S.A.

Mediterráneo, 3

Tel. 945 01 73 00*

Fax. 945 01 73 01

01010 Vitoria-Gasteiz

Posta-kutxatila / Apartado: 809

01080 Vitoria-Gasteiz

www.ejie.es

Este documento es propiedad de EJIE, S.A. y su contenido es confidencial. Este documento no puede ser reproducido, en su totalidad o parcialmente, ni mostrado a otros, ni utilizado para otros propósitos que los que han originado su entrega, sin el previo permiso escrito de EJIE, S.A.. En el caso de ser entregado en virtud de un contrato, su utilización estará limitada a lo expresamente autorizado en dicho contrato. EJIE, S.A. no podrá ser considerada responsable de eventuales errores u omisiones en la edición del documento.

NB29_ARQ_Definición de la Arquitectura (1.0).doc

Control de documentación

Título de documento: DEFINICIÓN DE LA ARQUITECTURA.

Histórico de versiones

Código: Versión: Fecha: Resumen de cambios:

1.0 05/10/2006 Versión Inicial

Cambios producidos desde la última versión

Control de difusión

Responsable:

Aprobado por:

Firma: Fecha:

Distribución:

Referencias de archivo

Autor: José Luis Olabarri

Nombre archivo: NB29_ARQ_Definición de la Arquitectura (1.0)

Localización: Sharepoint – NB29

Responsabilidades

Función: Nombre: Fecha: Registro:

Autor Luis Olabarri 05/10/2006

NB29_ARQ_Definición de la Arquitectura (1.0).doc ii/43

Revisor Ricardo Gómez 05/10/2006

Aprobación Ander Martínez

NB29_ARQ_Definición de la Arquitectura (1.0).doc iii/43

Contenido

Capítulo/sección Página

1 Introducción. 1

2 Requisitos arquitectónicos. 1

3 Definición General de la Arquitectura. 1

3.1 Modelo de interacción entre capas. 1

3.2 Capa de Entrega. 1

3.2.1. Patrón de uso. 1

3.3 Capa de Servicios. 1


3.3.2. Transacciones en los orquestadores. 1

3.4 Capa de Negocio. 1


3.4.2. Transacciones en la capa de negocio. 1

3.5 Capa de Acceso a Datos. 1

3.5.1. Patrones de uso. 1

3.5.2. Transacciones en la capa de acceso. 1

3.6 Capa de Entidades de Transferencia. 1

3.6.1. Patrones de uso. 1

3.7 Capa de Componentes Arquitectónicos. 1

4 Conclusión final: 1

5 Lecturas Recomendadas. 1

6 Anexo. 1

NB29_ARQ_Definición de la Arquitectura (1.0).doc iv/43

6.1 Tipos de propiedades para las transacciones contenidas. 1

6.1.1. Required. 1

6.1.2. RequiresNew. 1

6.1.3. Mandatory. 1

6.1.4. NotSupported. 1

6.1.5. Supports. 1

6.1.6. Never. 1

NB29_ARQ_Definición de la Arquitectura (1.0).doc 1/43

1 Introducción.

Para el desarrollo de la nueva Arquitectura del Departamento de Industria, Comercio y Turismo partimos de una arquitectura obsoleta. Las aplicaciones a migrar se tratan en su mayoría de aplicaciones cliente/servidor desarrolladas en SQL/Windows y Visual Basic.

Se ha decidido rehacer de nuevo todo sobre una arquitectura J2EE, tanto el desarrollo de las aplicaciones como la parte de datos. Además será necesario que los nuevos desarrollos convivan con los realizados por la e-Administración. Esto plantea un serio problema a la hora de plantearse las situaciones de convivencia entre las nuevas aplicaciones desarrolladas y las existentes en la actualidad.

Otro punto importante a tener en cuanta a la hora de definir la arquitectura es el dinamismo del Departamento de Industria, Comercio y Turismo. En número de secciones que controla el departamento es variable por lo que se hace necesario que el proceso de migración de cualquier sección, así como la incorporación de nuevas secciones, sea sencillo y con poco coste temporal.

El presente documento define la Arquitectura para el Departamento de Industria, Comercio y Turismo, así como la normalización de su uso para la migración de las aplicaciones existentes en el departamento como para futuras evoluciones del mismo.


2 Requisitos arquitectónicos.

� Requisitos generales de la arquitectura:

- El nuevo sistema se basará en una arquitectura orientada a servicios (SOA).

- El nuevo sistema se basará en la nueva infraestructura de eAdministración . (GEREMUA, GESTOR DE PORTALES, INFRAESTRUCTURA DE INTEGRACION …)

- Orientación al puesto de trabajo.

- Integración total entre el backoffice y el frontoffice (teletramitación).

- El análisis y diseño tendrá en cuenta la evolución del sistema, con continuas mejoras en distintos puntos simultáneamente.

- Integración total entre el backoffice y el frontoffice (teletramitación).

- El diseño del sistema deberá contemplar la exportabilidad de secciones o funcionalidades completas del sistema.

- El diseño de la arquitectura contemplará las transacciones y caídas de servicios .

- El análisis y diseño tendrán en cuenta la administración y monitorización del sistema una vez puesto en marcha.

- El nuevo sistema permitirá la explotación de datos .

� Requisitos tecnológicos de la arquitectura:

Nota: En este documento se puede recomendar la utilización de otras herramientas de trabajo o la mejora de algunas herramientas, en base a pruebas de concepto.

o Servidor web:

� Apache Web Server 2.5 sobre Linux Red Hat Enterprise 3.0

o Servidor de aplicaciones:

� BEA Weblogic Server 8.1 sobre Linux Red Hat Enterprise 3.0

o Servidor de integración

� BEA Weblogic Integration 8.1 sobre Linux Red Hat Enterprise 3.0

o Base de datos:

� Oracle 8.1.7 o 9i sobre Sun Solaris 8

o Seguridad:

� XLNets y Certificados de Izenpe

o Gestión de contenidos


� Interwoven TeamSite 6.0

� Gestor de portales desarrollado por el Lote3

o Herramientas:

� Framework J2EE: Geremua

� IDE (PC compatible con XP SP1):

• Eclipse 3.0 con plugin MyEclipse 3.8.4

• Ant

• Gestión de dependencias: Maven

� Versionado de código/trabajo en equipo:

• CVS

� Procesos batch:

• Gestor de procesos batch K31/O75

• Shell Sun Solaris 8

� Informes:

• JReport

� Integración:

• Propagador-enrutador

• Adaptador genérico

� Tramitación electrónica:

• Sistemas, procesos e interfaces del Lote4 de eAdministración

� Business Inteligence

• Oracle Discoverer

� Pruebas:

• JUnit

• LoadRunner

� Documentación y diagramación

• Rational Rose XDE

• SharePoint Portal Server

• Rational Requisite Pro

• JavaDoc


3 Definición General de la Arquitectura.

Se define una arquitectura común para dar soporte a la migración de las aplicaciones existentes en la actualidad en el Departamento de Industria, Comercio y Turismo y a los posibles desarrollos que se lleven a cabo en un futuro, basándose en los requisitos planteados en el punto anterior.

La evolución del mercado y de la tecnología lleva al desarrollo de un único punto de servicios comunes para dar soporte a ‘n’ consumidores. Dando como resultado una Arquitectura Orientada a Servicios (SOA).

SOA promueve el desacople de los componentes de una infraestructura multiplataforma en transacciones elementales o servicios elementales reutilizables por todos los consumidores.

Las ventajas que aportan las Arquitecturas SOA frente a otro tipo de arquitecturas son:

- La abstracción de las aplicaciones y sistemas en servicios a través de sus interfaces normalizadas favorece la generalización de su uso y, al requerir un mínimo conocimiento del sistema o aplicación subyacente, facilita los proyectos de desarrollo .

- Se fomenta la reutilización efectiva y práctica. El consumo de servicios no es sino una manera de reutilizar el mismo código.

- Cada uno de los componentes se independiza del resto, permitiendo su evolución técnica y funcional, siempre que se respete la interfaz de los servicios original.

Servicio : Se trata de una función sin estado, auto-contenida, que acepta unas llamadas y devuelve unas respuestas mediante una interfaz bien definida. Los servicios pueden también ejecutar unidades discretas de trabajo. Los servicios no dependen del estado de otras funciones o procesos ni implican el establecimiento de sesiones.

Pretenden favorecer la interoperabilidad entre los procesos de negocio organizativos e inter-organizativos.

Interoperabilidad : La capacidad que tienen los sistemas TIC y los procesos de negocio que los soportan, de intercambiar datos y permitir compartir información y conocimiento. Es necesaria una interoperabilidad a tres niveles: Organizativo, Semántico y Técnico.

Interoperabilidad

Organizativa

Interoperabilidad

Semántica

Interoperabilidad

Técnica

•WorkFlow

•Compartir Conocimiento

•Estructuras de Datos

•Diccionarios

•Metadatos

•Intercambio de datos: XML, Wes Services

•Transformación de datos: XSLT

•Modelización: UML, RDF, BPM..

•Protocolos TCP/IP, HTTP…

•Seguridad


- La utilización de estándares abiertos permite una interoperabilidad cuasi universal con independencia de las plataformas tecnológicas implicadas.

- Se facilitan las pruebas unitarias sobre los sistemas especializados y desacoplados.

- Se mejora la escalabilidad gracias a procesos distribuidos sorbe balanceo de carga.

- Se facilita la composición de nuevos servicios sobre servicios ya existentes.

La implementación ideal de una Arquitectura SOA requiere tener en consideración algunos inconvenientes técnicos inherentes al modelo:

- Los tiempos de llamado nos son despreciables, gracias a la comunicación de la red, tamaño de mensajes, etc. Esto necesariamente implica la utilización de mensajería confiable.

- La respuesta de los servicios es afectada directamente por aspectos externos como problemas en la red, configuración, etc. Estos deben ser tenidos en cuenta en el diseño, desarrollándose los mecanismos de contingencia que eviten la parálisis de las aplicaciones y servicios que dependen de él.

- Debe manejar comunicaciones no confiables, mensajes impredecibles, reintentos, mensajes fuera de secuencia, etc.

- Obviamente, un servicio debe de controlar internamente su propia transaccionalidad, pero muchas veces se requiere mantener la transaccionalidad interservicios, lo cual exigiría el control de la misma desde la propia lógica del consumidor.

Por ello un diseño exitoso de una arquitectura basada en servicios debe de estar basado en una plataforma de mensajería confiable, que aísle de la implementación funcional muchos de los problemas anteriormente mencionados. Algunos de las responsabilidades de un mecanismo así, incluyen:

- Entrega garantizada de mensajes.

- Enrutamiento de peticiones a un servicio disponible.

- Seguridad del contenido de los mensajes.

- Calidad de servicio.

- Escenarios fuera de línea.

- Control de transaccionalidad interservicios.

- Control de la seguridad de acceso.

Ligado a esta nueva arquitectura llega un nuevo modelo de desarrollo orientado a servicios (SODA), el cual deberá de aplicarse en los nuevos análisis y diseños proporcionando:

- Reutilización de servicios : Se encapsulan los servicios con sentido funcional, en vez de las tradicionales llamadas a métodos orientados al sistema. Estos servicios han de exponerse en un único catálogo de servicios de forma que queden accesibles al resto de las aplicaciones fomentando de esta manera la reutilización.

- Independencia de la plataforma : Siempre se ejecutan como si se tratara de una llamada remota. La tecnología y localización de la aplicación proveedora del servicio se oculta detrás de la interfaz del servicio. Permitiendo la migración de plataforma o tecnología de las aplicaciones que ofrecen o consumen el servicio sin que para ellos se vea afectada la definición del servicio.

- Flexibilidad : La aplicación consumidora y la aplicación proveedora pueden cambiar. Mientras no se modifique la definición de los elementos esenciales (obligatorios) del interfaz, la comunicación


entre ellas no se vera afectada. Permite responder a las nuevas demandas de servicios rápidamente. Esto se traduce en alta disponibilidad y escalabilidad.

- Seguridad : Permite definir autenticación y autorización necesaria de los consumidores de servicios.

- Estándares : Conectividad a través de estándares comunes extensibles: XML, SOAP, WSDL, JMS, WS-Security, WS-Routing, etc.

La arquitectura base, sobre la que se deben desarrollar las aplicaciones del SGI (Sistema General de Industria) se basa en los patrones de diseños propuestos por sun developer network para el desarrollo de aplicaciones J2EE.

En el siguiente gráfico se esboza una arquitectura en capas orientada a servicios la cual pretende recoger todos los requisitos de desarrollo presentes y futuros que se puedan plantear en el Departamento de Industria Comercio y Turismo.


Broker

Servicios

BP

M

Broker de M

ensajes

Bus e-B

29

VISION DEL CIUDADANO

Gestor de Portales

FRAMEWORK - GEREMUA

XLNets

BBDDsnegocio

BBDDsnegocio

BBDDsDepartamento

Infraestructura e-Industria, Comercio y Turismo

ESCRITORIOS Monitor del Sistema Administrador UsuariosAdministrador Avisos

JaKina

Aplicaciones Negocio: Lógica de negocio.

Ent

idad

es d

e tr

ansf

eren

cia.

Rep

osito

rio d

e S

chem

as.

Util

idad

es C

omun

es d

e la

Arq

uite

ctur

a.

Infr

aest

ruct

ura

eAv

ServiciosArquitectura

ServiciosDepartamentales

Capa de negocio

Capa de servicios

Capa de acceso a datos

Capa de Integración

Capa de Presentación

Broker

Servicios

BP

M

Broker de M

ensajes

Bus e-B

29

Broker

Servicios

BP

M

Broker de M

ensajes

Bus e-B

29

VISION DEL CIUDADANO

Gestor de Portales

FRAMEWORK - GEREMUA

XLNets

BBDDsnegocio

BBDDsnegocio

BBDDsDepartamento

BBDDsnegocio

BBDDsnegocio

BBDDsDepartamento

Infraestructura e-Industria, Comercio y Turismo

ESCRITORIOS Monitor del Sistema Administrador UsuariosAdministrador Avisos

JaKina

Aplicaciones Negocio: Lógica de negocio.

Ent

idad

es d

e tr

ansf

eren

cia.

Rep

osito

rio d

e S

chem

as.

Util

idad

es C

omun

es d

e la

Arq

uite

ctur

a.

Infr

aest

ruct

ura

eAv

ServiciosArquitectura

ServiciosDepartamentales

Capa de negocio

Capa de servicios

Capa de acceso a datos


Capa de Presentación

Capa de Servicios

Capa de Datos


Capa de Entrega

Capa de Negocio

Com

pone

ntes

A

rqui

tect

ura

Ent

idad

es d

eT

rans

fere

ncia

Capa de Servicios

Capa de Datos


Capa de Entrega

Capa de Negocio

Com

pone

ntes

A

rqui

tect

ura

Com

pone

ntes

A

rqui

tect

ura

Ent

idad

es d

eT

rans

fere

ncia

La arquitectura general del SGI estará compuesta de:

1. Aplicaciones de presentación (capa de entrega) : Aplicaciones desarrolladas sobre GEREMUA.

2. Aplicaciones de integración (capa de servicios): Orquestadores de servicios de servicios de negocio. Autogestionan la transaccionalidad entre los distintos servicios que ofrecen los sistemas de negocio. Se presentan como servicios de granularidad gruesa.

3. Aplicaciones de negocio (capa de negocio): Representan los sistemas que componen la arquitectura. Cada sistema tiene su propio modelo de datos y son los encargados de gestionar estos datos.

4. Aplicación única de Entidades de transferencia: Todas las entidades de negocio detectadas se agrupan en una única aplicación.

5. Aplicación de utilidades (componentes de la arquite ctura): Aplicación encargada de agrupar a todas las utilidades comunes que se hayan podido detectar dentro de la arquitectura.


Capa Descripción de función.

Capa de Entrega Conjunto de aplicaciones que ofrecen la interfaz de presentación de la arquitectura al usuario final (funcionarias, funcionarios, ciudadanas y ciudadanos). Las aplicaciones de la capa de presentación se desarrollan haciendo uso de GEREMUA, JAKINA y el Gestor de Portales. Esta capa se encarga únicamente de la gestión de la presentación y de llamar a las acciones a realizar en el momento adecuado. Se componen de Componentes de presentación y Operaciones de presentación

Capa de Servicios Aplicaciones encargadas de orquestar de forma coherente y reutilizable los servicios ofrecidos por las diferentes aplicaciones de negocio. Además de ser los encargados de gestionar de forma transparente la transaccionalidad. Presentan una interfaz de servicios de un granularidad gruesa a todas las aplicaciones organizativas e inter-organizativas.

Capa de Negocio Aplicaciones encargadas de resolver la lógica de negocio de la arquitectura. Cada aplicación tiene su propia interfaz para exponer sus funcionalidades y además podrán exponer dichas funcionalidades a través de servicios. Cada aplicación gestiona su propio modelo de datos a través de su propia cada de acceso a datos. Es decir, una aplicación de negocio se compone de: Interfaz de acceso, objetos de negocio y capa de acceso a datos.

Capa de Acceso a Datos Gestión de consultas y modificaciones de los repositorios de datos existentes en la arquitectura (Bases de Datos, Servicio de Directorios,…). Son proyectos, que cumplen un mismo patrón DAO, dentro de las aplicaciones de negocio. Cada aplicación de negocio implementará su capa de acceso en un proyecto aparte con el fin de separa negocio y datos.

Capa de Integración Conjunto de utilidades ofrecidas por “WebLogic Integration” con el fin de fomentar la interoperabilidad tecnológica; facilitar la exposición de servicios, el desarrollo de procesos de negocio, facilitar la gestión de eventos y de fomentar las ejecuciones en paralelo y operaciones asíncronas.

Componentes de Arquitectura Utilidades comunes para toda la arquitectura. Se trata de librerías desarrolladas específicamente para el SGI o de librerías heredadas de GEREMUA. Se usan para Gestión de errores, Herramientas de trazabilidad, acceso a ficheros de configuración,… etc. Con el fin de fomentar la reutilización de código y facilitar la normalización de desarrollo.

Entidades de Transferencia Componentes comunes para la transferencia de información. Se trata de un conjunto de objetos legibles por todas las aplicaciones de la arquitectura. El uso de esta capa permite la reducción de transformaciones dentro de la arquitectura y favorece la interoperabilidad entre todas las aplicaciones.


3.1 Modelo de interacción entre capas.

Antes de entrar en el detalle de cada capa, puede ayudar a entender mejor el modelo arquitectónico revisar por encima el modelo de interacción existente entre las diferentes capas de la arquitectura que componen el SGI.

El usuario interactúa con la capa de presentación. Cuando es necesario acceder a negocio para obtener alguna información, o para poder realizar alguna operación hace a través de un intermediario; encargado de encaminar las peticiones entre los diferentes servicio que componen el SGI, de esta forma se abstrae a la capa de presentación de la complejidad tecnológica de acceso y de la situación en la que se encuentra un determinado sistema. El intermediario encamina la petición de la capa de presentación hacia los servicios de orquestación de sistemas, delegando la transaccionalidad sobre esta capa. Los orquestadores de servicios orquestan las llamadas a los sistemas en un proceso de negocio. Las aplicaciones de negocio, son sistemas que ofrecen servicios de una granularidad mas fina que las de la capa anterior, acceden a las bases de datos a través de su propia capa de datos. Encargada de agrupar todos los accesos a datos físicos.

PRESENTACION

Intermediario

EJBSession

DAO

OT

WebService JPD EJBFacade JMS

EJBSession EJBSession EJBSession

AccesoServicioOrquestador

AccesoA negocio de sistema

Acceso a datos

Acceso a Negocio

PRESENTACION

Intermediario

EJBSession

DAO

ET





Acceso a datos

Acceso a Negocio

PRESENTACION

Intermediario

EJBSession

DAO

OT





Acceso a datos

Acceso a Negocio

PRESENTACION

Intermediario

EJBSession

DAO

ET





Acceso a datos

Acceso a Negocio

Todas las capas de la arquitectura hacen uso de la capa de entidades de transferencia. Utilizan este tipo de componentes como unidad léxica. De esta manera se promueve la interoperabilidad semántica haciendo uso de un mismo repositorio de entidades de transferencia. Así mismo, con el fin de fomentar la reutilización de código, todas las capas de la arquitectura tienen accesible la capa de componentes de la arquitectura. Por ejemplo, el intermediario de negocio es un componente o utilidad de la arquitectura.


En la siguiente gráfica se explica el flujo entre capas con un ejemplo:

Ventanilla

Intermediario

DAO

OT



Acceso a datos

Acceso a Negocio

Gestor Expedientes

EJBSession

Gest/Exp

OrquestadorAperturaExpediente

Infra

estru

ctur

aeA

v

EJBSession

REI

DAOREE

Aplicación Ventanilla Aplicación Gestor Expedientes Aplicación REI

Ventanilla

Intermediario

DAO

OT



Acceso a datos

Acceso a Negocio

Gestor Expedientes

EJBSession

Gest/Exp


Infra

estru

ctur

aeA

v

EJBSession

REI

DAOREE


Ventanilla

Intermediario

DAO

OT



Acceso a datos

Acceso a Negocio

Gestor Expedientes

EJBSession

Gest/Exp


Infra

estru

ctur

aeA

v

EJBSession

REI

DAOREE


Ventanilla

Intermediario

DAO

OT



Acceso a datos

Acceso a Negocio

Gestor Expedientes

EJBSession

Gest/Exp


Infra

estru

ctur

aeA

v

EJBSession

REI

DAOREE


En el caso del ejemplo tenemos las siguiente aplicaciones:

- Aplicaciones de presentación:

o Aplicación Ventanilla.

o Aplicación Gestor de Expedientes.

- Aplicaciones de integración.

o Aplicación: Servicios de Expedientes.

o Servicio utilizado:

- Orquestadores de Apertura expediente

- Aplicaciones de negocio:

o Gestor de expediente.

o REI.


3.2 Capa de Entrega.

Capa encargada de presentar a los usuarios finales (funcionarias, funcionarios, ciudadanas y ciudadanos) los resultados de las acciones que vayan realizando sobre la Arquitectura del Departamento de Industria, Comercio y Turismo. Las aplicaciones de la capa de presentación se desarrollan haciendo uso de GEREMUA. Esta capa se encarga de ofrecer una navegación entre las diferentes interfaces gráficas de usuario a través de operaciones de presentación.

3.2.1. Patrón de uso.

GEREMUA es el framework de desarrollo para aplicaciones J2EE de EJIE. Se trata de un conjunto de componentes, desarrollados sobre STRUSTs implementando el paradigma MVC2 (Modell View Cotroller adaptado a WEB) e intenta separar la lógica de negocio de la presentación del acceso a datos. Las aplicaciones se modelan como flujos de navegación dirigidos por el usuario, quién va pasando por estados intermedios en los que se ejecuta lógica de negocio.

Sub

sist

ema

de L

iste

ners

Sub

sist

ema

de L

iste

ners

Sub

sist

ema

de C

onec

tore

sS

ubsi

stem

a de

Con

ecto

res

Subsistema de InfraestructuraSubsistema de Infraestructura

Subsistema de ControlSubsistema de Control

Subsistema dePresentación


Subsistema deNegocio


Sub

sist

ema

de L

iste

ners

Sub

sist

ema

de L

iste

ners

Sub

sist

ema

de C

onec

tore

sS

ubsi

stem

a de

Con

ecto

res

Subsistema de InfraestructuraSubsistema de Infraestructura

Subsistema de ControlSubsistema de Control





En la figura anterior se muestran los seis subsistemas que componen el framework de desarrollo de GEREMUA.

- Subsistema listeners: Se trata de una colección de adaptadores específicos para cada canal o protocolo utilizado. Se recibe directamente las peticiones de los clientes del framework y se redireccionan al gestor de canal. Además permite añadir las validaciones de los campos de formulario a este nivel dentro del “Gestor de Validaciones Remotas”.

- Subsistema de control : Se trata de un conjunto de componentes eencargados de llevar la conducción principal del flujo de control de la ejecución ante una interacción de un usuario con el sistema. El componente más interesante de este subsistema es el “Gestor de Canal Browser PC


http”. Se trata del encargado de dirigir los pasos de ejecución dentro del framework para el protocolo http.

- Subsistema de presentación: Es la agrupación de las “interfaces de usuario” (jsps, javascript, css, customTags…) además de las operaciones de presentación. Una “operación de presentación” se suele corresponder con un caso de uso. Es interesante resaltar el “Motor de flujo de la navegación” se trata de un componente genérico que permite establecer cuál es el próximo paso de ejecución de una Operación de Presentación a partir de su diagrama de estados

- Subsistema de negocio: Recoge los componentes encargados de la funcionalidad independiente del dispositivo y del canal de acceso.

- Subsistema de Conectores: Elementos encargados de la integración de las aplicaciones con sistemas externos. Aísla a los aplicativos de los detalles de integración Recibe informaciones de las Funciones de Integración que se encuentran en el subsistema de negocio.

- Subsistema de Infraestructura : Colección de ccomponentes encargados de dar soporte a las operaciones tradicionales de las aplicaciones, como es el caso de los mensajes de log.

GEREMUA es un framework de desarrollo declarativo, la mayor parte del esfuerzo se dedica a la configuración de las operaciones de presentación , junto con el diseño gráfico de los componentes de presentación (JSPs) de la configuración de las operaciones internas .

ListenerHttp

Gestor Canal

JSPsJSPsJSPsJSPsJSPsJSPs

JSPsJSPsOperacionesDe Presentación


JSPsJSPsOperacionesInternas


- Una operación de presentación agrupa un conjunto de acciones que el usuario puede realizar dentro de un escenario de presentación. Normalmente agrupa todas las acciones posibles dentro de un mismo caso de uso. GEREMUA ofrece un fichero de configuración para cada operación de presentación. Internamente hay que configurar las diferentes acciones que el usuario puede realizar.

- En muchas ocasiones puede que sea necesario acceder a realizar una operación de negocio, una inserción en una base de datos, etc. GEREMUA denomina a esto operaciones internas . Con el fin de desacoplar las operaciones internas de la capa de presentación presenta un inter-mediador basado en el patrón business delegate. El cual abstrae a la capa de presentación de la situación de la implementación de la operación interna, así como de la complejidad de la misma.

- Los componentes de presentación son la representación gráfica de los formularios y respuestas de las diferentes acciones realizadas por el usuario en modo gráfico.


La Arquitectura del Departamento se compone de un conjunto de sistemas desacoplados. Estos sistemas desacoplados ofrecen servicios (en geremua: operaciones internas). Además asociados a estos sistemas, existen procesos de negocio encargados de orquestar estos servicios con el fin de ofrecer una granularidad más gruesa (se busca usar como mucho una única interacción con negocio para resolver una interacción de un usuario que requiere de negocio). Tecnológicamente estos servicios se desarrollan utilizando estándares del mercado como, WebServices, JMS, EJBs y JPDs. Sin embargo GEREMUA, hoy por hoy, no está previsto para interactuar más que con EJBs. Para resolver este problema dentro de las utilidades de negocio se ha desarrollado otro inter-mediador que permite interactuar con todas las tecnologías anteriormente mencionadas. El inter-mediador que se ha desarrollado para el SGI incorpora ciertas diferencias con el incorporado en GEREMUA (véase Intermediario de Negocio).

La idea de centralizar las peticiones de los servicios desde la capa de presentación hacia las capas de negocio resulta muy interesante para la Arquitectura del Departamento. Las causas que mueven a esta centralización de las peticiones es la existencia de servicios distribuidos en sistemas desacoplados por toda la arquitectura y por otras arquitecturas remotas, como la eAv. Un punto central donde pueda solicitar la ejecución de un servicio desconociendo donde se encuentra geográficamente situado es muy interesante. Pero además ofrece un punto donde poder monitorizar el comportamiento de los usuarios dentro de mi sistema, así como un punto donde poder cachear seguridad y operaciones en la capa de presentación reduciendo el tráfico de red. En resumen (aplicando el patrón decorator) podemos incorporar diferentes comportamientos al conjunto de interacciones entre los sistemas.

Otro problema que se encuentra al usar inter-mediador de GEREMUA, al estar implementado sobre reflexión para fomentar la programación declarativa como única solución, produce que al realizar una subida a otro entorno de trabajo falten librerías necesarias o los objetos de retorno esperados no sean lo que se habían planteado en un principio, detectando el problema en ejecución, ya que en compilación siempre funcionaría.

Por lo tanto, para la Arquitectura del Departamento de Industria, Comercio y Turismo el flujo entre componentes de la capa de presentación y la capa de negocio que se propone es el siguiente:

ListenerHttp

Gestor Canal






IntermediarioB29

(programático)

IntermediarioQ70

(declarativo) Sist. SimulaciónSist. Simulación

ServiceLocatorDecoradoresDecoradoresDecoradores

Para desarrollar y diseñar aplicaciones sobre GEREMUA, así como para tener un conocimiento más a fondo de cada componente es necesario conocer las guías de uso existentes sobre el framework (véase: Lecturas Recomendadas: Guías GEREMUA , Inter-mediador de Negocio Programático y la Guía de Estilos del SGI.).

Nota: En casos excepcionales puede ser necesario el uso de algún cliente pesado, como AJAX, Java Web Star,… En cada uno de estos casos habrá que estudiar su convivencia con el framework de desarrollo de GEREMUA.


3.3 Capa de Servicios.

Representa todas aquellas funcionalidades de la capa de negocio y de la arquitectura que se entienden como reutilizables por otros elementos (aplicaciones) internos al Departamento de Industria, Comercio y Turismo o externos pero con acreditación de uso.

La capa de servicios debe de ser expuesta, por lo tanto en la capa de integración (en un servidor weblogic integration), con el fin de poder presentarlo como accesible desde el resto de aplicaciones internas al departamento o externas.

En esta capa se orquestan los servicios presentados por los sistemas desarrollados en la capa de negocio, así mismo en esta orquestación pueden participar otros componentes que pertenecen a la infraestructura de gobierno, e-Av, Xlnets, Izenpe, Registro de entradas, etc…

Así mismo esta capa será la encargada de definir la transaccionalidad entre las diferentes interacciones.

Desde la capa de presentación es posible acceder, pero solo a través de operaciones internas , directamente a ciertos servicios expuestos de la capa de negocio.

Es necesario definir un servicio en la capa de servicios:

1. Cuando existe interacción entre diferentes sistemas de la capa de negocio en un mismo proceso de negocio.

2. Cuando un servicio tiene naturaleza reutilizable por varias aplicaciones, internas o externas al departamento.

Se pueden identificar, en esta capa diferentes tipos de servicios:

- Servicios Departamentales : Cooperaciones de las aplicaciones departamentales al resto de aplicaciones de la arquitectura con el fin de fomentar la interoperabilidad. Los servicios se deben definir ofreciendo granularidad gruesa con el fin de reducir el numero de interacciones sobre la capa de servicios.

- Servicios Arquitectura: Conjunto de servicios comunes que facilitan el uso de la arquitectura a las aplicaciones que la componen. Ejemplo: Servicio Propagador Enrutador.

PRESENTACION

Intermediario

EJBSession

DAO

OT





Acceso a datos

Acceso a Negocio

PRESENTACION

Intermediario

EJBSession

DAO

OT





Acceso a datos

Acceso a Negocio



El patrón propuesto es el SessionFacade, resuelto tecnológicamente a través de EJBs, JPDs, WebServices y JMS (MDB).

En base a pruebas de concepto se ha resuelto que es más rápido el desarrollo de servicios de orquestación a través de EJBs de Sesión. Esto no descarta al resto de tecnologías ya que en algunos casos será inevitable el uso de JPDs. Los JPDs son sencillos de desarrollar, pero la ventaja más importante es que permiten realizar procesos con flujos en paralelo, recogedores de eventos, facilitan las tareas asíncronas, etc. Todas estas ventajas, además de las que puedan presentarse por el entorno de despliegue de las aplicación habrá que tenerlas MUY en cuenta a la hora de decidir la tecnología a utilizar para realizar un servicio de orquestación de servicios.

Por el momento es recomendable el uso de JPDs:

1. Procesos de larga duración.

2. Procesos en los que puedan realizarse ejecuciones d entro del mismo proceso de negocio en paralelo.

3. Situaciones en las que la orquestación de servicios resulte de la captación de un evento determinado.

<EJB><JPD><WS><MDB>SessionFacade

<EJB>BusinessSession

App1


App2


App3

DAO

acce

ss

access

acce

ss

access

DAO

acce

ss

DAO

acce

ss

Intermediario <EJB><JPD><WS><MDB>SessionFacade


App1


App2


App3

DAO

acce

ss

DAO

acce

ss

access

acce

ss

access

DAO

acce

ss

DAO

acce

ss

DAO

acce

ss

DAO

acce

ss

Intermediario


3.3.2. Transacciones en los orquestadores.

La capa de servicios será la encargada de orquestar las transacciones del SGI. Los artefactos que se proponen para realizar orquestación de servicios pueden iniciar transacciones o pueden gestionarla por su cuenta de forma contenida.

- Un WebService no es transaccional, pero si es posible iniciar una transacción desde dentro de un WebService.

- Los EJB, JPDs o MDB gestionan la transaccionalidad a través de los contenedores, haciendo uso de los atributos de transaccionalidad que definen cada uno de los servicios que se exponen. Estas propiedades se explican en el anexo: Tipos de propiedades para las transacciones contenidas.

• Recomendaciones para la definición de la transacci onalidad en el caso de usar WebServices:

- En este caso el WebService, si se desea que sea transaccional, deberá de gestionar el mismo la transaccionalidad. Es decir, deberá de abrir una transacción y controlar las distintas invocaciones, haciendo commit y rollback cuando el lo crea oportuno.

- Ejemplo: Dentro del servicio que se expone en un WebService se pueden orquestar llamadas a EJBs de sesión, de entidad, etc… A todo tipo de recursos transaccionales definiendo una transacción de usuario.

InitialContext initialcontext = new InitialContext();

UserTransaction usertransaction = (UserTransaction)initialcontext.lookup("java:comp/UserTransaction");

usertransaction.begin();

try {

//TODO � Desarrollo de la orquestación de servicios.

usertransaction.commit();

}catch (Throwable e) {

usertransaction.rollback();

}


• Recomendaciones para la definición de la transacci onalidad (gestionada por contenedores) para la capa de servicios (JPDs, EJBs, MDBs):

Propiedad Servicio Recomendación. Required Se puede entender que Required debe

funcionar en la mayoría de transacciones, por lo que se propone como propiedad transaccional por defecto al inicio de la programación. Al ser un atributo declarativo no será problema modificarlo más adelante.

RequiredNew Se debe de usar esta opción cuando se desea que el servicio al que se está llamando se ejecute como una nueva transacción.

Mandatory Se debe de usar esta cuando se cree obligatorio que el servicio invocado se ejecute dentro de la transacción del cliente.

NotSupported Se debe de usar este atributo en aquellos servicios que no necesitan ser transaccionales. Hay que tener que las transacciones reducen el rendimiento.

Supports El uso de Supports ha de ser utilizado con cuidado, ya que el comportamiento transaccional de un mismo método o servicio puede variar.

Never El uso de Never es útil para obligar a que el método o servicio no pueda ser invocado nunca desde una transacción.

Propiedad Servicio Descripción. Recomendación. Servicios no TX Se puede entender por todos aquellos

servicios que no son, ni van a ser transacciones, pero que en un momento dato pueden intervenir en una transacción. Por ejemplo, se entiende como un servicio no TX a los que combinan consultas de bases de datos sin inserciones.

NotSupported

Servicios 1/2 TX Se puede entender que son aquellos servicios en los que en un momento dado pueden pasar a ser transaccionales, o aquellos en los que no se tiene clara su transaccionalidad

Required

Servicios TX. Se debe de usar esta cuando se cree obligatorio que el método o servicio invocado se ejecute dentro de la transacción del cliente.

Required

Servicios TX aislados.

Se debe de usar esta opción cuando un servicio se quiere que se comporte siempre como una transacción aislada.

RequiredNew


3.4 Capa de Negocio.

Capa de la arquitectura encargada de resolver la lógica de negocio del SGI. Entendiendo que la arquitectura está orientada a ofrecer servicios y a fomentar la interoperabilidad es necesario separar la capa de negocio de la capa de presentación de forma ordenada, es decir agrupando los diferentes sistemas detectados en aplicaciones diferentes con su propia capa de negocio e interfaz de acceso.


Una aplicación de negocio representa un sistema que ofrece servicios de granularidad fina (a nivel de método) al conjunto del SGI. Lo lógico es que el acceso a estos servicios se realice a través de los orquestadores de servicios, aunque puede que haya casos en los que se pueda acceder directamente. Por ejemplo, si se resuelve la petición del usuario con una única interacción sobre un servicio del sistema o aplicación de negocio.

El patrón que ha de utilizarse para el desarrollo de los sistemas es el siguiente:



Ifaz de acceso

access

DAO

acce

ss

Intermediario

BussinessObjectBussinessObjectBussinessObject

Entidades de Transferencia

crea

usa

usa

viaja



Ifaz de acceso

access

DAO

acce

ss

Intermediario

BussinessObjectBussinessObjectBussinessObject


crea

usa

usa

viaja



Ifaz de acceso

access

DAO

acce

ss

DAO

acce

ss

Intermediario

BussinessObjectBussinessObjectBussinessObjectBussinessObjectBussinessObjectBussinessObject


crea

usa

usa

viaja


Se trata de una colección de objetos de negocio los cuales agrupan toda la lógica del sistema, y que en caso de ser necesario realizan las llamadas a la capa de acceso (DAO) para persistir, modificar o recuperar datos físicos relacionados únicamente con el propio sistema. Una aplicación de negocio solo debe conocer su estructura de datos y en ningún caso debe pretender o ser concebida (salvo claras excepciones que habrá que justificar) para acceder a datos relacionados con otros sistemas. Las relaciones entre las diferentes estructuras de información o sistemas que componen el SGI se realizan a través de los orquestadores, nunca se debería de realizar en esta capa.

Una vez desarrollados los objetos de negocio se debe definir la interfaz de acceso, y esta además debe de ser definida como remota como un EJB de sesión.

Por lo tanto la capa de negocio se compone de los o bjetos de negocio de un sistema bien definido y acotado junto con su interfaz; accesible, por lo menos, po r la capa de servicios y en algunos casos por la capa de presentación.

PRESENTACION

Intermediario

EJBSession

DAO

OT





Acceso a datos

Acceso a Negocio

PRESENTACION

Intermediario

EJBSession

DAO

OT





Acceso a datos

Acceso a Negocio


En el siguiente ejemplo se muestra un ejemplo de cómo serían las interacciones con la capa de negocio. Se puede observar que en algunos casos es posible acceder directamente.

Hay que intentar limitar el número de interfaces por sistema a una única interfaz. De esta forma se consigue limitar el número de dependencias necesarias para desarrollar los orquestadores de servicios de la capa de servicios.

Ventanilla

Intermediario

DAO

OT



Acceso a datos

Acceso a Negocio

Gestor Expedientes

EJBSession

Gest/Exp


Infr

aest

ruct

ura

eAv

EJBSession

REI

DAOREE

Sistema Ventanilla Sistema Gestor Expedientes Sistema REI

EJBSession

Ventanilla

Intermediario

DAO

OT



Acceso a datos

Acceso a Negocio

Gestor Expedientes

EJBSession

Gest/Exp


Infr

aest

ruct

ura

eAv

EJBSession

REI

DAOREE

Sistema Ventanilla Sistema Gestor Expedientes Sistema REI

EJBSession

Nota: A la hora de definir un método en la interfaz de un sistema hay que tener en cuenta que puede ser susceptible de pertenecer a una transacción de un nivel superior. Como se ha comentado en el punto anterior es la capa de servicios la encargada de iniciar y definir las transaccionalidad entre operaciones. Por este motivo habrá que tener muy en cuenta este aspecto antes de elegir entre los diferentes niveles de transaccionalidad que podemos incorporar en un EJB de sesión.


3.4.2. Transacciones en la capa de negocio.

La capa de negocio es orquestada por la capa de servicios a nivel de proceso de negocio y a nivel transaccional; aún así esto no es una norma, ya que desde la capa de presentación (a través del intermediario de negocio) se puede acceder directamente a un método expuesto en la capa de negocio.

Esto puede crear ciertos problemas y generar cierta incertidumbre a la hora de definir la transaccionalidad de un método de un sistema de negocio, ya que no está claro en un primer momento si un determinado método participará o no en una transacción.

En este punto se pretende dar una serie de consejos o recomendaciones para facilitar la decisión de los analistas funcionales o diseñadores técnicos sobre cómo definir las propiedades transacciones de los EJBs de sesión; recomendados para implementar las interfaces de acceso de los sistemas de negocio o aplicaciones de la capa de negocio.

• Recomendaciones para la definición de la transacci onalidad (gestionada por contenedores) para la capa de servicios (JPDs, EJBs, MDBs):

Propiedad Servicio Recomendación. Required Se puede entender que Required debe

funcionar en la mayoría de transacciones, por lo que se propone como propiedad transaccional por defecto al inicio de la programación. Al ser un atributo declarativo no será problema modificarlo más adelante.

RequiredNew Se debe de usar esta opción cuando se desea que el servicio al que se está llamando se ejecute siempre como una nueva transacción.

Mandatory Se debe de usar esta propiedad cuando se cree obligatorio que el servicio invocado se ejecute dentro de la transacción del cliente.

NotSupported Se debe de usar este atributo en aquellos servicios que no necesitan ser transaccionales. Hay que tener en cuenta que las transacciones reducen el rendimiento.

Supports El uso de Supports ha de ser utilizado con cuidado, ya que el comportamiento transaccional de un mismo método o servicio puede variar.

Never El uso de Never es útil para obligar a que el método o servicio no pueda ser invocado nunca desde una transacción.


Propiedad Servicio Descripción. Recomendación. Método no TX Se puede entender por todos aquellos

métodos que no son, ni van a ser transacciones, pero que en un momento dado pueden intervenir en una transacción. Por ejemplo, se entiende como un método no TX a los que combinan consultas de bases de datos sin modificaciones en los repositorios de datos. El uso de esta opción es muy recomendable en este tipo de métodos ya que se mejora el rendimiento de la arquitectura.

NotSupported

Métodos 1/2 TX Se puede entender que son aquellos métodos en los que en un momento dado pueden pasar a ser transaccionales, o aquellos en los que no se tiene clara su transaccionalidad. Se entiende como la transaccionalidad por defecto.

Required

Métodos 100% TX. Se debe de usar esta cuando se cree obligatorio que el método invocado se ejecute dentro de la transacción del cliente.

Required

Métodos TX aislados.

Se debe de usar esta opción cuando un servicio se quiere que se comporte siempre como una transacción aislada.

RequiredNew


3.5 Capa de Acceso a Datos.

La capa de acceso a datos es la encargada de facilitar el acceso a los repositorios persistentes de información a los sistemas definidos en la capa de negocio. Como ya se ha comentado en el punto anterior, cada sistema tendrá debidamente definido su repositorio de información y no se permite el acceso entre diferentes repositorios salvo en excepciones que deberán de ser debidamente justificadas.

3.5.1. Patrones de uso.

Se recomienda la utilización del siguiente patrón de acceso:

BBDD

usa

accede

encapsula

obtiene/modifica

crea/usa

No tiene sentido la utilización de patrones como el DAOAbstractFactory ya que cada sistema dispone de una única fuente de datos (datasource) accesible, el la mayoría de los casos se tratará de una base de datos oracle 8.1.7 o superior definida como un recurso OCI XA (para permitir transaccionalidad).

El patrón que se proponen es simple de implementar, además permite separar los accesos a datos de la lógica de negocio en diferentes proyectos dentro de una misma aplicación, sin penalizar el rendimiento del conjunto de la aplicación de negocio y facilitando el posterior mantenimiento correctivo y evolutivo del código desarrollado.

Por ejemplo: Una aplicación que representa un sistema deberá de tener como mínimo y en su mayoría como máximo los siguientes proyectos:

� Aplicación (Sistema X).

� SistemaXBO: Proyecto java representando los objetos de negocio de la aplicación.


� SistemaXDAO: Proyecto java que implementa el patrón DAO para el acceso a datos.

� SistemaXEJB: Proyecto Enterprise con un EJB de sesión, en el cual se implementa la interfaz de acceso.

� La aplicación tendrá dependencias con la aplicación de entidades de transferencia, ya que las entidades de transferencia viajan por toda la red.

En cuanto al método de acceso a utilizar, se han realizado una serie de pruebas, haciendo uso de varios métodos de acceso, como EJBs de entidad CMP, JDBC, HIBATIS, etc. De estas pruebas de concepto se ha desprendido que el método de acceso que ofrece un mayor rendimiento es JDBC. Sin embargo no descartamos el uso de otros métodos de acceso que no incurran en la utilización de innumerables librerías no homologadas por el departamento de desarrollo EJIE. Por este motivo se puede entender que:

1. La recomendación de uso es DAO – JDBC .

2. Se permite el acceso desde BusinessObjects de la capa de negocio a EJBs de Entidad CMP 2.0. Entendemos que el patrón DAO no encaja con CMP.

3. No se permite el uso de métodos de acceso no homologados por EJIE.

4. Es imprescindible al implementar el acceso a datos que este esté totalmente separado (en diferentes proyectos) de la lógica de negocio.

3.5.2. Transacciones en la capa de acceso.

La capa de acceso es la encargada de persistir los datos en los repositorios de información. En la mayoría de los casos los repositorios de información serán bases de datos oracle. La capa de acceso no debería de tener consciencia de las transacciones, ya que esta debería de estar gestionada por contenedores. Por este motivo está prohibido el uso la gestión transaccional sobre la conexión de una base de datos, salvo en casos muy concretos y que deberán de ser claramente justificables.

Las conexiones a bases de datos se realizan a través de pules de conexión, que se encuentran accesibles a través de datasources a la capa de acceso. Los pules de conexión deben de ser configurados haciendo uso de drivers transaccionales (XA) para facilitar la gestión de las transacciones contenidas.

Nota: La recomendación es que cada aplicación disponga de una conexión a base de datos transaccional y de una conexión no transaccional. De forma que según la tipología de las acciones (consultas, modificaciones, inserciones, borrados) sobre los recursos de acceso se puedan realizar a través de conexiones transaccionales (más lentas) o conexiones no transaccionales.


3.6 Capa de Entidades de Transferencia.

En la mayoría de las arquitecturas las aplicaciones han ido creciendo de forma aislada, cada una implementando y trabajando con sus propios objetos. Para evitar esto es interesante contar con un repositorio o capa de entidades comunes para la transferencia de información. Un conjunto de objetos entendible por todas las aplicaciones de la arquitectura.

Objetivos:

- Mantener un repositorio común de objetos ; en el que se agrupen todos los objetos de la arquitectura con el fin de poder reutilizarlos por todas las aplicaciones.

- Evitar el desarrollo repetitivo de diferentes clases para representar un mismo objeto.

- Reducir el número de transformaciones necesarias en la interoperabilidad de aplicaciones.

- Facilitar la serialización de objetos en XML para facilitar el intercambio de información.

3.6.1. Patrones de uso.

Contexto:

En la actualidad el Departamento de Industria, Comercio y Turismo cuenta con varias aplicaciones, la mayoría de ellas no están siquiera desarrolladas sobre lenguajes orientados a objetos. Para integrar cada una de las aplicaciones, hoy por hoy se realiza mediante procesos batch que recogen e insertan la información en las diferentes bases de datos. El desarrollo de las nuevas aplicaciones y la migración de las existentes se harán sobre una arquitectura orientada a servicios desarrollada en J2EE; por lo que la orientación a objetos de la arquitectura es clara.

En el nuevo contexto de gobierno surge la necesidad de comunicarse con los servicios que ofrece la infraestructura de la e-Administración. Hoy por hoy la comunicación es a través de XML y el número de interacciones se presupone alto.

Partimos de una arquitectura dividida en capas, en la que la capa de presentación tiene la necesidad de comunicarse con la capa de acceso a través de la capa de negocio, haciendo uso de WebServices, EJBs de sesión, etc… siguiendo el patrón Session Facade.

El problema:

En el desarrollo de aplicaciones para un mismo departamento, lo más normal es que se repita el desarrollo del mismo objeto una y otra vez, además se suele incluir comportamiento dentro de los objetos (lógica de negocio), lo que hace que la reutilización de estos objetos entre aplicaciones no sea sencilla.

La arquitectura del SGI separa por completo el comportamiento de los objetos de las propiedades que definen una entidad de transferencia. Esta decisión está motivada a que el comportamiento de un objeto puede ser diferente en cada una de las aplicaciones que se vayan a desarrollar sobre la arquitectura del departamento, sin embargo es poco probable que cambien las propiedades que definen los objetos. De esta manera se consigue mantener un único repositorio de objetos comunes a todas las aplicaciones del departamento.

Esta separación implica tener una capa de lógica de negocio separada de la capa de objetos en la que se desarrollen los diferentes comportamientos. Esta lógica puede estar distribuida entre diferentes puntos de una red corporativa, incluso pueden estar separadas en diferentes redes. Esto es un


problema ya que puede aumentar el tráfico de la red y disminuir el rendimiento de la arquitectura. Por este motivo es muy importante definir los servicios de la capa de negocio de forma que reduzcan este tráfico. Así mismo es necesario definir los objetos de forma que se puedan utilizar como fuentes de información en si mismos. Es decir, una vez recuperados poder utilizarlos para recuperar información sobre los mismos objetos.

La arquitectura del SGI está muy ligada con la arquitectura de la e-Administración. La e-Av presenta una serie de servicios sobre los que las aplicaciones del SGI realizan peticiones. Los servicios de la e-Administración aceptan como parámetros de entrada XML por lo que será necesario que los objetos de trasporte de la arquitectura del SGI mantengan coherencia con los ya definidos en la e-Administración y que puedan ser serializados en XML para la interoperabilidad entre las dos arquitecturas.

3.6.1.1. Transfer Objects

- Solución:

Para la implementación de la capa de entidades de transferencia del SGI existen múltiples patrones. El patrón Transfer Objects permite crear una librería de objetos serializables, de forma que puedo intercambiarlos entre capas aunque estén dispuestos de forma remota.

obtiene/modifica/crea

usausa

crea/usa

crea/usa

obtiene/modifica/crea

usausa

crea/usa

crea/usa

- Conclusión:

El gran problema de este patrón es que no se adapta bien a una arquitectura orientada a servicios ya que no permite serializar los objetos en XML. Este problema hace que cada vez que se desea ínter operar con otras aplicaciones se tengan que hacer transformaciones de Java a XML y de XML a Java haciendo uso de artefactos DOM y SAX, ya que los objetos de trasporte no


están preparados trabajar con la mayoría de herramientas de mapeo de datos java-xml existentes en el mercado.

Por este motivo, a pesar de la sencillez del patrón no parece muy recomendable para la arquitectura del Departamento de Industria, Comercio y Turismo. Sin embargo si vale como una aproximación al siguiente patrón que presentamos el cual pretende ser una extensión de este patrón hacia las arquitecturas orientadas a servicios.

3.6.1.2. XML Serialization Transfer Objects

- Solución:

En el mercado existen una gran variedad de productos que ayudan a la serialización de objetos en XML. De forma que las aplicaciones trabajan con objetos Java mientras que el trasporte entre aplicaciones se resuelve a través de XML, se denominan productos de mapeo de datos JAVA-XML. El uso de estas herramientas facilita la creación de objetos partiendo de schemas (xsd) que definen estos objetos y que a través de una serie de herramientas permiten generar la capa de entidades de transferencia en base a una factoría de objetos JAVA serializables a XML.

La idea de este patrón es mantener un repositorio de schemas común para toda la arquitectura y haciendo uso de estas las herramientas de mapeo de datos JAVA-XML conseguir una librería java de Objetos de Transporte serializable en XML.

Esta operación se denomina binding; para realizar esta operación se ejecuta una rutina que recorre los esquemas generando automáticamente las librerías de objetos java que representan dichos esquemas.

REPOSITORIODE

SCHEMAS (XSD)

UTILIDADES DE MAPEO DE DATOS

JAVA-XML

LIBRERÍA:CAPA DE ACCESO

SERIALIZABLEEN XML

REPOSITORIODE

SCHEMAS (XSD)

UTILIDADES DE MAPEO DE DATOS

JAVA-XML

LIBRERÍA:CAPA DE ACCESO

SERIALIZABLEEN XML

Las herramientas de mapeo de datos JAVA-XML suelen proporcionar utilidades para la transformación de schemas a librerías de objetos, además de APIS para facilitar el tratamiento de estos objetos (para su serialización y de-serialización).

La elección de la herramienta más adecuada para la a arquitectura del SGI, así como la utilización de la misma, se recoge en el documento ARQ-Herramientas y Utilidades técnicas de la Arquitectura SGI.

La librería de objetos serializables en XML ha de ser distribuida en todas las aplicaciones y capas de la arquitectura, así mismo es necesario que tengan acceso al API java para poder serializar a XML los objetos o para poder deserializar XMLs a objetos.

Por defecto, las herramientas de binding generan una colección de objetos que solo permiten la serialización en XML para su trasporte entre aplicaciones. El mantener una comunicación inter-aplicaciones solo a través de XML tiene como principal ventaja dotar de una mayor flexibilidad al cambio de la definición de los objetos. Sin embargo el rendimiento es un poco menor.


APLICACIÓN :API MAPEODE DATOSXML-JAVA

OBJETOJAVA

XML

de-serializa

serializa


OBJETOJAVA

XML

de-serializa

serializa

En la siguiente figura se muestra una solución combinada entre Abstract Factory y la Serialización en XML. El patrón pretende la convivencia entre interoperabilidad stream e interoperabilidad XML.


OBJETOJAVA

XML

de-serializa

serializa

InterfazeSerializable

implements


OBJETOJAVA

XML

de-serializa

serializa

InterfazeSerializable

implements

Esta solución tiene como principal varios problemas:

• Es una combinación , por lo que no marca una regla general a la hora de tomar una decisión sobre que transmisión de datos utilizar en cada caso.

• Hereda los problemas inherentes al uso de Transfer Object, además de los problemas inherentes a serialización XML.

• Incongruencia entre Schemas y librerías de objetos. Para permitir que los objetos implementen serializables hay que modificar directamente los objetos. Por lo tanto, si es necesario realizar una nueva operación de binding habría que remodificar de nuevo todos los objetos.


Nota:”Puede que según la herramienta de mapeo que se seleccione esto no sea necesario, ya que hay algunas herramientas que incorporan tags propios para la definición de esquemas que pueden incorporar este tipo de facilidades”.

- Conclusión:

La separación de la capa de trasporte de la lógica de negocio de las aplicaciones de la arquitectura tiene una serie de consecuencias favorables y alguna desfavorable.

Ventajas:

o Facilita la exportabilidad de las aplicaciones . No solo sobre la misma arquitectura, ya que al ser posible

o Fomenta la reutilización de código . Las aplicaciones no tienen que definir la mayoría de los objetos, ya que al compartir el mismo contexto (gobierno) es muy probable que los objetos se encuentren disponibles dentro de la librería de la capa de trasporte.

o Reduce el tráfico de red . Los objetos de trasporte pretenden reducir el numero de llamadas remotas para conseguir información a una única llamada. Además este patrón pretende facilitar la búsqueda de información dentro del objeto de trasporte.

o

Desventajas:

o Es posible encontrarnos con objetos obsoletos viajando por la arquitectura : Lo más seguro es que los objetos de trasporte se modifiquen continuamente, es decir, definir a priori unos objetos que recojan todas las necesidades de las aplicaciones es complicado, por lo que es muy probable que estos estén en continuo mantenimiento. Esto puede hacer que aplicaciones que no se hayan actualizado para dar soporte a los nuevos objetos de trasporte tengan problemas por usar objetos no actualizados. Un cambio en un objeto muy utilizado dentro de la arquitectura puede traer consecuencias. Aún así, el usar objetos serializables en XML para la interoperabilidad entre la capas puede hacer que el problema no sea tan grave como lo podría ser si se usaran objetos serializables. Para solucionar este problema es muy importante definir los schemas que representan los objetos de forma abierta. Es decir, definir el núcleo de propiedades obligatorias que representan el objeto de una forma coherente y los añadidos al objeto de forma opcional.


3.7 Capa de Componentes Arquitectónicos.

En esta capa se definen el conjunto de utilidades y herramientas comunes que se han detectado que pueden ser de utilidad para el desarrollo del SGI. Se considera oportuno realizar una división en dos tipos de herramientas:

- Capa de recursos de integración:

o Para el proyecto se cuenta con un servidor de integración. La función fundamental de este servidor es la de exponer el conjunto de servicios al interior de la organización a otras unidades orgánicas que puedan necesitar el uso de los servicios del SGI.

o Pero además un servidor de integración incorpora un conjunto de herramientas muy útiles para el desarrollo de procesos de negocio. Sobre todo para el desarrollo de procesos de negocio en los que en cierto momento requieren de intervención humana, por lo que los tiempos de duración de los mismos suelen ser imprevisibles.

o Estas herramientas son:

- Broker de eventos : Las aplicaciones pueden producir eventos de varios tipos. Depositar un fichero un filesystem, traspasar un fichero a través de ftp, recibir una petición http, inserción de una tupla en una base de datos, la expiración de un periodo de tiempo determinado … el broker de eventos permite recoger todo este tipo de eventos y provocar que estas acciones inicialicen procesos de negocio a través de canales de comunicación.

- Generadores de eventos : Permiten a las aplicaciones de integración generar diferentes tipos de eventos.

- Canales de comunicación : Su principal uso es la comunicación entre el broker de eventos y los procesos de negocio. Pero además incorpora la capacidad de filtrar el contenido que viaja por los diferentes canales

- JPD: Permiten desarrollar de forma visual procesos de negocio complejos, de larga duración, con ejecuciones en paralelo, etc... Haciendo uso de una paleta de servicios.

- Paletas de servicios : Los servicios dentro de integración se representan como controles dentro de una paleta. Lo que se podría entender como un broker de servicios. Esta paleta se encuentra accesible para poder ir incluyéndolos en los procesos de negocio y fomentando de esta manera la reutilización de código.

- …

- Capa de recursos o utilidades comunes:

Se trata de un conjunto de librerías en las que se agrupan todas las utilidades que se consideran de uso común para la arquitectura, con el fin de fomentar la reutilización de código.

- Librería de acceso a ficheros de configuración : Librería que permite a cada código de aplicación acceder a su configuración. Las propiedades de configuración se guardan en la memoria virtual de la máquina java del lugar donde esté corriendo dicha aplicación, estas propiedades son accesibles desde cualquier punto de la aplicación, y solo se hace un acceso a disco al inicio, para recuperar las propiedades, posteriormente se hace sobre memoria (véase: Gestor de arranque y configuración GEREMUA (revisar si encaja)).


- Librería de traza para sistemas distribuidos . Permite la escritura de trazas, manteniendo un esquema formalizado, de forma que posteriormente puedan ser explotadas por el monitor del sistema. La librería de trazas permite ver el flujo de navegación de los usuarios a pesar de hacerse a través de sistemas distribuidos (véase: Modelo de Trazabilidad de la Arquitectura).

- Librería con el conjunto de excepciones de la aplic ación : Librería encargada de agrupar todas las excepciones de la arquitectura (véase: Modelo de Gestión de Errores).

- Librería para el acceso a XLNets : Librería encargada de simplificar los accesos a XLNets para (véase: Modelo de Seguridad de la Arquitectura y Gestor de Seguridad de GEREMUA).

o Realizar un login de usuario.

o Realizar un login de aplicación.

o Comprobar los permisos de acceso de una aplicación a un determinado servicio.

o Recuperar una clave de acceso para acceder a un determinado recurso de la arquitectura.

o Cachear las peticiones a XLNets para limitar el número de interacciones con el servicio de seguridad. De forma que no se ralentice el rendimiento de los sistemas involucrados en la arquitectura ni se estrese demasiado al sistema XLNets.

- Gestor de impresiones : Utilidad encargada de facilitar la impresión desde las aplicaciones de presentación (véase: Gestor de impresión GEREMUA).

- Proporciona soluciones básicas. Sirve para imprimir documentos de forma online.

- Lee una Plantilla

- Sustituye los huecos por datos del Contexto

- Aplica un procesamiento FOP o lo deja en html

- Muestra el resultado en un browser (generalmente PDF) para su impresión

- No permite XSL, solo FO en el caso de PDF

- Gestor de Mensajes e Internacionalización : Punto único de consulta de literales y mensajes asociados a un código y un idioma (véase: Gestor de mensajes e internacionalización GEREMUA).

- Gestor de Tablas de Códigos : Servicio de lectura de tablas de códigos (tablas de listas de valores, de sólo lectura y de uso común), que permita de modo transparente y configurable realizar operaciones de cara a optimización del rendimiento (p. ej. , pasarse a tablas en memoria) (véase: Gestor de mensajes e internacionalización GEREMUA).

- Gestión de Pools: Es el encargado de gestionar de forma genérica las conexiones, reservando, liberando y reutilizando instancias de los mismos a petición de los Solicitantes (FrameWork o aplicaciones). Mejora el rendimiento (véase: Gestor de pools GEREMUA)

- Gestión de Caches: Guarda instancias recursos que no deseamos que el Garbage Collector borre. (véase: Gestor de caches GEREMUA)

- Intermediario de negocio: Componente encargado de enrutar las peticiones de los servicios desde las operaciones de presentación a la lógica de negocio. (véase: Intermediario de negocio.)


4 Conclusión final:

El resultado de este documento es la definición de una arquitectura para el SGI basado en patrones j2ee. En este punto se define el flujo de comunicación desde el cliente hasta los repositorios de información de las aplicaciones a través de los componentes de la arquitectura.

BBDD 3BBDD 2

ListenerHttp

Gestor Canal

JSPsJSPsJSPs



IntermediarioB29

(programático)

IntermediarioQ70


ServiceLocator

Orquestadores: SessionFacade

JPD Webservices EJBSessionJMS MDB Gestiónde TX

DecoradoresDecoradoresDecoradores

Sistemas Horizontales de la aplicación. Capa de negocio

BBDD 1

Sis

tem

a 1

(app

)EJB Sessión

Objeto NegocioObjeto NegocioObjeto Negocio

DAO Sist

ema

2 (a

pp)EJB Sessión


DAO Sist

ema

3 (a

pp)EJB Sessión


DAO

MVC2

BusinessDelegate

ServiceLocator

SessionFacadeTra

nsfe

rObj

ect

DataAccessObject

BusinessObjets

Ent

idad

es d

e T

rans

fere

ncia

core patterns

Web

logi

c se

rver

inte

grat

ion

Web

logi

c se

rver

BBDD 3BBDD 2

ListenerHttp

Gestor Canal

JSPsJSPsJSPs



IntermediarioB29

(programático)

IntermediarioQ70


ServiceLocator





BBDD 1

Sis

tem

a 1

(app

)EJB Sessión


DAO Sist

ema

2 (a

pp)EJB Sessión


DAO Sist

ema

3 (a

pp)EJB Sessión


DAO

MVC2

BusinessDelegate

ServiceLocator

SessionFacadeTra

nsfe

rObj

ect

DataAccessObject

BusinessObjets

Ent

idad

es d

e T

rans

fere

ncia

core patterns

BBDD 3BBDD 2

ListenerHttp

Gestor Canal






IntermediarioB29

(programático)

IntermediarioQ70


ServiceLocator





BBDD 1

Sis

tem

a 1

(app

)EJB Sessión


DAO Sis

tem

a 1

(app

)S

iste

ma

1 (a

pp)EJB Sessión


DAO

EJB Sessión

Objeto NegocioObjeto NegocioObjeto NegocioObjeto NegocioObjeto NegocioObjeto Negocio

DAO Sist

ema

2 (a

pp)EJB Sessión


DAO Sist

ema

2 (a

pp)

Sist

ema

2 (a

pp)EJB Sessión


DAO

EJB Sessión


DAO Sist

ema

3 (a

pp)EJB Sessión


DAO Sist

ema

3 (a

pp)

Sist

ema

3 (a

pp)EJB Sessión


DAO

EJB Sessión


DAO

MVC2

BusinessDelegate

ServiceLocator

SessionFacadeTra

nsfe

rObj

ect

DataAccessObject

BusinessObjets

Ent

idad

es d

e T

rans

fere

ncia

core patternscore patterns

Web

logi

c se

rver

inte

grat

ion

Web

logi

c se

rver


1. El usuario envía peticiones http a través del explorador .

o http://<nombrehost>:prueto/warContextRoot/configuracionOperacionPresentacion/nombreAccion.do

� nombrehost: máquina (ip o dns) en la que se encuentra instalado el servidor web.

� Puerto: puerto de escucha del servidor web.

� warContextRoot : Ruta del contexto de la aplicación web.

� configuracionOperacionPresentacion: ruta donde está la configuración de las operación de presentación solicitada.

� nombreAccion.do: Nombre de la acción que se desea realizar. Se encuentra representada dentro de la configuración de la operación de presentación.

o Ejemplo: http://localhost:8100/r17MantenimientosWar/aplicacionesJSP/r17inicio.do

2. Las peticiones son recogidas por el componente listener http y re-direccionadas al gestor canal.

3. El gestor canal tiene precargada información de configuración, obtenida del web.xml, con la cual sabe la configuración de operaciones de presentación a la que tiene que acceder la petición del usuario, para realizar la acción que ha solicitado.

4. La operación de presentación decide lo que tiene que hacer. Se entiende que una operación de presentación se corresponde con un caso de uso del DSI de la aplicación de presentación. Existen varios tipos de operaciones de presentación definidas en las guías de desarrollo de GEREMUA.

5. Si la operación de presentación necesita acceder a lógica de negocio lo hará a través de las operaciones internas de GEREMUA. La clase genérica que ofrece GEREMUA para la ejecución de una operación interna puede ser extendida, de forma que en este punto se puede decidir si se desea utilizar el intermediario de negocio programático o el declarativo.

6. La funciona de los intermediarios de negocio es exactamente la misma. Aunque se describen con detalle en otros documentos las principales diferencias entre uno y otro es que uno es totalmente declarativo y otro es programático. Es decir, en se define todo a través de un XML y en el otro se programan las llamadas a los métodos a través de una interfaz de acceso. La segunda opción es más costosa de desarrollar, pero sin embargo el mantenimiento del código es más sencillo. Otra ventaja del intermediario de programático es que está concebido para acceder a un abanico más amplio de tecnologías (JPD, EJB, WS, JMS).

7. Los intermediarios de negocio pueden redireccionar las peticiones a sistemas de simulación . Estos sistemas lo único que hacen es devolver una respuesta en la que se retorna datos de respuesta previamente concertados. Con el fin de poder ir evolucionando las aplicaciones de presentación sin depender de la lógica de negocio.

8. Además se puede incorporar comportamientos predefinidos, a través de los decoradores , a las peticiones de negocio. Por ejemplo, se puede hacer que un servicio deje una traza siempre que sea invocado, que incorpore en la petición un identificador de flujo para poder seguirlo en sistemas desacoplados (que no compartan sesión) el flujo de una petición de un usuario, etc, etc.

9. El servicelocator no es más que un artefacto que cachea ciertos elementos de las peticiones de forma que hace que estas sean más ágiles.

10. En la capa de servicios residen los orquestadores , estos orquestadores se agrupan en diferentes aplicaciones, normalmente por las dependencias que tienen entre los sistemas. Pero también se pueden realizar por las unidades de negocio con las que trabajan. Por ejemplo: Aplicación de orquestadores de expedientes (permite abrir un expediente, cerrar un expediente, aportar


documentación a un expediente…). Los orquestadores de servicios representan a los procesos de negocio del SGI, además de orquestar los servicios dirigen las transaccionalidad de las diferentes interacciones.

11. En la capa de negocio de implementa un sistema por aplicación en un conjunto de objetos de negocio , y presenta un interfaz a través de un EJB de sesión .

12. Cada sistema tiene acceso a su propio modelos de datos , y debe de estar perfectamente acotado, intentando justificar debidamente el acceso a otros sistemas directamente o a otros repositorios de datos.


5 Lecturas Recomendadas.

- Schemas:

o Especificación de XML Schema: http://www.w3.org/TR/2000/WD-xmlschema-1-20000922/

o Mejores Prácticas para la definición de esquemas: http://www.xfront.com/BestPracticesHomepage.html

- Patrones:

o Patrones J2EE: http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html

o Diseño de Patrones: http://www.dofactory.com/Patterns/PatternAbstract.aspx

o Sun Center J2EE: http://java.sun.com/developer/technicalArticles/J2EE/patterns/J2EEPatternsRelationships.html

o SDO pattern: http://dev2dev.bea.com/wlplatform/commonj/sdo.html

o Catálogo de patrones J2EE:

� http://industria.at.ejie/Migracion%20B29/Document%20Library/Diseño/Arquitectura/documentacion%20de%20interes/patrones%20J2EE/Catálogo%20de%20Patrones%20de%20Diseño%20J2EE.%20Negocio%20e%20Integración.doc

� http://industria.at.ejie/Migracion%20B29/Document%20Library/Diseño/Arquitectura/documentacion%20de%20interes/patrones%20J2EE/Catálogo%20de%20Patrones%20de%20Diseño%20J2EE.%20Presentación.doc

- Libros de arquitectura:

o Diseño de arquitecturas J2EE: http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/titlepage.html

o Libro de bolsillo de los arquitectos J2EE: http://industria.at.ejie/Migracion%20B29/Document%20Library/Diseño/Arquitectura/documentacion%20de%20interes/libros%20arquitectura/J2EEArchitectsHandbookV1.0.0.pdf

o Master en EJBs (tercera edición): http://industria.at.ejie/Migracion%20B29/Document%20Library/Diseño/Arquitectura/documentacion%20de%20interes/libros%20arquitectura/MasteringEJB3rdEd.pdf

- Guías de uso:

o Guía de desarrollo GEREMUA: http://industria.at.ejie/Migracion%20B29/Document%20Library/Diseño/Arquitectura/documentacion%20de%20interes/geremua/GuiaDeDesarrollo-GEREMUA_v1.1.doc

- Mapeo de datos JAVA-XML.

o Comparación de Herramientas para Mapeo de Datos JAVA - XML (Java – XML Data Binding Tools):


� http://www.xml.com/pub/a/2003/09/03/binding.html .

� https://bindmark.dev.java.net/

o Prueba de XMLBeans del XML-Journal.

� http://dev2dev.bea.com/pub/a/2004/01/hitesh_seth.html

o Herramientas para el Mapeo de Datos JAVA–XML.

� http://www.rpbourret.com/xml/XMLDataBinding.htm

� http://wiki.apache.org/old/XmlMappingFrameworkComparison


6 Anexo.

6.1 Tipos de propiedades para las transacciones con tenidas.

6.1.1. Required.

Si el cliente está corriendo dentro de una transacción, e invoca a un método de un EJB o a un proceso orquestador de servicios, el método o servicio se ejecuta dentro de la misma transacción del cliente. En el caso en el que el cliente no se esté ejecutando dentro de una transacción, el contenedor del orquestador de servicios inicia una nueva transacción antes de iniciar el servicio invocado.

6.1.2. RequiresNew.

Si el cliente está corriendo dentro de una transacción, e invoca a un método de un EJB o a un proceso orquestador de servicios, el contenedor de transacciones realiza las siguientes acciones:

1. La transacción del cliente se deja suspendida (no se elimina, se suspende).

2. Se inicia una nueva transacción.

3. Delega la llamada al método o servicio invocado.

4. Se resume (reinicia) la transacción del cliente después de finalizar el método o el servicio.

Como en el caso anterior, si el cliente no se está ejecutando dentro de una transacción, el contenedor del orquestador de servicios inicia una nueva transacción antes de iniciar el servicio invocado.

6.1.3. Mandatory.

Si el cliente está corriendo dentro de una transacción, e invoca a un método de un EJB o a un proceso orquestador de servicios, el método o servicio se ejecuta dentro de la misma transacción del cliente. En el caso en el que el cliente no se esté ejecutando dentro de una transacción, el contenedor lanza una excepción del tipo: TransactionRequiredException.

6.1.4. NotSupported.

Si el cliente está corriendo dentro de una transacción, e invoca a un método de un EJB o a un proceso orquestador de servicios, el contenedor suspende la transacción del cliente antes de invocar la servicio o al método. Después de que el método o servicio se completa, el contenedor resume la transacción del cliente.

Si el cliente no está corriendo dentro de una transacción, el contenedor no inicia una nueva transacción antes de comenzar el método.


6.1.5. Supports.

Si el cliente está corriendo dentro de una transacción, e invoca a un método de un EJB o a un proceso orquestador de servicios, el método o servicio se ejecuta dentro de la transacción del cliente. Si el cliente no está asociado a una transacción el contenedor no inicia una nueva transacción antes de ejecutar el método o servicio asociado. Es decir, hay veces que es transaccional y otras que no.

6.1.6. Never.

Si el cliente está corriendo dentro de una transacción, e invoca a un método de un EJB o a un proceso orquestador de servicios, el contenedor lanza una excepción de tipo RemoteException. Si el cliente no está asociado a una transacción, el contenedor no inicia una nueva transacción antes de ejecutar el método o servicio asociado.

DEFINICIÓN DE LA ARQUITECTURA. - · PDF fileNB29_ARQ_Definición de la...

Documents

Transcript of DEFINICIÓN DE LA ARQUITECTURA. - · PDF fileNB29_ARQ_Definición de la...