Client Server Communication and Persistence Frameworks

When using Persistence frame开发者_StackOverflow社区works like Hibernate, JPA etc. on the server side, what are the general practices of passing on the data between client and server ? Are there any existing design patterns for the same ?

Thanks.

I do not know about patterns but I know in a design using for example EJB3 with JPA that it's not recommended to pass JPA entities to client through remote EJB's because proxies stay and it can generate a lot of useless network traffic. You'd better detach your entities or give to client simple value objects.

Client-server, or with the inclusion of database, 3-tier architecture is a design pattern itself. The question is rather which technology should be used in the communication. There are many choices, e.g. HTTP, TCP, UDP, JMS, XMLRPC, RMI, CORBA, C RPC or flash-drives carried by post pigeons. In general, it is advised to

• use a technology that has a tooling to define your message/data format, like SOAP (WSDL), CORBA (IDL), XML (XSD, Relax NG, Schematron,..) over JMS/HTTP/....
• choose a text-based format (XML, JSON, ..) instead of a binary (RMI, CORBA, ..) when performance is not a major issue. Text formats are easier to understand for the programmers writing the next version or a brand new client. It is also easier to debug or audit such an interface.
• use an open, standard technology, don't re-invent the wheel.
• choose an underlying transport that suits your communication model. E.g. JMS is well suited for fire-and-forget communication, while HTTP is well suited for synchronous request-reply.
• keep in mind higher-level architecture. E.g. if your server (service) is one of many maintained by the same IT department, it is advised to use the same communication technology for all of them (see also SOA).

Regarding your question on dependency on the chosen persistence framework, I think there is none. Your choice of using e.g. Hibernate does not enforce or exclude any client-server communication technologies.

Ideally, the persistence layer should be quite separate from your client-server comms layer. While not strictly a pattern, the idea here is loose coupling.

As HerQuLe said, you should try to make sure that the data you send between client and server is just POJO style info, rather than serializing a (possibly much more complex) proxy.

As Sebastien Lorber said you may use DTO pattern, i.e. to copy entities to POJOs. But you may send JPA entities to client to avoid DTO's. There are two problems with sending entities:

1. Lazy relations: you have to initialize all necessary lazy relations before you send entities out. (There are a few solutions how the remote client can read lazy relations, I would not recommend this).
2. Entities may contain JPA/Hibernate specific code - annotations, collections, proxies. You have either to
   • Add Hibernate/JPA jars to the client code.
   • Clean the entities before you send them out. (You do not clean the annotations, just add hibernate-annotations.jar to the client code). See Hibernate, Get Out of My POJO!