2010-09-09 16 views
11

Bueno, tenemos una situación por decidir ahora. Pensé que stackoverflow es el mejor lugar para debatir.EJB Vs WebService? Punto de vista del rendimiento

Antecedentes:

Tenemos 2 servidor de aplicaciones de empresa JVM y una aplicación implementada en cada uno de ellos. necesitamos habilitar la invocación de la funcionalidad comercial de una máquina a otra. Supongamos que uno es cliente y otro es servidor.

Ahora desde el punto de vista de rendimiento de qué método es mejor diseñar aplicaciones de servidor.

manteniendo en cuenta lo siguiente:

tengo 2 opciones:

  1. aplicación EJB puro significa cliente EJB y el componente de servidor EJB

  2. WebService enfoque de Java convencionales (sin servicio web sobre EJB, porque es simplemente un desastre)

Métricas de rendimiento: velocidad: qué enfoque de diseño procesará una solicitud más rápido. ¡Mi aplicación comercial se implementará en la máquina de 32 bits con seguridad!

También tenga en cuenta que hay 2 JVM, uno es de 32 bits y 64 bits (para evitar esta situación es inevitable en este momento)

favor envíe sus comentarios

Saludos

Chetan

+0

Agregó la etiqueta de Java a su pregunta. –

+0

¿Qué problemas tiene con los servicios web respaldados por EJB? –

+0

@BlaiseDoughan lo siento por offtopic, pero es una buena práctica para hacer servicios web con respaldo EJB? – MyTitle

Respuesta

8

Si con "Servicios web" te refieres a los servicios web SOAP, los EJB deberían ser más rápidos sin importar cómo lo hagas.

Pros:

  • Java serialización es más rápido que los Servicios Web XML
  • serializar y analizar XML utiliza más memoria que la serialización recta, EJB ahorrar memoria
  • EJB se expresan en interfaces Java rectas y objetos de valor . Para los servicios web, es posible que tenga que agregar una capa de asignación, como XmlBeans o JAXB.
  • mayoría de los protocolos de EJB permite reutilizar fácilmente las conexiones TCP/IP entre las llamadas

Contras:

  • Hacer una primera XML mensaje de definición de un diseño adecuado se desacoplar el cliente y el servidor
  • Es más fácil cambiar los formatos de mensaje dado esa capa extra de indirección
  • implementaciones EJB han sido históricamente enorme y lenta, como en el más grande que las pilas de servicios web (pero más nuevas implementaciones EJB como Apac él OpenEJB es pequeño, liviano e integrable)

Pero si no necesita el manejo distribuido de transacciones, solo use RMI.Tiene los pros pero ninguno de los contras de los EJB. Ha existido por siglos, pero todavía funciona de maravilla.

+0

muchas gracias por los detalles. Estoy buscando una forma más rápida de comunicación entre 2 JVM. EJB es lo que siento. especialmente en mi aplicación, no quiero perder mi rendimiento debido al análisis de XML en los extremos. – Chetan

1

No tiene que ser uno o el otro. Puede tener toda su lógica comercial en EJB y también proporcionar una fachada de servicio web para acceder al EJB. También recuerde que hay diferentes tipos de arquitecturas de servicios web. SOAP es lo que la mayoría de las personas piensa cuando escuchan "servicio web", pero es posible que también desee ver JAX-RS.

Enviar datos como XML a través de HTTP es terriblemente ineficiente. Por otro lado, le da mucho más flexibilidad en el lado del cliente. Los servicios web se pueden consumir desde prácticamente cualquier plataforma o lenguaje de programación.

+0

gracias Mike. Si tomo SOAP sobre EJB, el procesamiento de XML obstaculizaría mucho mi rendimiento. porque mi carga útil xml sería de alrededor de 60 a 100 KB en su mayoría. – Chetan

+0

Mike sugiere JAX-RS que envía mensajes XML no SOAP. Para ver un ejemplo, consulte: http://bdoughan.blogspot.com/2010/08/creating-restful-web-service-part-45.html –

Cuestiones relacionadas