Level: Introductory Robert McMillan (bob@filbert.net), Freelance Writer
17 Jun 2003 Sam Ruby, a member of the IBM Emerging Technologies Group, has become a key part of several Web services-related open source projects over the last three years, including Tomcat and the IBM SOAP stack. He's still contributing both his code and his insight to the community. He spoke with Bob McMillan on a number of topics, including the appeal of open source, the future of Web services, and the power of Web logs.
Sam Ruby is an addict. A 21-year IBM veteran, he got hooked on open
source three years ago, while working on his day job, which, at the time,
was integrating PHP with the Java platform. Ruby hadn't really been involved in open
source development before, but he jumped right in, working on his
Java-PHP integration work and submitting a number of fixes along the
way. Before he knew it, the PHP team had given him commit access to
its source code tree. He was floored. Soon, his work had him
submitting patches to Apache's Tomcat project, and again, Ruby was blown
away by his reception. It was easy for him to get access to source code
and fixes from fellow developers, and before long he had Tomcat commit
access as well. "That's not exactly the type of cooperation you see
between competing projects within IBM," he says. "And that quickly
became addictive."
Ruby has been a significant contributor to the IBM SOAP stack, and is
known for his thoughtful and precise thinking on everything from Web
services and open source to blogging. developerWorks contributor Robert
McMillan interviewed Sam by telephone recently to ask about his current
work in the IBM Emerging Technology Group, and to get his thoughts on Web
services.
developerWorks: How did you end up working on Web services?
Sam Ruby: I'd pretty much been a developer my entire career. I write code. I
liked writing code. And as I progressed at IBM, what they say as you get
promoted is, "You can't write code anymore." Well, I refused to do that. I
tried being in an architecture role for a while. These are natural
places for you to move up to, but what I've refused to do is move in any
direction that got me to move from actually writing code.
After that, I moved into Emerging Technology. The emerging technology at
the time was Web services. So I dove into that. I helped contribute
significantly to the what was originally the IBM SOAP stack, which got
contributed to Apache. IBM's Soap4J became Apache SOAP. It's since been
rewritten as Apache Axis. [See Resources for links to this and other projects and topics referenced in this article.]
developerWorks: How did you convince IBM to contribute this code to Apache?
Ruby: This was in the early days of SOAP. We were very much scared that
Microsoft would co-opt the standard -- embrace and extend and all the
normal things. We'd been burned an awful lot with IBM and Microsoft
competitions, with OS/2 and the like. So if we simply said, "OK, there's
a standard out there called SOAP -- Microsoft has their implementation; we
have our implementation," guess who people are going to test
interoperability with? And then they'll say, "Well, if it doesn't work
with ours, maybe if we made ours a little more like Microsoft's, that
would make life better." That's not the position we wanted to be in.
So what we decided to do was, instead, open source it, and say, "Here is
a ubiquitous, in essence de facto reference implementation." It's not
anointed as a reference implementation, but it achieves the same
purpose. It's our way of increasing the probability that this
implementation of a standard is adopted. Our version was absolutely the
most compliant with the SOAP specifications at the time, and got a lot
of people noticing it.
developerWorks: There are so many emerging Web services standards, and groups that
these standards can go through, and then there's this de facto open
source way of developing standards. It seems very easy to get confused
about what standards are emerging where, and what standards efforts are
important to watch. Does this all make sense to you?
Ruby: I think the short answer to that is that I don't think anybody
knows which way it's going. What we've got is lots of people with
competing interests. No one person knows exactly the right answer for
the future. But instead of going like we have done in the past and say,
"Let's build this humongous standard like CORBA," and you've got to
agree to every single aspect of it in order to have an implementation....
What we're doing collectively -- not something that IBM's doing or
Microsoft's doing, but what the whole industry is doing -- is defining
this, in steps. And what you get is a bit of confusion. You get a bunch
of people with opposing standards -- some of which live, some of which die.
In the process, the industry -- I'm not saying IBM or anyone in specifics
-- is trying lots of venues, whether it's W3C or OASIS or just simply
publishing a URL out in the Web and not going through any standards body.
There have been a number of noticeable failures. Microsoft originally
put out SOAP With Attachments, then later said that was a failure, and
then they put out this other thing called DIME, and now they're saying
that was a failure, and the best thing to do is go back with SOAP With
Attachments when you've got to, but actually put the data in the XML
infoset when you can.
So what you're seeing there are people trying this, seeing if it works,
seeing if other people rally around it. We don't know yet which of these
standards will be used five years from now. However, the basics, like
SOAP and WSDL, seem to have gotten a lot of traction and don't seem to be
going away.
developerWorks: In the open source world -- as opposed to the world of consortiums
-- it seems that the role of standards often takes a backseat to working
implementations.
Ruby: I like standards, but I actually personally treat the word
standard a little differently. I take the dictionary definition versus
the definition you find in various consortiums. If you look at the
dictionary definition, it basically says, "Something that everybody
agrees upon." When I say a meter, that is a term people agree upon. It's
not something I have any say on. It actually is an international
standard, which is kind of cool. The fact that we all agree that this is
a meter, or this is a yard, or whatever you want to pick: that's a
standard. By that definition, PowerPoint is a standard. Not in the same
sense that people talk about standards bodies and the like, but, by and
large, if you send something, PowerPoint is sort of the way you send it.
Is it a standard I like? Not particularly. However, it is something that
is known. When I say "PowerPoint," that conjures up an image in your mind
that is exactly the image that I'm trying to express.
developerWorks: Just to get back to the evolution of SOAP, has there been anything
about that that has surprised you?
Ruby: By and large, SOAP itself hasn't evolved. When I got involved,
SOAP 1.1 was just getting proposed. SOAP 1.2 has not actually been
proposed yet. It's still going through the efforts and machinations of
the standards organizations. In essence, what has evolved is the whole
stack associated with SOAP. Originally, I was a skeptic on much of the
higher-level stuff. In particular, at first I thought WSDL was overkill.
developerWorks: What changed your mind on that?
Ruby: What I worked on to help make these things a standard, is I
actually hosted the first SOAP builders interop meeting, and then went
to pretty much all of the meetings since then. At them, we send a
message to the other person. Does the other person receive that message,
and then, when they send a reply, do we actually understand the reply
that came back?
Most of the problems were not what I expected; the problems were in the
naming of parameters. It actually is a lot easier for an implementation
to take a definition that said, "This is what a correctly formed
definition would look like," and then from that definition generate
correct code. So it's first-hand observation of the problems that we see if
you don't try to be a little more formal in your definitions.
developerWorks: You seem to occupy an interesting position when it comers to REST.
When you've talked about it in the past, you've said that you personally
advocate additional constraints to Web services. What did you mean by this?
Ruby: I was responding to a specific individual who's been a long-time
critic of Web services, who argues strongly that what you need are the
constraints that REST provides. His name is Mark Baker. What he
advocates strongly is the architectural constraints that you get with
HTTP -- in other words, GET and POST and just a minimal number of verbs.
And there is some argument there that has some validity to it.
I think they [REST and Web services] actually can play nice together.
You can actually say, "I will use REST to describe how objects are
accessed," and then use SOAP to talk about how those objects are
represented.
One interesting thing is that REST stands for Representational State
Transfer, and one thing that REST does not talk at all about is how you
actually represent the state, despite the fact that that's the name. Conversely, Simple Object Access Protocol (SOAP) does not talk about any
way in which you access objects; it just talks about how you represent
state and do transfer.
So, you have two groups of people not talking to one another, but talking
past each other. If you actually combine the best ideas of both, you end
up with an extensible and modular and loosely coupled system.
developerWorks: You seem to be the person who's right in the middle of this
argument. Do you feel that your understanding of all of this is unique?
Ruby: Unfortunately, it's a little more unique than I would like. I wish
a lot more people would have that same common understanding. Most people
sort of tune off, or immediately jump to one of the two extremes, as it
were. They simply stop listening.
developerWorks: Why do you think that is? Is it simpler to put one thing into one
paradigm?
Ruby: I'm not sure I should speculate. I think a lot of it is that
people don't spend the time and actually look at some of the issues.
Everybody's got only a finite amount of time in which they can learn
things, and this may not be the area that excites them much. So they
look at which way people are going, and simply assume that everybody
else is weird. And we all do that to some extent. This happens to be an
area that I'm looking at, but I'm sure there are other areas where I
don't do proper research.
developerWorks: Do you think that this will change as people start to get more
serious about using Web services, and begin to spend the hands-on time
with these technologies?
Ruby: I think, independent of the core battles that we're seeing, people
are getting a greater appreciation of XML as a way of representing data
to send back and forth. XML has been a buzzword and technology that
people have been using for many, many years -- even longer than Web
services. That is the first rung, as it were.
developerWorks: What do you think is most important for Web services to evolve? Are
there specific standards that are needed?
Ruby: Well, there's no question that standards have outpaced
implementations. There are too many standards out there. There will
still be more standards created. But I don't think the answer is more
standards.
In terms of tooling, more tooling that can handle XML easier and better
is where I think more work needs to be done: tools that make XML
intuitive and obvious, perhaps to the point where it is transparent.
developerWorks: You said that more standards are not what is required. Do you think that
the proliferation of standards may be confusing people about where to go?
Ruby: The proliferation of standards may be a bit confusing. What we're
finding, though, is that many of the higher-level standards are aiming at
smaller markets, where there does need to be an agreement, and it needs
to be a public agreement, but it isn't something that will be
universally adopted. We're hoping SOAP will be universally adopted, and
as you move up the stack from UDDI and BPEL, the business process stuff,
you'll find there are specific niches where this makes a lot of sense,
and in those niches, that's exactly the right answer. And there may be
places where people say, "I don't need that." And that's OK too.
developerWorks: I wanted to ask you, what software are you working on right now?
Ruby: I'm not doing as much Web services right now. Mostly what I'm
playing with is my Web log. I'm playing with it and trying to figure out
how to do additional things. About a month or two ago, I rewrote the
whole thing into Python.
developerWorks: What applications of Web logs have caught your attention?
Ruby: Web logs are extremely intriguing to me. When I said that I found
open source addictive, I was talking about the collaboration that I
found, the fact that I could post a question and there would be answers
within minutes, and that was without me having a prior contractual
relationship with somebody. It was just that somebody was interested in
the same thing I was, and we were just trying to help out each other.
I'm finding the same addictive nature in Web logs. I just simply post
something out there and say, "This caught my interest," and somebody
else says, "Well, that caught my interest too," and they either comment
on my Web log, or they comment on their Web log. And people follow the
links.
In open source, much of the collaboration is structured around a very
tangible thing: a piece of code. This is not as structured. I've thought
about it a lot, and I've not yet figured out what the magic is that
makes it all work. In theory, what you do in Web logs, you could do in a
newsgroups.
developerWorks: But in Web logs, the topic is connected to you, rather than
something else.
Ruby: But on Web logs, I don't have to worry about scope. It's just something
that caught my interest. One of the essays that's on the left-hand side
of my Web log is called "Manufacturing Serendipity." It talks about
that phenomenon. For example, one time I happened to be in Boston, and I
noticed it was snowing outside. It was late in the year, so I commented
on that, and it was read by Miguel de Icaza, who at the time I knew of,
but not terribly well. Based on this, he e-mailed me while I was in a
meeting and said, "Oh, you're in Boston. Perhaps we could have dinner."
These types of fortuitous things that have happened have just exploded
for me since I created the Web log. You know a lot more about me before
you even called me because you were able to read a number of things on
the Web log. Right now this is an interview, but this interview is made
easier because of that extra thing I've done with my Web log. I'm not
sure what the tangible benefits are, but I have to believe that there
are ways we could integrate this into things like business processes or
things that have real value to customers.
I mean, faxes changed the way businesses operate. Telephones changed the
way businesses operate. I've seen in the last few years that instant
messages have changed the way people operate. If you look in meetings,
people get together face to face in meetings. While they're in the
meeting, they may be instant messaging people outside the meeting; they
may be instant messaging each other. So what you'll find is there's one
guy talking, and other people may not want to interrupt him, or they'll
have something that the thing that they're hearing has triggered and
they actually do need to take care of.
developerWorks: So what applications do you see for IBM's products?
Ruby: At the group I'm in within Emerging Technology, our job is to
figure out the answer to the question you're asking, and the only honest answer I
can give you is: I don't know yet. I do believe that a number of IBM
products will need to change. I do believe that there may be new
products that come out based on this.
Resources
About the author  | | |
Robert McMillan is a freelance writer based in San Francisco. He has contributed to Wired News, New Scientist, Linux Magazine, and Network World, and was the founding editor-in-chief of LinuxWorld.com. Contact Robert at bob@filbert.net. |
Rate this page
| 
