SOA in a Virtual World

Wikipedia defines a virtual world as a computer-based simulated environment intended for its users to inhabit it. Often a computer application is a business process made virtual by the use of computer technology. We therefore have to be careful when discussing the virtualization of computer environments as this may imply a virtual virtual reality.

The only example of virtual virtual reality I have seen is in a Futurama episode. It displayed an arcade booth with the label 'Virtual Reality' complete with a player using stereoscopic goggles and wired gloves. It then displayed another arcade booth with man sitting in a simple chair imaging he was wearing stereoscopic goggles and wired gloves. The caption to this booth was "Virtual Virtual Reality".

If we talk about "Virtual SOA" we must be talking about something that is not an SOA at all. Judith Hurwitz comes close to this when she discusses a "Virtualized SOA" in her article "Is virtualization the foundation of SOA?"

Andrew Doble writes about building a virtual SOA without investing in in-house software like an ESB. I would argue that this is in fact legitimate SOA. The only thing "virtual" about Andrew's suggestion is the ownership of the software tools.

Virtualization and SOA however do go together. Judith Hurwitz defines Virtualization as

"a technique for abstracting the physical characteristics of computing resources
in order to more easily leverage hardware systems, applications, operating
systems, networks, graphics, data or storage so they can be repurposed based on
customer need."

I believe that loose-coupling is the foundation of SOA but virtualization in many cases allows the benefits from this loose-coupling to be realised. The basic examples of virtualization are virtual servers, storage area networks and thin client platforms such as Citrix. These provide infrastructure flexibility for the deployment of SOA software. The design of the software for an application written using SOA is not affected. The SOA discipline should make sure that flexible deployment options can be used.

Manufacturers such as IBM are building business around SOA infrastructure. One thing to remember is that you do not need virtualization to build SOA. An SOA application can be built on a single server if you required, although it should also give you the flexibility to distribute this application and take advantage of virtualization options.

I agree with Lorraine Lawson in her posting "SOA and Virtualization: Complex, Fuzzy Ideas That Go Great Together? ". These two concepts mix well. However SOA is from the software development world and virtualisation is from the infrastructure world. We should beware of talking in terms of virtualizing our SOA. Our CIOs may consider we are sitting in a corner thinking we have an SOA when this is just a virtual reality.

Fry from "Futurama" with a virtual Lucy Liu.

© 2001 Twentieth Century Fox. All Rights Reserved

Coupling Calculus

I have had thread going through this blog on Coupling. Coupling is important because good definitions of SOA are dependent on the concept of 'loose coupling' or more precisely, 'message coupling'. The thread so far has included the following postings:

Cohesion, Coupling and SOA
Bragging Rights on Coupling
AOP: The Worst Form of Coupling
Binding and Coupling
Subroutine Call Coupling
Seven Levels of Coupling or Seven Deadly Sins?
Coupling with Contracts

In the first posting of this series I went back to the origins of the coupling term that was coined by Edward Yourdan to explain good programming practice in terms of subroutines. I then tried to come up with a list of coupling types which would help explain what were good and bad form of coupling.

This served to clarify the concept in my mind but the list of coupling types is not exhaustive and term 'coupling' is still not clearly defined. Coupling is a measure, usually described as 'loose' and 'tight' which correspond to the value judgement of 'bad' and 'good' respectively.

A good measure has numbers that describe it, but this is not yet the case with coupling. I and other authors have attempted to rank coupling types in order of merit with the ranking an implicit measure of coupling.

There have been attempts to measure coupling by looking at program artefacts like variable names and measuring how many times they are referenced. These attempts seem to miss the point by measuring what can be measured rather measuring coupling properly. Some of these approaches are described in footnote 1.

In this posting I try to suggest some definitions relating to coupling. This will not come up with useful numbers but it will try to explore the concept of coupling and may be a basis on which more theory can be developed.

Coupling is about how easy it is to change applications. If one part of an application (module) has to be changed because another part of a program changes then these program parts a tightly coupled. If one module does not have to be changed for changes made to another module then these application modules are loosely coupled. There are a number of programming practices that can be put in place to loosen the coupling between modules. This is good because it reduces the effort required to maintain your code.

The above would seem to be a fairly elementary description. Definitions however can still be made more precise, so that the concept can be analysed in more detail.

Lets say we have two modules A and B in a system S. The number of changes that can be made to A can be defined as C(A).

We can make changes to A because we want system S to do something different, or we can make changes to A for other reasons. We might want S to be produce results more quickly or we just might want A or S to be reorganised to be more easily comprehended. A change to A might not mean any change the output of S.

In order for A to be changed and the result of S to be changed to a desirable result (which may be an unchanged outcome for S) then in some cases some module B would have to change as well.

The coupling between A and B is defined as the effort required to make changes to B as a result of these changes A. For change j then there is work (and cost) associated with this change for systems S say Wj(S). The work in module Wj(A) and module be Wj(B).

Coupling then can be defined in terms of an individual change
Coupling(j) =the work required in B to make change j as a result of the change in Aj.
Coupling(A,B) is the sum of all work require in B for such changes j.

This leaves the concept of 'Coupling Type' to be explained. A system can be organised to reduce coupling between A and B. A coupling type is a way of organising the system. Some ways of organising will mean that a change to A require changes to B. Some ways of organising will mean that B can remain independent of changes in A. Some ways may increase or decrease the work involved in making changes to B when A is changed.

In general a way of organising a system S is O(S) which is another system which produces the same results. This is a change to the structure of the system rather than a change to the outcomes of the system. If we wanted to measure the coupling of a way of organising O then 'all' we have to do is sum all the Coupling(A,B) over all such S, A and B. A coupling type describes a number of ways of organising a system. The coupling associated with a coupling type is therefore the sum of all the Coupling (A,B) over all these ways of organising S.

To express this succinctly:

Coupling between two modules (A and B) of a system (S) is the work required to make changes to a module (B) as result of changes to another module (A) and still produce the desired outcome of a system (S).

A coupling type is scheme for organising the system (S). A measure of the coupling of a coupling type is the sum over all A and B for systems S which conform to this coupling type.

These technical definitions of coupling describe big, practically incomputable numbers. The conclusions we can draw though are

• There is nothing really special about a coupling type. There could be a very large number of these and they are not confined to simple statements about how to pass parameters between modules. My earlier posting attempting to count these is inherently futile expect to provide common examples.
• Coupling is about work relating to a change. I have not defined what I mean by 'work' intentionally. We could count lines of code changed or look at whether logic or data is changing. We count the costs of making these changes (eg. Hours of labour). It is meant to be used in its common sense. If it is necessary to trawl through technical documentation to make a change to one line of code this is still consider then the trawling effort should be consider as part of the work expended for this change.
• Coupling is about systems in general. It is not just code instructions that are relevant. You might have to change constants, configurations, contracts or XML. These need to be considered in the concept of coupling.
• The concept of coupling is relevant to systems theory examples outside of the field of computer science. Systems can also refer to biological or sociological systems (See footnote 2).
• A change may not actually change the behaviour of the system at all but it is still relevant for coupling.
• Coupling at its most elementary level looks at two particular modules, a particular system and a particular change. Thus it sensible to say A is tightly coupled to B in a system S in relation to change j.
• Coupling can aggregated up to the module or level or to the Coupling Type level. Thus we can have A loosely coupled to B. We can talk about a Way of Organisation or a Coupling Type as facilitating loose coupling.
• Restriction have not been placed on A and B. Therefore if B=S we can have A tightly coupled with the rest of the system S. A and B could intersect or A could be a sub-module of B.

