domingo, 31 de marzo de 2013

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

miércoles, 27 de marzo de 2013

¿Qué es BPEL?


Siempre ha existido una necesidad continua en las empresas para integrar los sistemas y aplicaciones que utilizan los procesos de negocio. Con el surgimiento de la tecnología de servicios web se ha hecho más fácil solucionar este problema con las aplicaciones y sistemas disponibles dentro de la empresa y también haciendo posible la publicación de estas funcionalidades para que puedan ser consumidas por externos. La primera fase de la evolución de los servicios web es establecer las bases para la descripción, publicación y distribución de los servicios web, esto incluye los protocolos de transporte de internet (HTTP, SMTP, HTTPS, ETC), los modelos de datos (basados en XML), el intercambio de mensajes (SOAP), la descripción de las operaciones de servicio y tipos (WSDL) y la publicación y descubrimiento (UDDI).

Ninguna de estas especificaciones de los servicios esenciales web (SOAP, WSDL, UDDI, ETC) se habían diseñado para proporcionar mecanismos por sí mismos para describir cómo los servicios web individuales se pueden conectar para crear soluciones empresariales fiables y seguras con el nivel adecuado de complejidad, es aquí donde se asociaron empresas como IBM, Microsoft, BEA, Oracle; con el objetivo de crear un Lenguaje de Ejecución de Procesos (BPEL).

Se considera que la tecnología de servicios web nos está envolviendo cada vez mas y nos está obligando a conocer la compleja necesidad de los clientes. La habilidad de integrar y ensamblar Servicios Web en estándares basados en procesos de negocios es un importante elemento del servicio orientado a empresas y BPEL integra muy bien los servicios Web.

BPEL son las siglas de  Lenguaje de Ejecución de Procesos de Negocio. Lo podemos definir como un estándar basado en XML diseñado especialmente para la “orquestación” de servicios Web.

El orquestamiento de servicios web es la forma ordenada en el que los servicios web se  ejecutan de tal manera que cumplan con una funcionalidad coherente para el negocio. Esto significa que permite el control centralizado de la invocación de diferentes servicios Web con cierta lógica de negocios, definiéndose cuál, cómo y cuándo se ejecutará un proceso determinado.

Entonces, BPEL es un estándar diseñado para integrar una variedad de aplicaciones y conseguir los objetivos de negocio independiente de las plataformas y tecnologías con mayor escalabilidad y flexibilidad. BPEL se convierte en el pegamento para enlazar los servicios web dentro de soluciones del negocio.

Cuando un proceso de negocio es ejecutado mediante la interacción de servicios Web significa que gracias a BPEL existirá una interfaz única para soportar mensajes XML, independiente de las plataformas asociadas, con lo cual se evita tener que usar múltiples protocolos y formatos e interfaces distintas. Aunque no todas las actividades están actualmente implementadas como servicios Web en las organizaciones, sus efectos a nivel interno son tangibles, puesto que ayudan a simplificar y hacer más veloz la interacción y la ejecución de un proceso de negocio. Un proceso de negocio usando BPEL puede orquestar muchos servicios web y efectivamente crear aplicaciones nuevas y completas, con sus propias interfaces públicas para los usuarios finales.

BPEL provee un motor de orquestación para describir cambios de información interna o externamente. BPEL maneja de manera muy explícita los aspectos funcionales de los Procesos de Negocios utilizando funciones como bucles, tareas humanas, compensaciones, secuencias paralelas, conversaciones o transacciones asíncronas o síncronas, largas unidades de trabajo, etc. BPEL apunta principalmente a los cambios de un proceso de negocio, comunicaciones con servicios de manera asíncrona, envió de mensajes, cambio de mensajes, flujos paralelos de actividades, manipular datos a través de interacciones con otras herramientas, soporta grandes transacciones de negocios y actividades y provee consistentes manejos de excepciones.

Al usar BPEL para definir procesos de negocios muchas compañías se han fortalecido por seleccionar e incorporar lo mejor del mercado para sus procesos ya que obtienen flexibilidad para reemplazar o actualizar ciertos aspectos en el negocio sin impactar a los sistemas que utilizan y que se encuentran trabajando bien. Por nombrar una compañía puede cambiar de proveedor de servicios sin impactar el orden de manejos de sistemas incluso los mismos empleados que participen en procesos importantes.

En la actualidad los servicios Web son un tema especial para el comercio y la integración. Las compras, las solicitudes, los mensajes, etc., solo un conjunto de datos a considerar y que son vía Servicios Web por mencionar algunos.

