Whither BEA?

I've had this feeling for a while now. It's more a question of when than if. When will BEA open-source WebLogic?

Consider the market. WebLogic remains one of the technically best J2EE servers available, but the capabilities of J2EE servers have rapidly been commoditised. For those who want adequate functionality at an unbeatable price, there's Open Source JBoss. For those who want the guarantee of commercial support, there's JBoss with commercial support. For those whose paranoia drives them to pay any price for the reassurance of a large corporation behind their app server, there's always IBM's WebSphere. And now with Apache's Geronimo getting ready to roll, the market is hotting up, even in the Open Source segment.

Who in their right mind will buy WebLogic anymore?

I'm sure this idea has been kicking around at BEA for a while, but as long as people were still buying and paying for WebLogic licences, there wasn't a strong reason to consider it seriously. Now that the license market is shrinking, BEA will have to do something dramatic to stay relevant.

Open-source WebLogic - that's what I think they will have to do. They'll have to make their money through support and professional services. It may not buy as many Ferraris, but continuing with the old model will have them walking to work at the current rate, assuming there is some work left. They really have no choice.

I'm beginning to think the proprietary software model is itself a fly-by-night model. Make your money on licensing while you can, because the window closes as soon as Open Source hits the market. Move on to the next segment undiscovered by Open Source and milk it for all it's worth while that window is open, etc.

[I also think Sun will Open Source the Java VM, tools and core libraries this year, but that's another story.]

Software Patents: The giant fled at a mouse's roar, - or did he?

The defeat of the despicable Computer Implemented Inventions Directive (better known as the Software Patents bill) in the European parliament is undoubtedly cause for celebration. Initially, I was overjoyed to see the margin of the defeat: 648-to-14! I couldn't believe that in this era of venal politicians, hundreds of MEPs (Members of the European Parliament) stood up to enormous pressure from corporate interests and did the right thing by the little guy.

Then I read this news item that appeared before the vote. In case the link evaporates, let me repeat the important points it made. It said that "European high-tech leaders [...] would prefer the European Parliament to scrap a controversial software patent law rather than confuse it with dozens of amendments when it votes later this week." The CEO of Alcatel said that "any departure from the Common Position would put at risk our future prosperity and significant numbers of jobs across Europe." Not to be outdone, a spokeswoman for Philips said the bill was best withdrawn before it was cluttered with amendments, otherwise "it will become legally confusing. We should either have a good bill, or no bill." The CEOs of Nokia, Siemens and Ericsson agreed. The Philips spokeswoman said that without a new bill, tech firms could continue to use the laws of individual European countries to protect their intellectual property.

American megacorporations Microsoft and IBM, among the strongest pro-patent lobbyists, were not asked for their opinion, and they remained discreetly silent.

So there you have it.

We really shouldn't be amazed about the 648-14 margin.

There were probably two types of MEPs out there who voted against the bill:

1. Those who opposed the bill because it would have stifled innovation in software, raised prices for consumers and given too much power to large corporations. (How many fingers do you think it will take to count these noble folk?)

2. Those who opposed the bill because the proposed amendments to it would have diluted its ability to stifle innovation in software, raise prices for consumers and give too much power to large corporations.

So when the good guys and the bad guys voted together to kill a bill, any wonder the result turned out to be a landslide?

I'm just intrigued by the 14 fellows who voted for the proposal. Who are these guys? Probably the back-bench dozers who didn't read the latest instructions from their corporate masters.

The bottom line is this: We didn't chase the bad guys away; they chose to withdraw, for now. But you can bet they'll be back. The potential profits from software patents are simply too high for them to abandon.

I propose a counter-attack: Apparently, the European Patent Office (EPO) has been granting software patents since the '80s and has to date granted 30,000 software patents! We should take the battle into the other camp by demanding that these patents be invalidated. Force the corporations to fight to hold onto what they plundered earlier, so they can't concentrate on fresh plunder.

All things considered, I guess the glass is half-full, after all. The efforts of thousands of people did stop the corporate campaign. It made their original goal unachievable, and forced them to abandon their current legislative assault on our freedom. But as Jefferson said, the price of freedom is eternal vigilance...

Understanding Microsoft's Indigo

Indigo has been in the news a fair bit lately, with the latest tidbit about Microsoft trying to block Open Source clones, in this case Mono. I don't have much sympathy for the Mono guys in any case. Trying to build Open Source versions of Microsoft technology is a lot like trying to make vegetarian dishes using meat substitutes - the whole idea is wrong-headed and limiting. I don't know why they even bother, and why they aren't spending their time more usefully in strengthening the true alternatives to Microsoft technology (Java/J2EE on Linux).

But let's leave the Mono crowd to stew in their own juices.

What *is* Indigo, anyway? Microsoft has a good introductory page describing the technology, but it wasn't good enough for me. I needed something to compare against. As an architect, I like to think of technology capabilities rather than products. And being Java-trained, I think of capabilities as being described by abstract interfaces rather than concrete implementations.

The closest that Microsoft's page came to describing Indigo in this way was the table comparing Indigo with earlier Microsoft technologies. It still wasn't good enough, so I created another table, expressing the same capabilities in more generic terms. Now I had a framework to compare not only the two generations of Microsoft technology, but also Java/J2EE equivalents.

Java technology relies on a single API standard with multiple independent implementations. Microsoft technology is generally represented by just a product, which blurs the distinction between the technology standard and its implementation. I've tried to cut through the confusion using the table below.

---

	Capability ->	Basic Web Services	Newer Web Services (WS-*)	Native Remoting	Messaging	Distributed Transactions
MS/ .NET	Standalone Implementation /Technology	ASMX	WSE (initial implementation of emerging standards)	.NET Remoting	MSMQ	Enterprise Services
	Integrated Implementation/Technology	Indigo (subsumes all the above technologies and products)
	Capability ->	Basic Web Services	Newer Web Services (WS-*)	Native Remoting	Messaging	Distributed Transactions
J2EE	Technology Standard (API)	* JSR 101 (XML-RPC) * JSR 109 (Enterprise Web Services - WS-I Basic Profile) * JSR 110 (WSDL manipulation) * JSR 155 (WS Security Assertions - SAML) * JSR 172 (Web Services for mobile clients)	* JSR 109 (WS-AtomicTransaction) * JSR 115 (WS-Trust) * JSR 181 (WS-MetaDataExchange) * JSR 183 (WS-Security) * JSR 208 (WS-Choreography) * JSR 261 (WS-Addressing) * JSR 265 (WS-Policy) * JSR 921 (WS-ReliableMessaging)	* RMI * RMI-over-IIOP (J2SE technology)	* JSR 914 (Java Message Service - JMS)	* JSR 907 (Java Transaction Architecture - JTA)
	Standalone Implementation	Apache Axis	(emerging)	David (academic implementation)	SwiftMQ, SonicMQ	SimpleJTA, Atomikos TransactionsTM
	Integrated Implementation	Any J2EE Container (WebSphere, Weblogic, JBoss, etc.)

As you can see, Indigo appears to be a major technical achievement when compared to the earlier generation of Microsoft technology, but it's old hat when compared to Java technology. The capabilities of Indigo have existed in J2EE for ages!

Yes, folks, it appears Microsoft has at last managed to implement a J2EE container ... minus EJB capability :-).

