Integrating Sun Java Studio Creator Into Your Development Process, Page 2
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.
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@example.com.
Page 2 of 2