The future of the ESB

Loek Bakker's weblog: Understanding the future of the ESB: "It's so simple: ultimately, when all the parts have the ability to work together (i.e.: they all can communicate through messages, which will be the bus), the role of the ESB will be like the role of DNS for the Internet: addressing and routing. Nothing more, nothing less."

I suggest that he overstates the role of DNS. It doesn't really do routing. That is the job of routers and switches.

I generally agree that the capability we want for the end-points to do the processing, so that the actually communicaiton flow is point-to-point. But that point-to-point connectivity is not exposed to the application. I want to be able to modify application behaviours and policies as if it all went through a central hub, but don't want to actaully make a network hop and who-knows-how-many context switches in order to perform any routings and transformations.

Using DNS as an example, browsers look-up (resolve) domain names only occasionally, and then direct their traffic to the end-point directly. In some cases the end-point may do some virtualization and wrokload management at the far end, but all of that is of no consequence to the requestor. This is the way the applications should work with an ESB.

Tim Bray On PHP

"Spaghetti SQL wrapped in spaghetti PHP wrapped in spaghetti HTML" Ouch. Tim certainly has an opinion here. I question where this has anything to do with PHP. One could certainly create the same kind of pasta using JSP and is the way many ASP sites look inside. I suggest the difference is not the language, but the focus of the developer.

Dan Bricklin's wikiCalc

Dan was the original author of VisiCalc. He is at it again with wikicalc. An online spreadsheet. I like the idea, the alpha code is somewhat functional, but needs polish. Great work Dan.
Software Garden Products: wikiCalc Program: "The wikiCalc program is a web authoring tool for pages that include data that is more than just unformatted prose. It combines some of the ease of authoring and multi-person editing of a wiki with the familiar visual formatting and data organizing metaphor of a spreadsheet. "

Designing Software for Your Market

One thing that bothers me is the way that many IT shops go about desginin infrastructure or shared services. The scenario I often see is that rather than defining who/what/where the market is and providing a solution that addresses that need, the approach is more often "How can I convince those people to use what I have or want to build".

To me the difference is the lack of a product development team (in the marketing sense). Once that is in place then they must work in conjunction with engineering.

It seems that even Microsoft sees the need to improve this model within their own organization. In the course of developing the next release of Exchange, the two departments wrote a book together. Bink.nu: "It encompasses everything from the market outlook to the perceived value of possible features to potential customers. At its essence, the book serves as a contract between marketing and engineering, describing what goes in and what stays out of the software."

This seems like an approach that more should model.

Can Google help Firefox?

Steven J. Vaughan-Nichols in his artcile Firefox Is Heading Towards Trouble said, "If the Mozilla Foundation and Firefox friends like Google don't start spending money—right now—to hire more programmers, more project managers and more servers, it won't matter how many ads in the New York Times Firefox supporters take out, Firefox will have already reached its high tide of popularity and we can only wait for the ebb to begin." I think he has a good point. There has been much speculation about Google and the gBrowser. What there are up to is certainly not clear. But it seems a pretty good bet that they are doing something with the firefox code base. Although this may dilute the market share for pure firefox, I suspect it would help a lot with code quality, and may even server capacity.

A good overview about the benefits of workflow

I ran across this short note from George Parapadakis about workflow benefits. I thought it was a good summary. And You Know - Of Course What Workflow Is

Software Factories

I have been reading a bit about software factories, and also recently attended a presentation by Jack Greenfield (author of Software Factories: Assembling Applications with Patterns, Models, and Tools). Many interesting ideas.

The first thing to keep in mind, is that there is a war going on. The combatants are familiar: Microsoft and a few friends on one side, eveybody else on the other. As somebody once said, "the first casualty of war is truth".

One of the main principles of the software factory idea from Microsoft is that of "Domain Specific Languages". Fankly I am having trouble accepting the idea as useful for large scale developments in large development shops. I can see how it might work well with a team of A-Team programmers. But when dealing with 9-5 programmers - those with lives away from programming, I think having a dozen DSLs within the organization will be too much to handle. These DSLs will be on top of the general programming languages we already have. At least for the next 10 years. The average Joe doesn't want to learn that much.

On the other hand, I can see the counter argument. As Grady Booch points out, " In many cases, the semantics of the UML are pretty close to what you need" (December 3, 2004), UML is not exactly what you need - just close. There is often an impendance mismatch - which means you lose power, perhaps introducing distortion. The DSL approach says create exatcly what you need and use that - the mismatch is avoided.

The difficulty I have with that is that it may just be moving the problem. Now the programmer has to deal with a dozen different interfaces (DSLs). Is the programmer more likely to make a mistake in the coding? Would there be 'Whoops - that would have been the way to code it using DSL#34, but in DSL#93 it is done this way, becuase of what we learned when we used to use DSL#67. "

