Consumir un Web Service hecho en Java desde .Net

La interoperabilidad entre diferentes plataformas de desarrollo es, cada vez más, un hecho. Aunque no es nueva, la arquitectura orientada a servicios (SOA) es parte de ese planteamiento. Voy a exponer en este artículo lo sencillo que resulta integrar la plataforma .Net con Java a través de un servicio web construido en esta última. Aplica en diversos escenarios, como por ejemplo, casos en los que gran parte de la lógica se encuentra en aplicaciones Java ya desarrolladas que se intentan o pretenden migrar a .Net o en casos de clientes delgados que corran bajo plataformas Windows contra servidores con otros sistemas operativos. Es decir, nos sobran los motivos.

Prerrequisitos

Vamos a trabajar este ejemplo con las siguientes herramientas:

• NetBeans JDK 6.7.1. Puede descargarlo aquí.
• Java SE JDK. Puede descargarlo aquí.
• Visual Studio 2008 Service Pack 1. Puede descargar un trial aquí.

Creando un servicio web en Java con NetBeans

En primer lugar crearemos el servicio web en Java. Para hacerlo, en NetBeans haremos clic en Archivo –> Proyecto nuevo, después de lo cual aparecerá el siguiente diálogo:

Allí seleccionaremos la categoría Java Web y a continuación Web Application. Haremos clic en Siguiente. Viene el segundo paso del asistente: definiremos el nombre de nuestra aplicación y la ubicación, entre otros aspectos. En este ejemplo, nuestra aplicación llevará por nombre DiferenciaHoraria:

Clic en Siguiente. En el siguiente paso escogeremos el servidor y la versión específica de Java EE. En este caso usaremos GlassFish v2.1 y Java EE 5, respectivamente:

Clic en Terminar. NetBeans nos creará a nosotros un proyecto con una estructura similar a la que vemos en la siguiente imagen:

A continuación sobre nuestra aplicación web haremos clic derecho y del menú contextual seleccionaremos Nuevo –> Web service, como se muestra en la siguiente imagen:

En el cuadro de diálogo resultante asignaremos un nombre a la clase contenedora del servicio y un paquete:

Clic en Terminar. Reemplazaremos el código de nuestro servicio web con el siguiente:

 

package miempresa.misolucion.misservicios;

import javax.jws.WebService;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import java.util.*;

@WebService()
public class DiferenciasHorarias {
    
    @WebMethod
    public float CalcularDiferenciaEnHoras(@WebParam(name="hora")int prmHora, 
                                           @WebParam(name="minutos") int prmMinuto)
    {
        float horaRecibida = prmHora + (prmMinuto / 100);
        
        Calendar calendario = new GregorianCalendar();
        int horas = calendario.get(Calendar.HOUR_OF_DAY);
        int minutos = calendario.get(Calendar.MINUTE);
        
        float horaActual = horas + (minutos / 100); 
        
        float resultado = horaRecibida - horaActual;
        
        return resultado;
    }

}

Procederemos a hacer el deploy del servicio web. Para ello hacemos clic derecho en la aplicación y seleccionamos la opción Deploy.

Luego ejecutaremos en prueba nuestro web service:

 

De la ventana del navegador que se despliega tomaremos la ruta así: http://localhost:8080/DiferenciaHoraria/DiferenciasHorariasService, sin el sufijo ?Tester.

 

Creando el cliente en .Net

Como este blog está orientado al desarrollo en .Net asumiré que sabemos crear una aplicación de consola por lo que iré omitiendo cosas:

Esta aplicación se llamará ClienteDiferenciaHoraria. Lo que haremos a continuación será establecer la conexión con el servicio web. Para ello agregaremos una nueva referencia de servicio como se ve en la siguiente imagen (para acceder a este menú haremos clic derecho sobre el proyecto):

