web-services - servicio - tipos de ejb

¿Algún beneficio de seguridad de hilos de exponer un servicio web como un bean de sesión sin estado?

Question

¿Hay algún beneficio relacionado con la seguridad del hilo de exponer un servicio web como un bean de sesión sin estado?
(Corrígeme si estoy equivocado) pero creo que los servicios web no son seguros para hilos y, como Servlets, el servidor crea una sola instancia de una clase de servicio web (no una instancia por solicitud).

Lo que no sé si son asignados desde un grupo de beans como beans sin estado son: por el servidor de la aplicación. Estoy tratando de encontrar si utilizo la anotación @Stateless con un servicio web que ya está anotado con la anotación @WebService, que forzará al servidor de la aplicación a comenzar a asignarlos desde un grupo para cada solicitud entrante. De esa manera, sé con certeza que crearé una instancia separada para cada solicitud entrante.

Answer 1

Introducción

La cantidad de instancias utilizadas por el punto final del servicio web depende del marco que esté utilizando.

Si usa un punto final simple (es decir, JAX-WS con los servicios web Apache CXF o Spring), tendrá una única instancia de servicio para todos los hilos / solicitudes (como usted dijo, Servlets). Entonces, por definición, este tipo de servicios están destinados a ser apátridas. Pero si necesita agregar algún estado al servicio, puede hacerlo, pero le corresponde al desarrollador hacer que el hilo del servicio sea seguro.

Cuando usas EJB tienes más flexibilidad: si usas beans sin estado, tendrás un grupo de instancias para administrar todas las solicitudes (si poolSize = 1 obtienes el mismo comportamiento de Apache CXF). Nuevamente, puede agregar un estado a un bean sin estado, pero hacerlo más seguro es aún más difícil porque tiene un grupo de instancias para administrar. Pero si necesita un estado, puede usar un bean con estado para tener un marco que le haga la vida más fácil con respecto a la seguridad de los hilos.

Algunos consejos sobre los estados de servicio

Si no mantiene un estado en su servicio, su servicio web es seguro para subprocesos. En otras palabras, un servicio sin estado si es seguro por definición.

Si necesita algún estado que deba ser compartido por TODO el thread / request, puede agregar algo de estado a un servicio sin estado (JAX-WS o un bean de sesión sin estado con poolSize = 1) pero necesita hacerlo seguro, agregando sycn blocks (por favor, no sincronice su @WebMethod ). IMPORTANTE: En teoría (y en la práctica), NUNCA debe agregar un estado a un bean de sesión sin estado, porque el grupo puede destruir / crear instancias cuando "quiera".

Si necesita mantener un estado que solo será utilizado por el hilo / solicitud actual, puede agregar algún estado a un servicio sin estado utilizando variables ThreadLocal , o más fácilmente usando beans de sesión con estado.

Ahora, finalmente, respondiendo tu pregunta

1. Los beans de sesión sin estado son seguros para la ejecución de subprocesos si y solo si los haces seguros para subprocesos: no deberían tener un estado :-)
2. La única diferencia entre un servicio web clásico y un servicio web de bean de sesión sin estado, si el primero tendrá una única instancia, y el segundo utilizará un grupo de instancias. Si poolSize = 1 obtienes el mismo efecto, pero en teoría, el grupo puede destruir tu instancia cuando "quiera".

Esperando que ayude,