Grady also said, "we do disagree with Microsoft's rejection of the UML in favor of proprietary domain-specific languages". At first is wondered from where he pulled the word "proprietary". That word to me usually implies 'closed', 'owned', 'not generally available'. I thought these DSLs could be open, public, generally available. But then when I consider the number of them that could exist, I realized that proprietary is not so wrong.

Enough for now. This Software Factories versus MDD (or MDA) battle will be ongoing for years. I don't either will win, but both will declare victory.

Java over-engineered?

I don't know the name of the author of this post, but he (or she) has some interesting observations. About two-thirds of the way down the post he has a list of things that are bad about J2EE - in comparison to .NET.
What I think is most interesting is that I think he is comparing typical solutions built on those technologies rather than J2EE and .NET. Ya I know - semantics.
Anyhow, he goes on to blame this on "cross-platform compromises" and "textbook OOP".

Hmmm.

In the many commercial grade J2EE code bases that I am familiar with (high volume web banking and brokerage web sites), I can't say that we have made many cross-platform compromises - very few in fact. But when we do, we usually encapsulate the dependency, and put a factory in front of it. This add layers and makes the code more opaque. That is certainly true. But, as I said, we don't do that very often. Would stored procedures made the code simpler? I don't think that would be true either. In our case, it would add another layer!

What about textbook OOP? Is that a bad thing? Must be. I am wondering if what is observed is a tendency to make things overly abstract, overly decoupled - perhaps even overly reusable? The motivation is good - planning for change. It is often done with a view to save money in the future, without looking at the ROI. I think that too often we spend two dollars today to save a dollar next year.

