Arquitectura orientada a servicios
Los servicios web siguen siendo un concepto muy misterioso a los ojos de muchas personas. Al investigar la causa raíz, creo que se debe principalmente a que los servicios web se promocionan mucho, pero rara vez se ven aplicaciones prácticas. , lo que confunde a la gente. Un sentimiento muy complicado y difícil de entender. Además, los servicios web se basan en XML y muchas personas no comprenden el propio XML, aunque es posible que escriban archivos de configuración en formato XML todos los días.
Al mencionar el origen de los servicios web, primero debemos hablar de SOA (arquitectura orientada a servicios). Como muchas tecnologías de software que hicieron época, la aparición de SOA es fundamentalmente para resolver el problema de la crisis del software. . Cualquiera que haya trabajado en un proyecto ha tenido esta sensación. A medida que avanza el proyecto, la relación entre los módulos se vuelve cada vez más estrecha. Cualquier pequeña modificación puede causar inestabilidad en todo el sistema y, como resultado, las necesidades del cliente siempre cambian. el proyecto que terminó casi en fracaso.
Desde la perspectiva de las tendencias de desarrollo de software (distribuido), C/S-gt; B/S-gt; SOA, el grado de acoplamiento entre módulos es de estrecho a flexible, y el acoplamiento flexible es conveniente para la modificación. . ¿No están la mayoría de los diversos patrones de diseño de los que hablamos a menudo también destinados a reducir el acoplamiento entre clases?
Aquí cito la definición de SOA del sitio web de IBM: La arquitectura orientada a servicios (arquitectura orientada a servicios) es un modelo de componente que integra diferentes unidades funcionales de una aplicación (llamadas servicios) a través de estas se vinculan los servicios. mediante interfaces y contratos bien definidos. La interfaz se define de forma neutral y debe ser independiente de la plataforma de hardware, sistema operativo y lenguaje de programación en el que se implementa el servicio. Esto permite que los servicios integrados en una variedad de dichos sistemas interactúen de una manera unificada y común. (Texto completo)
En pocas palabras, el sistema se divide en tres roles: proveedor de servicios, usuario de servicios y centro de registro. El proveedor publica servicios en el centro de registro y el usuario descubre todos los servicios a través de él. el centro de registro requiere un servicio, luego se vincula al proveedor del servicio y llama al servicio.
Entonces, ¿cuál es la relación entre los servicios web y SOA? Se puede decir que los servicios web son una implementación de SOA, un poco como la relación entre Tomcat y las especificaciones JSP/Servlet. SOA es un concepto relativamente virtual. Por ejemplo, solo propone definir algunas interfaces y protocolos. Entonces, ¿cómo deberían concretarse estas cosas? Los protocolos utilizados por los servicios web se basan en XML. Habrá tres roles, y estos tres roles en los servicios web tienen métodos de implementación específicos. Cuando vea esto, se preguntará: ¿qué otras implementaciones de SOA existen? Se pueden considerar CORBA, DCOM y J2EE, pero creo que no se pueden considerar muy puros, al menos no todos tienen protocolos neutrales.
Ahora es el momento de utilizar un ejemplo específico para ilustrar el servicio web. Supongamos que nuestro sistema necesita una función para consultar las condiciones climáticas locales (hora mundial, tipos de cambio, etc., obviamente). No crearemos nuestro propio programa para buscar datos en la base de datos del departamento meteorológico. Esto requiere muchos procedimientos y, lo que es peor, hacerlo aumentará nuestro vínculo con el departamento meteorológico. Imagine que un día la estructura de la base de datos del departamento meteorológico cambia y tendremos que modificar nuestro propio código. Si se olvidan de notificarnos este cambio, ¿imagina lo que verán los clientes?
Para utilizar los servicios web, buscamos servicios relacionados con el clima de un determinado centro de registro. Entre los resultados, podemos elegir un servicio que cobre una tarifa más baja o un servicio que cobre una tarifa ligeramente más alta. Tarifa pero es más estable y precisa. Desde el centro de registro, podemos obtener una descripción completa del servicio seleccionado, que incluye varios tipos de datos y métodos de llamada. Usando esta información, podemos usar herramientas para generar estas clases necesarias, así como Stubs de cliente. para llamar a servicios web remotos. En nuestro ejemplo, después de la llamada, el proveedor de servicios devolverá un mensaje que contiene el resultado. En nuestro sistema, el resultado requerido se puede obtener de este mensaje y mostrarlo al cliente.
Esto forma una llamada de servicio web completa. Este método de llamada se llama llamada estática porque la dirección del proveedor de servicios (llamado punto final de llamada) está escrita en el Stub. Hay otro método llamado llamada dinámica, que se analizará más adelante.
Entonces, ¿cuál es la diferencia entre los servicios web y el anterior RPC (llamada a procedimiento remoto)? RPC generalmente requiere que la persona que llama y la persona que llama sean isomorfas, es decir, escritas en el mismo lenguaje, pero los servicios web no tienen este requisito (el truco es usar XML para encapsular mensajes), lo que aumenta enormemente el grado de flexibilidad; Además, los servicios web además de este método similar a RPC, la llamada también puede basarse en mensajes. El usuario del servicio solo puede recibir o enviar mensajes. Este método es muy útil en algunas aplicaciones.
Para resumir el contenido: los servicios web son la implementación de SOA y los servicios web no son RPC.