Servicios web Stateful vs. Stateless

Imagine una aplicación CRUD más compleja que tiene una arquitectura de tres niveles y se comunica a través de los servicios web. El cliente inicia una conversación con el servidor y hace algo parecido a un asistente. Para procesar el asistente, el cliente necesita comentarios dados por el servidor.Servicios web Stateful vs. Stateless

Iniciamos un debate sobre los servicios web con estado o sin estado para este enfoque. Hice algunas investigaciones combinadas con mi propia experiencia, lo que me lleva a la pregunta que mencioné más adelante.

servicios web sin estado que tienen las siguientes propiedades (en nuestro caso):

+ high scalability 
+ high availability 
+ high speed 
+ rapid testing 
- bloated contract 
- implementing more logic on server-side

Pero podemos tachar los dos primeros puntos, nuestra aplicación no necesita una alta escalabilidad y disponibilidad.

Así que llegamos al servicio web stateful. He leído un montón de blogs y mensajes en el foro y el punto más inventado la implementación de un servicio web de estado fue:

+ simplifies contract (protocol) 
- bad testing 
- runs counter to the basic architecture of http

pero no lo hace casi todas las aplicaciones web tienen estos puntos negativos? Las aplicaciones web utilizan cookies, cadenas de consulta, identificadores de sesión y todo para evitar la apatridia de http.

Entonces, ¿por qué es tan malo para los servicios web?

Fuente

2010-04-06 codevour

Bastante cerca de un engañado: http://stackoverflow.com/questions/988819/stateful-webservice – gregmac

Ponga el estado en un lugar que pueda manejar fácilmente el estado: la base de datos –

Porque mantener el estado en un servicio web es difícil y si no es extremadamente cuidadoso y/o experimentado tarde o temprano, es posible que encuentre algunos errores muy difíciles de encontrar.

Fuente

2010-04-06 21:16:37

Bueno, depende de lo que sea la plataforma. Muchas veces el contenedor se hará cargo de las sesiones por usted. –

¿Por qué no utilizar simplemente un contenedor diseñado para este fin, como un RDMS? –

No estoy seguro de entender. Si pone cosas en RDMS, básicamente significa rodar sus propias sesiones, que probablemente tendrán un peor rendimiento. No parece que necesite información persistente en la sesión, ¿por qué ponerlo allí? –

He tenido buena suerte con los servicios web con estado. Se sienten un poco sucios porque la cosa de la sesión de cookies de agujero en la parte superior de HTTP es eso; pero, por otro lado, eran SOAP, por lo que sería un poco estúpido estar demasiado molesto por la belleza en ese punto.

Una cosa a tener en cuenta es la interoperabilidad: si está haciendo un servicio web con estado, sus clientes tendrán que respaldar la misma idea de estado que usted tiene (generalmente cookies). Pero de nuevo, funcionó bien para mí.

P.S. Supongo que está en un contenedor que se encargará de llevar el registro de las sesiones por usted.

Fuente

2010-04-06 21:18:07

El estado es donde se esconden la mayoría de los errores.

Fuente

2010-04-06 21:18:55 SamB

Servicios web Stateful vs. Stateless

Respuesta

Cuestiones relacionadas