Architecture and process for creating software applications for multiple domains

• US 20030078960A1
• Filed: 04/30/2001
• Published: 04/24/2003
• Est. Priority Date: 04/30/2001
• Status: Abandoned Application

• Current Assignee: General Electric Capital Corporation (General Electric Company)
• Original Assignee: General Electric Capital Corporation (General Electric Company)
• Inventors: Morrill, Daniel L., Murren, Brian T., Arthur, Richard B.
• Application Number:
  US09/845,737
• Publication Number:
  US 20030078960A1
• Time in Patent Office: Days
• US Class Current: 709/203
• CPC Class Codes: H04L 67/2871 Implementation details of single intermediate entities
• CPC Class Codes: H04L 67/34 involving the movement of software or configuration parameters network booting or remote initial program loading [RIPL] G06F9/4416
• CPC Class Codes: H04L 67/56 Provisioning of proxy services store-and-forward switching systems in data switching networks H04L12/54
• CPC Class Codes: H04L 67/565 Conversion or adaptation of application format or content adding application control or application functional data H04L67/561
• CPC Class Codes: H04L 69/18 Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
• CPC Class Codes: H04L 69/32 Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
• CPC Class Codes: H04L 69/321 Interlayer communication protocols or service data unit [SDU] definitions; Interfaces between layers
• CPC Class Codes: H04L 69/328 in the presentation layer [OSI layer 6]
• CPC Class Codes: H04L 9/40 Network security protocols

Abstract

A multi-layer software architecture permits efficient and timely construction of processes and server-based software applications for many diverse domains, such as business-oriented domains like asset management, leasing and lending, inventory tracking, and so forth. The architecture is arranged into several hierarchical layers. Layers may be removed, modified, or updated without impacting other layers. This allows the architecture to adapt easily to many different problem domains, to support many different types of client devices, to accommodate many different users in different regions and cultures of the world, and to interface with many diverse resources.

Claims

1. A server system comprising:

one or more computers; and

a multi-layer application executing on the computers to handle client requests submitted by various client devices, the multi-layer application comprising;

a problem-solving logic layer to process the client requests according to an associated problem domain, the problem-solving logic layer containing one or more execution models to perform various sets of tasks when processing the client requests, the problem-solving logic layer producing replies to the client requests;

an execution environment layer to receive the client requests and select an appropriate execution model in the problem-solving logic layer for processing the client requests;

an interfacing layer to interface the problem-solving logic layer with one or more resources so that the execution models may utilize the resources when processing the client requests; and

a presentation layer to receive the replies produced by the problem-solving logic layer and to structure the replies in a manner that makes the replies presentable on the various client devices.

2. A server system as recited in claim 1, wherein the execution environment layer comprises a framework to receive the client requests and route the requests to the problem-solving logic for processing.

3. A server system as recited in claim 2, wherein the execution environment layer comprises one or more adapters to interface the framework with different types of the client devices.

4. A server system as recited in claim 1, wherein the execution environment layer comprises:

a model dispatcher to route the client requests to selected execution models in the problem-solving logic layer; and

a request dispatcher to structure the replies for return to the client devices.

5. A server system as recited in claim 1, wherein the multi-layer application can be adapted to receive requests from new client devices with incompatible communication protocols by substituting a new execution environment layer that supports the new client devices.

6. A server system as recited in claim 1, wherein one of the execution models is embodied as a set of discrete program modules, each program module performing a specific task.

7. A server system as recited in claim 1, wherein one of the execution models is embodied as an interaction-based model in which computer programs are defined by a series of interaction definitions.

8. A server system as recited in claim 1, wherein the execution models are embodied according to at least one of a command model, an action-view model, and a use case model.

9. A server system as recited in claim 1, wherein one of the execution models performs tasks according to a first business purpose, and the multi-layer application being reconfigurable to achieve a different business purpose by installing another execution model that performs tasks according to the second business purpose.

10. A server system as recited in claim 1, wherein the interfacing layer comprises:

a data abstraction layer to obtain data from the resources and map the data into a domain framework that models information flow for a specific problem domain; and

a data coordination layer that provides an interface for the problem-solving logic layer to access the domain framework of the data abstraction layer and obtain the data.

11. A server system as recited in claim 10, wherein the data coordination layer comprises one or more application data managers that interface the domain framework in the data abstraction layer into an application solution space of the problem-solving logic layer.

12. A server system as recited in claim 1, wherein the multi-layer application can be adapted to access new resources by substituting in a new interfacing layer that supports the new resources.

13. A server system as recited in claim 1, wherein the client devices support different data formats, the presentation layer being configured to select appropriate data formats for encoding the replies.

14. A server system as recited in claim 1, wherein the client devices support different communication protocols, the presentation layer being configured to select appropriate communication protocols for delivering the replies to the clients.

