Method and apparatus in a data processing system for the controlling and sequencing of graphical user interface components and mediating access to system services for those components

Abstract

A method and apparatus in a data processing system for displaying a graphical user interface. A container is displayed in a graphical user interface from a set of containers, wherein a display of the container handled by a view controller from a set of view controllers. Each view controller handles the display of an associated container within the set of containers and user input for the associated container. A display of the set of containers is altered by an application mediator, wherein the set of containers are displayed in an order determined by the application mediator.

Claims

What is claimed is:

1. A method in a data processing system for displaying a set of containers, the method comprising the steps of:

displaying a current container from a set of containers using a plurality of view controllers, wherein each view controller handles user input for a container within the set of containers;

responsive to a selected user input to the current container, sending the selected user input from the view controller to an application mediator; and

responsive to receiving the selected user input at the application mediator, sending a response to the plurality of view controllers to display a different container within the set of containers.

2. The method according to claim 1 further comprising:

altering a display of the set of containers by said application mediator, wherein the set of containers are displayed in an order determined by the application mediator.

3. The method of claim 2 further comprising:

generating an event by a view controller in response to a selected user input to a container handled by the view controller, wherein the altering step is responsive to the application mediator receiving the event.

4. The method of claim 1, wherein the set of containers is a set of panels.

5. The method of claim 1, wherein the selected input is a first selected user input and further comprising:

responsive to a second selected user input to the current container, sending the second selected user input from the view controller to an application mediator; and

responsive to receiving the second selected user input at the application mediator, sending a view controller for the current container to alter a presentation of the current container.

6. A data processing system for displaying a set of containers, the data processing system comprising:

displaying means for displaying a current container from a set of containers using a plurality of view controllers, wherein each view controller handles user input for a container within the set of containers;

sending means, responsive to a selected user input to the current container, for sending the selected user input from the view controller to an application mediator; and

sending means, responsive to receiving the selected user input at the application mediator, for sending a response to the plurality of view controllers to display a different container within the set of containers.

7. The data processing system of claim 6, wherein the set of containers is a set of panels.

8. The data processing system of claim 6, wherein the selected input is a first selected user input and further comprising:

sending means, responsive to a second selected user input to the current container, for sending the second selected user input from the view controller to an application mediator; and

sending means, responsive to receiving the second selected user input at the application mediator, for sending a view controller for the current container to alter a presentation of the current container.

9. The data processing system of claim 6, wherein the application mediator mediates access to a service.

10. The data processing system of claim 9, wherein the service is a database.

11. The system according to claim 6, further comprising:

altering means for altering a display of the set of containers by the application mediator, wherein the set of containers are displayed in an order determined by the application mediator.

12. The data processing system of claim 11 further comprising:

generating means for generating an event by a view controller in response to a selected user input to a container handled by the view controller, wherein the altering step is responsive to the application mediator receiving the event.

13. A computer program product in a computer readable medium for displaying a set of containers, the method comprising the computer program product implemented steps of:

first instructions for displaying a current container from a set of containers using a plurality of view controllers, wherein each view controller handles user input for a container within the set of containers;

second instructions, responsive to a selected user input to the current container, for sending the selected user input from the view controller to an application mediator; and

third instructions, responsive to receiving the selected user input at the application mediator, for sending a response to the plurality of view controllers to display a different container within the set of containers.

14. The product according to claim 13, further comprising:

fourth instructions for altering a display of the set of containers by the application mediator, wherein the set of containers are displayed in an order determined by the application mediator.

Description

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates generally to an improved distributed data processing system and, in particular to an improved method and apparatus for creating applications. Still more particularly, the present invention relates to a method and apparatus for creating client applications.

2. Description of Related Art

Distributed data processing systems involve data transfers between clients and servers (also know as services). Typically, a client locates a server, initiates a session with a server and requests the server to perform some service. The server expects requests from a client to arrive in a particular format. A server is more complex than a client because the server typically handles a large number of clients simultaneously, often fetches and stores information from a large database, creates additional transactions for other services, performs business logic, and returns information formatted according to each client channel. For example, data will be specified in a particular message format. A particular transmission protocol will deliver the message to the server. The server accepts the message protocol as its application programming model (API) to its services and returns a result. A variety of software systems, such as Enterprise Java Beans (EJB), Servlets, Java Server Pages (JSP), and XML have been implemented to enhance the development of client and server-side software.

Client applications perform a number of different functions. For example, the application on the client side handles the user interface and may provide program logic for processing user input. Additionally, a client application must match the requirements of a particular server to provide communications with the particular server. Clients are packaged and distributed according to the services provided by the server.

A graphical user interface (GUI) exists in the client application to handle what the user views on the screen. Events resulting from user input, such as mouse clicks or keyboard strokes, are detected and handled using "listener" processes in the application. The events are processed by program logic. The program logic may result in requests being sent to a server.

Communication with the server is provided using processes that use protocols, such as hypertext transfer protocol (HTTP), secure sockets (SSL), or Remote Method Invocation (RMI).

Client software can be either "thick" or "thin". A thick client is typically a large client-installed application that may access a database directly and apply business logic. They typically have dependence on the client operating system and require manual support to install and configure. By contrast a thin client is typically a small application downloaded on request from a server and accesses the database through an intermediate application server. This is known as a multi-tier application. A number of different usage scenarios for clients are present, resulting in a variety of client needs being present. For example, it is typical that in an global enterprise Intranet, the client configuration is controlled by the business but the large number of clients includes older machines with slow networks (e.g. 9600 baud). Likewise, in the Internet, there is little configuration control by the business and it is estimated that a large percentage of clients worldwide still use 14.4K connections that result in very slow network speeds and downloads. A typical user will become very frustrated if downloads take longer than a minute or two. Further, mobile users require compact software that can be customized and packaged to fit on machines and operate disconnected from the network. Subsequent automated support to connect to the network is needed.

At the other end of the spectrum, power users with high speed connections expect screen refresh times in the sub-second range and "instantaneous" echoing of typed characters to provide the look and feel of processing in a local environment. In a multi-tier computing environment, the primary role of the client is to present and gather information quickly. The client application is considered a business asset independent of the network topology and server function. In these environments, it is desirable to be able to use the same client processing code for different user types and interface channels, such as automated teller machines (ATM), Kiosks, Internet [hypertext markup language (HTML)/applets], and regional office clients (applications).

Consequently, a common thin or thick client development environment for developing clients may be used to solve these problems, especially when the size and speed of the application download, integration and operation is important. Any software development environment should be based on sound software engineering principles.

Object-oriented languages have been employed in creating thin clients. Object-oriented programming environments have been presented as providing software reuse, which is a desirable feature in creating thin clients and reducing development time. In reality, the present object-oriented programming environments for developing thin clients are unable to provide enough object reuse and repeatability for quickly developing thin clients. Nor do they specify how to readily support additional message formats, protocols, data models and servers, mobile disconnected users, and caching.

Therefore, it would be advantageous to have an improved method and apparatus for a client development architecture that facilitates creating thin clients in a manner in which component reuse is increased while client development time is reduced, and multiple message formats, protocols, data models and servers, mobile disconnected users and caching can be readily integrated.

SUMMARY OF THE INVENTION

The present invention provides an architectural pattern for creating applications for a data processing system. A graphical user interface is created in which the graphical user interface includes a plurality of components. Processes for presenting the plurality of components and receiving user input are handled by a first set of graphical objects, wherein in response to selected user input, a first event is generated. An application object is created in which the application process controls an order in which the graphical objects present the set of components and process the event and wherein the application generates a second event. A transport object is created in which the transport object processes the second event and forwards the second event for processing to a destination within the plurality of destinations. A plurality of destination objects are created in which each destination object within the plurality of destinations objects handles accessing a destination within the plurality of destinations.

The present invention provides a method and apparatus in a data processing system for refreshing data in an application. A call is received to update data in the application, wherein the data is destined for a component in the application. A data type is identified for the data. Responsive to the data type being a handled data type, the data is formatted and a refresh is called on the component.

The present invention provides a method and apparatus in a data processing system for displaying a component or container. The container is displayed within a display using a first component. A location of the component or container is controlled within the display using a second component, wherein the second component controls the location and geometry of the component or container in response to receiving an event. The component or container is selectively displayed using a third component, wherein the third component generates the event.

The present invention provides a process in a data processing system for managing services in a desktop environment from an object oriented-environment. A presentation of a graphical user interface is controlled using a view controller, wherein the view controller handles user input to the graphical user interface. Responsive to a selected user input, the selected user input is sent from the view controller to an application mediator. Responsive to receiving the selected user input at the application mediator, the selected user input is processed at the application mediator. Responsive to the application mediator determining that a service is required in the desktop environment, an event is generated. Responsive to detecting the event at a listener object, a method is executed in the listener object to perform the service in the desktop environment.

The present invention provides a method and apparatus in a data processing system for managing transactions. A request event is received at a transporter object. The request event includes a target and an indication of how to handle the request event. A destination object is identified within the plurality of destination objects using the request event to form an identified destination object. The request event is sent to the identified destination object, wherein the identified destination object handles the request using the indication and accesses the target.

The present invention provides a method and apparatus in a data processing system for displaying a graphical user interface. A container is displayed in a graphical user interface from a set of containers, wherein a display of the container handled by a view controller from a set of view controllers. Each view controller handles the display of an associated container within the set of containers and user input for the associated container. A display of the set of containers is altered by an application mediator, wherein the set of containers are displayed in an order determined by the application mediator.

The present invention provides a method and apparatus in a data processing system for performing validation of user input. User input is received in a container displayed in a graphical user interface, wherein presentation of the container and the user input to the container are handled by a view controller. Responsive to receiving the user input, a call is sent to a validation object by the view controller. Responsive to the call, the validation object tests the user input using a criteria, wherein the rule is separate from the view controller.

The present invention provides a method and apparatus in a data processing system for managing permissions in an application. A user input is received at a container handled by a view controller, wherein the user input requests a change in permissions in the application. This user input, may be, for example, a change in security in an application through a login process. A view event describing the user input is generated. The view event is received at an application mediator. Responsive to receiving the view event, by the application mediator, a request event is generated and a permission corresponding to the user input is received. The permission alters an item, which may be in either of both the view controller and the application mediator.

The present invention provides a process and apparatus in a data processing system for presenting a view to a client. At an application mediator, a view event is received from a view controller, wherein the view event describes an action on a displayed container handled by the view controller. Responsive to a requirement that a change in a placement of the displayed container is required, a placement event is generated by the application mediator. A determination is then made by a placement listener, as to whether the placement event includes an indication that an alternate view is to be generated. Responsive to a determination that an alternate view is to be generated, a call is sent to a method in the view controller to generate the alternate view.

The present invention provides a method and apparatus in a data processing system for processing user input in a graphical user interface. A graphical user interface is presented using a view controller, wherein the view controller handles the user input to the graphical user interface. Responsive to a selected user input, an event is sent to a first application mediator. Responsive to the first application mediator being unable to process the event, the event is sent to a second application mediator for processing, wherein the first application mediator and the second application mediator handle an order in which a set of displays are displayed by a view controller.

The present invention provides a method and apparatus in a data processing system for presenting a set of screens in a graphical user interface. A first screen within a set of screens is presented, wherein the set of screens are presented using a set of view controllers. Responsive to a selected user input to the first screen, an event is generated by a view controller within the set of view controllers identifying the user input to the first screen, which is handled by the first view controller. Responsive to detecting the event generated by the view controller, a second screen from the set of screens is selected, by an application mediator, for display by sending a response to a view controller handling the second screen.

The application mediator is initialized from reading a state machine file and control processing of view event received from virtual controllers.

The present invention provides a method and apparatus in a data processing system for serializing data. A serializer receives a data element for serialization, wherein the data element includes a class name string. Responsive to receiving the data element, the serializer replaces the class name string with a code having a smaller size than the class name string to form a modified data element. Responsive to forming the modified data element, in which the serializer serializes the modified data element. This serialized data is transmitted and deserialized by a deserializer, which replaces the indicator with the class name.

