Open source 4 Ever.... El camino hacía la liberación......

Principios de la orientación a servicios

2010-11-03T10:22:00.001-03:00

Un tipico problema con el que nos podemos encontrar a la hora de construir una servicios SOA es si el servicio construido es realmente es un servicio "SOA Compliant". Para comprobar si una servicio lo es, la mejor forma de hacerlo es chequeando que la aplicación cumpla con los Principios de la Orientación a Servicios.

No existe una definición estándar de cuales son los Principios de la Orientación a Servicios, por lo tanto, lo único que se puede proporcionar es un conjunto de Principios que estén muy asociados con la Orientación a Servicios. Estos Principios según Thomas Erl son:

Los Servicios deben ser reusables: Todo servicio debe ser diseñado y construido pensando en su reutilización dentro de la misma aplicación, dentro del dominio de aplicaciones de la empresa o incluso dentro del dominio público para su uso masivo.

Los Servicios deben proporcionar un contrato formal: Todo servicio desarrollado, debe proporcionar un contrato en el cual figuren: el nombre del servicio, su forma de acceso, las funcionales que ofrece, los datos de entrada de cada una de las funcionalidades y los datos de salida. De esta manera, todo consumidor del servicio, accederá a este mediante el contrato, logrando así la indepencia entre el consumidor y la implementación del propio servicio. En el caso de los Servicios Web, esto se logrará medienta la definición de interfaces con WSDL.
Los Servicios deben tener bajo acoplamiento: Es decir, que los servicios tienen que ser independientes los unos de los otros. Para lograr ese bajo acoplamiento, lo que se hará es que cada vez que se vaya a ejecutar un servicio, se accederá a él a través del contrato, logrando así la independencia entre el servicio que se va a ejecutar y el que lo llama. Si conseguimos este bajo acoplamiento, entonces los servicios podrán ser totalmente reutilizables.
Los Servicios deben permitir la composición: Todo servicio debe ser construido de tal manera que pueda ser utilizado para construir servicios genéricos de más alto nivel, el cual estará compuesto de servicios de más bajo nivel. En el caso de los Servicios Web, esto se logrará mediante el uso de los protocolos para orquestación(WS-BPEL) y coreografía (WS-CDL).
Los Servicios deben de ser autónomos: Todo Servicio debe tener su propio entorno de ejecución. De esta manera el servicio es totalmente independiente y nos podemos asegurar que así podrá ser reutilizable desde el punto de vista de la plataforma de ejecución.
Los Servicios no deben tener estado: Un servicio no debe guardar ningún tipo de información. Esto es así porque una aplicación está formada por un conjunto de servicios, lo que implica que si un servicio almacena algún tipo de información, se pueden producir problemas de inconsistencia de datos. La solución, es que un servicio sólo contenga lógica, y que toda información esté almacenada en algún sistema de información sea del tipo que sea.
Los Servicios deben poder ser descubiertos: Todo servicio debe poder ser descubierto de alguna forma para que pueda ser utilizado, consiguiendo así evitar la creación accidental de servicios que proporcionen las mismas funcionalidades. En el caso de los Servicios Web, el descubrimiento se logrará publicando los interfaces de los servicios en registros UDDI.

Cuando se desarrollan aplicaciones SOA es muy útil y necesario tener en cuenta siempre estos principios, ya que nos van a dar las pautas necesarias para tomar ciertas decisiones de diseño complejas.

Como se habrá podido observar, una característica muy importante de los Principios de la Orientación a Servicios, es que todos ellos se inter-relacionan. El siguiente gráfico muestra la inter-relación de los diferentes principios:

Como se puede observar en el gráfico, el objetivo de la Orientación a Servicios es obtener software totalmente reutilizable a través de un conjunto de técnicas y principios como los descritos anteriormente.

Java Business Integration, JBI. (2)

2009-04-17T15:02:00.001-04:00

Modelo de Componentes.

