28
Mar

¿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:


Facebooktwitterlinkedinmailby feather
26
Mar

¿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
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.
Facebooktwitterlinkedinmailby feather
26
Mar

¡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:
Facebooktwitterlinkedinmailby feather
26
Mar

¿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).

Facebooktwitterlinkedinmailby feather
26
Mar

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?
Facebooktwitterlinkedinmailby feather
24
Mar

Primer Simposio Nacional de Oracle Exitoso

El 15 de marzo del presente año se llevó a cabo el Primer Simposio Nacional de Oracle en las instalaciones de la Universidad Internaciones, dicho evento contó con conferencistas de talla nacional e internacional, variedad de temas y una audiencia muy heterogénea que va desde estudiantes hasta personas técnicas y de negocio. 

A continuación los participantes de uno de los dos salones:

 
 
El evento se llevó a cabo con mucho éxito, la empresa Sequal Solutions donó 3 medias becas las cuales se rifaron entre todos los participantes del simposio. A continuación la carta en la cual se donan estas becas.
Contamos con invitados especiales como Everest Medinilla y Rafael Cordón de Datum, Oscar García Colom de Xerox y Guillermo de León de CONCYT.
 
 
 
 
Tanto Anibal García, como yo, estamos muy satisfechos con éste evento y esperamos con muchas ansias el Segundo Simposio Nacional de Oracle, el cual lo programaremos para el próximo año, esperando contar con conferencistas invitados de Argentina y Venezuela.
 
 
 
 
 
Las fotos del evento están publicadas en el siguiente link:

https://www.dropbox.com/sh/ff6bqm2k7cgepmc/HR07I_qn8P

 
Las Presentaciones del evento están publicadas en el siguiente link (lamentablemente algunas presentaciones no fueron autorizadas para compartirlas):

https://www.dropbox.com/sh/7f4sy97mtgy5t4g/VjHJ3XDVNj

 
Agradezco mucho a todas aquellas personas y/o empresas que hicieron posible este Simposio, como SISSA S.A., SISOFT, Universidad InterNaciones y Sequal Solutions; los conferencistas: Augusto López, Ronald Vargas, Fabriccio Diaz, Julio Mendez, Juan René Simon, Joel Perez, Daniel Cacia.

 

894741_555990221089079_1799671817_o 892307_555990041089097_626146912_o881975_553980884623346_1472272762_o

 

 
¡Hasta el próximo año!
Facebooktwitterlinkedinmailby feather
8
Mar

Conferencia SOA en Escuela de Postgrado USAC

El día sabado 16 de febrero tuve la oportunidad de poder impartir la conferencia “Service-Oriented Architecture SOA” en las instalaciones de la Escuela de Postgrado de la Universidad de San Carlos de Guatemala, los temas tratados fueron los siguientes:



Agradezco mucho la invitación del Ing. Luis Fernando Alonzo, instructor del curso “innovacion de tecnologias de informacion” en dicha Escuela de Postgrado.

A continuación algunas fotos del progreso de la conferencia:




Agradezco también a la Escuela de Postgrado por el reconocimiento que me dieron por mi participación:



Facebooktwitterlinkedinmailby feather
8
Mar

Verificar datafiles corruptos

Estimados tecnólogos Oracle reciban un cordial saludo nuevamente desde Guatemala, como ustedes saben, un DBA se enfrenta diariamente a diferentes problemas con las bases de datos que administra, problemas de performance, de IO, de red, storage, CPU, etc., para poder encontrar  la solución a estos problemas, el DBA debe ir delimitando la causa, y es por eso que en esta ocasión veremos una manera fácil de verificar si una base de datos posee corrupciones.

Oracle provee desde la versión 7.3.2, una herramienta llamada DBVERIFY la cual es usada para lo siguiente:


  • Validar corrupciones en  la cabecera de un datafile
  • Cada Bloque de dato dentro de un Datafile tiene un “wrapper” en el cual se encuentra metadata de  dicho bloque, este wrapper también es validado en busca de corrupciones.
  • Validar Consistencia en tablas e índices dentro de los datafiles.
  • Desde la versión 8.1.6 también se validan todos los demás tipos de bloques, por ejemplo  bloques de segmentos rollback.

Una de las ventajas de esta herramientas es que puede ser ejecutada cuando la base de datos está abierta, esto en ambiente de producción es muy importante pues se evita downtime.

La herramienta es muy sencilla de utilizar y provee los siguientes parámetros de entrada:

FILE:               nombre del datafile que se verificará.

START:           Bloque inicial

END:               Bloque Final

BLOCKSIZE: Tamaño del Bloque

LOGFILE:       Una archivo de log en el que se escribirá el feedback de la operación.

FEEDBACK:   Muestra detalladamente el avance del proceso.

PARFILE:        Archivo de parámetro

