Servicio web vs sockets TCP/IP (Java) + SQL Connections

Question

Actualmente nos encontramos en una etapa del ciclo de vida de nuestro producto en el que estamos pensando en trasladarnos a los servicios web. Nuestro sistema está escrito en Java, que consiste en varias aplicaciones de cliente y servidor que hablan entre sí a través de sockets TCP y también tiene SQL en línea para realizar recuperación de datos y actualizaciones (¡sé!) Que usa nuestra propia clase de conexión SQL que luego utiliza java.sql.Connection para conectarse a una base de datos de SQL Server utilizando el controlador JDBC de Microsoft.

Las aplicaciones se unen entre sí utilizando sockets TCP. Solicitan datos e intercambian datos entre ellos. Lo cual funciona perfectamente bien.

Pensamiento

lo que estamos buscando en la conversión de todos los accesos de datos y la comunicación TCP a un servicio web.

El servicio web estaría diseñado para ejecutarse en un sitio seguro de Internet de las empresas. La idea sería que los usuarios pudieran conectar a sus clientes al servicio web desde su hogar, cuando no están en la red de la empresa, o en el trabajo, cuando lo están.

Las aplicaciones del cliente enviarían/​​recibirían los mensajes a/desde las aplicaciones del servidor usando el servicio web. Las aplicaciones cliente recuperarían y actualizarían los datos en la base de datos utilizando el servicio web.

Pregunta

Me gustaría saber qué experiencia de los pueblos es de hacer cualquier cosa con 2 vías de comunicación (petición y empuje) a través de un servicio web (si es posible) y lo que los pensamientos son acerca de hacer esto.

La conversión del acceso a datos a un servicio web parece bastante directa: puedo anticipar algunos problemas con el rendimiento cuando se recuperan grandes conjuntos de datos en algunas partes del sistema.

Estoy mirando a través de varios materiales de lectura sobre el asunto, ya que es un tiempo desde que he tocado los servicios web (usando C# y ASP.NET). Actualmente lee "Creación de servicios web con Java ™: comprensión de XML, SOAP, WSDL y UDDI". Debo admitir que pensé que los servicios web siempre eran apátridas, ¡pero acabo de leer que no lo son!

Gracias,

Andez

Answer 1

Ayuda a pensar de servicios web como siendo el mismo que cualquier otra aplicación web en la capa de transporte. Utiliza los protocolos HTTP/HTTPS de la misma manera, es solo que en lugar de enviar HTML, envía XML de acuerdo con un formato predefinido (SOAP). Como tal:

• de lo orientado petición/respuesta
• puede tener estado en la misma forma que una página web puede ser de estado, usando sesiones (suponiendo que tiene un cliente de servicios web que apoya el mantenimiento de las cookies de sesión a través solicitudes)
• Todas las solicitudes finalmente se reducen a buenos puntos finales de servlets pasado de moda en el servidor

Mantener estas limitaciones y características en mente, piensan acerca de sus necesidades y como se asocian uno contra el otro. Si necesita una verdadera comunicación bidireccional (push), los servicios web no son ideales. Son cliente/servidor, orientados a solicitud/respuesta.El impulso de lograr, tendría que sondear desde el cliente. Una posible alternativa podría ser permitir que tanto el "servidor" como el "cliente" actúen como "servidores" del servicio web. Eso significaría agrupar un motor de servlets liviano con el cliente (como embarcadero) para que el "servidor" pueda realizar llamadas de servicio web al "cliente". Otra forma es observar el RMI/IOOP bidireccional.

Otra forma más sería mantener la capa de comunicación como la tiene hoy. No hay ganancia inherente en la refactorización de los servicios web solo por el uso de los servicios web. Si no agregan ningún beneficio, es solo desperdicio. Como ya mencionó, el servicio web viene con una carga adicional (protocolo detallado, servlet engine, etc.), por lo que realmente necesita equilibrar el costo adicional y el tiempo de desarrollo con un claro beneficio. Como dice el refrán "si no está roto, no lo arregles". Como dice que la solución actual "funciona perfectamente bien", probablemente no la cambiaría. Aunque soy solo yo.