En el cuadro de diálogo desplegado escribiremos la ruta del servicio (tomada anteriormente del navegador después de la puesta en prueba) y agregaremos el sufijo ?wsdl. Haremos clic en Ir y asignaremos un nombre a la referencia (en este caso DiferenciasHorariasServiceReference):

Visual Studio generará un cliente para el servicio web, como podemos ver en el explorador de objetos:

Finalmente haremos, desde nuestro código .Net, el llamado al servicio así:

static void Main(string[] args)
{
    DiferenciasHorariasClient proxy = new DiferenciasHorariasClient();

    float resultado =
        proxy.CalcularDiferenciaEnHoras(21, 37);

    Console.WriteLine("La diferencia es: {0}", resultado.ToString());
    Console.ReadLine();
}

Ejecutaremos nuestra aplicación y veremos el resultado de la integración entre estas dos plataformas de desarrollo. Espero que sea útil para alguien.

El código usado aquí es meramente ilustrativo y no se trata de una solución real.

ASP.NET Dynamic Data, un vistazo

Introducción

En medio de las expectativas que ha generado el framework ASP.NET MVC y la disyuntiva que supone frente al tradicional ASP.NET (modelo WebForms), y que hemos discutido ya en otra entrada, ha pasado desapercibido, desde mi punto de vista, el framework ASP.NET Dynamic Data.

¿Qué es? Podemos describirlo escuetamente como un framework que permite construir aplicaciones web funcionales fuertemente orientadas a datos basadas en modelos de datos creados en LINQ to SQL ó Entity Framework. Esto incluye mejoras en la integración entre los tradicionales controles de datos y dichos modelos, en términos de validación de datos y uso de plantillas para representar el CRUD. Para hablar en el contexto de las nuevas tendencias en el desarrollo web: se trata de un poderoso framework de Scaffolding (para quien sea nuevo este término lo podemos resumir como la técnica implementada por diferentes frameworks para, automáticamente, generar la funcionalidad CRUD de una aplicación web basada en una base de datos y metadatos que la describen).

¿Cómo tenerlo?

ASP.NET DD viene incluido en el release Service Pack 1 del Framework de .NET. Para asistir el proceso desde Visual Studio se necesita tener instalada la versión 2008 con SP1. Si se trata de Visual Web Developer Express, se necesita la versión 2008 con SP1.

Primeros pasos

Una vez tengo los prerrequisitos instalados puedo crear mi primera aplicación Dynamic Data. Usaré para esta serie de artículos sobre Dynamic Data un pequeño modelo de datos para una aplicación de Help Desk. Adjunto en esta entrada el script para crear dicho modelo en SQL Server 2005 Express.

Lo primero que debo hacer es crear el nuevo Website escogiendo la plantilla adecuada:

Esto generará una solución de tipo Dynamic Data Website. La estructura de archivos de este tipo de soluciones tiene varias particularidades, pero la principal es la creación de la carpeta DynamicData, como se ve en la siguiente imagen:

Esta carpeta está compuesta por las subcarpetas:

• Content, que trae por defecto las imágenes de navegación entre listas paginadas y dos controles de usuario: GridViewPager, con la lógica para recorrer grillas paginadas y FilterUserControl, que se usará para establecer filtros en las páginas de listas de entidades (entidad/List.aspx).
• FieldTemplates, que contendrá controles de usuario por defecto para la edición de los campos de una entidad.
• PageTemplates, que contiene las plantillas para las páginas que intervienen en el CRUD de cada entidad: Details, Edit, List, Insert, ListDetails.
• CustomPages, donde ubicaremos las páginas que creemos con comportamiento diferente al preestablecido para las entidades en las que necesitemos que sea así.

Demos un vistazo a dos de las subcarpetas:

 

 

 

 

 

 

 

 

 

