Creando servicios web convergentes con el WebSphere Application Server

La convergencia de las telecomunicaciones con la World Wide Web es la principal fuerza motora detrás del desarrollo de muchas aplicaciones nuevas e interesantes. Las líneas entre estos mundos tradicionalmente aislados se están desvaneciendo debido a protocolos desarrollados en IEFT como el SIP, y a nuevos modelos de programación como el JSR 289, que permiten a las aplicaciones controlar simultáneamente las señales entre estos dos mundos. Mediante una aplicación de muestra, este artículo ilustra cómo desarrollar un servicio web convergente usando el® WebSphere® Application Server de IBM. This content is part of the IBM WebSphere Developer Technical Journal.

Dustin Amrhein, IBM MobileFirst Solution Architect, IBM

Author photoDustin Amrhein is a MobileFirst Solution Architect at IBM. In this role he helps clients to evaluate, design, and adopt solutions that support their enterprise mobility strategy. Dustin started with IBM as a developer for WebSphere Application Server where he worked primarily on Web and REST services runtimes. While in the development lab, Dustin also worked on cloud computing and web communication technologies.


Nivel de autor profesional en developerWorks

Brian Pulito, WebSphere Architect - SIP, IBM

Brian Pulito is the lead SIP and CEA Architect for WebSphere. He was one of the lead developers of the WebSphere CEA system application and has helped design, develop and support numerous SIP based products including Sametime and WebSphere. Brian is one of the leading advocates for SIP based technologies within IBM and has worked with many customers to help bring their SIP based applications into production.



08-08-2011

Introducción

La convergencia de SIP y HTTP está alentando al desarrollo de todo tipo de nuevas capacidades, incluyendo aplicaciones Web y móviles que contienen ricos atributos de comunicaciones como hacer clic para llamar, supervisión de presencia y control de llamadas de terceros. Esto también está teniendo impacto en muchas industrias diferentes, permitiendo el desarrollo de todo tipo de nuevos recursos y servicios (Figura 1).

Figura 1. Nuevos recursos de comunicaciones de las aplicaciones convergentes
Nuevos recursos de comunicaciones de las aplicaciones convergentes

La especificación SIP servlet más reciente, conocida como JSR 289, ha dado pasos acelerados para estandarizar el modelo de programación necesario para el desarrollo de aplicaciones Web SIP/HTTP verdaderamente convergentes. El WebSphere Application Server de IBM inicialmente publicó el contenedor SIP que cumple con la JSR 289, en la forma del Feature Pack para Communications Enabled Applications (CEA).

Adicionalmente al desarrollo de aplicaciones convergentes, el modelo de programación JSR 289 permite el desarrollo de servicios web convergentes. Una interfaz basada en WSDL proporciona acceso al servicio web convergente vía SOAP sobre HTTP, y el SIP se utiliza en el backend.

Este artículo proporciona detalles sobre cómo desarrollar un servicio web convergente. Específicamente, la muestra de servicio web convergente descrita en este artículo proporciona una interfaz para suscribir a una entidad de presencia y para recibir notificaciones cuando los atributos asociados con esa entidad de presencia cambien. En backend, la aplicación de muestra convierte la solicitud de servicio web en una suscripción SIP enviada a un servidor de presencia SIP.

El servicio web convergente descrito en este artículo demuestra muchas capacidades del contenedor del WebSphere Application Server, incluyendo:

  • Conversión de una solicitud de servicio web en una suscripción SIP.
  • Establecimiento de afinidad de sesión de aplicación SIP mediante un servicio web.
  • Desarrollo de un servicio web bi-direccional necesario para recibir notificaciones asíncronas.
  • Programación de un servicio web basado en sesión para soportar failover y redundancia.

La aplicación de muestra

La aplicación de muestra que se trata en este artículo proporciona una interfaz de servicios web para suscripciones de presencia convergentes con un agente de usuario SIP que reenvía las suscripciones y maneja las notificaciones hacia y desde un servidor de presencia SIP. La Figura 2 ayuda a ilustrar esto.

Figura 2. Entorno de aplicación convergente
Entorno de aplicación convergente

El diagrama de secuencia de la Figura 3 ilustra el flujo completo de mensajes implementado en la aplicación de muestra.

