<snip>
A stack diagram implies a layered design pattern (think OSI stack), which
indicates that the layer on top calls the layer below to further the
process. It's a runtime processing diagram. It seems to me that we're trying
to convey too much information in this stack diagram. (combining runtime
processing with other things)
</snip>
I believe that you are correct in concluding the multiple purposes behind
the WSA stack diagram but the statement about the use of a stack diagram as
runtime relationships is not necessarily true. The key message behind the
WSA stack may not be "runtime" but "definitional" relationships. There
will be several/many runtime variations of how these components are employed
but generally within these same structural relationships. But I would start
with four boxes and the two pillars very much like Hugo's diagram:
Label for Box 1. "Processes" (rather than aggregation); Content: "Examples:
Discovery, Aggregation, Choreography..."
Label for Box 2. "Services" (rather than description) Content: WSDL Service
Descriptions
Label for Box 3. "Messages" include two boxes within Box 3a "SOAP
Extensions" Box 3b: "SOAP"
label for Box 4. "Transport" Content: "HTTP, SMTP, JMS..."
Pillar A: "Security"
Pillar B: "Management"
Base technology of 1-3 is XML shown either as a backplane or just included
explicitly inside each box as "Base Technology: XML". We do like to
"factor" XML out separately but I don't think it would offend if it where
just spelled out within each box but a back plane is more expressive.
I have included an example below.
George Blanck
gsblanck@nyc.rr.com
x$0 Associates - System Architecture and Design
