SG #06

Arreglos de Discos. Qué son y Dónde utilizarlos.

Anonymous — Sun, 25 Nov 2007 23:59:22 +0000

Arreglos de Discos. Qué son y Dónde utilizarlos. Anonymous Sun, 11/25/2007 - 17:59

Publicado en

SG #06

Infraestructura

Autor

Ariel García

Un arreglo redundante de discos independientes (RAID por sus siglas en inglés) es típicamente implementado para la protección de la información o incremento del desempeño al acceso de los discos duros. Existen varios tipos de arreglos y los más usados en la industria son: 0, 1, 5 y el 0+1 ó 10, siendo este último el de mayor desempeño, protección y costo.

Actualmente prevalece el uso de este tipo de configuraciones para la protección de la información, pero la industria del almacenamiento y las aplicaciones están evolucionando. Al día de hoy el fabricante de software o la industria del hardware nos entregan soluciones que nos permiten despreocuparnos en cierto grado en la definición del tipo de arreglo a utilizar o para qué archivos en específico los necesitamos. Obviamente estas soluciones son las de mayor costo y mejor desempeño.

Desafortunadamente, sólo aquellas empresas con enormes presupuestos para IT pueden adquirir soluciones de este tipo. En este artículo se explicará cómo los arreglos de disco nos ayudan no sólo a proteger la información, sino también a incrementar el desempeño de nuestras aplicaciones. Primero daremos una breve explicación de qué son los arreglos de discos y los tipos más populares a implementar. Después daremos una recomendación para la configuración de arreglos en las base de datos más comunes que podemos encontrar en el mercado.

¿Qué son los Arreglos de Discos RAID?

RAID proviene del acrónimo del inglés “Redundant Array of Independent Disks”, que significa matriz redundante de discos independientes. RAID es un método de combinación de varios discos duros para formar una unidad lógica única en la que se almacenan los datos de forma redundante. Ofrece mayor tolerancia a fallos y más altos niveles de rendimiento que un sólo disco duro o un grupo de discos duros independientes

RAID 0. Este arreglo es conocido como distribuido (striping), porque utiliza un sistema que utiliza a los discos como uno solo, teniendo un conjunto de cabezas independientes para su uso. La información es dividida en bloques de datos que se distribuyen en todos los discos del arreglo. EL RAIDø incrementa el desempeño, la lectura y escritura de la información al escribir un solo dato con varias cabezas de forma simultánea. Ejemplo: un dato de 8 bits se divide en todos los discos escribiendo 2 bits en cada uno de forma simultánea. Esto es más rápido que escribir 8 bits de forma serial con una sola cabeza. Este tipo de arreglo no tiene nivel de protección. En caso de la falla de un disco, se perdería toda la información.

RAID1. Este tipo de arreglo se conoce como Espejeo (Mirroring), porque su conjunto de discos los utiliza como espejos. Ofrece el nivel de protección más alto, pues uno tiene copia idéntica de la información de cada disco. Toda la información escrita en el disco primario se escribe en el disco secundario. RAID1 tiene un incremento en el desempeño de la lectura de la información, pero puede llegar a degradar el desempeño de la escritura.

RAID5. Este tipo de arreglo se denomina también como distribuido con paridad. Este tipo de arreglos distribuye la información en todo el conjunto de discos. A diferencia del RAIDø, RAID5 elabora un bit de paridad con el cual es posible reconstruir la información del arreglo en caso de la pérdida de alguno de los discos. La información y los bits de paridad son distribuidos en todos los discos, garantizando que siempre se encontrarán en discos distintos. RAID5 tiene un mejor desempeño que RAID1, pero cuando uno de los discos falla, el desempeño de la lectura llega a degradarse.

Raid10 (0+1). Este tipo de arreglo es una mezcla del arreglo distribuido y espejeo. La información se distribuye en un conjunto de discos como un RAIDø y, a su vez, este conjunto de discos es espejeado a otro conjunto de discos como un RAID1. RAID10 provee el nivel de protección y desempeño más alto para escritura y lectura que cualquier otro arreglo, debido a que contiene los beneficios de los arreglos distribuidos y espejo. Su único problema es el costo de implementación, al tener que usar siempre el doble discos.

¿Dónde Puedo Utilizar un Arreglo de Disco?

