Method, apparatus, and system for implementing view caching in a framework to support web-based applications Number:7,146,617 from the United States Patent and Trademark Office (PTO) owispatent

Title: Method, apparatus, and system for implementing view caching in a framework to support web-based applications

Abstract: According to one aspect of the present invention, a system is provided for implementing view caching in a framework to support web-based applications. The system comprising a set of server-side objects managed by an object manager (OM) running on a server. The system further comprises a set of browser-side objects running on a browser running on a client. The system also comprises a remote procedure call (RPC) mechanism and a notification mechanism to facilitate communication and synchronization between the browser-side objects and the server-side objects. The system additionally comprises a cache on the client to store layouts of views, wherein each view is a display panel consisting of a particular arrangement of applets.

Patent Number: 7,146,617 Issued on 12/05/2006 to Mukundan,   et al.

---

Inventors:	Mukundan; Anil (San Jose, CA), Coker; John (Hillsborough, CA), Coppens; William E. (San Leandro, CA)
Assignee:	Siebel Systems, Inc. (San Mateo, CA)
Appl. No.:	09/969,980
Filed:	September 29, 2001

---

Current U.S. Class:	719/330 ; 719/316; 719/318
Current International Class:	G06F 9/44 (20060101)
Field of Search:	719/330,318,320,316 709/203,219 707/2,3,10 715/500.1

---

References Cited [Referenced By]

---

U.S. Patent Documents

	5287507		February 1994		Hamilton et al.
	5613124		March 1997		Atkinson et al.
	5630066		May 1997		Gosling
	5706502		January 1998		Foley et al.
	5721908		February 1998		Lagarde et al.
	5742768		April 1998		Gennaro et al.
	5745110		April 1998		Ertemalp
	5754173		May 1998		Hiura et al.
	5974430		October 1999		Mutschler et al.
	5983227		November 1999		Nazem et al.
	5995756		November 1999		Herrmann
	6064406		May 2000		Atkinson et al.
	6175877		January 2001		Zerber
	6182127		January 2001		Cronin et al.
	6230160		May 2001		Chan et al.
	6401134		June 2002		Razavi et al.
	6404441		June 2002		Chailleux
	6490547		December 2002		Atkin et al.
	6553563		April 2003		Ambrose et al.
	6574635		June 2003		Stauber et al.
	6687816		February 2004		Frayman et al.
	6745368		June 2004		Boucher et al.
	2002/0116418		August 2002		Lachhwani et al.

Foreign Patent Documents

	WO 00/52603		Sep., 2000		WO
	WO 01/18691		Mar., 2001		WO
	US02/29969		Jan., 2003		WO

Other References

Using Layout Managers, www.iam.ubc.ca/guides/javatut99/uiswing/layout/using.html, no date. cited by examiner . Applet Caching in Java Plug-in, java.sun.com/j2se/1.3/docs/guide/misc/appletcaching.html, no date. cited by examiner . Applet Power!, java.sun.com/features/1997/oct/applets.html, 1997. cited by examiner . Brockschmidt, Kraig, "Inside OLE," Microsoft Press, pp. 187-188, paragraph 2. cited by other . Gamma, Erich, et al., "Design Patterns: Elements of Reusable Object-Oriented Software," 1995 Addison-Wesley, U.S.A., pp. 293-294. cite- d by other . Leff, Avraham, et al., "Web-Application Development Using The Model/View/Controller Design Pattern," Enterprise Distributed Object Computing Conference, 2001 Proceedings. 5th IEEE International, Sep. 4-7, 2001, pp. 118-127. cited by other.

Primary Examiner: Thomson; William
Assistant Examiner: Opie; George L.
Attorney, Agent or Firm: Campbell Stephenson Ascolese LLP

---

Claims

---

What is claimed is:

1. A system, comprising: a set of browser-side objects running on a browser residing on a client; a remote procedure call (RPC) mechanism and a notification mechanism to facilitate communication and synchronization between the browser-side objects and a set of server-side objects managed by an object manager (OM) running on a server; and a cache on the client to store layouts of views, wherein each view is a display panel comprising a particular arrangement of applets, and wherein the client is to receive a request from a user to switch to a view, and to obtain a layout of the view from the server using the RPC mechanism and the notification mechanism, and to store the layout of the view in the cache if the layout of the view has not been cached.

2. The system of claim 1, wherein the client flushes the cache, if the cache is full, to clear up storage space in the cache for the layout of the view.

3. The system of claim 1, wherein the client creates and displays the view using the layout obtained from the server, obtains data for the view from the server, and populates the view with the obtained data.

4. The system of claim 1, wherein the client retrieves the layout of the view from the cache, if the layout of the view has been cached, to save a round trip to the server.

5. The system of claim 4, wherein the client creates and displays the view using the layout retrieved from the cache, obtains data for the view from the server, and populates the view with the data obtained from the server.

6. The system of claim 1, wherein the applets are represented by the browser-side objects.

7. A method, comprising: loading a set of browser-side objects on a browser running on a client; providing a remote procedure call (RPC) mechanism and a notification mechanism to facilitate communication and synchronization between the browser-side objects and a set of server-side objects managed by an object manager (OM) running on a server; receiving a request from a user to switch to a view, wherein the view is a display panel comprising a particular arrangement of applets; obtaining a layout of the view from the server using the RPC mechanism and the notification mechanism if the layout of the view has not been cached in a cache on the client; and saving the layout of the view in the cache if the layout of the view has not been cached.