It is still important to describe different coupling types and to determine what types promote loose coupling and what types do not. Good practice will reduce coupling for common programming changes.

To determine whether one coupling type is better than another the above suggests we need to enumerate all possible changes and work out which type leaves you with less work involved in one module as result of changes in another. This is obviously impractical but the analyst can do a couple of things to determine a good coupling type. A range of typical changes can be investigation or the coupling type can be looked at in relation to a specific type of change. For instance the benefits of message queuing can be looked at in relation to changing the location or speed of hardware.

This posting has added some precision to the concept of coupling. Counting all the possible ways to change a system is futile, however good and bad coupling will be become evident by looking at coding examples and foreseeing the changes that will be required to any system.


Footnote 1:

The following web pages describe metrics for coupling. These can be based on a static analysis of code or a dynamic tracing of the execution paths. In both cases the emphasis is counting the reference to a variable or type. This has some value in the task of maintaining code but is not a measure of the work required to change one module based on the need to change another. In some cases there may be some correspondence between the amount of work in changing the use of the variable with the number of times it is reference but not generally.

Lethbridge, Timothy C. and Anquetil, Nicolas, Experiments with Coupling and Cohesion Metrics in a Large System, April 2000, https://www.site.uottawa.ca/~tcl/papers/metrics/ExpWithCouplingCohesion.html

Poshyvanyk, Denys and Marcus, Andrian, The Conceptual Coupling Metrics for Object-Oriented Systems, http://www.cs.wayne.edu/~vip/publications/poshyvanyk-ConceptualCoupling.pdf

Glover, Andrew, In pursuit of code quality: Code quality for software architects: Use coupling metrics to support your system architecture, April 2006, http://www.ibm.com/developerworks/java/library/j-cq04256/
FrontEndArt describes one of its products for montoring source code quality include various metrics for coupling, http://www.frontendart.com/monitor/help/node22.html
Diederik Krols provides a blog-site archive which includes the postion "OO-Metrics for Coupling". This provides a coupling metric based on types shared across a module boundary. http://dotbay.blogspot.com/2006_01_01_archive.html

Footnote 2:

The concept of "structural coupling" in systems theory is used to describe co-evolution in biological and social systems. This is where, if entity A evolves then entity B might need to evolve to compensate. There would seem to be more complicated processes at play here than in a computer application.

Kay, Robert and Goldspink, Chris, Towards a Complex Non-linear Systems Theory of Organisation, http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-72/044%20Kay%20Complex.pdf

Coupling with Contracts

I listened to a podcast by Thomas Erl yesterday which gave yet another slant to the subject of coupling in SOA. My previous posting about coupling was inspired by a Zapthink arcticle on "The Seven Levels of Loose Coupling" seven levels of coupling. The Thomas Erl podcast provides more information on at least three of the seven levels described by Ronald Schmelzer in the Zapthink article. These are

• the coupling between the service consumer and the services implementation,
• the coupling between the service consumer and the service contract, and
• the coupling between the service consumer and the business process

In his podcast Erl asks the listener to refer to a diagram on his "SOA Principles" web-site. The types of coupling he focuses on in the podcast and the diagram are:

Service consumers are coupled to the service contract

• The service contract can be coupled to a parent business process
• The service contract can be coupled to the service logic
• The service logic can be coupled to the service contract
• The service logic may be coupled to proprietary vendor technology
• The service logic may be coupled to multiple services it may need to compose
• The service logic may be coupled to various resources that are part of the overall implementation environment

These coupling relationships broaden the possibilities explained in the Zapthink article. Firstly all the coupling relations are not based around the service consumer and secondly the coupling is not a symmetric relationship. Erl explains that it is good to couple the logic to the contract as this is contract-driven development but poor practice to have the contract tied to the logic of the service.

The multitude of coupling relationships was referred to in my earlier posting. When discussing coupling, it is important to be clear on what is being coupled when explaining service coupling. Zapthink discusses implementation, contract, policy, business process, data schema, infrastructure and semantic layer. What Erl describes is the service logic is part of what Zapthink describes as the implementation. Erl does not describe policy coupling. The data schema is part of the implementation environment and the infrastructure could be vendor technology.

I would prefer to keep coupling as a symmetric relationship. In other words if logic is coupled to contract then contract is coupled to logic. Erl is trying to cover methodological issues when he talks about contract-driven development. This is an important 'pattern' but it is not about coupling. It is about what a developer does first. The fact is that the contract and the logic are coupled and if this coupling can be made loose then that will provided more flexibility.

The focus of the Zapthink article is on the coupling with the service consumer. Erl has a twin focus on the contract and the service logic. My previous discussions on coupling tended to focus on coupling between services (or program modules). I tend to think that most important coupling concern in SOA is between the consumer and the service implementation in SOA. The consumer may be a user interface or another service. Contract coupling is important but it is more of a vehicle for loosening the coupling between consumer and provider.

One strength of the Zapthink article is that it has enabled me to analyse the Erl model. As is usual for Thomas Erl, his illustrations provide some clarity to a complex interaction of concepts. In this case his diagram should be taken as a sample of the coupling issues rather than a representation of all of the coupling issues relevant to SOA. Also as discussed above I suggest we stick with a symmetric notion of coupling to keep the world of SOA a simpler place.

Does normalization apply to Services?

I was listening to a podcast by Thomas Erl this week where he was talking about a pattern for normalization of services. This was interesting because there is not much in SOA with the same theoretical rigour as database normalization inspired by the work of Edgar Codd in the 1970s and the relational algebra and the Structured Query Language (SQL) that followed it.

The normalization that Erl talks about is fairly limited. On his website he summarizes normalization as

Problem
When delivering services as part of a service inventory, there is a constant risk that services will be created with overlapping functional boundaries, making it difficult to enable wide-spread reuse.
Solution
The service inventory needs to be designed with an emphasis on service boundary alignment.

There does not seem to be a lot of science involved in decomposing services to their basic elements so they can have maximum reuse and be easily composed into higher level services. Perhaps more precisely it is a 'soft' science that is all about governance, process and aligning with user requirements.

Normalization of services is not something that has been picked up strongly by other authors however David Chappell has his description of the normalization project which is consistent with Thomas Erl:

An idealized SOA environment provides a cleanly delineated set of services,
with one way to accomplish each function. This kind of normalization makes reuse
self-enforcing, since each service provides access to a specific group of
information in a specific way.

In his podcast Erl gives an example. If we have a service to get an invoice, then it is redundant to have a service or a method to get an invoice header. To have both is not normalized however there are reasons you may require both and therefore this would be 'denormalized'.

