A Failure to Communicate

Rich Turner replies and I'm more confused than ever. He's wearing his Indigo-colored glasses and misreads just about everything I wrote. I'll leave aside the SOA discussion for now and concentrate on Indigo. I'll try to make this as plain as I can.
 
I want to design and build services with Indigo. I want services, messages, and operations to be first-class citizens in the programming model. I'm perfectly happy to use XML as the serialization format for messages and XML Schema as the schema language for describing messages. I'd rather not have to deal directly with the XML and Schema in the programming model. I want to work with a higher-level abstraction. Ideally I think this would be a new .Net type called Message (or message if you prefer C#). This would be an addition to the existing types (classes, value types, interfaces, arrays, pointers, and enumerations). This type's members would be restricted to public fields (no properties, no methods, etc.). The datatypes for those fields would be limited to the intersection of those simple types in both .NET and XML Schema AND complex types constructed from those simple types. It would be really cool if there was a Whitehorse designer like the class designer. Of course, to go along with the Message type, I'd like a true Service project in Visual Studio.
 
There are other ways to implement what I really want, but this, I hope, makes clear a few points that I have been unable to get across to any member of the Indigo team. First, I don't want to design an object model and then decorate it with attributes to design my messages. I want to design the messages directly. Without using any attributes. No attributes. What's so hard about the "no attributes" part of this? Everybody else that I've discussed this with understands that I don't want to use attributes. They may not agree with me, but they understand that I don't want to use attributes. Rich, just like the rest of his team, says, "create a data structure that you've adorned with the attributes necessary to describe the construct."  Using attributes is a way of saying that the message isn't real or important. It's a just a messy detail that Indigo will handle for you. Second, when I say I want to work with messages, I'm not saying that I want to process the XML directly. I don't want Indigo to "get out of my way", I want it to help me. The Indigo team has this bizarrely bifurcated view of the world that equates message-oriented with hard-core bithead and object-oriented with Average Joe Developer. It's only that way in the Indigo world because they've made it that way by refusing to expose their underlying model in a consistent manner. It doesn't have to be that way. There's a very straightforward, business-oriented messaging model that could easily be layered on top of Indigo. If only they could see it. There's clear evidence all around them. WSE is closer than Indigo is, but BizTalk is where they really need to look.
 

Posted May 09 2005, 10:09 PM by john-cavnar-johnson
Filed under:

Comments

Bruce Williams [MSFT] wrote re: A Failure to Communicate
on 05-09-2005 8:40 PM
Would it be accurate to say that you are (reasonably) satisfied with the _features_ of Indigo, but you don't want to use C# (as it exists today), but would prefer some mix of a language ("M#"?) that has SOA constructs as first-class language elements, and perhaps equivalent GUI tools like the Biztalk 'Mapper' you described in another post?

If that's the case, there are (at least) two answers:

#1 - By the time we were really solidifying our OM story in Indigo, we weren't really in a position to push new language requirements into Whidbey. I'm not promising it will happen in the future, either; but I'm sure the idea has been and will be given real consideration. Having reasoned feedback and requirements from folks like you really helps, BTW - thanks!

#2 - We'd really like our technology to 'feel' like the older Microsoft technologies that it replaces. It just makes life easier for the many developers out there trying to learn and port to Indigo.

on the flip side, perhaps 'M#' is a great third-party opportunity - C# is just a language that compiles down to IL; there is no reason some enterprising company out there couldn't come out with their own M# that compiles to IL, makes calls to Indigo as appropriate, and in general implement everything you want. (This is why I asked if Indigo had all the *features* that you want.) I understand this might not be the perfect solution for you, but perhaps some other reader of this blog will take it as a challenge... *grin*

Another point about the GUI stuff - its definitely not too late to get more good GUI tools into Indigo - maybe not for Beta 1, but in a later release. So *please* keep telling us in great detail all the different kinds of cool tools you'd like to see, to help you write your distributed applications using Indigo. If you'd like to exchange e-mail with one of our 'tools' folks directly, drop me a line at bwill@microsoft.com and I'll hook you up.
Brain.Save() wrote On Attribute-Based Programming Models
on 05-09-2005 10:47 PM
Brain.Save() wrote On Attribute-Based Programming Models
on 05-09-2005 11:57 PM
BradK wrote re: A Failure to Communicate
on 05-10-2005 8:51 AM
*Affordable* Biztalk-esque features in Indigo. Great idea, I think. Rocky Lhotka and you seem to have the same thinking I do right now: 1. Messages, and 2. Services that are tolerant to un-pretty messages. Would that be considered broken contracts in Indigo ?
Ilya Baimetov wrote re: A Failure to Communicate
on 05-10-2005 10:30 AM
Finally!!!
Almost 12 years ago, when I was a graduate student, we built a OO runtime, where everything was an object, including methods and messages that the objects excanged. And there was a single method (first responder) that would had a first chance on all messages coming to the object.
With scuh base object model, we did a lot of intersting experiments with message dispatch techniques. Even inheritance was not built in and we implemented several different approaches. All possible because message was a first class entity, and could always be intercepted. Pretty similar to WINPROCs, if you think about it :)

- Ilya

Add a Comment

(required)  
(optional)
(required)  
Remember Me?