BPEL está basado en un lenguaje XML que permite a los usuarios a conectarse vía servicios web facilitando la orquestación e interacción.

En términos más técnicos, BPEL es un lenguaje de flujo de procesos, el cual será desarrollado normalmente usando un editor visual para crear un diagrama de flujo. lo anterior incluye esperar por un evento, transformarlo en mensaje, definir la trayectoria y momento en el que proceso se ejecutará, invocar un servicio externo y esperar respuesta, advertir alguna falla y definir un proceso compensatorio si corresponde. El proceso compensatorio es muy importante porque durante un proceso de negocios un servicio externo puede ser llamado y dicho servicio completará y hará los cambios necesarios, en caso de que el estado siguiente del proceso falle, realizándose otras transacciones para solucionar el problema eventual.

A continuación una "orquestación" realizada con la herramienta de BPEL proporcionada por Oracle:



martes, 26 de marzo de 2013

¿Qué hay de nuevo en Oracle Database 12c?


Pluggable Databases: Permitirá contener una colección de esquemas u objetos de esquemas que aparecerán para un cliente en Oracle Net como una base de datos separada, independiente. A la característica Pluggable Databases también se le es referenciada únicamente por las siglas PDB. Un Container Database (CDB), es una base de datos que incluye una o más PDB’s. Es posible sacar un determinado PDB de un CDB y volverlo a incluir dentro de un diferente CDB. 


Resource Manager soportado por PDBs: El Resource Manager es una herramienta que gestiona  recursos, esta herramienta también estará soportada para ser usada  a nivel de CDB  y a nivel de PDB. Se puede crear un plan de recursos para CDB que permitirá asignar recursos al CDB completo y a individuales PDBs. Se podría asignar más recursos a una determinada PDB y menos recursos a las demás PDBs dentro del CDB, o también se podría especificar que todas las PDBs dentro de un CDB poseerán igualdad de recursos.


 Full Transportable export/import: Esta característica permitirá mover bases de datos desde una instancia a otra. Transportando una base de datos es mucho más fácil y rápido que otros métodos, tales como full export/import. Adicionalmente, se puede usar la característica “Full Transportable export/import” para mover una base de datos no-CDB o una base de datos 11.2.0.3 dentro de un PDB que es parte de un CDB.

Nuevos privilegios administrativos para diferentes tareas de administración: Oracle 12c ahora provee privilegios para tareas relacionadas con Oracle Recovery Manager (Oracle RMAN), Oracle Data Guard y Encriptación de datos. Cada nuevo privilegio de administración sede el minimo privilegio requerido para realizar dichas tareas. Estos nuevos privilegios evitan la necesidad de asignar el rol SYSDBA para todos los DBA’s. Más bien cada DBA tendrá una tarea asignada y en base a esa tarea serán sus privilegios. Para las tareas de Backup y recuperación con RMAN está creado el rol backupdba, para las tareas de Data Guard está creado el rol dgdba y para las tareas de encriptación de datos está el rol kmdba, por supuesto aún siguen existiendo los role dba y asmdba.

Database Smart Flash Cache soportado para múltiples dispositivos flash: Una instancia de base de datos puede acceder y combinar múltiples dispositivos flash para crear un Database Smart Flash Cache sin requerir un volumen manager. Está característica fue introducida en 11g, sin embargo, en 11g es necesario un volumen manager y no todos los dispositivos flash son soportados.

Temporary Undo: El Undo generado por los objetos temporales es almacenado en un Tablespace Temporal, ya no más en un Tablespace de tipo Undo. Al usar Undo temporal se reduce la cantidad de Undo almacenado en el tablespace de tipo Undo y el tamaño de los redo log. También facilita la realización de Data Manipulation Languaje (DML) en tablas temporales en una Base de Datos standby de tipo “Physical” creada con Data Guard.

Mejoras en el Database Resident Connection Pool (DRCP): Se puede hacer uso de las características que provee Oracle Advanced Security  con DRCP, incluyendo fuerte autenticación y encripción con la opción de Advanced Security. Las conexiones creadas con  DRCP  soportan varios tipos  de autenticación entre ellos Kerberos y Enterprise User Security.

Mover Datafile online: En oracle 12c es posible mover un datafile a un diferente dispositivo de almacenamiento cuando esta online y siento accedido. Esta capacidad simplifica las operaciones de mantenimiento reduciendo los Downtime.

