¿Por qué actualizar a la nueva versión de Oracle SOA Suite 12c?
Hola, aquí estoy nuevamente con este post que es un resumen de la más reciente plática que tuve en el OTN Tour México 2015, evento que se llevó a cabo el pasado 14 de Agosto de 2015 en la UVM Coyoacán. Este evento anual es organizado por el grupo de usuarios Oramex y junta a una serie de expositores de todo el mundo con el objetivo de acercarnos a la red de tecnología Oracle. Hubo un total de 24 pláticas y un taller práctico. De lo que platicaré hoy es uno de los temas del evento, específicamente del rubro de Middleware y trata sobre algunas razones por las cuales es conveniente actualizar a la versión a Oracle SOA Suite 12c.
Bien pues comenzando con el tema, los invito a hacer una reflexión porque seguramente muchos de nosotros sabemos que hacer un cambio de versiones de cualquier software implica esfuerzo, tiempo, recursos económicos y algunas veces pareciera que se tienen que alinear muchas estrellas para que esto suceda. Tenemos la costumbre, quizás mala desde el punto de vista de sistemas, de realizar este esfuerzo, cuando la versión que se tiene actualmente de un software está en su límite de tiempo de vida, o bien, cuando ya no cumple con los requerimientos funcionales, probablemente ocasionando errores y pérdidas de diversos tipos. Para ese momento quizás ya es un poco tarde para hacer una estrategia de cambio que requiera el mínimo esfuerzo e inversión, lo que pasa en estos casos es que se tiene que hacer con carácter de urgencia, o el típico… ¡es para ayer! Que casi nunca pasa en sistemas. Esto sin duda nos obliga a tener tiempos muy cortos, poca planeación y seguramente algo se nos va a pasar. Al final, puede resultar más caro hacerlo con prisas.
En cambio, si tomamos una postura previsora y nos damos a la tarea de destinar tiempo y recursos antes de vernos en una situación crítica, podemos logar que se lleve a cabo de una manera más eficiente, ahorrándonos tiempo, esfuerzo, y lo que es más preciado, dinero.
Generalmente la iniciativa de cambiar a versiones más actuales surge del equipo técnico y es éste quien debe darse a la tarea de convencer a las personas que aprueban los gastos que implica el proceso. Convencer a estas personas que por lo general tienen un perfil más administrativo y que muchas veces no tienen claridad de la importancia de SOA en la organización, es complicado si solo lo vemos desde el punto de vista técnico. Porque, pensémoslo bien, por poner un ejemplo, a un director de sistemas que está tratando de ahorrar el mayor presupuesto posible, por muy buena onda que sea, no le va a interesar destinar dinero para que el equipo de desarrollo sea feliz, o haga su trabajo un poco más ameno, lo que le interesa saber es qué beneficios del negocio se obtienen y cómo se ven reflejados al paso del tiempo, además de que debe tener muy presentes los riesgos que implica no hacerlo. De esta forma es más fácil que acceda y que todos seamos más felices.
Entonces veamos dos aspectos importantes en la toma de decisión de cambio de versión, técnicos y de negocio. Comencemos con los técnicos, que no son más que algunas características de lo nuevo que tiene la versión 12c de SOA.
Beneficios técnicos
Beneficios de negocio
Esta lista es un grupo de razones que se traducen en beneficios al negocio, y que a su vez contestan de manera global a nuestra pregunta ¿Por qué actualizar a la versión de Oracle SOA Suite 12c? y son:
Estrategia de Upgrade/Migración.
Y hablando precisamente de punto número 9, es altamente recomendado, yo diría necesario, definir una estrategia de upgrade/migración, tener un plan nos dará claridad sobre las actividades que se tienen que realizar y evitaremos que se nos escapen cosas.
En esta gráfica podemos ver cómo ha ido avanzando la SOA Suite de Oracle a lo largo del tiempo hasta llegar a la versión actual, misma que fue liberada a mediados del año pasado y en específico se han liberado un par de releases que nos han traído hasta la 12.1.3, como se pueden dar cuenta, es una versión que lleva ya bastantes meses de ser constantemente mejorada y evaluada, por lo que éste es el mejor momento de cambiar de versión, ya que le quedan unos 4 años quizás antes de que saquen una nueva.
Para generar nuestra estrategia, es importante que nos situemos en algún punto de la línea, ya que dentro de cada uno de estos puntos existen versiones intermedias, por ejemplo, entre la 11 y la 12 existen varios releases como la 11.1.1.3, 11.1.1.5, 11.1.1.6, etc. y esto determinará la complejidad y el costo de migrar nuestros sistemas a la versión 12c. No es lo mismo que comencemos con una versión 10g, que con una 11g, así como tampoco es igual tener 11.1.1.3 que tener 11.1.1.7 por ejemplo. Situarnos en el punto exacto nos da la disyuntiva de hacer un upgrade o una migración.
Entendamos por upgrade como el proceso de cambiar de la penúltima (aunque no estrictamente) versión, a la última. Es el proceso más sencillo y menos costoso puesto que no se requiere crear de cero muchas cosas o modificar extensivamente lo que ya tenemos y podemos usar las herramientas que provee Oracle, en este caso, por mencionar dos ejemplos, solo podemos hacer upgrade de nuestro dominio SOA si tenemos la versión 11.1.1.6 o la 11.1.1.7 con JDK 7, y solo podemos hacer upgrade de un deployment usando una JVM de 64 bits, entre muchos otros. Aquí pueden encontrar la lista de requisitos para hacer upgrade.
Por el contrario, realizar una migración significa que el salto de versión es mucho más grande y por ende implica mayor dificultad… por decir algo, la instalación y configuración completa de nuestro dominio, aunque no necesariamente tiene que ser tan compleja la exportación/importación de nuestros proyectos, tal es el caso de versiones como la 11.1.1.3 o la 11.1.1.5.
Si estamos hablando de que tenemos la versión 10g, definitivamente es necesario hacer una migración. Les recomiendo que revisen la documentación de Oracle para obtener toda la información referente a esto.
Una vez que estudiamos a fondo nuestra situación actual y ya identificamos lo que requerimos, migración o upgrade, entonces el siguiente paso es determinar el alcance y darle forma a nuestra estrategia.
Para el caso de un upgrade, recomendamos que su estrategia tenga los siguientes pasos como mínimo:
Si identificamos que debemos realizar una migración completa, se debe tomar una decisión sobre las siguientes opciones:
Si vamos de 10g a 12c
En esta página pueden encontrar toda esta información, es la documentación oficial de Oracle que sirve como una guía, además hay videos donde pueden observar paso a paso la forma de realizar Upgrade.
Oracle Fusion Middleware 12c 12.1.3
Install, Patch, and Upgrade – Tasks
http://docs.oracle.com/middleware/1213/cross/upgradetasks.htm
Bueno pues así llegamos al final de este post, espero les haya sido interesante.
Muchas gracias por su atención.
¡Nos leemos pronto!
Si te interesa conocer más de ésta y otras tecnologías de Oracle, te recomiendo que visites la página de Oracle Technology Network Latinoamerica http://www.oracle.com/technetwork/es/index.html. Aquí podrás encontrar artículos, información, actividades y muchas otras cosas más, además de poder acercarte a los expertos en varios idiomas.
Bien pues comenzando con el tema, los invito a hacer una reflexión porque seguramente muchos de nosotros sabemos que hacer un cambio de versiones de cualquier software implica esfuerzo, tiempo, recursos económicos y algunas veces pareciera que se tienen que alinear muchas estrellas para que esto suceda. Tenemos la costumbre, quizás mala desde el punto de vista de sistemas, de realizar este esfuerzo, cuando la versión que se tiene actualmente de un software está en su límite de tiempo de vida, o bien, cuando ya no cumple con los requerimientos funcionales, probablemente ocasionando errores y pérdidas de diversos tipos. Para ese momento quizás ya es un poco tarde para hacer una estrategia de cambio que requiera el mínimo esfuerzo e inversión, lo que pasa en estos casos es que se tiene que hacer con carácter de urgencia, o el típico… ¡es para ayer! Que casi nunca pasa en sistemas. Esto sin duda nos obliga a tener tiempos muy cortos, poca planeación y seguramente algo se nos va a pasar. Al final, puede resultar más caro hacerlo con prisas.
En cambio, si tomamos una postura previsora y nos damos a la tarea de destinar tiempo y recursos antes de vernos en una situación crítica, podemos logar que se lleve a cabo de una manera más eficiente, ahorrándonos tiempo, esfuerzo, y lo que es más preciado, dinero.
Generalmente la iniciativa de cambiar a versiones más actuales surge del equipo técnico y es éste quien debe darse a la tarea de convencer a las personas que aprueban los gastos que implica el proceso. Convencer a estas personas que por lo general tienen un perfil más administrativo y que muchas veces no tienen claridad de la importancia de SOA en la organización, es complicado si solo lo vemos desde el punto de vista técnico. Porque, pensémoslo bien, por poner un ejemplo, a un director de sistemas que está tratando de ahorrar el mayor presupuesto posible, por muy buena onda que sea, no le va a interesar destinar dinero para que el equipo de desarrollo sea feliz, o haga su trabajo un poco más ameno, lo que le interesa saber es qué beneficios del negocio se obtienen y cómo se ven reflejados al paso del tiempo, además de que debe tener muy presentes los riesgos que implica no hacerlo. De esta forma es más fácil que acceda y que todos seamos más felices.
Entonces veamos dos aspectos importantes en la toma de decisión de cambio de versión, técnicos y de negocio. Comencemos con los técnicos, que no son más que algunas características de lo nuevo que tiene la versión 12c de SOA.
Beneficios técnicos
- Disponemos de un Quick Install que nos provee de un ambiente de desarrollo y servidor local de forma rápida. De hecho la instalación nos debe llevar menos de media hora, cuando en otras versiones, honestamente yo me he dado de topes en la cabeza. Claro que después de instalarla como 10 veces aprendes a hacerlo más rápido, pero sin duda nada como esta nueva versión, la cual incluye en un solo paquete JDeveloper, Weblogic, la SOA suite con OSB integrado y EM, la base de datos sigue estando por fuera.
- El IDE de desarrollo, es decir, JDeveloper, integra elementos para generar Compuestos SOA y también flujos OSB, anteriormente estaban separados, JDev solo para SOA, y la consola web y Eclipse OEPE para OSB. Esto brinda la misma experiencia usando BPEL y OSB.
- En la consola de monitoreo y administración, Enterprise Manager, se visualiza ahora también información sobre los servicios del OSB.
- La exposición de servicios tipo REST ahora es muchísimo más sencilla, basta con unos cuantos clics para que se creen interfaces de este tipo con mensajes JSON o XML simple. Lo cual simplifica la integración con móviles y cloud. En versiones anteriores el proceso es bastante más complejo. Más información de cómo hacerlo con 11g aquí.
- Se pueden crear y usar Templates para SOA y OSB, desde proyectos hasta actividades. Esto es muy bueno para mantener los estándares de desarrollo y agilizar los tiempos de construcción.
- Se pueden crear y reutilizar subprocesos BPEL, con la finalidad de construir bloques de actividades que puedan ser usadas en diversas ocasiones. Existen los subprocesos standalone y los inline.
Se tiene ahora un mapper visual de XQuery 1.0 y el mapper para XSLT 2.0 ha sido expandido y mejorado. - Se agregó funcionalidad de debug, ya sea en un servidor local o en uno remoto, se pueden establecer breakpoints en las actividades de un flujo, cambiar los valores de las variables y en general todas las funciones a las que estamos acostumbrados durante el debug.
- Las pruebas unitarias se simplifican, se puede desarrollar y probar directo en JDev sin usar la consola del EM, se auto generan mensajes de entrada, se pueden emular respuestas y fallos y se puede acelerar la ejecución con Fast Forward.
- Existe un nuevo componente en la SOA-INFRA llamado ESS, Enterprise Scheduling Service, que sirve para calendarizar la ejecución de tareas como PL/SQL, EJBs, Web Services, Java, líneas de comando, purgado de bases de datos, habilitar/deshabilitar adaptadores inbound, entre otras.
- Se agregó funcionalidad para el purgado de la base de datos del MDS, en la que se almacena el histórico de las instancias ejecutadas de los servicios. Se agregaron políticas de purgado configuradas por default.
Beneficios de negocio
Esta lista es un grupo de razones que se traducen en beneficios al negocio, y que a su vez contestan de manera global a nuestra pregunta ¿Por qué actualizar a la versión de Oracle SOA Suite 12c? y son:
- Porque siempre queremos estar alineados a los avances tecnológicos, a los avances de la competencia, a las tendencias del mercado, a la integración con el mundo exterior, y sobre todo, a las necesidades de nuestros clientes.
- Porque necesitamos generar diseños optimizados y/o aprovechar estos eventos para mejorar nuestros servicios críticos, si es que ya los tenemos.
- Porque debemos minimizar los escenarios de caos, causados por mantener versiones anteriores, que puedan generar pérdidas económicas o incluso más graves.
- Porque con versiones más recientes tenemos mayor capacidad de cumplir con los requerimientos del negocio, estamos mejor preparados para el futuro.
- Porque la versión 12c de SOA está probada y corregida, lo cual implica riesgos bajos de uso de las herramientas.
- Porque es más barato realizarlo con una estrategia y tiempo suficiente, que hacerlo bajo presión y con el tiempo encima.
- Porque si se sobrepasan los tiempos límites de vida de las herramientas, se pueden generar errores y pérdidas significativas al negocio.
- Porque eventualmente se termina el soporte de Oracle para corrección de errores de versiones anteriores.
- Porque analizaremos y diseñaremos una estrategia de upgrade/migración que nos va a respaldar durante todo el proceso y que nos ayudará a documentar y mejorar procesos de este tipo en futuras ocasiones.
Estrategia de Upgrade/Migración.
Y hablando precisamente de punto número 9, es altamente recomendado, yo diría necesario, definir una estrategia de upgrade/migración, tener un plan nos dará claridad sobre las actividades que se tienen que realizar y evitaremos que se nos escapen cosas.
En esta gráfica podemos ver cómo ha ido avanzando la SOA Suite de Oracle a lo largo del tiempo hasta llegar a la versión actual, misma que fue liberada a mediados del año pasado y en específico se han liberado un par de releases que nos han traído hasta la 12.1.3, como se pueden dar cuenta, es una versión que lleva ya bastantes meses de ser constantemente mejorada y evaluada, por lo que éste es el mejor momento de cambiar de versión, ya que le quedan unos 4 años quizás antes de que saquen una nueva.
Para generar nuestra estrategia, es importante que nos situemos en algún punto de la línea, ya que dentro de cada uno de estos puntos existen versiones intermedias, por ejemplo, entre la 11 y la 12 existen varios releases como la 11.1.1.3, 11.1.1.5, 11.1.1.6, etc. y esto determinará la complejidad y el costo de migrar nuestros sistemas a la versión 12c. No es lo mismo que comencemos con una versión 10g, que con una 11g, así como tampoco es igual tener 11.1.1.3 que tener 11.1.1.7 por ejemplo. Situarnos en el punto exacto nos da la disyuntiva de hacer un upgrade o una migración.
Entendamos por upgrade como el proceso de cambiar de la penúltima (aunque no estrictamente) versión, a la última. Es el proceso más sencillo y menos costoso puesto que no se requiere crear de cero muchas cosas o modificar extensivamente lo que ya tenemos y podemos usar las herramientas que provee Oracle, en este caso, por mencionar dos ejemplos, solo podemos hacer upgrade de nuestro dominio SOA si tenemos la versión 11.1.1.6 o la 11.1.1.7 con JDK 7, y solo podemos hacer upgrade de un deployment usando una JVM de 64 bits, entre muchos otros. Aquí pueden encontrar la lista de requisitos para hacer upgrade.
Por el contrario, realizar una migración significa que el salto de versión es mucho más grande y por ende implica mayor dificultad… por decir algo, la instalación y configuración completa de nuestro dominio, aunque no necesariamente tiene que ser tan compleja la exportación/importación de nuestros proyectos, tal es el caso de versiones como la 11.1.1.3 o la 11.1.1.5.
Si estamos hablando de que tenemos la versión 10g, definitivamente es necesario hacer una migración. Les recomiendo que revisen la documentación de Oracle para obtener toda la información referente a esto.
Una vez que estudiamos a fondo nuestra situación actual y ya identificamos lo que requerimos, migración o upgrade, entonces el siguiente paso es determinar el alcance y darle forma a nuestra estrategia.
Para el caso de un upgrade, recomendamos que su estrategia tenga los siguientes pasos como mínimo:
- Revisar los pre-requisitos de upgrade en la documentación y validar si es viable.
- Realizar tareas de pre-upgrade, por ejemplo respaldos, purgado de instancias viejas, validación de permisos, etc.
- Instalar el software de SOA 12c en ambiente de Testing.
- Crear/Actualizar esquemas de la BD interna de SOA, ya que cambiaron algunos de ellos.
- Re-configuración de Dominio. Podemos usar las herramientas de upgrade que proporciona Oracle.
- Tareas de post-upgrade, por ejemplo complementar o generar documentos de memoria técnica.
- Validación y pruebas de los resultados en ambientes de Testing.
Si identificamos que debemos realizar una migración completa, se debe tomar una decisión sobre las siguientes opciones:
Si vamos de 10g a 12c
- Primero se puede hacer una migración a 11g, de preferencia a la 11.1.1.7 y después un upgrade a 12c.
- O bien, realizar un rediseño completo de los desarrollos y arquitectura, y hacer una migración directa a 12c.
- Se puede realizar el upgrade a una versión previa y luego a 12c.
- O bien, realizar la migración directa a 12c aprovechando para re-factorizar tantos servicios como se desee.
En esta página pueden encontrar toda esta información, es la documentación oficial de Oracle que sirve como una guía, además hay videos donde pueden observar paso a paso la forma de realizar Upgrade.
Oracle Fusion Middleware 12c 12.1.3
Install, Patch, and Upgrade – Tasks
http://docs.oracle.com/middleware/1213/cross/upgradetasks.htm
Bueno pues así llegamos al final de este post, espero les haya sido interesante.
Muchas gracias por su atención.
¡Nos leemos pronto!
Si te interesa conocer más de ésta y otras tecnologías de Oracle, te recomiendo que visites la página de Oracle Technology Network Latinoamerica http://www.oracle.com/technetwork/es/index.html. Aquí podrás encontrar artículos, información, actividades y muchas otras cosas más, además de poder acercarte a los expertos en varios idiomas.
Comentarios
Publicar un comentario