In a previous post, I mentioned Indigo's "A-B-C" programming mantra as one of the technology's greatest strengths. "A-B-C" stands for "Addressing, Binding, Contract" and is Microsoft's way of teaching the concerns of connected systems:
- Addressing: Where can I find the service?
- Binding: How is the service expressed across the wire?
- Contract: What is the information exchange of the service?
Are there other concerns in connected systems? Of course. But "A-B-C" is a great pedagogical device for approaching the programming model.
“Contract” is the service-oriented version of the API -- the developer's concern. “Addressing” is where the service lives on the network and is the administrator's concern. “Binding” is how the service is configured to show itself outside the process -- will it be over SOAP, MTOM, etc. Most likely the administrator's concern, but not entirely outside the realm of developer concern.
Why do I think this break-down of the model is important? Because it's very, very teachable. I see “A-B-C” as being crucial to one's initial experience with the technology. And I increasingly have come to believe that one's initial experience with a technology is more crucial than generally acknowledged to the technology's long-term acceptance.
My concerns about Indigo stem from the medium- to long-term complexity of the programming model, especially to the extent that the Indigo model conflicts with the CLR model. Did the failure of the EJB model stem from its inherent complexity or its relatively harder learning curve? If the former, then Indigo may face similar challenges. If the latter, Indigo seems to be on firmer legs.