Move over LAMP, HILTS is here

While the corporate world is slowly gaining awareness of the LAMP stack and the more clued-on Open Source world is beginning to explore some new alternatives, a far better stack of Open Source technologies has quietly emerged.

I call it HILTS, which stands for Hibernate-Ingres-Linux-Tomcat-Spring. As a platform for running enterprise applications, I believe it represents the best that you can get for love or money.

We won't waste time arguing the strengths of Linux. Linux is the operating system of the future on every hardware platform imaginable, and when the Microsoft dazzle wears off in the near future, the rest of the world will see that too. Linux should absolutely be your OS platform of choice.

Ingres is quite simply the best Open Source database out there, bar none - better than Firebird (Interbase), better than PostgreSQL, better than MaxDB (formerly SAP DB). Notice that I don't consider MySQL worth mentioning as a competitor. Ingres has true enterprise-class features comparable to Oracle or Sybase, and the documentation that comes with it is awesome. It runs on several major OS platforms, unlike MS-SQLServer. If you want my opinion, move all your data to Ingres. That's the future. [Disclosure: I developed applications using commercial versions of Ingres a decade ago, and some bias may result from the long exposure.]

Tomcat is the quiet achiever of the Java server family. It's everywhere. Every development shop runs Tomcat somewhere, and many even run it in production. Virtually every J2EE IDE bundles Tomcat. Heck, JBoss bundles Tomcat. There was a time when I thought of Servlet/JSP engines as the Genie of the Ring when compared to EJB-capable app servers, which were the Genie of the Lamp. No longer. The existence of powerful frameworks like Spring, which I'll come to in a moment, means that enterprise-class applications can run quite comfortably on Tomcat. Tomcat should be your app server platform of choice.

