People need diagrams - they really do speak louder than words (or symbols). My own experience is that you need a diagram not only to explain a design to others, but to create it in the first place. And I expect most people feel the same way - Todd speaks for us all, in a way.
However, a diagramming notation alone really is not enough, for two reasons:
- As Steve says, without a formal semantics a diagram is (by definition) meaningless. In the end, an informal diagram is just scribble - and hence subject to the familiar software development game of chinese whispers. How many times have you dealt with "but that's not what we asked for" shortly before a project milestone? Too many times, I bet, if you're honest.
- However, you cannot embed enough semantics into a graphical notation without making it so cumbersome that it loses its primary quality - of being usable. One notation that suffers badly from this is BPMN. 20 types of event? What business person (or even analyst) is going to be completely familiar with all these?
Those who have been following my recent writing will know that, for this reason, I see a natural convergence of Steve's work on WS-CDL with my own on Role Activity Diagrams and their extension into a full process execution system. I am not sure what form this convergence will take, but it does seem to be on the cards.
-- All the best Keith
http://keith.harrison-broninski.infoSteve Ross-Talbot wrote:
Todd, from your diagram and the text I could not possibly guarantee that I could implement it because it is ambiguous and incomplete with respect to any message exchanges between the services. My point all along is that we need to move on and figure out a better way of describing the interactions because that moves us along the path to understanding a systems behavior. Describing a systems behavior in terms of the roles (service definitions if you like) and the interactions between roles and the ordering and dependencies between those interactions (even if it is from an externally observable perspective) is what is needed to ensure the thing does what is described. Diagrams and annotations just do not cut it.
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