The present invention provides a method and apparatus in a data processing system for providing an interface to an application for monitoring execution of the application. An event generated by a view controller is detected, wherein the view controller handles presentation of a container in a graphical user interface. A determination is made as to whether the event is an event selected for monitoring. Responsive to the determination that the event is an event selected for monitoring, a request event is generated, wherein the request event includes data from the event and a destination.

The present invention provides a method and apparatus for a data processing system for accessing classes and methods in an object oriented system. Responsive to receiving a selected user input to a container, a view event is sent from a view controller o an application mediator. The view event identifies an action taken to generate the selected user input. A request is selectively generated based on the view event, wherein the request event includes a major code identifying a class name as a destination and a minor code identifying a method name a function to be invoked. The request event is sent to a transporter. The transporter acts as a router to send the request event to an appropriate destination object from a plurality of destination objects. Responsive to receiving the request event at the transporter, the request event is sent to a destination object within a plurality of destination objects based in the class name. The destination object formats the request event into a form recognizable by the destination associated with the destination object. The destination may be located on a remote data processing system. The request event is used to access the class or method identified in the request event. The access may be, for example, an invocation of the method.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

FIG. 1 depicts a pictorial representation of a distributed data processing system in which the present invention may be implemented;

FIG. 2 is a block diagram depicting a data processing system that may be implemented as a server in accordance with a preferred embodiment of the present invention;

FIG. 3 is a block diagram illustrating a data processing system in which the present invention may be implemented;

FIG. 4 is a diagram illustrating a model view controller diagram depicted in accordance with a preferred embodiment of the present invention;

FIG. 5 is a diagram illustrating the components in an architectural pattern depicted in accordance with a preferred embodiment of the present invention;

FIG. 6 is a diagram illustrating classes in a class hierarchy depicted in accordance with a preferred embodiment of the present invention;

FIG. 7 is a unified modeling language diagram depicted in accordance with a preferred embodiment of the present invention;

FIGS. 8A and 8B are diagrams illustrating variables and methods in a ViewController depicted in accordance with a preferred embodiment of the present invention;

FIGS. 9A-9E are diagrams illustrating variables, constructors, and methods for ViewControllerImpl depicted in accordance with a preferred embodiment of the present invention;

FIGS. 10A-10C are tables which show the variables, constructors and methods for ViewControllerBaseImpl depicted in accordance with a preferred embodiment of the present invention;

FIGS. 11A-11C are tables which illustrate a variable, a constructor, and methods for a ViewControllerAdapter depicted in accordance with a preferred embodiment of the present invention;

FIGS. 12A-12D are drawings illustrating variables, constructors, and methods for a ValidationRule depicted in accordance with a preferred embodiment of the present invention;

FIGS. 13A and 13B are tables illustrating variables and constructors for a ValidationRuleException depicted in accordance with a preferred embodiment of the present invention;

FIGS. 14A-14F are diagrams illustrating variables, constructors, and methods for a ViewEvent depicted in accordance with a preferred embodiment of the present invention;

FIGS. 15A and 15B are diagrams illustrating a variable and a method for a ViewListener depicted in accordance with a preferred embodiment of the present invention;

FIGS. 16A and 16B diagrams illustrating a variable and methods for an ApplicationMediator depicted in accordance with a preferred embodiment of the present invention;

FIGS. 17A-17E are diagrams illustrating variables and a constructor for an ApplicationMediatorImpl depicted in accordance with a preferred embodiment of the present invention;

FIGS. 17F-17I are diagrams illustrating code used in methods for an ApplicationMediatorImpl depicted in accordance with a preferred embodiment of the present invention;

FIGS. 17J-17M are diagrams which depicts code used to handle the event dispatch in accordance with a preferred embodiment of the present invention;

FIGS. 18A-18C are diagrams illustrating variables, constructors, and methods for a PlacementEvent depicted in accordance with a preferred embodiment of the present invention;

FIGS. 19A and 19B are diagrams illustrating a variable and method for a PlacementListener depicted in accordance with a preferred embodiment of the present invention;

FIGS. 20A-20C are diagrams illustrating variables, constructors, and methods for a TopEvent depicted in accordance with a preferred embodiment of the present invention;

FIGS. 21A and 21B are diagrams illustrating a variable and methods for TopListeners depicted in accordance with a preferred embodiment of the present invention;

FIGS. 22A-22C are diagrams illustrating a variable, constructors, and methods for RequestEvent depicted in accordance with a preferred embodiment of the present invention;

FIGS. 23A-23C are diagrams illustrating a variable, constructors, and methods for a RequestException depicted in accordance with a preferred embodiment of the present invention;

FIGS. 24A and 24B are diagrams illustrating a variable and methods for a RequestListener depicted in accordance with a preferred embodiment of the present invention;

FIGS. 25A and 25B are diagrams illustrating a variable and methods for a RequestResponseListener depicted in accordance with a preferred embodiment of the present invention;

FIGS. 26A-26C are diagrams illustrating variables, a constructor, and methods for a Transporter depicted in accordance with a preferred embodiment of the present invention;

FIGS. 26D-26H are diagrams illustrating code used in methods in a Transporter depicted in accordance with a preferred embodiment of the present invention;

FIGS. 27A and 27B are diagrams illustrating a variable and methods for a Destination depicted in accordance with a preferred embodiment of the present invention;

FIGS. 28A-28C are diagrams illustrating variables, constructors, and methods for a DestinationImpl depicted in accordance with a preferred embodiment of the present invention;

FIG. 28D is code used to process a RequestEvent depicted in accordance with a preferred embodiment of the present invention;

FIGS. 29A and 29B are diagrams illustrating variables and methods in a Factory depicted in accordance with a preferred embodiment of the present invention;

FIGS. 30A and 30B are diagrams illustrating a variable and methods for a JTC depicted in accordance with a preferred embodiment of the present invention;

FIG. 31 is a flowchart of a process for creating a ViewController depicted in accordance with a preferred embodiment of the present invention;

FIG. 32 is a flowchart of a process for creating ValidationRules depicted in accordance with a preferred embodiment of the present invention;

FIG. 33 is a flowchart of a process for creating a ViewEvent depicted in accordance with a preferred embodiment of the present invention;

FIG. 34 is a flowchart of a process to create an ApplicationMediator depicted in accordance with a preferred embodiment of the present invention;

FIG. 35 is a flowchart of a process for creating a RequestEvent depicted in accordance with a preferred embodiment of the present invention;

FIG. 36 is a flowchart of a process for creating a Destination depicted in accordance with a preferred embodiment of the present invention;

FIG. 37 is a flowchart of a process for creating a TopListener depicted in accordance with a preferred embodiment of the present invention;

FIG. 38 is a flowchart of a process for creating a PlacementListener depicted in accordance with a preferred embodiment of the present invention;

FIG. 39 is a diagram illustrating runtime behavior of a ViewController subsystem depicted in accordance with a preferred embodiment of the present invention;

FIG. 40 are steps in the operation of a ViewController subsystem, as viewed from a ViewControllerImpl, depicted in accordance with a preferred embodiment of the present invention;

FIG. 41 is a flowchart of a process for a JTC application to present alternate views (HTML/XML) of itself while running in a separate environment, such as a server, as the alternate views depicted in accordance with a preferred embodiment of the present invention;

FIGS. 42 and 43 are diagrams detailing processes within the ViewController subsystem depicted in accordance with a preferred embodiment of the present invention;

FIG. 44 is a complete list of predefined major event codes depicted in accordance with a preferred embodiment of the present invention;

FIG. 44 shows how a text field representing a social security number can be validated and displayed depicted in accordance with a preferred embodiment of the present invention;

FIG. 46 shows how a social security number can be validated and converted back to a transmittable format depicted in accordance with a preferred embodiment of the present invention;

FIG. 47 illustrates the application of two edit rules, range checking, and formatting for viewing depicted in accordance with a preferred embodiment of the present invention;

FIG. 48 illustrates inheritance where the ViewControllerBaseImpl is a subclass of JPanel from the Java swing components depicted in accordance of a preferred embodiment of the present invention;

FIG. 49 illustrates inheritance where the ViewControllerBaseImpl is a subclass of java.lang.Object and where the methods getComponent, setEnabled and setVisible are implemented to ensure the ViewController subclassing ViewControllerBaseImpl can be treated as a GUI component, container or bean depicted in accordance of a preferred embodiment of the present invention;

FIG. 50 is a diagram illustrating runtime behavior of an ApplicationMediator subsystem depicted in accordance with a preferred embodiment of the present invention;

FIG. 51 is a diagram illustrating Event threading support depicted in accordance with a preferred embodiment of the present invention;

FIG. 52 is a flowchart of a process used in designing and executing an ApplicationMediator depicted in accordance with a preferred embodiment of the present invention;

FIG. 53 is a diagram illustrating runtime behavior of the Placement subsystem is depicted in accordance with a preferred embodiment of the present invention;

FIG. 54 is Java code illustrating the creation and firing of a PlacementEvent in an ApplicationMediator depicted in accordance with a preferred embodiment of the present invention;

FIG. 55 is Java code illustrating the callback to a PlacementListener with a PlacementEvent and inspecting the PlacementEvent for semantic interpretation depicted in accordance with a preferred embodiment of the present invention;

FIG. 56 is a flowchart of a process used in processing a PlacementEvent depicted in accordance with a preferred embodiment of the present invention;

FIG. 57 is a diagram illustrating runtime behavior for a TopListener subsystem depicted in accordance with a preferred embodiment of the present invention;

FIG. 58 is Java code illustrating the creation of an ApplicationMediator and the adding of a PlacementListener depicted in accordance with a preferred embodiment of the present invention;

FIG. 59 is Java code illustrating the creation and firing of a TopEvent in an ApplicationMediator depicted in accordance with a preferred embodiment of the present invention;

FIG. 60 is Java code illustrating the callback to a TopListener with a TopEvent and inspecting the TopEvent for semantic interpretation depicted in accordance with a preferred embodiment of the present invention;

FIG. 61 is a diagram illustrating runtime behavior of a RequestEvent subsystem depicted in accordance with a preferred embodiment of the present invention;

FIG. 62 is Java code illustrating the creation of RequestEvent, setting its major and minor codes, and firing an asynchronous RequestEvent from an ApplicationMediator depicted in accordance with a preferred embodiment of the present invention;

FIG. 63 is Java code illustrating the callback, to an ApplicationMediator, a successful asynchronous RequestEvent with a result depicted in accordance with a preferred embodiment of the present invention;

FIG. 64 is Java code illustrating the callback, to an ApplicationMediator, an unsuccessful asynchronous RequestEvent with a RequestException depicted in accordance with a preferred embodiment of the present invention;

FIG. 65 is a flowchart of a process for using a RequestEvent depicted in accordance with a preferred embodiment of the present invention;

FIG. 66 is a diagram illustrating runtime behavior of a Transporter subsystem depicted in accordance with a preferred embodiment of the present invention;

FIG. 67 is Java code illustrating creation of a Transporter and adding it as a RequestListener depicted in accordance with a preferred embodiment of the present invention;

FIG. 68 is runtime behavior of a Destination subsystem shown in accordance with a preferred embodiment of the present invention;

FIG. 69 is a diagram of Java code for creation of a Destination, setting a major code and adding it to a Transporter as a DestinationListener depicted in accordance with a preferred embodiment of the present invention;

FIG. 70 is a diagram illustrating Java code for creating Destinations with wild card, priority and normal major codes, firing a RequestEvent, and a report of the expected results depicted in accordance with a preferred embodiment of the present invention;

FIG. 71 is a diagram of Java code used for accessing, identifying type and recursively attaching JTC, AWT and JFC listeners to JTC, AWT and JFC programs and objects depicted in accordance with a preferred embodiment of the present invention;