Múltiples índices en el mismo conjunto de columnas: Esta característica permite crear multiples índices en el mismo conjunto de columnas para realizar migraciones de aplicaciones sin eliminar existentes índices y recrearlos con diferentes atributos.

Mover una partición o subpartición online: Esta característica permitirá que las operaciones DML continúen ejecutándose sin interrupción mientras una partición o subpartición está siendo movida.

Redefinición de tablas con múltiples particiones online: Oracle 12c permitirá minimizar el Downtime cuando se está redefiniendo una tabla con múltiples particiones. Se podrá redefinir dicha tabla con sus particiones en una sesión sencilla y de manera online.

Nuevo parámetro en el procedimiento FINISH_REDEF_TABLE: El parámetro “dml_lock_timeout” está disponible en Oracle Database 12 y permitirá establecer al procedimiento FINISH_REDEF_TABLE un límite de tiempo de espera para que las transacciones pendientes realicen “commit”.

Columnas invisibles: Esta característica permitirá crear columnas individuales de manera invisible. Cualquier acceso genérico hacia una tabla con columnas invisibles, no mostrará dichas columnas, por ejemplo:

SELECT * FROM table
DESCRIBE table

Una consulta genérica a una tabla no mostrará los valores de la columna invisible, a menos que explícitamente se escriba en la sentencia “SELECT” el nombre de la columna. No se podrá insertar un valor en una columna invisible en la sentencia “INSERT”, a menos que explícitamente se escriba el nombre de la columna.

Usted puede hacer uso de Columnas invisibles si se está realizando  cambios en dicha tabla pero no se desea afectar las aplicaciones dependientes.

Sentencia ALTER TABLE ADD COLUMN optimizada: Una columna “nullable” es una columna que ha sido creada sin usar la restricción “NOT NULL”. Para ciertos tipos de tablas, cuando se agregan columnas nullables, dichas columnas poseen un valor por defecto. La base de datos en su versión 12c tiene la capacidad de poder optimizar los recursos y poder almacenar el valor por defecto de dicha columna en la “metadata” de la tabla. Es decir, en lugar de insertar el valor por defecto en cada registro insertado a la tabla, dicho valor es almacenado como “metadata”, de esta manera se evita la inserción del valor en todos los registros de la tabla.

Clonación Copy-on-Write de una Base de Datos: Cuando se está clonando una base de datos, Oracle 12c puede crear los archivos en la nueva base de datos haciendo uso de la tecnología Copy-on-Write, esto permite que únicamente los bloques de datos que están siendo utilizados requieran espacio adicional el ambiente de nuevo. Esto elimina el problema que para cada ambiente de pruebas nuevo se tenga que copiar en cada uno de ellos todos los datafiles del ambiente de producción, redundando espacio.

Log DDL: Cuando se habilita el registro de las sentencias DDL, éstas sentencias son registradas en un archivo log diferente al archivo de alerta de la base de datos (alert log).

Log Debug: Información importante que la instancia provee puede ser usada para poder realizar debug a la base de datos. Esta información es registrada en un archivo de log diferente al archivo de alerta de la base de datos.

Palabras reservadas para la herramienta SRVCTL: Para mejorar la usabilidad, cada opción de SRVCTL es una palabra reservada en lugar de una letra sencilla identificando la opción a usar.

Ahora la sintaxis que espera la herrameinta SRVCTL es:

SRVCTL <comando> <objeto> <opción>

Donde:

Comando: es un verbo tal como “start”, “stop” o “remove”.
Objeto: es un componente en que SRVCTL realizará la operación, tal como base de datos, listener, etc.
Opción: Extiende la operación a realizar especificando adicionales parámetros, por ejemplo “-db”, “-service”.

SRVCTL es sensible a mayúsculas y minúsculas.

Trnasaction Guard and Application Continuity: Si un corte de conexión ocurre entre la aplicación (cliente) y la base de datos (servidor), el cliente en versiones anteriores recibía un mensaje genérico de error el cual prácticamente decía que la comunicación se había perdido. Este mensaje no informa al cliente sobre si la transacción finalizó satisfactoriamente o hubo un fallo en la operación commit.

Transaction Guard usa un nuevo concepto llamado Identificador de transacciones lógicas (LTXID), el cual es un identificador único global. Cuando existe un error recuperable, Transaction Guard usa LTXID para determinar el resultado de la transacción. Este resultado es retornado al cliente en lugar de un mensaje genérico de error. El usuario entonces toma la decisión de volver a ejecutar la operación o no.

Nuevos tipos de Jobs: Varios tipos de jobs han sido agregados los cuales permiten ejecutar personalizados scripts usando sqlplus, o RMAN o una terminal convencional.

