[XML magazine] SOAP InterOpera

[Adam Rifkin]

"The whole purpose of SOAP as a foundation for Web services is that it will,
over time, give nearly universal interconnectivity on a worldwide scale, as
we do with other Web technologies."

"One of the things that's been so wonderful about SOAP since it first became
public is that it's really been driven by programmers from the ground up,
with all the best that that brings with it-people working quickly, people
cooperating to solve problems in the moment."

SOAP makes integration better, faster, cheaper.


http://www.xmlmag.com/upload/free/features/xml/2001/soapinterview/soapinterv
iew-4.asp

SOAP InterOpera 
by Steve Gillmor  
 
Given SOAP's role as the underlying specification for Web services, the work
being done on the SOAPBuilders discussion list regarding the state of XML,
and particularly, SOAP interop has attracted a lot of attention on Web news
sites, weblogs, and trade publications. XML Magazine Editor in Chief Steve
Gillmor and Editorial Director Sean Gallagher hosted a roundtable discussion
with a number of key players from the SOAPBuilders and W3C communities:

Glen Daniels leads the Web Services engineering team at Macromedia, is a
member of the W3C's XML Protocol group, and is an active contributor to the
Apache group's open-source SOAP engine. 

Simon Fell is lead architect at StreetFusion, and the author of the
pocketSOAP and 4s4c SOAP/COM toolkits. 

Paul Kulchenko is an open source developer and the author and maintainer of
the popular SOAP::Lite module for SOAP clients and servers in Perl, the
XMLRPC::Lite module that implements XML-RPC protocol, and the UDDI::Lite
module, a client interface for UDDI repositories. 

Andrew Layman, Microsoft's XML Web Services Architect, co-authored the SOAP
1.0 and 1.1 specifications, the WSDL specification, and the first XML schema
submission to the W3C. He is a coeditor of the W3C Namespaces in XML
specification and has participated in W3C XML work since early 1997. 

Noah Mendelsohn is a Distinguished Engineer at IBM and Lotus Development
Corp. He is an editor of the recently published W3C Schema Recommendation,
and a coauthor of the SOAP Version 1.1 specification. 

Jake Savin, UserLand Software developer, is coauthor with Dave Winer of A
Busy Developer's Guide (BDG) to SOAP 1.1. He is currently responsible for
UserLand's SOAP implementation, and works on UserLand products including
Manila and Radio UserLand. 

Sanjiva Weerawarana is a research staff member and manager of the component
systems group at IBM TJ Watson Research Center. He has been actively
involved with evolving the Web services platform, including SOAP, WSDL, and
UDDI, and has contributed to several implementations including SOAP4J,
Apache SOAP, IBM Web Services Toolkit, and the WSDL Toolkit. 

Dave Winer is founder and CEO of UserLand Software, a columnist, weblogger,
and software developer; and one of the coauthors of the SOAP 1.1
specification. 

Winer: I think it's working, Steve. If you look at the interop matrix tests
and see how the engineers are working with each other-it's truly a thing to
behold. It started out rough and we had to get accustomed to each other-and
there are different ways of thinking and different views of the world-but in
the end, engineering took hold here and I think, for the most part, it's
working.

Daniels: I would agree with that. There's a couple of interesting things
that are going on in parallel. One is that at this very basic level,
everybody wants to get their applications talking to everybody else's
applications, so there's this at-the-byte level interoperability that
everybody is trying to figure out: okay, if I pass you an integer, are you
going to be able to decode it? That's really cool.

Then, there's this second-layer set of discussions as people are improving
their implementations, which gets into a lot of the interesting areas that
are open to interpretation in the spec. That's some of the most valuable
stuff that I've seen so far, all these bright minds coming together and
saying, how are we going to deal with these things, what kinds of
compromises are we going to have to make, and how can we move together as a
community into helping each other to figure this stuff out? I'm also on the
XML Protocol Working Group in the W3C, and we're definitely very excited
about dealing with all of these issues that are coming up with the SOAP
spec. Before SOAPBuilders, there wasn't really a solid place for everybody
to be working together and trying to dig into these things. I think it's
great.

Layman: One of the things that makes this particularly hard-but is really a
testament to what's been accomplished-is that we're not just talking about
getting an implementation or even a couple of implementations of a single
language to work together. What's being dealt with here is getting some
languages which are fairly different in their underlying type model to be
able to get data back and forth. To contrast this with something like Java,
which would say that the way that you get things to interoperate is that you
get all your programs to be written in one language-what's happening here is
that you've got people getting Python and Perl and Java and C to
interoperate, and then they're having to deal with issues like how do
cross-language serializations happen? How do you deal with multireferenced
objects? What's the right serialization order? Those things are trickier-and
they're being solved.

