On Wed, Nov 26, 2008 at 7:31 AM, Colin Jack <[EMAIL PROTECTED]> wrote:
>> Sending references is, of course, also of great value.  But from the
>> point of view of the article which motivated this thread, I believe
>> what the author was trying to say - similar to my blog post - is that
>> if the sender wants the message to convey certain information, that
>> information needs to be in the message itself, not referenced.  You
>> would include references only when the reference itself is what you
>> want to communicate, not whatever value the reference currently
>> dereferences to.
>>
>
> I'm interested in how far you take this approach because on systems
> I've worked on, admittedly not necessarily examples of best practice
> as far as SOA/messaging, it seems like the self-contained messages
> approach can bring you to a situation where the provider is sending
> large amounts of data in messages.

That can happen, sure, but only because you've presumably determined
that you want/need to convey a lot of information in a single message.
 If you don't *need* to, and large messages are a burden, then don't
use them.

> Going back and trying to reduce the message size/complexity after the
> fact can become very difficult so although consumer-driven contracts
> may improve the process I am drawn towards Steve's approach of having
> a minimum reference set in the message and then references to non-core
> information.

What do you mean by "non-core"?  If you mean that the references are
to data that isn't part of the information you're trying to convey to
the recipient, then sure, that's what I've been talking about; use
references for that stuff.

>
> I'd also wonder whether the consumer couldn't also be getting events
> relating to the referenced resource, if so the reference in the
> message is all we need because it can act as an identifier for
> information that we already have. Not tried that approach though,
> perhaps its got major issues in practice?

Hmm, I don't follow.

Mark.

Reply via email to