FIG. 72 is a diagram of Java code used for attaching JTC listeners to JTC ApplicationMediators, ViewControllers and Transporters depicted in accordance with a preferred embodiment of the present invention;

FIG. 73 is a diagram of Java code used for attaching AWT and JFC listeners to AWT and JFC containers, components and beans depicted in accordance with a preferred embodiment of the present invention;

FIG. 74 is a diagram of Java code used for attaching AWT and JFC listeners to AWT and JFC components (java.awt.Button, com.sun.swing.java.JButton and com. and com.sun.java.swing.JTextField) depicted in accordance with a preferred embodiment of the present invention;

FIG. 75 is a flowchart of a process for performing hookJTCs and hookkWTs, non intrusive tracing, hooking, debugging, monitoring and logging of JTC programs and JTC program objects depicted in accordance with a preferred embodiment of the present invention;

FIG. 76 is a diagram describing the relationship between components and containers depicted in accordance with a preferred embodiment of the present invention;

FIG. 77 is a flowchart of a process for performing hookAWTs depicted in accordance with the preferred embodiment of the present invention;

FIG. 78 is a process for hooking an AWT and JFC component depicted in accordance with the preferred embodiment of the present invention;

FIGS. 79-82 are diagrams of Java code for use in managing the refresh of data objects in an ApplicationMediator (79), managing the refresh of data objects in a ViewController using initial types (80), and managing the refresh of data objects in a ViewController using an multiple concurrent updated or additional data types (81, 82) depicted in accordance with a preferred embodiment of the present invention;

FIG. 83 is a diagram of using multiple concurrent data model update notification mechanisms in a ViewController and ApplicationMediator depicted in accordance with a preferred embodiment of the present invention;

FIG. 84 is a flowchart of a process used in a TopListener depicted in accordance with a preferred embodiment of the present invention;

FIG. 85 is a flowchart of a PlacementListener depicted in accordance with a preferred embodiment of the present invention;

FIG. 86 is a flowchart illustrating handling of AWTEvents by a ViewController depicted in accordance with a preferred embodiment of the present invention;

FIG. 87 is a flowchart illustrating application of ValidationRules depicted in accordance with a preferred embodiment of the present invention;

FIG. 88 is a flowchart of a process for firing a ViewEvent depicted in accordance with a preferred embodiment of the present invention;

FIGS. 89-95 are flowcharts illustrating processes used by an ApplicationMediator depicted in accordance with a preferred embodiment of the present invention;

FIGS. 96 and 97 are diagrams illustrating processes used to refresh object data in an ApplicationMediator and ViewController depicted in accordance with a preferred embodiment of the present invention;

FIG. 98 is a flowchart of a process used to process RequestEvents depicted in accordance with a preferred embodiment of the present invention;

FIG. 99 is a flowchart of an initialization process for creating hierarchical ApplicationMediators depicted in accordance with a preferred embodiment of the present invention;

FIG. 100 is a flowchart of a process for handling events in a hierarchical ApplicationMediator system depicted in accordance with a preferred embodiment of the present invention;

FIG. 101 is a flowchart for a process for building a virtual ApplicationMediator state dispatching machine depicted in accordance with a preferred embodiment of the present invention;

FIG. 102 illustrates example table entries from the loading of a configuration file for a virtual ApplicationMediator state machine depicted in accordance of a preferred embodiment of the present invention;

FIGS. 103 and 104 are virtual ApplicationMediator access state dispatching machine used to determine whether processing of a ViewEvent is needed depicted in accordance with a preferred embodiment of the present invention;

FIG. 105 is a diagram of a serializer system write depicted in accordance with a preferred embodiment of the present invention;

FIG. 106 is a diagram of a serializer system read depicted in accordance with a preferred embodiment of the present invention;

FIGS. 107A-107C are diagrams illustrating an object array depicted in accordance with a preferred embodiment of the present invention;

FIGS. 108A-108B are diagrams illustrating code used in a serialization method depicted in accordance with a preferred embodiment of the present invention;

FIG. 109 implements the methods readExternal and writeExternal for reading/writing from/to input/output stream depicted in accordance of a preferred embodiment of the present invention;

FIGS. 110A-110O are diagrams illustrating code used in a serialization method depicted in accordance with a preferred embodiment of the present invention;

FIG. 111 is a flowchart of a process for using a serializer depicted in accordance with the preferred embodiment of the present invention;

FIG. 112 is a flowchart of a process for statically creating matching user profiles and associated JTC permission keys for JTC programs, where keys are built by recursively querying JTC ApplicationMediator and ViewController objects, depicted in accordance with a preferred embodiment of the present invention;

FIG. 113 is a flowchart of a process for a JTC program building a database of permission keys by iterating over JTC ApplicationMediator's getPermissions method and returning permission keys that are ViewController names that are alterable at runtime depicted in accordance with a preferred embodiment of the present invention;

FIG. 114 is a flowchart of a process for a JTC ApplicationMediator building a database of permission keys by iterating over JTC ViewController's getPermissions method and returning permission keys that are names known only to the ViewController and hat are alterable at runtime depicted in accordance with a preferred embodiment of the present invention;

FIG. 115 is a flowchart of a process for a JTC ViewController building a database of permission keys by iterating over runtime alterable components, containers and beans and returning permission keys that are component, container or bean names that are alterable at runtime depicted in accordance with a preferred embodiment of the present invention;

FIGS. 116 is a flowchart of a process for a JTC program accepting a database of permission keys by retrieving permission key/value data supplying the data to a JTC program depicted in accordance with a preferred embodiment of the present invention;

FIG. 117 is a flowchart of a process for a JTC program supplied with a setting of permission key/value data and iterating over all ApplicationMediators and passing the key/value data through setPermissions depicted in accordance with a preferred embodiment of the present invention;

FIG. 118 is a flowchart of a process for a JTC ApplicationMediator called with setPermissions of permission key/value data and iterating over all ViewControllers and passing the key/value data through setPermissions depicted in accordance with a preferred embodiment of the present invention;

FIG. 119 is a flowchart of a process for a JTC ViewController called with setPermissions of permission key/value data and iterating over the permission keys, identifying the corresponding components, containers and beans, and applying the value to the components, containers and beans, depicted in accordance with a preferred embodiment of the present invention; and

FIGS. 120-123 illustrate example patterns using the architectural pattern of the present invention depicted in accordance of a preferred embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

I. Hardware

With reference now to the figures, FIG. 1 depicts a pictorial representation of a distributed data processing system in which the present invention may be implemented. Distributed data processing system 100 is a network of computers in which the present invention may be implemented. Distributed data processing system 100 contains a network 102, which is the medium used to provide communications links between various devices and computers connected together within distributed data processing system 100. Network 102 may include permanent connections, such as wire or fiber optic cables, or temporary connections made through telephone connections.

In the depicted example, a server 104 is connected to network 102 along with storage unit 106. In addition, clients 108, 110, and 112 also are connected to a network 102. These clients 108, 110, and 112 may be, for example, personal computers or network computers. For purposes of this application, a network computer is any computer, coupled to a network, which receives a program or other application from another computer coupled to the network. In the depicted example, server 104 provides data, such as boot files, operating system images, and applications to clients 108-112. Clients 108, 110, and 112 are clients to server 104. Distributed data processing system 100 may include additional servers, clients, and other devices not shown. In the depicted example, distributed data processing system 100 is the Internet with network 102 representing a worldwide collection of networks and gateways that use the TCP/IP suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, government, educational and other computer systems that route data and messages. Of course, distributed data processing system 100 also may be implemented as a number of different types of networks, such as for example, an intranet, a local area network (LAN), or a wide area network (WAN). FIG. 1 is intended as an example, and not as an architectural limitation for the present invention.

Referring to FIG. 2, a block diagram depicts a data processing system that may be implemented as a server, such as server 104 in FIG. 1, in accordance with a preferred embodiment of the present invention. Data processing system 200 may be a symmetric multiprocessor (SMP) system including a plurality of processors 202 and 204 connected to system bus 206. Alternatively, a single processor system may be employed. Also connected to system bus 206 is memory controller/cache 208, which provides an interface to local memory 209. I/O bus bridge 210 is connected to system bus 206 and provides an interface to I/O bus 212. Memory controller/cache 208 and I/O bus bridge 210 may be integrated as depicted.

Peripheral component interconnect (PCI) bus bridge 214 connected to I/O bus 212 provides an interface to PCI local bus 216. A number of modems may be connected to PCI bus 216. Typical PCI bus implementations will support four PCI expansion slots or add-in connectors. Communications links to network computers 108-112 in FIG. 1 may be provided through modem 218 and network adapter 220 connected to PCI local bus 216 through add-in boards.

Additional PCI bus bridges 222 and 224 provide interfaces for additional PCI buses 226 and 228, from which additional modems or network adapters may be supported. In this manner, server 200 allows connections to multiple network computers. A memory-mapped graphics adapter 230 and hard disk 232 may also be connected to I/O bus 212 as depicted, either directly or indirectly.

Those of ordinary skill in the art will appreciate that the hardware depicted in FIG. 2 may vary. For example, other peripheral devices, such as optical disk drives and the like, also may be used in addition to or in place of the hardware depicted. The depicted example is not meant to imply architectural limitations with respect to the present invention.

The data processing system depicted in FIG. 2 may be, for example, an IBM RISC/System 6000 system, a product of International Business Machines Corporation in Armonk, N.Y., running the Advanced Interactive Executive (AIX) operating system.

With reference now to FIG. 3, a block diagram illustrates a data processing system in which the present invention may be implemented. Data processing system 300 is an example of a client computer. Data processing system 300 employs a peripheral component interconnect (PCI) local bus architecture. Although the depicted example employs a PCI bus, other bus architectures such as Micro Channel and Industry Standard Architecture (ISA) may be used. Processor 302 and main memory 304 are connected to PCI local bus 306 through PCI bridge 308. PCI bridge 308 also may include an integrated memory controller and cache memory for processor 302. Additional connections to PCI local bus 306 may be made through direct component interconnection or through add-in boards. In the depicted example, local area network (LAN) adapter 310, Small Computer System Interface host bus adapter 312, and expansion bus interface 314 are connected to PCI local bus 306 by direct component connection. In contrast, audio adapter 316, graphics adapter 318, and audio/video adapter 319 are connected to PCI local bus 306 by add-in boards inserted into expansion slots. Expansion bus interface 314 provides a connection for a keyboard and mouse adapter 320, modem 322, and additional memory 324. Small computer system interface (SCSI) host bus adapter 312 provides a connection for hard disk drive 326, tape drive 328, and CD-ROM drive 330. Typical PCI local bus implementations will support three or four PCI expansion slots or add-in connectors.

An operating system runs on processor 302 and is used to coordinate and provide control of various components within data processing system 300 in FIG. 3. The operating system may be a commercially available operating system such as OS/2, which is available from International Business Machines Corporation. "OS/2" is a trademark of International Business Machines Corporation. An object oriented programming system such as Java may run in conjunction with the operating system and provides calls to the operating system from Java programs or applications executing on data processing system 300. "Java" is a trademark of Sun Microsystems, Inc. Instructions for the operating system, the object-oriented operating system, and applications or programs are located on storage devices, such as hard disk drive 326, and may be loaded into main memory 304 for execution by processor 302.

Those of ordinary skill in the art will appreciate that the hardware in FIG. 3 may vary depending on the implementation. Other internal hardware or peripheral devices, such as flash ROM (or equivalent nonvolatile memory) or optical disk drives and the like, may be used in addition to or in place of the hardware depicted in FIG. 3. Also, the processes of the present invention may be applied to a multiprocessor data processing system.