.NET does not have any redeeming features that will save it from the same fate - (except maybe an army of VB6 programmers who haven't seen an OOP textbook!). Given time it will build it's own empires. Perhaps with the help of Microsoft! Chris Anderson and Miguel de Icaza exchanged some volleys about the complexity of Avalon see here and here.

PHP versus Java

Here is an intersting tidbit burried in a post about Friendster's switch from Java to PHP. As usual the debate tends to feed on how you build the application rather than the fundamentals of the underlying technologies.

Of particular interest was this quote. in the journal "ACM SIGMETRICS Performance Evaluation Review, Volume 31 Issue 3" there was an article called "A performance comparison of dynamic Web technologies" where Perl, Java server technolgy (also tomcat) and Perl was benchmarked in a labratory environment. It was concluded that Serverside Java outpreformed PHP and Perl by a factor 8. The abstract also states, In general, our results show that Java server technologies typically outperform both Perl and PHP for dynamic content generation, though performance under overload conditions can be erratic for some implementations.

Gartner says WSDL is a critical standard

A recent Gartner Research Report, entitled 'Consider WSDL a Critical Standard'. Reinforced their opinion that WSDL and web services are a fundamental component to successful SOA. Their bottom line is use WSDL or find your self alone in an obscure corner of the industry.

More on Rich Clients...

The IBM workplace technology seems to be gaining some traction. Stephen O'grady has written up an analysis of what some other vendors are proposing to do on top of it.

Actuate's plans are intersting for two reasons: 1)it is an open source business intelligence project, 2) it is built on Eclipse.

Rich Client Wars

Much is being written today about the future of the Rich Client application versus the browser applicaiton. One side says you can't get a good user experience out of a browser application, and you can't get sub-second response time from it either.

There are those at the other extreme as well. The say there is nothing the browser can't do and notuing it shouldn't do.

I suggest that truth lies in the middle. I also think that the middle will shift over time - towards the browser side.

This posting at looselycoupled, by Phil Wainewright, talks about how the Yahoo purchase of Oddpost is an indicator of things to come - delivery of rich user interfaces within the browser. His main point is that Microsoft's Avalon is the wrong direction for the company to be taking.

He may be right. Time will tell. I think Microsoft has surely thought about that. I think they are hedging their bets - make the borwser irrelevant. Where you really wnat to work is in Microsoft Office (with a healthy serving of Sharepoint Portal Server and BizTalk server to help it out). Take a look at their Office Information Bridge. If Microsoft could get us to live in a purely MS-Office world, then the browser becomes irrelevant, as does Google, Yahoo, IBM, Sun, Java and Linux. Apple would still be around - after all it does run Office, and the Microsoft marketing department needs Macs to publish their material (look at the document properties for their PDFs - you'll often see something like "Mac OS X 10.3.4 Quartz PDFContext")!

Microsoft Project Competitor Released under Open Source License

A company called Niku previously sold a product called workbench that was a serious competitor to Microsoft's Project. How serious? It sold for $10,000 a seat according to this InformationWeek report.

Despite the price tag, it was not a major revenue contributor, so Niku decided to release most of the code to the community under a Mozilla license. The product contains a few licensed components from others that cannot be released, as well, they will not release the source for their scheduling algorithm - which they may patent. They will distribute the binary for that piece. You can find out more at the web site.

Steve Ballmer commented in his corporate email that "Microsoft needs to do a better job of convincing customers that the latest versions of its products are worth having" (clipped from cnet). OpenWorkbench for free, or Microsoft Project for US$600 - Microsoft has its work cut out for it!

Interesting Items From Apple's World Wide Developer Conference

I don't own a Mac. Somedays I wish I did. This week more than most. I would like to win the lottery too!

So what is so attractive this week. Well, first off there is the dual processor 2.5Ghz G5. It's not new. But it is what goes with it that is interesting. Like the 30 inch Cinema displays! Gorgeous. A pair of those would be ever so sweet.

What else? Spotlight. This is Apple's search technology that will be part of the Tiger release of OsX. Think of it as Google for your desktop. The demonstration at the conference was very impressive. Speed was excellent. But I think effectiveness it the more important aspect. With spotlight you can save a search query and have it re-executed any time. Because of its speed, one should regret opening such a folder. I know that when I do a search on my windows machine, I plan on it taking some time.

Finally there is Rendevous. This might come in handy within our branch environment for application deployments with minimal configuration.

These are each very cool. Good work Apple.

Loose Lips Sink Ships?

Bruce Schneier recently wrote about the keeping of secrets in the world of international espionage. He discussed the American supposed cracking of Iranian encryption, and made the point that keeping secret that you know other people secrets can be very valuable.

During World War II, the Japanese made huge balloon bombs that they release into the air to be carried to North America. The intent was to start fires and kill people. It was of some success. However, 'In May 1947, the New York Times wrote "Japan was kept in the dark about the fate of the fantastic balloon bombs because North Americans proved during the war that they could keep their mouths shut. To their silence is credited the failure of the enemy's campaign."'

Somebody once said about music that the anybody can play the notes, but the rests make the music. Perhaps something similar can be said about security and silence.

Smart Dust, Even Smarter Vacuums?

In case you haven't read about it, there is a technology called Smart Dust - glitter sized network computing devices that can do all sorts of cool and scary things.

So what happens after we produce billions of Smart Dust devices and spread them pervasively (invasively) throughout our world?

Perhaps this could spawn add-on features for our Robot vacuum cleaners?

Not only could your smart vacuum cleaner take care of regular dust, it could seek out smart dust as well? And then what?

Do we need virus scanners for our smart dust? Can we run Norton anti-virus on our Roombas in order to separate 'good' smart dust from 'bad'? Maybe we will need a Smart Dust recycling program?

A New BEA Emerges From The Beehive

A few days ago i suggested that BeeHive was an important development to track. The META Group has published a report that is in agreement.

You need to be a customer to access the article. http://www.metagroup.com/us/displayArticle.do?oid=48577

California Passes Anti-Gmail Bill - Is this good

I hate banner ads. Why? Mainly since they are such a waste of screen real estate. They are irrelevant. I click on a banner ad very rarely (yearly?), and when I do, it is usually from a web site meant for a targeted community, therefore the ads are most relevant.

I have been using GMail for a month now. The text ads that Google has been placing on the right hand side have been very relevant. I find myself actaully reading the ads, and clicking thru many times a week. Are they invading my privacy? I don't think so - since I agreed to it.

If there must be ads on the web sites I use, then I prefer it the GMail way.

BEA donates Beehive to Apache

In October 2003, Crossvale (a research firm) published a report entitled “A Study in Enterprise Development Productivity”, subtitle “Comparing Implementation Approaches with J2EE API coding vs. Using a J2EE Development Framework”.

This report has been widely circulated by BEA as evidence that WebLogic is better than Websphere. However, in reviewing the report I found that they were really comparing the benefits of using advanced tooling to generate code rather than coding major portions by hand.

My conclusion was that BEA's WLW (WebLogic Workshop) may offer some improvements in our project delivery time, it also required a significant change in our infrastructure, and more importantly would require us to abandon our vendor neutral position.

On May 19 of this year, BEA announced that portions of WLW will be released to the open source community via Apache. The first code releases would be available later this year. It is a little early to gage the importance of this development. But given good market acceptance, this may be an importance addition to our tool set.

References
The Crossvale report
BEA Beehive Press Release
ZDNet News article

First Impressions of Gmail

I have started using my new Google mail account. So far I like it. The interface is clean and simple. But the thing that impresses me the most is it's speed. It is very fast. Much faster than Yahoo, Faster than my corporate Notes client as well.
I like the label approach to filing things, rather than the folder concept.

Good work, Google.