I'm implementing the content enricher pattern to add in some detail to a
message (id > name), and before I set out wanted to know if there was a
preferred implementation?

It's pretty simple - property is contained within incoming message, detail
is retrieved via a web service call, and then included back into the message
before it's sent out. There is some additional processing of the message
within an orchestration, that does not relate to the new detail, so it can
be added at any time before the final send (which is a web service call).

As I see it the detail can be added in the receive pipeline via a custom
component, or within the orchestration itself (either through custom
component, or web sevice call)? Adding detail in the orchestration seems
easier, but is rather messy, owing to the "immutability" of messages.
Pipeline might be neater, but is less flexible?

Anyone have a nice neat argument either way?

Hugo

[ Post a follow-up to this message ]

Perhaps what I'm really looking for is an equivalent to the database
functoids, only using web services to retrieve the data?

"Hugo Rodger-Brown" <hugo@coldhams.com> wrote in message
news:uLGNUFg1EHA.2568@TK2MSFTNGP10.phx.gbl...
> I'm implementing the content enricher pattern to add in some detail to a
> message (id > name), and before I set out wanted to know if there was a
> preferred implementation?
>
> It's pretty simple - property is contained within incoming message, detail
> is retrieved via a web service call, and then included back into the
message
> before it's sent out. There is some additional processing of the message
> within an orchestration, that does not relate to the new detail, so it can
> be added at any time before the final send (which is a web service call).
>
> As I see it the detail can be added in the receive pipeline via a custom
> component, or within the orchestration itself (either through custom
> component, or web sevice call)? Adding detail in the orchestration seems
> easier, but is rather messy, owing to the "immutability" of messages.
> Pipeline might be neater, but is less flexible?
>
> Anyone have a nice neat argument either way?
>
> Hugo
>
>

[ Post a follow-up to this message ]