Subbu Allamaraju makes an excellent point: there is no such thing as SOAP over JMS. It simply doesn’t make sense.

JMS is a set of APIs. It is not a transport or a protocol. You can implement JMS on any kind of transport; I could use messenger pigeons or smoke signals as the transport for a JMS system.

So let’s stop saying SOAP over JMS. It’s very misleading - the majority of people, particularly those a vendor has spoken to, assume it’s possible to have something that listens to any JMS system and picks messages off the wire. I’ve heard smart people ask for “a generic monitoring system for SOAP messages over JMS”. There’s no standard wire, so you really can’t do that.

JMS specifies the two ends (publishing and subscribing APIs), but not the middle. A transport specifies the middle. That’s what you need to send SOAP over.

Dale Georg makes an interesting point:

From what I can tell, while companies are expecting vendors to have a “roadmap� answer with respect to these [WS-*] specs, when it comes time to actually implement solutions, most aren’t using anything beyond basic SOAP over HTTP with maybe some WS-Security or UDDI thrown in. My feeling is that all these extraneous specs are either going to fall by the wayside when nobody picks them up and finds a real-world use for them, or will gradually find their way into general usage both as they mature and as Web Services projects advance to the stage where the solutions they offer are required (much as is happening now with WS-Security and UDDI).

I can buy that; useful specs will get used and prosper while useless specs will whither and die. Fair enough. Here’s the problem though: SOAP itself faces an uphill battle in many places. I came from a vendor that had to produce these “roadmaps”; now I’m on the other side, considering SOAP for use in significant projects. Let me tell you, it faces challenges. Performance and interoperability (between different toolkits) are big issues. Simplicity is a huge hurdle; it’s hard to argue that REST is not more easily adopted.

The effort we put towards SOAP can go into tackling the basic issues: performance, interop, authentication and authorization, and reliability, or into esoteric issues, as we seem to be doing now. Meanwhile, REST grows. How long before SOAP itself whiters and dies?

I’m sitting here in the hotel room, flipping channels, too tired to do any real work. I run across these free lectures from Harvard, and two minutes later I’m listening to a presentation on Evolutionary Dynamics. Nice. I see there’s quite a bit more out there; here’s MIT’s contribution, and some music lessons from Berklee College.

I miss academia. You specialize in your narrow thesis topic, but also get exposed to any variety of topics you like, with a chance to interact with the source of the information, the presenter.

I realize I’m not exactly representative of the general populous, but I’ll take evolutionary dynamics over American Idol any day. I expect there’s a strange little topic for anyone out there that’ll interest them more than what’s on TV. More and more we can get these on our schedule, tuned to our particular taste, fairly easily. Capturing content gets easier and cheaper, distributing it becomes a non-issue. TV gets less interesting everyday.

Academia is a great source of content, at least for a subset of the population. I look forward to more of this. The Web has changed my reading habits so fundamently; I expect in 5 years it’ll have done the same to my viewing habits.

“What do you think about the whole SOAP vs. REST thing?”. I hate this question, but it comes up all the time. Who cares? It’s all just XML over HTTP*. I don’t care about SOAP vs. REST.

My traditional answer has been: REST is great for simpler projects where the verb vocabulary fits the limited HTTP set, but as you look to add capabilities, you’ll invariably invent an envelope, and then some way of describing your service, so why not use SOAP and WSDL.

But this is not working. I’ve been publicly advocating SOAP for a long time; in fact, in a past life I started a company in that space. So it’s not easy for me to say this, but SOAP is in deep trouble. And when I say SOAP, I mean the whole SOAP+WSDL+UDDI+WS-* bundle, since the term Web services is ambiguous and includes REST for some people.

The problem is our obsession with constantly inventing new specifications instead of pausing and fixing the existing ones based on real world feedback.

To all you WS-* inventors out there: Look. Look people, look, look, look, look. Very smart people are having a lot of trouble with SOAP. Do you not see this as a problem? Do you see any of these problems being fixed by your new specification? Or should we pause for a minute, get the basics right, grow the whole market, and then address the higher level issues?

Let me point out the obvious: the whole Web has been built on simple little HTTP. How about that HTTP-DistributedManagement spec? How about that one about routing it through all kinds of actors and intermediaries? You hadn’t heard of those? It’s because they don’t exist.

This feels like dejva-vu; I wrote about this in 2002, and likely will again in the future. But let this be another data point: a hard-core, first-in-line SOAP guy is getting seriously turned off by this whole mess. REST is looking more attractive every day.

* Yes, I know SOAP is over “any” transport, but pragmatically speaking.

Check it out: http://norman.walsh.name/2005/03/12/nsdl .

