sapienti sat: Making SOA Ready for the Enterprise

The forgotten key to service dependability

If I have to name the feature of SOA infrastructure and governance that is at the same time most overlooked and critical to the overall success of post-pilot implementations, the honor would undoubtedly go to the Service Lease.

Let us start with a

Hypothetical Example

Once upon a time there was a talented developer Alice who implemented a ReallyUsefulService. She tested, documented and deployed it as was prescribed by the Company’s Process and as the last step published it to the SOA System of Record (some people like to call it a registry, but that’s a topic for another discussion) along with the corresponding SLA and all other relevant metadata. Some time later Boris, the technical lead in the Business Systems Group, was given a task to develop a BusinessCriticalApplication. Being wise in the ways of SOA he started by searching the registry for viable reuse opportunities, and found the ReallyUsefulService which was available and satisfied both his functional and non-functional requirements and constraints. He told his team to use the service and they lived happily ever after… Let’s pause here for a while, what exactly does it mean to have service published in a registry? For Boris it most likely means that the service will be available at the specified end point with the advertised contract, features and policies forever. How can he be so naïve? The Sun will burn out in a few billion years, but in an absence of any specific expiration date this assumption is most convenient and as good as any… Alice, on the other hand, when she was publishing the service, meant all of this to be guaranteed for the next instant, after which all bets are off. This is a very dangerous disconnect which will very likely lead many adopters of SOA to painful and costly surprises when things that were once in a registry start to change. But do not despair! Luckily there is a very simple answer – Service Lease.

The Concept

Service lease means that a binding (either explicit or implicit) exists between the service consumer, governance platform and (ultimately) provider which guarantees that from the time it has been granted until it expires, nothing of importance to either party will change. This doesn’t mean that implementing service lease requires to perform the full find-bind-execute cycle at runtime – in its simplest form the lease is just the expiration date placed on the service contract by the Governance Infrastructure that can guide prospective consumers at design time to make informed decisions about dependability of services they want to use.

The Benefits

The lease in the true spirit of SOA further reduces the coupling between the service consumer and the service provider, by limiting the amount of time consumers and providers may be bound. Without the notion of a lease, a consumer could bind to a service forever and never rebind to its contract again. This would have the effect of a much tighter coupling between the service consumer and the service provider.

The lease provides some degree of protection to both service consumers and producers. For consumers it is a guarantee that service should remain available and SLA would remain in force for the duration of the lease. For producers it is a guarantee that they will be free form any SLA obligations after the last lease expire; and if a producer needs to somehow change its implementation, security, QoS, or simply temporarily take the service down for maintenance, it may do so at this point. The implementation can change without affecting the execution of the service consumers, because those consumers must request a new contract and lease. When the new contract and lease are obtained, they are not guaranteed to be identical to the previous ones. They might have changed, and it is the service consumer’s responsibility to understand and handle this change.

The use(funless) of lease is not limited to registries and design-time in general. At run-time the governance engine should be aware of the lease of the services that are being invoked. Depending on the policy, it can notify the participants (consumers, providers, operations) that service is being used outside of its lease window or lease is about to expire, or it can reject the requests for out-of-lease services.

The Implementation

A practical implementation of Service Lease that we have in our SOA Governance Solution is based on the use of Lease Tokens. The basic token includes the expiration date; effective date in order to support early announcement of services and perhaps even at-your-own-risk availability, and issue date to support and track lease extensions.

When a service is “published” (i.e. approved for public consumption) the Governance Officer can define the lease terms and create a token that describes them. The token is be stored in the registry and made available via both the GUI and API. It is also visible to the Service Delivery Agent (run-time governance engine) to implement a variety from lease policies including embedding warnings with the replies, raising alerts and rejecting out-of-lease invocations. The mechanism is designed to be extendable and can support the following additional scenarios:

• Token inclusion with each request, to force the clients to do service lookup and present token as a proof.
• Issuing tamper-proof tokens using XML signature to prevent token forging by rogue consumers.
• Issuing traceable tokens containing unique IDs to allow the infrastructure to keep track of all consumers presently bound to a service.

The Alternatives

To my knowledge no other offering on the market today supports the notion of lease, so how do people manage? To tell the truth – I really do not know… The most reasonable workaround seems to be the subscription/notification mechanisms supported by most high-end registries. They allow consumers and other interested parties to register interest in various resources; including services and the system will automatically notify them when anything about those resources changes. Although a generally useful feature, it has a number of draw-backs when used as a substitute to service lease, including:

• It does not advertise the lease terms as a part of the service contract, so the prospective users can not made informed decisions about service dependability.
• It relies on inherently unreliable human behavior (users have to register for notifications of services they use) in order to be notified about the changes. And keep the subscriptions up to date as their contact details, responsibilities and employment status change.
• It is inherently reactive – the notifications are sent after the service information has changed in the registry, which typically happens as the last step of the update process after the changes has been deployed into the ecosystem. In all likelihood by this time something that depended on the affected service will be broken by the time the developer reads the notification e-mail and implements the necessary changes.
• It does not give the service providers a clear liability-free way to change service contract, SLAs or conduct maintenance.

Conclusion

SOA is new. SOA Governance is even newer. But most concepts it is based upon are not. Isn’t publishing service to the registry just a form of advertising? And advertisers have learned (many of them the hard way) that it is very unsafe to put an add without the expiration date… So, the SOA users of the world, – unite and demand from your Governance vendors to support service lease!