5. plataforma ae ee.ll. arquitectura software v0gfw.diputacionalicante.es/repo/rec/206/05....

Arquitectura Software

Plataforma de Administración Electrónica para EE.LL.

Índice

1.- GSE, SDC

1.1.- Arquitectura de ejecución

1.2.- Arquitectura de desarrollo

1.3.- workflow colaborativo

2.- Bus

2.1.- Elementos básicos

2.2.- Servicios Mule

2


2.3.- Servicios horizontales

3.- Rep. Documental

3.1.- Alfresco

3.2.- Integración

4.- Carpeta Ciudadana

4.1.- Arquitectura

1.1. Arquitectura de ejecución

1. GSE, SDC

Presentación : capa de presentación basada en Java Server Faces, enriquecido con componentes ad hoc de apoyo al desarrollo y a la ejecución.

Negocio : encapsulación de servicios de negocio en forma de beans Spring y publicación y consumo mediante web services, facilitados por Xfire.

Integración : acceso a base de datos mediante ORM’s o JDBC tradicional, y a otros sistemas mediante web services o conectores ad hoc.

3

J2EE 1.4+

Presentación Negocio Integración

JSF Spring

Componentes Arquitectura

Componentes Desarrollados

XFire

JDBC

ORM (Hibernate)

Servicios de Negocio

Conect. .

Acceso a Datos

Servicios Transversales

Presentación Negocio


capa de presentación(1/6)

JSF (Java Server Faces) es un especificación de la plataforma J2EE orientada a la obtención de interfaces web sofisticados generados en servidor , buscando los siguientes objetivos:

• Dotar de un entorno basado en componentes gráficos reutilizables a los desarrolladores.

• Disponer de un modelo orientado a eventos (más efectivo para interfaces de usuario) para conectar presentación con servicios.

• Facilitar la inclusión de información en los interfaces desde las


1. GSE, SDC

4

J2EE 1.4+

JSF

…

Vistas

…

Serv. de presentación

MyFaces ADF

Spring

Escritorio

Caché

Contexto

Localizador

Motor de Navegación

…Flujos de Navegación

Gestor de Seguridad

• Facilitar la inclusión de información en los interfaces desde las fuentes de datos de las aplicaciones.

• Permitir la adaptación de la presentación al canal empleado por el usuario, mediante componentes renderers .

Se incorporan dos kits de controles JSF: MyFaces (de la Apache Software Foundation) y ADF (construido por Oracle, y donado a Apache como proyecto Trinidad ). La arquitectura admite la integración de otras implementaciones JSF: SunFaces, IBM Faces, etc… Se incluyen renderers para explorador web y PDA.




Los desarrolladores crean Vistas , esto es, páginas JSF, combinando controles Faces mediante las facilidades que les proporcionan los entornos IDE.

También es posible crear páginas JSP y servlets integrados dentro del framework.


1. GSE, SDC

5

J2EE 1.4+

JSF

…

Vistas

…


MyFaces ADF

Spring

Escritorio

Caché

Contexto

Localizador



Gestor de Seguridad




Los Servicios de presentación son componentes específicos de cada aplicación que proporcionan la lógica de presentación existente tras los eventos de usuario (pulsar un botón, arrastrar una barra de scroll, etc.) recibidos a través de las Vistas.

A su vez, estos componentes invocan a los Servicios de Negocio para llevar a cabo las operaciones de consulta o actualización de información..


1. GSE, SDC

6

J2EE 1.4+

JSF

…

Vistas

…


MyFaces ADF

Spring

Escritorio

Caché

Contexto

Localizador



Gestor de Seguridad




La arquitectura incluye cuatro componentes básicos de apoyo a la presentación:

• El Escritorio ofrece un marco general de presentación desde el que el usuario puede navegar por diferentes aplicaciones, manteniendo una misma apariencia homogénea.

• La Caché permite prealmacenar datos utilizados frecuentemente en los controles de presentación (p.ej.: combos de provincias o países).

• El Contexto es una encapsulación de los diferentes niveles de persistencia de la información a lo largo de


1. GSE, SDC

7

J2EE 1.4+

JSF

…

Vistas

…


MyFaces ADF

Spring

Escritorio

Caché

Contexto

Localizador



Gestor de Seguridad

niveles de persistencia de la información a lo largo de una sesión de usuario:

• Aplicación.

• Sesión.

• Flujo.

• Petición.

• El Localizador permite invocar a los Servicios de Negocio sin que la capa de Presentación necesite conocer su localización.

La construcción de estos componentes se apoya en el framework Spring.



capa de presentación (5/6)

El componente director de la capa de presentación es el Motor de Navegación , cuyo objetivo es la ejecución de los Flujos de Navegación que se diseñen. Estos flujos determinan los elementos y sus transiciones que deben componer las interacciones con el usuario.


1. GSE, SDC

8

J2EE 1.4+

JSF

…

Vistas

…


MyFaces ADF

Spring

Escritorio

Caché

Contexto

Localizador



Gestor de Seguridad

Estos Flujos son elaborados mediante una herramienta de diseño, incluida en la Arquitectura de Desarrollo..




Los Servicios Transversales dotan de funcionalidad de apoyo al resto de los componentes de las otras capas.

Los elementos de los Serv. Transversales se detallan más adelante.

La arquitectura proporciona un Gestor de Seguridad propio de la capa de presentación, aplicando reglas de autenticación a los siguientes elementos:

• Permisos de ejecución de los nodos de un Flujo de Navegación .

• Permisos de ejecución de opciones del Escritorio .


1. GSE, SDC

9

J2EE 1.4+

JSF

…

Vistas

…


MyFaces ADF

Spring

Escritorio

Caché

Contexto

Localizador



Gestor de Seguridad

• Permisos de ejecución de opciones del Escritorio .

• Securización de controles JSF dentro de páginas, tanto para su visualización como para su habilitación.



Integración

capa de negocio (1/8)

Spring es un contenedor “ligero” con las tres siguientes características:

1º) Hace uso únicamente de objetos “POJO” (Plain Old java Objects), sin necesitar EJB’s para la lógica de negocio.


1. GSE, SDC

10

J2EE 1.4+


Spring…

Localizador

Local

Remoto

…

RM

IW

eb services

…

…

DA

O


Servicios

De

Negocio

XFireHTTP JMS Local



Integración

capa de negocio(2/8)

Spring es un contenedor “ligero” con las tres siguientes características:

2ª) Emplea la inyección de dependencia (hab. “IoC”) para establecer las dependencias existentes entre objetos de manera declarativa.


1. GSE, SDC

11

J2EE 1.4+


Spring…

Localizador

Local

Remoto

…

RM

IW

eb services

…

…

DA

O


Servicios

De

Negocio

XFireHTTP JMS Local



Integración


Spring es un contenedor “ligero” con las siguientes características:1111111111

Logging

Transaccionalidad

Seguridad

3ª) Incluye AOP (Aspect Oriented Programming) para poder definir declarativamente “asuntos cruzados” (cross-cutting concerns), sobre los que la propia lógica de negocio debería permanecer independiente (seguridad, transaccionalidad, distribución).


1. GSE, SDC

12

J2EE 1.4+


Spring…

Localizador

Local

Remoto

…

RM

IW

eb services

…

…

DA

O


Servicios

De

Negocio

XFireHTTP JMS Local

ComponentesPresentación, Negocio, Integración

Seguridad

Ad hoc



Integración


El componente Localizador permite que los Servicios de Presentación puedan acceder directamente a los Servicios de Negocio independientemente de su ubicación.

Se diferencian dos tipos de “acceso”:

• Local : el Servicio de Negocio reside en la misma JVM que el Servicio invocador.

Remoto


1. GSE, SDC

13

J2EE 1.4+


Spring…

Localizador

Local

Remoto

…

RM

IW

eb services

…

…

DA

O


Servicios

De

Negocio

• Remoto : el Servicio invocador y el invocado residen en diferentes JVM’s.

XFireHTTP JMS Local



Integración

capa de negocio (5/8) En el caso de acceso Remoto, se proporcionan dos

posibilidades “off-the-shelf”:

• Web services : Debido a la estandarización, tanto “institucional” (OASIS, WS) como de facto, de los elementos empleados, los web services son el principal mecanismo de integración en sistemas abiertos, ya se trate de arquitecturas SOA corporativas, o integraciones ad hocentre sistemas concretos.

• RMI: Remote Method Invocation es el mecanismo nativo de Java para la ejecución de métodos ubicados en


1. GSE, SDC

14

J2EE 1.4+


Spring…

Localizador

Local

Remoto

…

RM

