The Commercial Real Estate Longhorn demo raised questions in Scoble’s blog about the uptime/availability of a system dependent on end-users’ PCs. What good is a great end user experience if the system fails when an end user’s hard disk crashes? Sure, Indigo delivers messages reliably among the client PCs, but doesn’t the bank, for example, want servers in its data center to keep a complete audit trail of all these exchanges? Won’t the bank bet on a high-availability server solution over the “rich” client experience depicted in the demo?
There’s a “tyranny of the OR” implicit in these questions.
Joe Ternasky introduced me to this “tyranny” metaphor, and he loves to point out that end users think in terms of AND, not OR. I want a great end user experience AND server availability. I want secure messages AND audit logs. I want connectivity AND offline operation. I want my app to be a client AND a server…
Indigo helps us build for the AND.
Take for example, the need to audit the exchanges among the PCs in the demo. What if you had coded the entire application thinking only client-to-client, and weren’t even sure which exchanges needed audit? What if, after having deployed the application, your auditor says, “hey, where’s our datacenter audit and backup of all this stuff?” Quickly, you build a service that understands the message bodies and knows how to store them in the datacenter. But how do you insert your new service into the message flow among all these clients?
That’s where Indigo’s support for intermediaries using the WS-Addressing specification is so helpful. You can insert intermediaries at any point in your application’s topology with very little impact on your code. In his Guide to Developing and Running Connected Systems with Indigo, Don Box highlights:
The Indigo connector has explicit support for intermediaries that include firewalls, proxies, and gateways. The intermediary model of the Indigo connector is consistent with the SOAP processing model. While direct communication with a service is supported, Indigo assumes that a direct connection is the exceptional circumstance, not the rule. Instead, Indigo adapts to configuration, metadata, and service policy to determine the best route for a message and will take advantage of gateways or proxies as needed. Moreover, the Indigo connector vastly simplifies the creation of application-level gateways that can offload work from back-end services by providing message validation, security enforcement, and content-based load balancing.
So you insert your new audit service into the communications stream by treating it as an intermediary that’s application-aware enough to store an audit trail. That’s the flexibility in WS-Addressing that Omri describes:
The idea is that the organization of resources behind a Web service is opaque to the caller. There can be a single resource that "fronts" for a bunch of other resources - which in turn can be organized hierarchically, scaled out, or employ whatever internal organization is appropriate. The caller does not (in fact should not) need to know about this internal organization.
This flexible routing is a great help in addressing our initial redundancy/availability concerns. But our audit service is much more intrusive than a simple router. What about security? Aren’t the SOAP messages encrypted such that only the intended destination can read them? How can the new intermediary listen-in? We’re not just routing; we need to crack open the whole SOAP body. I’ll hunt for a security expert to describe our options in using shared keys or a shared service for this scenario…
So in this and future Longhorn demos that use Indigo in seemingly client-to-client scenarios, give Scott Collison a thrill (inside joke) and think “node-invariant” computing where it’s easy for services to be clients AND servers AND intermediaries AND….