While I agree with the point that messages should be self-describing, there is a difference between the semantics of a message body, and the action that occurs as a result of it being received. The exact same message body, having the exact same semantics, can legitimately cause different actions depending on who receives it and when. For example, a LogOrder port may simply log the order, while a FulfillOrder port may cause the order to be shipped.
However, there is also a difference between designing a system to change state (such as shipping a pizza) based on an *event* (such as receipt of a "do it" message) versus changing state based on *evidence* of the need to change state (such as possessing a signed pizza order that has not already been shipped). The reason I say "possessing" instead of "receiving" is that it should not be the *event* of receiving the message that by itself causes the pizza order to be shipped (because the same message may be accidentally delivered twice). Systems whose state changes are based on events are inherently more fragile than those whose state changes are based on evidence of the need to change state. This is the basic idea behind the two-phase commit protocol. A pizza order received by the FulfillOrder port will at one time result in the action of a pizza being shipped, while at a different time the same pizza order (a duplicate) with the same semantics should result in the action of the the order being ignored. Thus, although the uniform interface constraint may *encourage* the design of systems with self describing message semantics (because they discourage you from designing an SendPizza interface that ships pizza upon the receipt of a "do it" message), I do not think that self-describing message semantics are *dependent* on using a uniform interface. That seems to me to be a different issue. David Booth [EMAIL PROTECTED]