IW

eb services

…

…

DA

O


Servicios

De

Negocio

XFireHTTP JMS Local

de Java para la ejecución de métodos ubicados en máquinas virtuales distintas a la del propio sistema.

Los patrones de la arquitectura permiten incorporar nuevos mecanismos sin impacto en la implementación de los Servicios.



Integración


Para facilitar la exposición y consumo de web services de los Servicios de Negocio, se ha incorporado al framework el proyecto XFire . El objetivo es facilitar la interoperabilidad entre sistemas, específicamente dentro de una arquitectura de sistemas SOA (Services Oriented Architecture), sin que afecte a la implementación de la lógica de negocio en sí.

XFire es el proyecto open source de mayor madurez ymejores resultados para la construcción de web services,teniendo las siguientes características principales:

• Cobertura de los principales estándares : SOAP, WSDL,


1. GSE, SDC

15

J2EE 1.4+


Spring…

Localizador

Local

Remoto

…

RM

IW

eb services

…

…

DA

O


Servicios

De

Negocio

XFireHTTP JMS Local

• Cobertura de los principales estándares : SOAP, WSDL,WS-I Basic Profile, .WS-Addressing, WS-Security, etc…

• Enlaces (bindings ) con componentes POJO, XMLBean,JAXB, Castor.

• Incluye transportes HTTP y JMS.

• Integración directa con Spring .



Integración


Los Servicios de Negocio son codificados como beansestándar de J2EE. Sus características de seguridad, transaccionalidad y distribución pueden ser fijadas de manera declarativa (AOP) sin impactar a la lógica de negocio. Además, al emplearse inyección de dependencias, se facilita enormemente su validación mediante pruebas unitarias, y su exposición como web services .

Inyección AOP


1. GSE, SDC

16

J2EE 1.4+


Spring…

Localizador

Local

Remoto

…

RM

IW

eb services

…

…

DA

O


Servicios

De

Negocio Servicios de Negocio

Inyección de Dependencia

Pruebas Unitarias

DistribuciónXFireHTTP JMS Local



Integración


Se ha creado un patrón específico, denominado DAO (Data Access Object) que permite utilizar diferentes vías de acceso a las fuentes de datos de la aplicación. Se incluyen en la arquitectura, off-the-shelf, el ORM (Object-Relational Mapping) Hibernate , el framework iBATIS y los mecanismos JDBC tradicionales, pudiéndose incorporar otros ORM’s sin impacto para los Servicios de Negocio.


1. GSE, SDC

17

J2EE 1.4+


Spring…

Localizador

Local

Remoto

…

RM

IW

eb services

…

…

DA

O


Servicios

De

Negocio

XFireHTTP JMS Local

Negocio Integración


capa de integración (1/4)

Se proporcionan con la arquitectura tres modos de utilizar bases de datos relacionales:

1. JDBC : El más básico, estándar Java para acceso a bases de datos

2. El siguiente en orden de sofisticación es iBATIS , que se basa en dos componentes:

• iBATIS SQLMaps , que realiza un mapeo básico de objetos con tablas, y encapsula operaciones SQL.

• iBATIS DAO, que proporciona el marco de ejecución para


1. GSE, SDC

18

J2EE 1.4+


Spring

Servicios

De

Negocio

JDBC

DA

O

ORM (Hibernate)

Modelo de Dominio

iBATIS

Conectores

… …Objetos de acceso a datos

• iBATIS DAO, que proporciona el marco de ejecución para utilizar los mapeso de SQLMap.

3. El más completo, un ORM, en concreto, Hibernate , con las siguientes funciones:

• Persistencia transparente , permitiendo que cualquier objeto sea persistente.

• Mapeo Objeto-Relacional basado en ficheros XML de configuración, admitiendo cualquier tipo de relación entre entidades.

• Lenguaje de consultas orientado a objetos, HQL, como dialecto de SQL con polimorfismo, de uso facultativo.

• Integración con JMX (operación) y JTA (transaccionalidad).

• Arquitectura de cachés de dos capas.




Hasta el nacimiento y difusión de los web services como mecanismo homogéneo de integración entre sistemas, se diseñaban y construían componentes específicos ello. La arquitectura incluye los siguientes conectores:

• LDAP v3.0.

• SMTP.

• Documentum .

• Conexión a Host a través de CTG (CICS Transaction Gateway).


1. GSE, SDC

19

J2EE 1.4+


Spring

Servicios

De

Negocio

JDBC

DA

O

ORM (Hibernate)

Modelo de Dominio

iBATIS

Conectores


Gateway).

• AS/400 a través de JTOpen.




Integración

La existencia de un ORM permite la creación de un auténtico Modelo de Dominio que describa el sistema a modelar mediante orientación a objetos.

Hasta este momento, los análisis y diseños realizados mediante modelado OO no tenían reflejo en las clases, interfaces y objetos que finalmente era necesario construir para desarrollar las aplicaciones.

FACTURA

Id0..n


1. GSE, SDC

20

J2EE 1.4+


Spring

Servicios

De

Negocio

JDBC

DA

O

ORM (Hibernate)

Modelo de Dominio

CLIENTE

Id Nombre Dirección

Comprar()

LÍNEA-DETALLE

Id

Cantidad

Id

PRODUCTO

Id

Descripción

1

1 1

iBATIS

Conectores





Partiendo en diseño del Modelo de Dominio, y con el soporte de los componentes DAO, ORM y conectores, los desarrolladores codifican los objetos concretos de acceso a datos con las diferentes operaciones de manipulación de la información.


1. GSE, SDC

21

J2EE 1.4+


Spring

Servicios

De

Negocio

JDBC

DA

O

ORM (Hibernate)

Modelo de Dominio

iBATIS

Conectores


servicios transversales (1/3): seguridad (I)


Presentación IntegraciónNegocio

Seguridad

ACEGI se integra con Spring para poder dotar a la arquitectura de autenticación y autorización de manera declarativa (AOP).

Integrado en el framework, ACEGI proporciona, entre otras, las siguientes capacidades:


1. GSE, SDC

22

J2EE 1.4+

ACEGI

Gestor de Seguridad

capacidades:

• Definición por parametrización de seguridad de beans y HTTP requests.

• Soporte para autenticación HTTP BASIC y HTTP DIGEST .

• Gestión avanzada de claves : encriptado SHA o MD5 off-the-shelf, o integración directa de proveedores de encriptado.

• Información de autorización en diversas fuentes: XMl, JDBC , fichero Properties , LDAP .

• Soporte para certificados X.509.

• Posibilidad de definir políticas por canal (p.ej., servir sólo recursos públicos por HTTP, y privados por HTTPS).

servicios transversales (1/3): seguridad (II)


Presentación IntegraciónNegocio

Seguridad

La arquitectura proporciona un componente especializado (Gestor de Seguridad ) para la autorización sobre los recursos de la capa de presentación .


1. GSE, SDC

23

J2EE 1.4+

ACEGI

Gestor de Seguridad

de presentación .

El objetivo es alcanzar máxima eficiencia haciendo más fáciles a los desarrolladores las tareas de securización de los elementos más relacionados con la operativa de los usuarios, los pertenecientes a la presentación de las aplicaciones. En concreto, se securizan 1) nodos de los flujos de navegación, 2) opciones del Escritorio, y 3) controles JSF.

Este gestor es extensible , para securizar otros elementos de presentación que se incorporen, y adaptable , para emplear diferentes mecanismos y arquitecturas de seguridad.


servicios transversales(2/3): monitorización

MonitorizaciónSeguridad


Los servicios de monitorización y control están basados en JMX (Java Management Extensions) , permitiendo la visualización de atributos y el lanzamiento de métodos de objetos en tiempo de ejecución. Este mecanismo es extremadamente útil para la detección y corrección de incidencias, así como la modificación del comportamiento de las aplicaciones en caliente, tanto en tiempo de desarrollo y pruebas, como en soporte y mantenimiento.

La arquitectura incorpora un mecanismo de arquitectura que permite la monitorización directa de los flujos de navegación y de los servicios de negocio implementados, ofreciendo off-the-shelf una monitorización funcional de las aplicaciones. Esta infraestructura utiliza los recursos que proporciona Spring para la


1. GSE, SDC

24

J2EE 1.4+

Componentes Auxiliares

ACEGI JMX

Configuración dinámica

Trazas Multiidioma Cache

Excepciones

infraestructura utiliza los recursos que proporciona Spring para la gestión de componentes JMX.

Además, JMX cuenta con las siguientes características:

• Es un estándar consolidado para la gestión de aplicaciones J2SE y J2EE.

