This article represents my thoughts about the viability of BroadVision's new release and the market that they seem to be courting.

BroadVision has probably taken more flak about this issue than any other in recent years, general griping about their product aside of course! In response to market pressure, they added limited Java functionality in version 5.0: through some fairly ugly syntax, you could instantiate Java objects and create references to classes to access static methods and members. It made it possible to integrate external Java code into BroadVision web sites or to use Java to integrate external systems. It was a step in the right direction.

The boundary between the server-side JavaScript and Java is a thick one and therefore relatively expensive. It was not meant to encourage people to write JSP (Java Server Pages) instead of JSP (JavaScript Pages) but it was useful enough. I found it very useful while working on Office Furniture's web site to integrate a complex shipping engine which was written in Java as an independent RMI server application. An RMI client class was written that could be instantiated and manipulated in a BroadVision page.

There was one big drawback: you couldn't call out from the Java code to BroadVision's internal APIs to extend or reuse the standard components. Unless you wanted to write a lot of JNI code. Extending BroadVision's component framework still meant C++ code to most people. The criticism began to appear that BroadVision had not provided 'real' Java support (in much the same way that they haven't provided real XML support either... but that's a whole new article!).

BroadVision have worked hard to respond to this latest criticism. They signed an agreement with BEA Systems to provide an integration with the latter's WebLogic application server product and thus provide a full J2EE compliant environment. Whatever actual form this takes will be the cornerstone of version 6.0, due to ship at the end of March 2001. BroadVision have an interesting white paper on their web site (in their Extranet so you need a login) that documents their Java architecture for version 6.0. The new release will support JSP (Java Server Pages), Servlets and EJBs. It will be a hybrid environment, supporting multiple idioms.

What the new version will also provide is a complete Java API to BroadVision's component API. Perhaps they've built all the necessary JNI stubs or perhaps they've achieved this through other means. Either way, this will resolve the criticism leveled at version 5.0 that you can't extend the standard framework easily in Java.

This all sounds like it will make BroadVision very attractive to Java developers. It also opens up, to the current developer community, the possibility of using Java to create web sites with BroadVision. Logical? Maybe. But it somehow doesn't ring true for me.

Let's first consider the scenario of an existing BroadVision development environment that now has the option to develop web applications in Java. What does this really offer? Many current BroadVision developers actually have very little real software development experience - BroadVision mostly requires only JavaScript, a vaguely object-based language. Most BroadVision developers are not really equipped to develop good Java software - you only have to look at the quality of the dialog on the bv-users mailing list to see how ill-equipped most of these developers are. Sure, there are some BroadVision developers who can cut it in Java - they're already frustrated by having to work with BroadVision in the first place - but they are in a minority. When BroadVision required extensive C++, your development team were generally 'real' programmers but BroadVision changed the playing field with version 4.0: it 'dumbed down' the whole process for building BroadVision sites and it impacted the make-up of your team so that you no longer needed expensive 'real' programmers.

Assuming that you are blessed with a good development team (lucky you!), you should expect to see a shift from a JavaScript site to a Java site over a period of time as you rationalize your business logic into beans and transition JSP (JavaScript Pages) to JSP (Java Server Pages). After all, why else would BroadVision provide these features unless it expected people to take advantage of them? So there will come a time when... you have very little pure BroadVision code on your site. How much of BroadVision's core functionality will you continue to use? How tempting will it be to take your new JSP, Servlet, EJB application that runs on BroadVision's J2EE environment and migrate it to a much cheaper, much less proprietary application server?

Now let's consider the other scenario, that BroadVision is hoping to lure people who would otherwise build web sites with JSP, Servlet, EJB technology over to BroadVision. Where is the appeal? You have an existing site that works, that your developers understand, based on open standards. BroadVision want you to buy a very expensive product that swallows up your current technology (as if it were an add-on) so that you can 'enhance' your site with proprietary technology. I don't think so.

Or perhaps you don't have a web site yet but you happen to have good Java developers (perhaps you have already built your backend infrastructure with Java and are just beginning to figure out your web strategy?). What would you chose as your web site development environment? Would it be a complex, expensive, proprietary application system or would it be a standard, cheap, open application server? Let me think about that for two seconds...

If you really want a simple-to-build system on top of a J2EE server, why not buy ColdFusion MX and write CFML pages you can run on JRun, WebLogic and WebSphere?

I can't see any reason for existing Java shops to move to BroadVision even with its new Java-friendly architecture. Such shops already know how to build personalized e-commerce web sites in Java - they've already solved the problems that BroadVision purports to solve. I'm willing to be corrected but I don't think that's BroadVision's intended market.

Most existing BroadVision shops are locked into BroadVision - they've made a huge investment, both in the software itself and in the development of their web site. That investment is usually (tens of) millions of dollars. It's very hard to justify writing off that investment and moving to a new platform although a few of BroadVision's customers have done that - most spectacularly American Airlines who switched to ATG's Dynamo (see my comparison of Dynamo 4.0 to BroadVision 3.0 for more insight on this). Imagine if you had a way to gradually transition to a new platform, systematically rewriting parts of your web site application to utilize the new platform without actually having to buy that new platform. Imagine if your current - proprietary - vendor provided a natural migration path for you to move to an open standard platform. Sounds unlikely, but that is what BroadVision are doing for you: by adding support for JSP (Java Server Pages), Servlets and EJBs, they are providing a path to open standards.

Of course, what BroadVision are banking on is that their user base is locked in because developers are relying so heavily on BroadVision's rich functionality that it would be prohibitive to rewrite applications for the new open platform. It's an interesting wager. My experience with BroadVision and web sites is that very, very few sites actually take advantage of enough of BroadVision's feature set for this to be much of an issue.

The J2EE market is very competitive already with Dynamo, iPlanet, JRun, Tomcat, WebLogic, WebSphere... Prices vary from keen to free. Java developers are relatively numerous, certainly far more so than BroadVision developers. It's a very tempting platform.

I think BroadVision runs a grave risk that by providing a migration path to J2EE, it will ultimately reduce its market share in two ways:

1. Disgruntled developers will be able to drive their teams away from BroadVision incrementally, making the transition to a cheaper J2EE environment much more attractive.
2. By competing in the J2EE arena, BroadVision will cheapen its own appeal, trying to justify its high price tag solely on the basis of what it adds to the J2EE platform.