Arquitectura Orfeo
De OrfeoWiki
[editar] PROPUESTA DE ARQUITECTURA
ORFEO 4.0
Resumen de Versiones
- Versión Autor Fecha
- 1.0 Julian Rolón Vidal 7/04/2008
- 1.01 William Duarte 9/04/2008
- 1.05 Denis López C. 15/04/2008
- 1.06 Jairo Losada
- 1.07 Edison David Fuentes
[editar] Proyecto de reingeniería de Orfeo
[editar] Objetivos
El presente documento tiene por objeto poner a consideración de la comunidad, los elementos de arquitectura que delinearán el desarrollo de la nueva versión de ORFEO.
La nueva versión de ORFEO deberá incorporar los cambios necesarios en arquitectura y tecnología que le permita al Sistema de Gestión Documental y Procesos ORFEO mejorar la modularidad, escalabilidad, extensibilidad, portabilidad y mantenibilidad, manteniendo la filosofía y funcionalidades de ORFEO pero promoviendo flexibilidad en estas funcionalidades de forma tal que puedan adaptarse a las diferentes necesidades de los usuarios del sistema.
Una arquitectura modular, escalar, extensible, portable y de fácil mantenimiento deberá además, facilitar el trabajo en comunidad para que se puedan ofrecer mejores servicios. Estado actual Orfeo es un sistema de Gestión documental que además permite gestionar los procesos de la entidad que incluye entre otras las siguientes características:
- Gestión de documentos incluyendo almacenamiento, consulta y asociación de metadatos
- Gestión vía WEB de todos los procesos que incorporen la gestión de documentos
- Manejo de las Unidades Organizacionales dentro de una empresa o entidad
- Generación de Flujos de trabajo “ad-hoc” y predefinidos.
- Manejo de flujo documental entre las Unidades Organizacionales y entre los empleados o funcionarios de la empresa
- Módulo de digitalización para ingresar documentos físicos de usuarios externos al sistema
- Modulo de Manejo de carpetas virtuales generales y por usuario
- Manejo de números de radicación
- Manejo de anexos a documentos principales (documentos asociados a un documento principal que complementan la información del mismo)
- Conformación de “Expediente Virtuales”, a través de la agrupación y asociación de varios documentos principales.
- Módulo de archivístiva: Para rastrear la ubicación física de los documentos, donde se incorporan facilidades de la gestión física del documento (Tablas de Rentención Documental)
- Módulo de correspondencia: Para incorporar las tareas propias al envío y recepción de comunicaciones físicas (papel) externas a la empresa o entidad
- Módulo de combinación de correspondencia: Para automatizar la inclusión de números de radicación y otros metadatos en los documentos, inclusiva para la producción de grandes volúmenes de documentos con un texto estándar.
El sistema ORFEO fue desarrollado principalmente en php, en un proceso incremental y con la construcción paralela de una comunidad que permitió nuclear usuarios del sistema, programadores y otros participantes que de diversas formas aportaron en la mejora incremental del sistema, direccionado fuertemente por las necesidades que iban surgiendo, permitiendo rápidamente resolver soluciones puntuales.
No obstante esto ha generado algunas dependencias particulares que hace difícil la mantenibilidad del sistema y la integración del mismo de manera coherente, generándose variaciones de la versión estable y disponible de la comunidad que podrían obviarse si se aplicaran de manera consistente estándares de desarrollo.
La comunidad ha sido consiente de esta situación y a pesar de haberse planteado la necesidad de resolver este problema en el pasado, es hora de avanzar en la solución con base en la Metodología de Reingeniería, con el fin de que los esfuerzos colectivos que se dispersan en ajustes particulares de la herramienta se puedan nuclear en la construcción de una versión mejorada que podamos ofrecer de manera colectiva.
[editar] Actualmente el sistema tiene las siguiente debilidades:
- No es multicapa: No están bien diferenciadas cada una de las responsabilidades dentro del programa (interfaz de usuario, persistencia y lógica de negocio)
- Bajo desacople: Aunque a nivel funcional se identifican módulos , las interfaces de estos módulos no están bien definidas creando acople entre los mismos, esto dificulta la extensibilidad y el mantenimiento del sistema
- Baja escalabilidad: El sistema no se adapta bien al incremento de usuarios y demanda sobre el mismo lo cual produce bajo rendimiento y caídas del sistema
- Bajo grado de estandarización: El sistema no se acoge a estándares lo cual dificulta la interoperabilidad con otros sistemas
[editar] Casos de Uso Orfeo 4.0
Se tomara como base los casos de uso existentes actualmente en :
https://www.superservicios.gov.co/orfeoint/Manuales/cu/index.html
Estos casos describen la funcionalidad actual de Orfeogpl.org. Los nuevos desarrollos y nuevos cambios a estos casos se estaran exponiendo en :
Se debe seguir el documento inicialpara realizar los casos de uso mostrados.
[editar] Estandar a Usar "Open SCA"
Open SCA Service Component Architecture Specifications", es una especificacion que permite los desarrollos orientados a servicios, teniendo en cuenta el estandar SOA.
Esta especificacion esta actualmente disponibel en Java y PHP. Participan en esta definicion empresas tales como IBM, ORACLE, SUN Microsystem, entre [otras|http://www.oasis-opencsa.org/members]
Estas especificiones son emitidas por OASIS unas de las mayores entidades de estandarizacion. http://www.oasis-opencsa.org
Tambien encontramos documentacion para php en http://osoa.org
[editar] Propuesta arquitectónica
[editar] Los principales componentes son:
[editar] Persistencia
Aquí se detallan los principales componentes relacionados con el almacenamiento, búsqueda y recuperación de los datos y contenidos persistentes en el sistema
Repositorio de Contenidos:
Permite la creación, almacenaje y consulta de contenidos (documentos) y sus metadatos asociados, este módulo corresponde a la capa de persistencia y simplemente se encarga de almacenar documentos junto con sus metadatos agrupados lógicamente bajo espacios jerárquicos asociados a usuarios. Se propone utilizar un repositorio que implemente el estandar JSR-170 que incluye además de las funciones básicas de creación, modificación, reorganización y recuperación de contenidos y metadatos, características como versionamientos automático, transacciones y espacios de trabajo temporales y sesionables. Dos propuestas concretas podrán ser revisadas por la comunidad con el fin de incorporar al menos una a la luz de las necesidades que ha percibido la comunidad:
- JackRabbit de Apache
[editar] Búsqueda e Indexamiento
Este módulo permite hacer búsquedas sobre el repositorio de contenidos y sus metadatos, estas búsquedas deben estar apoyadas por técnicas de indexamiento de texto y opcionalmente OCR para indexar documentos que hayan sido digitalizados como imágenes. Este módulo debe trabajar conjuntamente con el repositorio a través de interfaces bien definidas y debe exponer la funcionalidad de búsqueda a otros módulos del sistema. Se propone Lucene de apache y se estudiarán otros motores posteriormente.
Datos de control
Este módulo permitirá manejar los datos de control propios de Orfeo, dada su naturaleza de control no es conveniente que se almacenen en el repositorio de contenido. Se propone acceder a un sistema de base de datos relacional pero el módulo debe permitir la independencia del motor de base de datos específico. Se propone una herramienta de mapeo relacional-objetos con manejo de transacciones estándar y automática (el manejo de transacciones debería estar ubicado en la herramienta o en el contenedor de aplicaciones). Se propone [Hibernate] o EJB3 para este módulo.
[editar] Capa de lógica de negocios
En esta capa se debe implementar toda la funcionalidad de orfeo apoyándose en los módulos descritos anteriormente, esta capa está compuesta por diferentes componentes que interactúan entre sí y que deben ser visto como servicios. Siguiendo esta idea, cada uno de estos componentes debe exportar su funcionalidad a través de una interfaz java y a través de una interfaz de servicios Web. Adicionalmente es deseable que estos componentes permitan estrategias de distribución para aumentar la escalabilidad, disponibilidad y desempeño del sistema. Sin embargo esta escalabilidad no se logrará totalmente si los repositorios usados no poseen también características que garanticen esta escalabilidad. A continuación se detallan cada uno de los componentes:
Negocio:
[editar] Componentes Núcleo
Estos componentes proporcionan el manejo documental central en la herramienta, tienen la más alta prioridad de implementación y proporcionan la base para los demás componentes del sistema Manejo de documentos
Este componente permite ingresar documentos al repositorio así como recuperarlos y moverlos entre las distintas carpetas virtuales y los distintos Departamentos y Roles. Adicionalmente permite la asociación de Tipos Documentales y Metadatos a los documentos, es el componente principal del sistema y los demás lo utilizan extensivamente
[editar] Empresas Virtuales
Este componente opcional permite la creación de espacios de trabajo por empresa, el objetivo es permitir que con una sola instalación de Orfeo se puedan manejar varias empresas. Si se decide que se incluye entonces pasará a formar parte de los componentes núcleo pero se debe aclarar que su implementación no es requerida. Tipos Documentales y Metadatos Permite la definición de metadatos asociados a un documento. Estos metadatos pueden estar construidos a partir de una definición genérica de metadatos (por empresa o departamento), a partir de un tipo documental específico o una combinación de los dos usando relaciones como herencia o composición.
[editar] Departamentos y Roles
Permite la creación y administración de departamentos en la empresa y de roles dentro de estos departamentos, opcionalmente (bajo estudio aún) se podría implementar un mecanismo para crear flujos de trabajo genéricos (a nivel de empresa o de departamento, estos flujos aplicarían a todos aquellos documentos que no estuvieran sujetos a un proceso en particular)
[editar] Carpetas Virtuales
Permite la creación y administración de carpetas genéricas (por empresa o departamento) y carpetas personalizadas de usuario, Este módulo trabajaría junto con el de Departamentos y Roles para la implementación de los flujos genéricos
[editar] Componentes de funcionalidad Orfeo
Estos componentes proporcionan la funcionalidad que expone Orfeo en su versión actual excluyendo la funcionalidad núcleo y la funcionalidad para interactuar con usuario externos y copias físicas.
[editar] Anexos
Permite la asociación de documentos complementarios a los documentos principales. Un documento principal tiene asociado un tipo documental, metadatos y posiblemente un flujo de trabajo genérico o un proceso específico, un anexo no tiene ninguna de estas propiedades.
Este modulo debe ir entregado al manejador de repositorio Jackrabbit ya descrito anteriormente.
Se debe probar y verificar como realizar la combinacion de datos dentre OrfeoGpl y los documentos radicados.
[editar] Radicación
Permite la creación y manejo de números de radicación que permiten identificar más claramente un documento principal, estos números deberían ser invariantes y únicos en el ámbito de un documento principal en particular. Adicionalmente, su generación debería poder ser especificado declarativamente (Con expresiones regulares por ejemplo).
Solicitud de Cambios a este modulo.
Permitir un numero indefinido de remitentes y destinatarios. Trabajar con AJAX el sistema de Busqueda de los usuarios (Sin abrir diferentes ventanas).
[editar] Expedientes
Permite la agrupación de documentos principales en casos con una trazabilidad histórica, trabaja de cerca con el módulo de búsquedas para facilitar al usuario la agrupación
[editar] Búsquedas
Proporciona una interfaz unificada para búsquedas sobre contenido y metadatos Componentes de interacción externa Estos módulos conectan el sistema con los mecanismos de captura, emisión y almacenamiento de documentos físicos.
Creacion de una bodega de datos para consulta historica. Asociacion de un reporteador tipo http://www.pentaho.com/.
[editar] Digitalización e ingreso
Agrupa varios componentes que permiten el ingreso de documentos provenientes de otros medios. Todos los componentes aquí desarrollados deben compartir una misma interfaz y cada implementación se debe encargar de un medio en específico. Entre estos medios, la digitalización es el más común pero también puede incluir faxes e incluso herramientas embebidas en las suites de ofimática para el ingreso automático de documentos al sistema.
Se debe tener independencia de sistema Operativo y no requerir licenciamientos adicionales. Se puede usar el projecto xsane.org. ya se esta realizando un prototipo usando "jai - java avanced imaging"
[editar] Archivo
Permite la asociación de un documento principal a una ubicación física y su posterior consulta Combinación de correspondencia Permite la generación automática y serial de cabeceras de documento a partir de metadatos Correspondencia Automatiza el proceso de envío de documentos por correo
Modulo en revision por la comunidad. Actualmente este modulo se encuentra en diseño, se haliberado la primera version. El manual se puede encontrar en : http://orfeogpl.org/ata/node/351 Falta incluir el modulo de Eliminacion de Documentos.
BPM
El sistema deberá integrar un motor de procesos que permita la creación de procesos específicos. Estos procesos deberán poder ser asociados a tipos documentales, carpetas virtuales, departamentos y roles, y empresas.
Se propone utilizar jbpm creando acciones ajustadas al modelo de Orfeo o BPEL para crear orquestaciones de los servicios expuestos. La opción de BPEL requiere de un estudio más detallado puesto que es difícil incluir los artefactos citados.
Se esta analizando el funcionamiento de la Herramienta JBPM para integrar a la Arquitectura Planteada.
[editar] Seguridad
Aquí se incluyen todos los aspectos relacionados con la seguridad del sistema, este tema es transversal y debe aplicar a todos los componentes implicados. Los temas a tratar aquí son autorización, autenticación y auditoría. Adicionalmente se podrá incluir un componente opcional y no transversal para la firma digital de documentos (no se muestra en el diagrama). Los aspectos de seguridad podrán aplicar a usuarios del sistema o al sistema como tal, por ejemplo, se puede utilizar el estandar WS-SECURITY para asegurar los WebServices de la aplicación utilizando un certificado digital que puede ser a nivel de la aplicación o de la máquina que lo contenga o de usuario. Los aspectos de seguridad deben estar definidos antes de empezar el desarrollo de módulos, inicialmente se propone utilizar JAAS y un directorio LDAP Estos temas deberán ser revisados con un experto en seguridad.
Caracteristicas de JAAS
[editar] FrameWork
Se propone escoger un FrameWork de trabajo para interconectar los diferentes componentes del sistema, un FrameWork proporciona agilidad de desarrollo y sobretodo uniformidad además de contribuir a la modularización, separación de responsabilidades, extensibilidad, mantenimiento y escalabilidad del sistema.
Se propone Spring http://www.springframework.org/.
Caracteristicas de FrameWork Spring
[editar] Interfaz de Usuario
Basados en la arquitectura multicapa propuesta, es posible crear distintos tipos de interfaz de usuario en el sistema que se detallan a continuación Interfaz integrada El sistema debe contar con una interfaz de usuario integrada, se propone el uso de Java Server Faces para la implementación de esta interfaz. Nótese que los componentes Faces interactúan directamente con el API proporcionado por la capa de lógica de negocios a nivel de interfaces Java. Esta interfaz de usuario será la predeterminada en el sistema.
Se propone utilizar ICEfaces.
[editar] Portlets
Como alternativa se propone la creación de portlets conformes a la especificación JSR-168 y sus sucesoras. Esto permitirá que el sistema sea integrado fácilmente en portales empresariales. Este tema requiere de más estudio. La creación de portlets también puede lograrse a nivel de WebServices siguiendo la especificación de la w3c WSRP. El uso de esta especificación permitiría la inclusión del sistema en portales desarrollados en otros lenguajes de programación
[editar] Ver Tambien
[editar] Requerimientos de Orfeo
La ingenieria de requerimientos Sera de Utilidad para ayudar a los ingenieros de orfeo a entender mejor el problema en cuya solucion trabajaran, incluye el conjunto de tareas que conducen a comprender mejor cual sera el impacto del software sobre el negocio, lo que el cliente quiere y como interactuaran los usuarios finales con el software. Empieza en la fase de inicio, la cual es una tarea que define el ambito y la naturaleza del sistema Orfeo, despues continua con la obtencion que es una tarea que ayuda al cliente a definir sus necesidades, posteriormente sigue la elaboracion que es la fase donde se refinan y modifican los requerimientos basicos. Por ultimo, los requerimientos se especifican y despues son validados y revisados para asegurar que la concepcion del problema que tienen los ingenieros de software coincidan con la percepcion del cliente. Recordemos tambien que la ingenieria de requerimientos tiende un puente hacia el diseño y la construccion.
Se propone realizar las siguientes tareas para el desarrollo de los requerimientos:
Tarea 1: Obtener información sobre el dominio del problema y el sistema actual.
Tarea 2: Identificar/revisar los objetivos del sistema.
Tarea 3: Identificar/revisar los requisitos de información.
Tarea 4: Identificar/revisar los requisitos funcionales.
Tarea 5: Identificar/revisar los requisitos no funcionales.
Tarea 6: Priorizar objetivos y requisitos.
Ver mas ingenieria de requerimientos Orfeo4.0
Personas y/o empresas que colaboraran en la version 4.0 Reunion 5 Marzo de 2009
[editar] Hoja de Ruta