For example, data processing system 300, if optionally configured as a network computer, may not include SCSI host bus adapter 312, hard disk drive 326, tape drive 328, and CD-ROM 330, as noted by dotted line 332 in FIG. 3 denoting optional inclusion. In that case, the computer, to be properly called a client computer, must include some type of network communication interface, such as LAN adapter 310, modem 322, or the like. As another example, data processing system 300 may be a stand-alone system configured to be bootable without relying on some type of network communication interface, whether or not data processing system 300 comprises some type of network communication interface. As a further example, data processing system 300 may be a Personal Digital Assistant (PDA) device which is configured with ROM and/or flash ROM in order to provide nonvolatile memory for storing operating system files and/or user-generated data.

The depicted example in FIG. 3 and above-described examples are not meant to imply architectural limitations. For example, data processing system 300 also may be a notebook computer or hand held computer in addition to taking the form of a PDA. Data processing system 300 also may be a kiosk or a Web appliance.

II. Overview

With reference next to FIG. 4, a diagram illustrating a model view controller diagram is depicted in accordance with a preferred embodiment of the present invention. Model view control (MVC) diagram 400 includes an end-to-end section 402 in which the view is represented by client 404, the control is represented by mid-tier logic 406 and the model is represented by persistence storage 408. Section 410 is a graphical user interface (GUI) component architecture in which the view are Java components 412, the control are event listeners 414, and the model are Java models 416. GUI components 410 may be currently embodied in systems such as the Java Foundation Classes (JFC) from Java.

In accordance with a preferred embodiment of the present invention, the present invention provides an architectural pattern for views in the client, for naviagation of views in the client, for placing and presenting views in a client, for issuing requests for different concurrent servers and services from the client, for issuing requests for client platform services from the client, for using multiple concurrent data model types in the client, for issuing multiple message formats from the client, for using multiple protocols in the client and for specific partitioning of these pattern components in the client, such as client 404. In particular, section 418 in these examples significantly defines and enhances and includes a view as Java Abstract Windows Toolkit (AWT)/(JFC) 420, a control as screen control 422, and a model as transactions 424. AWT is a tool kit containing primitives for basic windowing functionality. These primitives include user interface functionality, such as window and dialogue box manipulations, text rendering, buttons, check box, and radio button creation and manipulation, as well as graphics primitives such as line drawing, color choice. Virtually all sophisticated graphics and user-interface tools are built upon these primitives. The Java foundation classes (JFC) is a package containing, among other things, primitives for windowing functionality that provide a rich superset of AWT. These primitives or components include everything that the AWT provides along with a rich superset of new primitives, including, for example, tree view, tabbed panes, hypertext markup language (HTML) text views, etc. Java AWT/(JFC) 420 could be described through section 410.

Object-oriented design depends heavily on the class concept and the relationships between various classes. A class is an abstraction of an object that contains both attributes (data) and behavior (methods). Each new object created from a class is referred to as an instance of that class. In other words, the class is an abstract encapsulation mechanism while an instance is a particular object created from the class. If a method in a class is called, it is sometimes said a message is sent to an object.

Classes are organized into inheritance hierarchies where a parent class may have one or several subclasses. The subclasses share all the data and methods from the parent class and any other ancestor class in the inheritance tree. The search for the appropriate methods to be used starts at the class for the object and proceeds up the tree as necessary to find the desired method (the name and parameters of the method must match exactly). Multiple inheritance means that a class can have two or more parent classes. Some programming languages (e.g., C++) support multiple inheritance while others (e.g., Smalltalk) do not. Multiple inheritance is difficult to manage, so some languages (e.g., Java) provide a mechanism called interfaces that provide a type oriented mechanism to achieve a similar functionality without incurring the implementation burdens. The class hierarchy diagram is based on a Java implementation and makes extensive use of the interface mechanism.

III. Architectural Pattern

The present invention provides a method, apparatus, and instructions for an architectural programming pattern and implementation. The architectural pattern of the present invention is illustrated as a Java implementation for building thin (or thick) client applications and is also referred to as "JTC." JTC is a process, architectural pattern, and implementation to guide developers on how to build applications, and in particular, Internet style thin clients. JTC adapts to Internet changes rapidly. JTC increases developer discipline by providing a common repeatable programming pattern. JTC facilitates project management by providing for concurrent development of the client. JTC facilitates project management by providing for concurrent client and server(s) development. JTC provides for a natural partition of various programmer skills. JTC has a formula based approach for cost estimates. JTC provides multi-channel support (ATM, Internet, Kiosk, Extranet, Mobile, Branch, Call Center, Business partners, etc.). JTC supports mobile user disconnected mode. JTC provides natural support for multiple servers with reduced code level cohesion and coupling. JTC provides natural support for multiple data models such as, for example, XML, DHTML, Objects, Key/Value, EJB, streaming and asynchronous. JTC has natural support for multiple protocols, such as, for example IIOP, RMI, Sockets, HTTP, HTTPs, and Files. JTC has natural support for client Java accessible RS232 devices and APIs such as currency counters, J/XFS, printers, and coin dispensers.

With reference now to FIG. 5, a diagram illustrating the components in an architectural pattern is depicted in accordance with a preferred embodiment of the present invention. Architectural pattern 500 includes a ViewController 502, which provides a display of a component, container or bean on a data processing system. ViewController 502 basically provides a reusable GUI element containing graphical components such as text fields, labels, buttons, tables, images, beans, etc. to be displayed for viewing and interacting by a user. ValidationRules 504 are used to validate and format the user entry into components contained within the ViewController. For example, ValidationRules 504 may be applied to a single text field or to groups of text fields used for user entry. If a violation of a rule occurs, ValidationRuleException 506 is generated.

User inputs occur on the components, containers and beans controlled by ViewController 502. This user input is in the form of an AWTEvent 508 in the depicted examples. The AWTEvent 508 may be, for example, the click of a mouse button selecting a graphical button such as an "okay" button. In response, ViewController 502 will fire ViewEvent 510. ViewEvent 510 will contain major and minor codes that add more semantics than the AWTEvent 508. The changed data that may have been modified or entered by user or a reference to the data model may also be supplied for further semantics. AWTEvents 508 are not visible outside of the ViewController 502.

Next in architectural pattern 500, ApplicationMediator 512 is a form of a ViewListener in the depicted examples. ApplicationMediator 512 is the interface used to specify default behavior to control ViewController 502 as well as other ApplicationMediators 512. ApplicationMediator 512 will also mediate between ViewController 502 generated ViewEvents 510 and PlacementListener 514, TopListener 516 and Transporter 524. In this pattern, PlacementListener 514 is employed to manage the placement/containment of ViewControllers, such as ViewController 512 on the screen of a computer. PlacementListener 514 will manage ViewController 502 in response to a PlacementEvent 518 received from ApplicationMediator 512. For example, for a given component, container or bean represented by ViewController 502, PlacementListener 514 will control how ViewController 502 is placed on a screen, such as possibly in the south of a frame with a border layout.

ApplicationMediator 512 controls the ordering of ViewControllers, not the placement of ViewControllers. As a result, complete separation between view creation and layout by ViewController 502, view ordering and mediation by ApplicationMediator 512, and view placement by PlacementListener 514 is provided. This mechanism in architectural pattern 500 increases the reusability of ViewControllers, ApplicationMediators, and PlacementListeners. PlacementEvent 518 is used to notify PlacementListener 514 if ViewController needs to be adjusted on the screen.

Next, TopListener 516 is an interface that performs specific desktop duties, such as, for example, the launching of an application, performing a desktop shutdown, displaying a message on the desktop, displaying a context sensitive title on the desktop or reconfiguring and non-intrusive observing the JTC application. TopEvent 520 is used to send a message to the TopListener to indicate that some action is needed on the desktop.

A desktop provides the operating-specific functionality of a windowing system and application management. For example, in Windows 95, the graphical interface that starts up is called a "desktop". The Windows 95 GUI itself is the "desktop system". Additionally, a desktop application provides a view or window in which an application may run and launch other applications. This is typically accomplished by a display of a hierarchical list of applications, which may be selected and "launched".

ApplicationMediator 512 may generate and receive RequestEvents, such as RequestEvent 522. A RequestEvent, as used herein, represents a "lightweight transaction" that is used as an indication that an event and a service is required to process the event. A RequestEvent 522 is identified by major and minor codes. In addition, a reference to a data model may be included for additional semantics. In turn, Transporter 524 in architectural pattern 500 is used to map RequestEvents, such as RequestEvent 522, to Destinations 528, 530, and 532. In other words, Transporter 524 acts as an event broadcast mechanism within architectural pattern 500. Transporter 524 will route RequestEvents, such as RequestEvent 526 to various Destinations, such as Destination 528, Destination 530, or Destination 532. These destinations will interpret the RequestEvent 526, locate a server, create a message format, create a protocol and deliver the information to the server's service for processing. These response data will be returned to the Transporter 524 in a RequestEvent, such as RequestEvent 526. In turn, Transporter 524 will return the RequestEvent to ApplicationMediator 512, which will process the data contained in the event accordingly. For example, the return data may be sent to ViewController 502 to refresh the view displayed on the screen to the user. If an error occurs, a RequestException 534 may be generated and returned to Transporter 524 and returned to the ApplicationMediator 512.

The ApplicationMediator 512 can fire RequestEvents to the Transporter synchronously, asynchronously and repeating asynchronously. A synchronous RequestEvent will block the ApplicationMediator and either an error RequestException will be thrown or a possibly modified RequestEvent will contain the results. An asynchronous RequestEvent will return immediately. The error RequestException or a possibly modified RequestEvent will later be "called back" to the ApplicationMediator at the requestException and requestResponse interface, respectively.

In depicted examples, a type Object data, such as Data 536 may be passed in reference by ViewController 502 to a Destination such as Destination 1528. This data is passed via different events, such as ViewEvent 510, RequestEvent 522, and RequestEvent 526. Changed data, such as Data 538 may be returned from a Destination to ViewController 502 for display. This type Object data may take various forms, such as Extensible Markup Language (XML), String, Hypertext Markup Language (HTML), key/value, Remote Method Invocation (RMI), J/XFS, RS232, etc. The ViewController reads and modifies the Object data but does not create the data and the Destination creates, reads and modifies the Object data and sends it to and receives it from a server.

In addition, architectural pattern 500 also includes a Factory 540, which is used to allocate objects. Factory 542 is employed to also allocate singleton objects.

JTC 544 the system also contains a JTC interface implemented by all major objects in a JTC application including ApplicationMediator, ViewController, Destination and Transporter. Together, the objects implementing the JTC interface give the external appearance of a single application as they implement and propagate the required JTC interface methods.

The architectural pattern separates ViewController 502 (GUI view) from ApplicationMediator 512 (GUI state transition) from PlacementListener 514 (GUI placement) from RequestEvent 522 (lite transaction) creation from Destination 528 (transaction dispatch) from data creation 528, from data usage 502, and from transaction fulfillment.

The JTC interface of the present invention provides automatic non-intrusive tracing of application, and automatic non-intrusive event logging of application.

The ValidationRules provide class separation of chained field validation logic from both GUI and data model. Also the ValidationRules can run on client, server, or both.

The Destinations provide plugable data model, network protocol, and message format modules for remote or local fulfillment. Further, Destinations can support both local and remote configurations in addition to multiple chains of them being called FIFO. The simpler the Destinations, the thinner the application. The more complex the Destinations, the thicker the application.

The ApplicationMediators can be nested. PlacementListeners provide for partitioning of how to place components on the screen from what the components are and what order they arrive. RequestEvents (lite transactions) can be broadcast to multiple servers using multiple network protocols with various data and message formats.

The architecture also provides permission keys to support intra and inter ViewController and ApplicationMediator user ID and/or group enabling and disabling, and provides settable generic field level, focus level, and RequestEvent level ValidationRule invocation.

The ViewControllerBaseImpl provides a mechanism to switch between various graphics containers. The example code described herein is illustrated in Java, but the processes of the present invention may be applied to other programming languages.

IV. Class Hierarchy