Ahora que recordamos cuáles son los principales arreglos de disco, podemos revisar dónde podemos utilizarlos. Como tal, no existe una regla para definir dónde deberíamos o no utilizarlos. Esto generalmente depende de nuestros presupuestos y criticidad de los sistemas. En esta ocasión daremos una recomendación para las bases de datos más usadas en el mercado: Oracle, MS SQL y Exchange.

Ninguna de estas recomendaciones está labrada en piedra, la experiencia y el conocimiento de nuestros sistemas nos orientarán hacia cual es nuestra configuración óptima.

Para el caso de SQL Server de Microsoft, la configuración es más simple. Se recomienda el uso de RAID1 y RAID5. RAID10 también es recomendado, pero dado el costo de su implementación, optamos por la primera opción. Con la configuración de los arreglos solventamos las necesidades de I/O de las bases de datos. Para bases de datos muy grandes se recomienda distribuirlas en múltiples arreglos de discos.

Los Transactional Log Files requieren de un acceso secuencial optimizado y deben de contar con un buen nivel de protección, por ello recomendamos RAID1.

Patrones de Casos de Uso.

Anonymous — Fri, 23 Nov 2007 19:30:00 +0000

Patrones de Casos de Uso.

Anonymous Fri, 11/23/2007 - 13:30

Publicado en

SG #06

Requerimientos

Autor

Saúl Cuesta

Al desarrollar o construir algo, como por ejemplo una casa o una máquina, es muy útil apoyarse en la experiencia anterior, ya sea de uno mismo o de otros. De esta manera sabremos que la solución va a funcionar, y tendremos identificados los problemas potenciales, así como soluciones para éstos. Estas soluciones a problemas comunes se conocen como patrones, y se utilizan en diversos aspectos del desarrollo de software. Ya en un artículo anterior de SG se habló sobre patrones de diseño, específicamente del patrón Modelo-Vista-Controlador. En esta ocasión, estudiaremos la aplicación de patrones al modelado de casos de uso, y en específico abordaremos el patrón CRUD.

Contrario a lo que se pudiera pensar, un patrón de casos de uso no describe un uso particular de un sistema. Más bien, captura técnicas para que el modelo sea mantenible, reusable, y entendible. Entonces, podemos decir que los patrones de casos de uso capturan mejores prácticas para modelar casos de uso.

La aplicación de patrones de casos de uso nos trae los siguientes beneficios:
• Aumentar la productividad.
• Reutilizar elementos existentes (en este caso fragmentos de modelos).
• Evitar el retrabajo por errores.
• No invertir tiempo en resolver problemas ya resueltos.
• Aplicar la teoría al trabajo práctico.
• Habilitar las herramientas de soporte para modelar el desarrollo.

Captura y Organización de Patrones

Para capturar y organizar los patrones de caso de uso, recomiendo ampliamente generar un repositorio de patrones donde capturen al menos la siguiente información para cada patrón:

• Nombre: el nombre descriptivo del patrón.
• Intento: captura cuál es el objetivo de aplicar el patrón.
• Características: estados de los patrones, si son simples o complejos, comunes o infrecuentes.
•Palabras claves: palabras clave que caractericen al patrón para facilitar su búsqueda.
• Tipo: si el patrón afecta la estructura del modelo o la descripción de un caso de uso.
•Modelo: un modelo de caso de uso a aplicar.
•Descripción: la descripción del modelo.
•Aplicabilidad: cuándo y cómo aplicar el patrón.
•Discusión: completa discusión sobre el patrón.
•Ejemplo: un ejemplo donde uno o más de los patrones se aplica.
•Modelo de análisis: diagrama con clases de análisis que proporciona una realización de los casos de uso.

Una vez que hemos hablado sobre lo que es un patrón de caso de uso, y la forma de documentarlos, estudiemos el patrón conocido como CRUD, en sus variantes completa y parcial.

Nombre: CRUD
Intento: este patrón se utiliza en los casos donde se quiere realizar altas, bajas, cambios y consultas a alguna entidad del sistema. Su nombre es un acrónimo de las palabras en inglés Create, Read, Update, Delete. Palabras clave: Creación, altas, bajas, cambios, catálogo

Modelo 1: CRUD Completo

Descripción: el patrón CRUD Completo consiste en un caso de uso para administrar la información (CRUD Información), nos permite modelar las diferentes operaciones para administrar una entidad de información, tales como crear, leer, cambiar y dar de baja.

