Last October we ran a SOA workshop in Redmond, with the goal being to have members of the MCS field, global practices and other customer facing organizations discuss scenarios and patterns that they see on a regular basis. Having run several of these workshops in the psat, one challenge that is hard to overcome is ensuring people describe their scenarios and solutions in a standard way.

Given the lack of a standard vocabulary for many (most?) domains within our industry this is obviously made more difficult. In an attempt to overcome this shortfall myself, Piyush Gupta and Sudarsan Srinivasan spent about a month decomposing a number of customer solutions into their constituent patterns - thus building a catalog of patterns that participants at our workshop could use when describing solutions to their scenarios. Where such patterns were already documented, we normalized on terms from sources such as Hohpe's Integration Patterns, SOA Patterns, Workflow Patterns, Patterns and Practices and IBM's dev center.

Even armed with a standard vocabulary, the next problem becomes how do you succinctly present complex system designs without requiring large numbers of UML objects. Christopher Alexander aluded to the solution to this problem through the use of a visual notation to accompany each pattern. So I searched around and found that Matthew Oskowis had created a nice little Visio template including icons for each of Gregor Hohpe's patterns. This helped us for about 50% of the patterns and so I extended it to include the additional patterns that we had identified.

When using this visual notation it became too difficult expecting everyone to recognize each of these icons, so I also extended each icon to include the pattern name. It makes the diagrams a little clumsy - but they are still quite readable. As you can see in the diagram below it is also obvious that these icons convey a lot of information in a small amount of space - more so than an equivalent UML model would for example. 

The diagram below illustrates one such example, where a service agent is performing requestor side caching allowing configuration information to be retrieved from a central configuration service and cached. The Configuration Notification Service also allows the client (should it subscribe) to be notified of changes to this configuration.

Requestor side caching

For my presentation for tomorrow's SOA BP conference I will be walking through a number of scenarios using this SOA DSL, so figured I would first post it on the blog for people that are interested in using it. If you use it or extend it let me know how you go, or share your updates.