Archive

Archive for the ‘Metodología’ Category

Oracle MAA – Arquitecturas de referencia

diciembre 17, 2015 Deja un comentario

Oracle MAA best practices definen cuatro arquitecturas de referencia de alta disponibilidad que se ocupan de la gama completa de la disponibilidad y protección de datos requeridos por las empresas de todos los tamaños y líneas de negocio. Las arquitecturas o niveles se designan como Platino, Oro, Plata y Bronce.

MAA01

BRONZE

El nivel Bronze es el más indicado para las bases de datos donde un simple reinicio o restaurar la copia de seguridad es “HA enough”.

El nivel Bronze se basa en una sola instancia de base de datos Oracle con las MAA best practices, que utilizan muchas capacidades de protección de datos y alta disponibilidad que se incluye con cada licencia Oracle Enterprise Edition.

El Backup utilizando Oracle Recovery Manager (RMAN) proporciona protección de los datos y se utiliza para restaurar las bases de datos. La política de retención para los Backup’s vendrá dada por el RTO que tengamos. En los entornos productivos la necesidad de archivelog es imprescindible.

SILVER

El nivel Silver proporciona un nivel adicional de alta disponibilidad para las bases de datos que requieren unos tiempos mínimos, o cero, de inactividad en caso de problemas con la instancia de base de datos o fallo en el servidor, así como muchas tareas de mantenimiento planificado. El nivel de Silver agrega tecnología de Clustering, ya sea Oracle RAC u Oracle RAC One Node.

A este escenario le sumaríamos los pertinentes Backup’s con RMAN.

Estos Backup’s los podremos ir optimizando conforme a la arquitectura Silver que tengamos. Es decir: si se trata de un Cluster de base de datos, y manejamos grandes volúmenes Very Large Database (VLDB), la mejor solución para reducir la ventana será paralelizar el Backup, lanzándolo desde todos los nodos; a esta opción de Backup le podemos añadir compresión, dado que esta opción no requiere licenciamiento adicional.

Este es un ejemplo de cómo alocar canales en varios nodos de un RAC:

ALLOCATE CHANNEL ch00 TYPE ‘SBT_TAPE’ PARMS=”ENV=(NB_ORA_CLIENT=srvcrmp01-vip)” CONNECT=’sys/password@CRM1′;
ALLOCATE CHANNEL ch01 TYPE ‘SBT_TAPE’ PARMS=”ENV=(NB_ORA_CLIENT=srvcrmp02-vip)” CONNECT=’sys/password@CRM2′;

GOLD

El nivel Gold aumenta las expectativas, sustancialmente, para aplicaciones críticas de negocio que no pueden aceptar la vulnerabilidad a los puntos de fallo individuales. Este nivel añade tecnologías de replicación de bases de datos Oracle. En esta arquitectura se puede incluir, además: Oracle Active Data Guard, para poder descargar de trabajo la base de datos primaria (necesita un licenciamiento adicional y también está incluida en la licencia de GoldenGate) y Oracle GoldenGate, que sincroniza una o varias réplicas de la base de datos de producción, para proporcionar una protección de datos en tiempo real y disponibilidad. La replicación de bases de datos aware mejora sustancialmente la alta disponibilidad y protección de datos,  más allá de lo que es posible con las tecnologías de replicación de almacenamiento.

PLATINUM

El nivel Platinum introduce varias nuevas capacidades de Oracle Database 12c y muchas características que se han mejorado con la última versión. Estas capacidades incluyen: Application Continuity y Active Data Guard Far Sync para la protección con cero pérdida de datos a cualquier distancia, mejoras en Oracle GoldenGate para zero downtime ante actualizaciones y migraciones, y Global Data Services para la gestión automática del workload balancing en entornos de bases de datos replicadas. Cada una de estas tecnologías requiere un esfuerzo adicional para ponerlas en práctica, pero entregan un valor sustancial para las aplicaciones más críticas, en las que el tiempo de inactividad y la pérdida de los datos no son una opción.

En la Siguiente tabla podemos ver un resumen de los distintos niveles de protección y perdida de datos:

Table01

 

Para mas información sobre Oracle MAA os dejo este enlace a otro post muy interesante:

Consideraciones generales sobre recursividad

noviembre 22, 2010 1 comentario

La utilización de técnicas de recursividad dentro de la programación en cualquier tipo de lenguaje (en este caso PL/SQL) dota al código de un gran nivel de ‘factores de calidad’ (calidad + simplicidad + potenciabilidad). Características que conjuntamente con las de elegancia y sencillez dotan a esta técnica como de uso muy recomendable.

Unos de los casos más representativos de la aplicación de esta técnica, por su propia definición, es la del cálculo matemático del ‘factorial’ de un número:

n! = n * (n-1) * (n-2) * (n-3) * … * 1

Indicar como excepción a la recursividad tradicional, situaciones en las que la información susceptible de tratamiento está ubicada en la Base de Datos en un modelo de ‘Estructura Jerárquica‘. Esta puede ser tratada por ‘SQL‘ mediante consultas ‘jerárquicamente relacionales‘ (‘CONNECT BY PRIOR …‘). A esta excepción se le denomina ‘recursividad por estructura en relación reflexiva‘  (ver más detalladamente a continuación).

Leer más…

Categorías:Metodología Etiquetas: , , ,

¿Dónde está ubicada la lógica de negocio de tu aplicación? (2) – Caso práctico de desacoplamiento

En uno de nuestros clientes se me planteó como objetivo de un proyecto independizar la capa de negocio de la capa de presentación, desacoplándola totalmente para que pudiera ser reutilizada desde cualquier entorno gráfico y dispositivo móvil, en una posible evolución a orientación a servicios (SOA).

Lo primero que revisé fue la estructura interna de la aplicación para determinar qué cambios se debían realizar para dejarla lo más reutilizable posible. Después tocó evaluar en tiempo, coste y recursos esos cambios, tratándolos como si fuesen un proyecto más. Aquí pensé en los responsables y en cómo iban a enfocarlos de cara a obtener la aprobación desde arriba ya que este tipo de proyectos son difíciles de justificar delante de los gestores, pues consumen recursos, cuestan dinero y no aportan ninguna nueva funcionalidad. Pero este coste se debe conocer pues con él pueden decidir si la opción de adaptar para el cambio resulta más barata o más cara que empezar todo de nuevo, en cuyo caso también se debe valorar lo que representa la pérdida de toda la inversión y trabajo efectuado hasta el momento.

Leer más…

¿Dónde está ubicada la lógica de negocio de tu aplicación? (1) – Teoría

septiembre 9, 2010 Deja un comentario

Este post es como consecuencia de la realización de un proyecto en el cliente donde me encuentro. El objetivo del proyecto ha sido:

Independizar la capa de negocio de la capa de presentación, desacoplarla totalmente para que pueda ser reutilizada desde cualquier entorno gráfico, dispositivo móvil, en una posible evolución a orientación a servicios (SOA), etc.

El proyecto ha sido una labor de investigación y práctica continua. Se basa en la aplicación de las más actuales metodologías de desarrollo de software y en las buenas prácticas documentadas.

Como la documentación acumulada es mucha he decidido separar la parte teórica de la parte práctica. Así, este post es un resumen organizado de toda la teoría que he recopilado y que me ha servido de guía y el siguiente es un relato de la experiencia de ponerla en práctica de forma satisfactoria, un caso de éxito. Espero que os pueda ayudar o por lo menos guiar si debéis seguir este camino o uno parecido. De hecho la raíz de todas estas buenas prácticas se basan en la experiencia y el conocimiento de muchos como nosotros que nos hemos encontrado ante problemas o situaciones similares y que necesitábamos de una solución lo más efectiva y eficiente posible.

Si ya estás instruido en estas técnicas te invito a pasar directamente al segundo post: ¿Dónde está ubicada la lógica de negocio de tu aplicación? (2) – Caso práctico de desacoplamiento.

ÍNDEX.

1. ¿Dónde está la lógica de tu negocio?.