I am a little critical of the use of the term 'normalisation' to describe removing service redundancies. The processs of normalization in data modeling (and mathematics such as linear algebra) is a very precise and well developed technique where the concept used by Erl and Chappell while useful, is fairly loose.

If we wanted to do the equivalent of first normal form in service interfaces we might consider getting rid of the service equivalent of the "repeating groups" that destroys the relational model. If there are many 'invoice items' for an invoice, this means you could not accommodate 'invoice item' in your 'invoice' message. The strength of SOA relies on being able to exchange documents that mean something to the user. This is where attempts to get scientific about normalization fail the cause of SOA.

I will take this normalization discussion to its absurd ultimate. When I did my final year of my honours degree I simulated hardware that consisted entire of only two elements. They were the 'Nand gate' (logical not(and (a,b)) ) and a single binary digit of memory (Flip flop). The computer program that ran on this simulated hardware was simply a wiring diagram. Any computer program that can be represented in normal programming languages can be represented as a combination of these two elements. The sort of programs I ran on this simulation were the full adder, 4 bit timer and 3 bit shift register. Programming at this level is more a level in elementary digital electronics than it is in software development.

This was a distributed network of "services" at the very elementary level, but it is not very useful as a software development approach. This is a completely elementary normalized distributed application that can not be reduced further. This could be described as the ultimate implementation of reuse. You only have two 'services' (Nand and memory) both of which are reused constantly. The challenge is to link them together in meaningful ways. These services however are tightly coupled because of their synchronous nature and therefore this is not an SOA.

As a programming language this is worse than assembler language. Trying to wire gates together is even more detailed than assembler coding. Even if we could get SOA performing brilliantly at lower levels of granularity we do not want to go to such a low level of granularity that business entities are unrecognizable.

Beware dogmatic approaches to normalizing or simplifying a service inventory. I suspect the MEST architectural style with its focus on removing verbs or methods is heading down this type of reductionist thinking.

An overriding concern should be to meet business requirements and this might mean implementing redundant services and poorly structured business documents in services. Designing with a focus to eliminate redundancy is a good idea. It is nevertheless useful to seek out redundancies and investigate the option of reducing these if it does not compromise the ability of the services to represent business processes. Too much science in this process can reduce your services to absurd solutions.

Reference:
Kimber, Antony, The General Logic Array: An Abstract Architecture, Honours Report, The University of Adelaide, Department of Computer Science, November 1985.

This posting may have seemed a flimsy excuse to expose this work to the public domain but I hope it has described a useful anti-pattern for SOA.

The above project was done around the time Sun were having success introducing their Reduced Instruction Set Computer (RISC) chips which included simpler instruction sets that performed more quickly. Reducing down to a couple of elementary components is the extreme end of this strategy. There was also early interest in molecular electronics with the hope that if we could get molecules to behave as electronic components we could produce very small electrical circuits. One of the challenges of the project was working out lattice arrangements that would allow the appropriate connections to the two or more types of elementary components to be made.

Book Review: Loosely Coupled - The Missing Pieces…

This is a review of the book "Loosely Coupled: The Missing Piece of Web Services", by Doug Kaye. In a previous posting I expressed delight that an author had dedicated a book to this important topic. This perhaps is not the definitive book on loose coupling but there is plenty of value for the reader.

Doug has an easily readable style and sticks to a high level but there is enough technical substance to keep and IT architect or IT manager interested. You will find no code snippets and no programming standard specifications described in this book but there are some good diagrams and deep insights into SOA and how an organization should deliver SOA.

This book was published in 2003 and I kept expecting the information to be dated. There was no mention of an Enterprise Service Bus (ESB) but Doug Kaye describes a number network models, mediation tools and deployment options which have been incorporated into what vendors now label as an ESB. More importantly some of the missing pieces he describes in 2003 are still missing at the end of 2007. Security, transaction integrity and business semantics still do not have accepted solutions within SOA and these missing pieces are described in this book. The WS-* standards have progressed somewhat since the writing of "Loosely Coupled" but basics of SOAP, WSDL and UDDI were in place and many for the WS standards are foretold.

Doug has good perspective on what is required in the corporate world. He advises everyone to have your "elevator pitch" ready for that occasion when the CEO gets into the elevator with you and asks something like "So what's this I keep hearing about web services? What are they and why are they so important" (p27). Doug offers a response that suggests he is either a fast talker or works in a building that is much taller than mine, but the concept of having something ready like this is important if you are going evangelize about web services.

There is only one chapter dedicated to Loose Coupling and Doug has not tried to say everything there is to say on the subject. This justified in his statement "…loose coupling is a methodology or style, rather than a set of established rules and specifications" (p. 131). Figure 10-1 provides a table describing 10 types of coupling and descriptions of tightly and loosely coupled approaches to each. This is a good approach as it is not easy to describe coupling succinctly. I found this approach in another posting although interestingly the contents are different. I have found that in my previous posting that it is difficult to label types and coupling and the three column approach will enable me to do this more effectively. The book covers late binding, heterogeneity, routing and transformations well.

It is true to say that this book is more to do about its subtitle "The Missing Pieces of Web Services" than Loose Coupling. Doug makes the bold prediction that when we have solved all the pieces of the puzzle in the future that it will be so commonplace that "Web services won't be mentioned by the IT trade press, and the topic won't be tracked by analysts". The book searches through these missing pieces in most of the chapters. The fact that Web Services is still a strong topic for analysts and vendors is evidence suggesting that we have not yet found all those missing pieces.

Doug Kaye provides a good description of transaction control although I found the book I read earlier by Krafzig et al to have more detail in this area. Doug has two strong chapters on the problems of web services security and covers this topic in a thorough and systematic way. A couple of reviews have suggested that the book by Mark O'Neil also provides good coverage of Web Service security.

The chapter on deployment option talks about commercial opportunities for third parties in the delivery of services and services infrastructure. This discussed Web Service Networks, Distributed Web Service Networks, Web-Service Delivery Networks and Web Service Providers. Doug takes the service vendor view in his final chapter on providing external services. Both these chapters had little relevance to me. Four years after this book was written I have not been flooded with vendors wanting to sell me services or wanting to host infrastructure for me to operate my web service applications. Perhaps the money is not there, or perhaps it is just easier to use open source products or set up our own infrastructure. I still think Web Services provides some opportunities for commercial intermediaries, but until the vendors are out there and dealing in the government sector it will be difficult for me to get excited about this topic.

Doug writes a couple of good chapters on the management of simple and complex web services projects. In particular he deals with timing the project around web services approaches that have not yet been delivered. The chapter on Service Level Agreements (SLAs) was an important piece of the completion of the web services picture.

The book concludes with a number of checklists that anyone embarking on an SOA project should refer to. This should help the SOA project manager get their ducks in line to navigate the difficult road ahead.