With reference now to FIG. 6, a diagram illustrating classes in a class hierarchy is depicted in accordance with a preferred embodiment of the present invention. Class hierarchy diagram 600 illustrates the class hierarchy of new classes introduced by the present invention. All of the classes are inherit from the class java.lang.Object. These classes provide an architectural pattern for client development in Java. The classes illustrated in class hierarchy diagram 600 contain interfaces and classes to support the architectural pattern of the present invention. Although the depicted examples are illustrated with respect to Java, the architectural pattern of the present invention may be applied to other types of programming environments. The depicted examples are not meant to be limitations on the programming environment in which the present invention may be applied.

With reference now to FIG. 7, a unified modeling language diagram is depicted in accordance with a preferred embodiment of the present invention. Unified modeling language (UML) diagram 700 is a diagram illustrating the class hierarchy between various classes and interfaces within the architectural pattern of the present invention.

UML diagram 700 uses the following conventions. A sub-interface of another interface (e.g., ViewController 702 to JTC 742) or a subclass of another class (e.g., ViewControllerImpl 704 to ViewControllerBaseImpl 706) is shown by a solid line from the subclass to the parent class where there is an open arrowhead. If a class is used to implement an interface, then a dashed line goes from the class to the arrowhead at the interface (e.g., ApplicationMediatorImpl 720 to ApplicationMediator 718). A class or interface may be aggregated into another; this is indicated by a solid line connecting to a small diamond (e.g., ViewEvent 714 to ViewListener 718). The end with the small diamond represents the class that is aggregating (or containing) the class at the other end. The multiplicity of the association is indicated by numbers at each end of the line, such as ViewEvent having multiplicity of 0 to many (with "many" indicated by "*") and ViewListener 718 having multiplicity one. So each instance of a ViewListener 718 may contain zero or more instances of ViewEvent 714.

Occasionally, alternative methods may be present for implementing an object. For example, ViewControllerBaseImpl 706 may implement a Container by either using the Java Abstract Window Toolkit (AWT) Panel 707 or a JFC 709. The small dashed lines indicate a choice.

Turning now to a discussion of the classes illustrated in FIGS. 6 and 7, ViewController 702 is an interface that defines an interface for a class that will be a single Component containing user interface components that are logically related to show information to the user and take input from the user. In particular, ViewController 702 is a public interface that defines reusable graphics components as part of an overall client application.

With reference now to FIGS. 8A and 8B, diagrams illustrating variables and methods in ViewController 702 are depicted in accordance with a preferred embodiment of the present invention. The abstract ViewControllerImpl class implements the ViewController interface to provide default behavior where possible. The user can subclass ViewControllerImpl so that not all of the interface methods of ViewController need be implemented.

The ViewControllerImpl 704 is an abstract class implementation of ViewController. ViewControllerImpl 704 and ViewController 702 are the basic GUI building blocks for thin clients. ViewControllerImpl 704 provides the function that will be required by a subclass (not shown) ViewControllerImpl 704 is controlled and mediated by an ApplicationMediator. ViewControllerImpl 704 extends the ViewControllerBaseImpl class and implements the ViewController interface so as to support the event handling methods and provide a default implementation for the other ViewController methods. This class maintains a reference to the client data model, the user validation level, and the UI properties and resources. Methods are present to add and remove listeners for view events generated, fire (send) view events to the appropriate listeners, cleanup list of event listeners on clear and exit, and enable or disable the panel.

With reference now to FIGS. 9A-9E, diagrams illustrating variables, constructors, and methods for ViewControllerImpl 704 are depicted in accordance with a preferred embodiment of the present invention. Table 900 in FIG. 9A illustrates the variables used in ViewControllerImpl 704. The tables used to describe the class include a name of the variable, constructor, or method, a declaration for the variable, and a description for the variables. Table 902 in FIG. 9B contains a similar table for the constructor used in ViewControllerImpl 704. Table 904 in FIGS. 9A-9E provides a list of the methods used within ViewControllerImpl 704. Similarly, table 904 includes a name for the method, a declaration used for the method, and a description of the method.

ViewControllerImpl 704 is usually a Java Component or Container or bean with the extra methods specified here. The basic operation of a ViewControllerImpl is handles using the following steps: (1) implement the ViewController and JTC interfaces; (2) add your bean specific methods; (3) create and compose GUI; (4) return the Component in getComponent( ); (5) return and set permission keys, resources and properties when asked; (6) update permission keys, resources and properties when asked; (7) handle internal AWT events; (8) validate and format fields with ValidationRules; (9) issue ViewEvents for semantic interpretation; (10) return to the AWT Thread as soon as possible; (11) handle refresh (data) calls by updating GUI; (12) access data; and (13) repeat from step (3).

ViewControllerImpl 704 is controlled and mediated by an ApplicationMediator. The default function provided by this class includes: from ViewController interface: add/remove ViewListener, fireViewEvent, setValidationLevel, refresh, getComponent, and AWTEvent threading. From the JTC interface, the functions provided include: clear, exit, set/getEnabled, set/getVisible, and toString.

ViewControllers know the full semantics of the data model being used, even though only a generic Object data; type reference is provided. The ViewControllers will cast generic reference into Class based data objects. Some design principles to use in ViewControllers when deciding how to communicate information to ViewListeners are described below.

A ViewEvent is created, its setter methods are called, and it is fired to the ViewListeners. The listeners interpret the major and minor codes to decided what to do.

To provide additional information, the ViewController can set a Java data object in the ViewEvent using the setData method. The data reference can be simple String objects or user defined data objects.

A similar approach to provide additional information is for the ViewController to supply application defined objects using the setData method. The data reference are more complex than simple objects (i.e. Customer, AccountInfo, Schematic, CarSpec, etc.).

The ViewController also can provide named methods. For example, a ViewListener may call customerVC.getCustomerName( ) to retrieve the customer name. The implementation of getCustomerName is hidden by the ViewController and could involve manipulating several Java Components. In addition, setters may also be provided, such as VC.setCurrentCustomer( ). In general, too many named methods may suggest that information sharing should be via data objects within ViewEvents and refresh methods instead. The use of named methods may reduce reuse of a ViewController by an ApplicationMediator.

The ViewController may listen to property change events on a data model using standard Java mechanisms. Thus, the ViewListeners, the ViewControllers, or any other interested object can communicate via the data model changes. In general, this is very data-oriented object model programming approach and can lead to object-spaghetti code. Changes in the data model ripple throughout the application.

ViewControllerBaseImpl 706 is an abstract class and is a superclass of ViewControllerImpl 704. This class provides the indirection to allow specification of the Component type of the ViewController via a "has a" and/or "is a" relationship. The idea is for the developer to replace this class entirely with the developer's own implementation. This replacement may be accomplished by creating the developer's own implementation of ViewControllerBaseImpl that implements the methods getComponent( ), setEnabled (boolean enable), and setVisible (boolean visible). ViewControllerBaseImpl 706 is generally used with either JPanel 707 or a java.awt.Panel 707 by changing the inherits statement. ViewControllerBaseImpl may also be used with any Java or user-defined component or container. The variables, constructors, and methods for ViewControllerBaseImpl 706 are found in FIGS. 10A-10C. The variable for ViewControllerBaseImpl 706 is found in table 1000 in FIG. 10A while the constructors are listed in table 1002 in FIG. 10B. The methods are listed in table 1004 in FIG. 10C.

ViewControllerAdapter 708 is an abstract class and is a helper adapter class that fits between ViewControllerImpl 704 and the developer's subclass. ViewControllerImpl 704 implements almost all of the standard Java AWT listeners and provides empty methods. This class allows ViewControllers to be implemented without having to specify all of the methods of a Java AWT listener interface when a subclass being created needs only one such method.

ViewControllerAdapter 708 implements the following AWT event listeners: AdjustmentListener, ComponentListener, FocusListener, ItemListener, KeyListener, MouseListener, TextListener. This class knows about everything that ViewControllerImpl knows, and also knows the default empty implementation of AWT event listener methods. The methods on the class allow for adding and removing of listeners for view events generated, firing (sending) of view events to the appropriate listeners, cleaning up the list of event listeners on clear and exit, and enabling or disabling the panel.

FIGS. 11A-11C illustrate a variable, a constructor, and methods for ViewControllerAdapter 708. Table 1100 in FIG. 11A illustrates the variable while table 1102 in FIG. 11B illustrates the constructor of ViewControllerAdapter 708. Methods for ViewControllerAdapter 708 are shown in table 1104 and FIG. 11C.

ValidationRule 710 is an abstract class for class-based value validation rules used to validate and format ViewController contents. Validation is normally used for single or groups of text fields (user entry). Examples include range checking, date, social security number, or other business specific formats. The definition of the validation rules are kept out of the data models and ViewControllers to maximize reuse of validation logic. These types of objects only encode which rule to use.

Typically, validation rules have two methods: (1) edit and (2) normalize. The edit method is used to input a string, validate the value and output the view friendly formatted string. The normalized method is used to input a string, validate the value and output a string that will be set into the data model and/or transmitted via a RequestEvent to a destination. For example, given a value of "1000.0", edit will produce "$1,000.00" and normalize will produce "1000". The ValidationRule 710 provides two static helper functions to apply edits or normalizes on an input string given a list of edit rule class names. This is called ValidationRule chaining. In this manner, ValidationRule 710 allows a developer to keep the implementations of validation rules small and simple so as to maximize reuse of validation code. Additionally, ValidationRule 710 may be run on a server. The methods can create an instance of a ValidationRule given a class name, apply edit rules sequentially on a string given a list of ValidationRule class names, or apply normalize rules sequentially on a string given a list of ValidationRule class names. Invocation of a validation rule is initiated by the ViewController or some business logic method. In case of failure, a ValidationRuleException is thrown.

With reference now to FIGS. 12A-12C, drawings illustrating variables, constructors, and methods for ValidationRule 710 are depicted in accordance with a preferred embodiment of the present invention. The variables are illustrated in table 1200 in FIG. 12A while the constructor is shown in table 1202 in FIG. 12B for ValidationRule 710. The methods used in ValidationRule 710 are shown in table 1204 in FIG. 12C. FIG. 12D contains code 1206, which is used to apply ValidationRules for classes in response to ValidationRule 710 being given a list of class names for processing). Code 1206 will apply each ValidationRule for a class and return a formatted result. A similar code is used for ValidationRule.applyNormalizes.

ValidationRuleException 712 is a class that extends the Exception class in Java to represent the type of exceptions thrown by rules defined in ValidationRule 710. ValidationRuleException 712 is generated when a validation rule has failed. The cause of the failure is contained in the exception. In the depicted examples, processing of remaining validation rules will halt. This class needs to know the validation rule exception string.

With reference now to FIGS. 13A and 13B, tables illustrating variables and constructors for a ValidationRuleException are depicted in accordance with a preferred embodiment of the present invention. Table 1300 in FIG. 13A illustrates a variable while table 1302 in FIG. 13B illustrates constructors for ValidationRuleException 712.

ViewEvent 714 is a class having a mechanism used for communication between ViewControllers and ViewListeners, such as ApplicationMediators and between ApplicationMediators. Notification occurs when a significant AWTEvent has occurred that the ViewController cannot handle. Both ViewControllers and ApplicationMediators can fire ViewEvents. The ViewEvent state includes a major code, a minor code, a source Object of the event, and a generic Object data reference. Numerous predefined major codes and minor codes are provided and a subclass can define additional application specific codes.

When a ViewController fires a ViewEvent, it is handled in the ApplicationMediatorImpl superclass first and then forwarded to the ApplicationMediatorImpl subclass in the processViewEvent method. This mechanism allows threading and queuing to be handled by the superclass. Dispatching a ViewEvent to a subclass is performed in one of two ways: queued-event dispatching and thread-event dispatching.

