It’s interesting that the SOA Power Panel, as of 11:50 am Eastern U.S. time at least, is more often viewed than the App Server Shoot Out, 6,148 to 5,754.
It would appear to me at least that this result is not what Jeremy and the folks at SYS-CON would have expected since they broadcast the app server shootout “live” and chose to record the SOA Power Panel for later viewing.
Of course I have no idea how many viewers “tuned in” to the Web during the live broadcast, so maybe the reason for the difference is that the App Server Shootout’s live audience reduced the number of later viewings.
On the other hand, given the SOA Power Panel’s strong replay numbers, perhaps this indicates that it is simply a better “show.” I am not sure though, if this is true, how viewers might know that it is. Word of mouth?
Christmas is when we gather families together, remember friends, and indulge in the Christmas spirit.
My friend from Germany mentioned how quickly the time seemed to pass since his last Christmas message. This is a frequent item of conversation, of course, but nonetheless true. As I like to day, a 50th of a lifetime is smaller than a 10th. Time seems to accellerate as we age.
But there’s more to it. When our daughter was born it seemed like it took 100% of our attention to care for her. When our son was born about a year later, it seemed like it took another 100%. The accelleration of time hits warp speed after you have kids.
Yesterday we were listening to a classic Motown Christmas album. My daughter asked whether it was Stevie Wonder singing “One Little Christmas Tree.” Indeed it was: “One little christmas tree can light up the world.”
The Newcomer Tree Lights Up the World with Christmas Spirit
On Christmas we celebrate the best in us and think about friendship, harmony, and peace. Before I reach the end of my time on Earth I’d like to share the Christmas spirit with a few things (in no particular order):
Let’s have a truce in the battle over developers between Java and .NET. Let’s agree that XML is the thing to develop now. Those languages are just among the many that can be used to parse and interpret the XML.
Let’s call for peace among SCA, WCF, and JBI. Sticking to the standards – especially WSDL – should leave room for them all.
Let’s reconcile the Liberty Alliance and WS-Federation, WS-Reliability and WS-ReliableMessaging, REST and Web services, WS-Transactions and WS-CAF (well I guess we did at least manage to get a good start on this one).
Above all let’s just agree that the standardization of software is in everyone’s best interests, and that Web services and XML represent the best opportunity to date. Let’s focus on conformance to the specifications and finally achieve the interoperability and portability our customers have been asking for for years.
Perhaps I should have put this all on my Christmas list for Santa. But I am a strong believer in the power of the Christmas spirit. On top of that, I’m an inveterate optimist.
All the best for the holidays to everyone!
I am very pleased to say that the Celtix team here is cranking away, together with some other folks in the ObjectWeb community and made its date for the third milestone.
If you get a chance, please download Celtix and let us know what you think.
Every once in a while I search Google news for Web services stories.
Today a couple of interesting items came up.
The first was on this recurring motif of REST vs SOAP. Only this time the author decided to talk about it in terms of the “easy” vs the “hard” way to do it.
We went around on this a bit more than a year ago and I would have to say that the obvious conclusion seems to be that you use the simple technology when it’s appropriate, and the more complex technology when you need it.
Absolutes do not apply. It isn’t possible to characterize REST as easy without asking “easy for whom?” Or “easy for what purpose?”
These debates (mine included) always reference the Amazon.com experience, which shows that XML over HTTP (this is not really the same as REST by the way) is used by 80% of the developers while SOAP is used by 20%.
The first time I heard about this was back in June of 2003 and for me this still represents one of the best summaries of the phenomenon: SOAP is easier for developers used to Java or C# while XML over HTTP is easier for Web developers.
One technology is not inhernetly easier than another. It depends on the application – that is why we have different tools in the toolbox. What’s easy or hard depends on what you are doing.
If you are mapping XML to a Java or C++ class, using SOAP is easier. If you are simply searching for XML elements in an XML document to transform into HTML or something else, XML over HTTP is easier.
Another interesting news item concerns the demise of the public UDDI. I remember very well when this was launched in October of 2000 at Microsoft’s Redmond campus. It was a great vision, portrayed in living video color, of a Web of self-discovering services that would assemble themselves into any combination of interactions across the Internet to serve business and consumer alike.
One of the big problems was noted at the time: the lack of any oversight on the data posted to the public UDDI. Unlike the Yellow Pages, no one was ever in charge of verifying and validating the information being posted to any of the public sites. IONA developers used to store their browser bookmarks there, for example, for later retrieval after upgrading or changing computers.
Another problem was the data model. Granted, the world lacks a unified business or industrial categorization scheme, so this isn’t entirely the fault of UDDI.
I also clearly remember, late in the day, after all the video and PowerPoint, someone from the audience raising his hand to ask the question: “Can these technologies be used inside the firewall?”
It’s hard to remember now that back in 2000 now one was thinking about using Web services inside the firewall. We were all caught up in the magic of Web services over the Internet (“the browserless Web!”), and weren’t thinking much about using UDDI for an enterprise registry/repository. However today that’s very clearly what we are left with.
I was in Seattle last week and didn’t get much time to update the blog. Otherwise I would have posted this sooner.
The other two SYS-CON TV recordings are out:
It’s also great to see the SOA Power panel still on the most popular list. I thought that was the better of the two panels, a more lively discussion around the table, with everyone contributing and complementing what the other said.
As I mentioned, these were all done in an afternoon at the Reuters Studio overlooking Times Square.
I came from San Francisco on the redeye, walked for an hour to get some exercise and buy some dark socks (for some reason I hadn’t packed enough dark socks), slept for a couple of hours, got some lunch, and headed to the studio.
Then it was basically one panel after the other, directly followed by the one-on-one. Jeremy let me go first so I could catch my plane, but that meant I went right from the open source panel to the one-on-one. It seemed to be over before it got started. I left thinking it hadn’t gone very well – in fact wondering whether they would even post it.
I was just too tired. I didn’t manage to say everything I wanted to say. I can really see it, but I’m not sure it is so obvious to anyone who didn’t know how I was feeling. Everyone who’s seen it tells me it came out fine. So I guess you never know.
I am often asked about the differences between SCA with JBI. Jean-Jacuqes Dubray’s recent post on this topic has a great take on this, also including a comparison of those two with JCA for good measure.
It is really cool the way Jon Udell manages to snip multimedia content.
He was telling me about this during a break at last month’s Executive SOA Forum. He discovered how to do it by and trial and error. He figured if a media player could display the elapsed time, there had to be a way to reference that time point using a URL.
In the associated text, however, Jon did characterize the comment a bit more narrowly than I intended, as Tim Ewald points out.
I actually wrote an entire article on this topic to help promote my first Web services book.
The article also contains my definition of a Web service, which I made several attempts to standardize during my nearly two-year tenure as an editor of the W3C Web Services Architecture Specification.
While I didn’t exactly succeed, I did at least win the argument over separating the definition from the execution environment (i.e., the execution agent).
Paul Downey also contributes a good and succinct entry on the distinction between rpc-encoded and doc literal data formats, how we have finally settled on doc literal, and the consequences thereof. (And yes, Paul, I am still working on getting someone from IONA to join your WG. I haven’t fogotten 😉
But getting back to the original point, I can remember clearly the first time I had to come to grips with the differences in processing model between the XML/markup world and the “traditional” distributed computing world. A few months after I joined IONA I took over as chair of the XML/Value effort.
One example I use to illustrate the difference is one that I learned during those long XML Value conference calls and meetings. One of the XML folks from IBM used the analogy of HTML frames to illustrate the point about processing only what you understand of the data (or message). Today frames are pretty much taken for granted, but five years ago it was easy to remember when some versions of browsers didn’t support them. But those browsers still displayed the HTML that they could understand, ignoring the frames since that was part of a newer version of HTML that they didn’t understand.
In the binary world of distributed computing – let’s say CORBA for example – even a byte’s difference between what the server expects and what the client sends would cause a failure in communication. Not in the XML world. (This is by the way one definition of loose coupling.)
Web services represent a kind of unification of various computing “cultures,” each of which tends to view Web services through the lens of the technology they’re most familiar with. Let’s hope these various worlds can work together in a positive and fruitful way, and that we will all be able to create good standards and solutions that work for everyone.