Development and deployment. These are the foci of the WebLogic Platform 7.0 release. Don't get me wrong, it's not like we haven't been working on the container itself, we still have J2EE 1.3 compliance and some really high ECPerf numbers. We have, though, released with the product three tools that try to simplify the development, deployment, and administration of WebLogic Server applications.
The first tool, WebLogic Workshop, can be thought of as a Visual Basiclike tool for building Web services, complete with a debugger for those services. It's standard, too underneath the Web service layer lies all the power of the J2EE stack that we've worked so hard to make fast, scalable, and reliable. Anyone who is familiar with WebLogic should bring up this tool and its tutorials, learn how to use it, and then show it to people who aren't yet convinced that Java is the way to go. You shouldn't have much trouble convincing them that this is an easy way to develop Web services.
For the developers out there who complained bitterly about losing the graphical deployment descriptor editor in 5.1, we've created a new tool called WebLogic Builder. This tool lets you edit deployment descriptors for J2EE application EARs, WARs, and EJB JARs in place and then redeploy those applications. It has built-in error checking and full coverage for all the descriptors. That should make it much easier and much less error-prone to deploy applications you've built or are porting to WebLogic from another system. It even auto-upgrades your existing older deployment descriptors to J2EE 1.3 so you don't have to change them by hand. With EJB 2.0 fully supported and standardized in this release, I think you'll find that all those complicated relations are much easier to manage inside Builder.
Maybe you're the kind of developer who scoffs at graphical tools and would really rather just use Emacs. Well, we have a productivity tool for you as well. WebLogic EJBGen lets you completely define your EJB implementation and its deployment information within a single file. Since the deployment information isn't separate from the implementation, it's much easier to make sure that all your relations are mapped and all your container-managed fields are hooked up. Using simple JavaDoc-like tags, you specify this information where it's needed, instead of trying to keep multiple files all in sync with each change.
And we haven't forgotten to include new enterprise-level features. One of the biggest additions (and my personal favorite, being a queuing kind of person) has to be the clustered queues and topics. Now you can build JMS-based applications without a single point of failure without having to do all the hard work yourself. The distributed topics and queues do almost all the work for you. Very few, if any, code changes will be needed to take advantage of this feature. Now building that huge scalable chat server is just a few JMS calls away!
On the security side, we've also built in support for entitlements and the full extension of the security stack in the server. This very sophisticated security system lets you precisely control access to resources beyond simple ACLs. Now you can stop people from using parts of a Web application based on the status of their account, or allow them to make changes to their account and reports while disallowing access to every other account. This new security system really gives you much tighter control over your J2EE components than the broad, coarse-grain, method/URI-level security built in.
One of the hardest features to get just right, so everyone is happy, is the deployment step. We think we've covered all the bases here. With our new two-phase cluster deployment with the option of using shared disks or your own replication instead of our internal file replicator, everyone should be able to reliably deploy their applications the way they want. For instance, if you want all your clustered servers to pick up .jsp- and servlet-class changes automatically, you can configure your application to reside on a shared disk and specify that the application shouldn't be staged by WebLogic. On the other hand, you might be running a really tight ship, where files can only change when the application is redeployed. So you tell WebLogic to do the staging and it will ensure that an application isn't deployed until all the clustered servers are prepared and then the change happens all at once across the cluster. The staging options are changeable at both the server and application level, so you don't have to be locked into one configuration.
Finally, the top-level domain configuration is no longer tied closely to where the WebLogic server itself is installed on the machine. This was a big problem for people who wanted to put the server code on a read-only disk while keeping all their configuration data, logs, applications, etc. on another part of the disk. Simple things like this go a long way toward ensuring the flexibility to deploy the WebLogic Platform in any IT environment.
Phew! That's a lot for you to digest. However, I think you'll find that the BEA WebLogic Platform is expanding in a good way. We're building the most complete, scalable, secure, reliable platform for developing J2EE-based applications. That's our mission.