I love the nifty features, but...
Recently I attended a BEA presentation for their upgraded WebLogic Workshop.
I really think that BEA is on the right track for business application developers (think Visual Basic for Java). Many of the intricacies of developing a J2EE multi-tiered application are hidden from the user, and much of the tedium of configuration files and EJB interfaces has been eliminated. The development environment, although by no means perfect, makes great strides towards a declarative environment where the user can concentrate on what needs to be done, rather then on how it should be done. I particularly like the page flow support, both for the ease of setting up the underlying actions, and for the graphical representation that makes it so much easier for me to communicate with my business owners.
That said I am in a quandary on whether or not to recommend that my company adopt the tool. Applications built by WebLogic Workshop can only be deployed on WebLogic servers. My company is not actively planning to move to another app-server, but WLS-only applications certainly fly in the face of the “write once, run anywhere” or even the more realistic “write once, test everywhere” mantra of Java. To their credit, BEA recognizes this as a problem, and they are moving towards making it at least possible for an application to be “ported” to a third-party app-server, but for the moment, you’re stuck.
Portability really takes a knock on the head when offerings from multiple vendors are stitched together in those areas of J2EE that are outside of the specification. For example, the use of Oracle’s TopLink as the Entity Bean CMP mechanism for either BEA’s WebLogic or IBM’s WebSphere is strictly constrained to specific releases and service pack levels. Forget portability between Vendors, when using products such as these you might not even be able to apply a sevice pack unless multiple vendors coordinate their release activities. Not a good thing (a lesson I have learned first-hand).
In the case of WebLogic Workshop, BEA wants to make the development of J2EE applications simpler to combat the dreaded .Net threat. To make application creation simpler, they've built their development studio on top of what I would call Struts and XDoclet on steroids with support for code generation bundled in the application server itself.
Call me trusting, but I really don't think the intention here was to force vendor lock in. BEA has already donated the
XmlBeans portions of this technology to Apache, and in private conversations with BEA employees they seem pretty commited to opening up whatever they can. I think this is simply a case where the "best" solution required a non-portable implementation. Witness BEA's participation with
for examples where they are championing standards to make this sort of functionality ubiquitous.
My recommendation to vendors who take this route is to be proactive and "publish the pitfalls". Clearly delineate the non-portable features and go one step further, develop a game plan for a portable alternative.
Returning to WebLogic Workshop... Much of the functionality is embeded by the IDE into the source code by using XDoclet style tags. In the WLS app server, explosion of these tags to the relevent classes is transparently painless.
My suggestion to BEA is to develop a (possibly painful) process to parse the tags, generate portable classes, and package the application for deployment on a "generic" J2EE certified app server. Publish this process and provide a licenseable run time, and I will be satisfied.
Portable does not have to mean free, and portable does not have to mean painless. It is not a crime to create something that works best within a proprietary environment, but I will have to hesitate to recommend it unless it can be made to work on any certified J2EE app server.