I like it a lot. Specifying the parameters via XPath statements is dead on. The POST body as template is also excellent, although I’m not crazy about the syntax. How do you feel about expressing the input parameters as XPath too? So maybe the XML fragment, with the parts that should be filled in specified separately as XPath. XPath is not just for selecting; it can get you to the element you want to fill in or modify as well.

I’m trying to think back to my own attempt at creating a description language circa 2000. I believe I used actual XML fragments, ala Norm’s POST method, for all pieces, so you could simply copy the XML out of the description language, massage to taste, and send it on its way. The response was also expressed as a sample XML in the description file, although I do like Norm’s better.

I didn’t have any typing information in there, and I think that’s a plus. I know all the strongly-typed Java folks will be shocked, but scripting languages have lived and prospered without typing (everything’s a string) for some time.

What value does typing have? Information (telling the consumer what to send in), and Validation (letting the consumer check his parameters before sending). I’d argue once you have something that’s appropriate for validation, it’s complex enough to lose its informational value for the vast majority of people out there. The only validation language I’ve seen have usefulness is regexp, and that’s tool complex for most people to read and understand. So skip it; put the parameter types in a human readable document. Ok, so maybe RELAX NG is nice, and I can understand it if I crease my forehead, hold my breath, and concentrate, but most people don’t like creasing their foreheads.

Most of the work is not in checking the syntax of the parameters anyway; it’s in the semantics. Calling the Amazon service was nice and easy, except I had to figure out what all their categories and nomenclature meant. Schema’s not going to help me with that.

Nice work Norm.

Debugging Web services seems to be a black art, entirely related to your knowledge of the arcane details of your SOAP toolkit. Here’s one approach I’ve found useful:

A SOAP call is just XML over HTTP. All you have to do is capture the XML sent by the SOAP client, inspect it, modify it as you like, and send it to the SOAP provider.

Grab yourself a copy of netcat. This is a great little command line utility that “reads and writes data across network connections, using the TCP/IP protocol.” You can use it to capture data and send data on a socket very simply, which is what HTTP is about. Unfortunately I don’t think there’s a windows version; there are alternatives, but I’m too lazy to dig.

Compiling and installing this thing is a breeze, and trust me, you’ll be happy you did. It’s quite a useful little tool. You can follow the supplied instructions for installation, or just do this:

tar zxvf netcat-0.7.1.tar.gz
cd netcat-0.7.1
./configure
make
cp src/netcat /somewhere/in/your/path


Once you have netcat running, setup it up as a listener:
netcat -l -p 9000

Now point your web browser at it:
http://youraddress:9000/test/path

You should see the HTTP request on the command line where you’re running netcat, and your browser waiting for a reply. Since you haven’t told netcat to return any data, it’ll just sit there. Hit stop on your browser. Congratulations, you’ve just captured data over a socket.

To make this useful, you’ll probably want to put the captured the data into a file:
netcat -l -p 9000 > incomingrequest.data

Ok. Now let’s try it with SOAP. Setup netcat to listen on port 9000 as shown on the line above. Now, point your SOAP client at it. Take your existing client, and set the ‘endpoint’ or ‘proxy’ or whatever your toolkit wants to call it, to http://youraddress:9000/test .

Run the client. It’ll send the request, the request will get captured by netcat, and it’ll sit there since there is no reply from netcat. Hit Ctrl-C on the netcat command line.

Now you can take a look at the incomingrequest.data file to see what your SOAP client is actually sending out. This may be the end of your debugging; you may see something you need to fix.

If not, we need to take the next step and send the request to the actual SOAP service. This is pretty easy:

cp incomingrequest.data outgoingrequest.data

Open outgoingrequest.data in an editor. You’ll see something like this:


POST /test HTTP/1.0
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.2RC2
Host: youaddress:9000
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: ""
Content-Length: 411


Followed by the XML for the SOAP message. This is the request sent by your SOAP client in all its glory. The very first line and the very last line are the ones you care about. Modify the first line, changing /test to whatever path the soap provider lives at. How do you find the value for this? By looking at the WSDL for the service. As an example, open up the XMethods stock quote WSDL:
http://services.xmethods.net/soap/urn:xmethods-delayed-quotes.wsdl

You’re looking for the location attribute of the address element under the port element, which typically appears at the very end of the WSDL file. In this case:
<soap:address location="http://64.124.140.30:9090/soap"/>

So the location is http://64.124.140.30:9090/soap , and the path we’re looking for is the piece after the third slash, /soap.

Change /test to /soap in your outgoingrequest.data file. Now you’re ready to send the request to the provider. Run netcat as:

netcat 64.124.140.30 9090 < outgoingrequest.data

This sends the request that you captured to the service provider, and captures the response from the provider. You may want to capture it to a file:
netcat 64.124.140.30 9090 < outgoingrequest.data > incomingresponse.data

