We have 11 domain objects that 1) implement Externalizable AND 2) are not exclusively for the use by the agents. The 11 are:

org.rhq.core.domain.auth - modules/core/domain/src/main/java - rhq
   Subject
org.rhq.core.domain.configuration - modules/core/domain/src/main/java - rhq
   Configuration
   Property
   PropertyList
   PropertyMap
   PropertySimple
org.rhq.core.domain.event - modules/core/domain/src/main/java - rhq
   EventDefinition
   EventSource
org.rhq.core.domain.measurement.calltime - modules/core/domain/src/main/java - rhq
   CallTimeDataValue
org.rhq.core.domain.resource - modules/core/domain/src/main/java - rhq
   Resource
   ResourceType

The Remote API will want all of the data when serialized to remote clients (i.e. the CLI, not the agent) - so we do not want to go through the Externalizable interface when streaming to/from the remote client.

To implement this we need:

1) To implement simple utility in domain module that just sets a ThreadLocal variable and gets that ThreadLocal variable's value. The value should be either an int or an enum to represent  "REMOTEAPI" and "AGENT". This should be in a new "serial" package under the domain module's "util" package - "org.rhq.core.domain.util.serial".

2) To write and read the full content of the 11 domain objects, we need 11 objects that essentially implement Externalizable (but maybe not explicitly), but their write/readExternalizable methods fully serialize their respective doman objects.  So we would have 11 "Externalizable" objects like "ResourceExternalizable", "ResourceTypeExternalizable", "SubjectExternalizable", etc. -- each you mimic the write/readExternal methods taking the stream and reading/writing the full data (as needed by remote clients). These 11 Externalizable objects should go in the same domain package "org.rhq.core.domain.util.serial" as the thread local utility from 1) above.

3) The 11 domain objects (Resource, ResourceType, etc.) will need to use the thread local utility created in 1) above in their writeExternal methods. When writing to the stream to go over the wire, if the thread local is not set OR the thread local is AGENT (i.e. this is the default), then the writeExternal does what it normally does today (i.e. write the minimized amount of data) with the exception that the very first byte sent over the wire is a flag to indicate this strategy is being used (e.g. send a char "a"). If the thread local is set and its value is REMOTEAPI, the domain object's writeExternal needs to invoke the writeExternal defined in the new Externalizable object created in 2) above (so writeExternal will need to instantiate it - or, perhaps Externalizable objects contain merely static methods). The Externalizable object would full serialize the object, with the additional first-byte getting sent to indicate the full serialization is occurring (e.g. send a char "b").

The domain object's readExternal would read the first character in the incoming stream, if its "a", it does its normal readExternal. If its "b", it needs to use the Externalizable object from 2) above to let it handle the full deserialization.

4) Deserialization is the easy part because the additional char at the beginning of the stream tells the domain object how to deserialize itself. However, when needing to serialize the domain object, the client/sender code needs to set the thread local using the utility from 1) above. This means the CLI remote client proxy code needs to ensure it calls the thread local utility and set the bit appropriately. The client sender running in the agent will not have to do anything because, as mentioned earlier, the default serialization mechanism to be used (if the thread local doesn't exist, or isn't set) is the original agent serialization strategy.  However, when the server is sending data TO the agent, the server needs to set this ThreadLocal to indicate AGENT strategy - do this in the AgentClient implementation. The AgentClient implementation may need to flip that ThreadLocal back to its original state - but I'm not sure about that.