Mendelsohn: What's particularly important to note is that not only are we
seeing tremendously impressive interoperability across a very large number
of implementations, but with SOAP in particular, it's absolutely critical
that there be such universal interop. When you're sharing code, that's
usually something you do to integrate perhaps a tool with an application or
something like that. The whole purpose of SOAP as a foundation for Web
services is that it will, over time, give nearly universal interconnectivity
on a worldwide scale, as we do with other Web technologies. Therefore, it's
absolutely critical that we see universal interoperability across a wide
range of implementations, and that's why it's so particularly heartening to
see this very rapid progress at this point.

Winer: Yes, if you think of the World Wide Web as being a publishing system
that crosses all operational boundaries, this is almost like a worldwide
scripting environment-it crosses every boundary and allows people choice. As
Andrew was saying, interop in the "old days" meant you write everything in
Java, and today it gives people choice-or at least that's the promise of all
this work.

Fell: Obviously, we've come an amazing way in a fairly short space of time
in terms of interop. You've only got to go back one or two months-it was
pretty much a mess. It's pretty impressive just how far we've come. One
thing to bear in mind is there's still a long way to go.

Gillmor: When you say it was a mess, can you be more specific?

Fell: In general, interop was pretty poor; there was no real organization in
terms of getting those issues resolved-largely individuals working on their
own trying to move stuff forward, but...

Daniels: Everybody only has one brain's view on this very complicated and,
in some places, fuzzy specification, so coming together into this group
where we can all talk to each other and play with our different
implementations has really shed a lot of light on what you do to be
interoperable. An example: there's a very basic extensibility mechanism in
SOAP-saying, you can put these headers in the message and you can mark the
headers as mandatory-saying, this must be understood for this message to
succeed.

A lot of the implementations hadn't really come to this idea that one of the
absolute core ways that you deal with extensibility is by agreeing to fault
in a well-defined way when there's a problem. If you see an extension that
you don't understand-even if you don't deal with header processing at
all-you are required to do this fault. It's a very small thing, but it
enables any application that you can imagine with SOAP to smoothly at least
fail in a comprehensible way with any other implementation. Having come to
that decision as a group, this is great, and we all learn stuff like that
all the time.

Gillmor: Dave, is that like your 404-error idea?

Winer: It's a lot like HTTP in the sense that there's a wide spectrum-HTTP
is a beautiful protocol because it allows very small implementations and
very rich implementations at the same time, and I think SOAP is there, too.
But I'm interested in what Simon was saying-and he didn't really get to
finish the thought. Simon, you said that there was still a long way to go
and I'm curious-what do we need to do from this point?

Fell: Currently, there's a lot of implementations-they all, largely,
implement and work the same way in terms of interop-but there's still a lot
of dark, dank corners in the spec that haven't been investigated. A good
example would be the serialization-order thing that's been discussed over
the last couple of weeks. As it happens, that hasn't been an issue yet
because everybody has decided to serialize their data in the same order, but
that doesn't appear to be a requirement in the spec. If somebody were to
serialize their data in a different order, it would flag up a lot of interop
problems.

Winer: Is that true? Have you actually verified that the implementations
depend on serialization order?

Fell: Not in terms of an actual test, but based on what various people have
said; i.e., in the discussions. I don't think there are very many current
implementations that cope with it.

Winer: Hmm, interesting.

Mendelsohn: One of the things that's interesting to see going on here is
that we now have two efforts that are extremely complementary. One is a
fairly formal effort by the W3C to produce a specification that ultimately
will be more rigorous, and will cover the edge conditions and meet perhaps a
slightly broader range of needs. On the other hand, one of the things that's
been so wonderful about SOAP since it first became public is that it's
really been driven by programmers from the ground up, with all the best that
that brings with it-people working quickly, people cooperating to solve
problems in the moment-and those are very complementary efforts.

It means that all the things that you've just heard discussed-where a
problem might be this week, etc.-we're going to learn stuff hour by hour and
day by day about what's possible and what's problematic that will make it
much easier for the W3C Work Group to do an effective job of knowing how a
spec is really going to work when we deploy it.

At the same time, having a group out there whose job is to formalize this
stuff and make it rigorous is going to mean that we have a good vehicle for
capturing the best of the insights that are generated hour by hour and day
by day as this debugging goes on. Having those complementary efforts is
really wonderful and is a very important aspect of what's happening right
now.

Layman: One of the nice things that's come out for me from looking at the
SOAP spec work is that when Noah and I and a bunch of others, like Dave,
worked on it a year or a year and a half ago, we did the best job we could
thinking things out. What's been really nice for me to see is that as people
have started using it-really building systems with it-there have been a
bunch of problems and issues that have come up, and some of them have
identified some awkwardnesses in the spec and certainly some areas that, to
put it charitably, the spec was not awfully clear on. But nothing has come
up yet that is an absolute show-stopper; everything that has come up has
been in the lines of, "well, this is a little awkward, but the spec really
does solve the problem." It's enabled us-thirty or forty companies-to
actually build stuff without having to go back and say "let's throw the spec
out and start over."

