This is the first of three articles about Integrating Sun’s Java Studio Creator into part of a larger development process within a business environment. This first part will cover the reasoning behind wanting to integrate creator into such a process, and the preparation work within other tools to create a Session EJB layer that will be suitable for consumption in Creator. Part 2 will cover the process of deploying the EJB layer to the Sun Application Server PE 8 embedded within Creator, and also creating and importing the EJB layer into Creator. Part 3 will give more details of what you do within Creator to harness the EJBs, including using serializable beans to transfer data and bind to Creator controls, and other strategies for transferring and binding data (collections, arrays, and so forth).
Since even before getting involved in the early access program for Sun’s Java Studio Creator (previously known as project Rave, and henceforth referred to as Creator for brevity) a little over a year ago, my focus has been very simple: replace Microsoft’s VB6 within our organization. The reasons for wanting to do this are pretty simple, first, VB6 is now deprecated in favor of .NET; second, most of our development work is already done in Java and has been for years; third, VB6 isn’t cross platform and increasingly our customers want Unix (or Linux) deployments of our software.
Originally, we sought to make the move by adopting a single tool to suit our needs. We looked at several, and eventually settled on Oracle’s JDeveloper (for reasons I will not go into here). We completed several projects using JDeveloper that were largely successful; however, there were a number of shortcomings, and it quickly became apparent that by removing VB6 from our tool chain, we had also lost something in our process.
Our VB6 usage was limited to creating graphical UIs, with the business logic, persistence, and other supporting functionality being written completely in Java. While this made life harder for communication between the two languages, one big advantage was that it made us design our UI/Business Logic interface with a great deal of care.
Using the ADF framework in JDeveloper for the whole application did allow us to create Web applications extremely quickly, but also imposed a number of costs on us. The main cost was in our design, we quickly found that in order to meet the tight deadlines, some of the functionality bled across architectural boundaries. Struts actions ended up containing business logic and even database table concerns, while special view objects were constructed at the lowest levels of the ADF just to satisfy the needs of a particular screen. The more View Objects we added at the low end, and functionality we added in the struts page actions, the harder the codebase became to unit test, maintain, and even understand.
Beyond this was the problem that our UI designers faced a far larger learning curve and an unfamiliar environment when creating the Web UI for the application. JDeveloper is a remarkably flexible tool, but as with all such tools, the flexibility comes at the price of simplicity.
The more I considered the problem, the more I saw that having separate tools for the UI and business logic layers was not a problem, but an advantage. Separate tools make it a lot easier to stay on the rails of good architecture even when facing tight deadlines. Furthermore, by concentrating on the UI creation task, Creator remains simple and well bounded, and the designers have worked at making it familiar to anyone who has used VB or .NET for UI design. The learning curve for UI designers is greatly reduced; this then frees the architects to concentrate on the Business Logic, Persistence, and other functionality.
I relate this because I suspect it will sound familiar to other architects, especially those who have developed using a fully integrated J2EE development environment. The speed of development in these tools often forces a compromise of design or architecture that, in the longer term, leads to trouble.
Given the experiences from previous projects, for this one I started to look into the possibility of using JDeveloper for its strengths (including easy persistence, easy EJB construction, and other strong J2EE support), and harnessing this work through a well-designed API that would then be consumed within Creator, and which would be used exclusively to design the API. By settling on the API at an early stage and stubbing it out with set return values, we were able to get the UI developers working on the screens even while the architects were constructing the API business logic and persistence. It also provided a perfect contact point for extensive unit and functionality testing.
As a part of the lead up to this project, I looked into a number of options for integrating the various tiers. Before I address these options, I will give a brief overview of the architecture, and in this case the technologies used for each.
Some notes on the architecture
The architecture described in the diagram is the architecture we are aiming for in future projects at NewEnergy Associates (the company I work for). You will notice the use of Stateless Session EJBs for the API rather than exposing Entity EJBs. Unlike some, I am not against the very notion of Entity EJBs, and I have seen that, with careful use, they can work well and not be the slow memory hogs so many describe them as. That said, I still find exposing an API based on Session Beans to be a better choice because it lets you expose the API you want, rather than one at least partially dictated by the underlying data storage.
Whether you choose to use Entity EJBs for the API, local references to Entity EJBs exposed to your session EJB API, or anything else you might want (Hibernate, JDO, and so on) is of course up to you, and that is the beauty of designing your own architecture. The main point here is that you should decide on an API layer that you will construct with whatever tools are currently to hand in your organization, or with new tools that you decide fit best. The API layer provides a focus for your design efforts, without getting bogged down in screen or Web page requirements, and also provides a perfect layer upon which to run extensive automated unit and functional tests.
Another option I will mention at this stage (and one that is poignant to us because we are using it on the current project I am working on) is avoiding the Session EJBs altogether. The reasons for doing this may vary, but in our case it is because the current customer is running Tomcat, and wishes to continue running Tomcat. Rather than mess with including a third-party EJB container, and because the project is not expected to scale to hundreds of users in this instance, we decided to stick to the same design principals (Persistence layer, business logic layer, API layer) but in this case the result of the API layer would be plain old jar files, which could then be included into Java Studio Creator as a library. With the exception of that one change, everything else remains the same.
For the rest of this article, however, I will proceed as if using the Session EJB layer. The use of plain old jars is pretty straightforward (hint, after creating and testing your jar files, in Creator right-click on the library references in the navigator pane and select Create New Library Reference. In the resulting dialog, add the jar(s) created to the class libraries. For extra points, add the source code directory or zipped source file under the source libraries tab; this will enable the javadoc popups when using IntelliSense).
Creating the API Layer
Writing the API and underlying code is something that any given engineer will probably undertake in a different way than any other. Suffice it to say, my approach normally follows this process:
- Take a stab at the API—at least documenting it, sometimes constructing it in code with stubbed implementation returning fixed example values where appropriate (this also lets development begin using Creator for the UI even while the rest of the middle-tier logic is being constructed, and also lets you write and run unit tests to keep you honest through the rest of the process).
- With the API definition in hand, I then design and create a persistence layer that represents the best guess of what will be needed. For us, this is currently done in Oracle JDeveloper’s BC4J layer, which auto-generates much of the code for you so this is not a time consuming operation. BC4J also lets you alter the persistence layer quickly and easily. Other persistence layers offer similar capabilities.
- Given the API at one end and the persistence layer at the other, I then design and construct the business logic to map one to the other. There is usually some iterative adjustment at this stage, hopefully more to the persistence layer than the API (which in some cases is already being used to construct Creator UIs).
This is based on a more extreme programming approach to the task. A more traditional and longer cycle approach may involve an entirely separate design phase for each of the above stages, followed by a distinct coding phase. This is no less valid but may result in a longer delay before the screens can start being coded in Creator.
This article is not intended to be a tutorial for creating Session EJBs. There are plenty of those around (see the Further Information section at the end for links). Given the choice, I gravitate towards Stateless Session EJBs in the API and will use a context pattern to provide continuity between calls from the same Web session. Your own experience in this area will dictate your choices.
JDeveloper, our chosen middle-tier tool, has good support for creating EJBs very quickly using diagramming and wizards, and without the need to construct your own deployment descriptors. This seems to be the case with most J2EE savvy IDEs now, so constructing the interface should be quick. As mentioned, a good idea is to construct the EJB API and get the methods and type signatures right; then code a very quick, fake back end to give back canned values from the methods. After this, you can publish the EJB jar, and get the UI development kicked off in Creator even while writing the real back-end to the API.
Creating the Persistence Layer
Armed with the API (or at least a pretty good guess at it), you should have a better idea what you need from your persistence layer. Work on some sequence diagrams to satisfy the API methods should help fill in any blanks. I find that sequence diagrams can be addictive and time consuming, so be conscious of the fact that if you try and plan for every eventuality with a sequence diagram, you will spend far too much time on them.
Another thing I have picked up over time is that I find keeping the persistence layer small is a benefit. Early experiences with using Oracle’s ADF to build the entire application resulted in numerous persistence View Objects in the application module that were very similar to one another and that were constructed to satisfy different pages in the Web app. Since moving to the newer architecture, I find that one View Object can satisfy the needs of numerous pages simply by changing the where clause or tweaking other aspects of the View Object programmatically, resulting in a much smaller and less complex Application Module. If these terms don’t mean much, don’t worry; I am sure the same principals apply to your favorite persistence mechanism. Keep it simple and small, and make the business logic more adaptive.
Creating the Business Logic
We now have both end points, the API at the upper end, and the persistence at the lower end. The sequence diagrams used to help find the persistence objects needed will also help construct the required business logic to connect the two. The business logic is the core of the system and will be different for every project, so there is not much more to say here, other than to point out that if you already coded the unit tests, these can be used and tweaked throughout the construction process to make sure things are working. Unit tests may need alteration as real data starts to flow out of the database rather than the canned responses that were stubbed in, but when this happens you should alter the unit tests to what you expect to see, rather than waiting to see what you get back and altering the tests to pass.
Creating the EJB Archive Files
Assuming we have completed all of the iterations necessary to have a fully working EJB API that is passing our unit and functional tests, what is next?
The last operation from your other tools is to bundle up the EJB API into one or more archive files. The archive file used is actually a modified form of Jar file called an EAR file (Enterprise archive) that itself is comprised of one or more jar files containing the API, and descriptors with information pertinent to the configuration and layout of the enterprise archive.
This article has covered in general the steps necessary to create an API based on Session EJBs suitable for use in a Creator project, using tools other than Creator either already in use at your workplace, or suitable for the task. This preliminary work has little to do with Creator at this point, other than to know where Creator fits into the process and preparing for it. Part 2 will focus on harnessing the work done here within Creator to consume the EJB session layer.
http://www.informit.com/articles/article.asp?p=21630&rl=1—Creating Session EJBs
http://www.oracle.com/technology/obe/obe9051jdev/EJBtoJSP/defaultejb.htm—Oracle JDeveloper specific EJB creation.
About the Author
Dick Wall is a Lead Systems Engineer at NewEnergy Associates, a Siemens Company based in Atlanta, GA that provides energy IT and consulting solutions for decision support and energy operations. He can be reached for comment on this and other matters at [email protected].