U.S. patent application number 10/942530 was filed with the patent office on 2006-03-16 for method, system, and storage medium for facilitating application development.
This patent application is currently assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION. Invention is credited to Brian D. Berry, Noah G. Sack.
Application Number | 20060059127 10/942530 |
Document ID | / |
Family ID | 36035317 |
Filed Date | 2006-03-16 |
United States Patent
Application |
20060059127 |
Kind Code |
A1 |
Berry; Brian D. ; et
al. |
March 16, 2006 |
Method, system, and storage medium for facilitating application
development
Abstract
A method for facilitating application development, the method
including initializing a page token in response to receiving a
request. The page token comprises an abstract model component
containing a specification for obtaining data designated to be sent
in a response to the request or a specification for updating data
obtained from the request, and also a view component for providing
referential format specifications for data provided in the abstract
model component. The method further includes passing the page token
between at least two components of a modified model-view-controller
architecture via a standard interface. The components include a
user interface controller, a user interface builder implementing a
first standard interface, an application layer implementing a
second standard interface, a data access manager implementing a
third standard interface, and at least one data access utility
implementing a fourth standard interface. The method further
includes applying business logic to contents of the page token as a
result of the passing, and presenting a response to the request
based upon results of applying the business logic.
Inventors: |
Berry; Brian D.; (Pleasant
Valley, NY) ; Sack; Noah G.; (Sloatsburg,
NY) |
Correspondence
Address: |
CANTOR COLBURN LLP
55 GRIFFIN ROAD SOUTH
BLOOMFIELD
CT
06002
US
|
Assignee: |
INTERNATIONAL BUSINESS MACHINES
CORPORATION
ARMONK
NY
|
Family ID: |
36035317 |
Appl. No.: |
10/942530 |
Filed: |
September 15, 2004 |
Current U.S.
Class: |
1/1 ;
707/999.003 |
Current CPC
Class: |
G06F 8/38 20130101 |
Class at
Publication: |
707/003 |
International
Class: |
G06F 17/30 20060101
G06F017/30 |
Claims
1. A method for facilitating application development, comprising:
initializing a page token in response to receiving a request, the
page token comprising an abstract model component containing a
specification for obtaining data designated to be sent in a
response to the request or a specification for updating data
obtained from the request, and a view component operable for
providing referential format specifications for the data provided
in the abstract model component; passing the page token between at
least two components of a modified model-view-controller
architecture via a standard interface, the components of the
modified model-view-controller architecture including: a user
interface controller; a user interface builder implementing a first
standard interface; an application layer implementing a second
standard interface; a data access manager implementing a third
standard interface; and at least one data access utility
implementing a fourth standard interface; applying business logic
to contents of the page token as a result of the passing; and
presenting a response to the request based upon results of the
applying business logic.
2. The method of claim 1, wherein the business logic is one of
default business logic and custom business logic.
3. The method of claim 1, wherein the request includes at least one
of: a browser-initiated hypertext transport protocol request; a
request for at least one of data, a document, an image, and
multi-media content; a search request; and a request to launch an
application.
4. The method of claim 2, further comprising updating the page
token via at least one of: the default business logic, wherein the
default business logic is applied by a call to the at least one
data access utility, and the page token is updated with data from a
data store or data from the user interface builder operable for
rendering panels; and the custom business logic, wherein the custom
business logic is applied by a call to the application layer, and
wherein further the custom business logic is operable for updating
data retrieved or for updating a view.
5. The method of claim 2, further comprising updating a data store
with data in the page token by the default business logic.
6. The method of claim 1, wherein the response to the request
includes at least one of: a search result; at least one of data, a
document, an image, and multi-media content; and a web page.
7. The method of claim 1, wherein: the user interface controller
interacts with the user interface builder via the first standard
interface; the user interface builder interacts with the
application layer via the second standard interface; the
application layer interacts with the data access manager via the
third standard user interface; and the data access manager
interacts with the at least one data access utility via the fourth
standard interface.
8. The method of claim 1, further comprising managing panel flow
via the user interface controller.
9. The method of claim 8, wherein the panel flow is managed using
specification information in the page token and machine status
information tracked by the user interface controller.
10. The method of claim 9, wherein the user interface builder
performs: extracting data from the request and placing extracted
data into the page token; identifying fields, data, and text
designated for placement on a current panel; and identifying a
format for the fields, data, and text.
11. The method of claim 10, wherein the application layer performs:
validating the extracted data by applying business logic to the
page token.
12. The method of claim 11, wherein the data access manager
performs: parsing the specification contained in the abstract model
component into segments, each of the segments classified by a
corresponding type of data store, each type of data store
associated with a data access utility.
13. The method of claim 12, wherein types of data stores include:
eXtensible Markup Language; Lightweight Directory Access Protocol;
Structured Query Language; and DB2.
14. The method of claim 12, further comprising: translating each of
the segments using the data access utility associated with a data
store specified by the segment, the translating including
translating each of the segments into a language understood by the
data store; executing an operation based upon results of the
translating; updating the segments to reference the results when
the operation executed is one that yields results; aggregating the
segments in the abstract model component of the page token; and
passing the page token back to the application layer.
15. A modified model-view-controller architecture, wherein
components of the modified model-view-controller architecture
include: a user interface controller; a user interface builder,
wherein the user interface controller is in communication with the
user interface builder via a first standard interface; an
application layer, wherein the user interface builder is in
communication with application layer via a second standard
interface; a page token comprising an abstract model component
containing a specification for obtaining data designated to be sent
in a response to a request or updating data obtained from a
request, and a view component operable for providing referential
format specifications for data provided in the abstract model
component; wherein, the page token is initialized by the user
interface controller and passed to one of the components via the
first standard interface; and wherein further, business logic is
applied to contents of the page token as a result of passing, and a
response to the request is presented based upon results of applying
the business logic.
16. The modified model-view-controller architecture of claim 15,
further comprising: a data access manager, wherein the application
layer is in communication with the data access manager via a third
standard interface; and concrete models, wherein the data access
manager is in communication with the concrete models via a fourth
standard interface, each of the concrete models comprising a
corresponding data access utility and a corresponding data store;
wherein in response to receiving the page token from the
application layer, the data access manager parses the abstract
model component and sends parsed data to one or more concrete
models associated with the parsed data; and wherein further,
corresponding data access utilities associated with the one or more
concrete models translate the parsed data into a language
understood by corresponding data stores, execute an operation
specified in the parsed data, and return results of the executed
operation to the data access manager.
17. The modified model-view-controller architecture of claim 16,
wherein in response to receiving the results of the executed
operation, the data access manager updates the page token with the
results and passes the page token back to the application
layer.
18. The modified model-view-controller architecture of claim 17,
wherein in response to receiving the page token, the application
layer applies business logic and passes the page token back to the
user interface builder.
19. The modified model-view-controller architecture of claim 18,
wherein in response to receiving the page token, the user interface
builder formats the data in the page token into a page for viewing
and passes the page back to the user interface controller.
20. The modified model-view-controller architecture of claim 19,
wherein in response to receiving the page, the user interface
controller sends the page to a display device.
21. The modified model-view-controller architecture of claim 20,
wherein the display device includes one of: a web browser; and a
cell phone.
22. A storage medium encoded with machine-readable program code for
facilitating application development, the program code including
instructions for causing a host system to implement a method,
comprising: initializing a page token in response to receiving a
request, the page token comprising an abstract model component
containing a specification for obtaining data designated to be sent
in a response to the request or a specification for updating data
obtained from the request, and a view component operable for
providing referential format specifications for the data provided
in the abstract model component; passing the page token between at
least two components of a modified model-view-controller
architecture via a standard interface, the components of the
modified model-view-controller architecture including: a user
interface controller; a user interface builder implementing a first
standard interface, an application layer implementing a second
standard interface; a data access manager implementing a third
standard interface; and at least one data access utility
implementing a fourth standard user interface; applying business
logic to contents of the page token as a result of the passing; and
presenting a response to the request based upon results of the
applying business logic.
23. The storage medium of claim 22, wherein the business logic is
one of default business logic and custom business logic.
24. The storage medium of claim 23, wherein the request includes at
least one of: a browser-initiated hypertext transport protocol
request; a request for at least one of data, a document, an image,
and multi-media content; a search request; and a request to launch
an application.
25. The storage medium of claim 24, further comprising instructions
for causing the host system to perform: updating the page token via
at least one of: the default business logic, wherein the default
business logic is applied by a call to the at least one data access
utility, and the page token is updated with data from a data store
or data from the user interface builder operable for rendering
panels; and the custom business logic, wherein the custom business
logic is applied by a call to the application layer, and wherein
further the custom business logic is operable for updating data
retrieved or for updating a view; and updating a data store with
data in the page token by the default business logic.
26. The storage medium of claim 23, wherein: the user interface
controller interacts with the user interface builder via the first
standard interface; the user interface builder interacts with the
application layer via the second standard interface; the
application layer interacts with the data access manager via the
third standard user interface; and the data access manager
interacts with the at least one data access utility via the fourth
standard interface.
27. The storage medium of claim 23, further comprising instructions
for causing the host system to implement managing panel flow via
the user interface controller, wherein the panel flow is managed
using specification information in the page token and machine
status information tracked by the user interface controller.
28. The storage medium of claim 27, wherein the user interface
builder performs: extracting data from the request and placing
extracted data into the page token; identifying fields, data, and
text designated for placement on a current panel; and identifying a
format for the fields, data, and text.
29. The storage medium of claim 28, wherein the application layer
performs: validating the extracted data by applying business logic
to the page token.
30. The storage medium of claim 29, wherein the data access manager
performs: parsing the specification contained in the abstract model
component into segments, each of the segments classified by a
corresponding type of data store, each type of data store
associated with a data access utility; translating each of the
segments using the data access utility associated with a data store
specified by the segment, the translating including translating
each of the segments into a language understood by the data store;
executing an operation based upon results of the translating;
updating the segments to reference the results when the operation
executed is one that yields results; aggregating the segments in
the abstract model component of the page token; and passing the
page token back to the application layer.
Description
FIELD OF THE INVENTION
[0001] The present invention relates generally to application
development, and more particularly, to a method, system, and
storage medium for facilitating application development using a
modified Model-View-Controller architecture.
BACKGROUND OF THE INVENTION
[0002] Object-oriented programming is a popular means for
developing applications. Object-oriented programming is implemented
by a special language such as Java, C++, Smalltalk.RTM., etc. and
refers to a type of programming that enables programmers to define
a data type of a data structure, as well as operation functions to
be applied to the data structure. In this manner, the data
structure becomes an object that includes the data and its
functions. By design, object-oriented programs are easily modified
as application changes are needed (e.g., a new object can be
created that inherits features of existing objects), although they
require substantial amounts of complex code even for simple
applications.
[0003] Advanced object-oriented programming techniques provide the
ability to better manage program code, as well as reduce the
complexity of the code, by compartmentalizing the code into
organized `chunks` or by implementing a general pattern during code
development. One general pattern used is the Model-View-Controller
(MVC) architecture. In a programming environment, the
Model-View-Controller architecture distinguishes between a model
(the data the user is manipulating along with its associated
business logic), a view (a graphical representation of the data),
and a controller (the mechanisms by which the user manipulates the
data). The controller may be used to change the state of the model
which, in turn, is displayed in the view. Segregating these
components enables developers to re-use object code thereby
reducing the time it takes to develop applications. Despite this,
the MVC model still requires rather extensive development even for
simple applications.
[0004] What is desirable, therefore, is the ability to provide
rapid application development and simple application integration
where most of the development is left to simple configuration
rather than complex code development.
SUMMARY OF THE INVENTION
[0005] Embodiments of the invention include a method for
facilitating application development. The method includes
initializing a page token in response to receiving a request. The
page token comprises an abstract model component containing a
specification for obtaining data designated to be sent in a
response to the request or a specification for updating data
obtained from the request, and also a view component operable for
providing referential format specifications for data provided in
the abstract model component. The method also includes passing the
page token between at least two components of a modified
model-view-controller architecture. The components include a user
interface controller, a user interface builder, an application
layer, a data access manager, concrete models, and the standard
interfaces between these components. The method further includes
applying business logic to contents of the page token as a result
of the passing, and presenting a response to the request based upon
results of applying the business logic.
[0006] Embodiments also include a modified model-view-controller
architecture for facilitating application development. The
components of the modified model-view-controller architecture
include a user interface controller and a user interface builder.
The user interface controller is in communication with the user
interface builder via a first standard interface. The components
also include an application layer. The user interface builder is in
communication with application layer via a second standard
interface. The components further include a page token comprising
an abstract model component containing a specification for
obtaining data designated to be sent in a response to a request or
updating data obtained from a request, and a view component
operable for providing referential format specifications for data
provided in the abstract model component. The page token is
initialized by the user interface controller and passed to one of
the components via the first standard interface, business logic is
applied to contents of the page token as a result of the passing,
and a response to the request is presented based upon results of
applying the business logic.
[0007] Embodiments also include a storage medium encoded with
machine-readable program code for facilitating application
development. The program code includes instructions for causing a
host system to initialize a page token in response to receiving a
request. The page token comprises an abstract model component
containing a specification for obtaining data designated to be sent
in a response to the request or a specification for updating data
obtained from the request, and also a view component operable for
providing referential format specifications for data provided in
the abstract model component. The program code also includes
instructions for causing the host system to pass the page token
between at least two components of a modified model-view-controller
architecture. The components include a user interface controller, a
user interface builder, an application layer, a data access
manager, concrete models, and the standard interfaces between these
components. The program code further includes instructions for
causing the host system to apply business logic to contents of the
page token as a result of the passing, and to present a response to
the request based upon results of applying the business logic.
[0008] Other systems, methods, and/or computer program products
according to embodiments will be or become apparent to one with
skill in the art upon review of the following drawings and detailed
description. It is intended that all such additional systems,
methods, and/or computer program products be included within this
description, be within the scope of the present invention, and be
protected by the accompanying claims.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] Referring now to the drawings, wherein like elements are
numbered alike in the several FIGURES:
[0010] FIG. 1 is a block diagram of a system upon which the
modified MVC framework may be implemented in exemplary
embodiments;
[0011] FIG. 2 is a diagram of the modified MVC framework and its
components in exemplary embodiments; and
[0012] FIG. 3 represents a flow diagram describing a sample
implementation of the modified MVC framework in exemplary
embodiments.
DETAILED DESCRIPTION OF THE INVENTION
[0013] In accordance with exemplary embodiments, a method, system,
and storage medium for facilitating application development is
disclosed. The modified Model-View-Controller (MVC) framework of
the invention allows for rapid application development and simple
application integration and enhancement whereby most of the
development is left to simple configuration rather than complex
code development. The flexibility of the modified MVC framework's
implementation provides custom application-specific extensions
while maintaining a standard interface at each level to ensure
simple integration. The implementation of the standard interface
combined with a standard data structure (i.e., page token),
eliminates the need for coding controller and model components. The
page token object introduces the concept of an abstract model which
is integrated with the view component to provide a more data-driven
aspect to the existing MVC model architecture.
[0014] In FIG. 1, a block diagram of an exemplary system upon which
the modified MVC framework may be implemented is generally shown.
The system of FIG. 1 includes one or more client systems 102
through which users at one or more geographic locations may contact
a host system 104. The host system 104 executes computer
instructions for implementing the modified MVC framework and the
client systems 102 are in communication with the host system 104
via a network 106. Client systems 102 interact with host system 104
by initiating one or more requests. Client systems 102 may be one
of many different types of client systems, e.g., a personal
computer that initiates HTTP requests via a web browser (or a
full-featured interface such as a rich client that is written with,
e.g., J2SE technology), a mobile computing device such as a
personal digital assistant (PDA) or cellular telephone that
initiate requests using Wireless Markup Language (WML), or a server
(e.g., a web service peer that requests services with Electronic
Business XML (ebXML) or Simple Object Access Protocol (SOAP)
messages).
[0015] The network 106 may be any type of known network including,
but not limited to, a wide area network (WAN), a local area network
(LAN), a global network (e.g., Internet), a virtual private network
(VPN), and an intranet. The network 106 may be implemented using a
wireless network or any kind of physical network implementation
known in the art. A client system 102 may be coupled to the host
system 104 through multiple networks (e.g., intranet and Internet)
so that not all client systems 102 are coupled to the host system
104 through the same network. One or more of the client systems 102
and the host system 104 may be connected to the network 106 in a
wireless fashion. In one embodiment, the network is an intranet and
one or more client systems 102 execute a user interface application
(e.g., a web browser) to contact the host system 104 through the
network 106, while another client system 102 is directly connected
to the host system 104. In another exemplary embodiment, the client
system 102 is connected directly (i.e., not through the network
106) to the host system 104 and the host system 104 is connected
directly to or contains a storage device 108.
[0016] The storage device 108 may be implemented using a variety of
devices for storing electronic information. It is understood that
the storage device 108 may be implemented using memory contained in
the host system 104 or it may be a separate physical device. The
storage device 108 is logically addressable as a consolidated data
source across a distributed environment that includes a network
106. Information stored in the storage device 108 may be retrieved
and manipulated via the host system 104. The storage device 108
includes a data repository containing documents, data, web pages,
images, multi-media, etc. Further, storage device 108 stores
configuration files (also referred to herein as page tokens). In an
exemplary embodiment, the host system 104 operates as a database
server and coordinates access to application data including data
stored on storage device 108.
[0017] The host system 104 depicted in FIG. 1 may be implemented
using one or more servers operating in response to a computer
program stored in a storage medium accessible by the server. The
host system 104 may operate as a network server (e.g., a web
server) to communicate with the client system 102. The host system
104 handles sending and receiving information to and from the
client system 102 and can perform associated tasks. Host system 104
executes various applications utilizing the modified MVC
framework.
[0018] The host system 104 may also include a firewall to prevent
unauthorized access to the host system 104 and enforce any
limitations on authorized access. For instance, an administrator
may have access to the entire system and have authority to modify
portions of the system. A firewall may be implemented using
conventional hardware and/or software, as is known in the art.
[0019] The host system 104 may also operate as an application
server. The host system 104 executes one or more computer programs
to implement business logic and related functions. As previously
described, it is understood that separate servers may be utilized
to implement the network server functions and the application
server functions. Alternatively, the network server, the firewall,
and the application server may be implemented by a single server
executing computer programs to perform the requisite functions.
[0020] Turning now to FIG. 2, an exemplary model of the modified
MVC framework 200 is described. Also shown in FIG. 2 is a request
201 and response 203. A request 201 may be a browser-initiated HTTP
request, or may be a request for data, a document, image, or other
content. The request 201 may also be a search request or a request
to launch an application. Response 203 refers to the results of the
request processing. Response 203, for example, might be a web page,
search result, etc. Requests and responses are handled by the user
interface controller 202 as described herein.
[0021] User interface controller 202 employs, e.g., a standard Java
Action Servlet for managing configuration information as well as
creating session-associated information (e.g., creating and
destroying objects required by an application). User interface
controller 202 also manages panel flow using the configuration
information and status information received from the page token 218
via a standard interface 204. Standard interface 204 (as well as
standard interfaces 208, 212, and 224a-224c) enables and
facilitates the independent functionality of the various elements
that comprise the modified MVC framework model 200.
[0022] Also included in the modified MVC framework model 200 is a
page token 218. Page token 218 is a data structure that contains a
view component 220 and an abstract model component 222. The page
token 218 is passed back and forth between model 200 components
including: the user interface controller 202, one of the user
interface builders 206, one of the application layer components
210, and zero or more data access utilities 226a-c via the data
access manager 214 during the request and response processes. The
abstract model component 222 contains a specification for obtaining
data to be sent in a response 203 or updating data obtained from
the request 201. The view component 220 contains a specification
for formatting a response (e.g., a web page) and also referentially
specifies how data from the abstract model component 222 will be
formatted in the view.
[0023] The user interface builder 206 interacts with user interface
controller 202 via the standard interface 204 described above. An
application layer 210 provides a set of high-level application
programming interfaces (APIs) for handling the page token 218, and
includes functionality to perform paging, searching, and standard
validation (e.g., checking required fields). Application layer 210
may be extended as necessary to apply business logic such as custom
validation functions. For example, application layer 210 manages
requests sent via the data access manager 214 to the concrete
models 216 if default interaction is not desired via the
implementation of custom business logic. Business logic is applied
by updating the page token 218 as it is received from a user
interface builder 206 or after it has been updated by one or more
of concrete models 216. Additionally, a single piece of business
logic may produce many page formats by updating the page token 218
as needed.
[0024] The modified MVC model 200 includes a set of standard user
interface builders 206 that interact with the application layer 210
using a standard interface 208 which performs requests to update
the page token 218 associated with the current panel or panel flow.
This enables the modified MVC framework 200 to provide a
standardized way of building all like panels, e.g. all add panels,
all modify panels, all delete panels, all list panels, and all
search panels. User interface builders 206 use the view component
220 of page token 218 to identify what fields, data, and text
should be placed on the panel as well as in which format to place
them. Further, user interface builders 206 handle the `plumbing`
associated with obtaining data from a client request by placing
this data into the page token 218 so that the business logic can be
used to validate the request data without having to write the code
to obtain it. These user interface builders 206 may be extended if
the needed type is not available in the existing framework as
described further herein. Once extended, they become immediately
available as standard page types.
[0025] Also included in modified MVC framework model 200 are data
access manager 214 and concrete models 216. As indicated above, the
abstract model component 222 of page token 218 contains a
specification for obtaining data to be sent in a response 203 or
updating data obtained from a request 201. This specification is
then routed by the data access manager 214 to be translated into
data store specific procedures by a translation layer provided by
data access utilities 226a-226c implemented in concrete models 216.
By performing translation of the specification at this location in
the framework, data store independent functionality may be
achieved, thereby eliminating the need to write code to access a
data store.
[0026] Concrete models 216 represent a collection of objects
responsible for managing data sources, such as data sources
228-232. This collection may consist of objects that manage one or
more such sources comprising a variety of types (e.g., IBM's
DB2.TM. 230, Lightweight Directory Access Protocol (LDAP) 228,
eXtensible Markup Language (XML) 232, Structured Query Language
(SQL), etc.). There may also be as many different data sources as
an application requires (e.g., multiple DB2 databases or a DB2
database and an LDAP database). Standard interfaces 224a-224c
enable specific actions such as add, delete, modify, and query to
be applied to one or more data sources for each page.
[0027] As indicated above, a translation layer is provided by each
data access utility 226a-226c to enable the abstract model
component 222 to be applied in the language of the underlying data
store. Since multiple data sources (e.g., 228-232) are managed by
the data access manager 214, it is possible to join data obtained
from any of the underlying data stores without suffering
performance degradation traditionally associated with join
operations. This standard interface for a data access utility
enables newly developed concrete model objects to become
immediately re-useable by any application using this framework.
[0028] Turning now to FIG. 3, a flow diagram describing a sample
implementation of the modified MVC framework is described. A client
request 201 generated by a user at client system 102 is received by
the user interface controller 202 on host system 104 at step 302.
The user interface controller 202 may include state machine
information that enables controller 202 to keep track of the page
flow. The user interface controller 202 initializes the page token
218, creates a session for the request at step 304, and passes the
page token 218 to a user interface builder 206. The user interface
builder 206 extracts data from the request 201 at step 306.
[0029] At step 308, it is determined whether default interaction is
required for the request 201. If not, custom logic is applied to
the request 201 at step 310. The extensibility of the user
interface builders 206 as described in steps 308-310 enable an
application developer to provide custom code to the user interface
builder 206 in situations where the configuration information in
the page token does not satisfy the requirements needed or the
results desired by the developer. For example, a developer may wish
to provide a standard validation procedure that is built into the
user interface builder 206. This may be accomplished by the custom
logic in step 310.
[0030] If default interaction is required at step 308, the default
logic is applied to the request at step 312. The view component 220
is then updated to reflect the application of the default logic
from step 312, or alternatively, to reflect the application of the
custom logic from step 310 at step 314. At step 316, it is
determined whether application logic is required for the request
201. This step determines whether the flow will proceed to the
application layer 210 for applying business logic and further
processing or whether such application of business logic is not
required, whereby the flow will return to the user interface
controller 202. If no application logic is required at step 316,
the user interface builder 206 updates the view component 220 at
step 318 and presents a response 203 to the requesting client
system 102 at step 320. For example, using the example above, if a
custom validation procedure is performed at step 310 and no
application logic is required at step 316, then a message (e.g.,
validation failed) may be presented at step 320. The user interface
builder 206 handles the view, e.g., builds a web page, updates the
view component 220, and sends the view (i.e., response) to user
interface controller 202, which transforms the view into a format
recognized by the requesting client system 102, and presents the
result to the client system 102.
[0031] If on the other hand, it is determined that application
logic is required at step 316, the user interface builder 206
calls, e.g., a validation method or subroutine in the application
layer 210 via the standard interface 208. It is then determined
whether default interaction is required within the application
layer 210 at step 322. If not, custom business logic is applied to
the page token 218 at step 324. Similar to steps 308-310 recited
above, steps 322-324 enable an application developer to extend the
utility of a configuration file in a page token 218 if desired by
providing customized code. For example, if a page flow requires
that information be gathered from different screens and a request
is sent to a web service for further action, then custom business
logic may be needed to handle this complex page flow. Handling
logic associated with password account administration is another
example of a workflow that may require custom business logic.
[0032] If, on the other hand, default interaction is required at
step 322, the default logic is applied to the page token 218 at
step 326. An example of default business logic may include
validating forms. Once the default logic has been applied at step
326, or alternatively, once the custom business logic has been
applied at step 324, it is then determined whether data access is
required at step 328. This step determines whether the flow returns
to the user interface builder 206 or whether the flow proceeds to
the data access manager 214. If no data access is required, then
the page token 218 is passed back to the user interface builder
206.
[0033] Once again it is determined whether default interaction is
required for the page token 218 at step 330. If not, then custom
view logic is applied to the page token 218 at step 332, followed
up updating the view component 220 to reflect this application of
logic at step 318. A response is then presented to the client via
the user interface controller at step 320. If default interaction
is required at step 330, the view component 220 is updated at step
318 to prepare it for transformation by the User Interface
Controller.
[0034] Returning back to step 328, if data access is required, the
application layer 210 calls a subroutine or method via standard
interface 212 and the page token 218 is passed to the data access
manager 214. The data access manager 214 parses the abstract model
component 222 of the page token 218 into abstract component pieces
or segments, if needed, and calls method or subroutine via standard
interface 224a-c and passes the segments (or the entire abstract
model component 222 if no segmentation is required) to one or more
of the corresponding data access utilities 226a-c at step 338. The
data access utilities 226a-c translate the operation provided in
the abstract model component 222, or segments, into the language
recognized by their respective concrete model data stores (e.g.,
LDAP 228, XML 232, DB2.TM. 230, etc.) at step 340. The operation is
executed (e.g., search, retrieve, add, delete, etc.) at step 342.
The results are then returned to the data access manager 214 which
reassembles the page token (e.g., aggregates the various abstract
model component segments received from the data access utilities
226a-c via standard interfaces 224a-c, respectively), updates the
page token 218 with the data received from the data access
utilities 226a-c at step 344, and passes the page token 218 back to
the application layer 210.
[0035] At step 346, it is determined whether application logic is
required. If so, custom business logic is applied to the page token
218 at step 348. Once the custom logic has been applied at step
348, or alternatively, if no application logic is required at step
346, the page token is passed to the user interface builder. At
step 330, it is again determined whether default interaction is
desired. If so, then the view component 220 is updated to reflect
the data access transaction at step 318, and the client is
presented with a response at step 320. Otherwise, custom view logic
is applied to the page token 218 at step 332, followed by updating
the view component as described in step 318.
[0036] As described above, the modified Model-View-Controller (MVC)
framework 200 of the invention allows for rapid application
development and simple application integration and enhancement
whereby most of the development is left to simple configuration
rather than complex code development. The flexibility of the
modified MVC framework's implementation provides custom
application-specific extensions while maintaining a standard
interface at each level to ensure simple integration. The
implementation of the standard interface combined with the standard
data structure (i.e., page token), eliminates the need for coding
controller and model components. The page token object introduces
the concept of an abstract model which is integrated with the view
component to provide a more data-driven aspect to the existing MVC
model architecture.
[0037] As described above, the present invention can be embodied in
the form of computer-implemented processes and apparatuses for
practicing those processes. The present invention can also be
embodied in the form of computer program code containing
instructions embodied in tangible media, such as floppy diskettes,
CD ROMs, hard drives, or any other computer-readable storage
medium, wherein, when the computer program code is loaded into and
executed by a computer, the computer becomes an apparatus for
practicing the invention. The present invention can also be
embodied in the form of computer program code, for example, whether
stored in a storage medium, loaded into and/or executed by a
computer, or transmitted over some transmission medium, loaded into
and/or executed by a computer, or transmitted over some
transmission medium, such as over electrical wiring or cabling,
through fiber optics, or via electromagnetic radiation, wherein,
when the computer program code is loaded into an executed by a
computer, the computer becomes an apparatus for practicing the
invention. When implemented on a general-purpose microprocessor,
the computer program code segments configure the microprocessor to
create specific logic circuits.
[0038] While the invention has been described with reference to an
exemplary embodiment, it will be understood by those skilled in the
art that various changes may be made and equivalents may be
substituted for elements thereof without departing from the scope
of the invention. In addition, many modifications may be made to
adapt a particular situation or material to the teachings of the
invention without departing from the essential scope thereof.
Therefore, it is intended that the invention not be limited to a
particular embodiment disclosed as the best mode contemplated for
carrying out this invention, but that the invention will include
all embodiments falling within the scope of the appended
claims.
* * * * *