16
Apr

Reset password OER/OSR

Algunas veces necesitamos resetear el password de algún usuario dentro del OER u OSR cuyo repositorio de usuarios está amarrado a una base de datos Oracle, a continuación demostraré una forma fácil de poder realizar esto, para ello necesitamos de lo siguiente:

  1. Conexión al esquema de OER/OSR
  2. Conocer el password de cualquier usuario

Cada herramienta OER/OSR mapea sus objetos a tablas relacionales, de igual manera los usuarios  y contraseñas.

La tabla donde se guarda los usuarios y contraseñas para OER es ENTSECUSERS, tal como se muestra en la siguiente imagen:
El OSR de igual manera mapea sus usuarios y contraseñas a una tabla relacional, la cual es PASSWD, tal como se muestra en la siguiente imagen:
Bueno, el metodo para resetear la contraseña es facil, se resume en lo siguiente:

Copiar el password encriptado del usuario del cual conocemos su contraseña y copiarsela al usuario del cual queremos resetear la password.
Por ejemplo, para el Oracle Service Registry (OSR):

SQL> select loginname, password from uddi.passwd;


deiby                                              wkBkLd75lDWMltqCwDYaWA==


admin                                            uRzRpUeBeQvqorr3QfpniQ==

Y sabemos que la contraseña del usuario “deiby” es “oracle” y el usuario al que queremos resetearle la contraseña es “admin”, entonces hacemos el siguiente update:

update uddi.passwd set password=’wkBkLd75lDWMltqCwDYaWA==’ where loginname=’admin’;

commit;


¡Listo! Ahora podremos logearnos al OSR con admin/oracle :)

Como recomendación, reinicie el Managed Server del OSR/OER.

Los mismo puede realizarse para el OER:

select username, password from oer.ENTSECUSERS;


deiby                                              wkBkLd75lDWMltqCwDYaWA==


admin                                            uRzRpUeBeQvqorr3QfpniQ==


update oer.ENTSECUSERS set password=’wkBkLd75lDWMltqCwDYaWA==’ where username=’admin’;

commit;


¿Funcionará el método con el DBA_USERS? pruebelo….. :)

Facebooktwitterlinkedinmailby feather
16
Apr

Oracle Service Registry Cannot obtain new connection

En algunas ocasiones es posible que el Oracle Service Registry (OSR) no pueda obtener una conexión desde el pool de conexiones creadas por el Data Source, esto puede producirse después de volver a realizar el despliegue de la aplicación del OSR.

Si buscamos errores en el log del Managed Server donde está desplegada la aplicación es posible que no encontremos información relevante. El log que se debería revisar es entonces:

$DOMAIN_HOME/servers//tmp/_WL_user/registry//public/serviceRegistry_errorEvents.log


En éste log vemos que las siguientes líneas aparecen:

<2013-04-11 15:46:02,557> – com.systinet.uddi.webui.WebUIRawService –  – EXCEPTION: org.systinet.uddi.account.AccountException: Initialization of accounts has failed. For help please contact the administrator of the registry.

<2013-04-11 15:46:03,518> – database_core.com.systinet.uddi.config.management.DatabaseConfig – Ignoring exception in event handler, it may be caused by unavailablity of database. – EXCEPTION: java.lang.RuntimeException: com.systinet.uddi.database.DatabaseCoreException: (12021) Cannot obtain new connection.

<2013-04-11 15:46:03,561> – database_core.com.systinet.uddi.config.management.DatabaseConfig – Ignoring exception in event handler, it may be caused by unavailablity of database. – EXCEPTION: java.lang.RuntimeException: com.systinet.uddi.database.DatabaseCoreException: (12021) Cannot obtain new connection.

<2013-04-11 15:46:03,563> – uddi_inquiry_v3.com.systinet.uddi.inquiry.v3.database.Get – DatabaseCoreException – EXCEPTION: com.systinet.uddi.database.DatabaseCoreException: (12021) Cannot obtain new connection.

<2013-04-11 15:46:03,565> – permission.com.systinet.uddi.permission.database.DBPermissionApiImpl – DatabaseCoreException – EXCEPTION: com.systinet.uddi.database.DatabaseCoreException: (12021) Cannot obtain new connection.

<2013-04-11 15:46:05,471> – uddi_inquiry_v3.com.systinet.uddi.inquiry.v3.database.Get – DatabaseCoreException – EXCEPTION: com.systinet.uddi.database.DatabaseCoreException: (12021) Cannot obtain new connection.


