Archivo
¿Tengo que instalar los “Oracle Critical Patch Update” en mis entornos?
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.
Piensa en Web, pantallas ligeras y rápidas
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:
- Layout: En un entorno tipo Cliente-Servidor (como Oracle Forms) disponemos de un runtime propietario y controlado que nos permite entre otras cosas el posicionamiento absoluto de items. En cambio en el entorno web no sabemos a priori sobre qué navegador va a correr nuestra aplicación. Incluso diferentes versiones del mismo navegador (léase MS Explorer) tienen comportamientos diferentes. Debemos asegurarnos que nuestra aplicación sea capaz de mostrarse correctamente en cualquier navegador. El uso de componentes estándar de ADF 11g simplifica en gran medida este punto.
- Simplicidad: El tráfico que genera una aplicación web es significativamente mayor que el generado por una aplicación Cliente-Servidor ejecutada en un entorno de tres capas (con servidor de aplicaciones), y además la representación es más lenta (el navegador debe interpretar el código html, javascript, css, etc que le llega). Para no penalizar el rendimiento de la aplicación, es aconsejable “aligerar” al máximo las pantallas. Al mismo tiempo estaremos generando pantallas más “atómicas”, y por tanto, más fáciles de reutilizar desde diferentes puntos de la aplicación. Frameworks como ADF 11g facilitan este tipo de diseños, mediante el uso de task flows.
Consideraciones generales sobre recursividad
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).
¿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.
Facilitando el consumo de nuestros Web Services basados en PL/SQL
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.
¿Dónde está ubicada la lógica de negocio de tu aplicación? (1) – Teoría
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.
Recuperación ante desastres con Oracle, del Active Dataguard a la Standby Manual
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.
Leer más…
Actualicemos los “Oracle Client”
¿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:
Best Practices ADF
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.
Nuestra red social |
|
|
