Mark Baker, Tech Curmudgeon

2002-09-05T11:51:00.000-04:00

I've relocated this blog to my own server. More control, RSS. Mmmm...

2002-09-03T15:41:00.000-04:00

For those who want to understand the issue Mark has with SOAP, he objects to the string "doGoogleSearch" in this example. FWIW, I don't see how this is any different, architecturally, than hidden controls in HTML.

It isn't any different than hidden controls, but I wouldn't use hidden controls either. I'd just POST the data "q=foo" to whatever URI the POST form told me too. No need to understand what "doGoogleSearch" means, because the context in which the POST operation is to be interpreted by the server, is provided entirely by the URI to which I'm POSTing.

2002-09-03T11:05:00.000-04:00

Sam asks;

Now it turns out that the Google API has a limit of a 1,000 queries per day. This means that the 1,001st query will not have the same result as the 1,000th query. The query itself has a (GASP!) side effect. It is most decidedly not idempotent. So what do you do? Call back the Hobbits and recode to use POST, or do you make the pragmatic decision to slightly bend the rules a bit?

Well, first of all, that part of 2116 that you referred to earlier in your blog (presumably you meant 9.1.1 not 9.1.2) says "SHOULD NOT", not "MUST NOT". The reason this is so, is because unsafe GETs won't break the Web; web page counters demonstrated that. What will break the Web is if people who click on a URI get blamed for causing the side-effect, as 9.1.1 points out when it says "The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.". Also, it's not a fundamental axiom, in the same way that a uniform interface is - it's derivate (though lots of other important principles are too).

But with that said, your example is an excellent one, because clearly a counter such as the one you describe would be "blaming" the user for bumping it up by one. So IMO, no, this service should not use GET, at least for those queries. It should be bootstrapped with GET though, so that you GET the HTML form, but the form results should be POSTed back.

Also, in case you were going to suggest that this somehow makes the Google API "ok" because it uses POST, it should be noted that it doesn't use POST, it tunnels through it. A client needs to know more than just the URI, the form structure, and the POST method. It needs to know what the string "doGoogleSearch" means.

And as for RSS, I welcome any suggestions for a blogging tool/service that provides free RSS feeds and lets me edit from a browser (something that Dave Winer seems dead set against providing - or at least he was in the past).

2002-09-02T22:48:00.000-04:00

Sometimes I see signs of smart folks figuring out how to do Web services properly, and I feel a glimmer of hope that the industry may not be wasting hundreds of millions of dollars with SOAP and WSDL. Then I see stuff like this, and I realize, nope, it's going to hell - specifically this part;

Bergandi: With a wizard-based environment within the SOAPswitch. The SOAPswitch itself has self-discovery capabilities. It has the ability to, in the example I gave you, inquire into the metadata of what the Siebel system looks like; discover what business objects are available and what methods are available against those business objects; and then, based upon that, in a very, very simple way, generate all the SOAP that's required for communication.

Internet-scale distributed computing just ain't that easy, folks, sorry.

2002-08-29T11:43:00.000-04:00

According to Jon Udell, extremism is dead. How silly! Sometimes, whether you know it or not, the truth is not shades of grey that requires finding a middle ground, it's boolean. Take REST vs. Web services, for example. REST is a simply a superior architecture by all important measures, than what people know to be Web services (the definition's so fuzzy, it's hard to pin down a specific one to argue against). End of story. And not just in the "oh yah, I guess I'd prefer REST" sense, but in the "Web services will fail to achieve their goal, and ultimately be discarded" sense. Just because someone hasn't done the homework necessary to properly evaluate REST, does not change this.

Extremism will live on, so long as there is right and wrong.

In the words of Henry Hazlitt (though the snippet starts slightly out-of-context);

"We Haven't Been Good Enough"

