| By Sam Pullara |
Article Rating: |
|
| June 20, 2002 12:00 AM EDT |
Reads: |
9,658 |
EJBs have always been the best way to ensure that your applications were portable and would leverage all the optimizations of the J2EE server. Now they are also easy to build. With the release of WebLogic Platform 7.0, you can create EJBs in record time. At the center of this revolution is Container Managed Persistence 2.0, which allows WebLogic to build tools that remove the layers from EJB development. Relations, the standard EJB query language, and JavaBean-like properties all contribute to this new age. Since EJB 1.0 was introduced it's had a rap as a difficult, complex technology to implement - probably for good reason. This release of WebLogic is targeted at changing that. Going forward there will be more and more tools to help you develop EJBs painlessly and efficiently.
The biggest tool for the developer is EJBGen. EJBGen gives you the power to create an entire EJB, including home and remote (and/or local) interfaces and deployment descriptors, by creating a single implementation file marked up with special JavaDoc tags. This drastically increases the maintainability of the system and makes it simple for developers to quickly generate the EJBs needed for a project. Listing 1 demonstrates this for you.
The relatively small amount of source code and description translates directly into all the pieces that make up an EJB component JAR. To generate the code, simply use EJBGen, which runs as a JavaDoc doclet:
javadoc -doclet weblogic.tools.ejbgen.EJBGen -d targetDir FooEJB.java
In the targetDir you'll find the Java source and the deployment descriptors for all the components that make up your EJB. Compile and JAR the files to deploy to the server. It's really as simple as that.
WebLogic Builder is the biggest time-saving tool if you've already written your EJBs and just need to configure and deploy them. The Builder tool will crack open .jar, .ear, and .war files or work on open directory structures to configure the deployment descriptors for all your components. Not only that, using an internal tool called DDInit (we provide Ant tasks to run it outside the Builder), you can take loose classes and turn them into components.
Let's say you don't want to use EJBGen or are given a set of interfaces for the EJB. Simply write the implementation beans compile, and point the Builder at your directory. Not only will it discover what kinds of beans you have, it will also generate defaults for all the deployment descriptors, including all the relations between beans. It's that simple. With a bean that is mostly for data, you can get away with writing as little as a couple of interfaces and one abstract implementation class with no methods!
There are also a couple of tools in the works that can save you time. Expect to see SQL2EJB and ReverseEJBGen in a follow-on release. SQL2EJB does what you might imagine: given a database with a reasonable schema (it's best if it has all of its foreign and primary keys properly marked), it will generate a set of EJBGen source classes that can then be EJBGen'd, compiled, and deployed to a server. Even better, since WebLogic supports dynamic table creation, you can deploy it to another database that doesn't already have the schema for testing or development purposes. This is the type of tool that has only become reasonable with the introduction of relations to the EJB specification. ReverseEJBGen does what you might imagine: given an EJB component, or set of components, it will generate an EJBGen source file that includes all the information found in the deployment descriptors. It will consolidate all those disparate files down to one file that is the final word on an EJB. Also, it lets you use the Builder tool to edit a deployed EJBGen'd component, change the deployment descriptors, and then convert back to the original format.
Expect to see these types of tools integrated with products like WebLogic Builder to make developing products for the WebLogic Platform as simple as possible.
