Blog vacation

I’m on vacation tomorrow through July 30, headed to London of all places. At first when I heard the news today I thought of canceling. After all, it isn’t just me but my son also.
I’m meeting my son Saturday at Heathrow. He’s finishing a six-week college program in Friday in Ireland, and then we’ll spend four days in London, take the chunnel train to Paris for three days, and then return home. It should be a great trip, and I have been looking forward to this for a long time now. I am not going to let those people ruin our plans.
And I’m not taking my laptop with me, for a change. Nor do I plan to spend a lot of time in Internet cafes. So the blog is also taking a vacation.
It’s been about 18 months now since Steve Vinoski suggested that we get started, and it was just starting to become popular. As this (among many articles) says, now everyone has one.
And by the way after that article (in the previous link) was published, I started receiving dozens of blog spam comments. Much more than usual. Those of you who have blogs recognize this phenomenon. They arrive regularly in any case, and for me the existence of spam comments were definitely one of the surprises in blogging. I have made a practice of closing comments and disallowing trackbacks after about a month. Otherwise I just spend too much time dealing with it. Unbelievable.
Because I cannot blog every day – unlike some other folks blogging is not my main job (don’t get me wrong, Scoble is a great guy and I enjoyed meeting him a few years ago at the Web Builders conference (now unfortunately defunct)), I try to focus on a “content” blog. Meaning I try to set aside a half day a week to create entries with some good content in them, some original ideas, opinions, or perspectives. Kind of like new articles or opinion pieces, but more personal. Hopefully to last the week instead of trying to put out brief entries daily, or several times a day, as many others do.
When I get back I will start trying some new stuff in the blog. But till then I hope everyone is able to have a great vacation this summer, as I am sure the blog is having, and keep your fingers crossed for me and my son in London next week.

.NET Discussion Misses the Point

Lots of heat generated by this eWeek article about .NET and VCs, but very little light.
The center of the reaction in the blogosphere seems to be either from Microsoft and related folks saying that maybe Microsoft’s approach with .NET (and perhaps Longhorn) is responsible, while other reactions focus on the misleading headline (i.e. it is not VCs who determine the market direction).
But this all misses the main point — open source is now where significant innovation is happening in software, and thus where VCs are more likely to find suitable investment candidates. Where once innovation happened more or less behind closed doors accessible only with strong NDAs in place, innovation is now starting to happen out in the open.
For example, a new Evans Data study shows that open source adoption is no longer based on cost alone and in many cases not even primarily. Open source users are finding excellent technical quality and suitability of features and functions. The decision to adopt is apparently becoming independent of whether the source is open or not.
The open source world is more a survival of the fittest environment in which code quality, ease of use, and suitability of and features and functions is of primary importance in determining a successful project. Customers can easily go to the next open source project if one doesn’t meet their requirements.
At the Massachussets Software Council Open Source SIG kick off meeting June 24 (which I previously blogged), Nat Friedman and Miguel de Icaza stressed the importance of preserving upward compatibility in open source projects. Failure to do so will also cause defection to other open source projects.
Furthermore, when Nat talked about the Hula project he started in February at Novell, he mentioned (and this is in the slides you can download either from his site or the SIG site) open source as a disruptive market force. The motivation for the “architecture of participation” for the Hula project is to create the industry’s best email and calendaring solution.
And as we have stated on the ObjectWeb open discussion forum for Celtix we are committing to have our commerical product, Artix, maintain consistency with Celtix, not the other way around.
Update: Another blog entry from a VC quoted by Scoble.

Legacy is just beautiful

Through the TechWatch news service comes this reference to a Computerworld article on the “beauty” of legacy systems.
Beauty as in the eye of the beholder, of course. Or as one of the founders of this company liked to say, “There are no ugly babies.”
It’s interesting in this article that the definition of legacy is pretty much something that works. In fact some people would say that “legacy” is a name any code earns immediately after it goes into production.
A few years ago we were discussing how to handle “legacy” systems in a standards meeting. The IBM representative said they preferred the word “heritage” (and even got a few people to go along with the idea that this is more polite somehow).
I thought why not take the next step? Call them “heirloom” systems…
But the serious point of the article highlights what is probably the most significant impact of Web services on the IT industry: the ability to recognize the value in existing systems and easily enable it for reuse. We are not talking about replacing COBOL with Java anymore; we are talking about adding a layer of XML to what’s already there and getting more out of existing investments, which is a very good thing.
We are not talking any more about replacing stuff that works just because a new technology came along. Legacy is definitely beautiful when it’s dressed up in XML and exposed using Web services.

ps on JBI

