Well Enabled Services

As part of my current software-as-a-service project, I've been investigating Microsoft's Connected Services Framework (CSF). This is Microsoft's answer to the service management problem. Service management is an issue in any IT department, but it is especially important when those IT services are offered to your customers.

At the core of CSF is the well-enabled service (WES). This is a web service with additional interfaces. These interfaces provide support for:

  • Discovery
  • Provisioning
  • Health
  • Utilization

Web services in general define a mechanism for discovering (WSDL) and consuming (SOAP) the service itself, but offer no management assistance. A WES adds these missing management interfaces.

Discovery
WSDL provides for the consumers of a web service to discover its capabilities. But a WES adds discovery of resources managed by that service. This set of resources differs from one service to the next. For example, an email service would manage mailboxes. The WSDL would tell the consumers of the service that they can check their email, but the WES discovery interface tells the IT technician that he can create and delete mailboxes.

Provisioning
In a single-tenant situation, the IT technician provisions services on behalf of his users. In our email example, this means that he would create a mailbox when someone is hired, and delete it when they are fired. In a multi-tenant situation, however, manual provisioning doesn't scale. Instead of the service provider handling every provisioning request manually, he would prefer to automate the task and put the power in his customer's hands.

Most services are not designed for multi-tenancy. They were built to solve a specific business problem. The burdens of scalable IT were probably not even considered during their design and construction. And even those that were designed for multi-tenancy have their own application-specific provisioning interface.

The WES provisioning interface is a small but important step toward a scalable IT solution: it gets us thinking about multi-tenancy during the design phase, and it gives us a common interface to implement. Granted, that interface is extremely weak (the ProvisioningRequest message has one string field: Data), but it's a start.

Health
A single-tenant IT technician can answer his user's support questions by using an application-specific interface to check the health of their resources. But in a multi-tenant environment, that doesn't scale. The customers should be able to check on the health of their own resources.

The WES health interface provides an automated mechanism to query the status of a resource. With this, a user could see, for example, whether their mailbox is online or offline, whether they have had any failed login attempts, and whether they are approaching their quota. These particular health metrics are specific to email, of course. Each WES advertises its own available metrics through the discovery interface.

Utilization
The single-tenant service has an on-going operational cost, regardless of utilization. The consumer of the service has already paid for it. The multi-tenant service, however, is paid for by the service provider. The service provider must ultimately bill the consumer for its use. One way to do this is to bill based on utilization.

The WES utilization interface allows a billing system to subscribe to usage events. When a billable event occurs -- exceeding a mailbox quota, for example -- the billing system is notified, and the invoice is sent.

Unfortunately, this subscription model creates several race conditions. The WES must be started before the billing system so that it can accept subscriptions. If the WES is ever restarted, the billing system must know to re-subscribe. And if the billing system hasn't subscribed when a billable event occurs, that information is lost.

Here's my opinion
Well-enabled services are a good start. Unfortunately, they are just a start. They give us a defined entry-point for provisioning, but do not prescribe a format for those messages. This means that tool support will be limited to routing messages, since generic tools cannot be built to generate or understand service-specific messages.

Furthermore, well-enabled services are built on unreliable technology. HTTP web services do not guarantee delivery. This may be acceptable for certain services, such as checking email, but it is not acceptable for provisioning requests and billable events. Lost bills means lost money.

More information
Microsoft and British Telecom have created the Connected Services Sandbox: a listing of well enabled services. They have posted an excellent article on Building a Well Enabled Service. This goes into much better detail, describing what a WES is, who should build them, and how to do it.

Microsoft's landing page on the Connected Services Framework is mostly executive-level propaganda. I'd recommend starting at their Communications Sector Developer Center for more relevant information.

Leave a Reply

You must be logged in to post a comment.