Aquí podemos apreciar el contenido por defecto de las carpetas FieldTemplates y PageTemplates. Como decía unas líneas atrás: se trata de las plantillas que se implementarán para cada entidad y sus campos en los diferentes escenarios de uso. Es importante decir que estas plantillas pueden ser modificadas para añadir la funcionalidad a nuestro gusto o necesidad (tema de una futura entrada) por tanto no estamos, necesariamente, obligados a usarlas para nuestro sitio Dynamic Data. Sin embargo, son lo bastante útiles como para usarlas en la mayoría de los casos y sirven también como ejemplo de buenas prácticas de desarrollo. También es importante añadir que contamos con un archivo Site.css en el que podremos personalizar la apariencia del sitio.

Otro elemento de vital importancia para DD en nuestra solución es el archivo Global.asax, puesto que allí se encuentra parte de la lógica usada para el Scaffolding.

Lo siguiente que haremos será general el modelo de datos de la aplicación; en este caso usaremos LINQ to SQL como ORM de la aplicación. Omitiré los pasos para crear el modelo y muestro a continuación el resultado:

Una vez tengo el modelo entro a mi archivo Global.asax y busco la línea que registra el contexto de datos y reemplazo el valor YourDataContextType por el nombre del DataContext de mi modelo LINQ to SQL, que en el caso del proyecto de ejemplo es HelpDeskDataContext:

model.RegisterContext
   (typeof(HelpDeskDataContext), 
   new ContextConfiguration()
   { ScaffoldAllTables = true });

Por defecto esta línea de código viene comentada y trae también asignado un valor false para la asignación de ScaffoldAllTables. Yo he habilitado la línea de código y he puesto true a ScaffoldAllTables, esto último para habilitar al framework a que genere la funcionalidad CRUD a todas las tablas del sistema; en caso de no querer hacerlo debería dejar el valor por defecto (false) y proceder a parcializar las clases del modelo a las que deseo generarles la funcionalidad completa anteponiendo a la declaración de la clase el atributo [Scaffold(true)]. Esto lo haremos en una futura entrada. Por ahora y con lo hecho hasta este punto podemos contar con una aplicación web con toda la funcionalidad de acceso a datos, en este caso para la base de datos que nos interesa.

Ejecutaremos la aplicación y nos encontraremos con una página inicial listando las entidades a las que se les hizo Scaffolding. De ahí en más, a explorar cada entidad y la funcionalidad generada. Esta configuración por defecto puede ser modificada.

Finalmente decir que el Scaffolding generado presenta problemas a la hora de insertar entidades con llaves primarias autonuméricas en tipos de datos byte y short.

Obtenga la solución de esta entrada aquí.

Obtenga el script de la base de datos de ejemplo aquí.

¿ASP.NET MVC ó WebForms?

Siguiendo con la línea editorial del artículo pasado me propongo en esta ocasión analizar las diferencias entre las dos opciones estelares de la plataforma .net para el desarrollo web: asp.net mvc y WebForms.

WebForms

Podríamos decir con respecto a WebForms que se trata de la simulación para la web de la visión de Rapid Application Development sostenida por Microsoft, puntualmente, de su visión del desarrollo de aplicaciones para sus sistemas operativos. Por tanto MS intentó minimizar el impacto y la curva de aprendizaje de los desarrolladores acostumbrados a trabajar en ambientes de escritorio mediante WebForms. Digamos que con WebForms se lograron cosas interesantes desde mi punto de vista y que supusieron una victoria (aunque ahora desde la luz del TDD y MVC parezcan derrotas), una de ellas, por ejemplo, el concepto de CodeBehind que permitía separar las etiquetas asp de la clase que las manejarían. Entonces ocurre con WebForms que manejo el desarrollo de mis páginas web orientado a eventos y se introducen dos conceptos importantes: el ViewState y el Postback, necesarios para que dicho modelo funcione. Todo eso que parecería una ventaja, para algunas situaciones empezó a convertirse en un problema y a medida que nuestros desarrollos crecían también el volumen de datos que debido al ViewState debía viajar en cada solicitud o respuesta hacia y desde el servidor se hacía considerable impactando el performance de la aplicación. Adicionalmente, en la medida en que iban ganando mercado otros navegadores la compatibilidad con los mismos se veía comprometida puesto que, reconozcámoslo, la emisión de html de los controles de servidor de WebForms no respeta cabalmente los estándares. Otro aspecto que debía considerarse es el hecho de que las urls creadas por este modelo de desarrollo estaban orientadas a archivos con extensiones por lo tanto la optimización para motores de búsqueda era precaria. Y un largo etcétera, como que se hacía prácticamente imposible el testeo de unidades de UI o que los desarrolladores se abstraían tanto de la implementación del HTTP que se acostumbraban a que la web tuviera estado, cuando lo natural es que no. En fin…

