miércoles, 22 de noviembre de 2017

Pruebas unitarias con utPLSQL

Las pruebas son un mal necesario del proceso de desarrollo de aplicaciones. Lamentablemente, las pruebas a menudo se pasan por alto o se pasan por alto cuando el tiempo es corto (seamos sinceros, ¿Quién no odia la fase de pruebas?). La distribución de código no probado o no marcado puede llevar a un código plagado de errores y a usuarios decepcionados. Las pruebas unitarias con un marco bien construido pueden ayudar a aliviar parte del tiempo que lleva ajustarse a un proceso de desarrollo bien probado.

Hay algunas opciones diferentes disponibles para probar tu código PL / SQL. La herramienta de Oracle SQL Developer:
  • http://www.oracle.com/technetwork/es/developer-tools/sql-developer/overview/index.html


Proporciona algunas buenas opciones de depuración.

También puede usar instrucciones DBMS_OUTPUT dentro de su código para mostrar los resultados de las variables a medida que se ejecuta su código. Esta es una buena técnica para ayudar a identificar problemas en su código.

Frameworks de prueba para PL/SQL

Los más conocidos en la comunidad de Oracle son quizás Quest's Code Tester, especialmente con personas que trabajan con Toad y utPLSQL, que ha sido desarrollado por el superhombre de PL / SQL Steven Feuerstein, y las características integradas de Oracle SQL Developer.
  • DbFit                                   
  • Desarrollador Oracle SQL
  • Pruebas unitarias PL / SQL para Oracle (PLUTO)
  • PL / Unidad
  • Quest Code Tester para Oracle
  • ruby-plsql-spec
  • utPLSQL