• Integración con fabricantes : servidores de aplicaciones y componentes de terceras partes incluyen instrumentación JMX.

• Integración transparente con herramientas de gestió n de sistemas : IBM Tivoli , HP OpenView , etc… y consolas propias de los fabricantes para la visualización de la información.

• Independencia de protocolo : diferentes transportes disponibles (RMI, SOAP, …) y adaptadores para otras tecnologías de gestión (SNMP).


servicios transversales(3/3): comp. auxiliares

MonitorizaciónSeguridad


Se proporcionan componentes auxiliares, utilizables por todos los elementos de la arquitectura, que proporcionan funcionalidades comunes:

• Trazas : Permite el registro de trazas a través de distintos canales para un posterior análisis. Jerarquiza trazas, permite varios loggers y recarga en caliente las opciones de trazado.

• Multiidioma : Herramienta para la recuperación de información en múltiples idiomas a partir de un código identificador . Se integra con la capa de presentación y con los componentes de trazas y caché.

• Excepciones : Proporciona las excepciones -tipo del sistema y de la


1. GSE, SDC

25

J2EE 1.4+

Componentes Auxiliares

ACEGI JMX

Configuración dinámica

Trazas Multiidioma Cache

Excepciones

• Excepciones : Proporciona las excepciones -tipo del sistema y de la aplicación , indicando la severidad, clase, sistema, detalle de la excepción, código y descripción.

• Configuración dinámica : Ofrece a otros elementos la posibilidad de recargar en caliente la información plasmada en sus ficheros de configuración, sin necesidad de rearranque del servidor de aplicaciones, ni de la aplicación.

• Caché: Permite el caché de objetos de uso frecuente para optimizar el rendimiento en acceso a los mismos. En la arquitectura se utiliza para

cachear los elementos del diccionario de multiidioma y para las listas de funciones . Se pueden crear nuevos elementos cacheables y gestores para esos elementos.

mapa funcional(1/3)

G. Configuración

Compil.&Despliegue

Cobertura procesos de desarrollo

CVS/Subversion

ANT

Plugins específicos Cobertura JSF

Apoyo al desarrollo en JSF

La arquitectura incluye plug-ins Eclipse que facilitan el manejo de los componentes opne source incorporados en la arquitectura:

• Hibernate Tools: El plugin Hibernate IDE para Eclipse ofrece características avanzadas de gestión de los mapeos O/R basados en ingeniería directa e inversa. Existen otros plugins para MyEclipse y NetBeans.

1.2. Arquitectura de desarrollo

1. GSE, SDC

26

J2EE 1.4+

Eclipse v3+

Compil.&Despliegue

Config.Proyectos

Pruebas unitarias

Pruebas rendimiento

Calidad Sofware

Flujos navegación

ANT

MAVEN

JUnit integr.

JMeter

PMD

Plugin

Hob

erna

te

Spr

ing

XF

ire

Plugins funcionales Eclipse

IDE’s basados en Eclipse

MyEclipse IBM RAD

BEA Workshop

IDE’s no Eclipse

Borland JBuilderOracle JDeveloper

SUN Netbeans


MyFaces, ADF, SunFaces, IBM Faces, JSF1.1 • SpringIDE: El plugin Spring IDE para Eclipse permite administrar de forma sencilla una arquitectura basada en este framework. Existen otros plugins para MyEclipse y NetBeans.

• XFire. El plugin XFire para Eclipse permite la generación de código y otras utilidades propias de la publicación y consumo de servicios web.

mapa funcional(2/3)

G. Configuración

Compil.&Despliegue


CVS/Subversion

ANT




1. GSE, SDC

27

J2EE 1.4+

Eclipse v3+

Compil.&Despliegue

Config.Proyectos

Pruebas unitarias

Pruebas rendimiento

Calidad Sofware

Flujos navegación

ANT

MAVEN

JUnit integr.

JMeter

PMD

Plugin

Hob

erna

te

Spr

ing

XF

ire



MyEclipse IBM RAD

BEA Workshop

IDE’s no Eclipse


SUN Netbeans


MyFaces, ADF, SunFaces, IBM Faces, JSF1.1La arquitectura se adapta a las facilidades proporcionadas por cada entorno de desarrollo (IDE) para la construcción de páginas JSF.

En todo caso, la arquitectura apuesta por la implantación de Eclipse , y ofrece integración directa con otros IDE’s líderes en la cobertura y facilidades en implementación JSF.

mapa funcional(3/3)

G. Configuración

Compil.&Despliegue


CVS/Subversion

ANT



La cobertura de los procesos de desarrollo se detalla en las siguientes diapositivas.


1. GSE, SDC

28

J2EE 1.4+

Eclipse v3+

Compil.&Despliegue

Config.Proyectos

Pruebas unitarias

Pruebas rendimiento

Calidad Sofware

Flujos navegación

ANT

MAVEN

JUnit integrado

JMeter

PMD

Plugin

Hob

erna

te

Spr

ing

XF

ire



MyEclipse IBM RAD

BEA Workshop

IDE’s no Eclipse


SUN Netbeans


MyFaces, ADF, SunFaces, IBM Faces, JSF1.1

cobertura directa de procesos de desarrollo(1/4)

G. Configuración

Compil.&Despliegue


CVS/Subversion

ANT

En las fases iniciales del proyecto, los Arquitectos fijan la estructura básica de los proyectos a desarrollar mediante el uso integrado de 4 piezas en un proceso de integración continua :

• CVS/Subversion como gestores de la configuración del softwar e, con repositorios estructurados según el montaje de entornos y los equipos de trabajo.

• ANT como herramienta de compilación y despliegue .• MAVEN para la configuración y manejo de proyectos J2EE , facilitando la construcción de releases de manera cómoda para los desarrolladores.

• La configuración particular del IDE en uso según la estructura de los proyectos, e integrando las tres herramientas anteriores en un marco de trabajo único.


1. GSE, SDC

29

J2EE 1.4+

Compil.&Despliegue

Config.Proyectos

Pruebas unitarias

Pruebas rendimiento

Calidad Software

Flujos navegación

ANT

MAVEN

Junit integrado

JMeter

PMD

Pintador de flujos

integrando las tres herramientas anteriores en un marco de trabajo único.


G. Configuración

Compil.&Despliegue


CVS/Subversion

ANT

Una arquitectura basada en Spring,que implementa un contendor “ligero” de componentes (sin infraestructura como EJB o servlet), permite la prueba de sus componentes sin tener que iniciar ningún servidor de aplicaciones (contenedores pesados), con lo cual seacelera el desarrollo y se facilita la ejecución de pruebas unitarias, lo que redunda en mayor calidad de código.


1. GSE, SDC

30

J2EE 1.4+

Compil.&Despliegue

Config.Proyectos

Pruebas unitarias

Pruebas rendimiento

Calidad Software

Flujos navegación

ANT

MAVEN

Junit integrado

JMeter

PMD

Pintador de flujos

En la arquitectura se ha integrado JUnit :

• Se ha extenido JUnit para permitir la validación de componentes de arquitectura.

• Se han elaborado casos de pruebas para los módulos principales de la arquitectura.

• Se proporcionan recursos para validar componentes construidos por los desarrolladores:

• Servicios de presentación.• Servicios de negocio.


G. Configuración

Compil.&Despliegue


CVS/Subversion

ANT

En la Arquitectura de Desarrollo se incorporan dos componentes orientados a las pruebas y calidad del software:

• JMeter: Herramienta de test que permite todo hacer pruebas de carga sobre todo tipo de interfaces: web services, JMS, HTTP, FTP, etc…

• PMD: Herramienta de control de código. Detecta problemas como bloques try/catch vacíos, código duplicado, código inalcanzable, etc...,


1. GSE, SDC

31

J2EE 1.4+

Compil.&Despliegue

Config.Proyectos

Pruebas unitarias

Pruebas rendimiento

Calidad Software

Flujos navegación

ANT

MAVEN

Junit integrado

JMeter

PMD

Pintador de flujos


G. Configuración

Compil.&Despliegue


CVS/Subversion

ANT

El Pintador de Flujos permite el modelado de los flujos de navegación de una forma intuitiva. Es una herramienta apta tanto para desarrolladores como para analistas. Permite además definir las autorizaciones sobre los recursos (vistas, servicios) de presentación.

nodo vista

nodo servicio


1. GSE, SDC

32

J2EE 1.4+

Compil.&Despliegue

Config.Proyectos

Pruebas unitarias

Pruebas rendimiento

Calidad Software

Flujos navegación

ANT

MAVEN

Junit integrado

JMeter

PMD