In summary, this was a well written book about the evolving phenomenon of Web Services. There are some valuable insights into Loose Coupling but an exhaustive technical treatment of coupling and the programming patterns that can reduce coupling is out of the scope of this book. There are some important insights to be found, especially on the subjects of security, evangelizing and commercial arrangements. I expect I will refer to this book many times in the future.

Loosely Coupled: The Missing Pieces of Web Services, Doug Kaye ; RDS Press 2003, ISBN 1881378241

Seven Levels of Coupling: Seven Deadly Sins or Seventh Heaven?

In this posting I discuss the Zapthink article by Ronald Schmelzer, "The Seven Levels of Loose Coupling".

This week I have found two commentators redefining loose coupling. The first is described in the discussion about virtual endpoints that was the subject of my previous posting and the second was this Zapthink article. I think it is important we clarify our definitions around SOA to avoid the concept being hijacked by commercial interests. So in this posting and the last I have attempted to sort out whether the discussion is adding to our understanding or muddying the waters.

In a previous posting I have identified 18 different types of coupling and I am still finding more. The first thing to realise about the seven levels of coupling is they are looking at a different attribute of coupling than what I refer to as 'types of coupling'. The levels refer to the entities that are being coupled. My discussion on coupling types looks at the coupling of two modules of program code. This code could be in calling programs, objects, subroutines or services.

The following table lists the seven levels. This table makes the distinction between 'Levels of Coupling' and 'Types of Coupling' clear. The core tenet that Zapthink is discussing is the "loose coupling of Service consumers and providers". This has a different meaning than loose coupling between program code in different services. The main difference is that aspects of the service provider, with the exception of the implementation are not program code at all. Another difference is that a service consumer may not be a service either and it also might not contain program code.

	Aspects of the Service Provider	Possible Types of Coupling
Loose Coupling the Implementation	The service implementation	18 types and still counting
Loose Coupling the Service Contract	Service contract	Interface Coupling, Bind-Time Coupling, Service Intermediary Coupling, Infrastructure configuration Coupling
Loose Coupling the Service Policy	Service policy	Bind-Time Coupling, Service Intermediary Coupling, Infrastructure configuration Coupling
Loose Coupling the Process	Service-oriented process (Trivial if this is a service)	18 types and still counting
Loose Coupling the Data Schema	Data schema of provider dataset and data schema of interface.	Data Services Layer Coupling, Data Transformation Service Coupling
Loose Coupling the Infrastructure	Infrastructure of provider	Single-vendor SOA platform Coupling
Loose Coupling at the Semantic Layer	Meaning of message attributes	Dynamic service definition Coupling

The seven layers are not as clearly layered as the phrase 'Levels' might suggest. Certainly policies could be considered a higher level than contracts and processes considered at higher level to implementation. The other levels could be considered to sit atop the infrastructure level and under the semantic level but normally data and process would sit beside each other with neither the master. I also see contracts sitting beside data and process as equal partners.

Coupling takes account of the dependency between two entities and the clarity of this dependency. Thus two services exchanging a message are loosely coupled if every dependency is clear from the format of the message. Services have different reasons for being dependent. These reasons are what we mean by 'Types of coupling'.

The types of coupling for the seven levels are described in the third column of table above. The first level describes service to service coupling which I have described earlier. The fourth level is interesting because the solution is almost trivial. The business process should look like a service and therefore all the coupling types for coupling between services also apply for coupling between a consumer service and provider service that is a composition of services used to implement a process. The sort of things that might cause dependencies with contacts, polices, infrastructure, data schemas and semantics are different to the program code dependencies.

Loose coupling of data schema is partly addressed by another Zapthink article which advocates the building of data transformation services rather than incorporating transformation logic inside services used to contain business logic.

Tight coupling between the consumer service and the infrastructure of the provider could be based around a number of proprietary technologies. The ones highlighted by Zapthink are the non-standard ESB and the single vendor SOA platform.

The types listed in the third column of the above table are those implied in the Zapthink article. I expect that a thorough investigation would uncover other types of coupling as well. The point of listing them in the table is to suggest that each coupling level will have its own types and each level (with the possible exception of the process level) needs to be investigated separately.

We can find coupling examples everywhere. For example Carlos Perez and David Walend discuss whether a DBMS and its application are loosely coupled if the application is accessing the DBMS using SQL. This is interesting but not relevant to SOA. For the point of view of defining SOA, I do not believe the seven levels of loose coupling matter. You can have an SOA as long as the services are loosely coupled. However as a model to assist good practice, I think the seven levels will provide value even if they do overload the 'loose coupling' term.

The concepts discussed in relation to levels of coupling are certainly valid. We do not want service consumers dying or behaving incorrectly due to changes with service provider's infrastructure, policies or any of the other aspects described in the seven levels. Zapthink continue to guide us on the path to software heaven, however in the process of introducing 'levels of coupling' Zapthink commit the sin of causing confusion around the important 'loose coupling' term. I recommend the "Seven Levels" article to SOA developers and I suggest developers need to be clear on what is being coupled whenever they use or encounter the term 'loose coupling'.

End Note:
One way to distinguish other levels of coupling from service to service implementation coupling would be to call the different levels something different other than 'loose coupling'. The names that occurred to me were 'loose buckling' or even 'loose zipping' which would be reminiscent of the zapthink integration zipper. Unfortunately both these terms have implications of embarrassing failure if the buckling or zipping is too loose. We do not want our metaphorical trousers around our ankles.

Subroutine Call Coupling

It has been more than a month since I did my last posting on coupling. Amazon has delivered my book on loose coupling by Doug Kaye and I am finding it valuable. Once I have finished that I hope to revise my original list of types of coupling.

In this posting I would like to say something about subroutine call semantics versus message passing and the coupling associated with this. I have discussed before that the synchronous approach which is a requirement of the subroutine call semantics is more tightly coupled than an asynchronous approach. There are two other differences between subroutine calling and message passing. These are

• the management of state of the calling module and the called module; and
• the management of the called instance itself.

When you invoke a subroutine it starts executing from its beginning. The invoked routine will usually have no state and complete before the invoking routine resumes again. Another form of routine call is the coroutine where the state in the called module is maintained from one call to another. The issue of state coupling was covered in my earlier posting and labelled as 'Process State Coupling'. This type coupling is intended to cover coroutine behaviour. A coroutine is even more tightly coupled than a normal subroutine call because of the dependency on state.

In a normal subroutine call state is not preserved in the called module from one call to the next however state is preserved in the calling module. It preserves its state by the simple expedient of suspending execution until the called module returns control.

Asynchronous message can still involve process state coupling. More loosely coupled messaging has enough information in the message to process without retaining state. This is, in general, better practice but is not always practical.

There is one other aspect of subroutine call behaviour that is different from message passing behaviour. When a subroutine is invoked it is in effect brought to life at that point. If you have to create an instance of a service in order to use it then this is another form of dependency. A service should be an entity that always "exists" that is ready to serve. In effect messages can wake up receiving services but it should not be the concern of the sending service to create or dispose of an instance of the service. I therefore intend to add 'Creation Coupling' to the coupling list when I next publish one. Creation coupling occurs in Java classes when a new object is created using the 'New' statement. Methods of that object are then called but the creation of new object (and sometimes its destruction) is often the role of the calling object.