Aplicabilidad: este patrón deberá ser usado cuando todas las operaciones contribuyen al mismo valor de negocio y todas son cortas y simples.

Modelo 2: CRUD parcial

Descripción: alguna de las alternativas del caso de uso puede ser modelada como caso de uso independiente.
Aplicabilidad: este patrón es preferible cuando uno de los flujos alternativos del caso del uso es más significativo, muy largo, o mucho más complejo que el patrón completo.
Discusión: muy a menudo los sistemas manejan información que, del punto de vista del sistema, se crea muy fácilmente. Después de un chequeo de sintaxis, o quizás un cierto chequeo sin importancia de un cálculo o regla de negocio, la información se almacena simplemente en el sistema. No es necesario realizar cálculos, verificaciones complejas, o recuperación avanzada de datos. La descripción del flujo es pequeña, y probablemente sólo haya una o dos trayectorias alternativas de menor importancia en el flujo. Las consultas, cambios, o bajas son operaciones igualmente simples.

¿Deben tales operaciones ser modeladas como un caso de uso? ¿Y deben incluirse en el modelo del sistema completo? La respuesta a ambas preguntas es sí. Son casos de uso porque son funciones que debe ser capaz de realizar el sistema. Alguien utilizará el sistema para administrar esa información. Por otra parte, deben ser incluidos en el modelo, ya que de otra manera estará incompleto. Y esto puede provocar que el proyecto no se lleve a cabo adecuadamente.

Afortunadamente, esto no significa que necesariamente cada operación se debe expresar como casos de usos separados. Según el patrón CRUD, los podemos agrupar. Este procedimiento tiene algunas ventajas obvias. Primero, el tamaño del modelo será reducido, hará más fácil de entender el modelo porque tiene menos casos. En segundo lugar, nadie estará interesado en un sistema que contiene solamente un subconjunto de estos casos de uso, ya que no generan el valor completo (por ejemplo, leer y dar de baja, pero no crear y cambiar). Agrupar estos flujos juntos en un caso como Administrar X se asegura de que las cuatro operaciones estarán incluidas en el modelo, y lo hace claro para el lector del modelo. Tercero, el valor de cada uno de los flujos por separado es muy pequeño, y podríamos estar cayendo en descomposición funcional; es la colección entera de estas operaciones la que da valor a los interesados.

Las cuatros operaciones no deben ser modeladas como caso de uso independientes.

La variación denominada CRUD: Parcial, indica que en caso de que solo algunas de las cuatro operaciones sean simples mientras que otras son complejas, se puede agrupar las operaciones simples en un caso de uso y dejar las otras modeladas como un caso de uso separado.

Observar también que esto es una situación típica donde un caso de uso no tiene solamente un flujo “básico”. Ninguno de los flujos se puede decir que es más “básico” o “normal” que los otros. Por lo tanto, un caso de uso CRUD tendrá típicamente cuatro flujos básicos, y posiblemente algunos flujos alternativos, como se demuestra en el ejemplo 1.

Una instancia de un caso de uso podrá realizar una de las siguientes operaciones (crear, leer, cambiar y dar de baja), y después dejar de existir. Esta misma instancia del caso de uso no continuará viviendo y esperando la operación siguiente que se realizará. Esta operación debe ser realizada por otra instancia del mismo caso de uso.

Como regla general, cuando no estamos seguros si combinar los diversos casos de usos en uno o crearlos como separados, la recomendación es mantenerlos como uno solo y después cuando se vea el tamaño y complejidad del caso de uso, se deberá tomar la decisión de separarlos si es necesario.

A continuación mostramos un ejemplo de un boceto de caso de uso utilizando el patrón CRUD. Por razones de espacio, no está completo. El objetivo es ejemplificar la aplicación del patrón.

Caso de Uso: Administrar Tarea

Este caso de uso permite registrar, listar, modificar, o eliminar la información de tareas realizadas.

Flujo Básico
El caso de uso tiene cuatro diversos flujos básicos:
Registrar tarea nueva
Modificar una tarea existente
Cancelar tarea
Consultar tarea fallida

Registrar tarea nueva
El caso de uso comienza cuando el usuario elige registrar una nueva tarea.
El sistema presenta una lista de posibles clases de tareas, y pregunta qué clase de tarea debe ser registrada, con qué nombre, y cuando se debe realizar.
El usuario provee la información requerida.
El sistema comprueba que el tiempo especificado es en el futuro y que el nombre de la tarea es único.
El sistema registra la nueva tarea y la marca como activa.
El caso de uso termina.

