Lessons from BEA eWorld 2004
Last week I blogged on my day-to-day experiences at BEA eWorld. Now I am ready to reflect on what I learned.
Its easy to get caught up in the spirit of the moment when you attend a conference. The shiny baubles, the bells and whistles, the inspired evangelists and the cunning pitchmen all contribute to a pleasant stupor where all is well and no problem is without a solution. Fortunately, all conferences eventually end. You return to the reality of day-to-day tasks of your job and to your peers. Im back home from BEA eWorld, and can now reflect on what I learned there, and begin to integrate those lessons into my game plan for the future.
Here are a few of the things that I will want to keep:
Loose Coupling is more important then Performance
Services with language neutral XML interfaces are much more widely reusable then services with language specific interfaces. Its easier for Java programmers to pass around Java objects instead of XML documents, but that choice limits who can use the service.
The community needs to focus on efforts to overcome the performance problems of XML interfaces. One such effort is Sun Microsystems Fast Web Services initiative. Efforts to stray from language neutrality for the sake of performance (like BPELJ) should be eyed with caution.
It is time for Business Developers to adopt Higher-Level IDEs (like WebLogic Workshop)
We are not quite at the Stop using Assembly Language and Start Using a Compiler stage, but we are getting very close. All the vendors provide productivity tools that generate the tedious code, leaving the developers to focus on logic. Its time to start using these tools, rather then continuing to write code with text editors (hence my comment about Compilers vs. Assemblers).
I was surprised that I didnt hear talk at the conference about the massive changes that EJB 3.0 suggests, but from the perspective of SOA it really doesnt matter. There was almost no mention of EJBs, persistence mechanisms, XML parsers, or any other implementation detail. The focus was at higher levels that abstract away the details that most of us have focused on.
I am not yet 100% comfortable using an IDE like WebLogic Workshop to develop my applications, but the writing is on the wall. The constraints and shortcomings of the higher-level IDEs will soon be offset by the increased productivity that they offer.
Productivity Tools will impact the adoption of Open Source projects
BEA developed the Beehive components to enable the creation of WebLogic Workshop. The Beehive enhancements to Struts and to Java Beans make it easier to build Productivity Tools. Now that Beehive is Open Sourced, applications written using WebLogic Workshop can be deployed on Tomcat.
The existence of good (and free) tools that make Beehive programmers productive will discourage the adoption of competing Open Source projects (such as the Spring Web Framework). Productivity tools drive adoption, the quality of the tools that support the project are as important as the quality of the project. If your Open Source project doesnt have good IDE support (like an Eclipse plugin), it is less likely that it will be widely adopted.
From a wider perspective, productivity drives adoption at many levels. The cost of a J2EE server is not that big a consideration over the long run; the cost of deploying and maintaining an application dwarfs the cost of the app server. The free price of JBoss or Geronimo will not matter if deployment or management is complicated. Businesses will continue to pay for WebLogic or Websphere if they perceive them as easier to manage. As we move to applications that incorporate many services, and the services are distributed across many servers, productivity and management tools will become even more important.
BEA has some really great employees
Didnt I mention that before?