It is the system's responsibility to effect and manage the invocation of the service, not that of the calling application. This allows two critical characteristics to be realized: 1) The services are truly independent, and 2) they can be managed. (Anagol-Subbarao)

In the paper "Web Servces Are Not Distributed Objects" by Werner Vogels he draws this distinction clearly. Loosely coupled web services do not have the same behaviour as objects.

An important notion at the core of distributed object technology is the object life cycle:
· Upon request, a factory instantiates the objects.
· The consumer who requested the instantiation performs various operations on the object instance.
· Sometime later, either the consumer releases the instance or the runtime system garbage-collects it.

It is this point that Werner distinguishes between services and objects and is also this point that makes distributed objects more tightly coupled than web services that are coupled using messages.

In this posting we have discussed subroutine semantics and discovered that subroutine a tightly coupled to their calling modules because of:

• Synchronous Coupling
• Process State Couping, and
• Creation Coupling

The use of asynchronous messages is much more loosely coupled as a result.

References:
Anagol-Subbarao, Anjali, J2EE Web Services on BEA WebLogic, Prentice Hall, October, 2004

Vogels, Werner, "Web Services are not Distributed Objects: Common Misconceptions about Service Oriented Architectures" , IEEE Internet Computing, vol. 7, no. 6, pp. 59–66, 2003

This is also available from Werner's blog site at
http://www.allthingsdistributed.com/historical/archives/000343.html

Marlin, Christopher D. Coroutines, Lecture notes in computer science, vol. 95, Springer-Verlag, Berlin, Heidelberg, 1980. ISBN 3 540 10256 6 and ISBN 0 387 10256 6.

Kaye, Doug, Loosely Coupled: The Missing Pieces of Web Services; RDS Press 2003, ISBN 1881378241

SOA Governance

I listened to a good Podcast on SOA governance today. It was Phil Windley and Scott Lemon interviewing Tod Biske and Ed Vasquez of Momentum SI. It is clear to me that SOA governance is important in managing SOA and SOA metadata. This podcast provides some ideas on what shape this governance can take and how products may or may not assist with this.

SOA has often been compared with Object Oriented development or even structured programming. The question was asked in the Podcast about why Governance was such an issue for SOA in comparison to these earlier approches. The answer is that the implication of an SOA decision goes beyond the IT group and single applications. The users of the service are significant stakeholders in an SOA and are directly affected by the policies. Organisation partners or organisation divisions sharing services need to agree on a service approach and comply with service interfaces in order to provide effective reuse.

Todd Biske emphasised three key aspects of governance in relation to policies that need to in place. These three aspects can be assisted by automation. They were

• Enforcement of policies
• Creation of policies
• Storage of policies

Later in the discussion two more aspects of governance were provided:

• Communication of polices
• Feedback on policies (policies evolve)

A strong theme of the podcast was that you cannot buy governance. It has to be appropriate for the organisation and a product is not yet out there that provides integrated assistance over all the aspects of governance. The process of building governance occurs by assessing the current situation, working out what processes are involved and then providing the appropriate level of manual operations and automation to support these processes.

Storage of policies is provided by registry and repository products. Registry products are moving toward providing more repository functions. The term "Regository" was coined in this podcast. A parallel can be drawn with LDAP. The registry is becoming much more of a managed data set which is configurable and provides information to humans not just automated processes.