BPEL Service Engine (SE).
Acerca de BPEL SE.
El BPEL SE proporciona servicios en tiempo de ejecución para el despliegue de procesos BPEL. El BPEL SE, se usa para ejecutar WS-BPEL 2.0 (o simplemente BPEL) compatible con los procesos de negocios. WS-BPEL 2.0 (Web Service Business Process Execution Language) es un lenguaje basado en XML usado para desarrollar Procesos de Negocio.
Los procesos de negocios típicamente implican el intercambio, o la orquestación, de mensajes entre los procesos y otros servicios conocidos como Partner Service (Proveedor de Servicio). El contrato entre un proceso de negocio y un proveedor de servicio se describe utilizando WSDL 1.1. El intercambio de mensajes entre un proceso de negocio y un proveedor de servicios es envuelto en los mensajes de un WSDL 1.1, tal como lo define un la especificación JBI, y el enrutamiento vía el NMR (Normalized Message Router) de JBI. El NMR interactua con servicios web externos, no residentes en la JVM local, vinculados por intermedio del Binding Components (BC). El BC es el responsable de encapsular los detalles específicos del protocolo utilizado. Las transacciones entre el BPEL SE, se colocan como un EJB o un componente Web que se manejan atreves del Java EE SE.
EL WS-BPEL 2.0 utiliza las especificaciones XML: WSDL 1.1, XML Schema 1.0, XPath 1.0 y XSLT 1.0. Hay que tener en cuenta que la especificación JBI está destinada a WSDL 2.0 y WSDL 1.1 quedara asumida por esta nueva versión. El BPEL SE soporta operaciones one-way, request-response (como se define en el WSDL 1.1), dentro de estado, de larga duración que involucran la interacción de dos o más partes. Asincrónico request-response se realiza mediante dos operaciones one-way, uno aplicado por un proveedor de servicio (Partner), el otro aplicado por el proceso de negocio utilizando una correlación.

JMS BC.
Acerca de JMS BC.
JBI es una arquitectura flexible y extensible que permite que los componentes JMS Binding Component utilicen el modelo de mensajería que separa los consumidores de servicios de proveedores de servicios. Este modelo de mensajería define el uso de WSDL, para describir las operaciones expuestas por el Binding Component. El WSDL se utiliza también para definir el nivel de transporte de los Binding para obtener las operaciones de los servicios en tiempo de diseño, se configura un JMS Binding Component para utilizar los elementos JMS extensibles en el WSDL.
La especificación JBI incluye un modelo que describe un intercambio de mensajes entre los mensajes de consumidores y mensajes de proveedores.
En un flujo de mensaje outbound, el JMS BC actúa como un proveedor de servicios. El JMS BC recibe un mensaje normalizado desde el Normalized Message Router (NMR), que convierte este mensaje a un mensaje JMS y luego envía el mensaje a un destino JMS.
En un flujo de mensaje inbound, el JMS BC actúa como un proxy de los consumidores, el JMS BC convierte el JMS mensaje este recibido desde un servicio JMS a un mensaje normalizado, y luego envía el mensaje normalizado como parte del intercambio de mensaje a otro componente quien haya solicitado el servicio.
El siguiente diagrama ilustra la relación entre el JMS Binding Componet y el JBI runtime enviroment, el tiempo de diseño (Netbeans) y otros componentes de JBI System Management.

Características de JMS BC.
Las características del JMS BC incluyen:
• Envíos de inbound y outbund de mensajes JMS (texto, binarios, xml).
• Recibo automático tipo acknowledgement de mensajes JMS inbound.
• Recepción batch de mensajes JMS inbound.
• Recepción inbound de mensajes JMS a través de un filtro de selección.
• Mapeo inbound de las propiedades JMS para las partes del mensaje normalizado NMR.
• Mapeo de las partes del mensaje NMR a mensajes JMS outbound.
• Normalización y des normalización de mensajes JMS y de las partes del mensaje en el WSDL.
• Invoca a operaciones request-response.
• Búsquedas JNDI a conection factories.
• Sincronización y concurrencia en modo CC.

Java Business Integration, JBI. (1)

2009-04-17T14:38:00.001-04:00