I am going to give what is no doubt a terribly oversimplified answer to that question. In the first place, we are almost hopelessly outnumbered. Our voices are simply drowned out in the general tumult and clamor. But there is another reason. And this is hard to say, above all to an audience of this sort, which contains some of the most brilliant writers and minds in the fields of economics, of jurisprudence, of politics, not only of this age but of any age. But the hard thing must be said that, collectively, we just haven't been good enough. We haven't convinced the majority. Is this because the majority just won't listen to reason? I am enough of an optimist, and I have enough faith in human nature, to believe that people will listen to reason if they are convinced that it is reason. Somewhere, there must be some missing argument, something that we haven't seen clearly enough, or said clearly enough, or, perhaps, just not said often enough.

A minority is in a very awkward position. The individuals in it can't afford to be just as good as the individuals in the majority. If they hope to convert the majority they have to be much better; and the smaller the minority, the better they have to be. They have to think better. They have to know more. They have to write better. They have to have better controversial manners. Above all, they have to have far more courage. And they have to be infinitely patient.

(thanks to Roger Costello for the pointer)

2002-08-14T16:41:00.000-04:00

Just reading through a relatively recent update to the Grid's Grid Service Specification. In there, they actually provide some (extended) WSDL that is used to access all Grid services; a generic interface, who would've thunk it? Some of the relevant text from that part of the spec includes;

In order to support discovery, introspection, and monitoring of Grid service instances, we introduce the concept of service data, which refers to descriptive information about a Grid service instance, including both meta-data (information about the service instance) and state data (runtime properties of the service instance). -- from section 4.4