Weerawarana: Yes, I'd like to reiterate something that Simon was saying,
too. We've made a very good start in getting interoperability going, but a
lot of the interop work we've done is at a basic level of SOAP today.
There's a lot of richer functionality that needs to be worked on to get
interoperability across those layers, and certainly we've made a very good
start. As Noah said, the W3C effort is making an effort to clarify the
entire stack in terms of coming up with a more rigorous specification of
what this protocol is supposed to be, and then this interop effort will
hopefully keep growing to addressing the entire specification in terms of
the functionality that they hope to address.

Gillmor: Jake, could you describe a little bit of the process that you and
Dave went through in producing the BDG?

Savin: We wrote it together, one or the other of us typing onto the Web,
while on the phone together discussing the various details-referencing the
spec and trying to get it as clear and easy to understand as we possibly
could because we had to have a starting point. And I think it served that
purpose quite well. Your mileage may vary-I'm sure other people have varying
opinions, [laughter]-but it was a good jump-start for us, and it enabled us
to start defining tests that would give us real, usable results.

Layman: I would absolutely support that. Having the BDG was, in many ways, a
really low bar that we could all measure ourselves against. But just getting
up to that point on interop fleshed out a lot of issues and produced a great
deal of discussion over what we really needed-how the spec should be, and
what it said, and what to do about it.

Gillmor: Can you give me examples of that?

Layman: The discussion earlier about headers-this gets back also to your
question about 404, so let me digress for just a moment. One of the things
that really made the Web work-as opposed to preceding attempts to build
world-scale hypertext-was that the earlier attempts had centralized
directories and they implicitly assumed that everything would work all the
time, whereas what made the World Wide Web work was the assumption that
failure will be quite common. You may try to follow a link and it isn't
there-you get a 404-it times out-it just doesn't work, so you deal with it.
SOAP takes somewhat the same approach. It doesn't demand, when you send a
message, that the receiver always be able to process it flawlessly; what it
does specify is how he can tell that he can't and how he should deal with it
when he cannot. That's the function that things like headers and this
mustUnderstand attribute have. They allow you to put in a message, something
that says: this part of the message-it's not optional-and you might not
understand it, and if you don't, I want you to fail in a predictable way
instead of just being really quiet about it.

Winer: Yes, we weren't even really speaking the same language up to the
point where we had that discussion. Before we had the BDG, as far as I was
concerned, I didn't feel we had a framework.... In fact, it's interesting
because we're going through much the same thing right now in the XML-RPC
community. I got laughed at yesterday for saying that we need a framework
for a discussion, and I was just trying to explain what was going on and why
it was so cool in SOAP interop-and if you haven't been there, you can't
know.

So, we put this thing out and a lot of people were shocked that we had the
audacity to actually write something other than the SOAP 1.1 spec to
describe what we were doing. But, until that point, we didn't even have a
way to get pushback on what we were doing. And then, Keith Ballinger, who's
also at Microsoft, said, "well, I can't interoperate with this unless you
reject messages you don't understand"-and in that was a big turning point
because we said, "well, geez, we didn't know we were supposed to do that."
[laughter]

It's like you catch these bullets in your teeth and go back and redo it-and
then basically said, "okay, Keith, we're rejecting the ones we don't
understand"-and, all of a sudden, we're starting to talk the same language.
I'm very gratified to hear Andrew say that the BDG was a positive step. We
felt that it couldn't happen without something like that being...

Layman: Dave is right. When he first proposed that, Dave and I talked a
little bit on the phone, and my attitude was a bit of "this thing is really
minimal-can we do better?" And, Dave was right in saying "we must do at
least this much."

Winer: If you don't have a small barrier, we're not going to get a lot of
independent developers here. And I think this is where you get a different
sort of viewpoint. I want to see a hundred, maybe two hundred SOAP
implementations; I would like to see a market develop here that's like the
market that existed in the early days of the Apple II or the IBM-PC or the
Macintosh or the early days of the Web. And for that to happen you can't
have it be orderly-it has to be easy. The one thing that each of those
environments had in their early days was that everybody could play if they
were willing to make an investment in understanding the technology. It's
relatively easy for a large company to add more people to a team, and once
you had more people, they, of course, wanted to add more complexity and
whatever, and that tends to shut out the small companies.

Being a small company ourselves at UserLand, it was absolutely, totally
important for us to have it be "doable." There are a lot of things we can't
do that the bigger companies can do. The inverse is true as well: we can
take more risks. As a smaller company, we have fewer people to please. We
have a lighter communication firewall. We can generally move a little bit
more dangerously than the larger companies can. And it's required all levels
of participation here to get to this point. For it to all be successful,
it's going to require just a lot of really strange, weird ideas, [laughter]
and hopefully we'll see lots of those.