15. A server system as recited in claim 1, wherein the presentation layer is configured to determine how to display the replies for a particular client.

16. A server system as recited in claim 1, wherein the presentation tier is configured to determine at least one of (1) a layout of individual replies, (2) display attributes in which to present the replies, and (3) a presentation theme.

17. A server system as recited in claim 1, wherein the presentation layer comprises:

a presentation module to determine how the replies will appear on the client devices to users; and

a rendering module, separate from the presentation module, to determine how to render the replies on the client devices.

18. A server system as recited in claim 1, further comprising an authentication module to authenticate the client devices or users of the client devices.

19. A server system as recited in claim 1, further comprising a constraint system to constrain operation of the multi-layer application according to a hierarchy of different constraints.

20. A server system as recited in claim 1, further comprising a constraint system to constrain operation of the multi-layer application according to multiple different constraints, the constraint system comprising a hierarchy of constraint layers, with each constraint layer containing a set of one or more constraints that customize operation of the multi-layer application.

21. A server system as recited in claim 1, further comprising:

a constraint hierarchy of multiple constraint layers, each constraint layer containing a set of one or more constraints that constrain operation of the multi-layer application, the constraint layers being organized within the constraint hierarchy such that a first constraint layer limits a second constraint layer but the second constraint layer does not limit the first constraint layer; and

a constraint resolver to resolve the constraint layers so that operation of the multi-layer application is constrained by a set of the constraints in the constraint layers.

22. A server system as recited in claim 21, wherein the hierarchy of constraints comprises constraints selected from a group of constraints comprising:

legally mandated constraints to constrain operation of the multi-layer application according to legal principles;

company-mandated constraints to constrain operation of the multi-layer application according to preferences of a company that operates the application;

customer constraints to constrain operation of the multi-layer application according to preferences of customers;

cultural constraints to constrain operation of the multi-layer application according to cultural aspects; and

end user constraints to constrain operation of the multi-layer application according to preferences of an end user.

23. A server system as recited in claim 1, further comprising a security policy enforcement module to enforce security restrictions on accessing information stored at the one or more resources.

24. A server system as recited in claim 23, wherein the security policy enforcement module is to enforce the security restrictions based on a set of low-level security rules defined using high-level permission concepts.

25. A server system as recited in claim 1, wherein the presentation layer includes a form processor to generate a data input form for the multi-layer application by automatically adding, to a form definition that defines the data input form, validation code to validate subsequent inputs to one or more fields of the data input form.

26. A server system as recited in claim 25, wherein the form processor is to generate the data input form by identifying one or more custom tags associated with the data input form, to replace each of the one or more custom tags with another tag, and further to add to the form definition, for each of the one or more replaced tags, validation code to validate subsequent inputs to a field corresponding to the tag.

27. A server system as recited in claim 25, wherein the form processor is further to automatically identify one or more data input fields to be included in the form definition.

28. A server system as recited in claim 25, wherein the form processor is further to automatically identify one or more restrictions associated with a data input field of the data input form, and to determine the validation code based at least in part on the one or more restrictions.

29. A server system as recited in claim 1, further comprising:

a resource bundle containing locale-specific content that is authored for a particular locale; and

a resource bundle manager to populate a locale-independent core with the locale-sensitive content in the resource bundle to produce a computer-servable document that can be served by the multi-layer application to the particular locale.

30. A server system as recited in claim 29, wherein the resource bundle manager resides in the interfacing layer.

31. A business-oriented computer software architecture stored on one or more computer-readable media, comprising:

a framework module to receive client requests from different client devices;

a first business logic module to process the client requests received by the framework according to an associated business purpose, the first business logic module generating replies corresponding to the client requests;

a presentation module to structure the replies produced by the first business logic module in a manner that makes the replies presentable on the client devices; and

the business-oriented computer software architecture being reconfigurable to another business purpose by substituting a second business logic module for the first business logic module.

32. A business-oriented computer software architecture as recited in claim 31, wherein the framework module forms a container for the first and second business logic modules that allows the first and second business logic modules to be selectively added or removed from the architecture.

33. A business-oriented computer software architecture as recited in claim 31, wherein the first and second business logic modules are implemented as discrete programs, each program performing a specific task.

34. A business-oriented computer software architecture as recited in claim 31, wherein the client devices support different data formats, the presentation layer being configured to select appropriate data formats for encoding the replies.

35. A business-oriented computer software architecture as recited in claim 31, wherein the client devices support different communication protocols, the presentation layer being configured to select appropriate communication protocols for delivering the replies to the clients.

36. A business-oriented computer software architecture as recited in claim 31, wherein the presentation module comprises:

a presentation component to structure how the replies will appear; and

