Esquemas nacionales de Interoperabilidad y Seguridad

A principio de este año por fin se han publicado en el BOE los Esquemas Nacionales de Interoperabilidad y de Seguridad, previstos en la Ley 11/2007. Se supone que estos esquemas surgen con la vocación de constituir el marco de referencia que deberán seguir los sistemas informáticos de la Administración Electrónica y de cualquier organización que trabaje con ella.

Os dejo los enlaces por si son de vuestro interés:

Esquema Nacional de Interoperabilidad

http://www.boe.es/boe/dias/2010/01/29/pdfs/BOE-A-2010-1331.pdf

Esquema Nacional de Seguridad

http://www.boe.es/boe/dias/2010/01/29/pdfs/BOE-A-2010-1330.pdf
aaaa
aaa

BPD. Business Process Diagram (I)

En BPMN se definen Business Process Diagrams (BPD). Un BPD está formado por un conjunto de elementos gráficos que facilitan el desarrollo de diagramas de flujos de procesos.

Estos elementos gráficos están categorizados de la siguiente manera:
  1. Objetos de flujo.
  2. Objetos conectores.
  3. Swimlanes.
  4. Artefactos.

1. Dentro de los objetos de flujo existen tres elementos que definen el comportamiento del proceso de negocio:

  • Evento: Su representación gráfica es un círculo. Representa una determinada acción que se produce durante la ejecución del proceso de negocio. Los eventos suelen tener asociados causas (trigger) o impactos (resultados). Se definen tres tipos de eventos dependiendo de cuándo estos afectan al flujo de proceso: Start, Intermediate y End.
  • Actividad: Una actividad es un término genérico que describe acciones que se ejecutan en una organización. Un ejemplo de actividad sería "Enviar hoja de gastos a administración". BPMN define tres tipos de actividades: Process y Sub-Process, de carácter no atómico, y Tasks, de carácter atómico. Los objetos Process (proceso) no están delimitados por ninguna figura geométrica, ya que un proceso no se representa con una figura específica, sino como un conjunto de objetos que normalmente se agrupan dentro de un Pool. Un Sub-Process (sub-proceso), se define como una actividad compuesta por una secuencia o flujo de otras actividades. Un sub-proceso forma parte de un proceso, pero éste a su vez puede ser contemplado como un proceso en sí. La representación gráfica asociada es un un rectángulo redondeado, pudiendo estar visible en el proceso principal (expandido) o pudiendo estar colapsado, en cuyo caso, se indica con un símbolo (+) que puede desplegarse. Y por último un objeto Task (tarea) se trata de una actividad atómica e indica las tareas específicas (a bajo nivel) que son realizadas de forma manual (por personas) o de forma automática (por sistemas) para ejecutar un determinado proceso. Surepresentación gráfica es también un rectángulo redondeado.
  • Gateway: Su representación gráfica es un diamante o rombo, y se utiliza para controlar la divergencia o convergencia de la secuencia de flujo. Con este elemento se modelizan las decisiones y permite crear nuevos caminos de flujo del proceso.

2. Los objetos conectores son los encargados de unir diferentes objetos de flujo, es decir, relacionar distintos eventos y actividades, creando el esqueleto básico de la estructura de un proceso de negocio. Se describen tres objetos conectores que hacen esta función.

  • Sequence Flow: Su representación gráfica es una linea sólida con una cabeza de flecha sólida y se usa para mostrar el orden (la secuencia) en el que las diferentes actividades se ejecutan en el proceso. Si es la secuencia por defecto, la línea sólida lo indica con una pequeña línea cruzada en diagonal sobre ella.
  • Message Flow: Su representación gráfica es una línea discontinua con una punta de flecha hueca y se usa para mostrar el flujo de mensajes entre dos participantes del proceso separados (entidades de negocio o roles de negocio). Dentro de BPMN es el objeto conector que une dos Pools.
  • Association: Su representación gráfica es una línea de puntos y se usa para asociar datos, texto, y otros artefactos con los objetos de flujo. Las asociaciones se usan para mostrar entradas y salidas de las actividades.


Blog recomendado. LRM Consultoría Logística

Redindustria os recomienda que visitéis el blog de la Consultora Logística LRM. Podéis acceder a él en la dirección http://www.lrmconsultorialogistica.es/blog.html.

Este blog incluye artículos relacionados con el sector de la logística integral y la gestión de proyecto logísticos y podréis encontrar entradas relacionadas con Supply Chain Management, compras y aprovisionamiento, producción, almacén, transportes y distribución.

Llevar a cabo proyectos SOA con éxito

Una vez comprendida la finalidad de los patrones SOA en la entrada anterior, dedicaremos ésta a explicar brevemente las etapas que se deberían seguir para completar un proyecto SOA con éxito:
  • Escoger el modelo de referencia SOA. Se debe elegir un modelo, independiente de la tecnología, que defina los conceptos y el vocabulario básico para el proyecto. Determinadas organizaciones con experiencia en proyectos SOA definen modelos sencillos basados en su propio glosario de términos y conceptos, aunque existe un modelo de referencia estándar, OASIS (del que hablaremos en alguna entrada futura).
  • Escoger el entorno de desarrollo. Principalmente, decidir entre .NET o un entorno Java.
  • Proponer una arquitectura de referencia SOA. Esta arquitectura identifica los servicios necesarios en la organización, muestra como interactúan estos servicios con los usuarios de negocio, y su relación con los procesos de negocio y los sistemas de información. Depende de la infraestructura tecnológica escogida para el proyecto, pero es reutilizable de unos proyectos a otros.
  • Identificar patrones SOA adecuados. Ya que su utilización facilita enormemente la siguiente etapa de esta metodología y permite aprovechar el conocimiento de otras organizaciones, empresas, etc, en experiencias previas.
  • Implementar una instancia concreta de la arquitectura de referencia. Esta etapa ya es específica para cada proyecto, y supone desarrollar con la plataforma tecnológica escogida los servicios de la arquitectura de referencia propuesta. Tras completar estas etapas sólo faltaría desplegar los servicios, ejecutarlos y monitorizarlos. Y realizar una mejora continua de la arquitectura desplegada en función de los resultados obtenidos con esta monitorización.


Patrones SOA

De la misma manera que los patrones EAI han facilitado mucho en los últimos años la integración de sistemas mediante la utilización de middleware de tipo MOM, (ya hemos dedicado a ellos varias entradas), se han identificado patrones SOA que permiten la reutilización de conocimiento y la propuesta de mejores prácticas en la realización de proyectos SOA.

Estos patrones no están ligados a ninguna tecnología en concreto, ni tampoco a ningún sector de negocio específico. Al igual que los patrones EAI, simplemente intentan estandarizar las técnicas de diseño que ayudan a superar los obstáculos más frecuentes que aparecen durante la realización de un proyecto SOA.

Los 90 patrones SOA que se han documentado hasta el momento se pueden dividir en tres categorías
dependiendo del nivel de diseño en el que se centren: Arquitectura del Inventario de Servicios, Arquitectura de Composición de Servicios y Arquitectura de Servicio.

Y algo muy importante que se debe tener en cuenta es que la aplicación de estos patrones no es una cuestión todo-o-nada, sino que se puede utilizar un determinado patrón como referencia inicial aunque en algún momento determinado del diseño sea necesario tener las particularidades específicas del proyecto, que quizás no encajen del todo con el patrón estándar. Los propios patrones van evolucionando con el tiempo gracias a las contribuciones de desarrolladores e investigadores en el área.

Aquí tenéis un enlace interesante si queréis profundizar en el tema:

http://soapatterns.org/