Kulchenko: Yes, Dave, you're absolutely right. It's a very important goal
that the BDG serves. When I started to do it, it was, like, soft
implementation-I didn't realize how difficult it might be. I thought that
eighty percent of work was to create deserializer and serializer, then add a
transport layer, and you're almost done. Now, if I were seeing all those
discussions on the SOAPbuilders maillist-I might not even think about trying
to do it. BDG isn't low level, but it's a simple level of interoperability
and functionality that you need to get. We've got today a new PHP
implementation, and they start from implementing what's specified in the
BDG, and I think that's been created because, as you pointed [out], we can
get more and more developers on board. It's a starting point for them, and
it's truly amazing.

Winer: Why can't they have some success right off the bat? We ought to be
having a party every time one of these new guys comes along.

Gillmor: SOAP co-author Don Box posted a document called "A Brief History of
SOAP," and one of the things that he addressed was the issue of WSDL and its
relationship with SOAP. He says, "Is WSDL perfect? Not by a long shot. Is it
workable? For the most part, yes. Does SOAP XML messaging make sense without
something like WSDL? No way."

Layman: If I'm going to interoperate with your service, you have to have
some way of publishing what your service actually implements: what the
message names are, what the structure is of the messages-and you can do this
in a couple of ways. You can put up a document, like the BDG did, that uses
a more programming-like style of saying, "this is what a method call would
look like,"-and then it supplements it with a bunch of prose and also says,
go read Section Five out of the SOAP spec. And that's sufficient, a form of
metadata, if you want. But it's frequently limited in the flexibility of the
structures that you can pass back and forth, or it has the limitation that
the whole thing is not machine-readable-remember, a whole bunch of this
stuff was in prose. Or you can use something like WSDL and make the whole of
your definition machine-readable. WSDL allows you to handle a wider range of
issues and it allows more automated tool support. But what Don was getting
at there was something in addition to that. Remember, we don't have a type
system; we have a whole bunch of languages and programmers who come at this
with different attitudes on type system. What schemas have allowed people to
do is that everybody can agree on a single type system-the one that's in XML
Schemas. That's not to say you have to, but the presence of it there allows
a sort of a neutral zone-a Switzerland of type systems-and everybody can
say, it's not the best one, but it is a singular one, and we can map all of
our stuff in and out of that.

Mendelsohn: I think the controversy about this has been a little overblown.
Don may have been a bit too categorical in what he said, but WSDL is
incredibly useful. Here's where a lot of the controversy about this traces
from: when you have languages like C or Java that are basically compiled
languages, then it's particularly useful to have things like WSDL. WSDL can
tell you-before you see a message, before one comes in, when you're building
your app, when you're compiling it-here's what the messages you're going to
see are going to look like. You can write your code to this, you can compile
it and, trust me, when a message shows up, your code will work-that's very
useful.

When you have more dynamic languages like scripting languages,
machine-readable descriptions like WSDL may still be useful, but they're
much less necessary. It's much easier to imagine how you would just build a
piece of code that would take in any message off the wire and do something
reasonably useful with it. Of course, at some level, the application has to
know whether it supplies stock quotes or weather reports, but a certain
amount of the discussion about WSDL and its value really traces back to that
difference of perspective. Both perspectives are good and important. WSDL
can be useful in certain cases even with scripting languages, but it's
probably less essential in dynamic environments.

Winer: I have a different philosophy on this stuff. I think that Don, in
that article, was replying to a lot of what I had already said-and it's a
pretty wide-ranging difference in a point of view. It's not strictly a
difference between dynamic and static languages; it's more a difference in
culture and what you believe in. I believe in very lightweight, low-tech,
loosely coupled systems. Given a choice between C and, oh, I don't know,
CORBA, I would probably choose C in a heartbeat. I like to be as close to
the metal as I possibly can be.

If there's a difference between what the IDL says and what the app does,
there's absolutely no question which way you do it-you do it the way the app
requires it. We went through this in excruciating detail in the Macintosh
scripting market in the early 1990s; many of the same arguments-in the end,
what worked was communities of developers working at the intersection
between products. I don't think you're going to see a huge number of
different interfaces. There's going to be some standardization at the next
level up. For example, we proposed an application called XML Storage System,
which is much higher-level than SOAP. There'll be others, and the developing
"glue" for each of the different environments is going to itself be another
sort of SOAPBuilders type of process. I don't know how many people are on
the SOAPBuilders list-it might be a hundred or two hundred. If this stuff
really works, within a couple of years we'll be looking at a hundred or two
hundred thousand people working on next-higher-level-up issues-on how
applications work together.