Como se logra ver en las lineas del log, claramente la conexión a la base de datos no se puede realizar. Entonces el problema puede ser causado por lo siguiente:

  1. El Data Source está creado en el weblogic con credenciales no validas.
  2. No hay comunicación entre la aplicación desplegada y el Data Sorce.

Sin embargo, al testear el Data Source desde el weblogic, se confirmó que el Data Source sí era válido y que las credenciales utilizadas eran correctas. Entonces solo queda una opción, el despliegue no se comunica con el Data Source.

Y aquí es donde viene la pregunta: ¿Cómo hace el despliegue para comunicarse con su Data Source?

Por intuición me recordé de aquella herramienta que el Oracle Service Registry trae con sus binarios llamada “setup.sh” o “setup.exe” según sea el SO sobre el cual este el OSR, me recordé que esta herramienta trae una opción de “reconfigurar la conexión a la base de datos”, donde se puede elegir en crear un tablespace, utilizar un tablespace existe y crear el esquema adecuado o simplemente conectarse a un esquema ya existente.


Para ejecutar esta herramienta en modo consola agregar la opción ” -c”, ejemplo “./setup.sh -c”

Esta herramienta está ubicada en:

$REGISTRY_HOME/bin

Utilicé esta herramienta para reconfigurar la conexión a la base de datos. Seleccioné la opción de “conectarse a un esquema existente”, ingresé los datos correctos de la base de datos: host, puerto, username, password, etc. La herramienta no retornó errores por lo que asumí que había realizado su tarea exitosamente.

Es necesario detenernos en este punto y revisar el log de la herramienta setup.sh, la cual se encuentra en:

$REGISTRY_HOME/log/setup.log

En este punto puede ser que muestre algún error relacionado con la librería “ojdbc6.jar” que debe estar agregada en el CLASSPATH del Managed Server donde está el OSR. Pero para mi problema, esta no fué la causa, pues la librería estaba correctamente agregada.

Bueno, prosigamos. Como indicaba, en el log del setup.sh no habian errores. Reinicié el Managed Server del OSR volví a ingresar a la aplicación y no, el problema no se habia solucionado, en el log seguía mostrando “Cannot obtain new connection”. Por intuición pensé que esta herramienta “setup.sh” volvía a reconfigurar todo lo necesario para restablecer la conexión entre la aplicación y el Data Source, pero no, no fue así. Entonces volví a la misma pregunta  ¿Cómo hace el despliegue para comunicarse con su Data Source?

Investigando llegué a la solución, el despliegue utiliza un archivo XML para comunicarse con el Data Source, este archivo es llamado “database.xml” y está ubicado en:


$DOMAIN_HOME/servers//tmp/_WL_user/registry//public/app/uddi/conf/database.xml


Este archivo es el que debe modificarse manualmente, indicando todos los datos correctos para lograr la conectividad con el Data Source: host, puerto, username, password, instance_name, data source name, etc.

Al modificar dicho archivo, reinicié el Managed Server del OSR, ingresé a la aplicación y pude por un momento imitar a Arquimides y exclamé ¡Eureka!

Facebooktwitterlinkedinmailby feather
5
Apr

Los sabores y colores de Oracle Exadata

Oracle está promoviendo fuertemente la solución Oracle Exadata, un servidor diseñado para procesar grandes cantidades de datos (Exabytes), optimizado para OLTP o para DWH. Recordemos un poco los prefijos:

103      kilo

106      mega

109      giga

1012    tera

1015    peta

1018   exa

Oracle sabe que constantemente los datos que se necesitan procesar se están incrementando, a continuación unos datos relevantes:

  • 2 billones de personas usan internet, y estas están generando cada vez más datos.
  • Un solo celular genera GB de información, multiplique esta información por el numero de celulares que existen ahora.
  • En el año 2,000 un Estudio dedicado a investigaciones espaciales registró en una semana más información que la que se había recolectado en toda la historia.
  • En 10 años una empresa de IT creció en datos hasta 140 Terabytes.

La arquitectura de este servidor es impresionante, toma en cuenta la optimización de varios aspectos como son IO, CPU, CACHE, Latencia, etc., desde el ensamblaje del hardware hasta los procesos que se ejecutan dentro de él. Consta principalmente de los elementos:
  • Exadata Database Servers
  • Exadata Storage Servers
  • Infiniband
  • Smart Flash Cache