¡SOA no es una moda pasajera; está aquí para quedarse!

SOA, una tecnología que está revolucionando los departamentos de Sistemas en los que, según reflejan los analistas, ya existen 1.700 proyectos en producción en todo el mundo y se prevé que en 2010, el gasto en SOA supere los 25.500 millones de dólares, a nivel global.


"El mayor inconveniente que existe actualmente respecto a esta tecnología es que existe un gran desconocimiento de las posibilidades que ofrece. Se trata más que nada de un tema cultural, por lo que los fabricantes debemos actuar como divulgadores de las Arquitecturas Orientadas a Servicios." Víctor Mojarrieta 

"SOA nace con vocación de reutilización y esto aporta flexibilidad. Puedes cambiar piezas sin que el castillo se derrumbe, por lo que hay una minimización del riesgo muy significativa y esto supone siempre una evolución desde el punto de vista tecnológico y de negocio." José Félix Díaz.


Ver el artículo completo en:
Parte 1:
Parte 2:
Parte 3:

¿Qué es SOA?


INTRODUCCION

 La interconectividad entre las empresa Guatemaltecas cada vez se hace más necesaria. Los bancos necesitan comunicarse, intercambiar datos de clientes, datos de cuentas, publicar cambio de monedas, etc. Las Escuelas también necesitan integrarse haciendo el proceso de inscripción o tramitación de documentos más rápidos. Las Empresas gubernamentales poseen también esa necesidad de intercambiar datos, por ejemplo con la SAT (Superintendencia de Administración Tributaria), con bancos, con entidades externas, etc. No cabe duda que esa agilidad e integración será grandemente codiciada por muchas empresas Guatemaltecas y como consecuencia la adopción de SOA proliferará. Sin embargo, la adopción de SOA no es un proyecto de semanas o meses, sino de años. Involucra la creación de varios proyectos, roles y la cooperación entre IT y el área de negocio.

La adopción de SOA trae como beneficio el cambio de paradigma que las grandes industrias de tecnología de la información han adoptado por varios años: Cliente/Servidor. SOA está llamando la atención de varias empresas por la alta agilidad y la reducción de costos que provee mediante servicios fuertemente reutilizables, desacoplados y gobernados con el fin de adaptarse a los cambios exigidos por el entorno en que se encuentran y poder competir fuertemente. Sin embargo, aún en Korea y Europa grandes compañías han fracasado en la adopción trayendo consigo grandes pérdidas económicas con un retorno de inversión nulo. La adopción de SOA está empezando y cada vez más empresas están involucrándose en la adopción de SOA para poder enfrentar los cambios que el mercado exige haciendo uso de agilidad empresarial, pero muchas de estas empresas que han intentado adoptar SOA han fracasado en el intento.

SOA es un concepto relativamente nuevo por lo que cada ves más estándares, roles, herramientas y protocolos están surgiendo y a la vez modificando esta arquitectura, haciendo su adopción difícil.

¿QUE ES SOA?

Antes de nada conviene aclarar qué es realmente SOA, ya que en muchas ocasiones se confunde con una tecnología o producto software, y  nada más lejos de la realidad. Hay decenas de definiciones distintas de SOA en la Web y aunque la mayoría de ellas son acertadas, unas son más completas que otras. Hay que entender que SOA es un concepto de diseño de arquitectura que trata de alinear a las TI con el propio negocio de la organización. Y para esto, sugiere la creación de servicios y funcionalidades de negocio fácilmente reutilizables. Estos servicios deben ser flexibles, seguros y lo más importante de todo, con una arquitectura basada en estándares. SOA intenta integrar las TI con el negocio para que las soluciones que aporte sean lo más cercanas a los requisitos de negocio que se intenten cubrir, y dejen de ser soluciones departamentales que cubran o resuelvan solo parcialmente parte de las necesidades existentes sin tener una visión de la globalidad del proceso.

SOA es la evolución del modelo de programación orientado a componentes, ya que SOA agrega herramientas de computación distribuida a estas tecnologías que hemos venido utilizando por años. Podríamos decir que el cambio más grande es filosófico: en lugar de pensar en el diseño de aplicaciones individuales para resolver problemas específicos, SOA ve el software como un patrón que soporta todo el proceso del negocio. Cada elemento de un servicio es un componente que puede ser utilizado muchas veces a través de muchas funciones y procesos dentro y fuera de la empresa. Los servicios se pueden actualizar y escalar conforme sea requerido, o se pueden cambiar a una librería de terceros, sin afectar la operación del negocio.