There you have it. Now you’ve seen both the request and the response. If you want, you can modify the request and see how the server responds. This is very easy; just modify the XML in the outgoingrequest.data file as you like. The only thing you have to pay attention to is the Content-Length of the request, the last line of the headers we saw above. Make sure you update this to be accurate. If you add five extra characters to your SOAP message, increase the Content-Length header by five. You get the idea.

Each time you use Amazon it assembles a better profile of your tastes, your habits, your likes and dislikes. Why should they own your profile? I propose you publish your likes and dislikes via a simple XML format (RSS? Atom?), and we build collaborative filtering tools to help you find people who share your tastes and lead you to new things you’d like to taste.

The basic idea is something like this: imagine we had a vector of likes and dislikes for a group of people. For each person, a long array that has a like or dislike for each item. We can use these vectors to calculate similarity between people’s tastes, and to predict items they may like but have not tried. This sort of technology is fairly common now, with Amazon and Tivo being two
well known examples.

Trouble is, Amazon may have a partial picture of what I’m interested in based on my interactions with them, but they’re not sharing it with me. So why don’t I keep and publish my own taste vector? If you do the same, and we can convince many others to do the same, we can get some meaningful info floating out there.

Here’s my basic proposal: let’s come up with a dead-simple XML format for expressing these vectors, and a convention for where they live - say, http://yoursite/tastevector.xml . We need to agree on a couple of things: a consistent way of referring to items (so we both use the same ID for the same item), and a consistent way of expressing like and dislike.

Consistent naming is a hard problem. So let’s punt and go with a good-enough solution. We can use ISBN for books, IMDB ids for movies, Amazon id’s for items carried by Amazon, and we’ll figure out something for the rest.

For expressing like and dislike, we can start with a very simple setup: Like, Dislike, Neutral, and Own, where Own indicates you’ve bought this thing but haven’t bothered to publish an opinion on it.

If you’re a geek like me, we’re pretty much there. But for the rest of the world, we’ll need tools. This can be very simple - just a web page that lets you type in your item and your opinion of it, and spits back a piece of XML, or maybe updates your taste vector for you. This could be a service that stores and serves up your taste vector so you don’t have to worry about it.

But now we’re publishing lots of details about what people like. What about privacy? Well, come up with a fake name or a fake identity for your taste vector if you’re worried about it. And don’t list the items you’d be embarrassed to tell other people about.

With me so far? If we can get enough people to do this, a bunch of tools will emerge to gather intelligence from it and suggest new things for you to try. Believe me, this is data people would kill for - better yet, it’s data marketers pay lots of money for today.

Why do I care? Because my tastes are sometimes outside of the norm, and I want to find the other wierdos to turn me onto new wierd things to try. If you’ve been following the long tail discussions, I may be able to convince you that there are a lot of outside-the-norm people there - in fact, it’s very likely you are one yourself.

Why do I think this may work? Well, it’d take a miracle to get this to really go where it could, but the success of technorati style folksonomies has me thinking miracles are happening these days.

If you’ve read this far you must be interested, so drop a comment in here and we can see if this has any legs…

I watched Ondskan (Evil).

Decent movie, fairly juvenile. It pushes all the buttons to build the tension, the hatred of the mean mean bad guys. The hero is so noble, so cute, such a good boy really. It’s one of those experiences where you find yourself rooting for the good guy and hating the bad guys with a visceral, childish surge. The ploy at the end is predictable and not overly satisfying.

Having said that, there are some nice aspects. It reminded me of real friendships, the kind you form when you’re young and emotions are pure. I enjoyed it overall, although not on any fancy, intellectual level; this is just a fun, let’s hate the bad guys kinda ride.

I’d rate this one as Watch if it comes your way.

I just watched The Machinist. Interesting movie. The most striking thing, almost an extra character in the movie, is Christian Bale’s emacited body. He starved himself for this role, achieving an incredible, disturbing skeleton state that had me distracted for the first ten minutes.

The movie is ok. I had high expectations - Christian Bale is typically a guarantee of a good movie. This has a nice creepy, disturbing feel all the way through. The story line is not terrible, but not great. The twist is decent.

One thing I didn’t figure out: The Idiot by Dostoyesky, which is one of my favourite books, kept showing up. That was a little odd; Crime and Punishment seemed like a more appropriate selection.

If you liked Fight Club, you may like this one, although Fight Club is a much better movie.

I was going to use a number based rating system, but these categories makes more sense to me: Avoid, Watch if you’ve got nothing else to do, Watch if it comes your way, Go watch it, Go out of your way to watch it, and Go right now, track it down, and watch it.

For The Machinist, I’d say Watch if it comes your way.

I hate XML namespaces. I strongly dislike them.

I will rant about this in detail in the future, as if there hasn’t been enough vitriol on this topic already. But let me present my current problem:

gsoap is returning this:


<soap-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:cmoda="urn:ows:cmoda:0.1">
</soap><soap-ENV:Body>
<cmoda:updateOfferBidsResponse>
<setofresults>
<item>
<source-id>1</source>
<sequence-num>1</sequence>
<offer-id>123</offer>
<success>true</success>
<reason>CMODA-UPDATE-OFFER-BID-UNDEF</reason>
</item>
</setofresults>
</cmoda>
</soap>


Axis is the client, and doesn’t like it. Complains of source-id not being correct. Turns out, it has a problem with the namespace. Most SOAP servers would return the result as:

<updateOfferBidsResponse xmlns="urn:ows:cmoda:0.1">


Note the inclusion of the namespace within this tag.

I looked thru the XML namespace tutorials, and I can tell this version means the child nodes of updateOfferBidsResponse are in the namespace specified here. But what does the gsoap version mean? Does

<cmoda:updateOfferBidsResponse>

also mean all children of updateOfferBidsResponse are in the cmoda namespace, or are they in some other namespace? I’m no genius, but I’ve looked around a bit and I can’t find the answer. In any case, either the Axis or the gSOAP folks didn’t quite get it either, or better yet, the XML libraries they’re looking at got it wrong or disagree.

I’m saying, people smarter than I don’t get it.

I’m trackback’ing Mr. Tim Bray’s long ago post in case by some magic he becomes aware of this and sheds some light my way (he’s the co-author of the spec, and I’ve met him once or twice, so why not bother him)…

So I’ve started this blog. But before I commit any more of my precious thoughts into this medium, let me step back and be one with the blog. Let me complain.

I’m using WordPress, which is really quite nice. But, …

You see, my thoughts, if you hadn’t noticed, are not trifles to be tossed away with the wind, yesterday’s news, here today gone tomorrow. They’re timeless treasures, to be cherised for all time. For each topic, I’d like permanent pages with meaningful, static-looking URLs. That way I can go back and build on a topic I had approached before. Also, each post can get indexed by google and I can make a fortune selling ads.

From the Wordpress Wiki:

Posts are very time-oriented objects. You write them at a specific time, and that time defines their context. Pages, on the other hand, are most often used to present information about yourself or your site that is somehow timeless - information that is always applicable. For example, you might write a Post describing what you did or thought on a particular morning (”Breakfast was good”), but on a Page you might write something whose context is less time dependent (”This site is about breakfast”).

Hmm. I disagree. The information in my posts are always applicable. They are precious nuggets of pure gold, dammit! In any case, Pages don’t have static-looking URLs either (by static-looking, I mean yahoo/google index-able).

I’ve found some resources on this: WhenBlogsMeetWiki,
WikiAndBlog .

I want the ease of use, the chronological presentation, the comment threading, and overall prettiness of a blog, but with the information publishing capabilities of a Wiki. I guess the main aspect of a Wiki is the communal editing capability; that’s not what I’m looking for in this context.

Basically, I want a blog front-end for a Wiki. Is that unreasonable?

This is hilarious…

http://www.overspun.com/video/Kimmel.TWIUC.02.18.04.wmv

I just saw Kung Fu Hustle . This is quite possibly the best movie ever made.

Ok, so maybe I exaggerate a little. But this is an excellent movie. Laugh out loud funny, and I’m not much of a laugher. Btw, Wachowski brothers, this is how a fight scene with one guy against a thousand is done.

Highly recommended. Go see Kung Fu Hustle. I give it 9 out of 10. Now I’ll have to go see Shaolin Soccer I guess…

I bought a Creative Nomad Muvo MP3 Player a little while back. I love this thing; it’s exactly what I wanted.

Before buying that, I tried a Lexar MPC-231 JumpGear, which is basically a cap for a USB memory stick that turns it into an MP3 player. I wasn’t happy with it; there wasn’t enough control, the screen was too small, it just didn’t feel right. This was generally my opinion of the stick type MP3 players, although my brother has the same Lexar and is happy with it.

So along comes Apple. They have a player with less features, less control, no screen. This would be absolutely un-sellable for Creative. A non-starter for any other brand. Sell less for a higher price? No way.

But apple has the intelligence to understand with such limited storage space fancy controls don’t make sense, the guts to embrace that, and the marketing genius to take a lack of features and turn it into a positive. The Shuffle. It’s freakin’ genius.

I’ve worked with and ran into quite a few marketing people in my time. They spend most of their time explaining that their sales people are idiots, the customers are idiots, or both. Apparently they got it backwards. I’m convinced there are 4 people who actually can do marketing, and they all work at Apple.

I have nothing interesting to say. Yet the urge to share my inner-most superficial thoughts with you, dear stranger, is so strong, I must start blogging. All the cool kids are doing it. And so I blog.