Oracle Proporciona dos tipos de Oracle Exadata:

  1. Oracle Exadata X2-2
  2. Oracle Exadata X2-8

El Oracle X2-2 Posee los siguientes componentes de Hardware:


El Oracle X2-8 Posee los siguientes componentes de Hardware:



El Oracle Exadata X2-2 a su vez, existe en 3 formas:

  1. Oracle Exadata X2-2 Full Rack
  2. Oracle Exadata X2-2 Half Rack
  3. Oracle Exadata X2-2 Quarter Rack

¿Es escalable Exadata? Claro que sí. Existen expansiones de Oracle Exadata. Por ejemplo, si se tiene un X2-2 Quarter Rack, se puede expandir a Full Rack. Si un Full Rack ya no es suficiente, se pueden agregar más Exadata Machines (cualquier clase). ¡¡¡Con dos switches adicionales se puede llegar a tener hasta 36 Exadata Machines en una sola configuración!!!

¿Estas Listo para Exadata?


Facebooktwitterlinkedinmailby feather
2
Apr

Variable Vacía en BPEL

Hace unos días encontré con otros colegas un problema en el desarrollo de un servicio web con BPEL en JDeveloper 11.1.1.5 que quizás no es tan común, pero que siempre es bueno saber la solución, ya que al principio parecería muy raro el comportamiento del Motor de SOA en el Weblogic (10.3.5), más sin embargo, el verdadero problema radica en cómo estemos describiendo nuestros servicios, en este caso el problema se encontraba en el XSD.

Descripción:

Se realiza una invocación de un Servicio Web externo, mediante el elemento "invoke" del BPEL. El servicio web invocado es síncrono, por lo que recibe una entrada de datos y retorna datos de salida. Por lo tanto, en un elemento "invoke" se debe asociarle dos variables de BPEL, llamemosla "vinput" para la variable de entrada de datos y "voutput" para la variable de salida de datos.

Los datos retornados por el servicio mediante "voutput" se pasan a la variable de salida del servicio BPEL.

A continuación el diagrama del BPEL en JDeveloper, como verán es sencillo:

 

 
 
Síntomas:

Al debuggear la instancia de ese servicio SOA en el Enterprise Manager, se ve que la invocación del servicio externo es exitosa, se le envía datos de entrada y retorna los datos correctos de salida. Es decir la variable "vinput" es poblada por nosotros y la variable "voutput" es poblada por el "invoke", todo esto es exitoso.

Al querer utilizar los datos de "voutput" y pasarlos a la salida final del servicio SOA, el motor de SOA encuentra a la variable "vouput" VACIA y por lo tanto el nuestro servicio SOA no retorna datos.

A continuación una imagen donde se puede ver que se "voutput" es poblada con los datos de salida, pero en el "transform" NO hay datos.

 

 
El elemento "transform" es utilizado correctamente, se toman los campos de "vouput" y se mapean a los cambos de la salida del servicio SOA, se utiliza un elemento "for-each" pues el servicio retorna un array de datos.

A continuación la imagen del XSL.

 

 
Solución:
 
En el XSD del servicio Externo se utilizan las siguientes clausulas dentro del tag :

attributeFormDefault="qualified" elementFormDefault="qualified"

Al remover estas clausulas y volver a desplegar el servicio, la ejecución fue exitosa.

Antes:

<xsd:schema attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="https://…….

Despues:

<xsd:schema targetNamespace="https://……

 

Facebooktwitterlinkedinmailby feather
1
Apr

SOA, la última Innovación Tecnológica

En los 70:

Al principio, usted gestionaba su negocio con métodos manuales y basados 100% en procedimientos que realizaban personas. Con la llegada de los ordenadores y los programas informáticos, usted empezó a resolver partes de la operativa de su negocio de forma mecanizada y por tanto recicló a su personal para que en lugar de procesar datos, los introdujera en una máquina de tarjetas perforadas y el ordenador realizará los cálculos correspondientes. Más tarde, se evolucionó a las aplicaciones informáticas. Con este gran paso, le gestionábamos de forma mecanizada su cartera de clientes con la aplicación Gestión de clientes, sus proveedores con Gestión de Proveedores, su stock con Gestión de Almacén, su Contabilidad con una aplicación de Financiera y así un largo etcétera.