ASP.NET MVC

Y llega ASP.NET MVC. No voy a ahondar en el hecho de que es una implementación del Modelo-Vista-Controlador y lo que ello significa, no. Haré más bien un resumen de los puntos fuertes frente al modelo de desarrollo de WebForms. Empecemos por decir que se vuelve al concepto de la web sin estado por tanto las idas y vueltas al servidor son mucho más descongestionadas. Adicionalmente se reemplazan los eventos por acciones de controlador asociadas a los tradicionales verbos del HTTP (GET, POST, PUT, DELETE) y se logra una separación de conceptos que facilita el TDD. En la capa de la vista se usan plantillas Html lo que asegura en gran medida que se respetarán los estándares y se atenderán de manera óptima diversos navegadores, así como que se tenga mayor compatibilidad con Ajax como concepto. Otro aspecto importante es que las urls vuelven a estar basadas en recursos permitiendo optimizaciones para motores de búsqueda. Y otro largo etcétera que no es más que el hecho de volver a las bases del desarrollo web con un potente framework de fondo para la atención de tareas de propósito general. Como desventajas están el hecho de que los controles de UI vuelven a hacerse medianamente básicos y que el desarrollo se dilata un poco puesto que ya no se trata de arrastrar y soltar ni del tradicional desarrollo-orientado-a-clics de las herramientas MS. En ese sentido debemos ser justos y reconocer que los HtmlHelpers minimizarán ese impacto – tanto más cuando hay unos bastante interesantes en la primera versión del framework mvc – y que Visual Studio sigue siendo una herramienta sumamente potente en términos de minimizar los esfuerzos de desarrollo (aquí me permito hacer un reclamo y es el hecho de que la edición express de VWD actual no lo es tanto para asp.net mvc; espero que la edición 2010 sí lo sea).

Conclusiones

Lo anterior no significa que WebForms esté condenado a desaparecer, no. Ni mucho menos. MS ha sido claro en que seguirá brindando soporte, investigación y desarrollo a ambas opciones de manera paralela. A lo que se debe enfrentar el desarrollador actualmente es a la decisión de cuál usar en sus nuevos proyectos (o incluso si incorpora mvc a los anteriores puesto que pueden coexistir en el mismo proyecto). Yo basaría esa decisión en lo siguiente:

• Si se trata de una aplicación corporativa (intranet o web) en la que la orientación a datos es fuerte (todas esas grillas de datos y sus facilidades) y los tiempos de respuesta no son el primer factor a tener en cuenta (hablábamos con Yeison García hace poco que en este tipo de aplicaciones los tiempos de respuesta no son un factor fundamental) yo recomiendo usar WebForms por varias cosas: el conjunto de controles UI y de componentes (bendito seas ObjectDataSource) es mucho más amplio, los tiempos de desarrollo se minimizan y los resultados pueden considerarse más estructurados.
• Si se trata de una aplicación web en todo su esplendor de propósito general y orientada a atender usuarios de diverso calibre – lo que es la web 2.0 –, abiertas al público recomiendo ASP.NET MVC. También si se trata de proyectos basados en metodologías como agile en los que la orientación del desarrollo es al testeo recomiendo ASP.NET MVC.

