Since NKP must physically relay requests over the network, there are certain requirements for serializability that you should consider.
For most standard resource models NetKernel already provides serializers and all you need to do is ensure the resource model is imported into both the address space of the client and of the server. For example if you are working with XML representation's you should ensure you import urn:org:netkernel:xml:core on both sides of the NKP connection.
If you are working with a custom POJO, you should provide your own transreptor that efficiently serializes the POJO. Often it will be more efficient to think about your own serialization format than to rely on the default Java serializable.
In addition, if your client/server will be requiring serialized representation back as a POJO you will need to provide a "parser" transreptor that can deserialize from the wire format to the POJO.
Request and response headers may be set on both the NKFRequest and the NKFResponse. Only primitive types of String, Boolean, Byte, Short, Integer, Long, Float and Double will be passed. Other values will be lost and a warning logged.
It is not possible to issue remotable TRANSREPT requests. The reason for this is that resolving a transrept request involves class comparison and for obvious reasons the Java classpath cannot be distributed. Also, given that a request needs to be serializable to go over the wire, then even if we did support it using reflection you'd need the transreptors implemented on both sides - which defeats the point anyway!
Cache dependency consistency is preserved across NKP but be aware that instantaneously checking expiration over the network can be costly. Therefore NKP implements an expiry polling mechanism to provide an engineering compromise trading network latency and bandwidth against accuracy of expiry time. See caching for more details.
NKP is implemented with a fundamentally asynchronous architecture. Both requests issued into NetKernel and requests transmitted over the wire are sent asynchronously. This has the advantage of not tying up threads unnecessarily. It is possible to configure timeouts in the Configuration however if the tunnel has reliable messaging then requests or responses should not just be lost.