web services - services - ¿Qué tan buenos y/o necesarios son los servicios web de estado?
web service wsdl ejemplo (5)
¿Qué tipo de servidor ves en proyectos reales?
1) Los servicios web DEBEN ser sin estado: Básicamente, debe enviar un nombre de usuario / contraseña con cada solicitud, cada solicitud debe usar HTTPS y autentificaré y cargaré el objeto Usuario cada vez que sea necesario.
2) Una sesión para servicios web: como en un contenedor web, por lo que al menos puedo guardar el objeto de usuario autenticado y tener algo similar a un ID de sesión, por lo que no necesito autenticar, cargar y verificar al usuario en cada solicitud.
3) Servicio Sticky (servicio persistente a través de solicitudes): https://jax-ws.dev.java.net/nonav/2.1/docs/statefulWebservice.html
Entiendo los problemas de escalabilidad de los servicios con estado (y de las sesiones de aplicaciones web), pero a veces debe tener algún tipo de estado, por ejemplo, para un carrito de compras. Pero también puede poner este estado en la base de datos (usar el back-end como un tipo de sesión argh ) o pasar el estado completo al cliente (el cliente se hace responsable de reenviar todo el carrito de compras).
La verdad es que, al menos para las aplicaciones web, la sesión ayuda mucho en muchas situaciones. Los problemas de escalabilidad se pueden ignorar si su sistema acepta que "el usuario debe comenzar de nuevo a hacer lo que esté haciendo si su servidor web falla" o puede intentar un clúster de sesión si eso es inaceptable.
¿Cómo es para los servicios web? Me inclino a concluir que los servicios web son muy diferentes a las aplicaciones web y aceptan la opción 1) (siempre sin estado), pero sería bueno escuchar otras opiniones basadas en la experiencia real del proyecto.
Creo que con los clientes de Flex, el estado se traslada del servicio al nivel de cliente. Mantenga los servicios sin estado y deje que los clientes mantengan el estado necesario. Los servicios son simples y los clientes pueden combinarlos como deseen.
Depende en gran medida de si el servicio está orientado a transacciones individuales (por ejemplo, obtener cotizaciones de acciones) o si la salida del servicio depende de los datos proporcionados por un cliente en particular a través de múltiples transacciones (en ese caso, el estado debe mantenerse).
En lo que respecta a los problemas de escalabilidad, el almacenamiento del estado en una base de datos no es realmente una mala manera de proceder (de hecho, probablemente sea la única opción si está equilibrando la carga de su servicio en una granja de servidores).
Idealmente, los servicios web (y sitios web) deberían ser sin estado.
Desafortunadamente, esto requiere un dominio del problema muy bien pensado y una clara separación de preocupaciones.
Descubrí que, en la práctica, la mayoría de los sitios web del mundo real dependen del estado, aunque esto limita su escalabilidad.
También he encontrado que muchos servicios web del mundo real también dependen del estado.
En última instancia, la decisión ''correcta'' es la que funciona para el problema específico, por lo que probablemente esté bien escribir un servicio web que dependa del estado y refactorizarlo más tarde si la escalabilidad se convierte en un problema.
Parece que estás equiparando el estado y la autenticación. ¿Quizás esté acostumbrado a almacenar el nombre de usuario y la contraseña en estado de sesión?
Esto no es necesario, incluso con los antiguos servicios web de ASMX. Simplemente pase la información que necesite a su operación de "Iniciar sesión". Esta operación se definirá para devolver un encabezado de "Ticket de autenticación".
Todas las demás operaciones que requieren autenticación requerirán este encabezado "Ticket de autenticación". Cada uno comprobará el encabezado para ver si representa un usuario válido y autenticado. Si es así, entonces realizarán su tarea. De lo contrario, devolverán un error de SOAP que indica que se requiere autenticación.
No se requiere ningún estado. Simplemente asegúrese de que el ticket de autenticación se pueda validar en cualquier servidor en el que se ejecute su servicio (por ejemplo, en una granja de servidores web), y estará bien.
Si bien es solo una pequeña diferencia, debe mencionarse:
Los servicios web no eliminan la escalabilidad, sino el estado en el servidor de aplicaciones que aloja los servicios web que eliminarán la escalabilidad. En el momento en que dice que este usuario necesita acceder a este servidor (como se hace en las sesiones adhesivas), está limitando efectivamente sus opciones de escalabilidad. El punto al que desea llegar es que ''cualquiera de sus servidores de aplicaciones de carga equilibrada'' puede manejar esta solicitud de servicio web y si agrego 1 servidor de aplicaciones más, debería poder manejar un% más de usuarios .
Está totalmente bien (y se recomienda personalmente) si desea mantener el estado para pasar un token de autenticación y en cada solicitud, obtenga el servicio para recuperar su ''estado'' de un almacén de datos (preferiblemente uno redundante y particionado, por ejemplo, clave distribuida + replicada) / almacén de datos de valor). Así es como Amazon lo hace con SimpleDb y Google con BigTable.
Ebay adopta un enfoque ligeramente diferente y almacena la mayoría de los clientes del estado en una cookie para que se transmita con cada solicitud. Aunque genera mucho más tráfico, aún es escalable ya que cualquiera de sus servidores aún puede manejar la solicitud.
Si desea un almacén de datos escalable, le recomendaría que busque en redis que tiene velocidad y características que no se pueden superar en un almacén de datos clave / valor.
También debe consultar highscalability.com si desea acceder a un buen material sobre cómo crear servicios rápidos y escalables.