With reference now to FIGS. 14A-14D, diagrams illustrating variables, constructors, and methods for ViewEvent 714 are depicted in accordance with a preferred embodiment of the present invention. Table 1400 in FIGS. 14A-14D illustrates variables for ViewEvent 714. Table 1402 in FIG. 14E shows the constructors for ViewEvent 714. The methods for ViewEvent 714 are shown in table 1404 in FIG. 14F.

ViewListener 716 is an interface for receiving ViewEvents generated by ViewControllers. The listener will be called back on the viewEventPerformed method. ViewListener 716 interprets the values from the ViewEvent and decides what action to take. If more information needs to be conveyed, ViewListener 716 gets the data variable. A ViewListener can set the ViewEvent to be consumed. When the ViewEvent is consumed, the ViewEvent will not be forwarded to other ViewListeners.

Turning now to FIGS. 15A and 15B, diagrams illustrating a variable and a method for ViewListener 716 are depicted in accordance with a preferred embodiment of the present invention. The variable for ViewListener 716 is shown in table 1500 in FIG. 15A. The method used in ViewListener 716 is shown in table 1502 in FIG. 15B.

ApplicationMediator 718 is an interface that specifies methods for the management of PlacementListeners, ViewListeners, RequestListeners, TopListeners, permissions, properties, resources, visibility, validity. ApplicationMediator 718 also defines a generic method to refresh data. ApplicationMediator 718 defines the interface for a class that will mediate multiple ViewControllers or other ApplicationMediators. Methods are provided in this class to add and remove PlacementListeners for the ViewControllers, to add and remove TopListeners for the ApplicationMediator, to add and remove RequestListeners for RequestEvents generated, and to add and remove ViewListeners for ViewEvents passed up from the ViewControllers. Other methods in the ApplicationMediator 718 set the data used by the ViewControllers, tell where and how to handle ViewEvents generated by ViewControllers, and generate RequestEvents based on some application logic of ViewEvents. Methods are provided in this interface to set the property information and the resources used by the ViewControllers.

The FIGS. 16A and 16B, diagrams illustrating a variable and methods for ApplicationMediator 718 are depicted in accordance with a preferred embodiment of the present invention. Table 1600 in FIG. 16A illustrates the variable used for ApplicationMediator 718 while table 1602 in FIG. 16B illustrates the methods used in ApplicationMediator 718.

ApplicationMediatorImpl 720 is an abstract class, implements the ApplicationMediator interface, and provides default behavior to manage ViewControllers, ApplicationMediators, add/fire/remove of PlacementListeners, RequestListeners, ViewListeners and TopListeners. A subclass of ApplicationMediatorImpl 718 should focus on managing the state machine for ordering the ViewControllers it creates and the mediating of prevents. This focus includes determining which ViewController to allocate, which ViewController to make visible, when to fire a PlacementEvent, when to fire a RequestEvent, and when to fire a TopEvent. A default list is provided to hold ViewControllers. The default list is a Vector and is directly available to subclasses. An ApplicationMediatorImpl 720 may create other ApplicationMediators. As a result, a list to hold ApplicationMediators also is provided.

The helper methods initApplicationMediators and initViewControllers will load their respective classes and store them in Vectors. The helper methods getAM, getVC, setAM, and setVC provide a way to get/set the elements in the Vectors.

When a ViewController fires a ViewEvent, the ViewEvent is handled in ApplicationMediatorImpl 720 first and then forwarded to the subclass (not shown) in the processViewEvent method. This process allows threading and queuing to be handled first by ApplicationMediatorImpl 720.

ApplicationMediatorImpl 720 needs to have reference to the client data model, PlacementListeners, TopListeners, ViewListeners, ViewControllers, other ApplicationMediators, UI properties and resources, and Event processing threads.

Methods are provided in ApplicationMediatorImpl 720 to add and remove listeners for ViewEvents generated or forwarded from a ViewController, to fire (send) ViewEvents to the appropriate listeners, to add and remove listeners for RequestEvents generated, and to fire TopEvents and to fire (send) synchronous or asynchronous RequestEvents to the appropriate listeners. Other methods add and remove listeners for PlacementEvents generated, fire (send) PlacementEvents to the appropriate listeners, and cleanup a list of event listeners and event processing threads on clear and exit. It is also possible to enable or disable the visibility, create, initialize, and manage ViewControllers, and to create, initialize, and manage other ApplicationMediators. Other methods get references of all JTC objects managed, set client data references for all ViewControllers and ApplicationMediators managed, add TopListeners, and handle the processing of a received ViewEvent in a separate thread (either in a queue fashion or unique thread per event).

Turning next to FIGS. 17A-17E, diagrams illustrating variables and a constructor for ApplicationMediatorImpl 720 are depicted in accordance with a preferred embodiment of the present invention. Table 1700 in FIG. 17A illustrates variables for ApplicationMediatorImpl 720 while table 1702 in FIG. 17B shows the constructor used in ApplicationMediatorImpl 720. Table 1704 in FIGS. 17C, 17D, and 17E illustrate the methods used in ApplicationMediatorImpl 720.

With reference now to FIGS. 17F-17I, diagrams illustrating code used in methods for ApplicationMediatorImpl 720 are depicted in accordance with a preferred embodiment of the present invention. In FIG. 17F, code 1706 illustrates code used in an exit method for ApplicationMediatorImpl 720. This code allows the ApplicationMediator to be exited by exiting all allocated ViewControllers and ApplicationMediators. All data will be set to null by code 1706 and all lists destroyed.

In FIG. 17G, code 1708 illustrates code used to clear an ApplicationMediator by clearing all allocated ViewControllers and ApplicationMediators. The data is set to null, but the lists are not destroyed. A cleared ApplicationMediator can be used again. In FIG. 17H, code 1710 is used to initialize an ApplicationMediator using the listeners of an existing ApplicationMediator. In FIG. 17I, code 1712 is used to refresh an object. This code is used to refresh ViewControllers and ApplicationMediators when new data arrives. In FIGS. 17I-17L, depicts code 1714 which is used to handle the event dispatch.

PlacementEvent 722 is a class used to notify PlacementListeners that a ViewController needs to be adjusted on the screen. The value stored in a PlacementEvent 722 are: (1) major code indicating the placement type; (2) minor containing additional information; (3) source, which indicates the sender of the event; (4) Component, which is the ViewController's component; and (5) data, which is a generic Object data, containing the type to pass more information and is typically not the same type of data sent in ViewEvents and RequestEvents. Predefined placement types, which are used as major codes include, for example, add, remove, and modify. A subclass may define more application specific PlacementEvent codes. Additional information may be conveyed through the use of the minor variable or by supplying real data.

With reference now to FIGS. 18A-18C, diagrams illustrating variables, constructors, and methods for a PlacementEvent are depicted in accordance with a preferred embodiment of the present invention. Table 1800 in FIG. 18A illustrates variables used within PlacementEvent 722 while table 1802 in FIG. 18B show constructors used for PlacementEvent 722. Table 1804 in FIG. 18C shows the methods used within PlacementEvent 722.

PlacementListener 724 is an interface used to manage the placement of ViewControllers on the screen. For a given component or container, such as a ViewController, PlacementListener 724 controls the placement while ApplicationMediator controls the ordering of ViewControllers instead of their placement. For example, if a designer wishes to create a split pane with a tree in the left pane that allows selection of ApplicationMediators, ViewControllers will display on the right. As a result, an "add" method is called to the split pane. If a frame is used, "add" has a different syntax. An object handling placement of components will register as a listener for notifications to place objects on the screen. This role is the one played by PlacementListener 724. The ApplicationMediator controls the ordering of ViewControllers, not their placement. A PlacementListener adds itself to a PlacementEvent generator and is called back with a PlacementEvent which indicates a desired action. This mechanism allows complete separation between view creation (ViewController), view ordering (ApplicationMediator), and view placement (PlacementListener). This arrangement increases the reusability of ViewControllers and ApplicationMediators to nearly 100% with respect to placement.

With reference now to FIGS. 19A and 19B, diagrams illustrating a variable and method for a PlacementListener are depicted in accordance with a preferred embodiment of the present invention. Table 1900 in FIG. 19A illustrates the variable used in PlacementListener 724 while table 1902 in FIG. 19B illustrates the method used in PlacementListener 724.

TopEvent 726 is a class used to notify TopListeners that ApplicationMediator needs some desktop function to occur. The value stored in TopEvent include: (1) major, which identifies the TopEvent type; (2) minor, which contains additional information; (3) source, which identifies the sender of the Event; (4) consume, which will result in the Event being processed if true; and (5) data, which is a generic object data used to pass more information. Predefined types, which are used as major codes include, for example, EXEC, BROWSER, TITLE, STATUS, and OS. This category of types is used for interaction with the desktop (operating system, browser, other applications). Additional major codes include TRANSPORTER, DESTINATION, APPLICATION_MEDIATOR, REQUEST_EVENT, VIEW CONTROLLER, VIEW_EVENT, TOP_LISTENER, TOP_EVENT, PLACEMENT_LISTENER, PLACEMENT_EVENT, MAJOR, MINOR, AWT_EVENT, and JTC. This category of types is used to indicate a reconfiguration of the JTC application. Additional TopEvent codes may be defined through the use of subclasses. Additional information may be conveyed by using the minor variable or supplying real data.

With reference now to FIGS. 20A-20C, diagrams illustrating variables, constructors, and methods for a TopEvent are depicted in accordance with a preferred embodiment of the present invention.

Table 2000 in FIG. 20A illustrates the variables contained in <update this tabled based on latest javadoc contents> TopEvent 726 while table 2002 in FIG. 20B shows the constructors for TopEvent 726. The methods for TopEvent 726 are found in table 2004 in FIG. 20C. TopListener 728 is an interface that performs business specific desktop duties for a display. TopListener 728 provides an interface that is highly customizable for each business application. This interface specifies a topEventPerformed method to receive a TopEvent encoding a task to be performed.

With reference now to FIG. 21A and 21B, diagrams illustrating a variable and methods for TopListeners are depicted in accordance with a preferred embodiment of the present invention. Table 2100 in FIG. 21A illustrates the variable for TopListener 728 while table 2102 in FIG. 21B illustrates the methods in TopListener 728.

The RequestEvent 730 is a class that extends EventObject to represent RequestEvents generated by ApplicationMediators. This class represents a lite-weight transaction. The instances of this class denotes a unit of work. RequestEvent 730 represents a request for a transaction or data from a source external to the application. The request is handled by a remote or local destination. The Transporter is responsible for mapping RequestEvents to Destinations. The state of a RequestEvent 730 includes the following information: (1) major code identifying a family of RequestsEvents; (2) minor code identifying a specific request under the family); (3) version, which is usually user defined; (4) status which may be an appended string showing the stages of processing; (5) consume (a consumed Request Event will cause JTC to stop processing the Request Event); and (6) data, which may be, for example a reference to generic Object data. A RequestEvent can be set to be consumed in which case Destinations and the Transporter will halt forwarding of the RequestEvent and return control to the ApplicationMediator.

Turning now to FIGS. 22A-22C, diagrams illustrating a variable, constructors, and methods for RequestEvent are depicted in accordance with a preferred embodiment of the present invention. Table 2200 in FIG. 22A illustrates the variable in RequestEvent 730. Table 2202 in FIG. 22B shows the constructors used in RequestEvent 730. Table 2204 in FIG. 22C illustrates the methods in RequestEvent 730.

RequestException 732 is a class that extends Exception to represent the type of exception thrown when there is a problem in submitting a RequestEvent. This class is used when the processing of a RequestEvent causes an error condition. This exception can be thrown directly when a synchronous or asynchronous RequestEvent is performed. This indicates failure in synchronous processing or failure in the fire mechanism. The exception can be thrown indirectly when asynchronous RequestEvent is processed. The cause of the failure is also indicated in the exception in the depicted examples. Thus, this class needs to know the string representing the reason for the RequestEvent exception.