Por ejemplo el framework PLUTO (PL / SQL Unit Testing for Oracle) (http://code.google.com/p/pluto-test-framework/) es uno de esos marcos.

Otro es el marco de pruebas unitarias utPLSQL, creado por Steven Feuerstein  y este artículo se centrará en utPLSQL ya que es más ampliamente adoptado que los demás. El framework de pruebas unitarias  utPLSQL (http://utplsql.org/downloads/) puede aliviar parte del dolor de realizar las pruebas unitarias. El marco es fácil de usar y funciona muy bien para probar código bajo cualquier circunstancia que pueda imaginarse. Ahí también hay muchas opciones en utPLSQL que se pueden usar para mejorar el proceso de prueba de su unidad. Como resultado del uso de pruebas unitarias, sus aplicaciones serán más fiables, y pasará mucho menos tiempo manteniendo la base de código.

Prueba de código PL / SQL almacenado sin pruebas unitarias

Problema

Desea asegurarse de que un bloque de código PL / SQL funciona correctamente, pero no quiere tomarse el tiempo para escribe una prueba unitaria

Solución

Envuelves el código en las sentencias DBMS_OUTPUT que muestran o imprimen los resultados de intermedio y final, así como los resultados de pasos y ramas condicionales complejos. Esto te permitirá ver la ruta que toma el código cuando se llama a la función con los parámetros especificados. El siguiente ejemplo muestra esta táctica para colocar comentarios en ubicaciones estratégicas dentro de un código PL / SQL para ayudar a determinar si el código está funcionando como se esperaba. Por ejemplo, supongamos que desea pruebe rápidamente la función que presentamos en el ejemplo. Así es como lo modificarías para probar rápidamente la exactitud de sus resultados.


Cuando la función CALC_HORAS_TRIMESTRALES se ejecuta con un valor de 7.34, los comentarios se mostrarán como se ve en el siguiente fragmento de una sesión:
SQL> set serveroutput on
SQL> select calc_horas_trimestrales(7.34) from dual;
CALC_HORAS_TRIMESTRALES(7.34)
-----------------------

7.25
El valor pasado fue mayor a una hora ...
La porción decimal <= .375

El uso de instrucciones DBMS_OUTPUT dentro del código PL / SQL para mostrar datos o información perteneciente a la funcionalidad del código ha sido una gran táctica para probar el código en cualquier idioma. Como una cuestión de hecho,
es probablemente una de las técnicas más utilizadas para depurar código. La capacidad de ver valores como se calculan o para determinar cómo se maneja una condición puede ser muy útil para determinar si su código se está ejecutando como debería.

Para utilizar las sentencias DBMS_OUTPUT para probar tu código, debes colocarlas en estrategias ubicaciones. En el ejemplo de esta receta, los comentarios se han colocado dentro de cada uno de los bloques IF-ELSE para mostrar un poco de texto que le dirá al desarrollador cómo se procesan los valores dentro de la función.
Esto puede ser muy útil cuando se prueba el código porque una serie de números se puede pasar al función para determinar si se está devolviendo el resultado correcto. Si no, entonces podrás  para ver exactamente dónde se está evaluando incorrectamente el código.


Aunque el uso de instrucciones DBMS_OUTPUT en el código puede ser muy útil para determinar dónde se encuentra el código funcionando correctamente, puede causar desorden y también puede crear sus propios problemas. Por ejemplo, si te olvidas de colocar una cita después de una de las instrucciones DBMS_OUTPUT que coloca en su código, entonces el código no se compila correctamente, lo que hace que busques la causa de otro problema. Además, es una buena idea eliminar las instrucciones de salida antes de que el código se libere en producción. Esto puede tomar un tiempo, que podría ser mejor invertido en el desarrollo. Como un medio para probar pequeñas unidades de código, usando DBMS_OUTPUT funciona bastante bien. Sin embargo, si desea desarrollar suites de prueba completas y una unidad automatizada probando, entonces debes de continuar leyendo el resto del artículo.

Instalar utPLSQL

Problema

Has elegido el marco de pruebas de unidad utPLSQL para PL / SQL para tu trabajo y quieres instalarlo.

Solución

Primero, descarga las fuentes de utPLSQL. Una vez que hayas obtenido las fuentes, sigue los siguientes pasos para instalar el paquete utPLSQL en la base de datos para la cual desea escribir las pruebas unitarias y ponerlo a disposición para todos los esquemas.
Crea un usuario para alojar las tablas, paquetes y otros objetos de utPLSQL. Por ejemplo, el usuario se llamará UTP y se usarán los tablespaces permanentes y temporales predeterminados.

Otorga privilegios al usuario UTP recién creado utilizando GRANT <privilege_name> TO  <user_name>, reemplazando valores con el privilegio apropiado y nombre de usuario El usuario requerirá los siguientes privilegios:
  • Create session
  • Create procedure
  • Create table
  • Create view
  • Create sequence
  • Create public synonym
  • Drop public synonym

Instalaa los objetos ejecutando el script ut_i_do.sql.

SQL> @ut_i_do instalar

Una vez que se hayan completado estos pasos, tendrás la posibilidad de ejecutar pruebas unitarias en paquetes que se cargan en diferentes esquemas dentro de la base de datos.

Usar utPLSQL

Problema

Te gustaría construir un paquete de prueba de unidad para uno o más de los objetos PL / SQL en su esquema de base de datos.

Solución

Deseas construir un paquete de prueba utPLSQL para probar un objeto en su base de datos. Un paquete de prueba consta de dos archivos separados, un encabezado de paquete y un cuerpo de paquete.

Cree un encabezado para el paquete de prueba y guárdelo en un archivo con el mismo nombre que le ha asignado al encabezado y con un sufijo .pks.
Un archivo de encabezado contiene tres procedimientos: 
  • ut_setup, 
  • ut_teardown 
  • El procedimiento que realiza las pruebas unitarias del objeto de destino en su base de datos. 

Por ejemplo, supòn que deseas crear un paquete de prueba de unidad para probar el código de la función CALC_HORAS_TRIMESTRALES. Este encabezado de paquete debe almacenarse en un archivo llamado ut_calc_horas_trimestrales.pks y cargado en la base de datos cuyos objetos estás probando.

Cree el cuerpo del paquete que implemente los procedimientos especificados por el encabezado del paquete de prueba de la unidad y guárdelo como un archivo con el mismo nombre que el encabezado, pero esta vez con un sufijo .pkb. El siguiente cuerpo del paquete debe almacenarse en un archivo llamado ut_calc_horas_trimestre.pkb y cargarse en la base de datos.

El cuerpo del paquete en este ejemplo se ajusta al formato que se debe usar para probar paquetes usando el marco utPLSQL.




lunes, 20 de noviembre de 2017

El Oráculo en la nube de las amazonas



Como bien reza el título del artículo sacado de una película de serie b de los cincuenta, en este artículo vamos a abordar como Amazon Web Services (AWS) te ofrece la posibilidad de ejecutar nuestra base de datos favorita en su nube pública. 

La ejecución de Oracle Database en la nube de AWS es muy similar a  ejecutar Oracle Database en su centro de datos. Para un administrador o desarrollador de base de datos, no hay diferencias entre los dos entornos. Sin embargo, hay una serie de consideraciones de la plataforma AWS relacionadas con

  • La seguridad
  • El almacenamiento de la información
  • La gestión de la configuración 
  • Administración y monitoreo de la base de datos

que nos facilitan a obtener lo mejor de su base de datos Oracle implementación en AWS

En este artículo proporcionaremos las mejores prácticas para lograr  un mejor rendimiento, disponibilidad y confiabilidad óptimas, y, por supuesto, un menor coste  (TCO) mientras ejecuta Oracle Database en AWS

El público objetivo para este artículo incluye administradores de bases de datos, arquitectos empresariales, administradores de sistemas y desarrolladores que deseen ejecutar su base de datos Oracle en AWS.


Introducción a AWS

Amazon Web Services (AWS) proporciona un conjunto integral de servicios y herramientas para implementar Oracle Database en la infraestructura confiable y segura de nube de AWS. AMAZON ofrece a sus clientes dos opciones para ejecutar Oracle Database en AWS:

Amazon RDS para bases de datos Oracle

Utilizando Amazon Relational Database Service (Amazon RDS) para Oracle, que es un servicio de base de datos administrado que ayuda a simplificar el aprovisionamiento y la administración de bases de datos Oracle. Amazon RDS facilita la configuración, el funcionamiento y la escalabilidad de una base de datos relacional en la nube al automatizar la instalación, el aprovisionamiento y la administración del disco, el parcheo, las actualizaciones menores de la versión, el reemplazo fallido de instancias y las tareas de respaldo y recuperación.

La función Multi-AZ de Amazon RDS opera dos bases de datos en múltiples zonas de disponibilidad con replicación síncrona, creando así un entorno de alta disponibilidad con failover automático. La función de escalado de botón de Amazon RDS le permite escalar la instancia de la base de datos hacia arriba y hacia abajo fácilmente para una mejor gestión de costos y rendimiento. Amazon RDS también viene con una opción de licencia incluida, que permite pagar por uso por hora.

Base de datos Oracle autogestionada Amazon EC2

Ejecución de una base de datos Oracle autogestionada directamente en Amazon Elastic Compute Cloud (Amazon EC2). Esta opción le brinda control total sobre la configuración de la infraestructura y el entorno de la base de datos. Ejecutar la base de datos en Amazon EC2 es muy similar a ejecutar la base de datos en su propio servidor. Tu tienes el control  total de la base de datos y tienes acceso a nivel de sistema operativo, por lo que puedes ejecutar agentes de supervisión y administración y usar tu elección de herramientas para la replicación de datos, la copia de seguridad y la restauración. Además, tiene la capacidad de utilizar cada módulo opcional disponible en Oracle Database. Sin embargo, esta opción requiere que se configure, administre y ajuste todos los componentes, incluidas las instancias de Amazon EC2, los volúmenes de almacenamiento, la escalabilidad, las redes y la seguridad, según las mejores prácticas de arquitectura de AWS.


Arquitecturas para seguridad y rendimiento

Ya sea que elijas ejecutar Oracle Database en Amazon RDS o Amazon EC2, la optimización de cada componente de la infraestructura mejorará la seguridad, el rendimiento y la confiabilidad. En las siguientes secciones, analizaremos las mejores prácticas para optimizar la configuración de la red, el tipo de instancia y el almacenamiento de la base de datos en una implementación de Oracle Database en AWS.

Configuración de la red

La nube privada virtual de Amazon (Amazon VPC) le permite aprovisionar una sección aislada lógicamente de la nube de AWS que está dedicada a su cuenta. Tiene control total sobre su entorno de red virtual, incluida la selección de su propio rango de direcciones IP, la creación de subredes y la configuración de tablas de rutas y puertas de enlace de red, y la configuración de seguridad.
Una subred es un rango de direcciones IP en su Amazon VPC. Puede iniciar los recursos de AWS en una subred que seleccione. Utilice una subred pública para recursos que deben estar conectados a Internet, y una subred privada para recursos que no estarán conectados a Internet.
Para proteger los recursos de AWS en cada subred, puede usar varias capas de seguridad, incluidos los grupos de seguridad y las listas de control de acceso a la red (ACL).
La siguiente tabla describe las diferencias básicas entre los grupos de seguridad y las ACL de red.


Amazon VPC proporciona aislamiento, seguridad adicional y la capacidad de separar instancias de Amazon EC2 en subredes, y permite el uso de direcciones IP privadas. Todos estos son importantes en la implementación de la base de datos. Implemente la instancia de Oracle Database en una subred privada y permita que solo los servidores de aplicaciones dentro de Amazon VPC, o un host Bastion dentro de Amazon VPC, accedan a la instancia de la base de datos. Cree grupos de seguridad apropiados que permitan el acceso solo a direcciones IP específicas a través de los puertos designados. Estas recomendaciones se aplican a Oracle Database independientemente de si está utilizando Amazon RDS o Amazon EC2.

Sobre las licencias Oracle

Como se indica en el documento de Oracle en el site My Oracle Support Doc ID: 2174134.1, Oracle es totalmente compatible con la implementación de Oracle Database en AWS. (Si quieres ver el documento, ha de registrarse para obtener una cuenta de Oracle, que es gratuita.) Las licencias de Oracle Database en AWS se basan en el tamaño de la instancia en la que está instalada la base de datos. 
Algunos puntos clave:

  • El recuento de núcleos virtuales de las instancias de Amazon EC2 se considera igual al recuento de núcleos físicos para fines de licencia. Para conocer el recuento de núcleos virtuales de cada tipo de instancia de Amazon EC2, consulte Núcleos virtuales de Amazon EC2 y Tipo de instancia de base de datos de RDS.
  • Oracle Database Standard Edition solo puede tener licencia en instancias de Amazon EC2 que tengan hasta 16 núcleos virtuales.
  • Oracle Standard Edition One y Standard Edition Two solo pueden tener licencia en instancias de Amazon EC2 que tengan hasta 8 núcleos virtuales.
  • Para Oracle Database Standard Edition, Standard Edition One o Standard Edition Two, las instancias de Amazon EC2 con 4 o menos núcleos virtuales se cuentan como un solo socket.
  • Para Oracle Database Enterprise Edition, las instancias de Amazon EC2 con 2 o menos núcleos virtuales se cuentan como un solo socket.

Portabilidad de licencia de Oracle a AWS

Sujeto a los términos y condiciones del acuerdo de licencia específico, las licencias de Oracle pueden ser transferibles a AWS. En otras palabras, sus licencias existentes se pueden transferir para su uso en AWS. Éstas incluyen:

  • Licencias basadas en servidor (basadas en CPU utilizadas)
  • Acuerdos de licencia empresarial (ELA)
  • Acuerdos de licencia ilimitados (ULA)
  • Licencias de Business Process Outsourcing (BPO)
  • Licencias de Oracle PartnerNetwork (OPN)
  • Licencias de User Plus con nombre

Es posible que se apliquen condiciones o limitaciones adicionales (incluidos los posibles costos) para las licencias que se transfieren a AWS. Verifique su contrato de licencia específico para obtener detalles y limitaciones adicionales.

Las licencias de Oracle se aplican de manera similar a Oracle Database en Amazon RDS y en Amazon EC2, con la excepción de que las licencias por hora solo están disponibles en Amazon RDS.

Conclusión

Dependiendo de su escenario de uso, puede utilizar Amazon RDS para Oracle Database o ejecutar una base de datos Oracle autogestionada en Amazon EC2. Independientemente de su elección, seguir las mejores prácticas proporcionadas en este artículo te ayudará a aprovechar tu implementación de Oracle Database en AWS.

miércoles, 15 de noviembre de 2017

Jolokia, una potente especia, para condimentar con Oracle Weblogic


Jolokia es uno de los chiles mas fuertes de planeta y también una utilidad para administrar Oracle Weblogic.

Jolokia es un puente JMX-HTTP que ofrece una alternativa a los conectores JSR-160. Es un enfoque basado en agentes con soporte para muchas plataformas. Además de las operaciones básicas de JMX, mejora la comunicación remota JMX con características exclusivas, como solicitudes masivas y políticas de seguridad detalladas.

Jolokia es un enfoque basado en agentes para el acceso remoto JMX. Es una alternativa a los conectores estándar JSR 160 (). La comunicación entre el cliente y el agente pasa por HTTP (GET o POST), donde la carga útil de solicitud y respuesta se representa en JSON.

El protocolo Jolokia admite las siguientes operaciones:
  • Lectura y escritura de atributos JMX
  • Ejecución de operaciones JMX
  • Búsqueda de nombres MBean por patrón
  • Listado de metadatos MBean como atributos, operaciones y notificaciones compatibles
  • Hasta ahora las notificaciones JMX aún no son compatibles (pero están en la hoja de ruta para una versión futura).

La arquitectura general de Jolokia se muestra en el siguiente diagrama. El agente traduce entre JSON a través de HTTP y llamadas a MBeans locales, incluida una serialización JSON de los valores devueltos.

Este enfoque tiene algunas ventajas:
  • Con la ayuda del agente, Jolokia puede proporcionar servicios que van más allá de la funcionalidad de los conectores JSR-160:

    • Solicitudes masivas que permiten múltiples llamadas JMX en una sola solicitud
    • Seguridad de grano fino con restricción de acceso en el funcionamiento de MBean y nivel de atributo.
    • Fusión de múltiples MBeanServer en una vista virtual, por lo que no es necesario saber con antelación qué MBean está registrado en qué MBeanServer. Con JSR-160 el objetivo MBeanServer debe conocerse con anticipación.
    • Modo de historial para almacenar valores recuperados previamente en un caché en el lado del servidor, junto con un sello de tiempo. Esto es especialmente útil para calcular el cambio de atributos JMX sin necesidad de un almacenamiento de cliente.
    • No se requiere Java en el lado del cliente debido a la naturaleza neutral de plataforma de HTTP y JSON.
    • La serialización JSON permite un acceso profundo a los objetos devueltos sin tener instaladas definiciones de tipos personalizados en el lado del cliente.
  • Dado que HTTP usa un solo puerto predefinido, esta configuración funciona muy bien con la configuración del firewall. El conector predeterminado JSR-160, por el contrario, no es tan inteligente ya que RMI usa un puerto aleatorio para su comunicación por defecto.
  • Por paradoja que pueda parecer, configurar un agente es a menudo más fácil que configurar la exportación JSR-160 JMX, especialmente cuando se trata de seguridad. Normalmente, para JSR-160, se deben adaptar los archivos de inicio de exportación y la configuración del servidor de aplicaciones. El agente estándar se implementa como una aplicación web normal, que es un procedimiento bien conocido.

La única desventaja de este modo es que se debe instalar un agente. Esto puede deberse a razones de política por la que no se permite instalar ninguna aplicación externa. O todos los servidores a monitorear ya están preparados para la exportación JSR-160 JMX, por lo que un paso de instalación adicional no es bienvenido. Además, actualizar Jolokia normalmente implica una redistribución del agente. 


Estas son todas buenas razones, por lo que Jolokia también tiene una respuesta. Al instalar un servidor JEE dedicado con un agente implementado, Jolokia puede operar en modo proxy, en cuyo caso traduce la solicitud de JOLOKIA JSON a la solicitud del cliente JSR-160 para la operación en el servidor de destino. Viceversa, el resultado sobre un conector JSR-160 luego se traduce en una respuesta JSON que se devuelve al cliente Jolokia.

Ejemplo

Para tener una idea de cómo es el protocolo de Jolokia, aquí hay un ejemplo de una simple solicitud y respuesta de Jolokia. Suponiendo que un agente está instalado, la siguiente solicitud HTTP GET lee las estadísticas de la memoria de montón utilizada de la JVM instrumentada:
 http://localhost:8080/jolokia/read/java.lang:type=Memory/HeapMemoryUsage
http: // localhost: 8080 / jolokia es la URL base bajo la cual se puede acceder al agente. La misma solicitud se puede realizar al enviar el siguiente cuerpo a la URL http: // localhost: 8080 / jolokia:
  {
    "mbean":"java.lang:type=Memory",
    "attribute":"HeapMemoryUsage",
    "type":"READ"
  }
En ambos casos, la respuesta contiene un objeto JSON:
 {
    "timestamp":1285531108,
    "status":200,
    "request": {
                 "mbean":"java.lang:type=Memory",
                 "attribute":"HeapMemoryUsage",
                 "type":"read"
               }, 
     "value": {
                "max":"129957888",
                "committed":"85000192",
                "init":"0",
                "used":"7713440"
              }
  }

Gestión RESTful de WebLogic con Jolokia


La administración y el monitoreo de los recursos de WebLogic es el pan de caa día para muchos administradores. La programación de una solución de gestión mediante la escritura de código JMX en Java es un proceso de bajo nivel y lento que puede evitarse utilizando la herramienta de scripts WebLogic basada en Jython (WLST).

WLST es un lenguaje de dominio específico de nivel superior (DSL) especialmente desarrollado para abordar problemas de gestión. Algunas líneas de código WLST suelen encapsular cientos de líneas de código Java utilizando JMX. Aunque WLST es compacto y fácil de escribir, aún adolece de la "J" en JMX: cada vez que ejecuta un script WLST para monitorear algún atributo en el servidor de aplicaciones, debe iniciarse una JVM en el lado del cliente para WLST. Esta sobrecarga puede ser bastante importante si está monitoreando muchos servidores y recuperando atributos a intervalos regulares. En particular, para sistemas de monitoreo como Nagios (o el Shinken más nuevo), el enfoque WLST no es adecuado.


Una de las nuevas características distintivas de WebLogic 12c es su servicio de administración RESTful, que se puede habilitar con un simple clic en DOMAIN / Configuration / General / Advanced / Enable RESTful Management Services  seguido de un reinicio del servidor.

Una vez habilitado, puede acceder a los valores de tiempo de ejecución de WebLogic 12c más importantes utilizando una sintaxis de URL simple de su navegador web o una herramienta de línea de comandos de Unix, como curl. Por ejemplo, puede recuperar datos de tiempo de ejecución del servidor de administración con una solicitud HTTP rápida en lugar de generar un proceso de JVM para WLST:

  • http://localhost:7001/management/tenant-monitoring/servers/AdminServer/



Instalación
El proceso de instalación está bien descrito en el sitio de Jolokia. Simplemente puede obtener el archivo jolokia.war del sitio de descarga de Jolokia o el repositorio central de Maven, no se necesita nada más para WebLogic.

Incluso es posible usarlo sin ninguna implementación en absoluto. Comenzando con JDK6, puede ejecutarlo como un agente JVM, una técnica que se usa típicamente para los perfiladores, etc. Por lo tanto, su llamada java que inicia WebLogic tiene el siguiente formato:

java -javaagent:agent.jar ...

Si desea instalar todo el proyecto Jolokia (incluido el shell JMX que se describe más adelante, el complemento Nagios, un complemento Spring Roo, etc.) en un sistema UNIX con Perl y CPAN ya instalados, puede ser tan fácil como:

[root@ccloud ~]# perl -MCPAN -e shell cpan shell -- CPAN exploration and modules installation (v1.9800)
cpan[1]&gt; install JMX:Jmx4Perl
[... you have to confirm the installation of several dependencies ...]

Comparación de funciones: Jolokia y WebLogic 12c RESTful Management Service


Ahora, ¿cómo se compara Jolokia con lo que ya tiene listo en la WebLogic 12c? Aquí hay una breve descripción:


La URL GET para una solicitud de lectura Jolokia tiene el siguiente formato:

&lt;base-url&gt;/read/&lt;<a title="MBean Object Name" href="http://docs.oracle.com/javase/6/docs/api/javax/management/ObjectName.html">mbean name</a>&gt;/&lt;attribute name&gt;/&lt;inner path&gt;

Para comenzar, simplemente pegue la siguiente URL en su navegador o use el curl de la utilidad de línea de comandos de Unix (suponiendo que tiene el servidor de administración ejecutándose en localhost: 7001). Recuperará los atributos configurados de ListenPort:

[JavaScript]
{ "request" : { "attribute" : "ListenPort",
      "mbean" : "com.bea:Type=Server,*",
      "type" : "read"
    },
  "status" : 200,
  "timestamp" : 1334776908,
  "value" : { "com.bea:Name=AdminServer,Type=Server" : { "ListenPort" : 7001 },
      "com.bea:Name=surf1,Type=Server" : { "ListenPort" : 7003 },
      "com.bea:Name=surf2,Type=Server" : { "ListenPort" : 7005 },
      "com.bea:Name=surf3,Type=Server" : { "ListenPort" : 7007 }
    }
}
[/JavaScript]

La respuesta se mostrará en una sola línea. Para obtener el formato anterior, puede pasar el resultado a uno de los muchos formateadores JSON en línea (o canalizar la salida curl a una utilidad adecuada).