In-Depth
ADT's Programmers Report: Microsoft's Don Box on SOAP, XML & VB
- By Jack Vaughan
- June 1, 2002
Roving educator Don Box has long been something of a spokesman for the Microsoft
developer community and an evangelist for Microsoft technology. So perhaps it
wasn't too surprising that, in early 2002, he joined Microsoft in the role of
architect. Neither is it surprising that, as he played a part in the invention
of SOAP, his mission at Microsoft is to create a useful Web service architecture.
ADT's Programmers Report Supplement Editor Jack Vaughan recently spoke
with Box.
Q: It was a leap for many Visual Basic developers to work over the last
few years with DCOM and distributed computing. Describe their challenges from
your viewpoint. How does .NET address them?
A: I spent a lot of time [as an educator] with both VB and C++ developers
before coming to Microsoft. For VB developers, one of the problems was that
there was any number of places their code couldn't run or run well. A lot of
the complexity that was in COM+ and IIS was put there to keep the VB code base
running. For example, COM+, which has kind of been the app server platform with
Microsoft, had to do all kinds of [thread management] in order to keep VB code
running well. That adds to the complexity.
The beauty of Visual .NET is that we have a modern common runtime, built with
an understanding of what kind of apps people are building today, and much less
need to do [management] under the covers. That was a major pain for VB developers.
Another major pain was that they always had kind of a second-class view of
new technology. In the past, new technology was exposed using low-level C API
or COM interfaces. In those days, it was very difficult for VB developers to
get access to newer technologies because they were designed to be accessed from
C. Probably around 1997-1998 you saw a switch on this platform. The APIs were
exposed using VB-friendly COM interfaces. But this made it more difficult and
caused performance problems for C++ developers.
The beauty of the new world is that there pretty much is unity across all the
languages -- there is a single type system and a single meta data format.
Q: There may still be a shortage of C and J2EE developers, but there are
quite a few VB developers. What useful traits do the VB folks bring to enterprise
development?
A: The number one trait of a VB developer is pragmatism.
The VB programmer understands that it's about shipping software. They don't
confuse craft and art. They tend to be craftsman, and very focused on solving
problem domain issues and making customers happy.
The C++ developer community, which I consider myself a part of, tends to become
enamored with the process.
Q: Yes, exactly. You just do not see that with VB developers.
A: Maybe it was the smaller surface area of their language, or perhaps the
real reason was that because VB had such a low bar of entry, a lot of people
who program in VB come from a wide area of domains.
Often, they come from the domain that they are writing the code for. They start
off writing macros in Excel or Word and [then they discover VB].
Q: Don't they still have to learn object technology to work with .NET?
A: I wouldn't say so. If you look at the common development scenarios in
Visual Studio .NET, there isn't a requirement to be a fluid, object-oriented
programmer. If you look at the way someone builds a Web service or form, the
experience is remarkably similar. There's not a lot of need to derive from this
and add an interface, and such. You can do that, but in terms of the prescriptive
path that VB leads you down, you can live a full and rich life without doing
any of that stuff.
Q: How does Java fare vs. the Microsoft server?
A: At Microsoft, we figure if you buy Windows, you pretty much have the
app server. There wasn't a lot of desire to break the technology into 18 different
products, all of which you have to pay for. A great example is the old Novell
story. There was a time you bought Novell NetWare if it was your file or print
server, but it wasn't really built as a general platform for people to build
platforms on top of.
The Windows NT approach was to build a general operating system, scalable to
both desktop and server systems. The idea was to make the platform as rich as
possible, so people could build compelling apps.
Q: You had a big hand in SOAP. What did you have in mind at the outset and
what do you see coming?
A: We wanted to build something that was small, and we didn't want to have
to invent a bunch of stuff. That's why we used XML and HTTP. The early specs
were fairly minimal; they didn't say a lot. That was sort of the magic of it
and what captured peoples' imaginations. It was a somewhat novel application
of stuff that was laying around already.
We tried to design extensibility in from Day 1, knowing that if we tried to
write a full-featured-from-the-ground-up protocol stack it had zero chance of
adoption. We basically found the right extensibility points, and that's where
the innovation and action is right now.
Q: What's your day job right now?
A: I work on the Web services team at Microsoft on
the Global XML Web Services Architecture [GXA]. We are taking advantage of the
SOAP architecture we laid out in 1998 and delivering the industrial-strength
features and functionality people expect -- security, flexible naming/routing,
reliable messaging, transactions and orchestration.
At GXA, we are coming up with ways of describing multi-service interactions
-- looking from the top down at your network and seeing that this application
is talking to that application, which is using these other three apps, and here's
the message exchange pattern. Having that kind of understanding allows us to
build a richer infrastructure. We can do a lot more to help developers [with
the] tools, and the platform itself can be smarter if we know what the message
sequences are.
Q: Will SOAP move away from the W3C's control over time?
A: No. I would be shocked if SOAP proper was not controlled by the W3C in
15 years. That's as far out as I can even fathom. That stated, quite often technology
comes from ad hoc communities, and once they gain momentum, then it is a good
time to make it part of the standards process.
[The W3C] controls the SOAP protocol. We like that. That's good. But I think
a lot of people are going to want to innovate on top of that. The innovation
on top of SOAP is not going to emerge from the W3C, but it may end up making
its way back to the W3C for the rigorous spec work needed to get a spec into
full standards shape.
Q: In reprise, what has Microsoft done lately to help programmers in the
enterprise?
A: This year we have done more than we have done in the last two,
three or four years put together. Visual Studio .NET is a pretty significant
investment for us. The primary motivation for doing it was to beef-up programmer
productivity.
A lot of people were getting stuck in the weeds back in the old days of C++
and COM development. We wanted to bring those people up the productivity scale.
At the same time, the people using VB were hitting the wall in some ways. The
way I look at .NET is that we made C++ developers more productive and VB more
powerful. That's a major win for the community at-large.
About the Author
Jack Vaughan is former Editor-at-Large at Application Development Trends magazine.