With reference now to FIGS. 23A-23C, diagrams illustrating a variable, constructors, and methods for RequestException 732 are depicted in accordance with a preferred embodiment of the present invention. Table 2300 illustrates the variable for RequestException 730 while table 2302 in FIG. 23B illustrates the constructors used in RequestException 732. The methods for RequestException 730 are found in table 2304.

The RequestListener 734 is an interface that defines the method for a class to implement for receiving synchronous or asynchronous RequestEvents. This interface is implemented by classes that want to listen and be notified when a RequestEvent is fired. A typical example is a Transporter instance. The RequestListener is added to an ApplicationMediator as a listener for RequestEvents. Two styles of notification are possible: synchronous and asynchronous. The Transporter implements the RequestListener interface to map RequestEvents to Destinations. Other classes can implement the RequestListener interface and register for RequestEvents to monitor them. A RequestException can be thrown directly when invoking synchronous and asynchronous RequestEvents or on a callback when invoking only asynchronous RequestEvents.

With reference now to FIGS. 24A and 24B, diagrams illustrating a variable and methods for a RequestListener are depicted in accordance with a preferred embodiment of the present invention. Table 2400 in FIG. 24A illustrates the variable in RequestListener 734 while table 2402 in FIG. 24B illustrates the methods used in RequestListener 734.

RequestResponseListener 736 interface is implemented by a class that requires asynchronous RequestEvent processing. For example, when an ApplicationMediator implements this interface, it will be called back on one of the two methods after it fires asynchronous RequestEvents. Successful RequestEvents are returned through the requestResponse method and passed a RequestEvent that may have new data. Unsuccessful RequestEvents are returned through the requestException method and the RequestException contains the reason.

Turning now to FIGS. 25A and 25B, diagrams illustrating a variable and methods for a RequestResponseListener are depicted in accordance with a preferred embodiment of the present invention. Table 2500 in FIG. 25A shows the variable in RequestResponseListener 734 while table 2502 in FIG. 25B illustrates the methods in RequestResponseListener 736.

The Transporter 730 is a class that implements the JTC and RequestListener interfaces. The primary function of Transporter class 730 is to map RequestEvents to Destinations. In other words, Transporter 738 acts as an event broadcaster to route RequestEvents to the appropriate Destination. Typically, ApplicationMediators fire RequestEvents which are routed to a Destination by the Transporter. The Destination processes the RequestEvent by performing some interpretation and sending them to a target, such as a server. This event broadcasting is performed by Transporter 738 based on the major code of the RequestEvent in the depicted examples. Transporter 736 needs to know the Destinations, the major codes registered by the Destinations, RequestEvents, RequestResponseListener, and RequestExceptions.

Methods are provided in Transporter 738 to register a Destination that processes RequestEvents with a specific major code, remove the registration of a Destination, receive a RequestEvent for synchronous or asynchronous processing, handle the processing of a received asynchronous RequestEvent in a separate thread (either in a queue fashion or unique thread per event), and return a list of Destinations registered for a specific key (major code). Other methods cancel the processing of an asynchronous RequestEvent, cleanup threads and lists of Destinations on clear and exit, enable or disable the sending of RequestEvents to Destinations, and enable or disable the tagging (status setting) of RequestEvents.

With reference now to FIGS. 26A-26D, diagrams illustrating variables, a constructor, and methods for a transporter are depicted in accordance with a preferred embodiment of the present invention. Table 2600 in FIG. 26A illustrates variables for Transporter 736 while table 2602 in FIG. 26B illustrates a constructor for Transporter 738. The methods for Transporter 738 are illustrated in table 2604 FIG. 26C.

Turning now to FIGS. 26DC-26D diagrams illustrating code used in methods in Transporter 738 are depicted in accordance with a preferred embodiment of the present invention. Code 2604 in FIG. 26E illustrates processing or selecting Destinations in response to a RequestEvent. Given a RequestEvent of Destinations, code 2604 will call each Destination in a first in first out (FIFO)/first exception first return (FEFR) order. Code 2606 in FIG. 26F illustrates a process for submitting a synchronous request. For each Destination listening for the current family of RequestEvents, as indicated by the major code, the RequestEvent is sent to a Destination for processing. If a problem occurs, a RequestException is thrown. Processing the RequestEvent will occur as long as a RequestException being thrown is not from a Destination and the RequestEvent is not consumed. Submission of an asynchronous request is performed by code 2608 in FIG. 26G. Code 2610 in FIG. 26H illustrates code for handling executions of submits on another thread.

The Destination 740 is an interface used to pass results or events. This interface is implemented by classes that want to listen to Transporters and send RequestEvents to servers. Destination 740 performs the following functions: (1) server: locate it; (2) network transports: create the low level protocols such as sockets, RMI, URLs, Files, etc.; (3) server types: be able to talk to different servers such as EJBs, Servlets, web servers, legacy, etc.; (4) message formats: be able to turn RequestEvents and data into formats that the servers understand; (5) timeouts: finish the job in the appropriate amount of time or cancel the operation; (6) retries: how many times should a connection be tried; (7) caching: save data until it becomes stale; (8) stale data: detect stale data; (9) heart beats: I am alive; (10) logging: save pre and post RequestEvents; and (11) objects: locate them, create them.

Example Destinations behaviors include the following: (1) serializing a request and writing it to a socket, (2) reading and writing requests and responses from a file for demonstrations, (3) casting the data in a RequestEvent into objects and so that RMI methods are visible, (4) debugging, (5) tracing, (6) compression, (7) encryption, and (8) translation.

A Destination 740 is first added to a Transporter as a RequestListener, listening for RequestEvents of a specific major code. When RequestEvents enter the Transporter, these RequestEvents are sent to each listening Destination via a requestEventPerformed. Additionally, a Destination monitors the state of the consumed attribute of the RequestEvent and will terminate processing when the state is true.

RequestEvents are identified by a major code (represents a family of Requests) and a minor code (represents a specific Request). Destinations are added to the Transporter as DestinationListeners specifying a major code for RequestEvents they are interested in receiving. The Destination is called when the major code of the RequestEvent matches the Destination's major code. Multiple Destinations can listen for the same RequestEvent major code and results of one Destination can be passed to the next Destination. RequestEvents are processed in a first in first out (FIFO)/first exception first return (FEFR) order.

With reference now to FIGS. 27A and 27B are diagrams illustrating a variable and methods for a Destination in accordance with a preferred embodiment of the present invention. Table 2700 in FIG. 27A illustrates the variable in Destination 740 while table 2702 in FIG. 27B illustrates the methods used in Destination 740.

DestinationImpl 742 is an abstract class that implements the Destination interface and provides a default implementation for the Destination interface methods. It needs to know whether the Destination is enabled or disabled, whether the RequestEvents are tagged with a status or not, and the RequestEvent processing timeout value. Methods are provided to enable or disable the processing of RequestEvents in the Destination and to set the RequestEvent processing timeout value.

With reference now to FIGS. 28A-28C, diagrams illustrating variables, constructors, and methods for a DestinationImpl are depicted in accordance with a preferred embodiment of the present invention. Table 2800 in FIG. 28A illustrates the variable used in DestinationImpl 742 while table 2802 in FIG. 28B illustrates the constructor used in DestinationImpl 742. Methods for DestinationImpl 742 are illustrated in table 2804 in FIG. 28C.

In FIG. 28D, code 2806 is used to process a RequestEvent. If an application uses a set of objects that perform the retrieval and update of data, then those objects can be accessed from a generic Destination class. Typically, a Destination implementation accesses a single interface class with methods and is written specifically to serve one purpose (i.e. the retrieval and update of customer data or the retrieval and update of employee data). However, a generic Destination class can be written to retrieve and update any set of data. The requirement is that the class/object that serves the data must all have methods with the same interface (in other words, they must take in the same number and type of object as parameters and return the same type or generic object.) This way, the Destination class can be implemented to use Java's reflection to access/create the object and invoke a particular method on the object. The major code of the RequestEvent can specify the class name and the minor code can specify the method name. The code in FIG. 28D shows how a Destination can be implemented to access an Enterprise JavaBean session bean instance from an application server using Java's RMI and Java's Reflection capabilities. The methods on the session beans all take a single parameter of type Object and return a parameter of type Object. The client user interface and the session beans know the specific type of data objects passed but the Destinations do not need to know about the data.

JTC 744 is an interface that provides a top level interface in the architecture of the present invention. All major objects in a JTC application implement this interface including the driver programs that launch the application/applet. This interface provides the ability to reference all objects using a single type. The behaviors expected include clear, exit, getJTCs, init, isEnabled, setEnabled, and toString. The interfaces that extending JTC are ViewController, ApplicationMediator, and Destination. The classes implementing JTC are ViewControllerImpl, ApplicationMediatorImpl, Transporter, and DestinationImpl.

Of particular importance is the getJTCs( ) method. Each JTC object returns the other JTC objects it creates. Iteration over these objects is possible. Inspection of the object types and addition of the appropriate listeners may be performed. This interface provides a mechanism for non-intrusive logging, tracing and debugging.

Factory 746 is a class used to make objects. This class is the place for code relating to prefetching, caching, and alternative "styles" for the new operator (or construction of objects), or loading a serialized object. The alternative "style" may be, for example, using Class.forName. The default behavior of a Factory includes, for example, creating a single object. Additionally, the behavior may include returning a previously created object if a key has been used or otherwise creating a new object and remembering the object.

Further, Factory 746 may be used to create multiple objects. Also, if a key[i] has been used, a previously created object may be returned. Otherwise, a new object [i] may be created and remembered by the Factory. For example, on a single JVM, a designer may want to create a single shared instance of a Transporter. Each access to the Transporter should be as follows: Transporter t=Factory.newInstance (com.ibm.jtc.Transporter, true). In this case, the Class.forName method is used with the key to create an instance of the Transporter. The true value indicates that a singleton may be created. The singleton may be turned off in which case all objects created are new and not remembered. Another key also may be used besides the class name. An example is as follows: Customer c=Factory.newInstance ("CUST", com.abc.Customer, true). The user can create a single object or create multiple of objects. For example, on a single JVM, a user may want to create and share one instance of a Transporter. The Factory class needs to know the list of singleton classes managed. The methods in this class provide several ways to create an instance of a class given one or more full path class name strings. The Factory class also can remove stored references of singleton classes.

With reference now to FIGS. 29A and 29B, diagrams illustrating variables and methods in a Factory are depicted in accordance with a preferred embodiment of the present invention. Table 2900 in FIG. 29A illustrates the variable used in Factory 746 while table 2902 in FIG. 29B illustrates the methods for Factory 744.

Q 740 is a class representing a queue of objects that are added and removed in first-in first-out (FIFO) ordering. The size of the queue can be set to a maximum or as unbounded. The structure maintains the queue of objects, the current size of queue, and the front and back ends of the queue. Methods are provided to add an object to the back end of the queue, remove an object from the front of the queue, and predicates to check if the queue is empty or full.

JTC 744 is a top level interface, which all major objects in an application created using the architecture of the present invention should implement. This would include driver programs that launch the application. This interface allows referencing of objects with a consistent type and a similar expected behavior.

Of particular importance in this class is the getJTCs( ) method. Each JTC object returns the other JTC objects it creates. With this interface, a process can iterate over these objects, inspect their types, and add the appropriate listeners. The system may be reconfigured through this interface. This reconfiguration includes, for example, disabling the Transporter, adding a priority Destination, and consuming an event. This interface provides an excellent mechanism for non-intrusive logging, tracing and debugging. For example, if a program Test1.java implements JTC, it will return the Transporter, ApplicationMediators and Destinations it creates.

With reference now to FIG. 30A and 30B, tables illustrating variables and methods in a JTC is depicted in accordance with a preferred embodiment of the present invention. Table 3000 in FIG. 30A illustrates variables in JTC while table 3002 in FIG. 30B illustrates methods for JTC.

V. Steps in Building an Application Using the JTC Architecture

