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