Digestion underway

Ok, so here’s the diagram again:

In the first column we can see the controller swim-lane. The Total Request message object drawn in this swimlane is constructed by the Controller.

Arrow (1) shows that the Total Request is passed to the Invoice object (which has a black dot for receipt and/or dispatch of a single message object)

Arrow (2) shows passing the Total Request to one or more Line Items

Arrow (3) shows passing the Total Request to the Tax Calculator

This captures the message flow, but it doesn’t show the details of the message. Nor does it show how each object interacts with the message.

Is that important?

Yes – the message is essentially its content. The semantics are embodied not only in the name type of the message, but also in the content of the message.

I’m calling this a message content diagram and the idea is that it supplements the message flow diagram (above).

(1) On the first line we can see that the Controller sets the Amount to 0 before passing the message to Invoice

(2) When the Invoice passes the message to the line item(s), the Amount gets updated by adding the line item amount

(3) When the Invoice passes the message to the tax calculator, the Amount gets updated by adding the tax total which is a function of the original Amount

I think this works quite well. I’m still not showing the public method names, but there’s a suggestion of the business logic within Tax Calculator: calculating the tax total is a function of the amount in the message

Now that I’m messing around with this, it occurs to me that the SOA guys already have the idea of MEP (Message Exchange Patterns). I ought to check-out what Mr. Erl’s been up to with his diagramming stuff. Tomorrow.