USERID:         Usuario/Constraseña

Entre las limitantes que tiene esta herramienta  están las siguientes:

  • No valida errores entre tablas e sus indices.
  • Solo puede ser utilizada con datafiles, no redologs, ni controlfiles.
  • dbverify puede ser usada para bases de datos en ASM, sin embargo, la base de datos debe estar abierta y el parámetro USERID debe necesariamente ser especificado.
  • Los datafiles necesitan tener una extensión.
  • No se pueden validar datafiles mayores a 2GB  en 8.1.6 por los bugs: 710888 y 1372172.

El uso de la herramienta es muy fácil, a continuación describo la manera de validar una base de datos completa:

Primero obtenemos el tamaño del bloque que se está utilizando en la base de datos mediante la siguiente consulta:

SQL> SELECT value  FROM v$parameter WHERE name = ‘db_block_size’;

VALUE

—————————————————————–

8192

Ahora continuamos realizando un script con las sentencias necesarias para validar todos nuestros datafiles:

SET ECHO OFF

set heading off

set feedback off

spool validardb.sql

select ‘dbv file=’ ||file_name|| ‘ logfile=archivo_’||rownum||’.log  blocksize=8192′ from dba_data_files;

spool off

exit

Verificamos que el archivo haya sido generado correctamente:

[oracle@soa1 ~]$ ls -ltr

-rw-r–r– 1 oracle oinstall      5092 Mar  8 01:25 validardb.sql

El archivo debería quedar de la siguiente manera:



Le damos permisos de ejecución al script creado:

[oracle@soa1 ~]$ chmod 777 validardb.sql

Ejecutamos el script:

[oracle@soa1 ~]$ ./validardb.sql

DBVERIFY: Release 11.2.0.1.0 – Production on Fri Mar 8 02:33:01 2013

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

Verificamos la salida del archivo:

[oracle@soa1 ~]$ ls -ltr

-rwxrwxrwx 1 oracle oinstall      1718 Mar  8 02:32 validardb.sql

-rw-r–r– 1 oracle oinstall       729 Mar  8 02:33 archivo_2.log

-rw-r–r– 1 oracle oinstall       726 Mar  8 02:33 archivo_1.log

-rw-r–r– 1 oracle oinstall       809 Mar  8 02:33 archivo_3.log

-rw-r–r– 1 oracle oinstall       739 Mar  8 02:33 archivo_4.log

-rw-r–r– 1 oracle oinstall       736 Mar  8 02:33 archivo_5.log

-rw-r–r– 1 oracle oinstall       738 Mar  8 02:33 archivo_6.log

-rw-r–r– 1 oracle oinstall       734 Mar  8 02:33 archivo_7.log

-rw-r–r– 1 oracle oinstall       740 Mar  8 02:33 archivo_8.log

-rw-r–r– 1 oracle oinstall       735 Mar  8 02:33 archivo_9.log

-rw-r–r– 1 oracle oinstall       729 Mar  8 02:33 archivo_10.log

-rw-r–r– 1 oracle oinstall       733 Mar  8 02:33 archivo_11.log

-rw-r–r– 1 oracle oinstall       726 Mar  8 02:33 archivo_12.log

-rw-r–r– 1 oracle oinstall       732 Mar  8 02:33 archivo_13.log

-rw-r–r– 1 oracle oinstall       728 Mar  8 02:33 archivo_14.log

-rw-r–r– 1 oracle oinstall       738 Mar  8 02:33 archivo_17.log

-rw-r–r– 1 oracle oinstall       729 Mar  8 02:33 archivo_16.log

-rw-r–r– 1 oracle oinstall       732 Mar  8 02:33 archivo_15.log

Escaneamos los archivos con extensión .log en busca de corrupción:

[oracle@soa1 ~]$ grep Failing  archivo*.log

[oracle@soa1 ~]$ grep Corrupt archivo*.log

[oracle@soa1 ~]$ grep Influx archivo*.log

La salida sería parecida a lo siguiente, en mi caso, la base de datos que estoy usando para realizar este articulo no contiene corrupciones:

[oracle@soa1 ~]$ grep Failing  archivo*.log

archivo_10.log:Total Pages Failing   (Data) : 0

archivo_10.log:Total Pages Failing   (Index): 0

archivo_10.log:Total Pages Failing   (Seg)  : 0

archivo_11.log:Total Pages Failing   (Data) : 0

archivo_11.log:Total Pages Failing   (Index): 0

archivo_11.log:Total Pages Failing   (Seg)  : 0

archivo_12.log:Total Pages Failing   (Data) : 0

archivo_12.log:Total Pages Failing   (Index): 0

archivo_12.log:Total Pages Failing   (Seg)  : 0

archivo_13.log:Total Pages Failing   (Data) : 0

archivo_13.log:Total Pages Failing   (Index): 0