8. The method of claim 7, further comprising: flushing the cache, if the cache is full, to clear up storage space in the cache for the layout of the view.

9. The method of claim 7, further comprising: creating and displaying the view using the layout obtained from the server; obtaining data for the view from the server; and populating the view with the data obtained from the server.

10. The method of claim 7, further comprising: retrieving the layout of the view from the cache, if the layout of the view has been saved in the cache, to save a round trip to the server.

11. The method of claim 10, further comprising: creating and displaying the view using the layout retrieved from the cache; obtaining data for the view from the server; and populating the view with the data obtained from the server.

12. A machine-readable medium comprising instructions which, when executed by a machine, cause the machine to perform a method comprising: loading a set of browser-side objects on a browser running on a client; providing a remote procedure call (RPC) mechanism and a notification mechanism to facilitate communication and synchronization between the browser-side objects and a set of server-side objects managed by an object manager (OM) running on a server; receiving a request from a user to switch to a view, wherein the view is a display panel comprising a particular arrangement of applets; obtaining a layout of the view from the server using the RPC mechanism and the notification mechanism if the layout of the view has not been cached in a cache on the client; and saving the layout of the view in the cache if layout of the view has not been cached.

13. The machine-readable medium of claim 12, wherein the method further comprises: flushing the cache, if the cache is full, to clear up storage space in the cache for the layout of the view.

14. The machine-readable medium of claim 12, wherein the method further comprises: creating and displaying the view using the layout obtained from the server; obtaining data for the view from the server; and populating the view with the data obtained from the server.

15. The machine-readable medium of claim 12, wherein the method further comprises: retrieving the layout of the view from the cache, if the layout of the view has been cached, to save a round trip to the server.

16. The machine-readable medium of claim 15, wherein the method further comprises: creating and displaying the view using the layout retrieved from the cache; obtaining data for the view from the server; and populating the view with the data retrieved from the server.

---

Description

---

FIELD OF THE INVENTION

The present invention relates generally to the field of data processing. More specifically, the present invention relates to a method, apparatus, and system for implementing view caching in a framework to support web-based applications.

BACKGROUND OF THE INVENTION

As technology continues to advance and the business environments have become increasingly complex and diverse, more and more companies have relied on various customer relationship management (CRM) software and eBusiness applications to conduct and manage various aspects of their enterprise business. In general, eBusiness applications are designed to enable a company or enterprise to conduct its business over an interactive network (e.g., Internet, Intranet, Extranet, etc.) with its customers, partners, suppliers, distributors, employees, etc. eBusiness applications may include core business processes, supply chain, back-office operations, and CRM functions. CRM generally includes various aspects of interaction a company has with its customers, relating to sales and/or services. At a high level, customer relationship management is focused on understanding the customer's needs and leveraging this knowledge to increase sales and improve service. CRM application and software is generally designed to provide effective and efficient interactions between sales and service, and unify a company's activities around the customer in order to increase customer share and customer retention through customer satisfaction.

Typically, CRM implementation strategy needs to consider the following: Knowledge Management: one of the important factors of an effective CRM implementation is the acquisition of information about a customer, its analysis, sharing and tracking. Also integral to the use of knowledge for competitive advantage is for employees to know what actions to take as a result of this knowledge. Database Consolidation: another important aspect of an effective and efficient CRM solution is the consolidation of customer information in a single database and the re-engineering of business processes around the customer. The goal here is to have all interactions with a customer recorded in one place to drive production, marketing, sales and customer support activities. Integration of Channels and Systems: it is very important for a CRM application/software to provide the capability to respond to customers in a consistent and high-quality manner through their channel of choice, whether that is the e-mail, the phone, web-based user interfaces, etc. This may require the seamless integration of various communication channels with the customer or enterprise database. It also may require the integration of CRM with other parts of a company's business systems and applications. Technology and Infrastructure: to enhance customer services, a CRM application/software may include various tools to automate and streamline online customer service. For example, a self-help model typically can be implemented using a combination of tools (e.g. knowledge bases with an intuitive search capability, agent technology or automated email, etc.).

Generally, eBusiness applications are designed to allow organizations to create a single source of customer information that makes it easier to sell to, market to, and service customers across multiple channels, including the Web, call centers, field, resellers, retail, and dealer networks. Advanced eBusiness applications are typically built on a component-based architecture and are designed to be Web-based and to deliver support for various types of clients on multiple computing platforms including mobile clients, connected clients, thin clients, and handheld clients, etc.

With the recent proliferation of the Web, it is desirable to provide the functionalities of the eBusiness applications in a Web-based environment. Furthermore, it is desirable for the eBusiness applications operating in a Web-based environment to retain the look-and-feel of desktop-based eBusiness applications with which the users are already familiar.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages of the present invention will be more fully understood by reference to the accompanying drawings, in which:

FIG. 1 shows a multi-layered system architecture in which the teachings of the present invention are implemented;

FIG. 2 shows a block diagram of one embodiment of a system configuration in which the teachings of the present invention are implemented;