Going back to what Andrew was saying before, the beauty of the Web was very
much like this: you only need to have a domain registered in order to
participate in the Internet. And in order to participate in the Internet as
a scripting environment, going all the way and trying to make everything be
supported by software-I don't believe in it-I just don't believe it's going
to work. I wasn't a COM programmer-Don, I think, comes out of that culture,
and perhaps Andrew can shed some light on this. Did IDLs work in the COM
world?

Layman: My experience has been that there is a pretty sharp division within
the programming world into two styles of doing development work. You can
call them top-down or bottom-up. There's a huge community of people that act
in the fashion that Dave described where you get some code written, you get
some other code written, and you keep evolving it until it works the way you
want it to. There's another very different approach-which you find more
oftentimes in big company shops with more formal projects, or where you have
a larger project you're trying to work out-where somebody will work top-down
and figure out the specifications for things, publish the specifications,
and then you later go in and fill in more implementation details. Depending
on the circumstances, one of these is going to be the optimal way to do
things. If you want to take the second course where you publish the external
presentation of a Web service, and then you take that as a contract and
people can just count on that contract and you build within that, WSDL gives
you what you need.

Winer: I think we have an agreement on that, Andrew. Let all the different
approaches have a chance and that's fine-whatever people are comfortable
with, then that's what they should use.

Layman: Would it be fair to say that when you and I started talking about
WSDL a while ago, you were of the impression that we thought that everybody
must use WSDL, whether it fit their situation or not? And I think you were
pleasantly surprised to hear me say, well, no, if it fits your situation,
then we think it's pretty useful.

Winer: Andrew, I've been pleasantly surprised many, many times [laughter]
throughout this process. That shows a lot of flexibility. I've had Microsoft
people tell me, in no uncertain terms, that WSDL was absolutely a part of
SOAP interop and inextricably involved in it, and under no circumstances
would it ever work without WSDL-and I'm pleased to see the flexibility. I
hate the "love fest" part of this-we're going to have to disagree on
something, Andrew. [laughter]

Gallagher: I'll throw something out here we can disagree on now.

Winer: All right. [laughter]

Gallagher: Where does security fit into interop? Is it an issue that gets
addressed within SOAP interop, or is it something that each of you is going
to take on individually?

Winer: I think the transport takes care of security. I think of it as a
bunch of different levels there.

Gallagher: Beyond transport-level security, is there a place for role-based
security within applications in SOAP, or is that something that needs to be
handled at some other interface level?

Layman: There's absolutely a place for role-based security. The issue is,
when you say "within SOAP", I would say absolutely not within the SOAP spec
per se-by which I mean the minimal SOAP specification. But that's what
headers are for, right? So the basic tests that we're running are: can we
exchange SOAP messages and can we properly process headers or at least
recognize the ones that we cannot? Then, you could move up a level and have
some applications, which is obviously a smaller group than the total
universe of SOAP applications. One might have a header in it, which is
designed to convey role-based security information from one party to
another. Not all SOAP apps have to do this, but it would be nice to have a
standard way of doing it when they want to. And then you can always put a
mustUnderstand attribute on the header and say, "I'm really serious about
this-if you don't understand this header, don't process the message!"

Daniels: Recently there was a Web service workshop out in San Jose that the
W3C hosted (the minutes to which are going to become public pretty soon) and
there was this question at the end of it: what does the community at
large-all of these companies that have come together to talk about
this-really want to be discussed and where should we think about forming
working groups and thinking about standardization efforts?

One of the most popular things that came up in the discussion was thinking
about the next level up from SOAP-what those extensions are and how people
can cooperate to be able to do things like security and transactionality and
all these other things that more business-level services want to do. But
everybody realizes that the really cool thing about the whole idea of an
orthogonally extensible spec is to have this core that everybody can
implement and then you're free to stop there, and that's great. Whatever
chunks that you want to implement in varying directions, you're more than
welcome to do-and, in fact, anybody can go off and define these things-but
there's a core set of stuff that maybe some people are going to get together
and say, hey, let's standardize this. But the great thing is that doesn't
stop anyone else from deciding there's a better way to do it later either.
It scales very nicely.

Weerawarana: Yes, I would also like to repeat some other comments that
Andrew made. Security-certainly transport-level security plays a vital role,
but that doesn't cover the entire requirements. There are a lot of
end-to-end security requirements that are not covered by a single
transport-level solution. Again, we should go back to the approach that they
have addressed with the BDG, which is, this is not a one-size-fits-all
thing; it has to be incrementally swallowable for the requirements that you
have. In some cases, HTTPS is all the security you need. In some cases, you
need digitally defined authenticated things, the certificate authority that
you need. The infrastructure must support the entire gamut, but that doesn't
mean that any specific application would require all of that, and if they
do, it should be available. But it certainly shouldn't be stuffed down your
throat unless you really need it.