Que SOA es una gran idea es indudable y también lo es que la expectativa que ha despertado entre las empresas, los consultores y los medios especializados es enorme, la más grande que ha habido en IT en muchos años. Es natural en cierto modo que sea así porque SOA cumple con un viejo anhelo de IT que es poder crear nuevos sistemas a partir de componentes preexistentes que se reutilizan. En cierto modo esta idea es obvia: todas las industrias hacen esto; cuando una empresa electrónica crea por ejemplo un nuevo equipo de audio, o cuando una automotriz diseña un nuevo modelo de automóvil no diseñan desde cero todos sus componentes; reutilizan muchos componentes y partes de los modelos ya existentes. Sin embargo en IT esto no se pudo lograr hasta ahora debido en gran medida a la falta de estándares universalmente aceptados. Es justamente la existencia de un cuerpo de estándares que todos los proveedores de la industria aceptan lo que permitió el desarrollo de SOA. SOA es entonces una forma de diseñar sistemas en la que las diferentes funciones se implementan en la forma de componentes débilmente acoplados denominados servicios. Los servicios se comportan como cajas negras en el sentido de que su implementación interna queda completamente oculta para quien los consume. Un servicio podría estar implementado en JEE, en .NET, en Cobol/CICS, en SQL, etc., sin que el consumidor ni siquiera se entere. La forma de utilizarlo es completamente independiente de la implementación. Esta idea de aplicaciones como servicios alineadas a los procesos del negocio no es nueva, solamente que en esfuerzos anteriores se requería mucho esfuerzo para integrar las aplicaciones heterogéneas.

SOA es un paradigma cuyo objetivo principal es aportar agilidad a la organización, de tal forma que esta pueda responder más rápidamente ante los cambios del mercado (por ejemplo, para lanzar un nuevo producto antes que los competidores).

Aunque las iniciativas SOA normalmente se abordan desde el punto de vista tecnológico, SOA no es una tecnología, sino un enfoque o manera de hacer las cosas que aporta grandes beneficios al negocio. De forma simplificada, SOA consiste en crear elementos software discretos, modulares y reutilizables llamados servicios.

Los servicios se convierten en recursos, accesibles de una forma estándar desde las aplicaciones y sistemas de la organización. De esta forma, para automatizar un proceso de negocio bastará con llamar a un conjunto de servicios en determinado orden (orquestación).


En muchas ocasiones se confunde con una tecnología o producto software, y

nada más lejos de la realidad. Hay decenas de definiciones distintas de SOA en la Web y aunque la mayoría de ellas son acertadas, unas son más completas que otras.

Hay que entender que SOA es un concepto de diseño de arquitectura que trata de alinear a las TI con el propio negocio de la organización. Y para esto, sugiere la creación de servicios y funcionalidades de negocio fácilmente reutilizables. Estos servicios deben ser flexibles, seguros y lo más importante de todo, con una arquitectura basada en estándares.


En el caso de SOA, los componentes reutilizables a crear son servicios de aplicación con significado propio, flexibles, débilmente acoplados y altamente interoperables sobre estándares tecnológicos abiertos.



En definitiva, SOA, a diferencia de otras soluciones de integración no se limita al uso de una herramienta o "plataforma de herramientas" para integrar aplicaciones, sino que sugiere una arquitectura ágil, escalable y completamente distribuida por toda la organización. En las arquitecturas SOA entre otras muchas funcionalidades,  pero no se reduce a la integración de éstas dentro de una localización concreta, sino que va mas allá, va a los procesos de las organizaciones, a la gobernabilidad, al uso de tecnología estándar, a la integración en entornos distribuidos.




