Re: The stack diagram (was RE: Discussion topic for tomorrow's call

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

George wrote:
| <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>
Hmm ... Not sure ...
Generally stack layers could be views in both ways as layers where the
lower one provides a service accessible via defined interface to the
upper one (the ISO-OSI example) but also as architectural layers where
the upper one resides on the lower one using some kind of abstracting
usage relationship.

Thus I absolutely agree to Eric that the relationships sould be
expressed as definitional relationships.

I'm not clear if the wording "Services" is appropriate here for the WSDL
including layer. Doesn't this imply that there is no service without
WSDL which is certainly untrue.
We don't we stick to the old "Description" label here?

"Processes" sounds good and is more clear than "Aggregation" here +1.

But the diagram is leaving out (intentionally?) our discussion that
there are Web Services which are not using WSDL at all.
I therefore suggest keeping the view wich embraces Messaging by
Description and Description by Processes.


Concerning the base technology topic I'm not sure if it is clear to the
user why we're repeating the very same wording three times (although it
is technically correct).
Furthermore the instance of base technology is used by all the more
specific layer, i.e. the same schema language instead of a fine tuned
problem specific schema language at every different layer.
Therefore I suggest to keep the notion of one base technology layer and
relate all layers to this instead of repeating the same string multiple
times and stating outside the diagram that it always means the same.

What about Hugo's suggestion to show explicitly transport's influence to
the SOAP layer?

I adapted my last diagram proposal to the new wording and attached it.

Further I suggest to drop the mentioning of DTDs which are currently
mentioned inside the Base Technology layer and introduce XMLNS
(Namespaces in XML) instead of it.


Savas wrote:
|I would be tempted to raise the security and management boxes so they
|don't expand all the way down to the transport protocol layer. At the
|same time, I would widen the transport protocol so that is the only box
|at the very bottom.
Sounds reasonable. Especially since pure transport layer security (like
SSL or IPSEC) proves inadequate for securing Web Services in many cases.

Cheers,
Mario


- --
Prof. Mario Jeckle
University of Applied Sciences Furtwangen
Dept. Business Applications of Computer Science

W3C Representative of DaimlerChrysler Research and Technology

URL: http://www.jeckle.de
MailTo:mario@jeckle.de
MailTo:jeckle@fh-furtwangen.de

My public key: http://www.jeckle.de/marioJeckle.pub
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+nNEa46tt20EwGqwRAg+dAKDpQ3nkMr0K/gv9iFKBxyNtQ+xyEwCgpLCX
9kRsiQNtPogdATGZFy1SuOQ=
=U7KL
-----END PGP SIGNATURE-----