Whats Next for Next-Generation Apps
Whats Next for Next-Generation Apps
Don Box is an architect assigned to the "indigo" project at Microsoft Corp., where he is working on next-generation Web services protocols and plumbing. Box recently spoke with eWEEK Senior Editor Darryl K. Taft about upcoming technologies from the Redmond, Wash., company such as the Language Integrated Query project, Windows Workflow Foundation and Windows Communication Foundation (aka Indigo).
What do you see as the most interesting technology in your space?
I think the Windows Workflow Foundation stuff is the most interesting thing in my space. We call it "dub, dub, F" because its so long to say. We did a lot of work in Indigo since the last PDC [Professional Developers Conference].
If I look at the division I work in, were basically shipping another round of Indigo and getting ready to call it done. Weve been listening to people telling us what they like and where we suck. And were trying not to suck.
Whats the concern some people have about "WSDL [Web Services Description Language] first" or "contract first" development and whether Microsoft supports it?
Lets take a step back. Indigo is based on contracts. We take contracts very seriously. The contract system, for me, is the heart of Indigo. Now the contract can have many representations. We need an in-memory rep so that we can load it into the CLR [Common Language Runtime] and do something with it. The question is how we externalize that stuff, like how do we put it in a text file and share the text file.
There are basically two ways that we support with full fidelity, first class to all the contracts in Indigo: You can write WSDL or you can write annotated C# or VB.Netannotated CLR-friendly languages. We dont care which one you do; it doesnt really matter to us. [None] of those is the native format we use in Indigo. We shred [the code] into something thats highly optimized for the way our system works.
But we take the data from either sideyou can mark up your code, or you can mark up your markup. We dont really care.
If I were an enterprise architect and I had to write a bunch of contracts, Id write in a dialect of XML vocabulary that was fairly close to my world ... and then write the transforms to spit out the WSDL and whatever else I needed to make my platform of choice run. If its Indigo, Im going to spit out those annotated C# files.
If its Java, Im going to spit out annotated Java files. You could use WSDL as the source material to generate that stuff, which is the mentality a lot of people have. The problem is its just not the best way to go.
Next Page: Questions and skepticism.
Questions and Skepticism
Why is the perception out there that you guys dont support it?
I think its because of the way people demo it. Its not our job to give people a religion. Its not our job to tell people this is the right way or this is the wrong way. Its not my job to convert people; its my job to ship software that people want to use.
Speaking of religious issues, you came out a bit skeptical about JBI [Java Business Integration]. What was that all about?
It was not clear to me exactly what was going on. I looked at what JBI was, and, for me, it was like, "Wow, that looks kind of like what we did in Indigo." However, when I talked to my friends in the Java community, they said they wanted to achieve the same things they wanted to achieve in Indigo, which was to have a single way to do messaging. The problem was, in my mind, its a little too "meta."
When we did Indigo, we basically said, "Were going to own the box. Were going to say, We know Windows programmers or .Net programmers want to program with messaging." So we said, "Were going to figure out what the right way to program messaging is, and thats the way were going to do it."
And we will make sure that we have a clean message to the developer community about where were going and what were going to do. Specifically, the things we needed to look at around MSMQ [Microsoft Message Queuing] were a lot of infrastructure out there and a lot of programs.
So we said, "Were going to make sure that the MSMQ API, which is specific to MSMQ, wasnt ready to be generalizable to JSON or POX or whatever." So, well make sure that MSMQ developers have a clean path to get into the Indigo world. Thats the way its going to work. So, we just have one method, and we write these adapter thingies to spit them out as arbitrary formats.
With JBI, I look and I think, "Man, how does that link to JMS [Java Message Service]? Do I need both? Do I want both?" It just wasnt clear to me. In some ways, as some Java guy termed it, it is basically a metacommunity. And I am at a point in my life where Id rather not go meta; Id rather just build the right thing and use the right thing. But thats where the Java community was. The user base seems pretty happy, even though IBM and BEA [Systems Inc.] arent jumping on yet. So its not for me to judge.
When you made your blog post on this, you got a lot of responses. Did anything come back to change your thinking at all?
Well, I was genuinely puzzled as to how to think about this for EJB [Enterprise JavaBeans] versus the servlet. For me, I look at the servlet architecture and API and say, That would not have been a horrible place to start.
With EJB, theres a lot of "cruft" [a term for old, dusty code] and would maybe not be where I would go, but servlets didnt look so bad. Servlets have a non-HTTP-specific modelat least the last time I looked at them, before I worked at The Firmthat has a general notion of a request or a reply. Everybody knows it. And everybody who knows it, by the way, likes it a lot.
So maybe if I ran the Java world, I wouldve generalized servlets a little bit more to satisfy some of these needs.
But instead, its like, lets do yet another one of these "gimundo" architectures. And its yet another thing I have to have a security spec for because I have to secure it. I have to [know] how transactions relate. Its a lot of work.
I cant say it sucks. It just may not have been the approach I wouldve taken.
Next Page: The open-source world.
Whats your view on the open-source world taking this stuff on?
I think its great! The more people we have thinking about hard problems, and maybe coming up with solutions, to me is strictly good.
So you dont care about any IP [intellectual property] issues that might arise?
There are people that care about the IP issues, and as a shareholder of Microsoft, I hope the right things happen. But just as a general technical guy, which is really the only way I know how to operate, I think its great that people are thinking about solving hard problems. I hope people are innovating and not doing other things.
Well, how much work is yet to be done?
Indigos going to ship. Its going to be next year. But we have so much work to do. I look at the WWF stuff, and that opens up so many things and makes me say, "If we knew then what we know now." ... Theres a lot of value left to add.
So whats the next interesting thing beyond that?
I think there are a lot of seeds of interesting stuff in WWF. So if you want to ask me what would be an interesting area to mine for directions, ideas, differentiators or new innovations, I think WWF is just a cauldron of interesting goop that both the community at large and [we] will figure out as we go along.
The reason I find it interestingjust to be clearis that we know at the heart of that system is the separation between code and declarative metadata.
If all we did was LINQ and said all were going to do is ship LINQ and were not going to do anything else for five years, wed still be kicking ass. Its that good.
I think theres a lot of fodder for innovation in the basic premise of WWF. The separation of opaque code from the transparent description, configuration, model or whatever you want to call itthat to me is the most interesting thing on the planet today.
Thats a theme. Were doing it on the communications pillar side. But the presentation guys are using the exact same premise. We focus on the roles of the programmer and the business analysts. They look at the programmer and the designer. Its the exact same premise and almost the same technology stack.
Are you saying WWF also supports model-driven development?
Thats a fancy name for it. I just look at it as a pure programmer. What theyve done is embraced and celebrated the difference between the programmer and the person who uses the artifacts of the programmer. So writing those XAML [Extensible Application Markup Language] files that tie together the activities, and having the tooling support, is a really interesting story. Theyre going to have a great V1 [Version 1]; their V1 is really good. They own their own tooling, and its great. Its fantastic; it makes me tear up. The Indigo guys say, "How can we get one of those?"
They have a general-purpose engine for taking XAML and code and wiring it up together and making it run. So we thought about what it would look like if we made some of that code Indigo code. I think the combination of the two is greater than either one alone.
So, how does this make things easier for developers?
One of the things we hear from people who want to use Indigo is: "I wish I had a model (and I dont mean the highfalutin model) where I could have parts of the service that I could change without having to bring in a high-priced developer. Id like to let the IT pro have a say and maybe be able to write declarative policy using the rules facility of WWF to do the authorization choices." Or, "Id like to be able to make routing decisions based on business conditions." WWF gives us a really nice palette to build out that kind of solution.
Check out eWEEK.coms for Microsoft and Windows news, views and analysis.