Dichas aplicaciones se desarrollaban a gusto y medida del cliente, pero encarecían notablemente los costes de mantenimiento y evolución de dicho software, ya que cada cliente debía pagar de forma individual sus propias adaptaciones a normativas, regulaciones, mercado, nuevas  líneas de negocio…Además, las empresas invirtieron de nuevo en formación y/o reciclaje de sus empleados: Operaciones, Finanzas, Almacén….todos debían ser capaces de utilizar las aplicaciones que les correspondían e intercambiarse la información necesaria entre los distintos departamentos que la requerían. Resultado: montañas y montañas de papel pijama que paseaban en carritos de una mesa a otra. Sólo les habíamos cambiado las herramientas de trabajo y aunque el circuito y el proceso era el mismo, el negocio ganaba en rapidez de gestión y por tanto de respuesta al mercado y a sus clientes.  Un nuevo reto para los CI y una nueva solución tecnológica.

Los 80:


Desarrollamos aplicaciones estándar para todos los clientes e integramos dicha aplicación con el resto de las existentes. Así conseguimos que el intercambio de información sobre un medio físico como el papel se transformara en intercambio de datos de forma automática entre las aplicaciones. ¡Bravo, señores informáticos¡. Conseguimos reducir costes de mantenimiento, ya que los posibles errores del software, las mejoras y evoluciones se distribuyeron a todos los clientes que habían adquirido dichas licencias por un módico porcentaje anual sobre el precio inicial de las mismas. Pero no olvidemos los costes de adaptación a las particularidades de los grandes clientes, que lógicamente exigían.

Y respecto a la integración, otro ¡bravo¡ Ya habíamos creado el famoso ¡¡¡spaghetti!!! Cada aplicación recibía información del resto para procesar y entregar otra tanta cantidad de la misma para todas las demás. Esto implicaba un nuevo sin fin de programas que tratasen y generasen respectivamente dichos datos. Consecuentemente, la ventana horaria del tratamiento batch se ampliaba, se complicaba la dependencia entre aplicaciones y creamos los equipos de guardia para resolver lo que pudiera ocurrir fuera del horario establecido de trabajo. Además, se ahorraba en costes de gestión, ya no era preciso tanto personal administrativo, se necesitaban informáticos de desarrollo, de técnica de sistemas, de explotación, bases de datos,….Pero tranquilos señores clientes, los CI somos fundamentalmente “solucionadores”.

Los 90 (principios):


Les creamos los ERP – y seguimos con las siglas -Enterprise Resource Planning ó Planificación de Recursos Empresariales. Una solución global y completa para gestionar todo el negocio de su Compañía, incluyendo las áreas comunes de cualquier negocio (Financiero, Recursos Humanos, Provisión,…) con las específicas de su sector de mercado. Paralelamente, introducimos el concepto de modularidad, es decir, desarrollamos aplicaciones más sofisticadas y que cubrían más operativa, pero independizando partes de la misma que llamaríamos módulos y que pueden ser reutilizadas desde distintos programas. Así creamos el “súper paquete de software” con un conjunto de módulos comunes y otro conjunto con aquellos específicos que componían la vertical del negocio y consiguiendo tener todo integrado desde el punto de vista de datos. ¿Pero la naturaleza del sector de negocio es tan distinta entre unos y otros? (un Banco vs una Operadora de Telecomunicaciones, por ejemplo) y la competencia de mercado tan alta, que pasa por ofrecer productos propios de cada Compañía a sus clientes finales. Ahí es donde el ERP empieza a no encajar del todo, porque cada empresa tiene necesidades diferentes y objetivos propios. Incluso perteneciendo al mismo sector, debe diferenciarse de la competencia y aportar su propio valor añadido, sus propios productos y soluciones; y claro, sus sistemas de información no pueden ser los mismos que los de la competencia. Bien, adoptamos el ERP para los procesos de gestión y administración de la Compañía y seguimos con nuestras aplicaciones específicas del negocio. ¿Reducimos integración? Poca cosa. Ahora teníamos que comunicar las aplicaciones propietarias con el ERP que nos exigiría unos formatos concretos e incluso unos desarrollos con un lenguaje de programación concreto formatos concretos e incluso unos desarrollos con un lenguaje de programación concreto. Fuimos modularizando y nuestras aplicaciones pasaron a ser multi-país, multi-entidad, multi-moneda, …, pero el spaghetti crece y crece. No olvidemos a las personas. Formamos a los de negocio para que se adapten a las nuevas tecnologías y evolucionamos a los informáticos con nuevos lenguajes y técnicas de programación.

Los 90 (mediados):