BENEFICIOS SOA PARA IT

  • Mayor interoperabilidad entre las aplicaciones internas existentes, las aplicaciones externas y las futuras aplicaciones.
  • Mayor reutilización de los sistemas de información de la empresa y de sus componentes mediante su conversión a servicios.
  • Menores costos de mantenimiento al evitar que las capacidades de negocio (componentes de software) que sean duplicadas o se superpongan se consoliden en una pequeña cantidad de servicios compartidos.
  • Reutilización, el código se implementa una sola vez y puede ser invocado desde aplicaciones distintas.
  • Homologación, al reutilizar un servicio se homologan funciones que son soportadas por el mismo servicio, proporcionando ya sea una misma lógica de negocio o interfaz.
  • Administración, tener identificados los servicios ayuda a mantener un inventario de los mismos, permitiendo una identificación rápida de aquéllos que son necesarios para implementar una función o proceso de negocio específico.
  • La simplificación del desarrollo de soluciones mediante la utilización de estándares de la industria y capacidades comunes de industrialización.
  • Alinear y acercar las áreas de tecnología y negocio.
  • Reducir los costos y el tiempo de desarrollo—Los servicios SOA pueden reutilizarse fácilmente y pueden convertirse en nuevas aplicaciones compuestas
  • Reducir los costos de mantenimiento, los servicios reutilizables reducen el grado de complejidad interna de los servicios de IT
  • Aumentar la calidad de los servicios, una mayor reutilización de servicios crea servicios de mejor calidad en múltiples ciclos de prueba de diferentes consumidores de servicios
  • Reducir los costos de integración, los servicios estandarizados pueden trabajar en conjunto, permitiendo que las aplicaciones dispares se conecten con rapidez y facilidad
  • Reducir el riesgo, menos servicios reutilizables brindan mayor control sobre las políticas gubernamentales de IT y corporativas, y reducen el riesgo general relacionado con el cumplimiento.
  • menor coste total de propiedad
  • Repotenciación de los sistemas legados.
  • Conectividad, los sistemas son más fáciles de conectar entre sí.
  • Reducción de tamaño de proyectos
  • Alta escalabilidad, los servicios pueden ser clusterizados o movidos entre servidores más rápidamente.
  • Reutilización real de los programas y mejora en tiempos de respuesta al negocio o “time to market”.
  • Minimiza la dependencia técnica
  • Facilita la tercerización de proyectos, los proveedores se adaptarán más rápidamente a los proyectos de la organización.
  • Permite altos niveles de crecimiento a costos más bajos y los usuarios, realmente, pueden hacerse cargo de las definiciones de los procesos que lideran.
  • Es posible exponer cualquier fuente de datos existente como.
  • El manejo del conocimiento atomizado y la encapsulación de éste en servicios permiten una mantención y un dinamismo únicos, mejorando el time to market.
  • Es posible atomizar la lógica y exponerla para que sea utilizada por otras aplicaciones en prácticamente cualquier plataforma tecnológica o ubicación geográfica.
  • Capacidad de Descubrimiento. Los servicios pueden exponer descripciones que permiten a otras aplicaciones y servicios localizarlos y determinar de forma automática la interfaz.

BENEFICIOS SOA PARA EL NEGOCIO

  • Procesos comerciales más ágiles que permiten la implementación en menor tiempo de los cambios requeridos en los procesos de negocio de la empresa.
  • Mejor visibilidad del negocio al exponer como servicios las capacidades comerciales de la empresa para su integración y optimización en los procesos comerciales y en los portales de información que apoyan la toma de decisiones. 
  • EL TCO final de soluciones implementadas bajo esta plataforma, en el mediano y largo plazo, es drásticamente más bajo que el de una solución tradicional.
  • Documentación, el usuario de negocio documenta tanto sus procesos como sus reglas de negocio.
  • Se genera un inventario de procesos de negocio junto con las relaciones que tienen con las reglas de negocio y a los servicios de las aplicaciones que ayudan a su implementación.
  • Al contar con un inventario es posible hacer una mejor planeación arquitectónica, al poder analizar el impacto que tendrán futuras integraciones de nuevas aplicaciones o nuevos procesos de negocio.
  • Información en tiempo real, al contar con monitoreo de los KPIs se genera información bajo demanda que puede ser utilizada para la toma de decisiones relacionadas con los procesos.
  • Agilidad para habilitar rápidamente soluciones innovadoras y para adaptarse a cambios en el mercado cuando ocurran.
  • Flexibilidad para reducir los tiempos y costos de implantación, y para contar con una arquitectura ágil que permita la evolución, cambio y crecimiento del negocio.
  • Rapidez para llegar primero al mercado antes que la competencia y crecer la participación de mercado.
  • Obtener mejor visibilidad de la información a través de toda su organización.
  • Optimice sus procesos de negocios.
  • Tasas internas del retorno sobre la inversión de hasta el 100%.
  • Ahorro en TCO (Total Cost of Ownership) de los componentes de software y de las aplicaciones construidas utilizando estos componentes.
  • Capacidad de reutilizar y potenciar otras aplicaciones informáticas como ERP's, CRM's, etc.
  • Mejora en los tiempos de realización de cambios en procesos.
  • Facilidad para evolucionar a modelos de negocios basados en tercerización.
  • Facilidad para abordar modelos de negocios basados en colaboración con otros entes (socios, proveedores).
  • Poder para reemplazar elementos de la capa aplicativa SOA sin disrupción en el proceso de negocio.
  • Facilidad para la integración de tecnologías disímiles.
  • Agilidad para habilitar rápidamente soluciones innovadoras y para adaptarse a cambios en el mercado cuando ocurran.
  • Aislar los sistemas frente a cambios generados por otras partes de la organización (protección de las inversiones realizadas).



