Oh god. So the concept of atomicity is that a service is a single method doing a single task and thus you have what?
The answer of course is a whole lot of weeds and little organisational structure. One bit I say in the book is that if you get to a service called "GetX" then you've gone one level too far. The theory is that these low level items become easy to combine in multiple ways but the reality is that the cohesion that you get at this level is far too low so either you have to artificially separate elements which takes excessive effort or you just face the fact that you have increased coupling behind the scenes. Where this approach does work (IMO) is when looking at Data for combination within a Mashup environment and as a mechanism around determining URIs for REST as that is a more fine grained approach but I'd argue that even there it works well for GET but poorly for POST. Steve 2009/4/20 Gervas Douglas <[email protected]>: > > > Doug Barry > > <<Processes that cannot be decomposed or factored further are used to > construct composite services of appropriate granularity. How many times have > you read a statement like that related to the design of a service-oriented > architecture? How many times have you been given a rigorous definition of > atomicity – that condition where processes cannot be decomposed further? My > guess is your answer to the first question is something along the lines of > "too many times to count" and your answer to the last question might very > well be "rarely or not at all." This column will provide a rigorous > definition of atomicity and a way to determine the correct granularity of > services based on atomic processes. > > Here's a rigorous definition of atomicity: Software atomicity occurs when > each input to a process is used to create one or more outputs from the > process. This definition, based in mathematics, has been around a long time. > One way to use this definition is to construct a matrix with inputs as rows, > outputs as columns, and then mark the inputs used by each output. An atomic > process will have all cells of the matrix marked. > > Although a matrix is an easy, back of the envelope, way to determine > atomicity, you can end up fooling yourself using this approach. It is easy > to rationalize marking all the cells of the matrix after you have completed > what you think is the correct decomposition. So, even if using a matrix for > atomicity provides a rigorous definition, it has a practical or > psychological flaw that limits its usefulness. > > In the 1980s, Mike Adler, a colleague of mine, addressed this flaw by > inverting the use of the matrix. Mike used the matrix to create the > decomposition instead of using it to check the decomposition. In order to > create the decomposition, Mike developed a specialized algebra that acts on > the matrix. > > In recent years, I have revisited Mike's research as it has become > increasingly obvious that people are struggling with less rigorous > definitions of atomicity – and even more difficulty with common definitions > of granularity. Mike's decomposition algebra, however, is a bit obtuse and > difficult to use with pencil and paper. So, I decided to program his algebra > – with some enhancements – and you can use it for free at Design > Decomposition. At that website, you can complete a matrix that will then > generate either business process or data flow diagrams. The latter is used > to represent services in an SOA. > > I've found several accidental benefits that are derived by starting with the > matrix rather than a diagram. First, it allows another way for non-technical > people to get in on design process. This appears to be particularly true for > business process diagrams. People who understand their jobs can usually > decide if a matrix cell should be marked based on whether or not a given > input occurs before or concurrently with a given output. They do not need to > be able to read, for example, BPMN diagrams. Such diagrams can be > challenging for some people. Second, for folks in IT, it is a way to manage > understanding complexity because you need to make only one binary decision > at a time: does a given input affect a given output in a single cell of the > matrix. Finally, sometimes people are surprised by the suggested > decomposition. I've come to think we, as designers, tend to repeat what has > worked for us before and can sometimes be blind to an alternate > decomposition. > > So, to get back to the definitions, I'm going to use the following figure > that was generated from a matrix using the decomposition algebra. [CLICK TO > ENLARGE] You can see the matrix and other details at Design Decomposition > Blog. This is essentially a visual depiction of the definitions. All the > processes in this figure are atomic. The decomposition algebra guarantees > that. > > To construct composite services from this figure, you need to determine > which of the external flows are used by atomic tasks in your business > process diagram (or its equivalent). For illustrative purposes, let's say > the top layer of processes relate to different tasks in a business process > diagram. Each of these becomes a service. The shared processes in the figure > below the top layer would most likely be more efficiently implemented in > some way other than as services. Nevertheless, at some later time, should a > business task need to access a lower level process as a service, that > process could then be factored out as a service. By following this pattern, > services always have the appropriate granularity to go with the business > process diagram. > > This technique provides atomicity for a design and a visual way to determine > the granularity of services. It should work with most methodologies since > all it does is suggest a decomposition that a designer can choose whether or > not to use. I am still tinkering with the decomposition algebra and its > implementation, so I invite anyone who tries the website to give me > feedback.>> > > You can read this at: > http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1354005_mem1,00.html > > Gervas > ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[email protected] mailto:[email protected] <*> 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/