Prácticamente el principal factor a tener en cuenta es si la aplicación está orientada a atender el público en general o es de carácter privado. Ya lo demás son concepciones del desarrollo web.

¿Linq to Sql ó Entity Framework?

Se me ha preguntado recientemente bajo qué criterios debía tomarse la decisión de usar EF o LINQ2SQL y haré aquí un resumen de los que considero debían tenerse en cuenta:

En primer lugar debo decir que tengo la impresión de que el proyecto Linq to Sql, a pesar de ser una consecuencia esperable en términos de niveles de abstracción, fue desarrollado como un mientras-lanzamos-EF. Eso no hace que haya sido una mala herramienta y, casi que por el contrario, ha opacado en algunos escenarios al mismo EF. Si analizamos un poco el estado del arte del desarrollo web, lenguajes y frameworks ligeros como Ruby on Rails han devenido adicionalmente en ORM’s ligeros y allí tenemos en L2S un claro ejemplo. Así las cosas, L2S está orientado al desarrollo rápido de aplicaciones conectadas a datos en arquitecturas web o de escritorio. Hace sumamente sencillo el acceso a datos en gran parte por la naturaleza misma de Linq y su similitud con el Sql.

Con Entity Framework sucede que está orientado a la construcción de aplicaciones corporativas en las que el nivel de abstracción del lenguaje de los desarrolladores sea un factor clave. Por ejemplo, permite el mapeo de una clase a diferentes tablas así como usar elementos propios de la programación orientada a objetos tales como la herencia y el polimorfismo. Esto no en todos los casos es una ventaja puesto que tiende a hacer más complejas las situaciones que representa y deriva en olvidar los objetos POCO que tan cómodos suelen resultarnos, aunque sobre esto se haya prometido que en la versión 4.0 del framework se permitirá la compatibilidad entre clases sencillas de un modelo de negocios y EF.

Dicho lo anterior, yo usaría estas listas de chequeo para determinar si uso el uno o el otro:

¿Cuándo EF?

• Cuando se trata de una aplicación que puede estar conectada a fuentes de datos de diferentes proveedores. Sobre esto EF lleva un poco la ventaja puesto que los proveedores de acceso a datos de terceros tardan menos en aparecer e incluso MS ofrece uno para Oracle. L2S está prácticamente destinado a trabajar con SQL Server.
• Cuando se necesita un lenguaje de abstracción más cercano a la lógica de negocio. El nivel de abstracción de EF así como su capa de Object Services es mucho más amplia y está orientada a no ser simplemente un ORM sino todo un lenguaje conceptual a la hora de desarrollar aplicaciones conectadas a datos.
• Cuando se estima que la aplicación sea escalable y de largo desarrollo en el tiempo. La lógica que se puede derivar de aplicaciones sobre EF es mucho más flexible por lo que se puede extender y escalar fácilmente a medida que el proyecto de software crece.

¿Cuándo L2S?

• Cuando se desarrolla una aplicación de nivel medio y pequeño. Resulta muy cómodo cuando se habla de aplicaciones en Asp.net mvc y casi que se asume como el ORM especial para este framework de desarrollo web. Pero prácticamente en cada escenario en el que el desarrollo esté orientado a datos y sea pequeño o mediano L2S, es una excelente solución pues se tiende a escribir menos código que con EF.
• Cuando se trata de una aplicación que tendrá por back-end un único proveedor de bases de datos. Y ojálá este sea Sql Server. Se han ido desarrollando por terceros proveedores L2S para bases de datos de terceros pero aún se encuentran en fases de desarrollo tempranas.
• Los niveles de abstracción que se usan en la aplicación están casi destinados a coincidir con la persistencia de datos. Aquí es donde L2S, al ser un ORM en sí, lleva la ventaja sobre EF y donde más podemos notar una solución sencilla a la disparidad entre POO y modelo relacional.

