Integrating Sun Java Studio Creator Into Your Development Process
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).