I'll admit I've had mixed feelings about Hibernate. On the one hand, there's no doubt that it's a cool, capable O-R mapping product, excellent at what it does. On the other, it doesn't implement a standard API like JDO, which to my standards-craving mind, is heretical. Hibernate has often made me ponder the philosophical question of whether an Open Source product can ever be considered proprietary. [Update: There is now a persistence standard, the Java Persistence API. Hibernate will implement JPA, just like TopLink and OpenJPA (formerly Kodo). Interchangeability of implementations, however theoretical, satisfies me :-).]

Ideology aside, there is a technical limitation with Hibernate. Perhaps it isn't a true limitation, because it only becomes apparent when you try to use it for purposes beyond what it was designed for. Hibernate is great at implementing the persistence behaviour of POJOs (load/store), but it knows nothing about managing that behaviour. In other words, it can persist objects perfectly, but has no idea when to do it. It needs another component to say when.

That's the beef I have with people who talk about Hibernate by itself as a replacement for Entity Beans. Simpler and cleaner Hibernate may be, but EJBs have the notion of container callbacks driven by transaction boundaries, so they know when to initiate persistence as well as how to do it. Hibernate needs to be explicitly told to do so by a Session Bean, which means that the application developer must now take responsibility for something that an EJB container did as a matter of course. It's a step backwards from EJB to Hibernate.

Ah, but not when the Spring framework holds everything together! Spring is transaction-aware, and Spring can now drive Hibernate the way the EJB container used Session Beans' transaction boundaries to drive the persistence of Entity Beans.

Spring 1.2 now also introduces Message-Driven POJOs, and with the use of Quartz, provides a much nicer timer mechanism.

I believe that with Spring 1.2, the world now has a credible alternative to EJB technology. Spring should therefore be every developer's application framework of choice.

So there you go - the entire server-side stack for your next application! HILTS will do everything you need. "Everything" implies the application of the 90-10 rule, of course. There will still be the 10% for which you may need another solution, but HILTS will comfortably handle the other 90%.

[I was toying with the idea of calling this e-HILTS, just to tell you that you'll probably use Eclipse on the client side as your development tool of choice, but it sounds too dot-comish to be serious.]

HILTS is good. Stick it to .NET, guys! :-)

Intel's Apple deal - Why it had to happen

I disagree with Robert Cringely's analysis that the Apple/Intel deal is aimed at Microsoft. I think the move has a far simpler and more transparent objective - it's Intel's obligatory response to IBM's provocative assault on its turf.

IBM has been making a lot of noise lately about popularising the PowerPC and positioning it as a more generic processor that is suitable for consumer workstations as well as for servers. Needless to say, this is a head-on assault on Intel territory. Intel makes its biggest margins on server chips like Itanium and Xeon, but its biggest revenues come from workstation chips like Pentium IV and Celeron. AMD is already costing them sleep in this market. The last thing they want is another commodity chip here.

The AMD genie will not be so easy to put back in the bottle, but PowerPC can possibly be nipped in the bud (Nice mixing of metaphors there ;-).

Q. Who's the largest non-IBM user of PowerPC chips?
A. Apple.

So, strike a deal with Apple and pay them whatever it takes to move to an Intel hardware base. True, that's not much of a market share gain, - barely three percent, as Cringely points out. But the move is not so much about gaining market share as it is about stemming a future loss.

It's about positioning PowerPC where Intel wants it - as an IBM-only chip that no one else will touch. Once Apple is taken out of the picture, the only significant users of PowerPC will be IBM's own pSeries and iSeries divisions, which hardly counts as industry endorsement. HP will stay loyal to the Intel architecture, as will Dell. Acer and the second rung of OEMs will do likewise. Lenovo, not being a division of IBM, will see no market reason to sell PowerPC-based consumer workstations. As long as there is no PowerPC port of Windows, there is really no mass market there.

At a single stroke, Intel has put PowerPC back in its box. The only way PowerPC can ride back into the consumer workstation market is on the back of Linux, but that's a market where it already plays and where it has made virtually no headway against Intel and AMD.

Compared to the future revenues salvaged by stemming the advance of PowerPC, anything that the Apple deal must have cost Intel is probably chicken feed.