Modificar tarea
El caso de uso comienza cuando el usuario elige modificar una tarea ya registrada.
El sistema recupera los nombres de todas las tareas no marcadas como activo y las presenta al usuario. El usuario selecciona una de las tareas.
El sistema recupera la información sobre la tarea y la presenta al usuario.
El usuario modifica cualquiera de la información actual excepto el nombre de la tarea.
El usuario acepta la información.
El sistema comprueba si el tiempo especificado es en el futuro y almacena la información modificada.
El caso de caso de uso termina.

Cancelar tarea
El caso de uso comienza cuando el usuario elige cancelar una tarea.
El sistema recupera y despliega todas las tareas futuras.
El usuario selecciona una de las tareas.
El sistema recupera la información sobre la tarea y la presenta al usuario.
El usuario confirma la cancelación, el sistema elimina la tarea; si no se puede, no se hace ninguna modificación.
El caso de uso termina.

Consultar tarea fallida
El caso de uso comienza cuando el usuario elige vista de la lista de todas las tareas que han fallado.
El sistema recoge todas las tareas con el estado fallado y presenta sus nombres al usuario.
El caso de uso termina.

Flujos alternativos
Cancelar la operación
Nombre o Tiempo incorrecto

Otros Patrones de Caso de Uso

Existen varios patrones adicionales al CRUD que son utilizados para modelar sistemas. Esta es una lista de los más importantes:

• Reglas de negocio

• CRUD

• Login

• Reportes y Explotación de información

• Inclusión y Extensión

Conclusión

La técnica de casos de uso nos permite modelar y especificar los requerimientos de nuestro sistema. Tiene muchos beneficios, entre los más importantes: primero nos permite planear nuestro proyecto y segundo ayuda a llegar a acuerdos con los usuarios, para que los casos de uso sean mas claros y mantenibles es importante encontrar patrones y documentarlos, de esta manera cuando nos encontremos con un problema igual o parecido podamos resolverlos en menor tiempo. El concepto de patrones no es algo que solo es aplicable a la práctica de requerimientos. De hecho, la disciplina de requerimientos copia este concepto de la de análisis y diseño. Lo que se busca con los patrones es reutilizar lo aprendido en los nuevos proyectos y usarlos en la organización como estándares.

Referencias
• Pan-Wei Ng, Understanding types of use cases and artifacts. IBM Developerworks.
www-128.ibm.com/developerworks/rational/library/1809.html

Bio

Saúl Cuesta Rodríguez es consultor de ITERA especializado en las prácticas de requerimientos y modelado de negocios. Es graduado de la Universidad Tecnológica de Panamá como Ing. en Sistemas.

El Proceso de la Prueba de Software: Lenguajes de Definición de Procesos

Anonymous — Fri, 23 Nov 2007 16:19:47 +0000

El Proceso de la Prueba de Software: Lenguajes de Definición de Procesos Anonymous Fri, 11/23/2007 - 10:19

Publicado en

SG #06

Prueba de Software

Autor

Luis Vinicio León Carrillo

En este número y el siguiente abordaremos el proceso de la prueba de software. Iniciaremos con el tratamiento formal del concepto, para luego pasar a su aplicación, vinculándolo con la administración de proyectos.

Una Definición Formal

Es común encontrarse en la literatura que aborda el proceso de prueba una referencia al “Modelo-V”. Mediante este modelo se describe a un nivel muy alto de abstracción las fases del ciclo de desarrollo en las que (idealmente) se involucra la prueba; La siguiente gráfica ilustra una adaptación de este modelo, que incluye algunas actividades de cada fase.

Este modelo tiene la ventaja de ser bastante intuitivo: la prueba comienza haciendo revisiones técnicas a los requerimientos y bosquejando los primeros casos de prueba de aceptación, pasando luego a revisar que la arquitectura satisfaga los requerimientos y a definir los primeros casos de prueba de sistema; después se revisa la modularidad del diseño y se bosquejan casos de prueba de integración, para luego pasar a revisar los algoritmos y a desarrollar los casos de prueba de unidad.

Las actividades de prueba de la línea izquierda de la “V” se llevan a cabo en paralelo al desarrollo de software e involucran también la revisión de apego a estándares; las de la línea derecha involucran la terminación del diseño de los casos de prueba y la aplicación de los mismos.

