2011-07-15 34 views
9

Estamos desarrollando un servicio para nuestro portal/cliente web desarrollado utilizando JSF. Mi consejo fue exponer el servicio como REST, pero otro miembro del equipo dijo que debía ir con la implementación de RMI, ya que es más fácil tratarlo en el objeto Java desde el punto de vista del desarrollo y la prueba.Servicio RMI vs REST

Mi argumento fue que los esfuerzos de desarrollo y prueba son más o menos los mismos, pero obtendremos toda la bondad de los servicios web REST.

FYI: Ya tenemos la configuración REST para que no haya ningún costo adicional en el soporte de la estructura. Estos servicios están expuestos para nuestro cliente de teléfonos inteligentes que utiliza la API REST.

Al final, nuestro gerente decidió ir con RMI, pero sigo pensando que REST sería una forma más inteligente.

¿Cuál sería su opción REST o RMI?

Nota: Nada en contra de mi miembro del equipo o Gerente solo tratando de aprender aquí.

+0

No hay suficiente información para obtener una respuesta definitiva, pero si ya tiene una API REST, su gerente debe tener una buena razón para agregar otra opción de interacción remota a la mezcla. – SteveD

+0

RMI está bien si se está ejecutando en casa. cualquier cosa cliente/servidor sobre Internet general debería estar usando un protocolo moderno de servicios web. – jtahlborn

Respuesta

4

El mayor argumento contra RMI y para REST/SOAP, etc. es que el cliente no tiene que ser Java.

Si su front-end puede cambiar en el camino de JSF a ASP, entonces tendrá problemas.

Aparte de eso, RMI es el camino a seguir. Una forma aún mejor de ir es EJB (que es una capa sobre RMI) con ventajas adicionales: muchos proveedores ya implementan la especificación EJB, usted obtiene las ventajas de la agrupación de objetos, gestión de transacciones, etc.

+6

Si quiere decir con EJB Enterprise Java Beans, no estoy de acuerdo, sería una gran sobrecarga hacer cualquier cosa relacionada con EJB si solo necesita RMI. –

5

Si hay son firewalls entre su cliente y su servidor, es probable que el tráfico de RMI esté bloqueado. El tráfico HTTP está abierto en la mayoría de los firewalls y REST no debería tener problemas para hacerlo.

+1

Esto puede ser un gran problema si está vendiendo su software en compañías; no le gusta abrir puertos para RMI, pero bueno, ¡le permitirán hacer un túnel a través de HTTP (S)! – SteveD

+3

También puede hacer RMI a través de HTTP. –

2

Es el cliente en Java, use RMI. Pero eso es solo pensamiento. Como es solo un protocolo punto a punto.

REST como paradigma es interesante si tiene, por ejemplo, muchas lecturas y me gusta usar tecnologías HTTP para el almacenamiento en caché, etc. Lo siguiente es que puede implementar fácilmente "cursores de paginación" para enviar datos como una página pequeña y agregar información sobre cómo recuperar la página siguiente.

Su pregunta básicamente está formulada como si fuera una pregunta tecnológica. ¿Cuál es el enfoque equivocado? No debe preocuparse por la tecnología, sino por la arquitectura del sistema. Todo el sistema de software, sus capacidades, su rendimiento, su escalabilidad, su configuración y su mantenimiento son completamente diferentes según su uso de RMI o REST.