Pintador de flujosSe dispone de un plugin para Eclipse en sus versiones 3.0 y superiores, así como una versión stand-alone basada en Eclipse RCP, lo que permite su uso sobre cualquier entorno de desarrollo utilizado.

nodo servicio

transición

paleta de objetos

propiedades

� Objetivos

� Dentro de las organizaciones, se tiene lanecesidad de contar con herramientas quefaciliten la definición y ejecución de los procesosde negocio propios de dichas organizaciones.

Usuarios del Workflow

Proceso de Negocio

1.3. workflow colaborativo

1. GSE, SDC

33

� Los procesos de negocio de las organizacionesa menudo implican la necesidad de aunar lasactividades humanas, tareas ejecutadas porsistemas y otro tipo de recursos y reglasimplicados en la ejecución de dichos procesos.

Proceso de Negocio

Información del Negocio

� Solución

� Mediante la incorporación de un Workflow colaborativo, la Arquitectura ofrece una solución integradaque permite definir flujos de procesos y asociarlos a elementos y recursos propios de la arquitectura.

� Esta pieza permite a las organizaciones tener disponible y estructurada la información que conformansus procesos, y monitorizar la actividad de dichos procesos. También les permite ahorrar costes en lapuesta en marcha de nuevos procesos (time to market) y en la modificación de los ya existentes.

IntegraciónPresentación Negocio

mapa de arquitectura(1/4)

Servicios

La Arquitectura incluye la integración directa entre el motor deworkflow y el Motor de Navegación de la capa de Presentación,gracias a los siguientes mecanismos propios del flow :

• Un componente JSF a medida “Tasks Pending ” o “Inbox ” quemuestra automáticamente un listado paginado de las Tareas deworkflow a la espera de acción por parte del usuario activo en lasesión en ejecución.


1. GSE, SDC

34

J2EE 1.4+

JSF


Spring

…

…

Vistas/

Serv. Presentación

Controles

JSF


…

EJB2 JDBC

…

Flujos de Navegación

…Servicios de Negocio

Local/RMI/Web Services

Localizador

Integración WorkflowO

RM

(H

ibernate)

jBPM

…Workflows colaborativos

• Los workflows que un usuario puede lanzar en virtud de su perfilestán arquitecturizados como entradas del Menú del Escritoriode la capa de presentación de la arquitectura . De esta manerael usuario no percibe diferencia entre un flujo de navegación y unworkflow, ya en su lanzamiento son operativamente lo mismo.



Servicios

El flow tiene incorporada la capacidad de lanzar flujos denavegación , diseñados por analistas y desarrolladores, desde losprocesos de negocio.


1. GSE, SDC

35

J2EE 1.4+

JSF


Spring

…

…

Vistas/

Serv. Presentación

Controles

JSF


…

EJB2 JDBC

…




Localizador


RM

(H

ibernate)

jBPM




Servicios

Desde los workflows diseñados en flow se puedelanzar servicios de negocio propios de laarquitectura. Se cuenta con recursos propios parala sincronización del contexto del workflow y dela arquitectura. Además se dispone de un módulode Spring que permite la ejecución de beans desdetareas automáticas del workflow.


1. GSE, SDC

36

J2EE 1.4+

JSF


Spring

…

…

Vistas/

Serv. Presentación

Controles

JSF


…

EJB2 JDBC

…




Localizador


RM

(H

ibernate)

jBPM




Servicios

En flow los procesos de negocio se construyen gráficamentegracias al plug-in Eclipse incorporado:


1. GSE, SDC

37

J2EE 1.4+

JSF


Spring

…

…

Vistas/

Serv. Presentación

Controles

JSF


…

EJB2 JDBC

…




Localizador

Integración Workflow

OR

M

(Hibernate)

jBPM


Task Node : Nodo de tarea “manual”,que necesita de interacción humnaa.

Fork y Join : los procesos pueden incluirdiferentes flujos de eejcución paralela.

Node : Nodo de tarea “automática”, quelanza un servicio de la arquitectura.

Índice

1.- GSE, SDC




2.- Bus



38



3.- Rep. Documental

3.1.- Alfresco

3.2.- Integración


4.1.- Arquitectura

2.1. Elementos básicos. Transportes.

2. Bus

Los transportes son los elementos responsables del transporte de mensajes de una aplicación a otra dentro delframework de Mule.

CXF: El transporte Mule CXF provee soporte a la integración de Servicios Web vía Apache CXF. Estos serviciossoportan una variedad de protocolos como SOAP, XML/HTTP, RESTful HTTP, o CORBA y trabajan con unavariedad de transportes como HTTP, JMS o JBI.

JMS: El transporte de Mule para la conectividad por JMS. Mule en si no es un servidor de JMS, pero puede utilizarlos servicios de cualquier servidor compatible con JMS 1.1 o 1.02b.

VM: El transporte VM se utiliza para comunicaciones internas entre componentes gestionados por Mule. Este

39

VM: El transporte VM se utiliza para comunicaciones internas entre componentes gestionados por Mule. Esteconector provee opciones para gestionar colas persistentes o no.

2.1. Elementos básicos. Transportes.

2. Bus

Los conectores son el núcleo central de los transportes. El conector mantiene la configuración y el estado de untransporte.

Cuando se recibe un mensaje , el conector utiliza un receptor de mensaje (message receiver), el cual lee losdatos, los empaqueta como un mensaje y pasa dicho mensaje al punto de entrada (inbound router) del servicio.

Al enviar mensajes , el conector utiliza un distribuidor de mensajes (message dispatcher), el cual recibe elmensaje y las instrucciones de enrutamiento del router del punto de salida (outbound router) del servicio y envía elmensaje al siguiente componente o aplicación.

40

2.1. Elementos básicos. Transformadores.

2. Bus

Los transformadores se encargan de transformar los mensajes que un servicio recibe o envía. Se asocian a losendpoints y su funcionamiento varía ligeramente en función del tipo de endpoint en el que aparezca:

Inbound : Si el transformador aparece en un inbound endpoint, entonces el mensaje que se reciba por dichoendpoint sufrirá la transformación antes de continuar la ejecución del servicio.

Outbound : Si el transformador aparece en un outbound endpoint, entonces el mensaje sufrirá la transformaciónjusto antes de ser enviado por el endpoint.

41

2.1. Elementos básicos. Transformadores.

2. Bus

Mule posee una serie de transformadores predefinidos que pueden ser utilizados desde el fichero deconfiguración XML sin necesidad de implementación de código adicional.

42

2.1. Elementos básicos. Routers.

2. Bus

Los routers son los elementos utilizados para determinar a qué puntos se debe enviar el mensaje para continuarcon el flujo de ejecución. Estos elementos gestionan cuál o cuales van a ser los endpoints a los que se va a enviarel mensaje.

Un router básicamente define cómo los mensajes van a ser enviados y recibidos por los componentes del sistema.En Mule se pueden definir inbound routers que se aplican a los mensajes al ser recibidos, y outbound routersque son invocados cuando un mensaje va a ser enviado.

Mule provee un soporte flexible para el enrutamiento de los mensajes entre los componentes.

Las características de enrutamiento están basadas en los requisitos de enrutamiento definidos en los patrones

43

Las características de enrutamiento están basadas en los requisitos de enrutamiento definidos en los patronesdescritos por EIP (ENTERPRISE INTEGRATION PATTERNS).

Para más información sobre estos patrones visitar su página oficial en la web:

http://eaipatterns.com/

Mule ofrece dos tipos básicos de routers: los predefinidos (que ya tiene una funcionalidad preestablecida que seadapta a los patrones antes mencionados), y los definidos por el usuario o propios .

2.1. Elementos básicos. Routers.

2. Bus

Existe una serie de routers predefinidos en Mule que aportan esquemas de enrutamiento básicos fácilmenteutilizables y adaptables:

Pass-Through Router : Este router es el utilizado cuando no se quiere especificar ningún algoritmo deenrutamiento. Simplemente se define un endpoint que será el que se utilice para continuar con la ejecución delservicio.

Filtering Router: Se define un filtro por cada endpoint y la llamada a dicho endpoint está condicionada alcumplimiento de la condición del filtro asociado. Puede haber varios endpoints con sus correspondientes filtros.

Chaining Router : Se definen varios outbound endpoints. Se llaman a estos endpoints de forma secuencial y la

44

Chaining Router : Se definen varios outbound endpoints. Se llaman a estos endpoints de forma secuencial y lasalida de un endpoint es la entrada del siguiente. Este tipo de router es el apropiado para definir una secuencia fijade acciones a realizar de forma secuencial.