lunes, 25 de marzo de 2013

Preguntas por Dimensión para SIMM


En uno de los artículos anteriores (SIMM) se examinó la matriz de madurez para SOA SIMM. Modelo que fue creado por Ali Arsanjani y Kerrie Holley el 20 de septiembre del 2005 en IBM donde expertos de IBM publicaron tutoriales, código de ejemplo, estándares y otros recursos para ayudar a desarrolladores de software.

El modelo SIMM consta de dimensiones y niveles de madurez. En este nuevo artículo publico algunas preguntas generales que deben ser contestadas en cada una de las dimensiones de SIMM.


Negocio:

  1. ¿Cuáles son los mejores procesos de negocio para la iniciativa SOA?
  2. ¿Cuál es la visión y los objetivos, y cómo están relacionados a lo que IT está actualmente haciendo?
  3. ¿Está documentada, definida y gobernada la actual arquitectura de negocio?
  4. ¿Es su arquitectura de negocio completa y moderna?
  5. ¿Cómo se mide el retorno de la inversión?
  6. ¿Qué tan agiles son los procesos de negocio?
  7. ¿Cuáles son las actuales prácticas de financiamiento?
  8. ¿Cuál es el actual costo modelo?
  9. ¿Quiénes son los dueños del portafolio de procesos, aplicaciones y servicios?
  10. ¿Existe un modelo de costo por el uso que los clientes hacen a los servicios?
  11. ¿Como hace actualmente para definir el costo total de arrendamiento (incluido software, hardware y futuros mantenimientos)?
  12. ¿Cómo son medidos los actuales servicios de negocios?
  13. ¿Cuál es la actual práctica para transformar SLAs de negocio hacia SLAs de IT?
  14. ¿Esta formalizada la arquitectura empresarial?
  15. ¿Esta formalizado el gobierno de su arquitectura empresarial?
  16. ¿Existen múltiples líneas de negocio? ¿Cada una de esas líneas tiene sus propios procesos?
  17. ¿Se comparte información entre los procesos de sus diferentes líneas de negocio?
  18. ¿Comparte servicios de las líneas de negocio con clientes, proveedores y socios?

Organización:

  1. ¿Qué tipo de características son comunes en el grupo de IT?
  2. ¿Cómo gobierna actualmente IT la arquitectura empresarial?
  3. ¿Qué tan alineado esta IT con el negocio?
  4. ¿Existen procesos para gobernar la arquitectura, están esos procesos documentados, si es así, son esos procesos usados como servicios?
  5. ¿Existen roles y responsables relacionados a la ejecución de los procesos de negocio?
  6. ¿Cuáles son las funciones y responsabilidades para quien gobierna?
  7. ¿Cómo se debería describir el costo de mantenimiento de  IT?
  8. ¿Qué tipo de entrenamiento SOA está disponible en la organización?
  9. ¿Qué tipo de relación existe entre el grupo de desarrolladores de la organización y el grupo de infraestructura?
  10. ¿Qué autoridades existen para gobernar la arquitectura?
  11. ¿Se ha solucionado los problemas de comunicación entre los departamentos internos, socios y proveedores?

Métodos y Procesos: 

  1. ¿Cuáles son las actuales practicas para manejar los requerimientos de sistemas o requerimientos de aplicaciones?
  2. ¿Qué metodologías de diseño y mejores practicas están actualmente adoptadas?
  3. ¿Se practica alguna técnica de diseño SOA?
  4. ¿Cuáles son las practicas actuales para diseñar y manejar servicios?
  5. ¿Cuál es el actual Framework para manejo de proyectos?
  6. ¿Cómo están organizadas las personas que manejan los Proyectos de IT?
  7. ¿Qué procesos de aseguramiento de la calidad tiene la organización?
  8. ¿Existe un grupo activo que trabaja por mejorar los procesos y prácticas de SOA?
  9. ¿Tiene la organización desarrollado un repositorio para mejores prácticas y reutilización de recursos?
  