Gillmor: One of the comments Dave and Jake made In a postscript to their
"Busy Developers' Guide to SOAP 1.1" document, Dave Winer and Jake Savin
indicate that there may be more BDG-style documents. Given the success that
the BDG seems to have had in jump-starting some of these interop issues, do
you see that coming?

Winer: That came from a conference call that we had right around that time
where people seemed to have a very strong interest in doing that-that's a
recipe or cookbook approach to make it easy to do any additional steps that
we might want to do. It makes sense.

Mendelsohn: Clearly there's a need to get the simple stuff right first and,
for certain purposes, to do only-as Dave says-the simple stuff if that's
what meets the needs of your applications. On the other hand, what we need
to keep an eye on is that the reason we're doing interoperability at all is
to try to maximize the degree to which everybody can talk to everybody. And
that means that we need to be careful when we define subsets. In fact, you
have to look a little closely because sending out messages that use only a
subset of a specification is always a safe thing to do-or almost always-and,
certainly, using a subset within your own world to meet a purpose is always
a safe thing to do. Putting up generic middleware that only understands a
subset of the messages that may be sent to it is not necessarily a bad
thing, but it can be in conflict with the goals of interop.

Winer: What's your scenario...?

Mendelsohn: If I made a Web browser that did not understand the majority of
HTML, for example, there may be circumstances in which that's the right
thing to do, such as on a small device. But we all know that it also makes
it difficult to have universal interoperability. We need to do that stuff
carefully, I believe.

Winer: There's just a certain tension here, and I don't know how to put it
except to be blunt-this isn't necessarily something that I feel, but I've
certainly heard it from a bunch of other smaller developers-I wonder what
that means? Maybe Andrew and Noah and Sanjiva, since they represent the
larger companies-as far as each of your companies' visions is concerned,
what will SOAP interop mean, say, two or three years from now? What kinds of
applications will you guys be running that may not work with the BDG or a
BDG-level application?

Layman: Let me answer that in two levels. The first one goes more
immediately to what Noah was saying. If we're designing a spec for
interoperability, it would be a rather pathetic way of getting the answer to
say "well, you know, we've got the spec: everybody sends a '1' over the wire
and then we cheer because we got that across," [laughter]. We would have cut
the spec down to the point where you can, everybody can, do the same thing,
but nothing useful can get done. And then, of course, at the other extreme,
you could have a very, very convoluted specification, something that was so
arcane that teams of thousands could work on it, like the pyramids. The
trick is to find a level at which you're going to get the kind of useful
work that programs need to do without dipping into arcana, or beyond what
we're driven into.

Winer: We had this discussion at the W3C meeting that Glen referred to. I
was sitting next to David Fallside, who is the Chair of the Working
Group-Bob Sutor and Andrew were there, and Sanjiva was at the table, too-and
David had an interesting comment: the guys who have a lot of experience
doing these kinds of things say, you have to have this, this, this, this,
this, a whole long checklist of things that without which, based on their
experience, none of this stuff can work.

And my response to that was, I'm familiar with that because when I came to
the Web, I was a GUI developer. I knew all about line-to, move-to,
draw-string, frame-rec, fill-rec, pull-down menus, mouse controls, all those
kinds of things. But then, coming to the Web, I had to throw most of that
knowledge by the wayside because HTML doesn't have any support for anything
remotely like that. Yet, we were still able to build what is a remarkable
networking system, even with a very limited vocabulary. And I think Fallside
is right-what we're feeling here is the pressure from people who feel that
they know how these things have to work. My concern is that this is coming
at the expense of accessibility-not the accessibility for handicapped
people-but accessibility for small companies and people with limited
resources, if not handicapped.

Layman: In a lot of programming languages...let's say we have a purchase
order and you're going to ship it someplace, you're going to bill it
someplace. You're probably going to have a member variable that is called
"ship to" and another called "bill to," and they're going to be references
to some sort of an addressing structure-maybe you're programming in C+ or
Java or C# or something like that.

Then, you have to ask the question: what happens if you're shipping the
thing to the same place you're billing it to? That happens a lot. What do
you do when you go to put that purchase-order information inside of a SOAP
message? Well, you have to make some decisions, and you have to decide these
when you write the specification. Do you, in effect, tell people, well,
don't do that? Or do you put two copies of the address out, in which case,
it says the same street address and everything, but you've lost a little bit
of information such as it's the same actual object? Or do you have a way
that you can have two pointers to the same object?

Winer: But we've resolved that one, haven't we?

Layman: Yes, I'm just bringing this up as an example of the sort of thing
that you end up discussing here, and every one of those choices raises a
certain level of complexity on the implementer that's higher than the
earlier choice.