FIG. 3 shows a block diagram illustrating another logical representation of a multi-layered architecture in which applications can be built in accordance with the teachings of the present invention;

FIG. 4 illustrates a block diagram of one embodiment of an application framework in which the teachings of the present invention may be implemented;

FIG. 5A illustrates an exemplary framework or infrastructure 500 to support an interactive web client and an mobile web client of FIG. 2;

FIG. 5B illustrates an alternative view of the exemplary framework or infrastructure shown in FIG. 5A.

FIG. 6A illustrates an exemplary configuration in which objects on the browser and objects managed by the object manager (OM) reside and operate on multiple computing devices, including a client and a server;

FIG. 6B illustrates an exemplary configuration in which objects on the browser and objects managed by the OM reside and operate on one computing device;

FIG. 7 illustrates an example of how the remote procedure call (RPC) paradigm can be used to divide a program into pieces that can be executed on separate computing devices;

FIG. 8 illustrates an exemplary model of execution used with remote procedure calls;

FIG. 9 generally shows an exemplary partitioning of RPC application code segments, RPC interfaces, client and server stubs, and the RPC runtime libraries in the RPC client and the RPC server;

FIG. 10 generally shows an exemplary marshalling and unmarshalling between client data structures and server data structures;

FIG. 11 generally shows exemplary roles of RPC application code segments, RPC interfaces, RPC stubs, and RPC runtime libraries during a remote procedure call;

FIG. 12 generally outlines an exemplary process 1200 of building a distributed RPC application;

FIG. 13 generally illustrates the linking of the local RPC runtime library and the object code generated from the application code;

FIG. 14 generally illustrates an exemplary process of communication between the browser-side or client-side objects and server-side objects running on a multiple-devices configuration shown in FIG. 6A

FIG. 15 shows an exemplary process of communication in which the browser-side applet invokes the method directly on the JSSBusComp object;

FIGS. 16, 17, and 18 illustrate examples of toolbars, application-level menus, and applet-level menus, respectively;

FIG. 19 shows a flow diagram of one embodiment of a process for creating various objects that are used for the configuration and execution of the various commands;

FIG. 20 shows a flow diagram of one embodiment of a process for creating a command object in accordance with the teachings of the present invention;

FIG. 21 illustrates one embodiment of the properties of a command object according to the teachings of the present invention;

FIG. 22 shows a flow diagram of one embodiment of a process for creating a toolbar object in accordance with the teachings of the present invention;

FIG. 23 illustrates one embodiment of the properties of a Toolbar object according to the teachings of the present invention;

FIG. 24 shows a flow diagram of one embodiment of a process for creating a toolbar item object in accordance with the teachings of the present invention;

FIG. 25 illustrates one embodiment of the properties of a toolbar item object according to the teachings of the present invention;

FIG. 26 shows a flow diagram of one embodiment of a process for creating a menu item object in accordance with the teachings of the present invention;

FIG. 27 illustrates one embodiment of the properties of a menu item object according to the teachings of the present invention;

FIG. 28 shows a flow diagram of one embodiment of a process for creating an applet method menu item object in accordance with the teachings of the present invention;

FIG. 29 illustrates the properties of an applet method menu item object according to one embodiment of the present invention;

FIG. 30 shows a flow diagram of one embodiment of a process for creating a class method menu object in accordance with one embodiment of the present invention;

FIG. 31 illustrates properties of a class method menu item according to one embodiment of the present invention;

FIG. 32 is a diagram illustrating the relationship between toolbar objects, toolbar item objects, and command objects in accordance with one embodiment of the present invention;

FIG. 33 is a diagram illustrating the relationship between a menu object, menu item objects, and command objects;

FIG. 34 is a diagram illustrating the relationship between an applet level menu object, applet method menu item objects, and class method menu item objects;

FIG. 35 illustrates a block diagram of one embodiment of a system configuration 3500 in which the teachings of the present invention may be implemented;

FIG. 36 shows a flow diagram of a process in accordance with one embodiment of the present invention;

FIG. 37 is a flow diagram of a process according to one embodiment of the present invention;

FIG. 38 shows a block diagram illustrating the relationship between various objects according to one embodiment of the present invention;

FIG. 39 shows a block diagram of a logical structure of a business component in accordance with one embodiment of the present invention;

FIG. 40 shows some properties or attributes of a business component field in accordance with one embodiment of the present invention;

FIG. 41 shows a flow diagram of one embodiment of a process according to the teachings of the present invention;

FIG. 42 shows a block diagram of one embodiment of a system configuration according to the teachings of the present invention;

FIG. 43 is a flow diagram of a process in accordance with one embodiment of the present invention;

FIG. 44 is generally a partially block diagram of a frame or infrastructure operating on a multiple-device configuration similar to the configuration shown in FIG. 6A and described above in the text accompanying FIG. 6A;

FIG. 45 generally shows the structure of an exemplary cache according with one embodiment of the present invention;

FIG. 46 generally outlines an exemplary process of caching a view according with one embodiment of the present invention; and

FIG. 47 generally outlines an exemplary process of switching to a view according with one embodiment of the present invention.

DETAILED DESCRIPTION

In the following detailed description numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be appreciated by one skilled in the art that the present invention may be understood and practiced without these specific details.