Feedback on policies and services is very important. Without proper feedback the organisation can become a lame duck. Portfolio management is important for services as well as for applications and projects. The discussion reminded me of getting feedback on this statistics for my blog site (using http://www.mybloglog.com/). This tells me where my links are coming from and also gives me a warm feeling that people actually see this stuff. The same thing is true of getting feedback on a website with a product like Webtrends. Services are no different. Metrics about who is using a service, when they are using it and how often, provide valuable feedback.

This feedback and the process of understanding the customers of your services gets the IT person closer to the business. It was suggested in the podcast that in general SOA involves IT doing more tasks previously understood to be business tasks. If you are not experiencing the pressure to do more work related to the business then you are not really doing SOA.

There can be hundreds of policies associated with SOA. Design time policies will include technology choices, product choices and methodologies. Run-time policies include your service contracts and service level agreements (SLAs). These SLAs may apply to each producer-consumer pair and include security policies, operational policies, compliance policies and integration policies.

SOA policy should not be a police state. The approach to implementing policy should be that "The path of following policy is the path of least resistance". An organisation should not reach a gridlock because there are so many policies that the developer cannot move. Policies are something that involves discussion with service users and should not be confined to the IT group.

Effective policy agreements will save time by avoiding the need to build using more than one technology (eg. SOAP, REST and JMS). The value of an agreement is that it saves the cost of building with multiple standards.

Greater governance enables the services in SOA to be more loosely coupled. Loose coupling is about reducing dependencies between services and making those dependencies explicit. The fact that the service contracts are written outside service code and are clearly defined is a key determinate of loose coupling.

Todd's two most important points were

1. Use a service or application portfolio technique to identify what services are good, bad, expensive or good value.
2. To get started on a project ask
   - What services dose this solution expose or use?
   - What business events does this solution publish or subscribe to?
   - What business processes do this solution support?

There were some good insights in this podcast. Governance in SOA is important. It may stop your SOA becoming JBOWS (Just a Bunch of Old Web Services). It makes sure that your organisation gets the best of reuse and does not get lost in mire of standards, products and methodologies.

Footnote:
JBOWS (or JaBOWS) was a term I heard this week in a talk from Glenn Smyth. There is a good post from Joe McKendrick on this acronym. Another reference can by found in an article by Rich Seeley which in turn refers to another artlicle by Brent Carlson which uses the acronym ABOS (A Bunch of Services). It would have been more accurate to write about ABOS in my posting but JBOWS has a nicer ring to it and seems more likely to catch on.

Binding and Coupling

From the Doug Kaye, the man who wrote the book on Loose Coupling

Loose coupling is like pornography. Everyone talks about it, but when challenged, few can tell you what it is. For some, it borders on a religion with the attendant fervor one would expect from the newly converted.

When I say he "wrote the book" I mean that literally. There is probably only one book dedicated to this subject and he wrote it.

• Loosely Coupled: The Missing Pieces of Web Services, Doug Kaye ; RDS Press 2003, ISBN 1881378241

I am not surprised it is possible to write a whole book on this. Firstly it is pivotal to SOA and secondly there are so many different aspects to coupling. Today I will discuss binding and Coupling but my postings on coupling probably will not be able finish until I read this book.

Binding is the time when a logical description of an attribute is tied to its physical value. For instance a service address can be bound when the source code is written, when it is compiled or when it is linked into an executable module. This is called ‘early binding’ or ‘build-time binding’. A service address can also be bound to its physical address when the message is sent, or when it is handled by intermediaries. This is called ‘late binding’ or ‘run-time binding’.

Some formats of payload can also be bound at build-time. For instance java objects (and serialized data objects) are bound at build-time. Therefore a receiver will reject a message containing a serialized java object that is not bound to the same physical representation of the object.

Generally in SOA, loosely coupled services are also considered to have all aspects of their messages bound at run-time. Having an address or payload that is bound at build-time reduces the run-time flexibility of these services.

Binding and coupling could be treated as independent dimensions of the separation between services. A build time dependency on a message is so significant however that I will roll it into the coupling dimension. This is appropriate as coupling is a combination of characteristics and not a single dimension anyway. By rolling build time dependency into our types of coupling it also enables us to keep our definition of a service clean without having to comment on binding between services.

This leaves me with another coupling type ‘Build-Time Coupling’ which I will add to my list of coupling types. It is more tightly coupled than most forms of message coupling. This list has been modified in my posting about Aspect Orient Programming and I intend to republish it again after I have made a couple more revisions.
'Build-Time Coupling’ is still a form of Message Coupling so I still include it as part of a service in SOA. It would generally not be considered good to have these dependencies and we would be justified in excluding build-time dependencies from the definition of a service.

It is good practice to pass version information in messages between services. Therefore a message may contain a version number or a build date so that another service can check it and take appropriate action. If a receiving service detects a change in the version of the sending service then this fact might be logged, or the metadata inspected or the message may be rejected. This is not a build time dependency described above. It is another metadata control. Rather than add ‘version coupling’ to a long list of coupling types I will combine the other coupling types that have similar metadata that control the behaviour of the services into ‘Process Control Coupling'.

I hope to revise my own list of Coupling Types shortly but in the meantime click on this link to look at the list developed by the man who wrote the book on coupling.

Footnote:
I have found and extended forum discussion on Passing Serialized Java Objects vs. Web Services . This features and appropriately named J. Cowboy who is railing against those bullies in management who want him to develop Web Services instead of passing (build-time coupled) serialized java objects around his system.

SOA Videos

I read a posting by Collin Smith which included some YouTube videos. This gave me the idea to do my own posting on SOA videos. This also gives me the opportunity to reuse my keywords 'Monkeys' and 'Lego' which so far I have only used once each. My most popular posting so far has been 'Chasers War on Wikipedia' which is more about entertainment than SOA. This posting may be similar.

First, here are some YouTube videos. They have obviously all come from the same source but I am not sure who takes the credit for these.

SOA is like Lego Blocks, http://www.youtube.com/watch?v=sbd_1G8Kqjs&eurl=http%3A%2F%2F
I have a previous posting on this analogy. Like other commentators for some reason they have not used real Lego blocks in the video. Instead they have used a pale imitation. At least they have called them 'Building Blocks' rather than 'Lego'.

SOA is like Music, http://www.youtube.com/watch?v=zV860odGN5Y
This fits with discussion on SOA orchestration but still does not do a lot for me.

SOA is like choosing what wear, http://www.youtube.com/watch?v=dyHWAiG6c-Y
This analogy took me by surprise and it does not really work for me, but the girl is pretty.

Greg the Architect, http://www.gregthearchitect.com/index.html
If you have not seen 'Greg the Architect' yet, then you are missing out. This is the pinnacle of SOA satire, even if it is the pinnacle of a very low heap. It is produced by the people at http://www.soanowjournal.com/. At the time of writing there are four episodes.

• Greg the Architect SOA
• Greg the Architect ROI
• Greg the Architect Focus Pocus
• Greg the Architect - Off the Grid

SOA Monkey, http://www.youtube.com/watch?v=cM31qu9T3Iw
This one appealed to me. It is seriously off the wall. This monkey knows a bit about SOA though.

The following videos are more informative than entertaining.

There are some good interviews with SOA people of note at http://tv.sys-con.com/read/category/1260.htm . These interviews have advertisements though. I liked one I found on YouTube with the advertising removed 'SOA Power Panel with Jeremy Geelan'. There were a couple of good things I got out of this hour long video. Firstly the quote "Think different. Don't think too long" and secondly eight service characteristics of SOA:

• Loose-Coupling
• Contracts
• Manageability
• Versioned
• Discoverable
• Addressable
• Distributed
• Point to Point (None of the speakers seemed to agree with this one)
• Self-Describing (This was a ninth one that was added by a speaker)

Tarrant County implements SOA for criminal justice agencies, http://www.youtube.com/watch?v=JIpLllGl1fc
This is advertising for Progress Software but I liked it because I work for a justice agency.

SOA - Service Oriented Architecture Introduction, http://www.youtube.com/watch?v=sRFwswaJpD0
This was a good SOA definition but turn down the sound because the speaker sounds like she is reading a children's story.

Another good source of SOA video is http://www.infoq.com/. I have mentioned these in earlier postings. In the posting 'ESB or not ESB?' I referenced some videos from Mark Richards (http://www.infoq.com/presentations/Enterprise-Service-Bus) and Sandy Carter (http://www.infoq.com/interviews/sandy-carter-soa). In 'AOP: The worst form of Coupling' I use Jim Webber's comments about MEST from http://www.infoq.com/news/2007/08/jim-webber-interview.

Sometimes after a hard day at the office reading pages of IT jargon I find the videos easier to absorb than more text information. I hope you can find something here that is either entertaining or informative.

AOP: The worst form of Coupling

I have just had the need to look at Aspect-Oriented Programming. The Wikipedia entry on this is very good and covers the benefits and risk well. The following provides a good summary of what AOP is all about:

…an aspect can alter the behavior of the base code (the non-aspect part of a program) by applying advice (additional behavior) at various join points (points in a program) specified in a quantification or query called a pointcut (that detects whether a given join point matches).

This offends my sense of what is good modularized code. AOP is done under the banner of "Separation of Concerns" but instead of separating parts of programming code in simple and visible ways, AOP is coupling it tightly. AOP is coupling code modules in ways a programmer would not expect from viewing the affected code. This is tight coupling of the worst kind. In my earlier posting on coupling I rated types of coupling from 0 to 14 from loosest to tightest. I will call this type coupling "code coupling" and give it 15, the tightest coupling index of all. The coupling is through the code rather than through data passed to the module. Code coupling is not new but I did not expect it to come up as modern programming paradigm.

Another form of code coupling is "inclusion coupling" which is explained well by Milind Shingade

Inclusion coupling is a form of coupling in which one component includes source code of another component. If the included component changes something on which includer depends or adds something that raises the conflict with something in the includer then the includer must change.

I see inclusion coupling as more benign than using AOP but I will still roll it into my "code coupling" category.

Control Coupling (coupling index 12) is pretty tight. This is where you pass a Boolean or control parameter to a procedure and have code in that procedure which checks the value and executes different logic based on that control parameter. This is one way of affecting the executed logic in the procedure but at least you can read the code and have some expectation of what the behaviour is going to be. With AOP an unsuspecting maintenance programmer may not have any idea that the program code is being affected by an "aspect".

Unfortunately I have to grant there may be a place for AOP. Code for auditing, logging, exception handling, security and range of routine work that needs to happen along with the business logic can make it difficult to discern the main thrust of what program code is trying to achieve. There is a big need for control and proper governance of AOP. If it has to be used then only senior developers should implement the Aspects. It only should be used in very limited circumstances. Ideally there should be clear documentation in program modules affected by an Aspect.

This should not be a pervasive programming paradigm. The programming should not be Aspect Oriented at all. Code should normal, good Object Oriented code but if AOP is supported a developer may introduce one or two Aspects to influence this code.

In summary I think AOP may be a horrible necessity in some programs and should be used with extreme caution. AOP has given me another type of coupling to add to my list. I had expected the next entry to my coupling list to be in the looser coupling range. I recently listened to a Podcast from Jim Webber of ThoughtWorks. Jim claims that MEST uses looser coupling than WSDL. I would like to see that. I am hoping to blog on this soon.

The Definitive SOA

The definition of Service Oriented Architecture (SOA) seems to cause some anguish and confusion. This is because

• There is no good definition,
• Every one is thinking a bit differently about what SOA is,
• There is no acknowledged ultimate source on SOA, and
• It is hard to be brief enough to fit any SOA definition on a bumper sticker.

I thought I would set myself the challenge of coming up with a definition of SOA that I liked. My favorite for the last 12 months has been from Chris Brown of Wachovia Bank. I like it because it has two perspectives:

• From a business perspective, SOA is a construct and discipline whereby new business requirements are evaluated holistically against a backdrop of processes and functions that are currently in use by other business solutions. A common process or service that has been previously created, and paid for, is then augmented or reused, in whole or in part to create a new and/or improved process.
• From a technical perspective, SOA is a software architecture model where loosely coupled software components, representing granular but complete technical or business functionality, are accessible through known platform independent interfaces and transports over a network.

This is good for me because it speaks to the business in language they can understand. For the purposes of talking to the business I am happy to abandon technical precision. As for the second part of the definition I have recently had cause to question its precision. Terms like 'loosely coupled', 'granular functionality' and 'complete business functionality' are too ambiguous for a good technical definition.

It should be clear from a good definition that some applications do not apply to SOA. Some definitions I have seen would have to admit well structured COBOL applications as complying with SOA.

The reason it is important to have a definition is that now there seem to be a number of different interpretations to SOA. SOA to some people is Web Services, SOAP and WSDL. SOA to some is having a discipline around component reuse and not much more. SOA to some can also be as vague as basing software on business services. These interpretations of SOA can be useful in certain circumstances. This just means that when I talk about SOA it is necessary to declare what I mean.

I have looked through a number of definitions referenced below. Of special note is the research done by SearchWebServices.com that documented 12 different definitions supplied to it by technical celebrities who were asked to keep there definition to 50 words.

The things I want to include in my definition are:

• Distributed Computing
• Message Coupling
• Platform Independence
• Implementation Hiding or Abstraction

I should mention that I interpret "Loose Coupling" to be relative term. What is loose coupling in one context could the tight in another context. I have an earlier posting on the subject of coupling which emphasis the wide range of coupling types. I think we need to be precise about exactly what coupling we are talking about so I will use the term 'message coupling' in my definition.

The things that appear in some definitions that I want to leave out of my definition are:

• Web Services, SOAP, WSDL (too specific)
• Reference to Clients and Servers (It does not matter in SOA)
• Benefits of SOA (Reuse, agility etc.)
• Higher order concepts (Quality of Service, Security, Orchestration, Repositories)

So here it is. I resort to defining SOA and then a service.

SOA is a software architecture where the business logic is encapsulated in services and a single application may be distributed over many processors.

A service in this context is a software component which
· Hides its implementation,
· Is based on standards,
· Is location transparent,
· Is message coupled, and
· Is accessible through defined platform independent interfaces.

It would have been no good for SearchWebServices.Com because it is 59 words and it certainly will not make a good bumper sticker. However, it works for me now and like the rest of my thoughts on SOA, it is sure to evolve.

References:
My previous Postings on coupling: Bragging Rights on Coupling, Cohesion, Coupling and SOA

Brown, Chris, Transforming Business Process through Effective SOA Implementation, Conference Paper for Service Oriented Architecture 2007: Synchronising Business and IT to Drive Performance, February 26 - March 1, 2007, IQPC Conferences

Mimoso, Michael, A defining moment in SOA, http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1017004,00.html, SearchWebServices.Com, 20 Oct 2004

Some More Definitions of SOA:
OASIS: http://en.wikipedia.org/wiki/Service-oriented_architecture
XML.COM: http://www.xml.com/pub/a/ws/2003/09/30/soa.html
Webopedia: http://isp.webopedia.com/TERM/S/Service_Oriented_Architecture.html
TechEncyclopedia: http://www.techweb.com/encyclopedia/defineterm.jhtml?term=soa
OMG: http://colab.cim3.net/cgi-bin/wiki.pl?OMGSoaGlossary%23nid34QI
OASIS: http://colab.cim3.net/cgi-bin/wiki.pl?OasisSoaGlossary%23nid34QP
OpenGroup: http://colab.cim3.net/cgi-bin/wiki.pl?OpenGroupGlossary%23nid34QT
W3C: http://colab.cim3.net/cgi-bin/wiki.pl?WwwCSoaGlossary#nid34R0
WhatIS: http://searchwebservices.techtarget.com/gDefinition/0,294236,sid26_gci929153,00.html
Gartner: http://www.ipt-group.com/download/SOA_IG/SOA_IG_CS_2007_08_28.pdf

Bragging Rights on Coupling

I am reading "Enterprise SOA: Service-Oriented Architecture Best Practices" by Krafzig, Banke and Slam and I have come across a section on "Tight Versus Loose Coupling". This is a topic of my recent post" Cohesion, Coupling and SOA.

In my earlier post I described the taxonomy from loose coupling to tight coupling provided in a Pressman textbook
· No direct coupling
· Data Coupling
· Stamp Coupling
· Control Coupling
· External Coupling
· Common Coupling
· Content Coupling

I then added to this Message Coupling which was suggested by Thomas Erl. Now Krafzig et al is suggesting there is more to message coupling than just a single category. The book describes seven dimensions of messaging coupling. The 'coupledness' created by messages will depend on
The physical link (eg. Whether messages are put on a queue or the communication is a point to point communication).

• The communication style (eg. Asynchronous or synchronous)
• The type system (eg. Is the type determined by the called service interface or the message payload)
• The interaction pattern (eg. A service is more loosely coupled if it receives a message, then processes it and then can forget about it such as a stateless service. Tight coupling is required if for example the service uses an internal variable to keep track of the state)
• Control of Process Logic (eg. Additional coupling can be added to impose transactional integrity)
• Service discovery and binding (eg. Are services discovered through UDDI or similar means or are they directly referenced? )
• Platform dependencies (eg. Tighter coupling results if the service must always invoked from the same technical platform).

This threatens to make a mess of the neat one-dimensional coupling spectrum but we must remember that the spectrum of coupling types is only a guide and that it was always possible to have combinations of coupling types. I develop a priority listing below.

What was meant by message coupling in my earlier post was focusing on the asynchronous nature of messages. All the Pressman coupling types assume synchronous procedure calling and this was proposed before the time of distributed computing so they all are fundamentally coupled by the fact the modules were running on the same piece of hardware. Distributed computing warrants its own sort of coupling. The new spectrum might look like (from loose to tight coupling):

0. No direct coupling
1. Services Registry Coupling
2. Message Payload Coupling
3. Queue Coupling
4. Asynchronous Coupling
5. Plane Old Message Coupling
6. Bind-Time Coupling (added from later posting)
7. Process Control Coupling
8. Creation Coupling (added from later posting)
9. Process State Coupling
10. Platform Coupling
11. Distributed Coupling
12. Data Coupling
13. Stamp Coupling
14. Control Coupling
15. External Coupling
16. Common Coupling
17. Code Coupling (added from a later posting)

Rather than use the dimensions of Krafzig et al I have used labels of describing and example of a a coupling category within that dimension. In most cases it is the looser coupling category. This is consistent with the earlier coupling types. Therefore I use 'Queue Coupling' for the 'Physical Link' of Krafzig et al and 'Asynchronous Coupling' is used instead of 'Communication Style'.

I have inserted "Plane Old Message Coupling" in at number 5. In fact all coupling types from 1 to 9 are message coupling. Coupling types 7,8 and 9 increase the coupling between services. Coupling type 1 to 4 loosen the coupling compared to a synchronous message, called using its inteface without the assistance of queuing or a registry.

As discussed in the earlier posting the classic coupling types are still relevant to SOA. If you use a tight coupling type then it does not matter what good things you have to decouple your services there will still be tight coupling.

The numbers in the above list can be used as score. A low score is good loose coupling. For example if you are sending messages with Boolean values that significantly effect the processing in the called services then you have control coupling and you score badly with a 14. It does not matter that you are using asynchronous message and type is based on the message payload. The services are still tightly coupled. Similarly if you send a huge amount of XML and the service only uses a part of this then this is 'Stamp Coupling' and can only score an 13.

Loose coupling in our ideal SOA applications requires our services to be recorded in a registry, to be driven by the message payload, to use queues to communicate, to be asynchronous, to not have overriding process control and to be stateless. These services are platform and hardware independent. The payload should not contain extraneous data, or control values. The operation of the services should not communicate using external methods or use common shared data areas.

If I ever write a software development text I think this would be useful content. Perhaps this can be used as bragging rights however I am not the sort of person to say something like "How many types of coupling do you know, I know 18".

References

Krafzig, Dirk, Banke, Karl and Slama, Dirk, Enterprise SOA: Service-Oriented Architecture Best Practices, Prentice Hall, 2004, Section 3.5

Pressman, Roger, Software Engineering: A Practitioners Approach, 1982 McGraw Hill

Erl, Thomas, Service-Oriented Architecture: Concepts, Technology, and Design, 2005 Prentice Hall

Cohesion, Coupling and SOA

I was prompted to review one of my university texts on program design when I was reading some material on how to develop good software under SOA. The text in question is "Software Engineering: A Practitioners Approach" by Roger Pressman. It gives and excellent account of cohesion and coupling apparently developed earlier by Larry Constantine. I note this is currently presented in Wikipedia (http://en.wikipedia.org/wiki/Cohesion_(computer_science) and http://en.wikipedia.org/wiki/Coupling_(computer_science) ).

Pressman presents a range of cohesion and coupling types and explains this as two linear scales (low coupling good, low cohesion bad). These do not seem to be used in any detail in the SOA literature that I have read which is a shame because knowledge of this concepts is relevant. There is a lot of discussion about loose coupling without much reference to its definition. In Pressman's terminology loose coupling between modules (or services) includes, 'No direct coupling' and 'Data Coupling'. When you get to 'Stamp Coupling' and 'Control Coupling' you are getting into the area of bad coupling which a developer may compromise on if there are good reasons (eg. Performance). 'External', 'Common' and 'Content Coupling' gets into the forbidden zone.

SOA adds 'Message Coupling' to the above list. 'Data Coupling' assumes a procedure call where the location of the recipient is known and the parameters conform to known format. Messages on the other hand do not require this detailed knowledge of the called procedure and therefore are usually lower on the coupling spectrum than 'Data Coupling'. 'Loose Coupling' is a term used often in SOA but it means more than just using messages to communicate between services. The other forms of coupling still can exist. You can pass control information by messages and still have control coupling. You can allow access to common persistent data and still have external coupling. Message orientation does not automatically mean you have loose coupling.

Cohesion is a term that is not seen as often in relation to SOA. Pressman lists different types of reasons that you might bring bits of code into the same module. Some of these are just as valid when you are building a service. The ideal cohesion is where a module implements a single idea 'Functional Cohesion'. The next best cohesion is 'Sequential Cohesion' where steps are included together because they have to follow each other sequentially. Both these forms of cohesion are usually too fine-grained to be implemented as services. Modules that exhibited this level of cohesion would however be good operations within a service.

'Communicational Cohesion' is the developing of modules around a data structure and this equates closely to 'Entity-Centric' services for an SOA. 'Procedural Cohesion' relates code that is included in a module because it belongs to the business process. This is similar to the 'Task-Centric' services for an SOA which are appropriate for business services but usually exhibit less cohesion than entity-centric services in application services. In the more scatter-brained rationales for cohesion we have 'Temporal Cohesion' for code which must be executed in the same span of time, 'Logical Cohesion' for operations that are logically similar and 'Coincidentally Cohesive' where the code is related loosely. These are scatter-brained approaches both in classical development and SOA.

Thomas Erl says that ideally
· Services are reusable
· Services share a formal contract.
· Services are loosely coupled
· Services abstract underlying logic.
· Services are composable
· Services are autonomous
· Services are stateless
· Services are discoverable
On the surface one might consider that the only relationship with this list to the concepts coupling and cohesion is the reference to loose coupling. In fact all the qualities except discoverability can be enhanced with an understanding of coupling and cohesion. Good cohesion and coupling allows services to be more reusable. A formal contract makes the relationship between services explicit and therefore less tightly coupled. If the underlying logic of a service has to be understood to understand the service then this probably means the interaction of the service is not going entirely through well understood messages. Autonomy is another way of expressing cohesion as service has control over its code and is not effected by outside influences. State in a service is a form of control coupling. A stateless service means that control is not being handled outside the service.
The important point here is that we can use some already tried and tested techniques to apply to quality service development. The design literature of SOA would do well to draw more on this legacy rather than use some statements about loose coupling that are left without clear definition. Another point of this discussion is to emphasize that old IT concepts are still valid, which gives aging software developers a warm feeling. We are still trying maximize cohesion and minimize coupling in our services just as we did in our Fortran subroutines.


References

Constantine, Larry and Yourdon, Edward, Structured Design, 1976

Pressman, Roger, Software Engineering: A Practitioners Approach, 1982 McGraw Hill

Erl, Thomas, Service-Oriented Architecture: Concepts, Technology, and Design, 2005 Prentice Hall