Metrópolis y Gobierno de SOA - Willy .Net

Tuxedo, etc.), siempre y cuando sea confiable para manejar solicitudes
asíncronas.
Es importante observar que todavía utilizaremos Servicios Web
enviamos y recibimos muchos mensajes SOAP, con la excepción
de que se enviarán utilizando una cola de mensajes asíncrona a
diferencia de HTTP. Tal como se ha dado el ejemplo, podemos utilizar
transportes permitidos por el Servicio Web para la cola de
mensajes. Por lo tanto, ¿Cómo funciona esta arquitectura con
nuestro nuevo contexto?
El Cliente Inteligente envía una planilla (y se crea una petición
del Servicio Web correspondiente). Esta petición se ubica directamente
en la cola de mensajes, en lugar de ser enviada en HTTP.
Una vez que el mensaje se ubica en la cola, el cliente puede desconectarse
sin peligro alguno.
El servidor basado en el Servicio Web a su vez tomará conocimiento
de este mensaje, y luego se pondrá en contacto con el
sistema de contaduría para que procese la petición. Si el sistema
de contaduría necesita pedir información adicional, se coloca un
nuevo mensaje en la cola (una petición al consultor) el destinatario
es la aplicación de Cliente Inteligente.
Este mensaje permanecerá en la cola hasta que el Cliente
Inteligente se vuelva a conectar. Para asegurar que el mensaje se
identifique sin demoras , tal vez consideremos un servicio en
segundo plano en base al cliente que se conecta a la cola de
mensajes y envía el cuadro de diálogo "falta información" en la
aplicación de la planilla para el consultor.
Esto proporciona una solución para nuestro para nuestro problema
de ciclos cerrados, y puede ofrecer un modelo más automatizado
pero esto tiene un defecto. El Cliente Inteligente debe
poder conectarse a la cola de mensajes para procesar las peticiones
que ingresan desde los sistemas de contaduría. La mayoría
de los proveedores de colas de mensajes realizan esto por medio
del acceso a alguna cola de mensajes APIs de propiedad exclusiva.
¿Qué sucede si el consultor está en una carretera? ¿Qué sucede
si el consultor sólo tiene acceso desde un aeropuerto a través
de la Web o un e-mail? Estos mensajes no serán entregados
hasta que se conecte a la red corporativa, lo que puede ser
inaceptable.
Utilizando otro transporte, veamos el segundo modelo:
Servicios Web que utilizan Transportes HTTP y SMTP. Uno de
los problemas más importantes con el diseño original es que una vez
que el sistema de contaduría envió el e-mail al consultor solicitando
más información, realmente se crea un ciclo abierto. Este diseño
depende de que el consultor tenga que asociar manualmente el mensaje
de e-mail con texto entrante con el proceso de la aplicación.
El transporte en sí mismo, por el contrario, es eficaz de un modo
razonable. Con la confiabilidad que representan los e-mail hoy en día,
es mucho más que probable que el consultor haya recibido el e-mail.
Teniendo esto en cuenta, podríamos considerar un nuevo diseño a
partir de lo siguiente:
Aquí la solicitud del Servicio Web sobre HTTP aún se utiliza para
enviar la planilla. De igual manera que con el diseño original, esto
está comprometido a una cola de mensajes para liberar la conexión
del Cliente Inteligente. En este diseño, si ocurre algún problema con
la planilla, se envía un e-mail -pero no al consultor. Por el contrario,
se genera un e-mail que contiene la solicitud del Servicio Web para
que se cree la aplicación de Cliente Inteligente. Lo que hacemos es
iniciar una solicitud de información adicional del Servicio Web, pero
utilizando SMTP como transporte.
El Cliente Inteligente necesita algunas modificaciones para hacer
que esto funcione. Es necesario que exista algún modo de recuperar
la solicitud de SOAP utilizando un e-mail -esto puede ser o un filtro
• Journal 5 • www.microsoft.com /architecture
Aviones, Trenes y Automóviles
en la bandeja de entrada del consultor o una cuenta de e-mail por
separado para la aplicación de Cliente Inteligente. En segundo lugar,
una vez que se ha recibido el e-mail, la aplicación de Cliente
Inteligente debe procesarlo y provocar que suceda la acción correcta
sobre el cliente (por ejemplo, un diálogo para preguntar al consultor
por la información faltante). Una ventaja de estos modelos es que
utilizan los transportes existentes, permite que la aplicación de contaduría
inicie una solicitud a la aplicación de Cliente Inteligente y (sujeto
a que podamos acceder al e-mail desde una ubicación remota) no
restringe al consultor a tener que conectarse a la red corporativa para
enviar los gastos. Hay que recordar también que debido a que la solicitud
es un Servicio Web, se pueden aplicar otras normas de igual
manera (Como WS-Security) -que proporcionan integridad y confidencialidad
para el mensaje a pesar de que éste se envíe a través de
servidores SMTP públicos.
Figura 8. Dos aplicaciones en comunicación en la misma máquina
utilizando http
Figura 9. TCP o In Process proporciona una forma más directa
para la comunicación entre aplicaciones locales
Figura 10. El transporte para el Servicio Web se utiliza para
registrar el mensaje en SQL
29