I. System Overview and Overall Architecture

In one embodiment, a system in which the teachings of the present invention are implemented can be logically structured as a multi-layered architecture as shown in FIG. 1. In one embodiment, the logical multi-layered architecture as shown in FIG. 1 provides a platform for common services to support the various applications. These services may include a user interface layer 110, an object manager layer 120, a data manager layer 130, and a data exchange layer 140.

In one embodiment, the user Interface layer 110 may provide the applets, views, charts and reports, etc. associated with one or more applications. In one embodiment, various types of clients can be supported via the user interface layer 110. These various types of clients may include traditional connected clients, remote clients, thin clients over an intranet, Java thin clients or non-Windows-based operating systems, and HTML clients over the Internet, etc.

In one embodiment, the object manager layer 120 is designed to manage one or more sets of business rules or business concepts associated with one or more applications and to provide the interface between the user interface layer 110 and the data manager layer 130. In one embodiment, the business rules or concepts can be represented as business objects. In one embodiment, the business objects may be designed as configurable software representations of the various business rules or concepts such as accounts, contacts, opportunities, service requests, solutions, etc.

In one embodiment, the data manager layer 130 is designed to maintain logical views of the underlying data and to allow the object manager to function independently of underlying data structures or tables in which data are stored. In one embodiment, the data manager 130 may also provide certain database query functions such as generation of structure query language (SQL) in real time to access the data. In one embodiment, the data manager 130 is designed to operate on object definitions in a repository file 160 that define the database schema. In one embodiment, the data storage services 170 provide the data storage for the data model associated with one or more applications.

In one embodiment, the data exchange layer is designed to handle the interactions with one or more specific target databases and provide the interface between the data manager layer 130 and the underlying data sources.

FIG. 2 shows a block diagram of one embodiment of a system configuration in which the teachings of the present invention are implemented.

In one embodiment, the multi-layered architecture allows one or more software layers to reside on different machines. For example, in one embodiment, the user interface, the object manager, and the data manager can all reside on the dedicated web clients. For other types of clients such as the wireless clients, in one embodiment, the object manager and data manager can reside on a system server. It should be appreciated and understood by one skilled in the art that the system configuration shown in FIG. 2 is for illustrative and explanative purposes and may vary depending upon the particular implementations and applications of the teachings of the present invention.

In one embodiment, the system environment illustrated in FIG. 2 may include more than one database 290. One or more subsets of the database 290 can be created or replicated by a replication manager. In addition, mobile web clients can have additional remote databases (also called local databases). In one embodiment, unless the remote or local databases associated with the mobile web clients are defined as read-only databases, these mobile web clients can create and update data locally that will be ultimately propagated up to the primary database when each mobile web client synchronizes with the system server.

In one embodiment, the database 290 is designed to store various types of data including predefined data schema (e.g., table objects, index objects, etc.), repository objects (e.g., business objects and components, view definitions and visibility rules, etc.), and user's or customer's data. In one embodiment, dedicated web clients and server components, including those that operate in conjunction with the other types of clients, can connect directly to the database 290 and make changes in real time. In one embodiment, mobile web clients can download a subset of the server's data to use locally, and periodically synchronize with the server database through the system server to update both the local and the server database.

In one embodiment, various tables included in the database 290 may be logically organized into the following types: data tables, interface tables, and repository tables, etc.

In one embodiment, data tables may be used to store user business data, administrative data, seed data, and transaction data, etc. In one embodiment, these data tables may be populated and updated through the various applications and processes. In one embodiment, data tables may include the base tables and the intersection tables, etc. In one embodiment, base tables may contain columns that are defined and used by the various applications. In one embodiment, the base tables are designed to provide the columns for a business component specified in the table property of that business component. In one embodiment, intersection tables are tables that are used to implement a many-to-many relationship between two business components. They may also hold intersection data columns, which store information pertaining to each association. In one embodiment, intersection tables provide the data structures for association applets.

In one embodiment, interface tables are used to denormalize a group of base tables into a single table that external programs can interface to. In one embodiment, they may be used as a staging area for exporting and importing of data.

In one embodiment, repository tables contain the object definitions that specify one or more applications regarding: The client application configuration The mapping used for importing and exporting data Rules for transferring data to mobile clients

In one embodiment, the file system 295 is a network-accessible directory that can be located on an application server. In one embodiment, the file system 295 stores the physical files created by various applications, such as files created by third-party text editors, and other data that is not stored in the database 290. In one embodiment, physical files stored in the file system 295 can be compressed and stored under various naming conventions. In one embodiment, dedicated web clients can read and write files directly to and from the file system 295. In one embodiment, mobile web clients can have a local file system, which they synchronize with the server-based file system 290 periodically. In one embodiment, other types of client such as the wireless clients and the web clients can access the file system 290 via the system server.

In one embodiment, the enterprise server 250 is a logical grouping of the system servers 255 that share a common table owner or a database, point to a common gateway Server, and can be administered as a group using server manager 260. In one embodiment, the connection to the gateway server can be established via TCP/IP. In one embodiment, the enterprise server 250 can be scaled effectively by deploying multiple system servers 255 in the enterprise server 250, thus providing a high degree of scalability in the middle tier of applications.