Multicasting Router : Se definen varios outbound endpoints. Se llama a todos estos endpoints en paralelo, esdecir, se llama a todos a la vez pasándoles a todos el mismo mensaje inicial.

Filtering XML Message Splitter : Se trata de un router específico para trabajar con XML. Se definen variosoutbound endpoints. Mule divide el XML en los nodos que lo componen. Este router permite definir un endpoint conun filtro correspondiente para cada uno de los nodos resultantes de la descomposición del XML.

2.1. Elementos básicos. Contratos de integración.

2. Bus

Los contratos de integración definen el formato en que se van a intercambiar los datos entre los distintoscomponentes y el bus de integración . Existen dos puntos principales de comunicación:

� Los puntos de entrada de los componentes : en estos puntos se recibe una petición por parte de uncomponente de la plataforma para la ejecución de un servicio y se devuelve una posible respuesta a dichocomponente, con información relativa al resultado de la ejecución de dicho servicio.

� Los servicios básicos de los componentes : en estos puntos el bus de integración realiza una llamada a uncomponente de la plataforma para solicitar la ejecución de u n método . Además, puede recibir unarespuesta de dicho componente con información sobre la ejecución de dicho método.

45

Los contratos de integración se basan principalmente en definiciones de servicios web contenidas en ficherosWSDL. Se define un fichero WSDL por componente. En dicho fichero WSDL se especifica cada uno de losservicios web correspondientes a cada uno de los servicios básicos que contiene dicho componente.

Por cada uno de estos servicios web, se especifica el formato de la llamada por parte del servicio básico Mule almétodo del componente y la respuesta de éste. En ambos casos, se definen los parámetros de la llamada y larespuesta, especificando el tipo y nombre de cada uno de ellos.

En lo referente al punto de entrada del componente, éste acepta cualquier llamada que se realice a cualquiera desus servicios básicos. Es por esto por lo que en este punto no habrá un contrato de integración específico, sino lasuma de los contratos de los servicios básicos del componente.

2.2. Servicios Mule.

2. Bus

En un servicio se especifica el punto de entrada en el que se va a leer el mensaje de entrada, el punto de salida alque se va a enviar, el componente del servicio, así como los transformadores, routers y filtros que se van a aplicaren la ejecución de dicho servicio.

Un componente de servicio en Mule puede ser una clase java, un servicio web, un bean de Spring u otraaplicación que contiene la lógica de negocio que se quiere introducir en el framework de Mule.

Un servicio envuelve el componente de servicio aportando la configuración para gestionar los mensajes de entraday salida de dicho componente de servicio.

Los servicios son el principal artefacto de Mule para implementar soluciones de integración .

46

Los servicios son el principal artefacto de Mule para implementar soluciones de integración .

2.2. Servicios Mule. Servicios de punto de entrada para componentes.

2. Bus

Se define un servicio Mule por cada uno de los métodos del componente habilitante de la plataforma a los quese quiera acceder. Este servicio controla el acceso a dicho componente y actúa de conector con él.

Asimismo, por cada componente habilitante de la plataforma se define un servicio Mule adicional que actúacomo punto de entrada de todas las llamadas a dicho componente habilitante y como dispatcher hacia losservicios Mule que actúan como conectores de los métodos de dicho componente habilitante.

47

2.2. Servicios Mule. Servicios de punto de entrada para componentes.

2. Bus

En el punto de entrada de estos servicios está expuesto mediante CXF el servicio web ofertado para comunicarel resto de componentes habilitantes con este componente.

De esta forma, todas las peticiones que lleguen al servicio web que actúa como punto de entrada de cadacomponente del BUS se gestiona por su correspondiente servicio de punto de entrada.

En caso de ser necesaria una transformación de los datos para acoplarlos a los requisitos de los servicios delcomponente, es en el Inbound de este servicio de punto de entrada donde se debe definir el transformadorapropiado.

Estos servicios tienen un componente de servicio definido mediante un bean de Spring para centralizar en un

48

Estos servicios tienen un componente de servicio definido mediante un bean de Spring para centralizar en unúnico punto del componente temas de seguridad y validación de mensajes . Además, estos servicios tiene lamisión de actuar como dispatchers.

Estos servicios de punto de entrada tienen definidos una serie de routers de tipo en su outboundendpoint. Estos routers determinan el servicio que debe ser invocado a continuación para procesar elmensaje basándose en el contenido o tipo de dicho mensaje.

En caso de que no se cumpla ninguna de las condiciones definidas en estos filtering-routers, entonces se asumeque el mensaje de entrada es inválido y se produce un error. Este caso se controla mediante el uso de una de lasestrategias de excepciones.

2.2. Servicios Mule. Servicios básicos.

2. Bus

Estos servicios son los encargados de realizar las llamadas a los métodos de los componentes habilitantescorrespondientes. Existe uno de cada uno de estos métodos por cada método existente en el componentehabilitante correspondiente.

Estos servicios solo pueden ser llamados por los servicios de punto de entrada y los servicios compuestos de esemismo componente, por lo que en sus Inbound routers solo se pueden utilizar los transportes VM y JMS .

El VM es para las llamadas síncronas mientras que el JMS se utiliza en los casos en los que no se necesitasincronía y el mensaje se va a almacenar en una cola a la espera de ser procesado.

Puesto que estos servicios son invocados de forma interna y, por lo tanto, se ha comprobado previamente la

49

Puesto que estos servicios son invocados de forma interna y, por lo tanto, se ha comprobado previamente lavalidez del mensaje , no es necesario que en el Inbound router se defina un filtro para validar que el tipo demensaje recibido se corresponde con el esperado.

Estos componentes sí que pueden necesitar del uso de un componente de servicio para realizar parte de lalógica del servicio (abrir conexiones con el componente habilitante que alberga el servicio, iniciar sesiones, etc.).Para ello se define un bean de Spring con la siguiente nomenclatura:

_

2.2. Servicios Mule. Servicios básicos.

2. Bus

Para el enrutamiento de los mensajes existen dos posibilidades:

� Enrutamiento estático : la dirección en la que se encuentra el método del componente habilitante es fija y novaría en función de la entidad local en la que se esté realizando el trámite que ha provocado la llamada aeste servicio.

En ese caso se define un router del tipo , dentro del cual está definido el endpoint quegestiona la llamada al método correspondiente del componente habilitante.

� Enrutamiento dinámico : la dirección en la que se encuentra el método del componente habilitante varía enfunción de la entidad local en la que se esté realizando el trámite que ha provocado la llamada a este

50

función de la entidad local en la que se esté realizando el trámite que ha provocado la llamada a esteservicio.

En este caso se define un custom-router en el cual existe un endpoint que hace uso del mecanismo deresolución de direcciones.

2.2. Servicios Mule. Servicios compuestos.

2. Bus

Los servicios compuestos son aquellos que agrupan la ejecución de varios servicios básicos que afecten auno o varios componentes. Existe un servicio compuesto por cada servicio de negocio existente.

51

2.2. Servicios Mule. Servicios compuestos.

2. Bus

Los servicios compuestos están en un nivel superior al de los componentes Mule y son externos a estos. Estoquiere decir que un servicio compuesto puede llamar a servicios de distintos componentes , para lo cual llamaen cada caso al servicio de punto de entrada del componente al cual pertenezca el servicio.

Para esto, el servicio compuesto tiene una configuración parecida al servicio de punto de entrada en su partede entrada (Inbound router). Oferta un servicio web mediante CXF y dispone de transformadores para una posibleconversión del mensaje y de un componente de servicio para la gestión de la seguridad y la validación demensajes.

La principal diferencia radica en la parte del enrutamiento del mensaje de salida En los servicios compuestos seutilizan los siguientes tipos de routers:

52

utilizan los siguientes tipos de routers:� Chaining Router.� Multicasting Router.� Filtering XML Message Splitter.

Con estos routers se pueden configurar las distintas posibilidades a la hora de componer servicios. Además, sepermite la posibilidad de combinar en un mismo servicio varios de estos routers para poder realizarcomposiciones más complejas. De esta forma, se puede utilizar un para realizar un envío avarios métodos al tiempo que se inicia una secuencia de acciones con un .

Esto permite tener una mayor flexibilidad a la hora de poder definir los distintos servicios compuestos que sederiven de los servicios de negocio.

2.3. Servicios horizontales. Seguridad.

2. Bus

Los servicios del bus a los que puede acceder un componente de la plataforma o un BackOffice están limitados:sólo pueden acceder a los servicios definidos en su componente Mule , a determinados servicios compuestos ya los servicios de punto de entrada de los componentes Mule que contengan los servicios básicos que formanparte de los servicios compuestos a los que este componente de la plataforma o BackOffice puede llamar.