2. Organizar Lógica de negocio. Diseño Procedimental vs Orientación a Objetos.

3. Metodologías Ágiles de desarrollo de software.

3.1 Introducción a las Metodologías Ágiles.

3.2 Programación Extrema. Programación en pareja.

3.3 Patrones de diseño, Antipatrones y Refactorización.

3.4 Refactorizar. Refactorización.

Leer más…

Los estándares sí importan

diciembre 31, 2009 Deja un comentario

Mis primeras andanzas en el mundo de las arquitecturas orientadas a servicios (SOA) se desarrollaron sobre un servidor WebLogic 9.2, por entonces, un desconocido para mí.

Para conseguir el objetivo fijado en aquel momento, se instaló el producto de diseño de procesos BPEL de Oracle sobre el servidor WebLogic. Para aquellos que no lo conozcan, BPEL (Business Process Execution Language) es, a grandes rasgos, un lenguaje estàndard que permite definir un proceso cómo un flujo de tareas –automáticas o humanas-, ofreciendo integración con web services de forma natural. Existen distintos productos en el mercado orientados a ofrecer las capacidades de diseño, implementación y ejecución de los procesos definidos mediante este lenguaje, uno de los cuales, es la SOA Suite de Oracle.

En el mismo servidor, desplegamos una aplicación en tecnología ADF –también de Oracle-, que interactuaba con los procesos de negocio, y que actuaba de interfaz de usuario para las distintas tareas humanas definidas en el proceso BPEL.

En la fase de pruebas empezamos a detectar comportamientos extraños. De vez en cuando, nuestra aplicación ADF perdía la sesión web. Tardamos un tiempo en darnos cuenta de que esto sólo pasaba cuando hacíamos logout de la consola de control de BPEL que estaba desplegada en el mismo servidor que nuestra aplicación y lo hacíamos desde el mismo navegador (que gran invento los navegadores con pestañas!!). Como estábamos comprobando a través de la consola el avance del proceso gestionado por las pantallas de nuestra aplicación ADF, esto nos estaba pasando muy a menudo.

El comportamiento entraba en clara contradicción con lo que sabíamos –y sabemos- de los servidores de aplicaciones J2EE:

1) La sesión web es gestionada por el contenedor J2EE a nivel de contexto o aplicación.

2) Nosotros teníamos dos aplicaciones distintas, con sus respectivos contextos en el mismo servidor de aplicaciones.

Repasamos la documentación del servidor WebLogic, y en el apartado de seguridad (Programming WebLogic Security) se explica que las aplicaciones que comparten el nombre de la cookie de sesión, funcionan como un Single Sign On. Es posible modificar el nombre de la cookie mediante el fichero de despliegue weblogic.xml, con los parámetros CookieName y CookiePath.

Con este nuevo conocimiento, creamos el fichero de despliegue con un nombre específico para la cookie de sesión de nuestra aplicación ADF. A partir de ese momento, el problema de invalidación de la sesión desapareció.

Una vez solventado el problema, no pude más que acceder a la especificación de los servlets –según la documentación, el WebLogic 9.2 daba soporte completo a la especificación 2.4 de los Servlets- para establecer cuál debía ser el comportamiento de un contenedor J2EE a la hora de gestionar las sesiones web. Con sorpresa, comprobé que la especificación, en su apartado 7. Sessions, establece que el nombre de la cookie de sesión debe ser JSESSIONID (apartado 7.1.1) y que el objeto de sesión debe limitar su ámbito al de aplicación o contexto de servlets (apartado 7.3).

Por lo tanto, WebLogic no estaba cumpliendo con las especificaciones estándar!!

La importancia de los estándares debe quedar clara a las grandes compañías que proveen de servicios, para garantizar el éxito de los proyectos que se desarrollan en sus plataformas. Oracle –actual propietario de WebLogic- se ha caracterizado por un apoyo claro a la definición y uso de estándares. Confiamos que en el futuro próximo, seguirán realizando la misma valiente apuesta por los estándares, que redunde en beneficio de tota la comunidad.

Categorías:Metodología