In one embodiment, the server 255 runs one or multiple server programs. It handles the incoming processing requests and monitors the state of all processes on the server. In one embodiment, server programs are designed and configured to perform one or more specific functions or jobs including importing and exporting data, configuring the database, executing workflow and process automation, processing to support mobile web clients for data synchronization and replication, and enforcing business rules, etc. In one embodiment, the server 255 can be an NT Service (under Windows NT operating system) or a daemon (e.g., a background shell process) under UNIX operating system. In one embodiment, the server 255 supports both multi-process and multi-threaded components and can operate components in batch, service, and interactive modes.

In one embodiment, the server manager 260 is configured as a utility that allows common control, administration and monitoring across disparate programs for the servers 255 and the enterprise server 250. In one embodiment, the server manager 260 can be used to perform the following tasks: start, stop, pause, and resume servers 255, components, and tasks; monitor status and collect statistics for multiple tasks, components, and servers within an enterprise server; and configure the enterprise server, individual servers individual components, and tasks, etc.

In one embodiment, the gateway server can be configured as a logical entity that serves as a single entry point for accessing servers. In one embodiment, it can be used to provide enhanced scalability, load balancing and high availability across the enterprise server. In one embodiment, the gateway server may include a name server and a connection brokering component. In one embodiment, the name server is configured to keep track of the parameters associated with the servers. For example, the availability and connectivity information associated with the servers can be stored in the name server. The various components in the system can query the name server for various information regarding the servers' availability and connectivity. In a Windows NT environment, the name server can be run as a NT service. In a UNIX environment, the name server can run as a daemon process. In one embodiment, the connection brokering component is used to perform load balancing function such as directing client connection requests to an appropriate server (e.g., the least-busy server).

In one embodiment, as illustrated in FIG. 2, the various types of clients that can be supported by the system may include the following clients: dedicated web clients, mobile web clients, web clients, wireless clients, and handheld clients, etc.

In one embodiment, dedicated web clients (also called connected clients) are connected directly to a database server for data access via a LAN or WAN connection. In one embodiment, these connected or dedicated web clients do not store data locally. These dedicated web clients can also access the file system directly. In one embodiment, the user interface, the object manager, and the data manager layers of the multi-layered architecture reside on the dedicated web client.

In one embodiment, the mobile web clients are designed and configured for local data access and thus can have their own local database and/or local file system. In one embodiment, mobile web clients can interact with other components within the system via the gateway server. Through synchronization, the modifications from the local database and the server database can be exchanged. Mobile web clients are described in more detail below.

In one embodiment, a web client runs in a standard browser format from the client's machine. In one embodiment, the web client can connect to a system server 255 through a web server. In one embodiment, the system server 255 is designed and configured to execute business logic and access data from the database 290 and file system 295. In one embodiment, the web client described herein is designed and configured in accordance with the teachings of the present invention to operate in an interactive mode. In one embodiment, the interactive web client framework as described herein utilizes dynamically created objects implemented in JavaScript on the browser side that correspond to objects on the server side. In one embodiment, these dynamically created objects on the browser side may include the current view and its corresponding applets, the current business object and the corresponding business components, etc. The web client is described in more details below.

In one embodiment, wireless clients are essentially thin clients enabled on wireless devices. The wireless clients can use a wireless application protocol (WAP)-based user interface to communicate and exchange information/data with the system server.

The system configuration illustrated in FIG. 2 is described in more details below with references to various structures, databases, tables, file systems, etc. as illustrating examples.

FIG. 3 shows a block diagram illustrating another logical representation of a multi-layered architecture in which applications can be built in accordance with the teachings of the present invention. Again, the multi-layered architecture as illustrated in FIG. 3 provides the platform for various common services designed and configured to support the various applications. In one embodiment, these various services may include presentation services logic layer 315 which corresponds to an applet manager and user interface layer 310, application services logical layer 325 which corresponds to an object manager (OM)layer 320 and a data manager (DM) layer 330, and data services logical layer 345 which corresponds to a database layer 340.

In one embodiment, the presentation services 315 may be designed and configured to support various types of clients and may provide them with user interface applets, views, charts, and reports, etc. As described above, a large variety of clients may be supported including wireless clients, handheld clients, web clients, mobile web clients, and dedicated (connected) clients, etc.

In one embodiment, the application services 325 may include business logic services and database interaction services. In one embodiment, business logic services provide the class and behaviors of business objects and business components. In one embodiment, database interaction services may be designed and configured to take the user interface (UI) request for data from a business component and generate the database commands (e.g.SQL queries, etc.) necessary to satisfy the request. For example, the data interaction services may be used to translate a call for data into DBMS-specific SQL statements.

In one embodiment, data storage services 345 may be designed and configured to provide the data storage for the underlying data model which serves as the basis of the various applications. For example, the data model may be designed and configured to support various software products and applications including call center, sales, services, and marketing, etc., as well as various industry vertical products and applications such as eFinance, eInsurance, eCommunications, and eHealthcare, etc.

FIG. 4 illustrates a block diagram of one embodiment of an application framework in which the teachings of the present invention may be implemented. As illustrated in FIG. 4, the application framework may include various logical groupings of various types of services and various types of tools that can be used to design and configure particular applications based on business needs and environments.