a rendering component, separate from the presentation component, to configure how the replies are output on a particular client.

37. A business-oriented computer software architecture as recited in claim 31, wherein the presentation module generates a data input form by automatically adding, to a form definition that defines the data input form, validation code to validate subsequent inputs to one or more fields of the data input form.

38. A business-oriented computer software architecture as recited in claim 37, wherein the presentation module automatically identifies one or more data input fields to be included in the form definition.

39. A business-oriented computer software architecture as recited in claim 37, wherein the presentation module automatically identifies one or more restrictions associated with a data input field of the data input form and determines the validation code based at least in part on the one or more restrictions.

40. A business-oriented computer software architecture as recited in claim 31, further comprising a domain framework to model information flow for a particular business domain.

41. A business-oriented computer software architecture as recited in claim 31, further comprising a constraint hierarchy with a hierarchical set of constraints that specify how the replies should be structured to customize the replies.

42. A business-oriented computer software architecture as recited in claim 31, further comprising:

a resource bundle containing locale-specific content that is authored for a particular locale; and

a resource bundle manager to populate a locale-independent core with the locale-sensitive content in the resource bundle to produce the replies.

43. A business-oriented computer software architecture stored on one or more computer-readable media, comprising:

a first layer to obtain data from external resources and map the data into a domain framework that models information flow for a specific problem domain;

a second layer to provide an interface into the domain framework of the first layer;

a third layer to process requests and produce replies, the third layer utilizing the second layer to access the domain framework and retrieve the data obtained by the first layer from the external resources;

a fourth layer to structure the replies for presentation and rendering on diverse client devices; and

wherein anyone of the first layer, the second layer, the third layer, and the fourth layer may be changed independently of other layers to modify operation of the computer software architecture.

44. A business-oriented computer software architecture as recited in claim 43, wherein the first layer may be updated to obtain data from new external resources.

45. A business-oriented computer software architecture as recited in claim 43, wherein the third layer is an original third layer that processes the requests according to a first business domain, further comprising a new third layer substituted for the original third layer to process the requests according to a second business domain.

46. A business-oriented computer software architecture as recited in claim 43, wherein the fourth layer can be updated to structure the replies for new client devices.

47. A business-oriented computer software architecture as recited in claim 43, wherein the fourth layer can be modified to structure the replies for presentation to users in different regions of the world.

48. A method comprising:

receiving requests from multiple clients, the requests being related to a problem domain;

processing the requests within problem-solving logic to produce replies within the problem domain, the processing comprising requesting data to be used in formulating the replies;

retrieving the data from one or more external resources and mapping the data to a domain framework for the problem domain, the domain framework being independent from the problem-solving logic; and

interfacing the problem-solving logic to the domain framework to obtain the data for use in processing the request.

49. A method as recited in claim 48, further comprising structuring the replies for presentation to the clients.

50. A method as recited in claim 48, further comprising:

structuring the replies to define how the replies will appear when presented at the clients; and

independent of said structuring, conforming the replies to output capabilities of the clients.

51. A method as recited in claim 48, further comprising constraining how the replies are presented according to a hierarchy of constraints, wherein the hierarchy of constraints comprises multiple constraints such that a first constraint limits a second constraint but the second constraint does not limit the first constraint.

52. A method for creating server applications for multiple different problem domains, comprising:

providing a framework to receive client requests from multiple different clients, individual clients communicating messages using different protocols and formats;

providing a resource structure to access resources that provide data related to the different problem domains;

creating a first server application for a first problem domain by interfacing first domain logic with the framework and the resource structure, the first domain logic being configured to process the client requests for the first problem domain;

creating a second server application for a second problem domain by interfacing second domain logic with the framework and the resource structure, the second domain logic being configured to process the client requests for the second problem domain; and

the first and second domain logic producing replies that the framework returns to the clients using the protocols and messaging formats employed by the clients.

53. A method as recited in claim 52, wherein the providing a resource structure comprises providing a resource structure that retrieves data from one or more external resources and maps the data to a domain framework that models information flow for a specific problem domain.

54. A method as recited in claim 52, further comprising:

structuring the replies to define how the replies will appear when presented at the clients; and

independent of said structuring, conforming the replies to output capabilities of the clients.

55. A method as recited in claim 52, further comprising generating a data input form for service to a client by automatically adding, to a form definition that defines the data input form, validation code to validate subsequent inputs to one or more fields of the data input form.

56. A method as recited in claim 52, further comprising automatically identifying one or more data input fields to be included in a data input form based on the first and second domain logic.

57. A method as recited in claim 52, further comprising forming a reply for a particular locale by retrieving a locale-independent core that contains locale-independent elements and populating the locale-independent core with locale-sensitive content that is appropriate for the particular locale.