Una desventaja del modelo es que requiere aún de mucho detalle para ser útil en la práctica. Además, la documentación de procesos es una actividad en sí misma, y los documentos generados suelen ser muy propensos a quedar rápidamente inconsistentes (a causa de los cambios) y/o sin actualizar (por la dificultad para realizar esos cambios).

Utilizando el conocimiento que hoy se tiene en el diseño e implementación de lenguajes de computación, se han desarrollado lenguajes que buscan abatir esos problemas; en la literatura se les conoce como Process Definition Languages (PDLs), y en ellos se basan los Business Process Management Systems (BPMSs), a los que se dedicó el número de julio-agosto 2005 de esta revista. Uno de los primeros trabajos en el campo de los PDLs es el de Osterweil[1]. De manera semejante a lo que ocurre con los BPMSs, el utilizar un PDL para definir un proceso de prueba posibilita la generación de un sistema de información que nos permite integrar herramientas CAST y administrar proyectos de prueba de software.

En la empresa e-Quallity hemos desarrollado un PDL para definir nuestros procesos y hemos observado que facilita mucho las actividades de diseño, documentación, análisis, mejora y mantenimiento de los mismos, debido a que la documentación adquiere muchos de los atributos de un lenguaje de computación, entre otros: es posible escribir descripciones más precisas y sucintas, con menos probabilidad de contener ambigüedades; las descripciones pueden modularizarse con facilidad, posibilitando el reuso y el mantenimiento efectivo.

Aquí presentaré un PDL mucho muy sencillo, en el que se omiten algunas cosas por cuestiones de espacio, pero tratando de incluir las ideas esenciales. Por la misma razón de espacio, no utilizaré grafos de sintaxis, sino que haré la definición utilizando BNF, con los terminales en negritas [2] y “λ” denotando la cadena nula; los no-terminales marcados con itálicas entre signos de mayor que y menor que (<Así>), no son definidos con mayor detalle; además no especificaré -entre otras cosas- lo que tiene que ver con el sistema de tipos (básicos, constructores, constantes y variables) ni los mecanismos de paso de parámetros. El PDL es más bien procedural y permite definir procesos dentro de otros procesos (tipo Pascal), posibilitando la generación de una jerarquía de procesos; los niveles permitirían diferenciar entre procesos y procedimientos.

En el siguiente número utilizaremos este PDL para documentar formalmente una sección de un proceso de prueba, y lo vincularemos con las fases de la administración de proyectos propuestas por el Project Management Institute.

Referencia
1. Osterweil, L. “Software Processes are Software too”. Proceedings of the ninth International Conference on Software Engineering. Marzo,1987
2. Aho, Ullman & Sethi. Compiladores: Principios, Técnicas y Herramientas. Addison Wesley, 2000
3. BNF and EBNF: What are they and how do they work? www.garshol.priv.no/download/text/bnf.html

ebXML. Parte 2: Funcionamiento en un Sistema Completo.

Anonymous — Thu, 22 Nov 2007 23:45:05 +0000

ebXML. Parte 2: Funcionamiento en un Sistema Completo. Anonymous Thu, 11/22/2007 - 17:45

Publicado en

SG #06

Arquitectura

Autor

Atanacio Reyes

En el número anterior, dimos un contexto general sobre lo que es ebXML y sus principales componentes. En esta ocasión, mostramos con mayor detalle el funcionamiento de ebXML en un sistema, así como su relación con RosettaNet y Web Services.

La orientación de la arquitectura técnica de ebXML se enfoca en proveer una estructura para que las organizaciones puedan colaborar en la integración de sus procesos externos. Típicamente el primer paso de este proceso consiste en que una organización defina y publique sus procesos de negocio en un repositorio donde otras organizaciones puedan descubrirlos. Una vez que otra organización los descubre, basándose en ellos y en su propia definición de procesos, inicia una secuencia de negociación mediante la cual se establecen acuerdos de colaboración, y apegándose a los términos y condiciones de estos acuerdos, los socios de negocios crean y configuran sus interfaces electrónicas de servicios, con lo cual se habilitan para iniciar transacciones y ejecutar así los procesos acordados. Los procesos definidos en la primera fase de este escenario y que a su vez han sido acordados con otros socios de negocios deben administrarse y verificar que satisfacen los acuerdos. Conforme los participantes en la comunidad de negocios electrónicos aumentan, se evalúan los procesos existentes con el propósito de mejorarlos y se definen nuevos procesos con el fin de ajustarse a las necesidades del mercado. La secuencia descrita en el escenario anterior, necesaria para el establecimiento de una comunidad con procesos externos compartidos e integrados entre sí, puede perfectamente llevarse a cabo mediante la implementación de las especificaciones que forman la estructura ebXML. En este artículo se muestra la correspondencia entre los pasos del proceso descrito y cada una de las especificaciones ebXML.