In one embodiment, the core services are are designed and configured to provide the framework in which the applications execute. In one embodiment, the core services may include the following: The enterprise server, which is the middle-tier application server The networks that link all of these pieces together Facilities like event manager and data replication, which allow sharing data between multiple installations of various applications as well as between the various applications and other external applications The authentication and access control, the security facilities.

In one embodiment, application integration services may be designed and configured to allow the various applications built in accordance with this framework to communicate with the external world. In one embodiment, the various types of services in this logical grouping may be designed and configured to provide for real-time, near-real-time, and batch integration with external applications. For example, these integration services may be used to enable communications between external applications and the internal applications using available methods, technologies, and software products. In one embodiment, application integration services allow the systems or applications to share and replicate data with other external enterprise applications. Accordingly, these services allow a particular application or system to be both a client requesting information, and a server having information requested from it.

In one embodiment, business processes services are designed and configured to allow the client to automate business processes through the application. In one embodiment, these various business process services may include the following: Assignment of tasks through Assignment Manager Enforcement of business practices through Workflow Manager Reuse of custom business logic through Business Services Ensuring proper product configuration and pricing through the Product Configurator and Pricing Configurator In one embodiment, creation of these business processes can be done through Run-Time tools such as Personalization Designer, Workflow Designer, SmartScript Designer, Assignment Administration Views, and the Model Builder, etc.

In one embodiment, integration services may be designed and configured to provide the client with user interface and thin client support. In one embodiment, these may include capabilities for building and maintaining web-based applications, providing web support facilities such as user Profile Management, Collaboration Services and Email and Fax services, as well as advanced Smart Scripting, etc.

In one embodiment, design time tools may be designed and configured to provide the services to customize, design, provide integration points, and maintain the application. These various tools provide one common place to define the application.

In one embodiment, admin services are designed and configured provide one place to monitor and administer the application environment. In one embodiment, these services allow the user to administer the application either through a graphic user interface (GUI) or from a command line, etc.

II. System Framework or Infrastructure

FIG. 5A illustrates an exemplary system framework or infrastructure 500 to support an interactive web client 205 and a mobile web client 210 of FIG. 2 in accordance with one embodiment of the present invention. FIG. 5B illustrates an alternative view of the exemplary system framework or infrastructure 500 shown in FIG. 5A.

The framework or infrastructure 500 can support the interactive web client 205 (shown in FIG. 2) and the mobile web client 210 (also shown in FIG. 2), and is capable of meeting certain criteria, such as increasing the interactivity and performance of the web client and the mobile web client, and reducing the number of page refreshes for common actions.

The framework or infrastructure 500 can include objects 502 that can be dynamically created on the browser to mimic corresponding objects 504 managed by the object-manager. In one embodiment, the objects 504 managed by the object manager (OM) can be built using a programming language, such as C+++, supporting the object-oriented paradigm.

As shown in FIGS. 5A and 5B, exemplary objects 504 managed by the OM can include an object 506 representing a view, CSSWEView 506. A view is generally a display panel consisting of a particular arrangement of applets. In one embodiment, one active view can be displayed at any given time. Another exemplary object managed by the OM can be an object 508 representing an applet, CSSWEApplet 508. An applet is generally a visual application unit that appears on the screen as part of a view. Other exemplary objects managed by the OM can include an object 510 representing a business component (CSSBusComp 510), an object 512 representing a business object (CSSBusObj 512), and an object 514 representing a frame (CSSWEFrame 514). In one embodiment, the business object may be designed as configurable software representations of the various business rules or concepts such as accounts, contacts, opportunities, service requests, solutions, etc. In this embodiment, the business components typically provide a layer of wrapping over tables, and the applets reference business components rather than the underlying tables. In addition, a frame is generally a sub-component of a view and may comprise of one or more applets.

In one embodiment, objects 502 on the browser can be built using JavaScript. As shown in FIGS. 5A and 5B, exemplary objects 502 on the browser side may include JSSBusObj 516, JSSBusComp 518, JSSView 520, and JSSApplet 522 to respectively mirror CSSBusObj 512, CSSBusComp 510, CSSWEView 506, and CSSWEApplet 508, which are objects 504 managed by the OM.

Objects 502 on the browser and objects 504 managed by the OM can be configured to reside and operate on one computing device or multiple computing devices. FIG. 6A illustrates an exemplary configuration 600 in which objects 502 on the browser and objects 504 managed by the OM reside and operate on multiple computing devices 602,604, including a client 602 and a server 604. FIG. 6B illustrates an exemplary configuration 650 in which objects 502 on the browser and objects 504 managed by the OM reside and operate on one computing device 652.

Returning to FIGS. 5A and 5B, objects 502 on the browser are generally synchronized with corresponding or mirrored objects 504 managed by the OM. Synchronization can be accomplished through a remote procedure call (RPC) mechanism 528 and a notification mechanism 530. The RPC mechanism 528 and the notification mechanism 530 will be described below in more details.

