How does a service work when the payload classes as not avai
TomF:
Just wondering e.g. the DLQ is running as a centralized service... it's forwarded a failed message that contains payload types that it knows nothing about... what should happen?
I'm seeing an exception related to this on th aggregator quickstart. The DLQ service is running on the AS, while the individual serives are all running standalone. The DLQ Service has no visibility on the payload types bound to them failed messages that get delivered to it.
Kurt:
Let me clarify this. This is a generic issue with our transport where do NOT leave the payload opaque. Instead we serialize the *entire* message on the way out and deserialize it on reception in the Courier. So now this courier will need access to the specific java classes contained in the message (let's say the dvd store classes). This is a consequence of the transport/message Implementation design and has nothing to do with the DLQ Service.
IMO we should leave the payload OPAQUE until we need to interact with the message. This will make sending messages around much easier.
Kev:
The generic problem with this issue is that each service is forced to deserialise the object when the message is deserialised. It is not just the DLQ which will be affected by this, all other services will be.
It should be possible to modify the message implementation so that this deserialising is done on a Just In Time basis, this would solve the generic problem.
This will not happen for the GA though, it will have to make it into the release (CP and trunk) at a later date.
TomF:
Kurt and I had a chat about this and came to the conclusion that there 2 issues... the generic issue as described by Kev above (i.e that the message payload is not opaque) and that there's potentially a general "patterns" type issue re whether or not messages being sent to the DLQ (or other orthogonal type services) should themselves be wrapped as payloads to a new message that is itself governed by its own set of contracts (i.e. between the ServiceInvoker and the DLQ).
Mark:
I've seen JIRA used several times for discussions like this. We should be using the forums for design discussions and/or the mailing list(s), but not JIRA. Let's change our habits please before Adrian (Brock) comes down hard on us ;-)
Kurt:
We don't want that to happen.