Apuntes de Java

¿Quieres implementar un servidor RESTful sin usar GlassFish, JBoss, Tomcat, Wildfly, Payara, Jetty, WebLogic ni nada parecido? ¿y en Java sin usar Node.js? Bueno, aquí les comparto una manera de montar de montar un servidor RESTful usando Jersey pero ejecutable desde la línea de comandos.

Liferay viene con servicios RESTful llamados " Servicios Web JSON ", porque utiliza el formato JSON. En este post voy a compartir una manera de consumir desde Jersey para acceder a sus datos.

Los WebSockets son una manera de poder comunicarse vía web entre un cliente y un servidor. A diferencia con otras tecnologías parecidas como los RESTful WebService, es que esta tecnología es bidireccional. El RESTful tiene que constantemente pedir al servidor para ver si hay un cambio, y con algunas técnicas "push" se puede simular una comunicación bidireccional. Con WebSockets, la comunicación es nativa. Ya que estamos cerca del lanzamiento de Java EE 7 implementado en GlassFish 4.0, veremos un pequeño esbozo de esta tecnología.

Este es un post pequeño, y quizás un poco fastidiado por algo que encontré en esta nueva versión de Liferay 6.1 GA2 (es decir, la 6.1.1) Para crear un JSON WebService, basta con crear un Service en el Portlet y ya está publicado. (Leer aquí  http://www.liferay.com/community/wiki/-/wiki/Main/JSON+Web+Services ) Si usamos Tomcat, no existe ningún problema. Es más, podemos ver el API WebService en una web para hacer las pruebas desde la misma web. Por ejemplo: si creamos un portlet llamado "Test-portlet" y creamos un servicio llamado "Calc", podemos entrar a http://localhost:8080/Test-portlet/api/jsonws y vemos todo el API. Pero... si usamos el GlassFish, no aparecerá la página. Según la gente de LR, cada contenedor tiene manera diferente de reconocer su contexto. Me consta: depuré el código fuente, y desde GlassFish devuelve el contexto "null" mientras que con tomcat devuelve el contexto (o sea, Test-portlet) Y la salida que me dan es llamar a un URL c

@Mick Knutson publica su libro " Java EE 6 Cookbook for Securing, Tuning, and Extending Enterprise Applications " donde se muestra, de manera general y concisa, los aspectos de seguridad, rendimiento y mejorar las aplicaciones Java EE 6. Aquí, mis comentarios del libro.

Seguimos con RESTful en Java! Ya luego comentaré qué pasó conmigo y por qué no estuve enviando contenido a mi blog. Hasta el momento hemos visto casi de manera abstracta el funcionamiento de RESTful  usando Jersey desde NetBeans . Ahora veremos como probar todo un CRUD de RESTful desde un complemento de Firefox llamado Poster .

Quienes hayan usado SOAP para WebService, sabrán que es bien fácil de diseñar, pero algo complicado de consumir: se necesita toda una API para construir los clientes utilizando el WSDL. Por ejemplo, para PHP se necesita de la biblioteca NuSOAP. Entonces, para lograr el concepto de "lenguaje único XML" es un dolor de cabeza. Y más aún si el cliente es tan simple como JavaScript, manejar XML de SOAP provocaría suicidos masivos... o no usar WebServices. Además, con SOAP se permite crear un solo servicio y ponerle varios métodos. Esto puede llevar a un mal diseño del servicio ya que podría tener un servicio que haga de todo: por ejemplo, un servicio de manejo de Clientes que permita también manejar Proveedores. RESTful es una propuesta muy interesante de Roy Fielding que permite manejar los servicios web con métodos definidos, manteniendo la simpleza del protocolo como XML, pero que cada servicio sea identificado únicamente con un solo URI . En este post veremos cómo cr

Volviendo con mis vídeos tutoriales, aquí presento cómo hacer un servicio RESTful desde NetBeans 6.9.

El escenario es el siguiente: Tienes un módulo EJB que consume un WebService, ya sea desde otro proyecto local o desde un WSDL externo al proyecto. Y tienes una aplicación web que utiliza el módulo EJB. Cuando despliegas el EJB, no hay problemas, pero cuando despliegas el módulo web, no sale nada y lanza un error: wsdl file META-INF/wsdl/client/......wsdl does not exist for service-ref... Dirás (como yo dije) "pero si compila!!!".. y pensarás "y si consumo el WS dentro del modulo web?". y te negarás porque eso rompería el esquema que pensabas... bueno... alguien también le pasó y también encontró la solución. Nada más hay que revisar el código que crea NetBeans en el EJB cuando consume un WebService: @WebServiceRef(wsdlLocation = "META-INF/wsdl/client/ProductsList/localhost_8084/ProductsListService/ProductsList.wsdl") private ProductsListService service; El EJB lo consume normalemente, porque el WSDL está dentro del mismo proyecto EJB. Cuando es llamado d

(Traducción no oficial de Getting Started with RESTful Web Services ) REpresentational State Transfer (REST) es un estilo de arquitectura para sistemas hipermedia distribuidos, tales como la World Wide Web. El centro de la arquitectura RESTful es el contecpto de los recursos identificados por los identificadores de recursos universal (universal resource identifiers URIs). Estos recursos pueden ser manipulados usando un interfaz estándar, tales como el HTTP, y la información es intercambiada usando representaciones de estos recursos. En este tutorial, primero aprenderemos un poco acerca de REST y luego veremos como NetBeans 6.1 maneja este estilo de arquitectura. Introducción Los servicios web RESTful son servicios construidos usando el estilo de arquitectura RESTful. El construir servicios web usando RESTful hace que se aproxime a una alternativa emergencia y popular usando tecnologías basadas en SOAP para desplegar servicios en internet, debido a que es liviando y tiene la capacida