Of the objects 502 on the browser, the JSSApplication object 524 typically exists throughout a user-session. The JSSApplication object 524 should be initially loaded when the user starts an application. An application would generally be started when the user invokes a subset of the application from an icon on the desktop or from the Start menu. The JSSApplication object 524 generally performs a role similar to that of the CSSModel object 534. The CSSModel object 534 is generally a global session object that provides access to repository objects that are in use, the current business object instance in memory, the relationships between the current business object and the business components contained in it, and the user's global state information. The CSSModel object 534 generally accesses a repository 532 to obtain needed information. The repository 532 is generally a set of object definitions used to define an application or a suite of applications. However, the JSSApplication object 524 is generally scaled down to track one view, applets associated to the tracked view, one business object, and the business components that are in use in the view.

Unlike the JSSApplication object 524, the JSSView object 520, the JSSApplet object 522, the JSSBusObj object 516 and the JSSBusComp object 518 are typically temporary or impermanent entities, and are generally replaced when a page refresh occurs. For example, a request to navigate to a new view may cause a new set of JSSView 520, JSSApplet 522, JSSBusObj 516, and JSSBusComp 518 objects to be created to run on the browser.

Accordingly, objects 502 on the browser can be generally described as lightweight representations of mirrored or corresponding objects 504 managed by the OM. Each object 502 on the browser would typically include a subset of the functionalities included in corresponding objects 504 managed by the OM. For example, the JSSView object 520, similar to a CSSView object 506, generally represents a collection of applets. The JSSBusObj object 516, similar to a CSSBusObj object 512, generally manages the various one-to-many relationships between active business components so that correct relationships are employed when these active business components are populated via queries. The JSSBusObj object 516 generally exists on the browser for the life of the current view, and should be kept in sync with the corresponding CSSBusObj object 512.

In one embodiment, when the browser submits a request to navigate to a new view to the web engine 526, the web engine 526 would send a response containing the view layout that is devoid of data. Then the web engine 526 would send a response containing a string of data to populate the view.

The JSSApplication object 524 generally manages communications flowing into and out from objects on the browser. In one embodiment, a method invoked on an object on the browser would typically be directed to the JSSApplication object 524 if the invoked method should be retargeted to an object 504 managed by the OM. The JSSApplication object 524 would generally use the RPC mechanism 528 to route the invoked method through the web engine 526 to the appropriate object 504 managed by the OM. The web engine 526 would typically be employed to send return notifications and data from objects 504 managed by the OM to objects 502 on the browser. The web engine 526 would generally use the notification mechanism 530 to route notifications and data through the JSSApplication object 524 to objects 502 on the browser.

The browser objects 502 generally use the remote procedure calls 528 to invoke methods on the objects 504 managed by the OM. These remote procedure calls 528 are generally packaged as HTTP requests. Responses from the objects 504 managed by the OM are packaged as HTTP responses containing notifications and associated status information and data. In one embodiment, remote procedure calls are made with blocking enabled to ensure synchronization between the objects 502 on the browser and the objects 504 managed by the OM. With blocking enabled, control would typically not be passed back to the calling code until the called remote procedure finishes executing.

Remote Procedure Call (RPC)

The RPC model generally uses the same procedural abstraction as a conventional program, but allows a procedure call to span the boundary between two computers. FIG. 7 illustrates an example of how the RPC paradigm can be used to divide a program 700 into pieces that can be executed on separate computing devices 702,704. This figure generally shows a distributed program having multiple procedures. Main( ) 706, proc_1( ) 708, proc_2( ) 710, proc_3( ) 712, proc_5( ) 714, proc_6( ) 716, and proc_7( )718 reside and operate in the first computing device or the client 702; and proc_4( ) 720 and proc_8( ) 722 reside and operate in the second computing device or the server 704. A solid line 724 from procedure n to procedure m denotes a call from n to m. A dashed line 726 shows how control passes from one computing device to another computing device during a remote procedure call.

FIG. 8 illustrates an exemplary model 800 of execution used with remote procedure calls. In this figure, solid lines 724 are generally used to denote flow control within a computing device; and dashed lines 726 are generally used to show how control passes from one computing device to another computing device during a remote procedure call.

As such, a remote procedure call generally executes a procedure located in a separate address space from the calling code. The RPC model is generally derived from the programming model of local procedure calls and takes advantage of the fact that every procedure contains a procedure declaration. The procedure declaration defines the interface between the calling code and the called procedure. The procedure declaration defines the call syntax and parameters of the procedure. Calls to a procedure should typically conform to the procedure declaration.

Applications that use remote procedure calls look and behave much like local applications. However, an RPC application is divided into two parts: a server, which offers one or more sets of remote procedures, and a client, which makes remote procedure calls to RPC servers. A server and its client(s) generally reside on separate systems and communicate over a network. RPC applications depend on the RPC runtime library to control network communications for them. The RPC runtime library generally supports additional tasks, such as finding servers for clients and managing servers.

A distributed application generally uses dispersed computing resources such as central processing units (CPU), databases, devices, and services. The following applications are illustrative examples of distributed applications: A calendar-management application that allows authorized users to access the personal calendars of other users; A graphics application that processes data on CPUs and displays the results on workstations; and A manufacturing application that shares information about assembly components among design, inventory, scheduling, and accounting programs located on different computers.

RPC software should generally meets the basic requirements of a distributed application including: Clients finding the appropriate servers; Data conversion for operating in a heterogeneous environment; and Network communications

