Oct 312005

On Friday one of the developers from Sun’s Fast WebService team, Santiago Pericas-Geertsen, posted a blog entry that included a reference to our work on IAP. I’m a big fan of Fast Infoset (FI), which is the technology and standard that is driving the Fast WebServices and the binary XML movement. This technology is a binary representation of an XML schema instance document that allows the format of the data to be expressed using XML schema, while still allowing for binary data to be sent as part of the document. Additionally, the documents are more compact and simpler to parse providing a large performance improvement.

This technology is truly the next generation for remoting and data transfer because it provides the ability to use all the good features of XML and XML schema without the binary limitations, which traditionally have plagued that technology. Additionally, the team of developers working on the FI project over at Java.net truly understand use cases for this technology.

A simple illustration of the great work the FI team is doing is that their FI parser is able to correctly handle an FI document from a InputStream without requiring an end-of-stream to determine that the FI document has ended. This makes it obvious that these developers understand that streaming XML or multiple documents on a single stream are going to be common applications for FI. Without mangling the stream at all, they can effectively read any number of FI documents from it.

We decided a while back, after comparing the performance of encoding simple JPEG images into a standard XML document and pushing them across the wire versus using a binary stream, to switch to FI. We found that since standard XML required that binary data be base 64 encoded and decoded, pushing images and other binary values across the wire had such a negative impact on performance that another solution was required. This is when we started evaluating Fast Infoset and found that it worked extremely well and required few changes to our existing code.

Here is the link to the blog entry that highlights the use of FI in IAP:


Also, here is the link to the FI project whose parser and serializer we are using:


Oct 252005

Inversoft has finally launched the IAP specification. This release has been stewing for a long time and it is finally out in the world. I’m still extremely excited about IAP and the possibilities for it. I’ll be spending my time this week sporadically sending out announcements hoping to drum up some interest. The only way that this technology is going to survive is if people get interested and start helping make it a success. Only time will tell.

In other news, I finally got the Savant runtime up and going. It currently only has a single feature that will spit out the dependency tree for any project. I have a lot more work to do to get it ready to release, but once I feel that the runtime is solid enough to support developers building out new dialects and plugins, I’ll release it as 2.0. From there, I’ll just be adding dialects and plugins as I need them and let the rest of the world go nuts.

Oct 242005

This is a bit late, but day 2 of the JCM went pretty well. There still is a sense of the need to spread the word about Jini to the rest of the world as well as the need to use Jini as a replacement for J2EE and Web Services. Honestly, I think there are bigger problems to worry about such as the “versioning” problem than worrying about whether or not WebServices is the best or worst technology, but the value of determining where Jini sits is valid.

The problem I think is that most folks don’t think Jini is “plumbing” (i.e. infrastructure) and it is. It’s kinda like a VIP or the clustering support for J2EE containers. It’s main purpose is to distribute across physical machine boundaries and not that much more. Of course folks will say that it does security and remote invocation and a whole suite of other things, but under all that, it’s just a distribution mechanism. Therefore, it plays really nice with J2EE and with WebServices. There’s no reason why Jini can’t co-exist. I say we take a step back (and a step forward, and a step back…) and get back to the hard problems.

As for the need to spread the word, well, I’ll let the marketing folks handle that. I like Jini and think it solves some problems, but has others as well. I think it should be used where it makes sense and ignored where it doesn’t. If Sun thinks it is the wave of their future, they are probably the only ones that are going to make enough noise to get it going, but I could be wrong. I say that because from what I see the Jini community for the most part likes the quiet.

Oct 192005

Jim Waldo was the keynote speaker today and had some great things to say about the future of computing on the network and about many things that plague everyone building large applications. The work that Brian Zimmer and I have done at Orbitz attempts to address a good portion of what Jim covered.

The main concepts were of course Reliability and Versioning. These go hand in hand because all engineers know that software evolves and at some point, if the applications are used enough, downtime isn’t acceptable for upgrades. Additionally, system wide upgrades aren’t feasible and can be extremely dangerous.

Another underlying theme is around Jini’s visbility and acceptance, as well as problems that plague Java and large open source bodies when they want new features. In my opinion, Jini doesn’t suffer from the open source debacle that is so common these days. Nor does it suffer from the standards hell of some other bodies. This means it doesn’t have as much exposure or momentum because that is the way it has stayed out of harms way.

This is similar to various smaller less notorious open source projects, most of mine falling into this category, that can make great changes that might normally cause disasterous uprisings in the community surrounding them and the user base. For example, I’ve completely re-written the model for Savant, because it needed it. I’m going to make that a minor revision and I’m pretty safe in assuming that no one is implementing my APIs and that these changes won’t cause issues. Jini is somewhat able to move in this agile way because of the lack of momentum and acceptance.

I think that the points that Jim brought up and all of the talk around here today suggests that something is going to occur in software in the near future, but I’m not certain what it will be or who will end up on top. Nor am I able to speak to the time-frame at all; but the enormously tough problems of versioning and reliability are going to require new methodologies and above all else new technologies. These technologies must be capable of taking a stance and say, “we are going to break all your stuff! Get ready or get out!” I don’t know if Java will ever do that, but I think Jini could if it could get out from under the sluggish giant it relies on today.