So, you want the service proxies themselves to serialize themselves and then re-constitute themselves, connecting back up to the original registry?
Sounds crazy or what?
I actually have this thing working right now, I just don't like to put writeReplace() on the service interface when it's not needed and has nothing to do with the service interface, I don't think that's right.
Serialized services don't "re-constitute themselves" nor "connect back to the original registry" but that is the illusion the pojo see...
Under the cover what really happens is that just a SerializedService instance is serialized and not the proxy itself... this instance has also the appropriate logic for, when deserialized, replace itself with the real service looking it up on the registry.
This is all transparently done using the standard serialization mechanisms.
I think this also goes a step ahead in the "distributed HiveMind" road, cause it means I can "put a service" on a wire and have it automatically and transparently looked up on the other end's registry.
Maybe I should post some code?
Now, what I'm saying is that HiveMind generated proxies should take care of implementing the serialization protocol methods IF the service interface extends Serializable AND the core service implementation has those methods implemented.
If the service interface implements Serializable, then the methods to lookup on the service implementation would be writeReplace() and writeObject(), then HiveMInd generated proxies should have these methods implemented delegating to the core service implementation.
Maybe Externalizable can be supported as well?
--
Pablo I. Lalloni Teléfono +54 (11) 4347-3177 Proyecto Pampa Dirección Informática Tributaria AFIP ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ One thought driven home is better than three left on base. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
<<attachment: smiley-1.png>>