JBI (Java Business Integration es una especificación desarrollada bajo la JCP y es un estándar basado en Java con el objetivo de abordar actividades para el desarrollo de Integración de Aplicaciones Empresariales (EAI, Enterprise Application Integration) y B2B (Business two Buiness) basados en los paradigmas y principios de la Orientación a Servicios (SOA). La referencia de JBI versión 2.0 en la JCP es el JSR-312.

Mediador basado en la Arquitectura.
JBI define una arquitectura basado en plug-in donde los servicios pueden ser conectados dentro del entorno JBI en tiempo de ejecución. JBI proporciona interfaces bien definidas para los servicios que interactúen con en un entorno JBI en tiempo de ejecución. Los servicios requieren ser expuestos por intermedio de una interfaz en el JBI runtime para que puedan ser ruteados los mensajes. El entorno de ejecución de JBI actúa como mediador entre los servicios que están deployados en el entorno.

El núcleo principal JBI runtime comprende de los siguientes componentes dentro de la misma JVM:
• Framework de Componente: Permite el deployment de diferentes tipos de componentes en el JBI runtime.
• Normalized Message Route: Permite un mecanismo estándar de intercambio de mensajes entre los servicios.
• Framework de Gestión: El framework de gestión permite el deploy, gestión y monitoreo de los componentes en tiempo de ejecución y está basado en JMX.

Modelo de Componentes.
JBI define dos tipos de componentes en el entorno de ejecución:
Service Engine (SE).
Son componentes responsables para la implementación de aplicaciones de lógica de negocios y otros servicios. Los componentes SE internamente pueden ser utilizadas en diferentes tecnologías y principios de diseño. Los componentes SE pueden ser tan simples como un componente que proporciona un servicio de bajo nivel como la transformación de datos y la traducción o algo más sofisticado, como por ejemplo un BPEL que contiene modelos de procesos de negocio.
Binding Component.
Son componentes que principalmente se utiliza para proveer un nivel de transporte a los servicios que están deployados en el JBI runtime. Los BC pueden ser de diferentes tipos e incluyen:
• Permite la comunicación remota con algún sistema externo usando protocolos de transporte estándar.
• Habilitar en la Maquina Virtual la invocación de dos servicios deployados en la misma Maquina Virtual.
• Habilita la comunicación entre servicios utilizando el estándar WS-I (Web Service Interoperability).
Un aspecto clave de JBI es el desacople entre el Service Engine (SE) y los Binding Component (BC) de modo que la lógica de negocio no es dependiente de los detalles de la infraestructura para invocar y/o consumir los servicios. Esto promueve una arquitectura flexible y extensible. Ambos componentes SE y BC de JBI pueden ser consumidores de servicios o proveedores de servicios.
Ambos componentes SE y BC proveen de interfaces para el JBI runtime para aceptar mensajes desde el JBI runtime.

Glassfish ESB V2.

2009-04-17T14:35:00.000-04:00

Glassfish Enterprise Service Bus es un ligero y ágil plataforma de Bus de Servicios, basado en el proyecto Open Source openESB incluyendo todo los paquetes e innovación del proyecto, con el objetivo de ser un Enterprise Service Bus de clase mundial Glassfish ESB actualmente proporciona de una flexible y extensible plataforma para la construcción y deployment de aplicaciones SOA y soluciones de integración.

La plataforma consiste de un núcleo para el runtime de aplicaciones, componentes, herramientas para el tiempo de diseño y soporte por Sun Microsystem.
El núcleo de runtime está disponible de diversas formas, por ejemplo, cubicarse como un servidor independiente o con un servidor de aplicaciones.

La versión disponible para descargar y desarrollar desde el sitio de Sun contiene:
• Glassfish Application Server 9.1 v2.
• Open ESB Core Component V2.
• Java Business Integration (JBI) service engine.
• Java Business Integration (JBI) Binding component.
• Java Business Integration (JBI) component tooling.
• Sun JMS IQ Manager.
• Netbeans IDE 6.1.

Arquitectura.

Características.
Características de Glassfish Application Server.
• Full compatible con Java Enterprise Edition.
• Clustering para escalabilidad y alta disponibilidad.
• Fácil para mejorar el rendimiento.
• Fundación Open Source, Glassfish Application Server está basado en el proyecto Glassfish.
• Sofisticada Administración.
• Soporte integrado para el desarrollo.
• Interoperabilidad con Web Service .Net 3.0.
• Update center.
• Mejora la productivdad.

Instalación de Oracle SOA Suite sobre Linux.

2008-12-03T23:16:00.009-03:00

Introduccción

Oracle SOA suite es una completa herramienta para dar soporte a los requerimientos de una arquitectura orientada a servicios.

Para mas información por favor acceder a la página oficial de oracle SOA suite.

http://www.oracle.com/technologies/soa/soa-suite.html

Pre-Requisitos.

Oracle Base de Datos 10 o superior.

RDBMS ó versión XE.

Sistemas operativos:

redhat-Red Hat Enterprise Linux AS release 3

redhat-Red Hat Enterprise Linux AS release 4

redhat-Red Hat Enterprise Linux ES release 3

redhat-Red Hat Enterprise Linux ES release 4

suSE-9.

Para la instalación de Oracle SOA Suite sobre algún sistema operativo linux no compatible, es decir, no certificada por Oracle, debes hacer lo siguiente:

Debes crear un archivo

nano /etc/redhat-release

y agregar algún nombre de los S.O certificados es decir,

redhat-Red Hat Enterprise Linux AS release 4

guardas y cierras

Importante: Cuándo termines la instalación y usas otra distribución linux debes eliminar el archivo.

Instalación.

Para la instalación de Oracle SOA Suite primero debes acceder al sitio web de oracle y descargar la versión estable, en este manual se utilizó la siguiente versión: Oracle SOA Suite 10g release 3 (10.1.3.x), descargado de la siguiente URL

http://download.oracle.com/otn/linux/ias/101310/soa_linux_x86_101310_disk1.cpio

Cuándo termines de descargar el archivo debes proceder a descomprimir el archivo utilizando cpio -idvm <>

Cuándo termine de descomprimir el archivo se debe dar permisos de ejecución al archivo de la siguiente manera.

chmod +x runInstaller

Después de dar permisos debes ejecutar el archivo de la siguiente forma:

./runInstaller

El comando debe desplegar lo siguiente en tu consola:

Iniciando Oracle Universal Installer...

Comprobando requisitos de Installer...

Comprobando la versión del sistema operativo: debe ser redhat-Red Hat Enterprise Linux AS release 3, redhat-Red Hat Enterprise Linux AS release 4, redhat-Red Hat Enterprise Linux ES release 3, redhat-Red Hat Enterprise Linux ES release 4 or SuSE-9

Aprobado

Se han cumplido todos los requisitos de Installer.

Comprobando el espacio temporal: debe ser mayor que 400 MB. Real 40413 MB Aprobado

Comprobando el espacio de intercambio: debe ser mayor que 512 MB. Real 5718 MB Aprobado

Comprobando el monitor: debe estar configurado para mostrar al menos 256 colores. Real 16777216 Aprobado

Comprobando si la velocidad de CPU es superior a 300 MHz. Real 2000 MHz Aprobado

Preparando para iniciar Oracle Universal Installer desde /tmp/OraInstall2008-12-01_03-13-44PM. Espere...leandro@cyborg-laptux:~/Personal/installers/bea_product/soa_suite$ Locking assertion failure. Backtrace:

#0 /usr/lib/libxcb-xlib.so.0 [0xb7950767]

.....

Seguido debe lanzar el wizard de instalación de Oracle SOA Suite.

Paso 1.

En el wizard paso 1, lo primero será seleccionar el directorio de instalación para la suite Oracle SOA, luego puedes seleccionar la instalación básica que ofrece, com lo muestra la siguiente ilustración.

Illustration 1: Instalación de Oracle Application Server SOA Suite

Nombre instancia: asInstancia

Usuario Administración (por defecto): oc4jadmin

Clave: admin2008

Paso 2.

En el wizard paso 2, como instalación básica, debes proveer información acerca de la conexión a los esquemas de la base de datos (solamente oracle rdbms o XE para desarrollo), como lo muestra la siguiente ilustración.

Illustration 2: Instalación de Oracle Application Server SOA Suite

En nuestro caso si estamos utilizando un ambiente de desarrollo “XE” en nuestro localhost, debemos proveer la siguiente información:

Conexión: localhost:1521:xe

Seguido de la clave del usuario SYS: sys

Proveer de las contraseña para los siguientes esquemas:

Nombre	Clave
ORABPEL	orabpelpwd
ORAESB	oraesbpwd
ORAWSM	orawsmpwd

Importante: Esquemas no existen.

En el caso que no existan los esquemas debes crearlos por intermedio de algun usuario con privilegios de DBA. También podemos utilizar el archivo que viene en Orace SOA Suite que se llama irca.sh (se los recomiendo) ubicado en:

DIR_PROGRAM/install/soa_schemas/irca.

DIR_PROGRAM es la ruta (carpeta) raíz donde se descomprimio el archivo Oracle SOA Suite.

Para crear los esquemas, objetos de cada usaurio con irca debemos escribir lo siguiente en nuestra consola, ver siguiente recuadro como ejemplo:

leandro@cyborg-laptux:~$ cd /home/leandro/Personal/installers/bea_product/soa_suite/install/soa_schemas/irca

leandro@cyborg-laptux:~/Personal/installers/bea_product/soa_suite/install/soa_schemas/irca$ ./irca.sh

>Resultado

Integration Repository Creation Assistant (IRCA) 10.1.3.1.0

>Ingresar la ruta donde está instalado la JDK

Enter JDK 1.4.x/1.5.x location: /home/leandro/Programas/java/jdk1.5.0_15

Enter database "host port serviceName" [localhost 1521 orcl]: localhost 1521 xe

Enter sys password:

Running IRCA for all product(s):

connection="localhost 1521 xe", , orabpelUser=ORABPEL, esbUser=ORAESB, orawsmUser=ORAWSM

Validating database ...

Validating database character set ...

Running prerequisite checks for ORABPEL ...

Enter password for ORABPEL:

Loading ORABPEL schema (this may take a few minutes) ...

Running prerequisite checks for ORAESB ...

Enter password for ORAESB:

Loading ORAESB schema (this may take a few minutes) ...

Running prerequisite checks for ORAWSM ...

Enter password for ORAWSM:

Loading ORAWSM schema (this may take a few minutes) ...

INFO: ORABPEL schema contains 225 valid objects.

INFO: ORAESB schema contains 180 valid objects.

INFO: ORAWSM schema contains 90 valid objects.

IRCA completed.

Please check for any ERROR message above and also check the log file

irca2008-12-01_05-26-16PM.log for any error or other information.

leandro@cyborg-laptux:~/Personal/installers/bea_product/soa_suite/install/soa_schemas/irca$

Y listo, quedan creados los esquemos, con sus tablas, datos, etc.

Paso 3.

Click en el botón “Instalar”.

Paso 4.

En este paso el wizard de instalación nos solicita los directorios donde se encuentran las credenciales, en el caso que ya exista el directorio debemos especificar la ruta correcta donde están instaladas, en nuestro caso dejaremos los directorios por defecto por ser esta la primera vez.

Seguido debes seleccionar el usuario que tenga privilegios de lectura y escritura sobre el directorio donde se encuentran las credenciales.

Illustration 3: Especificar directorio y credenciales.

Si el usuario seleccionado no tiene los privilegios de lectura y escritura sobre los directorios y las credenciales el wizard enviará el siguiente mensaje, como lo muestra la siguiente ilustración.

Illustration 4: Problemas de privilegios sobre credenciales y directorios.

Como lo indica el mensaje anterior debemos acceder a una nueva consola y ejecutar el comando que nos indica como un usuario root o aplicando sudo podemos continuar.

Si hemos ejecutado existosamente el comando nos desplega el siguiente mensaje:

leandro@cyborg-laptux:~/oraInventory$ sudo ./orainstRoot.sh

[sudo] password for leandro:

Creando el archivo de punteros del inventario de Oracle (/etc/oraInst.loc)

Cambiando el nombre de grupo de /home/leandro/oraInventory a leandro.

leandro@cyborg-laptux:~/oraInventory$

Paso 5.

El wizard validará las dependencias de la instalación, tales como:

Si hemos creados los esquemas.
Que esten correctamente las password de los esquemas.
Dependencias de librerias.

La siguiente ilustración nos muestra un ejemplo:

Illustration 5: Check List de dependencias.

Si lo anterior esta correcto el wizard continuara hasta completar la instalación oracle application server SOA, com lo muestra la siguiente ilustración.

Illustration 6: Instalación y configuración de Oracle Application Server SOA Suite

Al completar la instalación el wizard nos indicará, solo si estamos instalando con un usuario sin privilegios el siguiente mensaje:

Illustration 7: ejecución de Root.sh

Debemos abrir una consola y ejecutar como root o sudo el comando que nos indica, al momento de ejecutarlo en nuetsra consola nos responderá de la siguiente manera:

leandro@cyborg-laptux:~/Programas/java/oracle/product/10.1.3.1/OracleAS_1$ sudo ./root.sh

[sudo] password for leandro:

Running Oracle10 root.sh script...

The following environment variables are set as:

ORACLE_OWNER= leandro

ORACLE_HOME= /home/leandro/Programas/java/oracle/product/10.1.3.1/OracleAS_1

Enter the full pathname of the local bin directory: [/usr/local/bin]:

Copying dbhome to /usr/local/bin ...

Copying oraenv to /usr/local/bin ...

Copying coraenv to /usr/local/bin ...

Adding entry to /etc/oratab file...

Entries will be added to the /etc/oratab file as needed by

Database Configuration Assistant when a database is created

Finished running generic part of root.sh script.

Now product-specific root actions will be performed.

leandro@cyborg-laptux:~/Programas/java/oracle/product/10.1.3.1/OracleAS_1$

Si el comando anterior se ejecuto correctamente, como lo muestra la tabla anterior seguimos con la instalación haciendo click en aceptar en el wizard (ilustración 9).

Al momento de aceptar el wizard seguirá con la instalación del resto de los componentes, ESB, BPEL, WSM como lo muestra la siguiente ilustración:

Illustration 8: Instalación de los siguientes componentes.

En el caso que exista un error en la instalación puedes seleccionar la herramienta y reintentar nuevamente.

Paso 6.

Al terminar la instalación de todas las herramientas con éxito es el fin de la instalación y debiera desplegar la siguiente ilustración.

Illustration 9: Fin de instalación.

Para comprobar que los componentes fueron instalados debemos acceder a la siguiente URL.

http://localhost:8889

Iniciar el Servicio.

Para iniciar la Suite Oracle, debemos abrir una terminal (consola) y accedemos a ingresar al directorio donde está instalada la Oracle SOA Suite.

INSTALL_DIR/product/10.1.3.1/OracleAS_1/opmn

Una vez ingresado a directorio debes escribir el siguiente comando:

./bin/opmnctl startall

El comando debe responder de la siguiente forma:

opmnctl: starting opmn and all managed processes.

Estado del Servicio.

Para chequear si está funcionando o se ha inicializado el servicio sin problemas ingresamos el siguiente comando:

./bin/opmnctl status

El resultado del comando es similar a:

Processes in Instance: asInstancia.cyborg-laptux

Ias-component	process-type	Sid	status
OC4JGroup:default_group	OC4J:home	9142	Alive
ASG	ASG	N/A	Down

Para saber que los servicios del opmn se han iniciado correctamente deben mostrar un sstado de “Alive”, en algunos casos si muestra “Init” habria que esperar que cambie a Alive o si marca “Error” hay que detener el servicio.

Si los servicios se han cargado con éxito podemos abrir la consola de administración de Oracle SOA Suite, colocando la siguiente URL en el browser.

http://localhost:8889/

Detener el Servicio.

Para detener el servicio se debe escribir el comando:

./bin/opmnctl stopall

Bloqueo del teclado con Netbeans 6.1

2008-09-25T00:02:00.004-04:00

Hola a todos hoy quiero compartir con uds un problema que tuve con Netbeans 6.1 utilizando compiz+emerald sobre mi ubuntu hardy 8.04. Desarrollo algunos web services y procesos bpel para mi buen amigo slack para integrar unos sistemas oracle y trabajando con compiz+emerald ocurria que el teclado se quedaba bloqueado cuando trataba de importar un clase o codificada hasta usar ctrl+space para completar la palabra clave. Intente instalando netbeans nuevamente dado que hace poco habia migrado desde debian etch con jdk1.5 a ubuntu con jdk1.6 sin formatear mi /home/usuario/.

Comparto con uds y sobre todos para los fanaticos que utilizan sobre su linux compiz+emerald, las soluciones son:

1.- Vuelvan a utilizar la jdk1.5 y mantengan la variable AWT_TOOLKIT=MToolkit

2.- Utilicen la jdk1.6 sin la variable AWT_TOOLKIT=MToolkit.

Espero que les sirva!

Estrategia para la implementación de SOA (I)

2008-06-23T21:13:00.030-04:00

Hola a todos!! Hoy hablaré de un tema bastante importante e interesante para los que buscan diseñar una estrategia para la implementación de SOA o simplemente aquellos que buscan un camino para está innovadora arquitectura, y permitir que las empresas puedan integrar sus procesos, personas, tecnología y prácticas mediante esta estrategia. Este artículo enseña el modelo de dominio SOA basado en seis partes fundamentales y necesarias para este cambio Tecnológico y cultural que deben cumplir las diferentes áreas de las empresas.

Actualmente en las empresas poseen objetivos estratégicos, comerciales, operaciones y tecnológicos que van por diferentes caminos, quizás para el mismo norte, pero cada uno de las áreas se plantean sus propios objetivos y metas en rigor de su crecimiento económico, productivo el cuál es súper loable y respetable, pero esas iniciativas de cierto modo están lejos del crecimiento comun de negocio y procesos en apoyo de IT, fundamentalmente por qué sus necesidades son de corto plazo. Por esto es importante que las áreas dentro de una empresa estén alineadas bajo las mismas metas, objetivos y se puedan integrar mediante el modelamiento, rediseño de procesos y mejorar las prácticas de trabajo.

SOA es una estrategia que se implementa a largo plazo, que requiere sustentar su objetivo en el camino hacia una transformación de la IT que se entregará, dado que también es importante considerar que debemos responder de inmediato a las iniciativas de negocios de las empresas. En consecuencia, los beneficios de SOA solo será la realidad si se preserva un equilibrio entre los objetivos de largo plazo y los de corto plazo. Podemos mantener este equilibrio mediante la integración de cada organización de la empresa.

En este artículo encapsularemos estás prácticas en seis dominios denominado Domain Model for SOA, estos seis dominios cada uno se deben considerar de forma igualitaria proporcionando un marco coherente para la Arquitectura Orientada a Servicios (SOA).

Los seis dominios, si bien son distintos, están interrelacionados y son interdependientes. La ejecución de cada dominio en igualdad de atención es fundamental para el éxito de una empresa que implica su iniciativa a SOA.

Considerar que SOA es un nuevo término dentro de las empresas, y es fundamental rescatar que para el éxito de este nuevo camino es poder integrar las personas, procesos, prácticas, plataforma. Las empresas y cada área de la empresa se deben considerar como una sola y no como una entidad individual.

La siguiente ilustración muestra lo descrito anteriormente, la Integración es clave e importante para el éxito de la implementación.

Seis dominios de SOA.

Respondiendo a los desafíos.

Cada uno de los seis dominios direccionan al desafío con éxito a la entrega y de una correcta implementación de una Arquitectura SOA.

1.- Estrategias de Negocio y Proceso.

Desafío:
Proveer de implementaciones IT que soporten a las empresas y sus necesidades cambiantes.

Respuesta:
Proporcionar de un entorno (ambiente) que vincule la gestión (management) y medición de las IT con la estrategia empresarial y faculte a ambos a trabajar juntos con un proceso de mejoramiento continuo.

2.- Arquitectura.

Desafío:
Casí todas las empresas financian y construyen proyectos IT para cada una de las línea de negocio, dejando a toda la empresa con problemas de integración y procesos, pensados para un futuro dado que de esa forma se crean obstáculos para el cambio.

Respuesta:
Un entorno IT basado en estandares (normas), distribución, de bajo acoplamiento y sus procesos de negocio representados en diseños para responder a los cambios e integrar las funcionalidades a nivel de empresa.

3.- Construcción por Bloques. (Building Block)

Desafío:
La falta de consistencia (coherencia) y repetibilidad en la implementación de aplicaciones IT dificultan a la mayoría de las empresas en el logro de sus objetivos con respecto a los presupuestos de IT.

Respuesta:
Construir una base común de componentes, aplicaciones, servicios, basados en estandares (normas) en la cuál permita entregar IT y proveer de una base única para lograr la consistencia y maximizar la capacidad de desarrollo repitiendo estos éxitos a través de la reutilización de las aplicaciones y contar con una infraestructura principal.

4.- Proyectos y Aplicaciones.

Desafío:
TI es desarrollado tradicionalmente por proyectos dentro de las líneas de negocio, creando situaciones donde el capital excede, duplicando funcionalidad, duplicando desarrollo en donde la integridad de los procesos de la empresa se ve comprometida.

Respuesta:
Catalogar, categorizar, realizar refactoring de los sistemas y aplicaciones que ofrecen funcionalidades importante para la empresa, estandarizando el uso de la tecnología, normalizando funcionalidades, administrando la redundancia de nuevas aplicaciones así no se compromete consistencia en la ejecución de los procesos de negocio.

5.- Organización y Gobernanza.

Desafío:
El crecimiento orgánico de las empresas mediante la creación de soluciones individuales para los nuevos requisitos (funcionales, rendimiento) de arquitectura IT son dificiles y costosas para responder a los cambios.

Respuesta:
Una estructura organizacional y el mando para regular, estandarizar y normalizar la entrega de las IT para asegurar que IT cumpla con las necesidades de negocios de las empresas y maximizar el uso de la funcionalidad desarrollada.

6.- Costos y Beneficios.

Desafío:
El costo de las IT para el beneficio recibido es una constante fuente de fricción entre las organizaciones IT y los negocios que apoyan.

Respuesta:
Planificar y ejecutar las implementaciones IT para crear tempranamente valor sostenible y que se aproveche las inversiones existentes en IT, mientras se acomoda el cambio y crecimiento.

SOA (Arquitectura Orientada a los Servicios)

2008-06-16T23:05:00.010-04:00

Hola a todos!!!, hace un tiempo atrás, para ser más exacto hace 1 año 8 aprox... Comencé a investigar acerca de este nuevo mundo, SOA, este mundo de como visualizar una arquitectura empresarial desde una forma más transversal, que todo pueda conversar, independiente del lenguaje de programación en el cuál un sistema está escrito.

En un mundo globalizado que avanza tan rápido las empresas requieren desarrollar sistemas o aplicaciones que se adapten a las necesidades actuales de sus negocios, incluyendo interacturar con sistemas legacys, sistemas clientes, areas de operaciones, comercial, etc... Y quien sabe, lo que sea.

En muchos casos las empresas poseen sistemas legacy (antiguos) con décadas de desarrollo, soporte y mantención que en algunos casos no lo pueden reemplazar por su directa dependencia del negocio o riesgos de implementar nuevos sistemas desde cero. Cuál sería la solución para ello, desarrollar sistemas con nuevas interfaces, realizando una abstracción del negocio, funciones,etc... El cuál no todos están dispuesto a hacerlo, dado que no es menor hacerlo, redundar en funcionalidades y reescribir lógica de negocios es un riesgo que no todas las compañías pueden asumir.

Las interacciones entre los clientes, usuarios finales y usuarios de negocio van siendo cada vez más exigente y debemos proveer de sistemas flexibles a los cambios del negocio, desarrollar nuevas formas de interactuar.

¿Que es SOA?

SOA, es nada más que un concepto de arquitectura de software, SOA define la utilización de servicios para dar soporte a los requerimientos de los usuarios.

SOA tiene como por objetivo es que cada sistema o subsistema de las empresas presenten sus capacidades al resto de otros sistemas mediante la utilización de servicios, que permitan usar sus capacidades de una manera homogenea. Además de permitir a las empresas a darse cuenta que pueden realizar negocios combinando tecnología y procesos entregando una estrategia de gobernanza eficaz de la tecnología que gira entorno a la definición y reutilziación de servicios.

Conceptos importantes de SOA.

Visibilidad.

Para que el consumidor y el proveedor de un servicio puedan interactuar deben, primero, poder ‘verse’. La visibilidad implica conocimiento (el iniciador debe conocer la existencia de las otras partes), voluntad (los participantes deben estar predispuestos a interactuar) y alcanzable (los participantes deben tener un medio de interacción). El conocimiento requiere que el proveedor de un servicio sea capaz de hacer llegar los detalles del servicio (descripción y políticas) a potenciales consumidores. Se suele lograr por medios de publicación y descubrimiento. La voluntad para interactuar, de parte de un proveedor de servicio, puede ser sujeta a políticas (por ejemplo, puede requerir autenticación y autorización). Un consumidor y un proveedor de servicio pueden tener el conocimiento y la voluntad para proceder, pero si no son alcanzables, no podrá haber interacción.

Interacción.

La interacción implica realizar acciones frente a un servicio; generalmente involucra el intercambio de mensajes, pero también puede significar un cambio en algún estado compartido. Para permitir la interacción, se debe contar con un modelo de información (establecer el formato de la información intercambiada) y un modelo de comportamiento -acciones invocadas frente al servicio (modelo de acción) y los aspectos temporales (modelo de proceso) de interactuar con el servicio-.

Efectos en el mundo Real.

La ejecución de un servicio produce un efecto en el mundo real, que puede ser un cambio en un estado compartido o un dato en la respuesta. Un estado compartido es aquél al que tiene acceso tanto el proveedor como el consumidor del servicio. Las acciones internas que se realicen al ejecutar un servicio son, por definición, privadas y fundamentalmente desconocidas; es decir, un consumidor no sabe sobre el funcionamiento interno del proveedor y viceversa. Esto permite limitar las dependencias entre partes a las interfaces de interacción (mensajes, formatos de datos, etc.). Los efectos de un servicio deben estar especificados en su descripción.

¿Qué es un Servicio en SOA?
Un servicio en SOA es una función de aplicación empaquetada como un componente reutilizable para ser usado en un proceso de negocio.

El servicio proporciona información o facilita el cambio de datos de negocio de un estado válido y consistente a otro.

Un servicio SOA es autocontenido y sin estado.

La implementación concreta de un servicio SOA no es importante. A través de protocolos de comunicación bien definidos, los servicios pueden ser invocados de manera que se hace hincapié en la interoperabilidad y en la transparencia de localización

Beneficios de SOA

El mayor beneficio para las empresas es la agilidad. Las grandes empresas siempre están cambiando: o adquieren compañías, o hay nuevas adquisiciones de productos, o hay afinamiento de procesos de negocios, entre otras. El problema es que la industria de la tecnología tiene sistemas muy rígidos, y es difícil cambiarlos al mismo ritmo de la empresa. SOA otorga la posibilidad de hacer estos cambios de forma más rápida y flexible, agregando más dinamismo. Una empresa más flexible debiera ser una empresa más rentable.