Distributed applications include tasks such as managing communications, finding servers, providing security, and so forth. A standalone distributed application needs to perform all of these tasks itself. Without a convenient mechanism for these distributed computing tasks, writing distributed applications is difficult, expensive, and error-prone.

RPC software typically provides the code, called RPC stubs, and the RPC runtime library that performs distributed computing tasks for applications. The RPC stubs and the RPC runtime library should be linked with client and server application code to form an RPC application.

Table 1 generally shows the basic tasks for the client and server of a distributed application. Calling the procedure and executing the remote procedure, shown in italicized text, are performed by the application code (just as in a local application) but here they are in the client and server address spaces. As for the other tasks, some are performed automatically by the stubs and RPC runtime library, while others are performed by the RPC runtime library via API calls in the application code.

TABLE-US-00001 TABLE 1 Basic Tasks of an RPC Application Client Tasks Server Tasks 1. Select network protocols 2. Register RPC interfaces 3. Register endpoints in endpoint map 4. Advertise RPC interfaces and objects in the name- space 5. Listen for calls 6. Find compatible servers that offer the procedures 7. Call the remote procedure 8. Establish a binding with the server 9. Convert input arguments into network data 10. Transmit arguments to the server's runtime 11. Receive call 12. Disassemble network data and convert input argumemts into local data 13. Locate and invoke the called procedure 14. Execute the remote procedure 15. Convert the output arguments and return value into network data 16. Transmit results to the client's runtime 17. Receive results 18. Disassemble network data and convert output arguments into local data 19. Return results and control to calling code

FIG. 9 generally shows an exemplary partitioning 900 of RPC application code segments 904 and 914, RPC interfaces 906 and 916, client and server stubs 908 and 918, and the RPC runtime libraries 910 and 920 in the RPC client 902 and the RPC server 904.

The RPC client 902 or the RPC server 912 typically contains RPC application code segments 904 and 914, RPC interfaces 906 and 916, stubs 908 and 918, and the RPC runtime libraries 910 and 920. The RPC application code segments 904,914 are generally the code written for a specific RPC application by the application developer. The RPC application code segments 904,914 generally implement and call remote procedures, and also calls needed routines or procedures in the RPC runtime library. An RPC stub 908,918 is generally an interface-specific code module that uses an RPC interface 906,916 to pass and receive arguments. A client 902 and a server 912 typically contain complementary RPC stubs 906,916 for each shared RPC interface 906,916. The RPC runtime library 910,920 generally manages communications for RPC applications. In addition, the RPC runtime library 910,920 should support an Application Programming Interface (API) used by RPC application code to enable RPC applications to set up their communications, manipulate information about servers, and perform optional tasks such as remotely managing servers and accessing security information.

RPC application code segments 904,914 usually differ for clients and servers. RPC application code 914 on the server 912 typically contains the remote procedures that implement one RPC interface. RPC application code 904 on the corresponding client 902 typically contains calls to those remote procedures.

RPC stubs 908,918 generally perform basic support functions for remote procedure calls. For instance, RPC stubs 908,918 prepare input and output arguments for transmission between systems with different forms of data representation. RPC stubs 908,918 use the RPC runtime library 910,920 to handle the transmission between the client 902 and server 904. RPC stubs 908 on the client 902 can also use the local RPC runtime library 910 to find appropriate servers for the client 902.

FIG. 10 generally shows an exemplary marshalling and unmarshalling between client data structures and server data structures. When the client RPC application code calls a remote procedure, the client RPC stub 908 should prepare the input arguments 1002 for transmission. The process for preparing arguments for transmission is known as "marshalling."

Marshalling 1004 generally converts input or call arguments 1002 into a byte-stream format and packages them for transmission. Upon receiving call arguments, a server RPC stub 918 unmarshalls 1014 them. Unmarshalling 1014 is generally the process by which a stub disassembles incoming network data and converts it into application data using a format that the local system understands. Marshalling 1004,1016 and unmarshalling 1014,1006 both occur twice for each remote procedure call. The client RPC stub 908 marshalls 1004 input arguments 1002 and unmarshalls 1006 output arguments 1008. The server RPC stub 918 unmarshalls 1014 input arguments 1006 and marshalls 1016 output arguments 1008. Marshalling and unmarshalling permit client and server systems to use different data representations for equivalent data. For example, the client system can use ASCII data 1002,1008 and the server system can use Unicode data 1018 as shown in FIG. 10.

The IDL compiler (a tool for application development) generates stubs by compiling an RPC interface definition written by application developers. The compiler generates marshalling and unmarshalling routines for platform-independent IDL data types. To build the client for an RPC application, a developer links client application code with the client stubs of all the RPC interfaces the application uses. To build the server, the developer links the server application code with the corresponding server stubs.

In addition to one or more RPC stubs, each RPC server and RPC client should be linked with a copy of the RPC runtime library. The RPC runtime library generally provides runtime operations such as controlling communications between clients and servers and finding servers for clients on request. RPC stubs in the client and the server typically exchange arguments through the RPC runtime library that is respectively local to the client and the server. The RPC runtime library on the client typically transmits remote procedure calls to the server. The RPC runtime library on the server generally receives the remote procedure calls from the client and dispatches each call to the appropriate RPC stub on the server. The RPC runtime library then sends the results of each call to the RPC runtime library on the client.

RPC