Tres niveles (no web) aplicación de base de datos en Java - lo API / tecnologías son apropiadas?

Question

Actualmente estoy en la fase de investigación de una pequeña aplicación de base de datos (muy).

Es para una organización benéfica local que sólo tiene 3 o 4 máquinas de cliente que se ejecutan el sistema - sin embargo, con el fin de mover algo de lógica extraña lejos de los clientes, me estoy inclinando hacia el uso de una arquitectura de tres niveles (hay de datos que está en constante lectura a través y se actualizan en su caso, de que el cliente no necesita saber sobre)

es decir. Client <-> lógica del servidor <-> Base de datos

Mientras que soy competente en sí Java y unos pocos marcos / bibliotecas, no estoy particularmente familiarizado con lo que los marcos me podían ayudar aquí. Obviamente voy a estar utilizando JDBC para la base de datos de la mitad, pero la comunicación entre cliente y servidor es el escollo en el momento - yo realmente no quiero ir a cualquier lugar cerca de los conectores directos, por ejemplo (una exageración, o al menos, otro solución debe existir)

he pedido unos pocos desarrolladores que conozco acerca de sus opiniones sobre qué API para usar, y al mismo tiempo han sido muy útiles, todavía no estoy muy seguro de dónde ir. Hasta ahora he oído hablar de cosas REST, SOAP, COBRA y un montón de otras tecnologías. SOAP es el principal de ellos que me llamó la atención (ya que hay algunos buenos ejemplos de su uso con aplicaciones normales en lugar de sólo con la web), pero todavía no estoy seguro de dónde ir - que no parece particularmente apropiado para un general aplicación objetivo como éste (EJB también apareció, pero he oído mucho odio dirigido a él - se merecía este)

Se siente como si con el fin de encontrar la 'mejor herramienta para el trabajo' realmente se necesita para aprender cada uno en su totalidad a 'conseguir' ellos (lo cual es obviamente poco práctico)

¿alguien puede dar orientación sobre cómo elegir las API como éstas (cuando no los he usado antes) o dame información sobre unos de los más comunes, o es realmente sólo un caso de experimentar con un montón de ellos a ver cuál se ajusta mejor?

O tal vez me he perdido totalmente la marca y no hay un marco que está dirigido a esta situación exacta sin desventajas obvias?

Muchas gracias por cualquier ayuda.

EDIT:

completamente olvidó mencionar lo que realmente hace: No es terriblemente complejo - la caridad ejecuta un esquema de transporte, por lo que mantiene los detalles de los conductores, los clientes, los registros de kilometraje controlador, etc., para ver y editar La complejidad real sólo viene con las unidades, ya que los conductores pueden ser asignados a las unidades de repetición (en curso) que previsiblemente podrían continuar 'para siempre'. Sin embargo, cada instancia de una unidad en curso debe ser único, ya que se pueden cancelar o modificar individualmente

La razón principal que estoy inclinando por 3 capas es porque al ser una organización benéfica (con muchos usuarios de computadoras de voluntarios mayores que no son terriblemente 'inteligente') bien puedo estar actualizando la interfaz de usuario con bastante frecuencia para limar errores y bits que no son muy claras para los usuarios novatos. Así que mi plan es conseguir que el back-end entre el servidor y la base de datos absolutamente 'antibalas' en primer lugar, y luego verter todo mi enfoque en la interfaz de usuario para que pueda seguir desarrollando y iterate sin tener que preocuparse por el backend (también ya que voy a estar el desarrollo de piezas de la misma forma remota, centrándose actualizaciones en el lado del cliente es un poco más sencillo)

Todos estos atributos probablemente gritan 'hacer un sistema basado en la web' - el inconveniente aquí es que están detrás de todo tipo de integración difícil con algunas aplicaciones que ya se ejecutan, que no estoy seguro de que puedo conseguir hecho (adecuadamente ) con una aplicación web.

Answer 1

En el propio servidor, necesitará algún tipo de servidor Java EE.

implementaciones comunes aquí son GlassFish (la implementación de referencia) y Apache Tomcat ... suponiendo que no necesita nada más avanzado que un contenedor de servlets. Es probable que usted no si sólo está utilizando servicios web.

Para el cliente, supongo que vas a tener una aplicación GUI, es de suponer que los usos del oscilación o SWF. También podría optar por hacer una aplicación web, puesto que ya vas a tener un servidor web involucrado.

Para comunicaciones de cliente a servidor, se podría utilizar un JAX-WS (servicios web SOAP) o JAX-RS (servicios REST) ??aplicación.

implementaciones JAX-WS incluyen Sun metro (que se distribuye como parte de Java 6 SE ) o Apache CXF .

JAX-RS implementaciones incluyen Jersey y Apache CXF .

En cuanto a la capa de base de datos, JDBC no es su única opción. Java también tiene la Java Persistence API (JPA, actualmente en la versión 2.0).

JPA se utiliza generalmente en aplicaciones J2EE (aplicaciones web específicamente) para simplificar la capa de base de datos. implementaciones comunes son EclipseLink JPA (obsoletes Oracle TopLink) y Hibernate 's Anotaciones .

Todo esto se basa en varios estándares que componen JavaEE:. Servlet 2.5, JAX-WS 2.0, JAX-RS 1.1, 2.0 y JPA

Answer 2

  

EJB también apareció, pero he oído mucho   del odio dirigido a ella - es esto   merecido?

Fue completamente merecía con las versiones 1 y 2 de la especificación EJB. Pero v3 EJB representa una enorme simplificación que los hace pura y simple agradable de usar. En realidad, en buena conciencia, puedo recomendar el uso de beans de entidad en lugar de JDBC manual.

En cuanto a protocolo de comunicaciones, la exposición de los EJB como servicios REST o SOAP es simple absurda en la especificación más reciente de EJB 3.1 - todo lo que necesita es la adición de unas pocas anotaciones y listo