Note: This is a first cut at outlining the tools support needed for the Java Application Web Server. A discussion of the tools actually provided in the current release is in the User's Guide to Tools and Tool Status.
Building a web based application involves a number of different
tasks and roles. While these may be performed by different people with
different skills they all will need tool support. The following
discusses tool requirements organized by the development roles that
have been discussed in other parts of the Bojangles documentation.
Service Providers:
Providing BaseCollections
BaseCollections provide a mapping from in-memory objects to external storage. They also provide life-cycle and transaction support (transaction support is not provided in the current release) for the object's they contain. They are generally delivered with a set of supporting tools to aid in their use. We expect BaseCollections to be provided by professional development groups. Therefore the tools they will need center around a high-quality IDE for JAVA. This IDE should include support for.
Except for tool development support these are just the standard requirements for professional developers using Java.
Bojangles provides an object based framework for building code
generation tools that can be used by service providers to build
tools specific to their service.
Business Object Providers
Business objects are the server based objects that provide the business logic for an application. For the medium term these will mostly be developed in-house by the application's developers. At a minimum, business object developers need a Java IDE as discussed above. In a fairly significant application one would expect to have on the order of one hundred business objects arranged in a somewhat complex hierarchy and with complex inter-object relationships. Tools to design, and visualize the hierarchy and inter-object relationships will be very important.
Also, there is a fair amount of bookkeeping overhead to business objects in that generally each significant attribute will need a data declaration and get/set method pair in its implementation class as well as a get/set method pair in its interface class. This is five points to create or modify for each attribute. In the early stages of a project the design of the data attributes dominates. Even in a sample application like the Bojangles TRS demo there are about 110 attributes. Tool support for producing the initial code for these attributes and then maintaining them would be very useful.
Business objects are the starting point for application building, they embody the elements of the application's state and logic. Much of the actual application development will be based around the use of business objects. Therefore, it is very important that business objects be accompanied with high quality human and machine readable information describing the objects. This information needs to include information about the data scheme for each object, its dependencies, its relationships, etc. For application objects that are designed to directly support human interactions (i.e., business objects whose methods and attributes closely match human tasks) additional information to drive the development of a user interface will be needed. Tools to develop and maintain this information will be very useful.
Currently, Bojangles provides tools that generate the required
interface and implementation classes for business objects from
simple "base" class that the object developer produces by
hand.
Application Assemblers
In Bojangles, the role of application assembly breaks into several tasks including: server side programming, client side programming and setting up for distributed computing. Each of these tasks is discussed below.
The server side of an application is built by assembling a set of application objects with a set of base collections to provide the desired application function. Application assemblers will need excellent tools for looking at business objects, and their relationships. They will also need tools for adapting business objects to the BaseCollections that are chosen for the application. Adapting an business object to a BaseCollections consists of two types of activity.
This customization is called a Managed object and the process could be almost or completely automatic if the business object comes with high-quality, machine-processable information about its execution and data requirements.
Application assembly will usually involve adding custom logic to tie business objects together. Scripting support will be very important for this including all the normal scripting development issues such as visual interfaces, code editors, and debugging.
Currently, Bojangles provides tools that fully automate the process of customizing business objects for each of the BaseCollections currently supported. Mapping tools are not needed yet as the current set of BaseCollections require very little mapping.
The client side of a application will involve all of the normal problems of GUI development with the need to understand the interaction with the server-side business objects. If the server-side business objects are designed well then this part of the task will be easy as there will be fairly direct support for each of the user tasks. If this is not the case then the client-side programmer will also need business object visualization and analysis tools like the server-side programmer needed.
If the business objects are well designed and they have anticipated the end-user tasks well then a great productivity enhancement could come from tools that would automatically generate partial or complete client applications from business objects and their descriptive information. For example, it should be easy to build an initial HTML form for each user-interaction business object. This form could then be customized by the client developer.
Client-side development is inherently distributed. Therefore tools to support distributed debugging will be critical. Tools that will allow a distributed application to run in a non-distributed manner would also be very valuable.
Currently, Bojangles does not provide any client specific tools. However, our experience is that the current crop of Applet and Java development tools (such as Visual Cafe, or the RogueWave GUI libraries) work quite well with the rest of the Bojangles environment. Bojangles does provide a special debugging server that can be used with a WEB server to allow better visibility to and access to server execution. Due to the nature of the Bojangles programming model server binaries do not need to be changed to allow them to run in the debugging server.
The Bojangles programming model features the ability the make method calls in the client on object that exist in the server and between object that exist in different servers. Bojangles uses the OMG defined CORBA standard (and the CORBA IIOP wire protocol) to do this. Application developers will need to generate stub and skeletons for each of their object that need to be remotely accessible. Also, developers may want a way to generate CORBA Interface Description Language (IDL) descriptions of their Java interfaces or to generate Java interface and implementation files from IDL.
Currently, Bojangles provides tools to fully automate the production of stubs and skeletons for business objects. Bojangles also contains an early version of a tool to convert from Java to IDL, (The IDL to Java mapping is not defined yet so this tool not considered part of the Bojangles tool kit yet.) There is a tool available from the JavaSoft web site for converting from IDL to Java, but this tool is not fully compatible with the Bojangles programming conventions. We are working on this problem, but the standard is still not set.