After writing a somewhat lengthy and abstract entry about JBI yesterday it occurs to me that there’s a relatively simple answer to the confusion (see the comments at the end of the entry).
A lot of the difficulty seems due to marketing messages that compare JBI to EJB, when this is not really appropriate.
The reason for that, as I understand it, was to underscore the potential importance and impact of JBI on the industry. This of course remains to be seen.
However JBI and EJB are technically very different and no one should be thinking of one as an alternative for the other.
JBI is entirely focused on an API for integreation vendors. Application developers are unlikely to ever use it.
IONA’s implementation, which was demo’d at Java One, for example, allows any JBI compliant integration component to be hosted on Artix. Any vendor of business process management, data transformation, security services, transaction services, etc. can therefore immediately take advantage of Artix’s high performance middleware kernel and multi-protocol, multi-format, and multi-language capabilities.
EJBs on the other hand are squarely aimed at application developers and have nothing at all to do with enabling best of breed functionality for customers of integration technology.

JBI Debate

It’s good to see the current debate in the blogosphere around JBI. For one thing it’s good because once we are seeing this kind of reaction and this level of attention in Don’s blog it means JBI is starting to get some mindshare…
Don mention’s Steve’s entry although that entry was actually primarily about Celtix. But because Celtix supports JBI we are inevitably drawn into this debate…
In response, the first question to ask is whether one container can fulfill every requirement. This is kind of like asking whether one computing language meets every developers’ needs. The answers seem to be no and no.
If we can agree that multiple containers are necessary because one size fits all is not a good approach in software, then the next question is which containers do we need, and for what purpose(s).
JBI is aimed at messaging and integration, whereas EJB is really a transaction processing container. Sure EJB has support for “message beans” but these are in the context of transaction processing, a sort of messaging add on to the synchronous orientation of EJBs, like queuing is an add-on to popular TP monitors when applications needed both. This is not the same thing as a pure messaging solution since the queuing in these environments is always done within the context of the TP monitor environment and uses its development metaphors and APIs (i.e. not independent ones).
The answer to Don’s question about JCA vs JBI is pretty much the same, that is, within the context of whether you are doing OLTP or asynchronous messaging based integration. If it’s the former, use JCA since you are already using EJBs. If it’s the latter, use JBI since you don’t really need all the other EJB APIs. And EJB and JBI containers can co-exist, just the way TP monitors and independent messaging systems have co-existed for years.
The JBI container model is needed because asynch messaging and integration functions need to be first class citizens of many applications, not simply add-ons to TP monitor style interactions. However, equating EJB and JBI is also not quite correct.
The EJB container is all about concentrating user transaction requests into a shared database. The app server is the modern TP monitor, and the EJB is where the transactional interaction with the database happens.
JBI has no concept of the three tiers the way app servers do (servlet = presentation tier, session bean = application logic tier, EJB = database server tier). JBI is a container designed to support plug and play relationships between integration components and messaging systems, instead. While the EJB is designed for application developers, the JBI is designed for software vendors.
You can use an app server for integration, just like you can use a TP monitor, but it isn’t designed for that, and it takes a lot more coding.
That’s why EAI solutions were originally developed as distinct from TP monitors and became popular for a while. There’s a big difference between technology designed to support online transactions against a shared database and technology designed to share data across disparate applications (which may or may not be online, transactional, off the shelf, or even in the same part of the world).
If you take the single container argument to its logical conclusion you end up with a single software system trying to meet both OLTP and integration requirements. While this is possible it does not seem practical. Costs and time to market can be significantly reduced using software systems specialized toward particular types of requirements.
Some of the biggest new trends at Microsoft (of which Don is certainly aware) are software factories and domain specific languages (DSL). This is very innovative work with significant potential. A major concept of DSL is that a single general purpose language is never going to be the best solution for all jobs.
The industry would benefit from the adoption of JBI (or something similar) since it promotes a best of breed approach to integration. IBM is unlikely to support that, of course, since they want to be your single software supplier. But for smaller vendors specializing in business process management, transaction management, security, transformation, or messaging for that matter, a container model oriented toward integration requirements makes it easier to combine their software with other vendors’ software.
Where BEA is in all of this I’m not sure but it may be that they think they will be competing to become your single supplier as well, although the AquaLogic announcement makes it seem as if they are starting to move away from that idea.
JBI also makes perfect sense for open source, by the way, which may (come to think of it) contribute to some of the scepticism. Open source projects benefit from the ability to divide up work using a plug in architecture. This is one of the features of the Celtix project, and one of the reasons Celtix supports JBI in addition to our own plug in model.
The jury may still be out on whether or not JBI will succeed, and if it does whether it will achieve the level of adoption that EJB has, but at Java One last week the industry saw JBI off to a good start.
UPDATE/Correction July 11: Pointer to Steve Vinoski’s IEEE column on JBI, highly recommended background reading on JBI. This is actually what Don Box was referencing.