A thin client application or a thick client application that follows the JTC architecture of the present invention can be built using a top-down, bottoms-up, or from the middle approach. All approaches allow for concurrent development within the JTC client application. All approaches all for concurrent development of the JTC client application and the server and services.

The following steps show a bottoms-up process. A proper design of interfaces and subsystem models, will ensure that the JTC application can be implemented in parallel.

A. Design Client Application Subsystems

The key to the successful implementation of a JTC application that has reusable and maintainable parts is the proper division of the application into logical subsystems. This division should be driven by the analysis of the application's domain. For example, using an object-oriented analysis of the application's domain, sets of use cases can be developed in the following manner. The actors external to the system are identified. For example, in designing an automated teller machine (ATM) the customer using the machine would be an actor and the bank's central computer is also an actor. The use case is a set of interactions the actor or actors have with the system. All sequences of interactions, including normal and exceptional behavior, should be specified. For example, normal behavior for withdrawing cash from an ATM would include a sequence of prompts and customer responses that eventually lead to the dispensing of cash. Exceptions would include an unreadable card, an incorrect PIN, insufficient cash in the machine, insufficient funds in the account, etc. Use cases can include a set of preconditions and post-conditions. A precondition for the ATM would be possession of an ATM card and a post condition, if the cash withdrawal is successful, would be an appropriate debit from the account balance.

The use cases produce natural divisions of function in an application. Use cases describe functions of the application that are most likely to be reused within and outside of the application. Each use case or possibly a group of fine-grained related use cases should make up the logical subsystem model. Groups of ViewControllers and ApplicationMediators are implemented in these subsystems. A ViewController is used to represent a single reusable screen or grouping of information to be inputted and/or displayed. An ApplicationMediator mediates multiple ViewControllers for a single application function or use case.

Other subsystems of the client application include a communications subsystem, a client startup subsystem, reusable graphical components, business validation rules, and enterprise policies.

The business logic and central data management of an application should be separated out from the JTC application. This business logic and data can be physically located on any machine. JTC clients typically do not keep or manage transaction states; server side business logic manages the transaction states. Therefore, the communications subsystem is responsible for the sending of data requests and transaction requests to the business logic outside of the application. This consists of the implementation of RequestEvents and Destinations.

A client startup subsystem manages the client application lifecycle and overall look and feel. This subsystem includes implementations of TopListeners and PlacementListeners.

Common reusable graphical components used by user interface panels should be separated out in their own subsystem so that they are designed and implemented for reuse and available to other subsystems and applications.

The rules for validating user input for display format and persistent storage should be separated into another subsystem. This allows for central maintainability of the rules and reuse across all other subsystems and applications. ValidationRules are implemented in this subsystem.

Enterprise policies include functions related to security, login/logout, users/groups/roles, profiles, locale; and languages. These requirements cross subsystems in a consistent and easily managed manner through methods including set/getProperties, set/getResources, set/getPermissions. Additional non functional enterprise polices such as caching, data pre-fetching and mobile users are implemented in common easily configurable Destination subsystems.

In a bottoms-up approach, the client data model should be developed next for the specific subsystem. This model specifies the structure and contents of data used by the client application. There are a variety of approaches to a client data model: Local Object Model, Workflow Object Model, XML, Named Methods, Key/Value Pairs, Ordinal Positioning, RMI, etc. To optimized concurrent development with the server and services, a bootstrap Key/Value data model is a sufficient and expeditious choice.

Once a data model approach is chosen, then the data objects must be created. These can be grouped and organized at different levels of granularity. In general, each component, such as, for example, a ViewController or an ApplicationMediator, should only reference the data the component uses or manages. For example, a ViewController should only have data required to be displayed on a single screen and the data input by the user on that screen.

B. Create a ViewController

In these examples, a ViewController is a panel that contains one reusable screen of user display and input. This screen can either contain Java Abstract Windowing Toolkit (AWT) components or Java Foundation Classes (JFC/Swing) components. The way to choose between the two types of components is to implement the ViewControllerBaseImpl class. The ViewControllerBaseImpl class can extend AWT's Panel class or JFC's JPanel class. Also ViewControllerBaseImpl can just contain a component, container or bean and return it in the getComponent( ) method. In a graphical user interface, components are organized into manageable groups through the use of containers. Additionally, a container may provide basic window and dialogue services. A java.awt.Panel itself is a pure container. A java.awt.Panel itself is not a window in itself, but its sole purpose is to organize components in a window. With reference now to FIG. 31, a flowchart of a process for creating a ViewController is depicted in accordance with a preferred embodiment of the present invention. A particular screen is selected to implement (step 3100) and a class is created that extends one of the ViewController implementation classes (step 3102). This class should have a suffix of VC to distinguish it as a ViewController class. The init( ) method is overridden (step 3104) and replaced with code to create, initialize, and layout graphical components of the panel. Visual builders (such as IBM VisualAge) can be used to create this method automatically. The refresh( ) method is overridden (step 3106). In this method, data to be displayed will be passed in. ViewControllers should be implemented to be reusable with different sets of data. By invoking refresh( ), ApplicationMediators can control for what purpose the ViewController is used. The clear( ) method is overridden (step 3108). In this method, the set of data used is cleared from use and display. This allows for the ViewController to be used with another set of data.

As part of component initialization, the ViewController is added as its component's event listeners (step 3110). The event listeners are implemented for the components (step 3112). ValidationRules are used to validate user input from a component event (step 3114). Use ViewEvents (described below) to send user inputted data or requests for more data from an ApplicationMediator. The fireViewEvent method and the ViewEvent listeners are used to process the event (step 3116). If another ViewController needs to be displayed, use a ViewEvent to represent that request and have the ApplicationMediator process that request.

VIII. Create ValidationRule(s)

Turning now to FIG. 32, a flowchart of a process for creating ValidationRules is depicted in accordance with a preferred embodiment of the present invention. A ValidationRule implements two methods: edit and normalize. A particular business validation rule is selected (step 3200) and a class that extends ValidationRule is created (step 3202). This class should have a suffix of Rule to distinguish it as a ValidationRule class. The edit( ) method is overridden (step 3204). The edit( ) method takes a user-inputted string and generates a formatted output for display. The normalize( ) method takes a user-inputted or formatted string and generates a normalized output for transmitting to some persistent storage (step 3206). If the normalize and edit methods have the same implementation, then implement in the edit( ) method and have the normalize( ) method call the edit( ) method. The ValidationRule will compare user input against the selected business rule (step 3208). If the user input is not valid, then a ValidationRuleException is thrown (step 3210) and the process terminates thereafter. If the user input is valid, the process also terminates.

C. Create a ViewEvent

With reference now to FIG. 33, a flowchart of a process for creating a ViewEvent is depicted in accordance with a preferred embodiment of the present invention. In response to AWTEvents, ViewControllers visually manipulate components, containers and beans. A ViewEvent is created for an AWTEvent from a ViewController that needs action to be taken beyond the normal visual manipulation capabilities of the ViewController. ViewEvents are created by ViewControllers and processed by ApplicationMediators which are ViewListeners. Other ViewListeners can listen for ViewEvents to monitor and debug. The details are in two choices: 1) an interface is created to contain all the various ViewEvent codes used in the application (step 3300), 2) MyviewEvent is a subclass ViewEvent and contains the ViewEvent codes. Create an instance of ViewEvent using one of the above codes (step 3302). Data can also be sent with the event and send the ViewEvent using fireViewEvent method of ViewControllerImpl (step 3304) with the process terminating thereafter.

D. Create an ApplicationMediator

An ApplicationMediator class is typically present for every application function or use case of the system to be developed. An ApplicationMediator creates one or more ViewControllers to complete its function. It may also create other ApplicationMediators for nested functions or use cases. With reference now to FIG. 34, a flowchart of a process to create an ApplicationMediator is depicted in accordance with a preferred embodiment of the present invention. A particular function is selected (step 3400) and create a class that extends ApplicationMediatorImpl (step 3402). This class should have a suffix of AM to distinguish it as an ApplicationMediator class. The init( ) method is overridden (step 3404). The ViewControllers used by this ApplicationMediator are created (step 3406). The initViewControllers( ) and initApplicationMediators( ) methods can be used to create instances of the classes given a list of class name strings. These init methods also add the current ApplicationMediator as the ViewListener for the newly created instances. The processViewEvent( ) method is overridden (step 3408).

ViewEvents from all ViewControllers and ApplicationMediators created by the current ApplicationMediator are processed in this method. This method is called in a separate thread from the AWTEvent thread by the viewEventPerformed( ) method of ApplicationMediatorImpl, so that user processing can continue. RequestEvents are created for any requests for data or transaction to be processed by business logic outside of the client application (step 3410). These requests can be synchronous or asynchronous. For asynchronous RequestEvents, the requestResponse( ) and requestException( ) methods must be overridden. Refresh( ) is invoked on the ViewController or ApplicationMediator based on the response of the RequestEvent (step 3412) with the process terminating thereafter. Other possible actions based on ViewEvents include, for example, passing control to other ViewControllers or ApplicationMediators. Also, the ViewEvent can even be sent to higher level listeners using the fireViewEvent method of ApplicationMediatorImpl.

E. Create a RequestEvent

RequestEvents contain a major code to determine the Destination of the request and a minor code to determine the type of request. Turning now to FIG. 35, a flowchart of a process for creating a RequestEvent is depicted in accordance with a preferred embodiment of the present invention.

An interface for containing the strings of major and minor codes of RequestEvents is created (step 3500). Major codes determine the Destination but should be based on a grouping of related request types. In this manner, the processing of these requests can be changed as a group. When processing a ViewEvent in an ApplicationMediator, a RequestEvent can be created for requesting data or a transaction from a business logic subsystem that may be outside of the client application. An instance of RequestEvent is created using the appropriate major and minor code (step 3502). The event is sent using fireRequestEvent method of ApplicationMediatorImpl (step 3504) with the process terminating thereafter.

F. Create a Destination

A Destination takes a RequestEvent and sends it to the appropriate location for processing including servers, the hosting client environment, an in memory algorithm, or local devices. Each major code can be mapped to a different Destination. This allows the client application to access multiple servers and change locations of server processing without requiring code changes in the client application.

With reference now to FIG. 36, a flowchart of a process for creating a Destination is depicted in accordance with a preferred embodiment of the present invention. A particular Destination for processing client requests is selected (step 3600) and a class that extends DestinationImpl is created step (3602). In the depicted examples, this class has a suffix of Destination to distinguish it as a Destination class. The init( ) method is overridden (step 3604). Any initialization required to connect to a particular Destination can be implemented in this method. The requestEventPerformed( ) method is overridden (step 3606). A RequestEvent is passed to this method. The method should send the request to the appropriate Destination and update the RequestEvent with the response. Use the setstatus method of RequestEvent to update the processing status of the request. If a timeout value has been set, then implement a timeout mechanism for processing the request.

The Destination should observe the RequestEvent consume variable as an indicator that processing should be canceled. Next, the finalize( ) method is overridden (step 3610) with the process terminating thereafter. If connection to a Destination needs to be cleaned up, that functionality should be located in this method. The TopListener or any other class that starts the application should create Destinations and register them with the Transporter based on the major codes of the RequestEvents the Destination handles.

G. Create a TopListener

A TopListener manages the overall application. The TopListener is the entry point into the hosting client desktop environment, which includes the operating system, a browser, and legacy programs. Typically the class that contains the top frame of the application will also implement the TopListener interface. This class should have a suffix of Top to distinguish it as a TopListener class.

With reference now to FIG. 37, a flowchart of a process for creating a TopListener is depicted in accordance with a preferred embodiment of the present invention. A class is created that contains or is the top frame of the application and implements the TopListener interface (step 3700). An exit( ) method is created (step 3702) and a launch( ) method is created (step 3704). Next, a message( ) method is created (step 3706) and a title( ) method i