Winer: But what's coming next? That's what I'm concerned about? We might as
well get some work done here. [laughter] That's the way I see it. Let's say
we dealt with that-we have the ability to send-what are they called, "Id.
Refs"-or-I'm not sure exactly what they're called.

Layman: The spec calls them "Multi-Reference Values."

Winer: There you go-"Multi-Reference Values"-what else are we going to have
to deal with?

Layman: There are only a handful of additional things that I see being
debated that people don't seem to have settled on. One is that there seems
to be still some discussion over the proper use of name spaces under some
circumstances. There's a little bit of discussion about what goes into the
SOAPAction field. We seem to have very few full implementations of the
portion of the spec dealing with arrays. And the SOAP root attribute does
not seem to be generally implemented. But I think everybody is building up
on those things.

Winer: But we're close then, wouldn't you say?

Layman: Yeah!

Winer: Oh, okay. Cool.

Layman: I mean, as far as the base SOAP...

Winer: I was talking with Eric Kidd this morning, who is the implementer of
the C and C++ version of XML-RPC. He was signed on to doing a SOAP
implementation, and after seeing the report from the last conference call,
he basically flamed the list and said, I'm out of here, this thing is a
never-ending, blah, blah, blah. And this morning, I told him, no, Eric, I
don't think that's what's going on here; I think that we've managed to put a
pretty reasonable lid on [here]. You're not going to be implementing this
for the next five years.

That's what a smaller developer is looking for, some kind of assurance that
it's not a game that we can't win. That's the concern-not saying that it's
any specific company-but the big-company approach to things is that, well,
we could always re-engineer this next year, and that's always an option
because we know we're going to be around. The little-company viewpoint is
not like that at all-we don't know that we're going to be around next year.

Layman: I'd rather have our programmers doing more interesting stuff a year
from now.

Winer: Right on.

Gillmor: Against all attempts to keep this from being a total "love fest,"
it appears to be one. [laughter] I'd like to go "around the table" just
briefly for some summary comments from everybody.

Kulchenko: I'd like to talk a little bit about WSDL support, and I agree
with Noah that, in some cases, it is not a requirement. In some cases, it's
more important for something that's based on WSDL, based on a WSDL
description-you can queue in the really small application that will deal
with this particular service and nothing else. At the same time, I can see
other implementations-for example, I am working on one where you can access
the remote database through the same interface and you can get the database
on the wire.

And either on the client side or on the server side-I don't care how they
represent it on the wire-I just want to send it from that side and I'll get
it here and they'll be properly deserialized into an array of structures.
I'm not dealing with the objects here. But I don't care about the
description; I just want to get my data here. And probably there will be the
question of how we can deal with the other implementation that wants to
access the same server.

But, at the same time, I see the power of SOAP also, not only from accessing
the multiple clients for this particular server, but also implementing the
things that were impossible before that. For example, I'm working on a
database interface that you can access remotely without worrying what is on
that side, and I think that SOAP is a perfect instrument for doing it.
Unfortunately, yes, I don't have enough resources to implement all that WSDL
requires, and I'm working on the simple implementation. And the next thing,
I want to add the complex types. But, at the same time, I'm watching the
discussion on the SOAPBuilders list on WSDL, and the implementations that
use it [WSDL] move really quick in that direction. I understand all the
difficulties that I'm facing in this field, and I love to do it as much as
possible. At this point, I want to focus on implementing-not without WSDL,
but using only necessary information from WSDL to make a call. 

Layman: While WSDL is not going to be required for all applications, it's
going to be a neutral format for unambiguously defining the messages coming
in and out-and it really helps as a mechanism to define a service using
WSDL. It can be mechanically generated. It certainly supports tools. This
isn't to say that everybody has to start a project by designing a WSDL file,
but I would expect that over time, as services get to be very popular, that
it would become a routine thing to do.

Winer: We can't generate it mechanically, Andrew. There is no
mechanism-there is no way in a dynamic language that you can generate an IDL
automatically. We've been all the way through that one.

Kulchenko: While that's true-and I have the same situation in Perl-at the
same time, we have the POD (plain old documentation) mechanism that's
similar to JavaDoc, for example. So, I can generate a description from
additional information; I can't generate a WSDL from a method signature...

Winer: But that additional information should be your IDL, then. 

Kulchenko: Right, kind of, mm-hmm.

Winer: WSDL is quite complicated. [laughter]

Kulchenko: That's true.

Mendelsohn: What really matters is that our customers are looking for these
technologies to enable a new class of Web services applications. The key is
that we have to give them a core technology that's robust and that
interoperates. As Dave has very eloquently stated, part of getting that
interop right is making sure that the barriers to entry are low enough that
an awful lot of people out there will get this stuff right. And we're
actually in the happy situation right now where at least two relatively new
and exciting developments have happened within the last month or so.