Definición de Procesos de Negocio

Determinar qué procesos son necesarios para ser tomados en cuenta en una estrategia de comercio electrónico, además de la descripción de cada una de las actividades y elementos que los forman, es una tarea que puede ser realizada con mayor facilidad si se emplea una metodología orientada a capturar el conocimiento de una organización en prácticas de comercio electrónico. UMM fue desarrollada con ese propósito, además de que ebXML la recomienda debido a que en las especificaciones BPSS y CPP/A existe una correspondencia con esta metodología.

Exhibición de las Capacidades, Servicios y Procesos

El modelado de procesos, necesario para describir y definir las capacidades de colaboración de un socio de negocios, es normalmente independiente de la tecnología. Sin embargo, para poder exhibir dichas capacidades en un repositorio público de tal forma que puedan ser encontradas por socios potenciales, es necesario exponerlas en un formato estándar entendible electrónicamente y capaz de ser procesado e interpretado por una máquina. ebXML define dos esquemas XML para este propósito: CPP y BPSS. El documento principal que describe las capacidades de un socio de negocios es el CPP, dichas capacidades están definidas en términos de roles que desarrolla, empaquetado de los mensajes, protocolos de transporte que es capaz de desarrollar, mecanismos de seguridad y procesos que ejecuta. La definición de los procesos se especifica en otro documento, en el CPP sólo se incluyen referencias a él. Aunque ebXML provee la especificación BPSS para la definición de procesos de negocios, no limita a que en el CPP se incluyan referencias a documentos formados con esquemas diferentes, que pueden ser XLANG, WSFL o PIP (Rosetta Net).

En cuanto a la definición de contenido de los mensajes que intervienen en las colaboraciones, ebXML no especifica ninguna recomendación, dejando esta responsabilidad a otros organismos, los cuales pueden emitir formatos más apegados al giro de los negocios involucrados. Actualmente existen asociaciones que han definido contenido de mensajes para intercambio electrónico, como lo son: EDIFACT, ANSI, XEDI, Automotive Industry Action Group (AIAG), BOLERO.NET, OAG y otros.

Para almacenar el CPP y el documento que describe los procesos (que puede ser definido mediante el BPSS) en un repositorio, se utilizan los servicios de la interfaz Life Cicle Management (LM), provista por el registro. Para tener acceso a esta interfaz es necesario ser un usuario registrado en dicho repositorio. Un registro/repositorio normalmente es desarrollado por comunidades de empresas que se asocian con el fin de integrar sus procesos de negocios, sin embargo también existen empresas que proveen servicios de hospedaje en sus repositorios además de herramientas de software para transferencia electrónica de mensajes, modelado de procesos, transformación entre formatos XML etc.

Establecimiento de Acuerdos con Socios

Para encontrar socios de negocios potenciales, las empresas acceden a los servicios que ofrece el registro/repositorio a través de la interfaz Query Management. Para acceder a esta interfaz, no es necesario ser un usuario registrado del repositorio. Una vez que se descubre un posible socio en el registro, se puede transferir el CPP encontrado al servidor propio, con el cual se forma un CPA. Este CPA se envía al socio en cuestión para iniciar un proceso de negociación. Una vez que ambos socios están de acuerdo en el CPA, deben almacenar copias idénticas de este en sus servidores y con ellas configurar sus aplicaciones e interfaces con el fin de llevar a cabo los procesos acordados.

El CPA viene a ser un subconjunto de un CPP o puede ser la intersección entre los dos CPP’s a partir de los cuales se construye (el CPP propio y el CPP obtenido del repositorio) y define la forma en la que dos socios de negocios interactúan en la realización de las colaboraciones que han acordado, la interacción también puede llevarse a cabo a través de intermediarios, para lo cual debe existir un CPA entre cada parte y el intermediario (adicionalmente al CPA entre ambas partes).