La llamada de un componente de la plataforma o un BackOffice se realiza al punto de entrada del componentedonde se encuentra el servicio básico. En este punto de entrada se comprueba si el componente de laplataforma o BackOffice tiene acceso al servicio.

Cuando un componente de la plataforma o un BackOffice llaman a un servicio compuesto, dicho serviciocompuesto llama al punto de entrada del componente Mule en el cual se encuentra el primer servicio básico a

53

compuesto llama al punto de entrada del componente Mule en el cual se encuentra el primer servicio básico allamar. Así sucesivamente, por cada uno de los servicios básicos que forman el servicio compuesto. Lacomprobación de seguridad se realiza en los puntos de entrada del servicio compuesto y de los componentesque albergan los distintos servicios básicos a llamar.

En este caso el componente de la plataforma o BackOffice debería tener acceso a todos los componentes Muleque intervienen en la ejecución de los servicios compuestos sobre los que tiene permiso.

Para ello se define un fichero XML en el cual se especifican los servicios Mule accesibles desde fuera de lbus (servicios de punto de entrada de los componentes y servicios compuestos) y los componentes de laplataforma o BackOffice que tienen acceso a dichos servicios.

En los puntos de entrada de los componentes se establece el mecanismo de consulta de este fichero XMLpara la gestión de la seguridad y los permisos de acceso a los servicios.

2.3. Servicios horizontales. Transaccionalidad.

2. Bus

De los tres transportes que se van a utilizar (JMS, VM y CXF), tan solo soportan la transaccionalidad lostransportes VM y JMS, el CXF no la soporta. Puesto que la mayoría de conectores van a ser llamadas a serviciosweb mediante CXF, esto hace que la transaccionalidad se tenga que tratar en algunos casos de forma manual :

� Se ejecuta un servicio básico que sólo utiliza transportes transaccionales . En este caso latransaccionalidad se puede gestionar de forma automática .

� Se ejecuta un servicio compuesto que está formado por servicios básicos que tan sólo utilizan transportestransaccionales . En este caso la transaccionalidad se puede gestionar de forma automática .

� Se ejecuta un servicio básico que utiliza transportes no transaccionales . El servicio modifica el estado de

54

� Se ejecuta un servicio básico que utiliza transportes no transaccionales . El servicio modifica el estado dealgún objeto. En este caso se debe proveer un mecanismo para deshacer de forma manual los cambiosrealizados por el servicio y revertir el objeto modificado a su estado original.

� Se ejecuta un servicio básico que utiliza transportes no transaccionales . El servicio no modifica el estadode ningún objeto. En este caso no es necesario proveer ningún mecanismo manual para gestionar latransaccionalidad puesto que no hay ninguna modificación de estado que revertir.

� Se ejecuta un servicio compuesto que está formado por servicios básicos que tan sólo utilizan transportesno transaccionales . Alguno de los servicios básicos que lo componen modifica el estado de algún objeto. Eneste caso hay que proveer de un mecanismo manual para deshacer los cambios realizados por los servicios.

� Se ejecuta un servicio compuesto que está formado por servicios básicos que tan sólo utilizan transportesno transaccionales . Ninguno de los servicios básicos que lo componen modifica el estado de ningún objeto.En este caso no es necesario proveer ningún mecanismo manual para gestionar la transaccionalidad.

2.3. Servicios horizontales. Transaccionalidad.

2. Bus

En cuanto al mecanismo manual a utilizar para revertir los cambios realizados, una opción es disponer deservicios que hagan lo contrario que aquellos que se desean revertir. De esta forma, en caso de fallar la llamadaa un servicio básico que forme parte de un servicio compuesto, lo que se debería hacer es recorrer los serviciosbásicos ya ejecutados de dicho servicio compuesto en orden inverso llamando a los servicios contrarios a los quese habían llamado. De esta forma se haría un roll-back manual .

En caso de tratarse de un servicio básico, simplemente habría que capturar el posible error y en ese caso llamar alservicio que revierta los cambios.

Tan solo haría falta deshacer aquellos servicios que hayan modificado el estado de algún objeto. Hay serviciosque no es necesario deshacer pues su ejecución no modifica nada . Por otro lado hay que estudiar si hay algún

55

que no es necesario deshacer pues su ejecución no modifica nada . Por otro lado hay que estudiar si hay algúnservicio que no puede ser deshecho por algún motivo en concreto.

2.3. Servicios horizontales. Resolución dinámica de direcciones.

2. Bus

En la ejecución de un servicio correspondiente a una tramitación que tiene lugar en una determinada entidad local,se debe obtener la dirección en la que dicha entidad local tiene disp onibles los componentes habilitantesde forma dinámica para poder llevar a cabo la ejecución de dicho servicio.

Los principios básicos del funcionamiento de este mecanismo se detallan a continuación:

� Definición de los datos . Se define un archivo XML en el que se detalla por cada Entidad local la dirección enque se encuentra cada uno de sus componentes, además de algunos datos identificativos de dicha entidadlocal como son el código, nombre y provincia a la que pertenece.

� Configuración del mecanismo . Existe un proyecto Java que sólo contiene el fichero de datos de entidades

56

� Configuración del mecanismo . Existe un proyecto Java que sólo contiene el fichero de datos de entidadeslocales XML arriba descrito y una clase estática con un único método que es el encargado de consultar endicho fichero de datos la dirección a utilizar.

Este método consulta mediante XQueries el fichero XML de datos y devuelve un String con la dirección delcomponente solicitado.

� Utilización del mecanismo . En el caso de necesitar un enrutamiento dinámico y por lo tanto tener que haceruso de este mecanismo, se define un . Este tipo de roter permite referenciar a un bean Springpara que dicho bean se encargue de gestionar cuál va a ser el endpoint de salida.

El bean Spring referenciado realiza una llamada al servicio estático de obtención de la ruta y define unendpoint a partir de la ruta que este servicio le devuelva. Posteriormente envía el mensaje por dicho endpointpara continuar con la ejecución del servicio.

Índice

1.- GSE, SDC




2.- Bus



57



3.- Rep. Documental

3.1.- Alfresco

3.2.- Integración


4.1.- Arquitectura

3.1. Alfresco.

3. Rep. Documental

Alfresco es un producto software que extiende la Gestión Documental para dar respuesta al ciclo de vida de formaíntegra no solo los documentos sino de todos los contenidos de una organización, independientemente de sunaturaleza. Al mismo tiempo, Alfresco es una plataforma software sobre la que se puede desarrollar e integrarsecon otros productos, soluciones y plataformas.

58

3.1. Alfresco.

3. Rep. Documental

Alfresco es una solución 100 % Software Libre , basada en estándares abiertos de última generación, que ofrece:

� Gestión documental.

� Gestión de contenido web: mediante el gestor documental Alfresco WCM.

� Colaboración.

� Gestión de registros: permitiendo la tramitación de expedientes, documentos a través de los flujos detramitación que se definan.

59

� Servicio de interoperabilidad y gestión de contenidos (CMI S): los proveedores de ECM han elaborado unborrador de la especificación CMIS, con el objetivo de ofrecer y permitir la interoperabilidad entre distintosrepositorios de contenido. El borrador de la especificación cuenta con el respaldo de Alfresco, EMC, IBM,Microsoft, OpenText, Oracle y SAP.

� Gestión de imágenes: Alfresco está integrado con Kofax Ascent Capture. Alfresco permite la captura engrandes cantidades de imágenes, corrección y mejora automáticos de la imagen, certificado para trabajar conla mayoría de scanners en producción, herramientas para el tratamiento y conversión de imágenes mediante elframework ImageMagick.

3.1. Alfresco.

3. Rep. Documental

El Gestor Documental (ECM) Alfresco incluye un repositorio de contenidos a escala empresarial, portlets JSR-168 para la gestión y utilización del contenido, así como un interfaz CIFS (Common Internet File System) queofrece compatibilidad con el sistema de archivos de Microsoft Windows.

Alfresco ha sido desarrollado utilizando las últimas tecnologías Java , incluyendo Jboss Application Server 4.0,JBoss Portal 2.0, Spring 1.2, Hibernate 3.0, MyFaces 1.0, Lucene 1.4 y Java 1.5. La versión lanzada por Alfrescoofrece capacidades de gestión de contenidos empresariales en portales compatibles con JSR-168 y JBoss Portal2.0. La intención de este producto es hacer asequible a todo el mundo la gestión de contenidos empresarial.

