Just as Web Services start to embrace the Web and begin to pare the specifications down to manageable levels, syndication technologies begin to present new options for enterprise computing.
Mark Baker points to a piece by Jack Schofield in Computer Weekly comparing SOAP and RSS/Atom:
"It is clear that there are lots of server-based applications (not blogs) that could work by syndicating packets of XML data to client applications (not RSS aggregators). These will not rival Soap/web services as a system for executing transactions." -Jack Schofield, Quick and dirty substitute for Soap
I agree with Mark. If anything Jack Schofield is underestimating the impact syndication technology might have over the next decade. Last year I used Atom as the packaging format to ship system and business level events to a central monitor (I bet Coté would be up for a bit of that). I don't see why it would not be a good basis for enterprise concerns like messaging, authentication, or management interfaces. Atom, RSS and the Atom Publishing Protocol (APP) as a complement to REST could disrupt SOAP and WS.
The SOAP systems are going into their 3rd generation, but the same old skeletons of object mapping, synchronicity, design from code to wire and over-specification persist. For example, it would be curious to see how the Alpine Web Services proposal for Java might turn out if it targeted syndication XML instead of SOAP XML.
While the APP is 'just a' publishing technology and Atom is 'just a' syndication technology, there are five reasons to that microprotocols - namespaced module extensions that inform and affect application behaviour - will appear as an alternative to WS and SOAP based technologies by targeting enterprise computing concerns like reliable messaging and tracking. First such protocol driven extensions will tend to be mutually exclusive of each other and not an interdependent monolith as Web Services have turned out to be - that will make them easier to build and get deployed. Second, a good amount of Web Services complexity comes down to addressing - with syndication formats, addressing problems are dealt with using the Web's architecture and existing infrastructure rather than starting over. Third, with the exception of XML-RPC, none of the web syndication technologies carry the baggage of RPC-centric, protocol agnostic computing. While SOAP proponents are adamant the state of the art has moved beyond remote procedure calls, in the field many still have not learned the lessons and the tool kits have not yet caught up with best practices. Fourth and this should not be underestmated, a number of tricky issues around using XML in the protocols arena, security, and for carrying non-XML content were shaken out by the work on SOAP for others to learn from - this is reflected most notably in the Atom effort. Fifth, and perhaps most important, where traditional enterprise concerns cross over with consumer online services, they have tended to gravitate to plain XML over HTTP and REST-oriented approaches rather than SOAP Web Services. This is being done squarely to encourage the treatment of the service as a development and innovation platform and again comes down to speed and ease of implementation.
There's Plenty of Room at the Bottom
As next generation browser and aggregator applications fully support Atom, RSS and the APP, there's no reason to think that facilities like online order tracking and notifications will not be exposed using those formats. There's also sufficient reason to think that mobile technology will also support them. Incumbents, commercial innovators and application developers will tend to not invest time with the infrastructure as has been the case with Web Services - in truth when the pace and nature of innovation is happening outside consortia space, there's isn't much leverage to be had by controlling infrastructure. Instead they'll tend to target and compete using microprotocol extensions in a feature-driven approach. Microsoft are already going down that road with in terms of microformats with the RSS simple list extensions - which are incidentally usable via any syndication format. Extensions for enterprise concerns will surely follow.
The title of this post is taken from a section heading in Richard P. Feynmans wonderful essay There's Plenty of Room at the Bottom
What Sean said. After a lot of hard work in community building and a lot of development, Jython 2.2a1 is available for download. It's the first major release since 2001. Don't let the minor version number fool you. The jump from 2.1 to 2.2 is big: new-style classes, generators, and collections integration are significant changes - Jython just got a whole lot better.
From the release notes:
"This release includes many major changes since the last full release: - new-style classes - Java Collections integration - PEP 302 implementation - iterators - generators - __future__ division - support for running on JDK1.5 - new installer - a significant number of features to bring Jython in line with CPython - many, many bugfixes"
As I understand it, there'll be alpha and beta cycles before 2.2 is released. Anyone using Jython 2.1 should keep an eye on the releases. - I imagine 2.2 will be arriving some time this year, and you'll definitely want to upgrade to get the new language features and fixes.
"That is because scalability issues are not framework or language specific." - Brian McCallister
Good post from Brian. But be careful, it's not all solved in the system architecture. Which is to say, no matter how good your architecture is, you need to think about and measure how well the application code is running. You can still write application code that will kill a computer as the volume of data grows. Sean was telling me last night about some performance profiling he'd been doing for a multi-stage, multi-pipe XML processing line - let's just say that where the bottlenecks turned up were counter intuitive - I absolutely guessed wrong, but of course I did - it's a given that you'll guess wrong. So you have to measure - but to measure you have to build something to measure - you won't solve these kind of issues during architecture-picture-time. Spend architecture-picture-time making sure you can build something which can be measured later on.
As we keep moving towards application logic and to a value-driven programming world where transaction monitors, pools, caches, i/o, malloc-dealloc, library data structures, and runtimes are about as relevant a concern as flip-flops and asm, there's a risk we'll forget about the algorithmic side of code, which is never going to go away completely. Two of my favourite algorithm books for the working stiff, real eye openers, are Richard Skiena's The Algorithm Design Manual and Jon Bentley's Programming Pearls. The other thing that's caught my eye is not a book but a presentation [pdf] fast becoming a classic, by the people behind Livejournal, which is called, but if it were a nineteenth century novel it would would be called "LiveJournal's Backend. Or, You Can Scale Anything For Capacity When You Put Your Mind To It Even If You Didn't Get It Right Up Front, Or Have Become Surprisingly And Insanely Successful, And Are Now In The Weeds".
The Atom format is done. Here's Tim Bray from the atom-syntax list:
"...the remaining IETF process steps will not introduce material technical changes, and so format-10 is appropriate as a basis for implementors to go to work. So, implementors... to work."
This means there's some administrivia, but the Atom 1.0 format won't be changing. Tim has a followup on ongoing and you can read of about some of the i and t's that are going get dotted there.
Backing material to the format is coming along nicely. Sam Ruby is starting a suite of format tests. Tim has also written a comparison between Atom 1.0 and RSS2.0, which will help clear the air around the two formats. Robert Sayre has an article about Atom coming up in this month's issue of IEEE Internet Computing.
Apart from implementation, anyone publishing with the defunct 0.3 format can now start fixing their templates to use Atom 1.0. You can read the spec here and section 1.1 has a couple of examples that should get you started. I'll be fixing my own feed sometime after work today ('cos, you know, someone will check...). Anyone writing a book or articles can safely target Atom 1.0 as it appears in the draft-ietf-atompub-format-10 document, but it will eventually get its own RFC number.
Now, onto the Atom Publishing Protocol, or APP. Keep an eye on this one, a number of players are taking an interest, especially now the format has settled. Apart from normalizing the number of ways you can talk to aggregators and weblogs, as a publishing protocol designed to play nice with the Web, it's going to have an impact beyond syndication technology. I'm really excited it's going to act as a radical simplifier for web services, content management and even systems integration. So do check it out. I'm privileged to be helping Joe Gregorio out with the editing on behalf of the working group. With that, I intend to hack together a Python reference client to help draw out the issues (if anyone is working on an OSS server implementation of APP, let's talk). The work (yes, there's plenty to do) is happening on the atom-protocol list.
In Wikis, there's a nice trick you can use to bootstrap classification. Since clicking on WikiPage's title will show you all the pages that link to it, you can add a CategorySomething link to any wiki page and then add CategoryCategory to the CategorySomething page. To find all the pages in your something category, click on the CategorySomething page title. To find all the categories in your wiki, click on the CategoryCategory page title.
"If you do not have version control then you haven't got the ability to go back and fix mistakes easily. You do not know where you came from in a way. You haven't got the history of your code. Editing a code base without version control is kind of like using a word processor that does not have a delete key. You are typing away and as you get to the 50th page, you are typing very, very carefully because if you make a mistake you cannot go back and you've lost lot of work. Same with version control. If you do not have that kind of capability, you can't control your project's code base and you don't know where you got it from. Unit testing is equally important because unless you have a tested code base at the unit level, the very low level, then you're really building on sand. As you add functionality on top of functionality, you really don't know if the foundation is solid and that's why so many projects start to crumble when they get to a certain weight and certain height because the underlying stuff is just too flaky and it just falls apart. Lastly, automation is important because without automation you don't get consistent builds. You cannot consistently put together a bit of code. When you consider the average project now that is shipping on a CD with millions, billions of bits potentially, how do you know that those bits are the right bits. We had teams we went to where we had maybe 15 people on the team and if you have a look at the build product on those 15 PCs, they would be different on each one. So which one is the shipped build? Which one is the customer receiving? If a customer says I got a bug and the developer says, "I don't see it," then how do you know what to do? Because a developer's actual application may be different from the one the customer is running, so automation is really important." - Dave Thomas
Dave Thomas is a smart man. His interview on The Server Side is well worth the listen.
Cool, I lived there when I was a kid.