Al igual que el CPP, el CPA contiene referencias a la especificación de procesos (definida en BPSS, XLANG, WSFL o PIP de Rosetta Net), la que define una o más conversaciones entre las partes involucradas. La conversación representa una unidad simple de negocios definida por una colaboración binaria. Una conversación consiste de una o más transacciones de negocios, cada transacción es un mensaje de petición emitida por una de las partes que participan en la colaboración, y cero o un mensaje de respuesta emitido por la otra parte. Además la especificación de procesos define el orden en el cual las transacciones deben efectuarse (coreografía).

El CPA puede implementarse en un servidor B2B en el sitio de cada socio, donde deben residir sus especificaciones de procesos. Debe incluir además de los servicios que provee, una bitácora de auditoría. La información estática puede ser almacenada en una BD local, para generar los datos contenidos en las transacciones necesarias para satisfacer el CPA.

Intercambio de Información

Como se mencionó en el artículo anterior, ebXML especifica SWA como método de empaquetado para el transporte de mensajes, el propósito inicial de esta especificación, es que quienes estén usando EDI puedan realizar la transición a ebXML sin complicaciones. Como beneficio adicional permite que el contenido útil del mensaje sea definido de forma libre y de acuerdo a las necesidades de las partes que intervienen en determinada colaboración. El cuerpo del mensaje SOAP contiene un listado de todos los documentos adjuntos al mensaje, el formato de cada documento puede ser XML, pdf, imágenes etc., siempre y cuando el formato se haya especificado en el CPA al cual el mensaje SOAP hace referencia. El destinatario del mensaje puede usar este listado para verificar si todos los documentos adjuntos se recibieron. Además, en el encabezado del mensaje SOAP se define un identificador de conversacion (ConversationId) para indicar la parte del proceso que se ejecuta una vez terminada exitosamente la transacción.

Administración de Procesos

Los pasos anteriores son los necesarios para completar un proceso de integración de procesos de negocios interempresarial. Como puede observarse, sólo dos especificaciones de la estructura de ebXML son necesarias para que dos partes puedan integrar sus aplicaciones en un esquema de colaboración: el CPA y ebMS. El CPA es el acuerdo que convierte a las partes en socios, cuyo fin común es la integración de sus aplicaciones. La especificación de mensajes (ebMS) es el medio a través del cual llevan a cabo sus transacciones.

Conforme la comunidad de negocios va creciendo, la dificultad para administrar los procesos de colaboración entre socios se incrementa. Suponiendo que se tienen 5 socios y con cada socio se ejecutan 3 procesos y cada proceso tiene 4 actividades, en total deben administrarse 60 actividades. Considerando que cada proceso puede tardar desde unas horas hasta varios días en completarse, monitorear el estado de cada proceso conlleva algunas complicaciones.

Considerando el problema de administración de procesos ejecutables, surge una tecnología para ayudar a las empresas a administrar sus procesos a fin de optimizarlos y adaptar el comportamiento de las empresas a los cambios que normalmente son necesarios. Estos sistemas se conocen como Business Process Management Systems (BPMS) —ver SG Año 1 No. 4—, y aunque ebXML no recomienda un modelo particular de implemantación, este tipo de sistemas deben ser considerados al planear proyectos que involucran procesos ejecutables.

Relación de ebXML con RosettaNet

El consorcio RosettaNet (www.rosettanet.org) inició en Junio de 1998 auspiciado por la industria electrónica. El objetivo de la iniciativa es administrar de forma eficiente el canal de suministro a través del Internet. RosettaNet es un consorcio pionero en la definición de estándares basados en XML para integración B2B, y constituye la fuente de inspiración para ebXML. El modelo de esta especificación se divide en tres areas:

1. Intercambio de mensajes. RosettaNet Implementation Framework (RNIF)

2. Definición de procesos. Partner Interface Processes (PIPs).

3. Conjuntos de datos usados en giros específicos de la industria, tales como códigos de productos, códigos de industrias, etc.

RNIF v2.0 es una especificación muy parecida a la de ebMS, lo cual le permitió al consorcio RosettaNet alinearse completamente con ebXML en la versión 3 de RNIF.

En cuanto a la definición de procesos, RosettaNet ha desarrollado un catálogo bastante amplio. Cada proceso (PIP) está formado por diálogos especializados sistema a sistema en XML. Cada especificación de PIP incluye un documento de negocios con su correspondiente vocabulario y un proceso con la coreografía de los mensajes. Los PIPs están agrupados en siete áreas:

