Marshalling

(Un)Marshalling is what will (read/)write a Java object to a communication format. It is commonly the part converting an object to a XML or JSON payload but can really be any format, including binary formats.

This conversion is normally synchronous in the implementation and can be costly depending on the model you use and the serializer that is activated. Compared with the servlet API, where you yourself serialize the payload you want to read/return, here, the task is done by the framework and is, therefore, a bit hidden.

A crucial point at this stage is to make sure that the manipulated object has almost no logic and is fast to initialize/read. If you don't respect this point, you may end up holding the HTTP stream for too long which would badly impact your scalability and on a more general practice, you would risk to have some lazy loading of data with JPA which can fail or imply an unexpected connection usage depending the JPA provider and configuration. Another bad case would be to start writing and, then, compute some costly value before continuing to write and therefore force the marshalling process to pause and delay the write after having started it. This not only has a direct impact on the request thread pool but also on the HTTP I/O.

In the same spirit as the algorithm used to match a method to invoke (see the previous part), the JAX-RS runtime must resolve the provider to use (MessageBodyReader or MessageBodyWriter depending on whether you read or write) in order to make the link with the Java model. Here again, this resolution depends on the incoming request (or the response being built) and media type headers and is not as flat as expected even if it is cacheable and generally fast.