El soporte al estándar CIFS permite a los usuarios un fácil acceso al repositorio de contenidos empresariales. Elsistema de Alfresco es el primer sistema en código abierto que incluye el soporte a este estándar. CIFS permite a

60

sistema de Alfresco es el primer sistema en código abierto que incluye el soporte a este estándar. CIFS permite alos usuarios acceder al repositorio de Alfresco como si estuvieran accediendo a un disco compartido, permitiendoasí la sincronización off-line y el acceso desde cualquier aplicación. Un motor basado en reglas ofrece ademásversionado, clasificación y control automático, eliminando el trabajo manual asociado a los sistemas de gestión decontenidos.

3.1. Alfresco.

3. Rep. Documental

Se estructura en torno a un Repositorio de Contenidos único , gestionando el almacenamiento de la informaciónen cualquiera de sus formatos nativos, indexando (Full-text Indexes) y categorizando los contenidos para su rápidabúsqueda y localización, almacenando los metadatos en sistemas de Gestión de Bases de Datos (DBMS).

61

3.1. Alfresco.

3. Rep. Documental

Alfresco dispone de un sistema virtual de ficheros para acceder a los documentos y contenidos almacenados enel repositorio, bien a través de FTP, CIFS o WebDAV. Existe alta disponibilidad del sistema basada en estándares.

Existe además múltiples interfaces de integración con aplicaciones y servicios: Integración a nivel de Sistema deMensajería con Servidores de Aplicaciones, Integración con Portales del Conocimiento a través de Servidores dePublicación de Portales, Integración con CRM y Motores de Reglas de Proceso de Negocio a través de WSs, etc.

A su vez, Alfresco está basado en Estándares Abiertos : JSR-170, JSR-283, JSR-168, BPEL. Es el primer gestorde contenidos que utiliza normas y estándares abiertos para implementar tanto el propio gestor documental, comolas API’s e interfaces de acceso al mismo.

62

La arquitectura del producto se sustenta sobre estándares de facto en el conjunto de tecnología de código abierto,permite intercambiar elementos y reemplazarlos según las preferencias de la implantación. La configuraciónrecomendada se basa en la elección de los siguientes componentes en función de un exhaustivo estudio delestado del arte de las tecnologías de Código abierto:

� Middleware de capa de negocio basado en Spring , un framework de integración para aplicaciones J2EE quepermite modelar e implementar sistemas cooperativos de negocio mediante Javabeans, o EJB.

� Hibernate es una abstracción del modelo de acceso a los datos, integra diversas tecnologías de acceso afuentes como bases de datos relaciones, LDAP, etc.

� Lucene es un indexador que permite realizar búsquedas extremadamente eficientes sobre cualquier medio dealmacenaje. Específicamente utilizado sobre sistema de archivos.

� Web-Services , permiten la fácil integración de servicios con aplicaciones de terceros o con plataformasmediante estándares de mercado.

3.1. Alfresco.

3. Rep. Documental

Alfresco está construido sobre herramientas, plataformas y estándares basados en Open Source , de tal formaque se pueden construir y extender frameworks para la Gestión Documental y Gestión Empresarial de Contenidos:

� Spring . Framework de aplicaciones J2EE flexible, basado en el modelo vista controlador, que consta de uncontenedor ligero, una capa de abstracción común para la gestión de transacciones, una capa de abstracciónJDBC e integración con los principales entornos de trabajo.

� Hibernate . Entorno de trabajo que tiene como objetivo facilitar la persistencia de objetos Java en bases dedatos relacionales y al mismo tiempo la consulta de estas bases de datos para obtener objetos.

� Lucene . Es un API de desarrollo eficiente, versátil y robusta para indexación y búsqueda, escrita en Java,

63

� Lucene . Es un API de desarrollo eficiente, versátil y robusta para indexación y búsqueda, escrita en Java,multiplataforma y escalable que incluye algoritmos de búsqueda multi-índice, combinación de resultados yordenación por cualquier campo.

� Estándar JSR (Java Specification Request) 168 . Estándar que permite que cualquier desarrollo realizado enun Servidor de portales pueda ser instalado en cualquier plataforma del mercado mediante la interoperabilidadentre portlets y portales. Define una serie de APIs para los portlets y hace estándar las preferencias,información del usuario, instalación y seguridad.

� Estándar JSR (Java Specification Request) 170 . Define un interfaz estándar para acceder a un repositoriode contenidos desde un portlet: cualquier portlet desarrollado podrá utilizarse independientemente delproveedor de gestor de contenidos implantado.

� MyFaces . Implementación Open Source de la tecnología JavaServer Faces (JSR 127). JavaServer Faces esun marco de trabajo para aplicaciones Web basadas en J2EE que facilita de forma significativa la tarea de laconstrucción y mantenimiento de interfaces de usuario del lado del servidor.

3.1. Alfresco.

3. Rep. Documental

� Programación orientada a Aspectos (POA) . Paradigma de programación cuya intención es permitir unaadecuada modularización de las aplicaciones y posibilitar una mejor separación de conceptos. Gracias a laPOA se pueden capturar los diferentes conceptos que componen una aplicación en entidades bien definidas,de manera apropiada en cada uno de los casos y eliminando las dependencias inherentes entre cada uno delos módulos. De esta forma se consigue razonar mejor sobre los conceptos, se elimina la dispersión del códigoy las implementaciones resultan más comprensibles, adaptables y reusables.

� Web Services . Colección de protocolos y estándares que sirve para intercambiar datos entre aplicaciones.Distintas aplicaciones desarrolladas en lenguajes de programación diferentes y ejecutadas sobre cualquierplataforma pueden utilizar los servicios web para intercambiar datos.

64

� BPEL (Business Process Execution Language) . En castellano Lenguaje de Ejecución de Procesos deNegocio es un lenguaje XML diseñado para la orquestación de servicios web, entendiendo como orquestaciónel control centralizado de la invocación de diferentes servicios web, con cierta lógica de negocio añadida. Através de un documento XML BPEL, un analista de negocio es capaz de representar la lógica asociada y loselementos con los que se verá relacionado. Estos elementos serán servicios web y la lógica el proceso BPEL.

� Basado en Linux, Windows, AppleOS o Unix.

Estos estándares proporcionan características que favorecen reutilización de código y portabilidad entre proyectos:� Multiplicidad de Sistemas Operativos.

� Multiplicidad de Portales a través del estándar JSR 168.

� Sistemas de Gestión de Múltiples Contenidos a través del estándar JRS 170.

� Integración con Aplicaciones Corporativas vía Web Services.

3.2. Integración.

3. Rep. Documental

Para el desarrollo de este componente se han elaborado dos capas diferentes que interactúan entre sí comoveremos a continuación. De esta forma tenemos un “componente-alfresco” y un “AlfrescoService”.

65

3.2. Integración.

3. Rep. Documental

Como se observa en la imagen anterior, el “componente-alfresco” se trata de una librería que ofrece un conjunto demétodos que actúan de fachada entre los servicios web que proporciona Alfresco a través de su Api y el propio“AlfrescoService” cuyos servicios web se pretenden publicar. Al ser la Api de Alfresco de muy bajo nivel, se hacreído conveniente abstraer éstas operaciones en métodos o funciones más complejas con el fin de ofrecer unaserie de métodos realmente útiles a la hora de trabajar con el repositorio documental. De esta forma, con el“componente-alfresco” ofrecemos una Api mucho más elaborada que la que nos ofrece el propio Alfresco.

66

El componente “AlfrescoService” se ha desarrollado de forma “Contract-first” y ofrece un conjunto de servicios webque cumplen con los requisitos definidos en el documento de requisitos que acompaña a la documentación delcomponente y que están orientados a la gestión documental de los documentos relacionados con expedientes,documentos asociados a registros de entrada/salida y documentos de firmas de uno u otro caso. Este conjunto deservicios web que ofrece para la gestión documental será el que utilice el BUS de integración de la diputacióncorrespondiente.

3.2. Integración.

3. Rep. Documental

Dicho componente está elaborado con los frameworks Apache CXF y Spring.

� Apache CXF . Apache CXF es un framework open source de servicios. CXF te ayuda a construir y desarrollarservicios usando APIs de programación de alto nivel, como JAX-WS. Estos servicios pueden soportar variosprotocolos como SOAP, XML/HTTP, RESTful HTTP, o CORBA y funcionar sobre una variedad de capas detransporte como HTTP, JMS o JBI.

CXF incluye un amplio conjunto de características, pero su objetivo principal son las siguientes áreas:

– Soporte de Standards de Web Services : CXF da soporte a una variedad amplia de estandars deservicios web incluyendo SOAP, WSI Basic Profile, WSDL, WS-Addressing, WS-Policy, WS-

67

servicios web incluyendo SOAP, WSI Basic Profile, WSDL, WS-Addressing, WS-Policy, WS-ReliableMessaging, y WS-Security.

– Interfaces : CXF proporciona una variedad de modelos de programación de alto nivel. Incluye uno JAX-WS 2.1. También uno sencillo que permite la creación de clientes y endpoints sin anotaciones.

– Modo de uso : CXF está diseñado para un uso sencillo e intuitivo. Hay una API sencilla para rápidamenteconstruir por primera vez código de servicios, plugins de Maven para realizar la integración más sencilla,soporte para la API de JAX-WS, soporte XML para Spring 2.0.

3.2. Integración.

3. Rep. Documental

� Spring . Spring es un framework de aplicaciones J2EE flexible, basado en el modelo vista controlador, queconsta de un contenedor ligero, una capa de abstracción común para la gestión de transacciones, una capa deabstracción JDBC e integración con los principales entornos de trabajo. Para el desarrollo de este componentese ha integrado Apache CXF con Spring para poder crear y acceder a servicios web de una forma flexible ymuy simple.

� Junit . Framework que permite realizar la ejecución de clases Java de manera controlada, para poder evaluarsi el funcionamiento de cada uno de los métodos de la clase se comporta como se espera. Es decir, en funciónde algún valor de entrada se evalúa el valor de retorno esperado; si la clase cumple con la especificación,entonces JUnit devolverá que el método de la clase pasó exitosamente la prueba; en caso de que el valoresperado sea diferente al que regresó el método durante la ejecución, JUnit devolverá un fallo en el método

68

esperado sea diferente al que regresó el método durante la ejecución, JUnit devolverá un fallo en el métodocorrespondiente. JUnit es también un medio de controlar las pruebas de regresión, necesarias cuando unaparte del código ha sido modificado y se desea ver que el nuevo código cumple con los requerimientosanteriores y que no se ha alterado su funcionalidad después de la nueva modificación.

Índice

1.- GSE, SDC




2.- Bus



69



3.- Rep. Documental

3.1.- Alfresco

3.2.- Integración


4.1.- Arquitectura

4.1. Arquitectura.

4. Carpeta Ciudadana

Portal AAEE

Contenidopúblico

Contenido

protegido

Administración

Servicios

transaccionales

Capa integración

70

Secciones informativas

Gestión deContenidos

Oficina Virtual

Apache Tomcat

4.1. Arquitectura.


Servidor de aplicaciones: Tomcat 6

Como plataforma tecnológica de la arquitectura se utiliza Apache Tomcat 6.

Apache Tomcat es un contenedor de servlets sobre Java 5 que implementa la especificación Servlet 2.5 y JSP 2.1de Sun Microsystems.

Las principales características de Apache Tomcat son las siguientes:

• Código Abierto. Es software de código abierto publicado bajo licencia Apache Software Licence.

• Base instalada. El servidor Web de Apache es la plataforma web con más base instalada (50% según elúltimo informe Netcraft *).

71

último informe Netcraft *).

• Madurez. Apache Tomcat mantiene un desarrollo activo desde 1999, con continuas mejoras enfuncionalidad y estabilidad.

• Soporte. Existe una gran comunidad de usuarios y desarrolladores soportando Apache Tomcat y muchosproductos comerciales lo utilizan como servidor de aplicaciones, lo que garantiza su viabilidad.

• Extensibilidad. Extensiones permiten a Tomcat la utilización de EJBs o la configuración de clusters paraalta disponibilidad.

• Adecuación a los estándares. Apache promueve la definición y uso de estándares. Esto garantiza laindependencia de la plataforma y por tanto permite la migración a otra plataforma técnica en el futuro, tantolibres como como JBoss o Sun Glassfish, o comerciales como IBM Websphere, etc.

4.1. Arquitectura.


Gestor de contenidos: OpenCms 6.2.3

El componente tecnológico de base para construir el Portal Web es la última versión estable del conocido gestor decontenidos en software libre OpenCms. Actualmente es la versión 6.2.3.

La utilización de OpenCms permite trabajar con el Portal Web a través de cualquier dispositivo que proporcioneacceso a un navegador web, es decir, ordenadores personales, PDAs, teléfonos, etc.

72

4.1. Arquitectura.


Gestor de contenidos: OpenCms 6.2.3

OpenCms permite mantener un sistema de información web con gran facilidad, de tal forma que la asistencianecesaria por parte de técnicos informáticos es casi nula. Para conseguir esto, OpenCms oculta toda lacomplejidad del proceso de publicación, de forma que el personal de los diferentes departamentos pueda dedicarsea elaborar el contenido de la Web y publicarlo de una forma fácil e intuitiva.

Además de las características que se detallan a continuación, OpenCms permite su instalación en sistema decluster para balanceo de carga y tolerancia a fallos, funciona bajo servidor de aplicaciones como BEA Weblogic,TOMCAT, OC4J, etc., lo que permite hacer uso de las arquitecturas de objeto distribuido, particularmente con EJB.Posee un sistema virtual de ficheros sobre el que se trabaja, permitiendo definir y gestionar el espacio de trabajopara cada proyecto y los archivos del mismo.

73

para cada proyecto y los archivos del mismo.

Las características fundamentales de OpenCms son:

• Es software de código abierto publicado bajo licencia LGPL.

• Implementado en Java / XML.

• Entorno de trabajo desarrollado bajo tecnología web.

• Facilidades de edición de contenidos desde la vista de previsualización del portal.

• Gestión de galerías de archivos e imágenes.

• Sistemas de permisos y gestión de usuarios integrados.

• Publicación basada en Proyectos.

• Workflow y Gestión de Tareas.

• Histórico de Modificaciones del contenido.

4.1. Arquitectura.


Gestor de contenidos: OpenCms 6.2.3 (cont.)

• Editor WYSIWYG para la edición de contenidos no estructurados.• Editor basado en formularios para la edición de contenidos estructurados.• Integrado un sistema de escalado automático de imágenes de grandes dimensiones.• Versionado de contenidos.• Mecanismos de gestión de plantillas para la gestión de la presentación homogénea de los contenidos.• Soporte Multi-idioma.• Sistema de ayuda on-line.

74

•• Publicación estática y dinámica de contenidos.• Soporte del mecanismo de módulos para ampliar de una forma estándar las funcionalidades del gestor de

contenidos.

• Sistema de caché de contenidos.• Soporte SSL.• Sistema de planificación de tareas (para planificar la ejecución de acciones personalizadas periódicamente o

en instantes determinados).

• Soporte EJB.• Opencms está integrado con el motor de búsqueda Lucene.• Metainformación asociada a contenidos (documentos, imágenes, archivos, etc.).• Mecanismo de importación/exportación de contenidos en formato XML.• Exportación de contenidos en formato HTML.

4.1. Arquitectura.



Generación y definición de los nuevos tipos de contenidos:

• Definición de los atributos (campos obligatorios, opcionales, valores por defecto, etc.).• Asignación del editor apropiado para atributo/campo del contenido.• Los nuevos tipos de documentos son una combinación de uno o más tipo básicos de información, entre los

cuales se encuentran: textos, numéricos, documentos y archivos, imágenes, enlaces, etc.

• Generación de tipos a partir de subtipos.

75

4.1. Arquitectura.



Generación y definición de un sistema de categorización de contenidos:

• Las categorías se emplean para clasificar y etiquetar un contenido dentro un tema o un asunto determinado(en nuestro caso familias de servicios), lo cual facilita al usuario la búsqueda de los contenidos. Se puedeidentificar una categoría con una palabra clave. Se utilizan también para relacionar contenidos entre si

• Se habilitan mecanismos para asignar una o varias categorías a los contenidos• Se amplía el motor de indexación para que indexe las categorías de los contenidos y soporte búsquedas con

criterios basados en las categorías de los contenidos

76

4.1. Arquitectura.



Generación y definición de un sistema de categorización de contenidos:

Los desarrollos realizados para ampliar las funcionalidades de OpenCms están basados en el concepto demódulos, que es el mecanismo estándar de ampliación, de manera que el núcleo de la aplicación no se veaalterado y así facilitar posibles futuras actualizaciones de versión del producto.

77

Oficina de Proyecto

78

Oficina de Proyecto

Plataforma Administración Electrónica EELL

Email: [email protected]

Tlf: 963 477 337

5. plataforma ae ee.ll. arquitectura software v0gfw.diputacionalicante.es/repo/rec/206/05....

Documents