Periódicamente (en la actualidad cada tres meses) Oracle envía a sus clientes notificaciones de la salida de los “Critical Patch Updates“:
La mayoría de clientes se preguntan si deben instalar estos parches en sus entornos y qué ventajas/inconvenientes tendrían en caso de hacerlo.
Para aquellos equipos acostumbrados al desarrollo en entornos cliente-servidor, el paso al desarrollo de aplicaciones web no debería únicamente implicar el cambio de herramientas y tecnología a usar por parte del equipo de programación. Es tarea del equipo de analistas funcionales entender los cambios en la interficie de usuario, o a nivel transaccional que el paradigma web conlleva. Debemos tener en cuenta que un diseño funcional donde en una pantalla ponemos dos o tres relaciones maestro-detalle con multitud de ítems, si bien será implementable en web, su rendimiento será muy pobre, y además estaremos mareando al usuario llenando su navegador con una cantidad excesiva de información.
En un caso como el planteado, si realmente el usuario va a tener que rellenar toda esa información, lo más indicado sería presentarle la información en bloques (como en un wizard, con botones de “anterior” y “siguiente”; en cambio, si los datos a introducir or modificar es una parte del total, lo mejor sería que el usuario pudiera navegar a los diferentes bloques que él seleccione.
Cito un par de factores importantes que deberían ser tenidos en cuenta:
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).
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.
Una de las cosas más importantes a la hora de desarrollar web services es proporcionar un contrato detallado describiendo las operaciones y parámetros de nuestro servicio. Este contrato se describe mediante lenguaje XML en un fichero de tipo WSDL (Web Service Description Language). Cuanto más precisa sea la definición del servicio en su contrato, menos problemas tendremos de interpretación entre lo que entienden los que desarrollan el servicio y los que lo consumen. Además, un contrato preciso permite a los consumidores utilizar herramientas de generación automáticas que les facilitan la tarea de llamar al servicio, pudiéndose concentrar en la lógica de la interacción y no en la tecnología.
JDeveloper, desde su versión 9, proporciona herramientas para publicar web services basados en packages PL/SQL. De este modo, es fácil reaprovechar la lógica de negocio embebida en nuestras bases de datos Oracle. El único problema que tiene el wizard de JDeveloper, es cuando se trata de generar el contrato para un servicio que devuelve directamente una estructura XML, es decir, un objeto de tipo XmlType. En este caso, y ante la incapacidad de averiguar cuál es la estructura que devuelve el PL/SQL, JDeveloper pone en el contrato que el método devuelve cualquier XML (un elemento de tipo any o anyType de XSD).
Si queremos aplicar buenas prácticas, deberemos modificar el contrato generado para que contenga la descripción de la estructura que realmente devolvemos (y que nosotros, en calidad de proveedores del servicio, conocemos). En este post, explicamos cuáles serían los pasos a realizar.
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.
En la mayoría de empresas se han ido implantando durante los últimos años planes de recuperación ante desastres o DR (Disaster Recovery). Estos planes comprenden un conjunto de recursos hardware, software y procedimientos que deben permitir a una empresa continuar ofreciendo sus servicios (o los considerados mínimos) en caso de que ocurran problemas graves en los sistemas informáticos de ésta.
Ejemplos típicos de estos problemas pueden ser incendios, inundaciones, terremotos, pérdidas prolongadas de suministro eléctrico/comunicaciones o errores humanos que dejen fuera de servicio los sistemas informáticos principales de la empresa.
En el caso de los productos Oracle y para intentar minimizar este tipo de problemas, existen configuraciones de DR que nos permiten mantener en ubicaciones físicamente separadas (a decenas, centenares o miles de kilómetros) sistemas de contingencia que podrán seguir dando servicio en caso de caída de los sistemas principales.
No deberemos confundir el DR destinado a sobreponer a la empresa ante errores graves o de gran magnitud con la alta disponibilidad o HA (High Availability). La HA está encaminada a evitar cortes de servicio en caso de fallo en alguno de los componentes de nuestros sistemas informáticos. De hecho ambos tipos de soluciones se pueden combinar en los sistemas informáticos más críticos. Por ejemplo disponer de discos, o tarjetas de red duplicados en un servidor es una solución de alta disponibilidad (HA), disponer de un segundo servidor en otra ciudad replicado con el primero es protección ante desastres (DR).
Hoy nos centramos solo en el DR, y específicamente en DR para las BBDD Oracle, dejando para próximas entradas soluciones de HA para BBDD y HA/DR para servidores de aplicaciones Oracle.
¿Vale la pena actualizar los clientes de BBDD Oracle?
La mayoría de empresas que disponen de BBDD Oracle tarde o temprano han abordado un upgrade o migración de sus gestores, es parte del ciclo de vida del producto.
No obstante, estas migraciones o upgrades no siempre coinciden con la actualización de los clientes Oracle que tenemos dispersos por la organización… y esto puede ocasionar problemas.
Un ejemplo es una empresa con una BBDD 10.2.0.4, pero que mantenía algunos clientes en versión 10.2.0.1 (los instalaban y no aplicaban el parche). Todo funcionaba, ciertamente, pero en la BBDD aparecían selects como éstas:
Segun una nota de Oracle estas selects son del propio driver ODBC:
Empezar el año con una dosis de Best Practices siempre esta bien.
En esta caso hablamos de una presentación de Steve Muench ,Prodduct Manegar de Oracle y experto en Fusion Applications, del Open World del pasado año. Octubre 2009.
Best-Practices-From-Fusion-Applications-Teams-OpenWorld-2009
En ella hace referencias muy interesantes de cómo acceder a métodos públicos del AM,desde un bean, el uso de backing beans, lovs con descripción, task flows, etc.
Es un documento mas teórico que técnico pero muy útil para todos aquellos que empiezan el año con proyectos y tienen dudas de cómo afrontar ciertos temas.
avanttic
Rafael Planella
Javier Gea
Carles Biosca
Xavier Ribas
Aitor Casas
Albert Ibars
Jordi Sansó
Víctor Cruz
Montserrat Maceda
Javier Llorente Leyton
Diana Pujagut
Oscar San Jose
Antonio José Molina
Jose Luis Alvarez
Javier Navarro
Marc Pérez
Joan Massegú