Figura 3. Flujo de mensajes de la aplicación
Flujo de mensajes de la aplicación

(Tenga en cuenta que esta sólo es una de las formas posibles para implementar el monitor de presencia convergente. Usted puede decidir eliminar la necesidad del sendNotification y simplemente hacer que el monitor de presencia envíe los mensajes WS-notify cada vez que un mensaje NOTIFICATION ingrese al servidor de presencia).


Creando el servicio web

Esta sección describe cómo desarrollar los servicios web que usted necesita en su aplicación convergente. Para esta aplicación, usted desarrollará dos puntos finales de servicio web y dos clientes de servicio web. Utilizará el modelo de programación JAX-WS (API™ Java para servicios eb XML) para los clientes y puntos finales de servicio de su servicio web.

Creando el punto final del servicio convergente

Para ahorrar espacio, en los listados que se presentan en este artículo sólo se mostrarán secciones de código relevantes. No obstante, el código completo para la aplicación de muestra está incluido en este artículo para descargarlo.

  1. El primer punto final del servicio web será una parte del servicio convergente e interactuará con la infraestructura de servicio SIP. Este proporcionará métodos que exponen interacciones de mensaje con la infraestructura SIP, incluyendo suscribir, des-suscribir y sendNotifications. Usted adoptará el esquema de abajo hacia arriba para crear este punto final de servicio web JAX-WS, lo cual significa que usted simplemente comenzará codificando su clase de implementación de servicio web. El Listado 1 muestra la definición de clase y las definiciones de método relevantes para la clase de implementación del servicio web PresenceMonitor.

    Listado 1. Implementación de servicio web
    public class PresenceMonitor {	
    
    	public String subscribe(String presentity, String presenceServerAddress, 
    		String callbackEndpoint) {
    		...
    	}
    	
    	public String unsubscribe() {
    		...
    	}
    	
    	public String sendNotifications() {
    		...
    	}
  2. Luego, usted necesita hacer anotaciones a la clase con el fin de denotarla como implementación de servicio web JAX-WS. El listado 2 muestra las acotaciones necesarias para la clase PresenceMonitor.
    Listado 2. Implementación de servicio web con anotaciones
    @WebService(name="PresenceMonitor", portName="PresenceMonitorPort")
    public class PresenceMonitor {
    
    	@Resource 
    	private WebServiceContext wscontext;
    
    	@WebMethod(operationName="subscribe", action="doSubscribe")
    	public String subscribe(String presentity, String presenceServerAddress, 
    		String callbackEndpoint) {
    		...
    	}
    	
    	@WebMethod(operationName="unsubscribe", action="doUnsubscribe")
    	public String unsubscribe() {
    		...
    	}
    	
    	@WebMethod(operationName="sendNotifications", action="sendNotifications")
    	public String sendNotifications() {
    		...
    	}

    Usted comienza señalando que la clase es una implementación de servicio web, con el uso de la anotación @WebService. En la anotación @WebService, usted proporciona el nombre y nombre de puerto que desee asignar al servicio web. Luego, usted hace anotaciones a cada método que deseemos exponer en el servicio web con la anotación @WebMethod. En cada anotación @WebMethod, usted proporciona un operationName así como un nombre de acción. Usted no tiene que definir ninguno de los atributos en las anotaciones @WebService ni @WebMethod, puesto que son valores predeterminados. Usted termina las anotaciones a su clase poniendo la anotación @Resource en una variable de instancia privada del tipo javax.xml.ws.WebServiceContext. Esto dará como resultado la inyección automática de una instancia WebServiceContext tras la instanciación de la clase PresenceMonitor. Más adelante usted verá que esto le permite recuperar información de sesión HTTP y SIP dentro de nuestra implementación PresenceMonitor.

  3. Con las anotaciones en su lugar, usted puede utilizar las herramientas del WebSphere Application Server para generar los artefactos JAXB (Java Architecture for XML Binding) requeridos. El tiempo de ejecución utiliza estas clases para desordenar y ordenar solicitudes a y respuestas de su servicio web PresenceMonitor.

    Con el fin de generar estos artefactos, usted utilizará la herramienta wsgen que se encuentra en el directorio WAS_HOME/bin de su instalación WebSphere Application Server. El Listado 3 demuestra la ejecución de la herramienta wsgen en la implementación PresenceMonitor.

    Listado 3. Usando la herramienta wsgen
    C:\was70dev\bin>wsgen.bat -cp c:\cea\sip\PresenceMonitorServerWAR\build\classes
    com.ibm.sample.presence.ws.PresenceMonitor -d .\wsserver -wsdl -keep

    Primero, usted proporciona una ruta de acceso al comando wsgen usando el argumento –cp. La ruta de acceso incluye cualquier clase necesaria para compilar la clase de implementación com.ibm.sample.presence.ws.PresenceMonitor que usted especifica en el comando. El argumento -d proporciona el directorio hacia el cual escribir archivos de recursos (WSDL y esquema) y fuentes Java respectivamente. Finalmente, el argumento –wsdl le dice a la herramienta wsgen que genere un archivo WSDL (Web Services Description Language), y el argumento –keep instruye a la herramienta para que preserve todos los archivos fuente Java generados debido al comando. Tanto –wsdl como –keep son opcionales, pero se utilizan aquí para ilustrar los resultados de la herramienta wsgen. La Figura 4 muestra un listado de archivos generados y guardados en el directorio wsserver especificado en el comando.

    Figura 4. Archivos generados ejecutando wsgen en PresenceMonitor
    Archivos generados ejecutando wsgen en PresenceMonitor
  4. Las clases Java están incluidas en el paquete com.ibm.sample.presence.ws.jaxws junto con la clase PresenceMonitor en un archivo WAR (Web Archive) dentro de la aplicación. Usted llama el WAR con la implementación PresenceMonitor del servidor WAR. Adicionalmente, aunque el WebSphere Application Server no lo necesita para servicios JAX-WS Web, usted también empaqueta los archivos WSDL y XSD dentro del WAR. Como usted incluye el archivo WSDL en el WAR, también está actualizando la anotación @WebService en la clase PresenceMonitor, para incluir un atributo wsdlLocation, como se muestra en el Listado 4.

    Listado 4. Anotación @WebService actualizada en la clase PresenceMonitor
    @WebService(name="PresenceMonitor", portName="PresenceMonitorPort", 
    wsdlLocation=”WEB-INF/wsdl/PresenceMonitorService.wsdl”)
    public class PresenceMonitor {

    El atributo wsdlLocation proporciona una ubicación relativa al archivo WSDL desde la raíz del WAR. Por el valor mostrado en el Listado 4, usted ubicará el archivo WSDL generado por ejecutar la herramienta wsgen, en el directorio WEB-INF/wsdl del archivo WAR.

Usted ha terminado la implementación del PresenceMonitor, por ahora. Ahora necesita desarrollar el cliente de servicio web que le permitirá llamar los métodos de la implementación del PresenceMonitor.

Creando el cliente de servicio web

Para desarrollar el cliente de servicio web para la implementación PresenceMonitor, usted utilizará otra herramienta incluida en su instalación del WebSphere Application Server, llamada wsimport. La herramienta wsimport utiliza un archivo WSDL para generar artefactos de cliente de servicios web. Usted utiliza el archivo PresenceMonitorService.wsdl generado previamente por la herramienta wsgen. El Listado 5 muestra el comando para ejecutar la herramienta wsimport.

Listado 5. Ejecutando la herramienta wsimport
C:\was70dev\bin>wsimport.bat wsserver\PresenceMonitorService.wsdl -d wsclient –p 
com.ibm.sample.presence.jaxws.client –keep
  1. Ejecute la herramienta wsimport e ingrese el WSDL generado previamente. El argumento –p proporciona un nombre de paquete a utilizar para todas las clases Java generadas. De nuevo, el argumento –d especifica dónde poner los artefactos generados, y el –keep instruye a wsimport para que guarde todos los archivos fuente generados. La Figura 5 muestra el listado del directorio wsclient.

    Figura 5. Archivos generados al ejecutar wsimport en PresenceMonitorService.wsdl
    Archivos generados al ejecutar wsimport en PresenceMonitorService.wsdl
  2. Usted pone estas clases, junto con su código de aplicación de cliente, en un archivo WAR separado, el se conocerá como el WAR del cliente. Su código de aplicación de cliente utilizará estas clases con el fin de emitir llamadas remotas a los métodos de servicios web expuestos por la clase de implementación PresenceMonitor. Particularmente, su código de aplicación de cliente utilizará el servicio del cliente y clases de puerto --com.ibm.sample.presence.jaxws.client.PresenceMonitorService y com.ibm.sample.presence.jaxws.client.PresenceMonitor, respectivamente-- con el fin de enviar solicitudes de servicios web y recibir respuestas de servicios web. Más adelante, usted verá el código de aplicación de cliente que inicia estas solicitudes.

Con la implementación del servicio web convergente y el correspondiente cliente de servicio web construidos, sólo le resta construir una implementación de servicio web más.

Creando el punto final de escucha

En la implementación del punto final de servicio web PresenceMonitor hay un método sendNotifications. Ese método contiene lógica para enviar notificaciones de eventos SIP a un punto final de escucha de servicios web. A ese respecto, la implementación PresenceMonitor que usted construyó previamente no sólo es un punto final, sino que también es un cliente de servicio web. Ahora, usted necesita desarrollar el punto final de servicio web que actuará como escucha de notificación.

  1. Llame a la clase de escucha de servicio web PresenceListener. El Listado 6 muestra la clase y sus anotaciones de servicio web relevantes.
    Listado 6. Implementación de servicio web PresenceListener
    @WebService(name="PresenceListener", 
    		serviceName="PresenceListenerService", 
    		portName="PresenceListenerPort", 
    	   targetNamespace="http://listener.ws.presence.sample.ibm.com/”)
    public class PresenceListener {
    	
    	@Resource
    	private WebServiceContext wsContext;
    	
    	@WebMethod
    	public void notify(Event event) {
    		…
    	}

    La implementación PresenceListener expone un método único llamado notificar, que acepta una instancia del bean Event Java. Este método es utilizado por el PresenceMonitor para enviar notificaciones de un evento SIP. Volveremos a visitar la lógica interna dentro del método notificar. Así como usted hizo con la implementación PresenceMonitor, usted ejecuta la herramienta wsgen en la clase PresenceListener con el fin de generar los artefactos JAXB necesarios. La Figura 6 muestra los archivos resultantes de ejecutar la herramienta wsgen en el punto final PresenceListener.

    Figura 6. Archivos generados al ejecutar wsgen en PresenceListener
    Archivos generados al ejecutar wsgen en PresenceListener

    Coloque la clase de implementación PresenceListener y las clases mostradas en el Listado 6 dentro del WAR de cliente.

  2. Para completar la creación de sus recursos de servicios web para su aplicación usted necesita generar un cliente de servicio web para la implementación de punto final PresenceListener. Como hizo anteriormente, simplemente corra la herramienta wsimport en el archivo WSDL generado por el comando wsgen previo. Esto significa que usted ejecuta la herramienta wsimport en el archivo PresenceListenerService.wsdl. La Figura 7 muestra el resultado del comando wsimport.

    Figura 7. Archivos generados al ejecutar wsimport en PresenceListenerService.wsdl
    Archivos generados al ejecutar wsimport en PresenceListenerService.wsdl
  3. Coloque los archivos mostrados en la Figura 7 en el WAR de servidor, de manera que el PresenceMonitor pueda actuar como cliente de servicio web para su implementación PresenceListener.

Ahora usted cuenta con los recursos de servicio web necesarios de punto final y cliente. Ahora es el momento de reunir toda la aplicación. Observaremos la funcionalidad SIP requerida así como la lógica requerida por su cliente.


El servidor convergente de monitor de presencia

Después de crear el servicio web, usted pasa a crear las clases restantes que constituyen el monitor de presencia. El diagrama de clase de la Figura 8 muestra todas las clases principales que constituyen el monitor de presencia.

Primero, la clase de servicio web que recibe todas las solicitudes entrantes es el PresenceMonitor, como se describió arriba. Usted puede ver que PresenceMonitor utiliza una clase llamada PresenceSession. PresenceSession es el punto de convergencia entre la actividad de servicio web y la actividad SIP. Hay una correlación de uno a uno de los objetos PresenceSession con los objetos SIP Application Session (SAS). De hecho, el objeto PresenceSession es almacenado cono un atributo en el SAS. Este diagrama también muestra el PresenceSipServlet, que maneja todas las solicitudes SIP entrantes y que también utiliza el objeto PresenseSession.

Figura 8. Diagrama de muestra de clases de aplicación
Diagrama de muestra de clases de aplicación

PresenceMonitor

Como se describió arriba, PresenceMonitor es la clase principal de servidor que maneja las solicitudes de servicios web. Un aspecto importante de PresenceMonitor es cómo este establece una sesión de cliente y cómo esa sesión se asocia con una sesión de aplicación SIP. El código del Listado 7 (con el registro cronológico removido) muestra cómo una sesión de aplicación SIP se deriva del servicio web.

Listado 7. Estableciendo una sesión de cliente en la clase PresenceMonitor
WebMethod(operationName="subscribe", action="doSubscribe")
public String subscribe(String presentity, 
String presenceServerAddress, 
String callbackEndpoint) {

	String msg = "";
	try {
		HttpServletRequest httpRequest = (HttpServletRequest)wscontext.
			getMessageContext().get(MessageContext.SERVLET_REQUEST);
	
		PresenceSession presenceSession;
			
		presenceSession = findExpectedPresenceSession(httpRequest);
			
		if (presenceSession != null)
		{
			msg = "La suscripción ya se envió para esta sesión";
		}
		else
		{				
			HttpSession httpSession = httpRequest.getSession();
	    		SipApplicationSession appSession = ((javax.servlet.sip.
				ConvergedHttpSession)httpSession).getApplicationSession();
				
//	create the web service session to handle this traffic and save it as an 
//	attribute of the app session
			presenceSession = new PresenceSession(appSession, 
				callbackEndpoint);
appSession.setAttribute(PresenceSession.ATTRIBUTE_PRESENCE_SESSION, 
	presenceSession);
…

Cada vez que el código toma una sesión de aplicación de una HttpServletRequest, como se muestra arriba, el contenedor Web automáticamente inserta una cookie convergente en la respuesta HTTP usada para enviar la respuesta SOAP. El cliente de servicios web luego puede utilizar esta cookie para mantener la afinidad de sesión. Los procedimientos para hacer esto están en la sesión cliente de monitor de presencia .

PresenceSession

PresenceSession es la clase que convierte las notificaciones de presencia SIP en notificaciones salientes de servicio web. Cuando la aplicación de muestra recibe una nueva suscripción, PresenceMonitor crea una nueva instancia PresenceSession y la almacena como atributo de sesión de aplicación SIP. PresenceSession mantiene una fila de notificaciones SIP que vuelve a pasar al cliente mediante servicios web.

PresenceSession utiliza dos métodos importantes para proporcionar la interacción entre los servicios web y el SIP. El método de servicios web sendNotifications llama al getNotifyEvent en la PresenceSession asociada con la sesión de servicio web. Luego el método getNotifyEvent consulta si en la fila hay alguna notificación SIP nueva. Si existe alguna, PresenceSession llama al método de notificación del PresenceListener asociado, para entregar la notificación. Si la fila está vacía, se establece un operador booleano en verdadero indicando que la próxima vez que se reciba una notificación esta deberá ser enviada de regreso inmediatamente al PresenceListener asociado mediante el método de notificación.

Cada vez que el PresenceSipServlet recibe un nuevo SIP de notificación el servlet toma el PresenceSession asociado de la sesión de aplicación SIP y llama al método putNotifyEvent. Esto hace que la notificación sea agregada a la fila, o hace que PresenseSession envíe la notificación hacia el cliente mediante la interfaz de servicios web.

PresenceSession

PresenceSipServlet se utiliza principalmente para manejar notificaciones recibidas del servidor de presencia. También maneja las respuestas de las SUBSCRIBES que se envían. La aplicación de muestra utiliza anotaciones SIP en lugar de un descriptor de desplieguesip.xml.

El Listado 8 muestra cómo accesar a la PresenceSession asociada con la notificación enviada desde el servidor de presencia:

Listado 8. Accediendo a la PresenceSession asociada con la notificación
@protected void doNotify(SipServletRequest req) throws ServletException,
		IOException {

	//	First, we access the PresenceSession object associated with this 
	//	notification. The PresenceSession is where notification event are 
	//	queued and picked up through the Web Service interface.
	SipApplicationSession appSession = req.getApplicationSession();
	PresenceSession presenceSession = (PresenceSession)appSession.getAttribute
		(PresenceSession.ATTRIBUTE_PRESENCE_SESSION);
	…

El cliente de monitor de presencia

El cliente de monitor de presencia prueba la aplicación de servidor de monitor de presencia. Este convierte solicitudes HTTP en solicitudes de servicios web salientes. También maneja solicitudes de notificación entrantes de servicio web enviadas desde el servidor de monitor de presencia.

El cliente de monitor de presencia es bastante simple. El diagrama de clase de la Figura 9 a continuación muestra sus clases principales, diferentes a las clases de los servicios web.

Figura 9. Diagrama de clase de cliente de monitor de presencia
Diagrama de clase de cliente de monitor de presencia

TestServlet maneja la solicitud HTTP entrante y utiliza instancias del ClientController para hacer sus solicitudes de servicios web. En la solicitud HTTP se pasa un ID de cliente para correlacionar las sesiones existentes y hay un correlacionamiento de uno a uno de los IDs de cliente para ClientControllers. PresenceListener es un servidor de servicios web que recibe notificaciones del servidor de monitor de presencia, las cuales almacena en una fila.

Este código del ClientController del Listado 9 muestra el establecimiento del puerto del servicio web durante la suscripción inicial. Este puerto es correlacionado con el ID del cliente que se pasa en la cadena de caracteres de consulta de la solicitud de suscripción HTTP. (Vea la sección Entorno de prueba ). El punto importante a tener en cuenta aquí es el método utilizado para establecer afinidad de sesión. Poner SESSION_MAINTAIN_PROPERTY en el contexto de la solicitud asociado con el puerto asegura que cualquier cookie retornada en la respuesta HTTP SOAP se utilice en la siguiente solicitud HTTP SOAP iniciada desde este puerto. Esto asegura la afinidad apropiada con la sesión de aplicación SIP en el servidor de monitor de presencia.

Listado 9. Asegurando la afinidad en el método de suscripción
public String subscribe(String presentity, 
String presenceServerAddress, 
				String callbackEndpoint) {
	String msg = "";
	try {
		if(port == null) {
			String wsdlURLStr = webServiceURL + "?wsdl";
			System.out.println("wsdlURLStr is " + wsdlURLStr);
			if(!wsdlURLStr.startsWith("http://")) {
				wsdlURLStr = "http://" + wsdlURLStr;
			}
			URL wsdlURL = new URL(wsdlURLStr);
			PresenceMonitorService svc = new 
PresenceMonitorService(wsdlURL);
			port = svc.getPresenceMonitorPort();
			BindingProvider bp = (BindingProvider) port;

bp.getRequestContext().put(
BindingProvider.SESSION_MAINTAIN_PROPERTY, Boolean.TRUE);
		}			
		msg = port.subscribe(	presentity,
				presenceServerAddress, callbackEndpoint);
	}
	catch(Exception e) {
		throw new RuntimeException(e);
	}
	if (logger.isLoggable(Level.FINEST)) {
		 logger.exiting(className, "subscribe", port);
	}
	return msg;
}

Entorno de prueba

l entorno de prueba requiere un servidor de aplicación individual ejecutando WebSphere Application Server V7 con el paquete de recursos CEA o con WebSphere Application Server V8.0 beta 2 o superior. También requiere una instancia individual de sipp, que se utiliza como herramienta de fuente abierta para simular un agente de usuario SIP. En este caso, se utiliza un script sipp para simular un servidor de presencia SIP. Finalmente, necesitará un navegador para activar la prueba y validar los resultados.

Instale estas aplicaciones en el mismo o en dos servidores de aplicaciones diferentes:

  • PresenceMonitorClientWAR.war: Esta aplicación incluye un servlet de prueba que convierte solicitudes HTTP en solicitudes de servicios web del PresenceMonitorServer. En otras palabras, este es el cliente de servicios web descrito en el diagrama de secuencia de arriba.
  • PresenseMonitorServerWAR.war: Este es el código central descrito arriba que expone una interfaz de servicio web de un lado y una interfaz SIP en el otro.

Inicie las aplicaciones y el cliente sipp después de instalarlos. Se incluye un archivo de proceso por lotes que se utiliza para iniciar el cliente sipp.

Los siguientes pasos describen cómo ejecutar el código de prueba en cuanto se instala y se ejecuta. (Este ejemplo supone que ambas aplicaciones se están ejecutando en la misma instancia de servidor de aplicación).

  1. Este URL le dice al cliente de monitor de presencia (PMC) mediante una solicitud HTTP que abra una suscripción a través de una interfaz de servicio web con el servidor de monitor de presencia (PMS), el cual, a su vez, crea una suscripción hacia el servidor de presencia vía SIP:

    El appserverhost:port va a ser la cadena WC_defaulthost configurada para el servidor de aplicación.

    Los parámetros en la cadena de caracteres de consultas le dicen a la aplicación cliente qué hacer. Aquí están algunos detalles sobre cada parámetro:

    • Acción: La acción a ser tomada por el servlet del cliente. Las opciones incluyen subscribe, sendNotifications, getNotifications y unsubscribe.
    • Id: El ID de la sesión de cliente. Sería fácil convertir el código cliente para que utilice una cookie para accesar a una sesión HTTP.
    • presenceServerAddress: Se pasa al servidor de monitor de presencia a través de la interfaz de servicios web y especifica a dónde enviar la suscripción SIP. En una aplicación del mundo real, el servidor de monitor de presencia debe tener un elemento de configuración para esto.
    • Presentity: La cadena de caracteres presentity que está siendo suscrita. Al script sipp que representa el servidor de presencia no le interesa qué va aquí.
    • wsURL: El URL utilizado por el cliente para conectarse a través de servicios web al servidor de monitor de presencia.
  2. Luego, este URL le dice al PMC que solicite cualquier notificación disponible del PMS, enviándole una solicitud de servicios web. El PMS ya tiene una suscripción abierta al servidor de presencia vía SIP, desde el paso 1.

    http://<appserverhost:port>/PMC/testservlet?action=sendNotifications& id=1&presenceServerAddress=<sipphost:port>&presentity=Brian&wsURL=http:// <appserverhost:port>/PMS/PresenceMonitorService

  3. Este URL siguiente recupera cualquier notificación recibida por el PMC desde el PMS y lo muestra en formato HTML: http://<appserverhost:port>/PMC/testservlet?action=getNotifications& id=1&presenceServerAddress=<sipphost:port>&presentity=Brian&wsURL=http:// <appserverhost:port>/PMS/PresenceMonitorService
  4. Este último URL le dice al PMS, vía HTTP, que se des-suscriba del PMS el cual, a su vez, envía una suscripción con un 0 TTL al servidor de presencia vía SIP: http://<appserverhost:port>/PMC/testservlet?action=unsubscribe& id=1&presenceServerAddress=<sipphost:port>&presentity=Brian&wsURL=http:// <appserverhost:port>/PMS/PresenceMonitorService

Tenga presente que el código de muestra enviado con este artículo no es para uso en producción. La meta aquí es proporcionar únicamente lo necesario para explicar los conceptos descritos en este artículo. Por lo tanto, no se incluyen aspectos importantes del código como invalidación de sesión y soporte para failover.


Conclusión

Este artículo describe cómo puede usted desarrollar un servicio web convergente usando el WebSphere Applicaton Server. El ejemplo mostrado aquí incluye una interfaz para suscripción a una entidad de presencia y para recibir notificaciones cuando cambien los atributos asociados con la entidad de presencia. En el backend, la aplicación de muestra convirtió la solicitud de servicio web en una suscripción SIP enviada a un servidor de presencia SIP. Este ejemplo demostró muchas capacidades del contenedor convergente del WebSphere Application Server, y debería ser un buen punto de partida para que usted desarrolle sus propias aplicaciones convergentes.


Descargar

DescripciónNombretamaño
Sample application1105_pulito_sampleapp.zip106KB

Recursos

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere
ArticleID=963094
ArticleTitle=Creando servicios web convergentes con el WebSphere Application Server
publish-date=08082011