One is the interop work that's being driven by the programmers, which has
made tremendous strides toward getting SOAP as we know it to really work
properly-that's making excellent progress. And the other is the work that's
been alluded to, starting with the W3C coordinating to build on top of XMLP
and SOAP the other services that are needed, typically by more elaborate
industrial-strength applications that require security and a variety of
richer services to layer on top. We've got a ways to go down this path, but
there are some pretty exciting things happening right now.

Daniels: I want to echo where Noah was going, which is that this
community-building grassroots effort is doing an incredible amount to
provide information to the people who are taking this protocol forward into
what we hope is going to be something that is not only easy to deal with and
has the same kind of extensible, scalable barrier to entry as SOAP does-in
fact, it might very well be SOAP, we don't know that yet-but deals with all
these kind of fuzzier issues that we've been coming up with on the
SOAPBuilders list as well. This is just a really exciting time.

I'm going to be very interested to see what happens when some of the more
esoteric portions of the spec that have some valid-use cases start to get
the same kind of attention in the interop world once we've dealt with the
basic stuff. What are we going to do about intermediaries, which is a big
part of the SOAP spec? It's something that's been discussed a bunch, but I
don't think anybody's really implementing stuff with that yet, and that will
be a very interesting challenge when we get to that point. But the fact that
there is such a vibrant community out there that's doing this stuff-I don't
want to get too much into the "love fest" portion of things, but I'm psyched
about it-I think it's great.

Gillmor: Jake, do you agree with that?

Savin: Which part? [laughter]

Gillmor: The part about being excited about the opportunity to get into some
of the more esoteric areas.

Savin: From my point of view, we're already building apps that use this
stuff. Our content-management system, Manila, has a SOAP interface that's
usable right now and, in fact, Simon Fell is posting his test results using
it. That's what's exciting to me. I don't have a particular interest in, for
example, how intermediaries will work in our implementation. But I can
imagine that, in the future, there might be something cool that we'd want to
interoperate with that used that feature, in which case it would be
worthwhile for us to at least investigate whether that's worth our
engineering effort. But, at this time, I don't see that as being
particularly exciting.

Fell: I'm not entirely sure I agree with Andrew's assessment of how close to
the finish we are. I think it would be an interesting exercise to see how
far everybody thinks we are off from a reasonable number of implementations
that fully implement, say, Section Five. I think there's still a ways to go,
but we're making really good progress.

Gillmor: Dave, this started with you in a way, so let's have you wrap it up.

Winer: I'm with Jake a hundred percent-you totally got it right. My
priorities were interop and apps, and I feel that we've got an incredible
leg up in the interop department-I'm very confident. I want to see
development platforms be open, have developers have choice so that they're
not locked into Java or .Net or whatever-I want it to be inclusive. I'm very
optimistic about this. There's been a big change in the way we develop
software, and I think it's about to go really mainstream to the next level.

Weerawarana: Steve, you asked earlier whether there would be more BDG-like
efforts as different things in this framework come along. As Andrew and Dave
have sorted out, BDG for SOAP is coming fairly close to what SOAP itself
is-there are a few things that are not in that direction, and maybe those
could be classified as esoteric features that could have been added to SOAP
later on rather than starting at the bottom. So, as such, I would like to
see an effort placed as we define the standard set, that they are delivering
incrementally in some form so we address the minimum required functionality
and we evolve them over time, so that you effectively start at a BDG level.

SOAP is an example where-Dave and Andrew would find different cut-offs-there
are a few, not many at this point, a few things that SOAP has that are not
in the BDG level. But if we try to come up starting at the bottom, we
address the total minimum requirement and then keep going back upward as
functionality gets required, then we have a better chance at interop because
we address only those absolute minimum requirements. And WSDL-at some point,
I would like to talk to Dave as to how he would do WSDL so it doesn't have
that problem, because he finds it too complicated...

Winer: I have a low-barrier entry myself when it comes to complications.
[laughter]

Layman: With SOAP here, the proper way to close on this is to say that we've
got more than thirty different companies who have actually accomplished
something now that programmers have not ever accomplished in the past. There
have been a lot of attempts in the past to build something that allowed
programs to communicate without being locked into a specific platform. And,
in one way or another, none of them has ever succeeded to the degree that
we've now got thirty companies succeeding-some big and some fairly amateur-a
whole huge range here is actually doing it.

Winer: Yup. And, Andrew, Microsoft deserves a lot of the credit for that. I
don't even know that that's well enough appreciated, but it took a lot of
courage to work with the rest of us to get this thing going.

Layman: Well, courage to work with you, but the rest was a pleasure.
[laughter]


----
Adam@KnowNow.Com

For Ian Bell: http://www.bushorchimp.com/   :)