Over the past several months, I've had the opportunity to interface with several BEA WebLogic project teams and ask how they do their development. One question I usually bring up, mainly out of curiosity, is whether or not they decided to use BEA WebLogic Workshop as part of their overall development strategy. As you may already know, Workshop is designed to streamline the overall development effort and can provide substantial improvements in programmer productivity along with streamlining the configuration and deployment process. In theory, the decision to use Workshop as the IDE of choice for BEA WebLogic development should be a no-brainer. But what is really happening out in the field?

Well, the result of my impromptu, and albeit unscientific, survey shows something quite unexpected. In one case, the project team was involved in developing a portal-like application that would be deployed to a WebLogic 8.1 application server. Okay, you would think using BEA WebLogic Portal along with the Java Page Flow designer tool, both integrated quite nicely in Workshop, would be the logical choice. To my surprise, the architects decided to develop the application using Struts and were not planning to use WebLogic Portal at all. Their reasons were as follows. They wanted a pure J2EE design with the ability to deploy the application to any J2EE-compliant Java application server, including Tomcat. I guess they weren't aware that you aren't locked into using the BEA WebLogic Server for Workshop-developed front-end applications.

In another encounter with a WebLogic development team, I found a similar shying away from using Workshop, but for other reasons. In this case, the development team was involved more on the back end with message processing using Web services and EJB components (including message-driven beans). The reasons this time had to do with the performance and overall stability of the Workshop IDE itself. According to one of the developers, it has nice time-saving features, but it tends to be a resource hog, and bogs the system down. It also tends to freeze up from time to time. Consequentially, the development team is using JBuilder instead.

So, what's going on here? Did I just happen to stumble on a few development teams who aren't completely sold on the full capabilities of the BEA WebLogic product line, or is it more of a trend? Pondering the situation, I thought of a few reasons that would explain it. Since J2EE and associated technologies like Web services are based on open standards, each development team is ultimately free to pick and choose what they feel would be the best combination of tools and design techniques to get the job done. I would think in a number of cases development teams will choose solutions they are familiar with and that have a proven track record. An architect may also decide to go with an open source solution, like the team using Struts, because of the unique and robust design brought on by the contributions from the best and the brightest in the industry. Now, if this were Microsoft, there wouldn't be too many options when it comes to development. You basically use Visual Studio along with any plug-ins you can find, and that's it. In the J2EE world, you can get by with a simple text editor and a set of JAR files downloaded from Apache. Opposite ends of the spectrum.

I hope in the future more development teams will catch on and discover the robust capabilities of BEA WebLogic Workshop and that BEA will improve Workshop efficiency in upcoming releases so that developers with less than stellar workstations can make use of it.