archivo_13.log:Total Pages Failing   (Seg)  : 0

archivo_14.log:Total Pages Failing   (Data) : 0

archivo_14.log:Total Pages Failing   (Index): 0

archivo_14.log:Total Pages Failing   (Seg)  : 0

archivo_15.log:Total Pages Failing   (Data) : 0

archivo_15.log:Total Pages Failing   (Index): 0

archivo_15.log:Total Pages Failing   (Seg)  : 0

archivo_16.log:Total Pages Failing   (Data) : 0

archivo_16.log:Total Pages Failing   (Index): 0

archivo_16.log:Total Pages Failing   (Seg)  : 0

archivo_17.log:Total Pages Failing   (Data) : 0

archivo_17.log:Total Pages Failing   (Index): 0

archivo_17.log:Total Pages Failing   (Seg)  : 0

archivo_1.log:Total Pages Failing   (Data) : 0

archivo_1.log:Total Pages Failing   (Index): 0

archivo_1.log:Total Pages Failing   (Seg)  : 0

archivo_2.log:Total Pages Failing   (Data) : 0

archivo_2.log:Total Pages Failing   (Index): 0

archivo_2.log:Total Pages Failing   (Seg)  : 0

archivo_3.log:Total Pages Failing   (Data) : 0

archivo_3.log:Total Pages Failing   (Index): 0

archivo_3.log:Total Pages Failing   (Lob)  : 0

archivo_3.log:Total Pages Failing   (Seg)  : 0

archivo_4.log:Total Pages Failing   (Data) : 0

archivo_4.log:Total Pages Failing   (Index): 0

archivo_4.log:Total Pages Failing   (Seg)  : 0

archivo_5.log:Total Pages Failing   (Data) : 0

archivo_5.log:Total Pages Failing   (Index): 0

archivo_5.log:Total Pages Failing   (Seg)  : 0

archivo_6.log:Total Pages Failing   (Data) : 0

archivo_6.log:Total Pages Failing   (Index): 0

archivo_6.log:Total Pages Failing   (Seg)  : 0

archivo_7.log:Total Pages Failing   (Data) : 0

archivo_7.log:Total Pages Failing   (Index): 0

archivo_7.log:Total Pages Failing   (Seg)  : 0

archivo_8.log:Total Pages Failing   (Data) : 0

archivo_8.log:Total Pages Failing   (Index): 0

archivo_8.log:Total Pages Failing   (Seg)  : 0

archivo_9.log:Total Pages Failing   (Data) : 0

archivo_9.log:Total Pages Failing   (Index): 0

archivo_9.log:Total Pages Failing   (Seg)  : 0

[oracle@soa1 ~]$ grep Corrupt archivo*.log

archivo_10.log:Total Pages Marked Corrupt   : 0

archivo_11.log:Total Pages Marked Corrupt   : 0

archivo_12.log:Total Pages Marked Corrupt   : 0

archivo_13.log:Total Pages Marked Corrupt   : 0

archivo_14.log:Total Pages Marked Corrupt   : 0

archivo_15.log:Total Pages Marked Corrupt   : 0

archivo_16.log:Total Pages Marked Corrupt   : 0

archivo_17.log:Total Pages Marked Corrupt   : 0

archivo_1.log:Total Pages Marked Corrupt   : 0

archivo_2.log:Total Pages Marked Corrupt   : 0

archivo_3.log:Total Pages Marked Corrupt   : 0

archivo_4.log:Total Pages Marked Corrupt   : 0

archivo_5.log:Total Pages Marked Corrupt   : 0

archivo_6.log:Total Pages Marked Corrupt   : 0

archivo_7.log:Total Pages Marked Corrupt   : 0

archivo_8.log:Total Pages Marked Corrupt   : 0

archivo_9.log:Total Pages Marked Corrupt   : 0

[oracle@soa1 ~]$ grep Influx archivo*.log

archivo_10.log:Total Pages Influx           : 0

archivo_11.log:Total Pages Influx           : 0

archivo_12.log:Total Pages Influx           : 0

archivo_13.log:Total Pages Influx           : 0

archivo_14.log:Total Pages Influx           : 0

archivo_15.log:Total Pages Influx           : 0

archivo_16.log:Total Pages Influx           : 0

archivo_17.log:Total Pages Influx           : 0

archivo_1.log:Total Pages Influx           : 0

archivo_2.log:Total Pages Influx           : 0

archivo_3.log:Total Pages Influx           : 0

archivo_4.log:Total Pages Influx           : 0

archivo_5.log:Total Pages Influx           : 0

archivo_6.log:Total Pages Influx           : 0

archivo_7.log:Total Pages Influx           : 0

archivo_8.log:Total Pages Influx           : 0

archivo_9.log:Total Pages Influx           : 0

Facebooktwitterlinkedinmailby feather