So it's good to see them getting this important aspect right (at least to an extent - it's still much less useful than GET/PUT/POST/etc..), but it would be nice to see them embrace the Web rather than getting distracted with what people know to be Web services, since the Web already does most of the things they're trying to do, and many beneficial things they haven't even thought about. I attended a BOF of theirs at WWW 2002, and they had absolutely no interest in using URIs (though I see they're using them as Grid Service Handlers), and thought that protocol independance was a feature, not a bug. They really need a protocol guru on the team; without one, and some major changes, the Grid isn't going anywhere.

2002-08-14T11:30:00.000-04:00

I just made an interesting observation regarding all these orchestration, workflow, choreography Web services specs recently released. Let's see who in the Web Services Architecture WG picks up on this ...

(if anybody knows why Blogger's messing up the alignment below, please let me know)

2002-08-08T14:02:00.000-04:00

Clemens writes some more about HTTP, transactions, reliability, despite his publication deadline. Go, Clemens!

FWIW, I don't disagree that this is a commonly held view, but in my view, it's entirely incorrect. HTTP is not a panacea, but it's also not just a web page retrieval protocol. Some point-by-point responses;

I said that HTTP, without resorting to things like tunneling or callbacks, doesn't support any flavor of transactional behavior[...]. This is incorrect. HTTP supports what is sometimes referred to as a "state alignment transaction". That is, any party in the transaction can synchronize with the state of the other party using HTTP GET. State alignment is a form of transactional style that fits very well with the Internet/Web. Obviously, just using GET isn't sufficient for all transactional needs, even with a state alignment approach, so more work remains to be done. But to suggest that HTTP doesn't and can't do transactions is false.

For additional cases where HTTP doesn't really work (P2P in general and even non-transactional, long running operations)[...]. I use HTTP for P2P on a daily basis. My company's HTTP routing platform is premised on the fact that HTTP is suitable for P2P, and we've built some really cool, useful, and scalable stuff with it. Ask KnowNow about this too. WRT long running operations, see above re state alignment; you just have to look at the problem differently.

I can't say that I understand what you mean by the TIP/BEEP/HTTP pictures, but the prose preceding it suggests that you didn't understand my point that you quoted. I see reliability as an application layer issue, not a transport one. See what Jim Waldo has to say about the topic (chapter 5, if you don't have time to read the whole thing).

2002-08-06T13:17:00.000-04:00

Clemens responds. It's a bit long to respond to in detail, but I will point out another big misconception about HTTP; that it is unreliable. It is as reliable as any other workable protocol can be without being brittle, because it attempts to expose what needs exposing, and hides what can reasonably be hidden. Going back to those fallacies, number one is "the network is reliable". This should hopefully not come as a surprise to anybody, but what might is a corrolary of that fallacy (that I just devised 8-); Not only is the network not reliable, no layer that attempts to abstract that network can be reliable. "Reliability", in the context of Internet-scale systems, is an aspect of the coordination semantics of the over-the-wire agreement, not of the quality of service of the transport of the message.

2002-07-31T09:21:00.000-04:00

My most recent O'Reilly blog, "Web Services and the Eight Fallacies".

2002-07-31T07:37:00.000-04:00

The "theory monster" rears its ugly head again. Clemens Vasters writes "Hence, the "I love HTTP" discussion (aka REST) is solely academic and of very little relevance for complex real-world designs now and even less moving forward -- methinks.". REST is the furthest thing from theory in existence; it is 100% practice. It is what you get when you closely study how the Web works today. In contrast, "Web services architecture" is almost entirely theory in the context in which it's being used (the Internet). It, and its implicit resemblance to the OMA, has never been deployed at a scale even approaching the Web. Perhaps it's worth repeating; The Web is a giant leap forward in distributed computing architectures. Ignore it at your peril.

For many years, people have talked about how normal ACID/2PC transaction semantics are unsuitable for use on the Internet. That is still the case. We need to rethink what a transaction is on the Web, and I can guarantee you that when we do, it will be implementable as an HTTP extension.

2002-07-30T10:29:00.000-04:00

Sam Ruby responds, "Note: I've said nothing about behavior... only about syntax. Where is the disconnect?". As long as no behaviour is requested, then there is absolutely no disconnect. Excellent!

I think we still have some terminology issues though. For example you said that WSDL is for specifying protocols . I don't consider specifying the structure of expected content as a protocol. Protocols define contracts, and in this case, the contract is that if I POST something that you consider invalid - whether or not I've seen your WSDL (heh, that sounds rude 8-) - then you'll tell me so with a 4xx response (e.g. 400 or 415). Does that make sense? So this boils WSDL down to how I always saw it being used in the long run; as HTML forms are used ... that is, until RDF absorbs it. 8-)

2002-07-29T14:50:00.000-04:00

Sam and I are still disconnected, but we appear to have narrowed it done to this one key point. Must .. find .. way .... to explain.

Time for an example.


POST /some-uri/ HTTP/1.1

Host: example.org

Content-Type: text/plain

[blank line]

795

This is a client POSTing the data "795" to http://example.org/some-uri/. I consider this more hormone-like, because what the code bound to that URI does with the number "795", is completely up to it. And without additional information, the sender of that HTTP message has no idea what to expect will happen when he does. How this works in HTTP, is that the client (in HTML's case, a user) forms an expectation by believing the assertions in the HTML that they previously got, that if you submit some text, we'll send it to an LED flasher in our office (or will dial a phone number, or hunt down and kill the person with that SIN, or whatever). So different behaviours are negotiated out of band, not requested in band.

That should hopefully highlight the difference. Does it? It wasn't intended to compare the approaches. I'll leave that as an exercise to the reader. 8-)

2002-07-28T21:47:00.000-04:00

Sam Ruby, "I still do, however, see value in perfectly clear protocol specifications, a role that WSDL fulfills".

Here's how I see it. HTTP is the protocol, and no other protocols are required in order to get stuff done. I agree that WSDL does define protocols - application protocols in fact - but why is it required? I'm not sure how best to describe the difference, but Sam's own neurotransmitters essay might be a start; "In the second mechanism, the receiver determines the action to be taken. The request matches a receptacle on the membrane and the cell uses this information to trigger biological processes.". That is, the the "server" determines what is done, not the client. Using WSDL as a protocol definition mechanism (as practically all Web services use it), the client is asking that some action be taken by invoking some operation on the server. This is not the hormone/membrane, it's the virus. For the hormone approach, the protocol data unit is simply "handed off" to the recipient without any specific request for action other than "hand off". This is what POST means.

2002-07-24T11:42:00.000-04:00

I'm a few days late, but Sam Ruby posted his excellent REST+SOAP essay last week. I was surprised to see it not get more fanfare. I commented to Sam that I was concerned about this bit;

Now add high level methods which take care of all composite

create, update, and delete operations.

Sam suggested to me off-line that he was thinking about it in terms of just passing data over a wall/membrane, to which I responded that this is exactly how POST works; that the operation that occurs is determined solely by the server. So we may be in synch, but given previous things I've heard him say, and his work on SOAP and WSDL, I wonder if we really are. But here's hoping!!

2002-07-15T16:51:00.000-04:00

Thanks for the heads up Sam, it looks like a 404. Had to republish the Blogger archives. Bizarre, but you get what you pay for.

2002-07-15T15:30:00.000-04:00

An interesting discussion on xml-dist-app about implicit versus explicit use of the Web Method Specification Feature of SOAP 1.2. I guess I just have a hard time understanding why you'd want to hide the method, either by defining a default, or deriving it from the MEP in use. I mean, how else do you accomplish something without knowing what method you're invoking?

2002-07-12T14:25:00.000-04:00

I'm glad Sam Ruby is contributing to the SOAP/REST discussion. As a leader in the Web services space, his word goes a long way. I'm looking forward to reading his article.

As for "bad advocacy", I don't believe that I'm an advocate for REST, at least in the REST/SOAP discussions. I see myself as more of a soothsayer, trying to warn people that the current approach to Web services cannot do what people hope it can do; namely, work on the Internet. But my hope is that the industry understands this soon, because I'd prefer to see it put resources into more fruitful endeavours rather than spending them repeating past mistakes. But if they don't, then they'll just have to learn the hard way.

Curmudgeonly yours. 8-)

2002-07-08T22:02:00.000-04:00

O'Reilly invited me to join their list of weblogs, so I've done that. I'll use this Blogger one for day-to-day snippets, and the O'Reilly one for more article-style blogging.

2002-06-30T22:31:00.000-04:00

Spent some time thinking about how the Apache Axis project could support the SOAP 1.2 "Web Method Feature", the major architectural difference between SOAP 0.9/1.0/1.1, and SOAP 1.2. I'm not sure that many Web services folks understand the implications of this yet, but it's clear to me that it dispells the notion of SOAP as a layer, which is bound to mess with some software. Layers hide other layers beneath them, but what the Web Method Feature says is that a developer must be aware of which HTTP method they're using if they're using SOAP bound to HTTP. Let's hope they all see it that way too. 8-)

The topic is being discussed on axis-dev now.

2002-06-28T17:40:00.000-04:00

The big news from yesterday, WS-Security is submitted to OASIS. For those who don't think Web services have much of a future, this is really good news for the Web and the W3C, as it removes influence from the Web Services Activity, specifically the Web Services Architecture Working Group (of which I'm a member, but that I'd be happy to see go away). Of course, many Web Services proponents are quite concerned, as it puts more control in the hands of MS and IBM.

2002-06-27T21:33:00.000-04:00

Welcome to my first blog! Here's why I'm calling it "Mark Baker, Tech Curmudgeon".

I believe that distributed systems that work at Internet scale are extraordinarily difficult to build; much more difficult than is commonly believed, even amoungst those who know that it's difficult. I believe that there are very few people on this planet who have the expertise necessary to architect such a system. Of course, the Web isn't the only example, but it's a great one because of what it can do (as compared to, say, email or FTP, which are limited in their capabilities).

So when the "next big thing" comes along, and it's not developed by people who I know get how difficult it is, I'm naturally skeptical.

I'll try not to offend anybody with my posts, but since my job is to be critical of others' work, and people invariably put a lot of themselves into their work, this is going to be hard to achieve. But please know that it is not my intent to criticize any person or group of people, only to critique technology.