Re: [service-orientated-architecture] ZapThink needs help: Sample contracts?

[Keith Harrison-Broninski]

Hi Ron Out here in the wilderness beyond US borders, people are reasonably familiar with "these" Role Activity Diagrams (RADs).   I have both personal experience and ancedotal knowledge of RAD use in many organizations from 1990 to the present: Glaxo, Rolls Royce, Sun Microsystems, the UK Armed Forces, various other government bodies, etc etc etc. Both supporting and deriving from this industrial use, there is an extensive literature dating back to 1983: four books have been published in the last 10 years alone (Ould [1995], Warboys et al [1999], Ould again [2005, in a book published by the British Computer Society and endorsed by BPMI] and my own book [2005, which is being developed into an MBA course module in India] - and Google will turn up any number of papers/articles.  Until now, however, widespread acceptance of the technique in the IT industry (as opposed to the business community, which has always liked RADs) has been hampered by problems relating not to the notation itself but to the semantics by which they were traditionally interpreted, which prevented tool support from being developed.  These semantic problems are ironed out in my own work, which both enhances the theory and provides practical support via software. Anyway, you asked for example RADs.  There are several examples in the report of the Process Modelling Group from June 2005: http://www.bptrends.com/deliver_file.cfm?fileType=publication&fileName=09%2D05%20TB%20Proc%20Modelling%20Group%20Workshop%20Eindhoven%20June%202005%E2%80%A6%2Epdf or if the link above breaks due to word-wrap: http://tinyurl.com/83huc This international forum is focused on RADs alongside BPEL and CDL as the way forward for process modelling in industry.  The processes examples in the document do not relate specifically to SOA, though they could easily be implemented via Web services (for example).  But my point is that the sort of contracts you need are not specifically about SOA!  They are general "agreements" between process participants, of the form "if I promise to do this, you agree to do that, within such a time and in such a way".  Agreements like this: Can be of any form imaginable Tend to change throughout the life of a long-running process A general solution has to be founded on universal principles for process modeling and management, not on a specific technology paradigm such as SOA.  If I get the time I will try and do some examples more closely related to a mechanistic WS scenario.  But I don't think this is the point. -- All the best Keith http://keith.harrison-broninski.info Ron Schmelzer wrote: So, do you have any concrete and real-world examples of Role Activity Diagrams? We see a lot of talk about contracts in academia and theory and analyst-speak (we do lots of that, too ;) But, this time around, we want practicality. So, I put it on the table for you Keith: do you have any real world examples of these Role Activity Diagrams and how to specifically map it to the problem at hand with Service contracts? Theory is great, but customers want real stuff now. Best, Ron Keith Harrison-Broninski wrote: Ron I would say that the metadata you describe are all business process issues rather than technical ones.  We deal with them via the construction of "Role Activity Diagrams" that describe an agreement between parties on the future operation of the process.  The diagrams are not IT but business-oriented - moreover they are generally very concise and simple for anyone to understand. If Gervas will forgive a plug in this forum, my recent book provides a complete methodology not only for construction of such diagrams but for using them to manage process change.  The book provides various examples of agreements between parties, although these tend to be focused more on human-human collaboration than on the system-system collaboration typical of current SOA implementations.  However, we did use the technique with success in a mechanistic financial services application based on SOA, although unfortunately the details are confidential so I can't supply them for your research.  There are links to books and articles describing the method at: http://www.rolemodellers.com/abstracts -- All the best Keith http://keith.harrison-broninski.info Ron Schmelzer wrote: >Hi All -- > >As you all know, one of the key parts to making loosely coupled Services >work is a well-defined contract that identifies both functional as well >as non-functional requirements for Service providers and consumers. By >now, you also probably realized that WSDL by itself is not sufficient to >provide all the metadata needed for loose coupling and late binding. >Other metadata are needed including security, semantics, QoS, SLA, >process, etc. > >So, what we are looking for are actual examples of real-world contracts, >or templates for contracts that you are using in real-world SOA >deployments, or at the very least, guidance for how those contracts can >be defined. > >So, help anyone? > >Thanks in advance! >Best, >Ron SPONSORED LINKS Service-oriented architecture Computer monitoring software Computer and internet software Free computer monitoring software 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.