Totally agree. The next challenge that confront WS-CDL'ers is to map WS-CDL into various useful and well accepted graphical grammars. That work is being done (Howard Foster at Imperial as well as Pi4Tech). So I am hopeful that we shall make rapid progress. It would be good if others joined the bandwaggon and added to the pool of open source plugins to do this sort of thing. Anyone fancy doing WS-CDL2BPMN and WS-CDL2RAD? Now that would be progress.
On other comments, Alex in particular, I think that it is laudable that you want to understand more. And more can be provided. I shall certainly post a link later on showing an initial mapping of WS-CDL to pi-calculus (Carbone et al). We are (WG at W3C) working on a primer to help people understand WS-CDL better. The open source tools present a much more convenient and more intuitive view of WS-CDl hiding much of the complexity, after all no one really want to write XML do they? So I shall certainly rise the challenges and provide further information. I hope that you folks will also take a look at provide critical feedback. It is only through peer review that we can really deliver the value we aspire to. Cheers Steve T On 23 Mar 2006, at 09:42, Keith Harrison-Broninski wrote: > Both Todd and Steve are right, imo. > > 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: > 1 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. > 2 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? > We need WS-CDL, but we also need a simple graphical notation as a > human interface to it. This notation must (like WS-CDL) be based on > Roles and Interactions, but also have a powerful formal semantics that > extends beyond the graphical symbols - powerful enough to permit the > modelling not only of process execution but also of the various forms > of process management. > > 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.info > > Steve 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. > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