Aplicación:

  1. ¿Cuál es el actual estilo de desarrollo de aplicaciones?
  2. ¿Cómo se reúsa los recursos o funciones comunes?
  3. ¿Qué tipo de reutilización se realiza y cómo se mide la reutilización?
  4. ¿Cómo se integran las aplicaciones y sistemas?
  5. ¿Qué tipo de lenguajes de programación se utilizan?
  6. ¿Qué tipo de tecnologías de integración se utilizan?
  7. ¿Cómo está representada la lógica de negocio dentro de las aplicaciones?
  8. ¿Qué tan seguras son las aplicaciones más importantes de la organización?
  9. ¿Que tanto se usa XML?
  10. ¿Cuál es la taza de cambios y requerimientos en las aplicaciones?
  11. ¿Se están usando las tecnologías habilitadas por SOA, tales como ESB, compartimiento de datos, registro de servicios?

Arquitectura: 

  1. ¿Cómo caracterizaría la actual arquitectura?
  2. ¿Qué tipos de repositorios de datos utiliza la organización?
  3. ¿Cuál es el estilo de comunicación estándar dentro de la arquitectura?
  4. ¿Cómo se está cumpliendo con la integración en la actual arquitectura?
  5. ¿Qué métodos se utilizan para desarrollar bajo la actual arquitectura?
  6. ¿Cómo maduran las implementaciones de servicios?
  7. ¿Qué tan extensa es la arquitectura actual?
  8. ¿Qué principios de arquitectura definen su actual enfoque?
  9. ¿Qué tan extensa y sofisticada esta el uso de Frameworks en la actual arquitectura?
  10. ¿Cómo se realizan las decisiones de arquitectura?
  11. ¿Hace uso la organización de referencias de arquitecturas?
  
Información:

  1. ¿Hay un modelo de datos común entre todas las aplicaciones?
  2. ¿Hay modelos de datos independientes para diferentes aplicaciones?
  3. ¿Se utilizan reglas de mapeo para conversiones entre diferentes modelos de datos?
  4. ¿Hay dificultad en mover datos entre una aplicaciones y otra? ¿Para todas las aplicaciones?¿Para solamente algunas aplicaciones?
  5. ¿Cómo se intercambian los datos? ¿A través de API's? ¿Por XSD? ¿Por documentos escritos? ¿Por herramientas externas?
  6. ¿Están los modelos de datos en forma de Modelos de Objetos de Negocio, comprensibles para el negocio, o como modelo de objetos de IT, comprensible únicamente por el grupo de IT?
  7. ¿Los modelos de datos están definidos por un lenguaje que incluye taxonomías, ontologías u otra representación de alto nivel?
  8. ¿Se mantiene un directorio global o base de datos de objetos, con identificadores globales? ¿O se tienen mecanismos para mapear esos objetos entre diferentes directorios o bases de datos? Son estos mecanismos electrónicos o manuales?  Son todos los objetos mapeados o solamente algunos de ciertas aplicaciones?
  9. ¿Se tienen mecanismos para buscar objetos globalmente buscándolos por sus características?
  10. ¿Cómo se completa la transformación de los datos entre las aplicaciones? Se está usando un ESB para realizar la transformación, utilizando API's o llamando a un webservice?
  11. ¿Existe o está en desarrollo un Modelo de Información de Negocio para estandarizar datos, formatos de mensajes y conceptos entre todas las aplicaciones?
  
 Infraestructura:

  1. ¿Qué directrices está usando actualmente la infraestructura?
  2. ¿Cómo son derivados los SLA's de IT desde los SLA's del negocio?
  3. ¿Cómo se está monitoreando y midiendo la calidad de los servicios?
  4. ¿Se tienen SLA's sobre seguridad y privacidad? Como se está monitoreando y midiendo?
  5. ¿Qué nivel de monitoreo se tiene actualmente? Que herramienta de gestión están utilizándose actualmente?
  6. ¿Qué plataformas están actualmente en uso y que puedan ser integradas?
  7. ¿Qué recursos están situados bajo versionamiento?
  8. ¿Qué procesos de gestión de cambios se están utilizando?
  9. ¿Qué herramientas se están usando para gestión de la configuración?
  10. ¿Qué recursos son considerados como bienes de la organización?
  11. ¿Cómo es su actual arquitectura operacional?
  12. ¿Cómo soporta la arquitectura operacional los requerimientos no funcionales para aplicaciones y servicios?

Oracle ACE Director Award - Deiby Gómez

Thanks #OracleACE Program for this awesome certificate recognizing the work I have done in the community for the last year. Looking forwa...