En conclusión se habrá notado que tiendo a recomendar EF cuando se trata de aplicaciones corporativas, robustas, escalables y de un alto rigor en la representación de la lógica de negocio. Y L2S me parece una herramienta ideal cuando se trata de aplicaciones de tamaño pequeño y hasta mediano. Esto no significa que no se puedan invertir los escenarios de uso, no, pero quizás sí significa que de hacerlo se subutilicen o sean insuficientes los recursos de uno y otro. Para el framework 4.0 se esperan mejoras importantes en ambos y será necesario entonces revisar estas consideraciones. Quizás se vuelva una cuestión de gustos, simplemente.

Por ahora considero como un excelente término medio Linq to Entities, aunque EF se baste y se sobre por sí mismo.

Tiramisú de limón

El videoclip oficial. Sin palabras:

Sobre algunas de mis posiciones…

Me referiré puntualmente a mis posiciones en la industria del software. Es que hace días vengo siendo recriminado por mis preferencias a la hora de desarrollar software. Específicamente, mi preferencia por .net. Me permitiré aquí, aunque no deba, pronunciarme al respecto:

El open source y yo

Que vuelvo y digo: no tengo nada contra el open source; considero que existen al respecto grandes y respetables iniciativas, frecuentemente uso algunas de sus aplicaciones y donaría alguna vez un poco de dinero (que no me sobra) a alguna fundación de software libre. Y me parece genial que una persona o un grupo de personas decidan compartir sus desarrollos con el resto del mundo, permitir su distribución, su modificación, su loquesea. Pero no depreco de quien decida no hacerlo y me considero en el legítimo derecho de usar, producir y comercializar software privativo. Que me sostengo a mí mismo.

Microsoft y su comportamiento comercial

Sí, también considero que algunas de las prácticas llevadas a cabo por MS en el pasado dejan mucho que desear, por decir lo menos. Pese a eso uso muchos de sus productos. También tomo cocacola. Con lo que no estoy de acuerdo es con que lo desarrollado por MS sea tildado de malo sólo por pasión, que mucho me temo que es lo que pasa casi siempre, todo ese FUD, esas especulaciones, esa verborrea traída de los pelos de los detractores de MS; mucho me temo que los detractores de MS lo son comercialmente y parten de ello para, de plano, calificar de malomalomalomuymalo lo que tenga su sello. No todo lo que desarrollan es bueno, sí, lo reconozco (a mí me pasa a veces) pero tienen productos francamente buenos. Y mi relación con MS es comercial, me produce dinero el hacer una aplicación con sus herramientas, conocerlas, enseñarlas. Y de eso no me quejo.

.Net

Me encanta .net. Disfruto desarrollando en esta plataforma y me parece que es de las mejores del mercado. Yo también tuve 20 años y dije lo que dicen los románticos del open source pero, vamos, estaba estudiando. Tenía patrocinio. Ahora quiero hacerme a unos pesos y me encontré con que .net me facilitaba cantidades ganarme el pan de cada día, al menos tres veces al día.  Y repito: me encanta. ¿Que no es multiplataforma? Puf! me interesa poco, no quiero hacer aplicaciones para el 5% del mercado. Quiero hacer aplicaciones para el grueso de los consumidores de tecnología y ahí están los Windows. Y cuando Linux y todos sus tututus hagan suficiente ruido echaré mano de lo que haga falta para volver a hacerme los pesos de los tres panes del día. Entre tanto, repito, .net me encanta.

¿Java?

Ah! claro, también me encanta. Me parece que J2EE es de las cosas más serias del mundo. Y lo uso y lo usaré cuando pueda y deba (cuando alguien de ese segmento cincoporciento* me pague lo suficiente). Y claro, estimulo su uso, respeto su uso y me quito el sombrero cada que deba: ante la dignidad y la belleza.

¿Php?

Yo tenía un perro que se llamaba Pascal.

Los anteriores son argumentos meramente emocionales. Para los argumentos técnicos tengo pocas ganas hoy. Vendrán…