Diseñamos una solución software y de arquitectura de sistemas (“middleware”), que permitiese que las aplicaciones heterogéneas, en distintas máquinas y ubicaciones físicas pudieran intercambiarse información tanto en tiempo real (on line) como diferido (batch),

comunicándose con un único intercambiador de información y no directamente entre ellas una a una. Bienvenido el EAI – Enterprise Application Integration ó Integración de Aplicaciones de Empresa. Las aplicaciones requerían y suministraban información a partir de este gestor que funcionaba como una “cola de peticiones” o “cola de mensajes”. Ya no teníamos comunicación spaghetti, ahora nuestro formato era en estrella. No obstante, seguimos realizando una entrega por cada petición.

Los 90 (finales):


Los Grupos empresariales, la internacionalización de las Compañías y la inmediatez de los servicios, requería la apertura de nuevos canales (telefonía, Internet,..) que permitiese a los clientes finales contactar en cualquier momento y desde cualquier lugar.  Las redes de computadores cada vez se hacen más amplias y están más deslocalizadas. Necesitábamos de un dispositivo software que actuase como Application Server ó Servidor de Aplicaciones, que gestionara la mayor parte de la lógica de negocio y acceso a los datos de la aplicación. Los clientes finales van utilizando cada vez más los servicios que ponen a su disposición las Compañías a través de los distintos canales de acceso, el negocio crece y crecen exponencialmente las peticiones de información, y el cliente requiere inmediatez. El formato “cola de mensajes” ya no es suficiente y se evoluciona al “bus de datos” y concepto “publicación –suscripción”. Ahora, la aplicación origen sólo entrega la información una vez al “bus” y desde ahí, la captura cada aplicación que la requiera. Los CI tenemos mucho trabajo adaptando los Sistemas de Información a las nuevas tecnologías.

El 2000 y su efecto:


Falsos profetas, malos augurios, el fin del mundo….Los CI hemos dedicado mucho tiempo y esfuerzo, pensando, diseñando y desarrollando soluciones que redunden en mejorar los Sistemas de Información de las Compañías y por tanto su negocio. Hemos ido cubriendo con capas y capas de tecnología a esos “viejos” programas Cobol de los 70, a esos millones y millones de líneas de código que siguen ejecutándose día tras día, utilizando los mismos modelos de Base de Datos. Datos que costaba mucho almacenar en los 70 y que los CI reducíamos al máximo, empaquetándolos, no guardando datos calculables, definiendo la longitud mínima….Grabando los datos de fecha con las dos últimas posiciones y realizando los cálculos entre fechas con el mismo formato. ¿Quién pensaba que 30 años después estos “programas dinosaurios” seguirían funcionando?.

A las puertas del siglo XXI, batallones de becarios recién titulados con la ilusión puesta en las nuevas tecnologías, hijos de la Playstation y de los CI de los 70, ampliaron los modelos de datos y revisaron línea por línea los programas de sus progenitores adaptándolos al “efecto 2000”.¿Frustrante? Nada que no arregle el dinero. Así que paguemos a los becarios lo que nos pidan que lo trasladaremos a las empresas. A fin de cuentas, gracias a nosotros, los CI, el negocio cada vez va mejor y las Compañías no van a escatimar en gastos con todo lo que se juegan. El 31 de diciembre de 1999, millones de CI en todo el mundo hicimos guardia al pie del ordenador con todo el dispositivo posible de contingencia activado. La suerte y como no, nuestro buen trabajo, nos permitió que tras las 12 campanadas respiráramos con alivio: las comunicaciones, la electricidad, el gas,…., hasta los cajeros automáticos funcionaban. Con los ordenadores a salvo, los CI podíamos centrarnos de nuevo en la evolución de la Tecnología.

2000-2001:


Con el siglo recién estrenado, creamos los Portales de Internet, donde el Servidor de Aplicaciones y el middleware son piezas fundamentales; y que permite a las empresas gestionar y divulgar su información, desde un único punto de acceso a usuarios internos (empleados) y externos (clientes, proveedores, organismos reguladores,…). Señores de negocio, hemos inventado el e-Business y con él más siglas: B2B (Business to Business ó negocio entre empresas); el B2C (Bussines to Customer ó a Clientes) ó B2G (Business to Goverment ó con Organismos gubernamentales). Su negocio, antes local, está ahora abierto a la globalización. Ha transformado su empresa en una e-Communitie.

Efecto crisis 11M – 2001:


