Oracle Application Container – Demo
Introducción
Hoy haremos un ejemplo básico de uso de Oracle Application
Container. Lo primero que haremos es dar una mirada a los detalles de ésta nube
de Oracle.
Para esto, vamos a navegar a la siguiente URL:
Veremos las siguientes ofertas de PaaS. Por el momento nos
interesa el Application Container:
Esto nos llevará al sitio de Oracle Application Container.
Para solicitar una prueba, basta con elegir la opción “Try it” y seguir el
procedimiento de solicitud de la instancia:
Después de un rato (algunas horas), nos llegará un correo
electrónico de Oracle Cloud, que indicará que el servicio fue aprovisionado y
nos dará acceso a lo siguiente:
·
Administración de los servicios
o
Dashboard
·
Detalles de la suscripción (esto puede variar,
en mi caso se aprovisionó lo siguiente)
o
Oracle Application Container Cloud (este es el
que vamos a usar en esta ocasión)
o
Oracle Integration Cloud Service (se van a
divertir con Twitter, Facebook y LinkedIn)
o
Oracle SOA Cloud Service (para los que piensan
que SOA está muerto, ¡nada más falso!)
o
Developer Service (¿desarrollo en la nube?
Ustedes, DevOps, Continuous Integration, Git. ¡No sé, piénsenlo!
¿Cómo se come?
Aquí vamos a dar la descripción comercial para no entrar en
polémica (ya hay bastante polémica en el mundo gracias a los dichosos
microservicios).
El fabricante define esta nube como una plataforma políglota
nativa en la nube. Esto incluye:
·
Desarrollo nativo en la nube
·
Distintos estilos de aplicaciones en una
plataforma políglota y moderna con Java SE, PHP, Node.js y más
·
Rápida: autoservicio para el aprovisionamiento
de contenedores de aplicaciones. Esto es cierto, aunque para mi gusto no fue
tan rápido. El aprovisionamiento tardó algunas horas después de solicitarlo y
varias conversaciones por chat con el soporte de Oracle. Uno debe ser exigente,
aunque sean versiones de prueba.
·
Escalable: es posible seleccionar el tamaño de
la memoria RAM de nuestra instancia y escalarla hacia arriba o abajo de manera
dinámica. Esto es cierto. Hay quienes piensan que tener una instancia de unos
cuántos KB es importante, yo particularmente no entiendo para qué me serviría
una JVM que levante con unos cuántos KB. En fin, se puede hacer.
·
Abierta: se puede elegir entre las distintas
versiones de Java SE, PHP y Node.js. Así como librerías, módulos y frameworks.
·
Ágil: cuenta con herramientas de control del
ciclo de vida del desarrollo en la nube, incluye integración continua y
despliegue.
Demo
Ahora pasemos directamente al uso de Oracle Application
Container Cloud. La intención de esta entrada del blog es dar una introducción
para la creación de un web service (Grizzly + Jersey + REST), que pueda ser
almacenado y distribuido en un JAR. ¿Recuerdan eso de portabilidad en
microservicios, nubes, contenedores y todo eso? Pues eso es lo que haremos
aquí.
Antecedentes
Cuando un desarrollador piensa en crear un servicio REST
usando Java, asumen que para crear este tipo de aplicaciones se debe usar un
servidor Java EE. Sin embargo, hay alternativas mucho más ligeras para crear
aplicaciones REST usando Java SE. Demostraremos que una alternativa es usar el
servidor de Grizzly y el framework Jersey para REST.
Aquí cubriremos los aspectos básicos para crear una
aplicación REST con Grizzly, Jersey y Maven. La aplicación incluye un modelo de
datos simple para demostrar cómo se procesan las peticiones REST. Crearemos una
clase para el web service con anotaciones que convertirá los métodos en URLs
REST que se pueden consumir. Finalmente, empaquetaremos la aplicación REST en
un JAR portable que pueda ser ejecutado en donde sea.
Grizzly Web Server
Grizzly es un servicio web Java hecho con API NIO. El caso
de uso principal de Grizzly es el componente web server de GlassFish. Sin
embargo, el objetivo de Grizzly es ayudar a los desarrolladores a hacer más que
eso. Con Grizzly podemos construir servidores escalables y robustos usando NIO
y ofrecer algunas otras bondades como un Web Framework (HTTP/S), WebSocket, Comet
y más.
Jersey, REST y JAX-RS
Jersey es un framework de código libre (a todos nos gusta
mucho esto) para desarrollar web services en Java, de tipo REST. Jersey soporta
las APIs y servidores JAX-RS.
Escenario
El servicio web REST construido es el inicio de una
aplicación REST para la administración de información de clientes. Para este
ejemplo, los datos del cliente son almacenados en una lista. Crearemos un
método web para devolver todos los clientes contenidos en la lista y un método
para buscar al cliente por su identificador. Para mantener esto simple, todos
los datos son devueltos en un formato de texto plano.
Requisitos de software
Necesitamos lo siguiente instalado en nuestro equipo:
·
Maven 3.3.1 o superior: https://maven.apache.org/
·
Java 8 u45 o superior:
Proyecto Maven
El primer paso es crear el proyecto de Maven. Ya existe un
arquetipo para este tipo de aplicación (a veces se usa de manera indiscriminada
la palabra arquetipo). Para crear el proyecto debemos hacer lo siguiente:
1.
Navegar al directorio donde deseamos crear el
proyecto
2.
Ejecutar el siguiente comando para crear el
proyecto
3.
Es posible que no puedan encontrar el arquetipo
que estamos buscando y que les aparezca un error como el siguiente:
4.
Pero no teman, los tengo cubiertos. Vayan a esta
liga y descarguen el JAR:
5.
Luego copien el JAR en su repositorio local de
Maven:
6.
Ejecuten de nuevo el comando y la magia estará
hecha:
7.
Si damos una mirada en nuestro sistema de
archivos, veremos que el proyecto está creado:
8.
La estructura del arquetipo, se ve como sigue:
9.
En este punto me di cuenta que no tengo NetBeans
instalado. Al inicio dije que usaría NetBeans, pero puedo usar Eclipse también.
Si ustedes tienen NetBeans: File > Open Project. Si tienen Eclipse: File
> Import > Maven > Existing Maven Project.
10.
Usé Eclipse y la importación del proyecto se
debe ver así (para este punto, moví la carpeta generada por Maven hacia mi
workspace de Eclipse:
11.
Entonces, así se ve en Eclipse:
Una mirada al POM
Cuando creamos el proyecto de Maven, se creó nuestro archivo
de configuración principal: pom.xml. En este archivo vamos a colocar todas las
dependencias y versiones requeridas para construir el proyecto.
1.
La primera parte del archivo contiene metadatos
del proyecto. ¿Recuerdan el ID del grupo y del artefacto que colocamos en la
línea de comandos al crear el proyecto?:
2.
La segunda parte, contiene las dependencias del
código requeridas por el proyecto:
3.
La tercera y última parte del archivo, contiene
información acerca de los plugins requeridos por la aplicación:
Código fuente
Para este arquetipo, se han creado un par de archivos.
1.
La clase principal (main) que es la que levanta
la aplicación:
2.
La clase que define los métodos del web service:
Ejecución del web service
Una vez que hemos creado el proyecto, vamos a usar Maven
para ejecutar la aplicación e iniciar el web server.
1.
Abrir una terminal o línea de comandos
2.
Navegar hacia la ruta del proyecto
3.
Compilar el proyecto
4.
Ejecutar el proyecto. Esto lo hice desde Eclipse
(Run) para comprobar que Maven también funciona desde el IDE:
5.
Si navegamos a la URL del WADL, podremos ver lo
siguiente:
6.
Si ejecutamos un HTTP GET hacia la URL donde se
encuentra nuestro recurso, obtendremos lo siguiente:
Crear el web service de Clientes
Para hacer esto un poco más interesante, vamos a agregar
algunos datos de clientes a nuestro proyecto. Los archivos de clientes pueden
ser modificados para que podamos buscar un cliente de manera individual; o
bien, obtener la lista completa de clientes.
Agregar el código de las clases de clientes
Para esto vamos a usar dos clases. La clase cliente que es
usada para representar datos del cliente y la clase lista de clientes que es la
que crea una lista de clientes usando los datos de ejemplo.
1.
Crear la clase Customer. Se puede descargar del
siguiente link:
2.
Crear la clase CustomerList. Se puede descargar
del siguiente link:
Agregar el código del web service
El siguiente paso es agregar el web service a la aplicación:
CustomerService. Se puede descargar del siguiente link:
Probar el web service de Clientes
Una vez que hemos creado las clases tanto de Clientes como
del web service, vamos a probar el funcionamiento.
Lo primero que debemos hacer es detener el servidor y
volverlo a iniciar. Para esto únicamente corremos la aplicación principal
(main).
Obtener la lista de todos los clientes
En cuanto el servidor levanta, vamos a probar la siguiente
URL para obtener una lista de todos los clientes en nuestro navegador:
Lo que obtendremos es lo siguiente:
Buscar un cliente por su identificador
Si queremos obtener un cliente en particular, únicamente
debemos agregar su identificador al contexto de la URL. Así, al hacer una
petición (HTTP GET) a la siguiente URL, obtendremos los datos del cliente 103:
Buscar un cliente que no existe
En caso de colocar un ID de un cliente que no existe,
obtendremos la siguiente respuesta:
Crear un Uber JAR
Suena muy raro, ¿Uber JAR? Muchas veces cuando creamos una
aplicación, al estar desarrollando tenemos que incluir dependencias (otros
JAR), modificar el CLASSPATH, incluir muchas cosas para que nuestra aplicación
pueda funcionar. Si deseamos que esta aplicación pueda ser portable y la
podamos ejecutar en cualquier lugar, debemos crear un Uber JAR. Este tipo de
JAR es el que incluye todas las dependencias y lo podemos transportar a donde
sea.
Actualizar el pom.xml
Para que Maven pueda realizar esto, es necesario modificar
nuestro pom.xml. El primer cambio es agregar el plugin de assembly.
Este plugin es utilizado para crear JARs o WARs que
empaquetan aplicaciones Java en un único archivo. Lo que quiero resaltar aquí
es que la clase Main se configura para ser la clase ejecutable del JAR.
Ahora que hemos creado nuestro JAR ejecutable, es necesario
configurar el pom.xml para que agregue todas las dependencias al JAR. Para
esto, vamos a usar el plugin de dependency.
Al agregar la meta copy-dependencies, estamos logrando que
todas las dependencias queden dentro del JAR que vamos a generar.
Ejecutar la aplicación
Para construir y ejecutar la aplicación, debemos hacer lo
siguiente:
1.
Compilar la aplicación
2.
Empaquetar la aplicación
3.
Verificar el directorio del JAR
4.
Ejecutar el JAR
En este punto, tengo la aplicación corriendo en mi equipo,
sin necesidad de hacer más nada. Únicamente ejecuté el JAR:
¡Listo! Ahora tenemos un JAR ejecutable, empaquetado y listo
para ejecutarse en cualquier lugar que corra Java. Todo esto, con Java SE +
Grizzly + Jersey.
Despliegue en Oracle Application Container
Es necesario crear un archivo ZIP con el JAR de nuestra
aplicación y un MANIFEST escrito en formato JSON. Posterior a esto, podremos
desplegarlo en Oracle Application Container.
Creación del manifiesto
He renombrado el JAR que contiene todas las dependencias. El
nombre es auto descriptivo y describe el funcionamiento del servicio. Es un
servicio de catálogo de clientes:
Es necesario crear un archivo llamado manifest.json que nos
dará información del despliegue que vamos a realizar. El archivo tiene la
siguiente forma:
Donde:
·
Major Version: La versión de Java, en mi caso 8.
·
Command: El comando a ejecutar después de
realizar el despliegue
·
Build: Número de identificación de la
aplicación, proporcionado por el usuario.
·
Commit: Mensaje de despliegue de la aplicación,
proporcionado por el usuario.
·
Versión: Versión de la aplicación, proporcionado
por el usuario.
·
Notes: Cualquier comentario adicional,
proporcionado por el usuario.
Finalmente, debemos comprimir el JAR y el manifiesto, en un
archivo ZIP:
Despliegue vía la consola
Lo que debemos hacer para el despliegue es lo siguiente:
1.
Entrar a Oracle Application Container
2.
Crear una aplicación. Aquí proporcionaremos el
nombre de la aplicación a desplegar, el tipo de suscripción, el archivo a
desplegar, comentarios e información de la instancia (memoria, número de
instancias y versión de Java). Al desplegar la aplicación, debemos esperar
algunos minutos a que el archivo termine de procesarse.
3.
Monitorear la aplicación. Una vez que creamos la
aplicación, se tomará unos minutos para que se aprovisione el contenedor
correspondiente. Mientras tanto nos aparecerá algo como lo siguiente:
4.
Acciones sobre la aplicación. Tenemos
disponibles varias acciones que podemos realizar sobre cada aplicación
desplegada.
Conclusiones
La transformación digital nos ha llevado a la necesidad de
utilizar medios de comunicación efectivos y ligeros. Esta habilitación de la
comunicación entre aplicaciones es fundamental para dar agilidad a los negocios
y responder ante los constantes cambios en las necesidades del mercado.
REST nos ofrece una manera ligera, estándar y segura como
mecanismo de integración de aplicaciones, además de que es el preferido de los
dispositivos móviles. Existen en el mercado distintos frameworks que nos
facilitan el desarrollo e implementación de éste tipo de servicios y
aplicaciones. Muchos de ellos son software libre donde la comunidad colabora
diariamente.
Existen algunos otros componentes ligeros sobre los que
corren nuestros servicios REST, como es el caso de Grizzly en este ejemplo.
Otras opciones pueden ser Jetty o Netty. La decisión va a depender de las capacidades
que estemos buscando de nuestro contenedor de aplicaciones.
Finalmente, una de las cosas más importantes es la
portabilidad de las aplicaciones que estamos creando. El tema de la
contenerización es fundamental en estos tiempos. Codificar una única vez y
correr nuestro código en cualquier contenedor de aplicaciones. ¿Alguna vez
pensaron en esto? Soluciones portables, empaquetadas. De aquí pueden
desprenderse muchas líneas de negocio al pensar en cómo definimos la
arquitectura de nuestras aplicaciones y cómo las desarrollamos.
Siéntanse libres de expresar sus comentarios aquí abajo.
