At the WS-Addressing f2f, we've been talking about lifecycle of resources and identifiers. This has motivated me to finally start writing about time, lifecycle and garbage collection in distributed computing. Almost every higher level ws- spec has some solution or design for this, ie WS-Eventing, WS-Notification, WS-ReliableMessage, WS-Transactions, WS-ResourceFramework, SOAP-Conversation, etc. There seems to be a taxonomy of decisions that can be made wrt gcol. I'll provide this taxonomy, and an analysis of some WS- specs decisions lifecycle decisions.
Design decisions
The main decisions that a resource owner can offer for garbage collection are:
1. Timeout of resources.
2. Terminate messages.
3. Start message
4. Renew/refresh messages.
Timeouts
Timeouts are a mechanism to declare that a resource will not be available, probably deleted or garbage collected, at a certain point in time. The most common timeout is to use absolute times. Another variation is the use of duration. The main purpose of a timeout is that all users of a resource will know that the resource is no longer available after certain points of time.
A main problem of time based garbage collection is that the user(s) of a resource and the resource may have differences of opinion on time, commonly called skew. This breaks down into a false positive and false negative on time opinion. If the user is ahead in time, then it may prematurely think that a resource has expired and prematurely terminate it's use of the resource. If the user is behind in time, then it will incorrectly believe that a resource is still available for use and retain it's reference and perhaps even emit messages to the resource.
There are protocols available to synchronize time in distributed systems, NTP being a good example. This helps mitigate the problem of clock skew.
Another problem with using time is that a user may not have a clock, perhaps a cheap embedded device. It seems like most connected devices have a clock.
An advantage to timeouts is that it can enable distributed garbage collection without the use of explicit protocol messages. Without timeouts, a protocol to explicitly terminate resources is required.
Terminate Messages
Speaking of termination protocols, this is where the user or the resource can inform the other side that the resource is not longer available or of interest.
The advantage of a user terminate message is that it allows a resource to be garbage collected earlier than might otherwise be possible. Without it, a timeout is required or resources might never be garbage collected. The downside is that user terminate messages may be lost in transit and the resource is gcolled later than it ought to be. This is the classic problem of memory leaks.
The advantage of a resource terminate message is that it allows a user to delete is reference to the resource, saving it some costs and preventing potential extraneous messages. The downside is that a resource originated terminate requires that the user has implemented and deployed the terminate message.
Create Message
Invariably, resources that required garbage collection must be created. This can be done implicitly or explicitly. An explicit start message from a client will result in a resource being created. An alternative is to use an implicit start message, which is where another message type is overloaded to include the start message.
The advantage of an implicit start message is that network traffic is reduced.
The advantage of an explicit start message is that a resource may have the time needed for it's purposes, such as buffer creation. It also enables the client and service to negotiate the resource. A client may not want to accept the timeout on a resource because it is too short, so overloading with a higher level message would be bad behaviour.
Renew Message
When resources have timeouts, the resource may want to offer clients the opportunity to renew their interest. This enables a service to offer shorter timeouts than might be otherwise possible.
There is a trade-off between shorter timeouts and more renew messages that the resource has to make.
Specifications life-cycles
Examining some specific specifications:
- SOAP-Conversation: Implicit conversational beans. No timeout, implicit terminate, start, and no refresh messages.
- WS-Addressing: EPRs. No timeout, terminate, or refresh messages. There is an implicit start with a ReplyTo or FaultTo header.
- WS-Eventing: Subscription containing an EPR. absolute and duration based timeout, explicit user terminate (Unsubscribe), explicit resource terminate(Subscription End), explicit start (Subscribe), refresh messages(Renew).
- WS-ReliableMessaging: Sequence containing EPR. Timeout (absolute), explicit user terminate(TerminateSequence), explicit resource terminate (Fault), explicit start (Start Sequence), no refresh message.
- WS-Coordination: CoordinationContext containing EPR. Timeouts, explicit start (CreateContext), extension defined terminate or refresh messages.
- WS-Security: Security header block. Timeout, no messages
- WS-SecureConversation: SecureConversationContext. Leveraging WS-Security for timeout, explicit terminate(explicit start (RequestSecurityToken), no terminate or renew messages.
- WS-Trust: leveraging WS-SecureConversation for timeouts and RequestSecurityToken, and renew (Renew) message.
Conclusions
It's interesting to observe the similarities and differences between these different resource lifecycles. The main commonality seems to be the use of timeouts, but the start, refresh and terminate messages are different. An obvious question is whether it would be useful for EPRs to have a timeout/expiry value as a refactoring from all the other specs. Hopefully this will help in any such discussions.