…y efecto de la globalización, los siguientes tres años serán duros para la economía mundial. El sector Servicios, y por tanto los CI arrastrados por ella ven como se reduce la inversión en Tecnología. Imposible soportar los salarios inflados de los junior en un momento donde las Compañías que tanto negocio nos han dado para así potenciar y desarrollar el suyo, reducen sus necesidades y reclaman que bajemos nuestras tarifas. Resultado, EREs -expedientes de regulación de empleo (las siglas no sólo las usamos los CI) y a apretarse el cinturón. Ya se sabe cuando el hambre aprieta da alas a la imaginación. Las crisis se remontan y los buenos tiempos vuelven. Nuevo reto para los CI, aprovechemos para pensar en la siguiente evolución Tecnológica.

2004 y siguientes:


Y aquí estamos, inventando de nuevo la rueda y hablando de BPM – Business Process Management ó Gestión de Procesos de Negocio y SOA – Service-Oriented Architecture ó Arquitectura Orientada a Servicios.

Recordemos la introducción:
  • BPM es la metodología empresarial cuyo objetivo es mejorar la eficiencia a través de la gestión sistemática de los procesos de negocio.
  • SOA es un concepto de arquitectura de software que define la utilización de los servicios para dar soporte a los requisitos del negocio.

 Veamos como aterrizamos los CI este discurso a los no CI. Hasta aquí el negocio se había adaptado a las limitaciones que le forzaba la tecnología. Nótese que en los últimos 30 años nuestro discurso había sido que la tecnología ayudaba a gestionar mejor y por tanto hacía prosperar al negocio. Ahora es el negocio quien define las actividades y procesos a través de un modelado, lográndose un mejor entendimiento y la oportunidad de mejorarlos. Claro, antes los requisitos nos los inventábamos los CI en lugar de proporcionarlos el usuario de negocio. La automatización, administración y monitorización de los procesos, reduce errores, asegura una ejecución eficiente y permite explotar la información que de ello se obtiene para optimizarlos.
¿Hasta aquí algo nuevo?.

Evidentemente, para desarrollar una estrategia de BPM es necesario contar con una suite de soluciones y herramientas denominadas BPMS – Business Process Management System ó Sistema de Gestión de Procesos de Negocio -, que nos permitan construir aplicaciones bajo esta metodología. El negocio puede definir paso a paso los procesos utilizando una herramienta WFM – Workflow Management ó Gestión de Procesos – donde bajo un entorno totalmente gráfico y amigable para el usuario, éste define los pasos a seguir o actividades a realizar, los puntos de control, las alertas a emitir, los roles asignados a cada actividad, las personas asociadas a dichos roles y el nivel de escalado de información y autorizaciones correspondiente. Complementado con una herramienta BAM – Business Activity Monitoring ó Monitorización de Actividades de Negocio – podemos medir los tiempos dedicados a cada acción, la carga de trabajo asignada, la eficiencia de los empleados, etc. Por supuesto, una herramienta BAM nos permitirá documentar los procesos para su mejora y así poder definir, seguir y cumplir un SLA – Service Level Agreement ó Acuerdo de Nivel de Servicio; y nos ofrecerá en múltiples formatos de gráficos y agrupaciones de datos, la información relevante para mejorar el negocio. Además, facilitará la visualización de las alertas definidas según grado de criticidad y al nivel de dirección y gestión adecuado. De forma que un usuario de negocio pueda “orquestar” las actividades y “modelar” sus procesos y que ello se traduzca en un software que se ejecute y realice las acciones requeridas, para lo que es preciso una nueva arquitectura que nos permita diseñar estas aplicaciones. Y aquí entra SOA que define las siguientes capas de software o para entendernos, que “trocea” nuestras antiguas aplicaciones en programas o “servicios” cada vez más concretos, limitados y específicos:

  • Básicos: Programas desarrollados bajo cualquier tecnología, geográficamente dispersos y bajo cualquier figura de propiedad. Por ejemplo, validación lógica de una fecha.
  • Funcionales: Las funcionalidades del negocio se exponen como servicios.
  • Integración: Facilitan el intercambio de datos entre aplicativos.
  • Composición de Procesos: Define el proceso en términos de negocio adaptados a sus particularidades.
  • Entrega: Despliegue de los servicios a los usuarios finales.

Y son esos pequeños “servicios” los que se asocian en el workflow y generan una aplicación BPM.



Fuente:

CCB – Octubre 2008
Para MorellConsultor.es

Facebooktwitterlinkedinmailby feather