1. Captura de información, mantenimiento y distribución para el desarrollo de CPP y suscripciones a información de productos.
2. Distribución y actualizaciones periódicas de especificaciones técnicas.
3. Precios, tiempos de entrega, recepción y administración de órdenes.
4. Administración de inventario.
5. Campañas de información y mercadotecnia.
6. Asistencia técnica posterior a la venta.
7. Intercambios de diseño, configuración, procesos e información relacionada con manufactura.

Estas especificaciones de procesos son útiles para que las empresas que requieran integrar sus aplicaciones en un ambiente B2B escojan de entre este catálogo los procesos que mejor se ajusten a sus necesidades para definir sus CPPs. A partir del 2003 RosettaNet emplea la especificación de BPSS para definir todo su catálogo de procesos.

Relación de ebXML con Web Services

Existen muchas semejanzas que provocan confusión entre ebXML y Web Services. De hecho muchas empresas que ofrecen soluciones B2B e implementan en ellas especificaciones ebXML las anuncian como Web Services, colaborando con ello a aumentar la confusión.

Las principales semejanzas entre ambas tecnologías son:
• Usan el mecanismo de petición/respuesta sobre protocolos de transporte sin conexión permanente (HTTP, SMTP).
• Ambas usan SOAP como métodos de empaquetamiento de mensajes.
• El método para descubrir a las otras partes con quienes realizar transacciones es a través de un registro público (UDDI, registro/repositorio).
• ebXML especifica que la interfaz de un registro/repositorio pueda exponerse mediante servicios, lo cual provoca que las reglas de interacción con el registro se establezcan en un documento WSDL que puede ser descubierto mediante un UDDI.

Sin embargo, en los detalles de estas que parecieran ser semejanzas, existen profundas diferencias:
• El método de empaquetamiento de ebXML adiciona a SOAP extensiones que permiten la seguridad y confiabilidad de los mensajes usados en las transferencias, además de que es posible intercambiar documentos en cualquier formato convenido, no necesariamente XML.
• UDDI no provee almacenamiento de documentos, sólo provee referencias (links) a documentos WSDL, mientras que la separación entre registro y repositorio establecida por ebXML permite el almacenamiento de cualquier tipo de documentos. Este esquema puede ser usado para que una organización respalde todo el conocimiento adquirido, sus metadatos, la descripción de sus procesos etc., en un repositorio interno.
• La unidad atómica de Web Services es un servicio (transacción), mientras que en ebXML es una colaboración (proceso o conversación). Una colaboración está formada por una o varias transacciones que se realizan siguiendo una secuencia prestablecida, por lo cual es posible definir colaboraciones partiendo de servicios. Para agrupar servicios dentro de colaboraciones y definir el flujo de los mismos, se han establecido las especificaciones XLANG y WSFL propuestas por Microsoft e IBM respectivamente. Aunque estas empresas están entre los principales promotores de la tecnología de Web Services, no han podido establecer una especificación común para el flujo de los servicios que componen las colaboraciones, por lo cual sus respectivos productos y soluciones de integración B2B resultan ser incompatibles.

Aunque en el esquema de Web Services sea posible establecer colaboraciones partiendo de servicios, el hecho de que la unidad atómica de esta tecnología sea el servicio, compromete mucho la confiabilidad de las colaboraciones, más aún tratándose de que el protocolo de transporte HTTP no es orientado a conexión. Además de que el tiempo necesario para que una colaboración sea ejecutada puede tomar varios días.

Conclusión

En estos artículos hemos visto a grandes rasgos de lo que se trata ebXML. Es una tecnología bastante prometedora, que posiblemente ayude a evitar que las transacciones de negocio por Internet se conviertan en una torre de Babel. Los invitamos a que conozcan más sobre ebXML y analicen si su adopción puede traer beneficios a su empresa o industria.

Referencias
• www.ebxml.org

Bio

Atanacio Reyes Valenzuela es Lic. en Ciencias Computacionales de la Universidad Autónoma de B.C., tiene más de 10 años de experiencia en el desarrollo de software para integración de procesos de manufactura, interconectividad entre maquinaria y equipo para la automatización, procesamiento, control, administración, cálculo geométrico y matemático. Actualmente trabaja para la empresa Augen Ópticos, dedicada a la industria óptica oftálmica en México.