MXPA00002966A - Graphical user interface for web enabled applications - Google Patents

Abstract

An integrated system of user interfaces (20) is provided for communicating with remote services. A backplane architecture controls and manages the user interfaces by instantiating, launching, overseeing and closing the user interfaces associated with a plurality of applications residing in a plurality of remote servers (24, 26, 28, 31, 32, 34, 52). Each application communicates with one another and with the backplane via messaging interfaces.

Description

GRAPHICAL USER INTERFACE FOR APPLICATIONS ENABLED BY NETWORK The present invention relates in general to computer software, and more particularly user interface software in a server-client network architecture. A server-client software system that has a front-end graphical user interface and one or more back-end legacy systems are generally known in the information systems industries. The World Wide Web based on online systems is also beginning to emerge as the use of the Internet proliferates around the world. These online, network-based systems usually employ a network browser that displays pages of a hypertext markup language (HTML) such as the graphical user interface (GUI), and often includes Java applets and common port interface programs ( CGI) for interaction with the client. In these systems, however, recovery from a uniform resource locator (URL) and display on the client's screen is often done on a page-by-page basis. That is, each page retrieved and displayed is independent of any previous or subsequent page. Because each page is deployed and executed independently of the others, the components that exist on a page are limited in their ability to communicate with other components that exist on other pages. Moreover, there is no central structure architecture to manage and monitor the graphical user interface when screen displays are presented as independent HTML pages. Additionally, HTML pages and Java applets are usually confined to the network browser within where they are running. Therefore, it is highly desirable to provide a network-based user graphical interface system that includes a central structure architecture for managing and enabling communications and interoperability between various processes or components comprising the user graphical interface system, and at the same time, provide some independence from the network browser within which the graphical user interface is running. In conventional systems, a connection is made to a large legacy system via a dial-up connection from the personal computer belonging to the client or to the workstation. This connection frequently, though not always, emulates a steerable terminal by the legacy system. Dial-up access requires client software at the client's workstation to provide dial-up services, communication services, emulation and / or translation services and generally some form of resident client for the legacy application to connect to the client. mid-range computer or main computer running the legacy system. There are several problems associated with this approach: First, the aforementioned software is very hardware dependent, requiring multiple software versions compatible with each of a wide variety of client workstations that they usually have. Therefore, an extensive inventory is necessary for distribution. If the client's hardware platform changes toward improvement, the software license items must be renegotiated. Moreover, installing the software usually requires an intense effort from the client and the software support team before reliable and secure sessions are possible. Second, dial-up, modem, and communications software interact with each other in different ways that are not always predictable for a client application, requiring extensive problem-finding and problem-solving for a company that you want to make available to the customer the legacy system, particularly when several telephone exchanges, marking standards or signal standards are involved. Third, although more businesses are turning to the Internet to improve customer service and lower costs by providing network-based support systems, when a company wants to make more than one system available to the customer, the customer application for a legacy system does not it can be connected to a different legacy system, and the client usually has to say goodbye and say hello again to change from one to the other. The delivery technology used by the two legacy systems may be different, requiring different standards of interfaces, and different machine-level languages may be used by the two systems, such as the 96-character EBCDIC language used by IBM, and 127-character ASCII language used by contemporary personal computers. Therefore, an integrated and unified network-based system is desired to provide access to several different legacy systems in a session. Finally, the security and rights features of various legacy systems can be completely different and can vary from system to system and from platform to platform. Therefore it is desired to provide connectivity to business legacy systems over the public Internet, since the Internet provides connectivity access throughout the world through the TCP / IP protocol, without the need to navigate several telephone exchanges, dialing standards or standards. of signals. The popularity of the public Internet provides a measure of platform independence for the client, since the client can run their own Internet network browser and use their own platform connection to the Internet to enable services. This solves many of the hardware and platform connectivity problems in favor of the customer, and allows the customer to choose their own platform and operating system. Network-based programs can minimize the need for training and support because they use existing client software that the user already has installed and already knows how to use it. Also, if the client then changes that platform then, once the new platform is enabled for the Internet, the service is restored for the client. The loading of connectivity and communications software is thus resolved in favor of standard and easily available hardware and the search and marking software used to obtain and establish a public Internet connection. A paradigm delivered by the Internet solves many of the installation and configuration problems involved with the initial establishment and configuration of a client workstation, since the client application required to connect to the legacy system can be delivered via the Internet public and run within a standard network browser, reducing the compatibility problems of applications to search engine compatibility problems. For the company, the use of instantaneous network search engines by the client significantly simplifies the burden of the company limiting the development side of the client to analyze projects and data presentation tools that use a common interface enabled by the network browser. Software development and support resources are thus available for delivery by business legacy services and are not consumed by a need for customer support at the workstation level. The present invention is directed to an integrated graphical user interface system for enabling a user to interact with one or more application services provided by the remote servers. The present invention uses the paradigm of the network to allow easy and convenient access from the user's perspective. In order to provide cross platform software that is not dependent on specific hardware or specific operating system, the present invention is implemented using programming languages, such as Java® which only requires a Java® enabled network browser. The system of the present invention includes an application backplane unit for controlling and managing the global user interface system to a number of network enabled application services. By invoking the backplane unit a user can receive several different services available from the remote servers. Each remote service includes its own user interface unit, hereinafter referred to as the client application, independently implemented with each other and the backplane. Although client applications are developed independently as separate modules, the system of the present invention provides a capability to integrate client applications into a unified system, allowing users to access individual client applications via the backplane unit. As a novel feature, the present invention provides interoperability between each of the client's applications and the backplane, as well as between the client's applications. In accordance with the foregoing, it is the object of the present invention to provide a client interface system integrated to a number of different services available from remote servers, where separate client applications can communicate with each other and with the unit from backplane. The present invention includes a centralized user authentication feature to ensure that the user has valid access to the system. The authentication procedure generally includes a greeting object which prompts and accepts the user's name and password. The salutation object communicates the greeting transaction to the remote server responsible for filtering the users who try to access the remote services. As soon as a user has been authenticated by the system of the present invention, the user does not need to be validated again each time the user has access to another remote server via the user interface program of the respective server. In addition, each application can supplement the authentication procedure provided, with its own authentication method communicating with their respective servers independently. In accordance with the foregoing, it is another object of this invention to provide a unified authentication process for all remote services to ensure that only users with valid access codes can access the remote services. As soon as a validated user is registered in the system, the user is presented with a set of remote services that the user can obtain. The set of remote services available to each user is unique and depends on the user's subscriptions to the services. The service subscription set then forms the user's rights for the services. In this way, if a user subscribes to a free network service, the user has the right to have access to the information regarding the service. On the other hand, if the user does not subscribe to the free network service, that option is not available for the user to select. The present invention includes a user object to represent a current user registered in the system. This user object, among others, is responsible for obtaining from a remote server the information of the current user including the rights of the user for several remote services. The backplane uses the rights information to provide only the rights available to the user. As explained above, the backplane could disable the services to which the user has no rights, blocking the user from accessing those services. further, the user information is maintained for the duration of a session of greeting, allowing both the backplane and client applications to access the information as necessary throughout the duration of the session. The backplane and client applications use the information to selectively provide remote services to users. In accordance with the foregoing, this would make it another object of the present invention to provide a mechanism for retrieving and maintaining user information and rights so that they are available for processes and ropes running on the client platform without having to communicate with a server remote each time the information is needed.

The system of the present invention presents the remote services for the user to select in a form from an application toolbar on a screen. The toolbar runs in an independent framework and allows users to access different remote services from the screen during the life of a session. The system of the present invention implements a "live-in message" passed between a client and a server, called a "heartbeat". For example, a stay alive message is sent every previously defined period, for example, one minute from a client application to the server. When the client application fails to beat consecutively for a predetermined period of time, for example, one hour, the server treats this client application as it has left by closing the application and performing cleaning routines associated with the application. This mechanism effectively prevents unwanted sessions from being opened in the case of client application failures. In accordance with the above, it is another object of the present invention to provide a mechanism for detecting communication failures among the "stateless" processes that are executed in the present invention. The present invention also includes object-oriented base classes and interfaces for the backplane and for the use of client applications. Client applications are typically extended and implemented in order to achieve close integration with the backplane unit. Through the use of basic classes and interfaces, client applications can be implemented in more than one way. For example, the client application can be derived directly from the Java object class, or alternatively, from the Java applet class. Depending on the implementation mechanism, the backplane can launch the client applications either directly or by retrieving another page from the network that launches the client application. In accordance with the foregoing, it is another object of the present invention to provide a flexible and modular approach to implement each of the client's applications as the need arises, and yet at the same time provide tightly controlled runtime environment for the applications of the client. different customer. Preferred embodiments of the present invention will now be described, by way of examples only, with reference to the accompanying drawings in which: Figure 1 illustrates the software architecture component comprising a three-tier structure; Figure 2 is a diagrammatic overview of the software architecture of the MCI Interact networ system; Figure 3 is an illustrative example of a schematic backplane architecture invoked from a home page of the present system; Figure 4 illustrates an exemplary client graphical user interface presented to the client / interested party as a search engine web page; Figure 5 is a diagram representing the physical network architecture in the system of the present invention; Figure 6 is an example illustrating a page of the salutation network of the present invention; Figure 7 is a context diagram illustrating interactions with a user, a client platform, an OE system and other application systems such as the entry box, the requestor of reports, and the network administrator; Figure 8 is a data flow diagram illustrating the process diagram of the present invention during salutation, rights request / response, heartbeat transmissions and farewell procedures; Figure 9 is a data flow diagram for several transactions reported in the system of the present invention. Figure 10 is a flow chart illustrating a greeting process for the system of the present invention; Figure 11 is a flow diagram illustrating the process of backplane logic when a user selects a service; and Figure 12 is a diagram illustrating a security module design that has a clean separation from the specific implementations of the browser.

An Overview of the Network-Enabled Integrated System The present invention is a component of an integrated set of network client reporting and management applications using a network finder paradigm. Known as the networkMCI Interact system ("nMCI Interact") this integrated set of network-based applications provides an invaluable tool to enable customers to manage their telecommunications data values quickly and securely from anywhere in the world. The nMCI Interact system architecture is basically organized as a set of common components comprising the following: 1) an object-oriented software architecture that details the nMCI client-server-based aspect Interact; 2) a network architecture that defines the physical network necessary to satisfy the security and data volume requirements of the networkMCI system; 3) a data architecture that handles the application, back end or legacy data sources available for networkMCI Interact; and 4) an infrastructure that covers security, order entry, compliance, billing, self-supervision, measurements and support. Each of these areas of common components will generally be discussed later herein. Figure 1 is a diagrammatic illustration of the software architecture component in which the present invention operates. A first level or client level 10 of software services is resident in a client workstation 10 and provides client access to the enterprise system, having one or more loadable application objects addressed to front end business logic, one or more backplane service objects for administration sessions, one or more presentation services objects for the presentation of options to the client and data requested by the client in a format recognizable by the search engine and a search engine supplied to the client for presentation of options to the client and data to the client and for communications on the public Internet. Additional applications are directed to front end services such as the presentation of data in the form of tables and diagrams, and data processing functions such as classification and summarization so that multiple programs are combined into a set of unified applications. A second level or medium level 16 is provided, which has secure network servers and back end services to provide applications that establish user sessions, govern user authentication and rights, and communicate with adapter programs to simplify the exchange of information. data through the network. A third level or back end level 18 having applications directed to legacy back end services that include database storage and recovery system and one or more database servers to access system resources from one or more more main legacy computers. Generally, as will be explained later, the client workstation includes client software capable of providing a platform-independent, user-based, consistent user interface that implements scheduled objects to provide a GUI abstraction (graphical user interface) common and reusable domain abstractions problem. More specifically, client-level software is created and distributed as a set of Java classes that include applet classes to provide an industrial strength, an object-oriented environment of industrial strength over the Internet. Specific classes of applications are designed to support the functionality and the interfaces of servers for each application delivering the functionality through the system of two types: (1) cross product, for example, functions of input and report box, and (2) specific product, for example, free network management functions or call management functions. The system is capable of giving customers the right functionality to their product mix. Figure 2 is a diagrammatic overview of the software architecture of the networkMCI Interact system, which includes: system finder (a.k.a. the client) 20; the demilitarized zone (DMZ) 17 comprising a cluster of network servers 24; the Intranet Dispatch Server MCI 26; and MCI 30 Intranet application servers, and data warehouses, legacy systems, etc. 40. Client finder 20, is an enabled browser and includes client applications responsible for presentation and front-end services. Its functions include providing a user interface to several MCI services and supporting communications with the network of MCI 24 intranet network servers. As illustrated in Figure 3, and described more specifically below, the level software The client is responsible for the presentation services to the client and generally includes a network browser 14 and additional object-oriented programs that reside on the platform of the client's workstation 20. The client's software is usually organized into a component architecture each component being generally a specific application, which provides an area of functionality. The applications are generally integrated using a "backplane" services layer 12 that provides a set of services to the objects of the application provided by the front-end business logic. The backplane service layer 12 also handles the launching of application objects. The common set networkMCI Interact of objects provides a set of services to each of the applications. The set of services includes: (1) session management; (2) application launch; (3) interaplications communications; (4) window navigation between applications; (5) record management; and (6) version management. The primary common object services include: graphical user interface (GUI); communications; Print; user identification; authentication, and rights; import and export of data; registration and statistics; error handling; and message services. Figure 3 is a diagrammatic example of an example backplane architecture illustrating this relationship between common objects. In this example, the backplane service layer 12 is programmed as a Java applet that can be loaded and launched by the network browser 14. With reference to Figure 3, a typical user session begins with a network browser 14 creating a backplane 12, after successful salutation, the backplane 12, among others presents the user with an interface for an application administration of networkMCI Interact. A typical user display provided by the plane 12 may show several applications that the user is entitled to execute, each application represented by buttons represented in Figure 3 as the buttons 58a, b, c selectable by the user. As illustrated in Figure 3, after the selection of an application, the backplane 12 launches this specific application, for example, service inquiry 54a or event monitor 54b, creating the application object. When processing its functions, each application in turn can use common object services provided by the backplane 12. Figure 3 shows the graphical user interface objects 56a, b created and used by the respective applications 54a, b for their own presentation purposes. Figure 4 illustrates a graphical client user interface presented to the client / stakeholder as the page of the searcher network 250 which provides, for example, a set 252 of management report applications including: MCI 252c traffic monitor; call manager 252f; and network administrator 252e. Access to network functionality is also provided through the 252b report requestor, which provides a variety of detailed reports for the customer / stakeholder and a 252a message center to provide improvements and functionality to traditional e-mail communications. As shown in Figure 2, the client finder objects communicate the data by establishing a secure TCP message session with another of the servers in the demilitarized zone networkMCI Interact network 24 via a secure Internet communications path 22 established, preferably , with a layer version of safe sockets (SSL) of HTTPS. The network servers networkMCI Interact of demilitarized zone 24 function to decode the message of the client, preferably via the implementation of the SSL, and unwrap the key of the session and verify the user session. After establishing that the request has arrived from a valid user and mapping the request to its associated session, the servers in the demilitarized zone network 24 re-encode the request using symmetric coding and sending it on a second socket connection 23 for the dispatcher server 26 inside the Intranet of the company. A networkMCI Interact session is designed by means of a greeting, successful authentication, followed by the use of server resources, and farewell. However, the communications protocol of the global area network www uses HTTP, a stateless protocol, each HTTP request and response is a separate TCP / IP connection, completely independent of all previous or future connections between the same server and client. The nMCI Interact system is implemented with a secure version of HTTP such as S-HTTP or HTTPS, and preferably uses the SSL implementation of HTTPS. The preferred mode uses SSL that provides a separate spectral message that provides server authentication during a session. The preferred embodiment also associates a given HTTPS request with a logical session which is initiated and tracked by a "cookie jar" server 28 to generate a "cookie" which is a unique key generated by the server that is sent to the client along with each response to an HTTPS request. The client saves the cookie and returns it to the server as part of each subsequent HTTPS request. As desired, either the servers of the network 24, the cookie jar server 28 or the dispatch server 26, can maintain the "cookie jar" to map these keys to the associated session. A separate cookie jar server 28, as illustrated in FIG. 2, has been found desirable to minimize the load of the dispatcher server 26. This form of session management also functions as an authentication of each HTTPS request, adding an additional level of security to the global process.

As illustrated in Figure 2, after one of the demilitarized zone network servers 24 decodes and verifies the user session, it sends the message through a thermosensitive wall 25b over a TCP / IP connection to the dispatcher server 26 over a new TCP socket while an original 22 socket of the search engine is blocking, waiting for an answer. The dispatcher server 26 develops an outer protocol layer of the message from the server cluster of demilitarized zone 24, and recodes the message with symmetric coding and sends the message to an appropriate application representative via a third TCP / IP 27 socket. the response of the representative the three sóquets 22, 23, 27 block a receipt. Specifically, as soon as the message is decoded, the wrappers are examined to reveal the user and the target mid-level service (Intranet application) for the request. A first level of validation is carried out, making sure that the user has the right to communicate with the desired service. The user's rights with respect to this are extracted from the memory by the dispatcher server 26 from the StarOE server 49, and the server component of the present invention, at the time of the greeting and stored in the immediate memory. If the requestor is authorized to communicate with the target service, the message is sent to the representative of the desired service. Each application representative is an application-specific "daemon" that resides on a specific Intranet server, shown in Figure 2 as a joint or mid-range server 30. Each Intranet application server in set 30 is generally responsible for providing a specific rear end service requested by the customer, and, additionally, it is capable of requesting services from other Intranet application servers communicating to the specific representative associated with the other application server. In this way, an application server can not only offer its browser to a client for the server interface through the representative, but can also offer all its services from its representative to other application servers. In effect, the application servers that request services are acting as clients for the application servers that provide the services. This mechanism increases the security of the global system as well as reduces the number of interfaces. The network architecture of Figure 2 may also include a variety of application-specific representatives that have associated intranet application servers that include: a StarOE representative for the StarOE application server 39 to handle authentication, order entry / billing; an input box representative for the input box application server 31, which functions as a container for completed reports, call up detailed data and market new messages; a report manager representative capable of communicating with a specific report manager server of the system 32 for the generation, administration and notification of receipt of reports adapted to the client; a representative programmer of reports to carry out the programming and requests of the reports adapted to the client. Client-adapted reports include, for example: call usage analysis information provided by the StarODS 33 server; analysis information / network traffic monitor provided from the traffic view server 34; virtual data network alarms and behavioral reports provided by the broadband server 35; Trouble tickets for switching, transmission and traffic failure provided by the service inquiry server 36; and the free routing information provided by the free network administrator server 37. As partially shown in Figure 2, it is understood that each Intranet server in set 30 communicates with one or more consolidated network databases which include the information and data of network administration of each client. For example, the service inquiry server 36 includes communication with the MCI client services management legacy platform 40 (a). This administration of the network and data of the customer's network is additionally accessible by authorized MCI administration personnel. As shown in Figure 2, other legacy platforms, 40 (b), 40 (c), and 40 (d) can also communicate individually with Intranet servers to handle specific transactions initiated in the client's browser. The illustrated legacy platforms 40 (a), (d) illustrate only and it is understood that other legacy platforms can be interpreted in the architecture of the network illustrated in Figure 2 through an intermediate midrange server 30. Each of the individual representatives can be maintained in the dispatcher server 26, the related application server, or the separate proxy server located between the dispatcher server 26 and the midrange server 30. The relevant representative waits for an application client request that it is executed on the workstation of client 10 and then handles the request, either by handling it internally and sending it to the associated Intranet application server 30. Representatives additionally receive adequate responses again from the Intranet 30 application server. Any data returned from the Intranet application server 30 is translated back to the client format, and it returns over the Internet to the workstation of client 10 via the dispatcher server 26 and on one of the servers of the network in the cluster of servers of demilitarized zone 24 and the connection of secure sockets. When the resulting response header and drag application specifies data is sent back to the client's browser from the representative, the message will cascade all the time back to the real-time finder 14, limited only by the latency rate of transmission of the network. The intermediate-level software networkMCI Interact includes a communications component that offers three (3) types of data transport mechanism: (1) synchronous; (2) asynchronous; and (3) volume transfer. The synchronous transaction is used for situations in which the data will be quickly returned by the application server 40. In this way, a single TCP connection will be made and will remain open until the correct response has been recovered. The asynchronous transaction is generally supported for situations in which there may be a large delay in the response of the application server 40. Specifically, a representative accepts a request from a client or client via an SSL connection and then responds to the client 10 with a unique identifier and closes the connection of the sóquet. The client 10 may then combine repeatedly periodically until the response is ready. Each combination will occur on a new basketball connection to the representative, and the representative will respond with the resulting data or respond that the request is still in process. This will reduce the number of TCP connections consuming open resources at any time and will allow a user to close their browser or disconnect a modem and then return to verify the results. Volume transfer is generally intended for large data transfers and is unlimited in size. The volume transfer allows cancellation during a transfer and allows the programmer to code the resumption of the transfer at a later time. Figure 5 is a diagram representing the architecture of the physical system 10. As shown in Figure 5, the system is divided into three major architectural divisions that include: (1) the client's workstation 20 that includes the mechanisms that enable client connection to secure network connectors 24; (2) A secure network area 17, known as the demilitarized zone "DMZ" set aside at the MCI site with dual thermosensitive wall between the public Internet 25 and the MCI Intranet to avoid potentially hostile attacks to the client; and, (3) the company's mid-range Intranet servers 30 and the legacy main computer systems 40 comprising the back end business logic applications.

As illustrated in Figure 5, the present invention includes a double or complex thermosensitive wall system that creates a "demilitarized zone" (DMZ) between two heat-sensitive walls 25a, 25b. In the preferred embodiment, one of the thermosensitive walls 29 includes specific door filtration carriers, which can only be connected to a designated port on a dispatcher server within the demilitarized zone. The dispatcher server connects to an authentication server, and through a thermosensitive wall representative to the servers and applications. This ensures that even if a remote user ID and password are pirated, the only guaranteed access is that of the network servers 24 or intermediate data and privileges authorized for that user. In addition, the pirate may not connect directly to the company's server to the company's Intranet, thus ensuring the integrity of the internal company's system. Even with a stolen password, the pirate may not connect to other ports, root directories or applications within the company's system. The demilitarized zone acts as a thermosensitive double wall for the company's intranet because the network servers located in the demilitarized zone never store or calculate sensitive customer data. The servers of the network only put the data in a convenient form for the display for the client's network browser. Since the servers in the demilitarized zone network do not store client data, there is a much smaller opportunity for the client's information to be threatened in the event of a breach of security. As previously described, the client access mechanism is a client workstation 20 that employs a network browser 14 to provide access to the system of the present invention via the public Internet 15. When a subscriber connects to the site of the network of the present invention inscribing the appropriate URL, establishes a secure TCP / IP communication link 22 to one of several servers of the network 24 located inside a first thermosensitive wall 25a in demilitarized zone 17. preferably at least two servers of the network is provided to have the capacity to overcome faults. In the preferred embodiment of the invention, the system employs SSL encryption so that communications in both directions between the subscriber and the system of the present invention are secure. In the preferred embodiment, all secure network servers in demilitarized zone 24 are preferably DEC 4100 systems having Unix or NT based operating systems to execute services such as HTTPS, FTP, and Telnet over TCP / IP. Network servers can be interconnected through an Ethernet local area network running at 100 Mbit / second or greater, preferably with the deployment of switches within Ethernet networks to improve bandwidth utilization. One of these switching units included as part of the network architecture 45 is a unit manufactured by HydraWEB® HydraWEB Technologies, Inc., which provides, the demilitarized zone with a virtual IP address so that the subscriber requests received over HTTPS the Internet will always be received. The HydraWEB® 45 unit implements a load balancing algorithm that enables intelligent packet routing and provides optimal reliability and performance while ensuring accessibility to the "most available" server. In particular, it oversees all aspects of the health of the network server from the use of the central processing unit, to the use of memory, to the available change space so that Internet / Intranet networks can increase their speed of impact and reduce the costs of administering the network server. In this way, resource utilization is maximized and bandwidth (production) is improved. It should be understood that a redundant HydraWEB® unit can be implemented in a running / standby configuration with heartbeat message between the two units (not shown). Moreover, the architecture of the system of the present invention supports a scalable network server, in both vertical and horizontal directions.

Additionally, the architecture is such that new secure network servers 24 can be easily added as the requirements and use of the client increase. The use of HydraWEB® allows for better load distribution when necessary to match performance requirements. As shown in Figure 5, the most available server 24 receives HTTPS requests from the subscriber, for example, from the HydraWEB® 45 over a connection 44a and generates the appropriate coded messages to route the request to the network server midrange of Suitable intranet over the connection 44b, router 55 and connection 23. Via the HydraWEB® 45 unit, a TCP / IP connection 38 links the secure network server 24 with the Intranet dispatcher server 26. In addition, as shown in demilitarized zone 17, it is a second server 52 having its own connection to the public Internet via a TCP / IP 48 connection. An additional TCP / IP connection 48 links this second network server 52 to the intranet dispatcher server 26. More specifically, as shown additionally in Figure 5, the physical architecture for the networkMCI Interact includes three routers: a first router 55 for routing encrypted messages from the Public Internet 15 to the HydraWEB® 45 on a basketball connection 44; a second router 55 for routing subscriber messages encoded from a secure network server 24 to a dispatcher server 26 located inside the second heat-sensitive wall 25b; and, a second router 65 for routing encrypted subscriber messages from the second network server 52 to the dispatching server 26 inside the second thermosensitive wall. Although not shown, each of the routers 55, 65 may additionally route signals through a series of other routers before eventually being routed to the dispatcher server 26. In operation, each of the secure servers 24 function to decode the message. of the client, preferably via the SSL implementation, and unwrap the key of the session and verify the user session from the authenticated COUser object in the greeting. After establishing that the request has come from a valid user and mapping the request to its associated session, the secure network servers 24 will re-encode the request using symmetric RSA encoding and send it over a second secure socket connection 23 to the dispatcher server 26 in of the Intranet of the company. As described herein, the data architecture component of the networkMCI interaction reporting system focuses on the presentation of detail data in real-time (priceless) calls, as provided by the MCI TrafficView server 34 , and detailed data and reports of price calls, such as those provided by the MCI StarODS 33 server in a variety of user-selected formats. All reports are provided through a graphical user interface application interface that requests a report, which supports a worksheet, a variety of graphic types and diagrams, or both simultaneously. For example, the presentation of the worksheet allows classification by any arbitrary set of columns. The report viewer can also be launched from the input box when a report is selected. A common database can be maintained to store common configuration data that can be used by graphical user interface applications and by mid-range servers. These common data include but are not limited to: user security profiles, billing hierarchies for each client, general server data (states, NPA, country codes), and customer-specific choice lists: for example, ANI, calling cards, and so on. An MCI Internet StarOE server manages the database for common data configuration. Data related to the management of reports are also generated that include 1) report profiles that define the types of reports that are available, fields for reports, default classification options and allowed client adaptations; 2) report requests that define client-specific report requests that include report type, report name, programming criteria, and subtotal fields. This type of data is typically resident in a report server server database and managed by the report manager. The infrastructure component of the nMCI reporting system includes mechanisms to provide secure communications regardless of the content of the data being communicated. The security infrastructure of the nMCI interaction system includes: 1) authentication, which includes the use of a password and digital certificates; 2) coding of public keys, such as those used by a protocol for encrypting security sockets layer (SSL); 3) thermosensitive walls, such as described above with reference to the network architecture component; and 4) non-repudiation techniques to guarantee that a message originated from a source is the actual identifier sender. One technique used to combat repudiation includes one of an external monitoring drag with one-way, one-way electronic message digestions included in each transaction. Another component of the nMCI interaction infrastructure includes command entries, which are supported by the present invention, the order entry service ("StarOE"). The general categories of the characteristics that can be ordered include: 1) report with prices; 2) Real-time report; 3) detail of calls with prices; 4) detail of calls in real time; 5) broadband SNMP alarm; 6) broadband reports; 7) RTM without limit; 8) RTM out of limit; 9) free network administrator; and 10) call manager. The order entry functionality extends to additionally support 11) event monitor; 12) consultation of services; 13) network administrator out of limit; and 14) online billing. The self-monitoring infrastructure component of the nMCI interaction is the use of mid-range servers that support SNMP alerts at the hardware level. In addition, all software processes should generate alerts based on process health, connectivity, and resource availability (for example, disk usage, use of central processing unit, database availability). The measurement infrastructure component for nMCI interaction is the use of mechanisms to monitor the production of the volumes that the network servers, the dispatcher server, the application representatives and the mid-range servers. Monitoring the measurements helps in determining the growth of the hardware and the network. To provide the functional areas described above, the client level 10 is organized into a component architecture, with each component providing the functionality tasks. Client-level software is organized into a "component" architecture that supports each application, input box search and input box administration, report viewer and report requestor, TFNM, event monitor, broadband, time monitor real, and system administration applications. Other functionality built into the software architecture includes applications such as off-limit network administrator, call manager, service inquiry, and online billing.

Client Finder Application The present invention is directed to the client-level software component of the overall system described above. The system of the present invention provides an integrated and unified interface to various network-enabled application services, i.e., compliance systems, available to a user. As shown in Figure 3, the system of the present invention implements an "application backplane" 52, a single object that keeps track of all client applications, and which has the capabilities to start, stop, and Provide references to any of the client's applications. The application backplane 52 is typically implemented as a Java applet and is launched when a page on the network is retrieved via the URL pointing to the company's network site. Client applications typically comprise a graphical user interface program that allows a user to interact with one or more remote services enabled by the network. The backplane 52 and client applications use a browser 50 such as Microsoft Internet Explorer versions 4.0.1 or greater for an access and distribution mechanism. Although the backplane is started with a browser 40, client applications are generally isolated from the browser because they typically present their user interfaces in a separate frame instead of nesting them inside the network page. The architecture of the backplane is implemented with several main classes. These classes include COPlanoPosterior (COBackPlane), COApp, COAppImpl, COParm, and COAppMarco (COAppFrame). COPlanoPosterior 52 is an application backplane that launches applications 54a, 54b, typically implemented as COApp. COPlanoPosterior 52 is usually implemented as a Java applet and is launched by the 50 network browser. This backplane applet is responsible for launching and closing the COApps. When the backplane is implemented as an applet, it overlaps the standard applet methods init (), start (), stopO, and run (). In the init () method, the backplane applet obtains a user context object COUser (COUser). The COUser object maintains the information such as the user's profile, the applications and their rights. The user configuration and application rights provided in the context of the UserCode are used to build the application toolbar and the input box applications. When you click on an application toolbar icon, a particular COApp is launched using the launchAppO method. The launched application can then use the backplane for communications between applications, including retrieving data from the input box. COPlanoPosterior 52 includes methods to provide a reference to a particular COApp, for interoperation. For example, the COPlanoPosterior class provides a getAppO method and returns references to application objects by name. As soon as they are recovered in this way, the public interface of the application object can be used directly. COApp is the basic interface for applications. The applications, for example, TFNM 54a or call management 54b, generally have their start code and their inter-application interface in a class that implements COApp.

Generally, two classes are available for applications, COAppImpl or COApplet. Alternatively, their own implementation of the interface can be provided. In the preferred embodiment, the applications typically extend to COAppImpl. COAppImpl is a class "similar to applet", but it is not derived from java. applet .Applet or java.awc. Panel Without deriving from Applet, applications can be launched at any time without the search engine having to be pointed to a specific page, and it releases the applications of performers within the framework of the search engine. The classes derived from COAppImpl are created, launched, stopped and destroyed by the COPlanoPosterior 52. This provides a close and controlled integration by the system of the present invention. The COApplet class, on the other hand, extends the class Applet and it is intended to be launched by the search engine from an HTML tag < Applet > . The Applet extension is provided for applications that need more isolation from the present integrated system, or that require a separate browser-based deployment space. The COApplet class implements most of the COApp interface by sending it to a content COAppImpl object. The COAppMarco 56a, 56b is a computer window created and used by COApp to contain its user interface. The COAppMarco 56a, 56b is a separate window of the network browser 50. Generally, the COAppMarco 56a, 56b has a menu, a toolbar, and a status bar. The attachToviewArea () method of the COAppMarco can be used to paste a COVist object (COView) 60a, 60b, 60c into a COAppMarco 56a, 56b. The COVista class is a java extension. awt. Panel It provides a general purpose display space and container for a visual representation of the application. Application classes typically extend to the COVista classes to implement their presentation logic. COApp can use none, one, or many COAppmarks 56a, 56b. COParm is a generic data class used to pass parameters between applications. The COApp interface provides a public method for passing COParm message objects, for example, processing public empty message (COParm message), which can be used to pass messages between applications. The COPparm class contains a set of name-value pairs that are used to present information or requests. Figure 6 is an illustrative example of a salutation network page of the present invention. The salutation page 230 typically includes the fields of name 232 and password 234 for the user to enter. The page of salutation 230, in addition, may include hyperlinks 236 to other services such as the center of products and services, programs and promotions, and questions and answers with respect to the system of the present invention. After the user is properly authenticated via the page 230, a home page is retrieved. Figure 4, as previously described, illustrates an example of a home page, typically a new page of the network having a backplane object. The home page 250 is copied after authentication via the greeting page. Home page 250 comprises icons 252a-h for each application services as well as a toolbar and applications 254 for invoking services. The application toolbar 254 is different from the 252a-h icons because the application toolbar remains on the screen, although the home page 250 is no longer displayed. The home page also typically comprises HTML links to other services 256a-c these services may be a new information center, presentation of benefits, or support center for the system of the present invention. Figure 7 is a context diagram illustrating interactions with a customer, a customer platform, the StarOE, the order entry system, and other Intranet application services such as entry box, requestor of reports, and administrator of network to communicate various requests and transaction responses. Typically all customer interactions are carried out via a user interface program that it receives on the client platform 1356. The client platform 1356, in turn, communicates with the appropriate Intranet application services, for example, the entry box 1358, the report requestor 1360, and the network administrator 1362, to process the client's requests. The transactions communicated between the client platform 1356 and the client 1340 include the HTML page and cab file uploads 1402 according to the URL addressed to the client, the customer identification and password 1404 and requests by mouse and keyboard 1408 for acknowledgment of disclaimers of 1406 products as they are entered by the customer in the customer's terminal. In order to complete and process the transactions in response to a customer request, the 1356 customer platform communicates with the desired application services for information. For example, with StarOE, the client platform requests validation of sessions by communicating the user's identification and the client's password for 1412 authentication. The StarOE validates the user by checking the user identification / password pair stored in the client's profile and if it is valid, it generates a message transaction response that includes company identification and customer rights. The StarOE then transmits the validated session response 1414 with the company identification and the customer rights 1416. If the user identification / password is not validated, the StarOE notifies the client's platform, in which case the client's platform can request second validation with a new username / password pair entered into the StarOE transmitting a request for revalidation session 1418. The client platform can also request from StarOE several rights information associated with the client including access rights to application or privileges that the client has with respect to the integrated association of network applications. Figure 7 also shows transactions between the 1356 client platform and several Intranet application services including the 1362 network administrator, the 1360 report requestor, and the 1358 entry box. These transactions are specific to the functionality of a service. application. For example, the client platform 1356 can send free network administration requests 1420 such as "add / delete TFNM corp IDs" message which adds or clears the corp IDs from the participant's free network administrator list and at identification company corp. The administration of the free network responds by sending a response message 1422 such as an "add / delete TFNM corp ids" response indicating that the request message was received and will be processed. Similarly, from the 1360 requestor, the platform 1356 can send a verification message center request 1424, and the communication response of the message center to verify types of reports available in the message center. The report requestor 1360 can also send message center communication request 1428 to the platform 1356. Similarly, with the entry box 1358, transactions related to the message center such as request for metadata 1430 and responses 1432 can be communicated. As described above, StarOE is an authentication and rights system that handles "networkMCI Interact" greeting authentication and client rights for client sessions. At the beginning of the client's sessions and also during the duration of the sessions, all the application services communicate with the StarOE for the authentication of the client and their rights. Communication is typically done through the message interface, that is, by transmitting wrapped data with appropriate message headers and dragons. Figure 8 is a data flow diagram illustrating the flow of data between the processing modules of the system of the present invention during greeting, rights request / response, heartbeat transmissions and farewell procedures. As shown in Figure 8, the client platform includes the user networkMCI Interact 1340 representing a client, a page of the greeting network that has a salutation object for salutation processing 1342, a page orad that has the object in the posterior plane. The network server 1344, the dispatcher 1346, the cookie jar server 1352, and the OE 1348 server typically located on the company site. A session can be initiated when a 1340 client retrieves a page of network salutation by pointing a network browser to a uniform resource locator (URL) of "networkMCI Interact". Typically, cab files, class files and replenishment requests are copied to the salutation network page as shown in 1440. On the salutation network page, client 1340 then enters a user identifier (user id) and password for user authentication as illustrated at 1440. The client also introduces replenishment recognition 1440 on the salutation page 1342. If the user ID entered and the password is not valid or if there are too many unsuccessful greeting transactions, the greeting object 1342 communicates the appropriate message to the client 1340 as shown at 1440. A greeting object 1342, typically an applet launched on the page of the greeting network, connects to the network server 1344, to communicate a application for greeting to the system as shown in 1442. The greeting data, which have a coded user ID and password, was sent An alarm is sent to the dispatcher 1346 when they are established in connection as shown at 1444. Dispatcher 1346 then decodes the greeting data and sends the data to the StarOE 1348 after establishing a connection as shown at 1446. The StarOE 1348 server validates the identification of user and password and send the results back to the 1346 dispatcher as illustrated in 1446 along with the user's application rights. The dispatcher 1346 passes the results of the data obtained from the StarOE 1348 to the network server 1344 as shown at 1444, which passes the data back to the salutation object 1342 as shown at 1442. The client 1340 is then notified of the salutation results as shown at 1440. When the 1340 client is properly validated, the client is presented with another network page known as home page 1350, from which the backplane is typically launched. After user validation, the backplane generally administers the entire user session until the user says goodbye to the system of the present invention. As shown in 1448, the backplane initiates a session heartbeat that is used to detect and maintain live communications between the client platform and the company intranet site. The backplane also urges a user object to clean up all customer information as received from the StarOE 1348. For example, to determine which applications a current customer is entitled to access and activate only the application options on the page home to enable the client to select, the backplane sends a "get applications list" message via the 1344 network server and the 1346 dispatcher for the StarOE 1348 as shown in 1448, 1444, and 1446. The list of rights The customer is sent from the StarOE 1348 back to the dispatcher 1346, to the network server 1344 and to the backplane to the home page 1350 via the path shown at 1446, 1444, and 1448. The rights and applications for the customer are kept in the COUser object for proper use by the backplane and for subsequent recovery by the client's applications. Additionally, the rights information is also stored in a cookie jar 1352. When the network server receives the rights request from the backplane on the home page 1350 or from any other application of the client, the network server 1344 makes a connection to cookie jar 1352 and check if the requested information is included in cookie jar 1352 as shown at 1450. Cookie jar 1352 is a deposit of several client sessions and the details of each session are included in a cookie which includes the rights information of the OE server 1348. During the greeting process described above, the OE 1348 server can include in its response, the rights for the validated client. The dispatcher 1346 transfers the rights data to the network server 1344, which translates them in binary format. The network server 1344 then transmits the binary rights data to the cookie jar 1352 for storage and retrieval for the duration of a session. In accordance with the above, if the information requested can be located in cookie jar 1352, another request can not be made to StarOE 1348. This mechanism cuts the response time of processing the request. Although the same information, for example, customer application rights or rights for corporate identifiers, can be stored in the user object and maintained on the customer platform as described above, a second check is usually made with the cookie jar 1352 via the network server 1344 in order to secure against a violated or corrupted COUser object information. In this way, the rights are typically verified in two places: the client platform 1350 via the COUser object and the network server 1344 via the cookie jar 1352. When a connection is established with the cookie jar 1352, the server network 1344 makes a request for the rights of a given session as shown at 1450. The cookie jar 1352 goes through the stored list of cookies, identifies the cookie for the session and returns the cookie to the network server 1344 also shown at 1450 The network server 1344 typically converts the rights that are received in binary form, to rights chain representation, and sends the rights chain back to the backplane running on the 1350 client platform. 1352 cookies is used to handle beating transactions. Heartbeat transactions as described above are used to determine the continuity of the session and to identify processes that have died abnormally as a result of process failure, process crash or communications failure, for example. During a client session initialization, cookie jar 1352 generates session identification and establishes "heartbeat" transactions for the client session. Subsequently, a heartbeat request is typically sent from a process running on a client platform to the network server 1344, when a connection is established, as shown at 1448. The network server 1344 is connected to the cookie jar 1352 and request heartbeat update for a given session. The cookie jar 1352 searches for your stored list of cookies, identifies the cookie for the session and updates the beat time. The cookie jar 1352 then sends the network server 1344 the beat with updated status as shown at 1450. The network server 1344 then sends the status back to the client platform process, also shown at 1450.

When a client wants to say goodbye, a farewell request transaction can be sent to the network server 1344. The network server 1344 then connects the cookie jar 1352 and requests to dismiss the session as shown at 1450. The cookie jar 1352 identifies the cookie for the session and deletes the cookie. After deleting the cookie, cookie jar 1352 sends a farewell status to network server 1344, which returns the status to the client platform. Other transaction requests are also sent via the network server 1344 and the cookie jar 1352 as shown in Figure 9. Figure 9 is a data flow diagram of several transactions reported in the system of the present invention. Typically when a client enters a mouse click into an application link as shown at 1460, an appropriate transaction request stream is sent to the network server as shown at 1462. Network server 1344 typically decodes the transaction stream and connects to the cookie jar 1352 to verify whether a given session is still valid as shown at 1464. The cookie jar 1352 identifies the cookie for the session and sends it back to the network server 1344 as shown at 1464. The network server 1344 upon receipt of the valid session connects to dispatcher 1346 and sends the transaction request as shown at 1466. When dispatcher 1346 obtains the request, it can also be connected to cookie jar 1352 to validate the session as shown in 1468. The 1352 cookie jar identifies the cookie for the session and sends it back to the 1346 dispenser as shown at 1488. The 1346 dispenser, after After receiving the valid session, connect to an object application server or representative 354, which may include StarOE, and send the requested transaction to the target as shown at 1470. The server or representative 354 processes the request and sends the response again as data stream which is sent back to the dispatcher 1346 as shown at 1470. The dispatcher 1346 sends the data back to the network server 1344 as shown at 1466, which encodes and sends the data to the client platform as shown in 1462, called home page 1350 in Figure 9.

User Salutation Figure 10 is a flow chart illustrating a process of greeting the system of the present invention. Typically, a user initiates a browser in step 280 and accesses a page of the network that has a salutation applet by entering the URL in step 282 of the server serving the system of the present invention. The HTML file associated with the network page is loaded with software tools and common objects in steps 284, 286. The user is prompted to enter his name and password on the network page. If the system of the present invention determines that software files that include classes to initiate a session, have already been copied previously, for example, from a previous session, steps 282, 284, 286 are skipped. The salutation applet verifies the name / password entry and instantiate a session object in step 292, communicating the name / password pair. The object of the session sends a message containing the name / password to a remote server for user validation in step 294. When the user is authenticated appropriately by the server in step 296, another page of the network is copied that it has the object in the backplane in steps 298, 300, 304. This page is called the home page. At the same time, all the software objects of the application are copied in step 302. If the system of the present invention determines that the backplane and the application files have already been copied, steps 300, 302 are not performed, 304. The backplane object is urged in step 306. The backplane communicates with a remote command entry server component to retrieve the rights of the user in step 308. The rights represent specific services in which the user has subscribed and is privileged to have access. It also describes what rights the user may have within a single service. For example, from the COUser context, the backplane can obtain the list of applications that the user has the right to access. In addition, each COApp maintains a set of rights within the application in the COAppRules (COAppEntitlements) object. Using the context information COUser, the backplane knows which COApps to provide, for example, which buttons to install in its toolbar. The backplane stores the user's specific rights in memory for other processes to access. After determining the rights, the backplane starts a new chord and an application toolbar begins in step 310. The application toolbar includes the remote services to which the user has subscribed and can choose to execute. From the application toolbar, a user is able to select a service to execute. After selection of the user, the selection is communicated from the application toolbar to the backplane in steps 312, 314, which then launches the graphical user interface program associated with the selected service. The application toolbar is still in the user's deployment, even after a particular service has been started. This is useful when a user wants to start another remote service directly from having run a previous service because the user does not need to recover the home page again. If it is determined that the password entered by the user is not valid in step 290 or step 296, the greeting count attempted in step 316 is increased. If the greeting account that is attempted by the user is greater than a Pre-defined allowed number or tests as indicated in step 318, a message is transferred to the user in step 320 and the user must start the search engine. If the salutation account attempted by the user is not greater than the number of previously allowed allowed attempts, a "failed entry" message is conveyed to the user in step 322, and the user is prompted to reintroduce the name / password in the step 288. If it is determined that the user's password has expired, the user is prompted to change the password in step 324. For example, the user may be required to change the password every 30 days for security reasons. Whenever the user changes the password, the new password is transmitted in real time to a server responsible for updating and maintaining the password entry for the user. The user then enters the new password in step 324 and continues with the process described above in step 290.

Backplane Logic Figure 11 is a flow chart illustrating a backplane logic process when a user selects a service from a home page or from the application toolbar. The user initially selects an application in step 330. If the selected application is derived from COAppImpl, the object, COPlantePosterior 52, prompts the desired application object by name. The COPlanoPosterior 52 also creates a COApp StartCommit object to handle the start of the COAppImpl in step 336. Each COAppImpl starts on its own string. COAppStartCircle calls the init () method of COAppImpl. Here the COAppImpl typically creates the application-specific classes it needs, including the COAppMarco (or a class derived from it) if desired. COAppStartCircle calls the start () method of the COApp. As soon as the start () method has been completed, the COAppStartCord ends. If the desired application is derived from java. applet .Applet, a new search window is created, and it goes to the HTML page from which the applet will load 338. This will cause the search engine to load the applet, and call its init () method and start () In this init () method, the applet obtains a reference to the backplane by calling the static method of the COPlanoPosterior class to getPlannerPosterior (). Also in its init () method, the applet notifies the backplane that it has been launched by calling the registerApp () method of the backplane. Alternatively, if the desired application is an application that requires a direct URL launch from the home page, for example RTM, as shown in step 332, the desired application is invoked by retrieving a page from the network that has the URL of the application as shown in step 338. Each application obtains a session identifier in step 340 after its start. The input to the session and the administration will be described in more detail with reference to the classes of communications. If the applications wish to perform another additional authentication, they are free to recover the COU user object and perform any special authentication they need, without bothering the user to re-enter their username and password. During the process of functions specific to each application, the applications are able to communicate with each other as well as with the backplane obtaining a reference to the applications or the backplane and invoking the public interfaces or methods with the reference. After a user has finished interacting with COApp, the user requests the selected COApp to exit via a menu selection, by clicking on a box with a button in a window frame, or with a keyboard command, for example. The COApp then requests to leave the COPlanoPosterior. If the selected application is derived from COAppImpl, the COPlanoPosterior creates a COAppDetenerCuerda to handle the output of the COApp. As with the start, each COApp is stopped on its own string. COAppDetenerCord calls the stop () method COApp. Typically, a COApp will not be mounted on this method. It is called by consistency with the applet interface of the COApp class. An applet stop () method is called by the network browser when the web browser leaves the page from which the applet was loaded, in order to allow the applet, for example, to stop an animation. For consistency with this model, COApp can use this method to stop long-duration strings. The COAppStartCircle calls the destroy () method of COApp. Here the COApp typically performs resource cleaning routines, including stopping any chords, and calling the dispose () method for any COAppMarco object. If the selected application is derived from java. applet .Applet, the web browser window contains the page from which the applet was launched closes. This will cause the stopO method of the applet to be called by the network browser. In this stopO method, the applet notifies the backplane that it has been stopped by calling the deregisterApp () method of the backplane. Then a user typically requests to be dismissed via menu, closing box, and so on. When this request is received by the backplane, it sends transaction Farewell to the network server. The backplane closes the toolbar and directs the network browser to the salutation URL. Then the back plane comes out. Figure 11 also includes links to other web pages. For example, if the hypertext help is selected in step 342 of the application toolbar, a help URL is launched in a new lookup window in step 344. Similarly, if the customer support hypertext is selected in the Step 346, a customer support URL is launched in a new browser window in step 348. If a user selects a marketing promotion hypertext in step 350, the URL for the new product information will be launched in a new one. search window in step 352. If the product overview hypertext is selected in step 354, a URL belonging to the characteristics of the product will be launched in a new search window in step 356. If the user selects home in In step 358, the home page will be displayed again in step 360.

User The present invention includes a user unit to represent a user of a current session. The user unit is generally implemented as a COUser class that extends java. lang.Object. The COUser class object typically maintains information that includes a user profile, applications, and their rights. In order to minimize network traffic, the amount of data carried by the COU is initially minimal, and populated as requests are processed. Requests are usually processed by retrieving information from the Order Entry service. The profile information is stored and populated in the COUser object if this information is required again. A COUser object is created when the user registers, and maintains the user's name and password as an object in the COClient Session objects. The session object is contained within the backplane, which manages the session throughout its lifetime. The code below illustrates how this happens: // inside the backplane session COClient Session = new COClient Session (); try . { Session. salutation ("username", "password"); } capture (COClienteSalutaciónExcepción e). { ....}. , - // If the user object is required user COUser = session. getUser (); The salutation method of the COClienteSesión object communicates with the OE server (Figure 2), a back end authentication mechanism, to authenticate the user. The COUsuario that can be obtained from the COClienteSesión immediately after the start process is very scarce. It includes a limited set of information such as user name, a list of applications that the user is entitled to, for example. The details of each rights information are retrieved at the time of actual processing of that information.

Communications The present invention includes a client communications unit to provide a single interface from which the backplane and applications can send messages and requests or back end services. The client communications unit includes a client session unit and a client transaction unit. The client session unit and the transaction unit comprises classes used by client applications to create objects that handle communications to the different representatives of applications and / or servers. Generally, entire communications processes begin with the creation of a client session after a connection process. This starts through the connection process. The user registers on the user's network page with a username and password. During a connection process, the object of the client session of class with COClienteSesión is created, and the object COClienteSesión passes the user name and password information in pair obtained from the process of connection to an administrative service of the remote system that validates the particular The following code instructions are implemented, for example, to start a session using the class COClienteSesión. COClienteSesión ss = new COClienteSesión (); try . { sessionURL (urlCadena); sessionalutation ("j smith", "myPassword"); } cachar (COClienteSalutaciónExcepción e). { ..} cachar (MalformadaURLEexcpeción e). { ... In addition, the COClienteSesión object contains a reference to validate the object or user associated with the user of the COClienteSesión object. The session client object also provides a session, where a client registers in the system at the beginning of the session, and if it is authenticated successfully, it is authorized to use the system until the session ends. The client object session at the same time provides a capacity to maintain session-specific information for the life / duration of the session. Generally, communications to and from the client are carried out on HTTPS using the protocols HTTP over an SSL encrypted channel. Each request / response HTTP is a separate TCP / IP connection, completely independent of all previous or future connections from the same server and client. Because HTTP is stateless, which means that each connection consists of a single client request which is answered by a single reply by a server, a novel method is provided to associate a given HTTP request with the logical session to the which belongs When a user authenticates when connecting via the administrative server of the system, the object of the client session is given a "cookie", a unique key generated by the server that identifies a session. The session key is typically encapsulated in a COWebCookie class, "public COWebCookie (int value).", Where the value represents a given cookie value. The object of the client session maintains this key and returns it to the server as part of the subsequent HTTP request. The network server maintains a "cookie jar" that is resident to the dispatcher server and that maps these keys to the associated session. Additional authentication of each HTTPS request, which adds security to the overall process. In the preferred embodiment, typically only one cookie is sufficient for the entire session. Alternatively, a new cookie can be generated in each transaction, to add security. Moreover, the cookie jar can be shared between multiple physical servers in the event of a server failure. This mechanism prevents sessions from falling through a server failure. In addition, to allow the server software to detect client sessions that have "died", for example, that the client's session has been disconnected from the server without news because of a client-side crash or a network problem , the client application that uses the session object of the client "beats" throughout the predefined period, for example, one minute for the network server to "renew" the session key (or record). On the network server it in turn makes a request for a heartbeat transaction to the cookie jar. After receiving the request, the cookie jar service "marks" the session record with a time stamp indicating the most recent time the customer communicated with the server using the heartbeat. The cookie jar service is also alarmed, over a configurable period, to read through the cookie jar records (session keys) and check the time stamps (indicating the time at which the customer last heard) ) against the current time. If the session log delta is larger than a predetermined amount of time, the cookie jar server clears the session log, effectively causing the session key to die. Any subsequent transaction received with a dead session key, for example, not existing in the cookie jar, has prohibited access through the thermosensitive wall. Heartbeat messages are typically enabled by invoking the object method COClientSession "public synchronized empty enable heartbeat session (boolean enableHeartbeat)", where enable heartbeat is a flag to enable or disable the beating of a session. The heartbeat messages are typically periodically transmitted by first invoking a object method COClient Session "public synchronized empty set interval heartbeat (length millisecondsinterval) where the heartbeat interval is set in milliseconds, and by the object method COClientSession" protected int initiateLatid () ", where the heartbeat process begins as soon as the heartbeat interval is reached.The" beating "failures for a consecutive predefined period, for example, one hour, will result in the expiration of the session key. previously described, a typical communication with remote servers is initiated by invoking a COClient Session object.A COClient Session instance can then be used to connect to a given URL by invoking its setURLO and logon () methods.There are no limitations on how many ways simultaneous connections are allowed. the process of greeting, the given URL will point to the home page that contains the backplane applet. A second component of the communication unit provided and used in the present invention is a class of transactions. The main purpose of the class of transactions is to send a message to the back end service and return the corresponding response of that service. That answer may be in the form of a message. Any message can be sent with any transaction. Transactions do not need to be aware of any type of server content information. Instead, this information is encapsulated in messages sent to and from the back end server. Transaction classes provide a single transaction sentiment to the user of a transaction although transaction instances can drive multiple HTTP / HTTPs transactions to back end services, thus hiding the complexity of the user of a transaction. Transaction classes include two main behaviors: blocking and non-blocking. Non-blocking transactions optionally have block type behavior. The present invention provides a type of synchronous and asynchronous blocking transaction and non-blocking volume type transactions. The uppermost abstract basic class of all transaction classes is the COTransaction class. Instances derived from this class gain their blocking behavior is inherited. The non-blocking behavior is inherited from the abstract class CONobloqueoTransacción. Since this class inherits from COTransaction, all instances derived from the NOlockTransaction have both blocking and non-blocking behavior. The synchronous type of transaction type is COSincTransaction while the asynchronous and volume transaction classes are COAsincTransaction and COVolumenTransacción respectively, being a transaction type only of blocking, COSincTransacción extends to COTransacción. COSincTransaction and COVolumenTransacción give both blocking and non-blocking behavior and therefore extend CONoBlockTransaction. In order to send a message, two pieces of information need to be provided to the transaction: the first is the message that is to be sent to a back end service and a second is the target back end service of interest, usually represented by a COService object. Once a request has been executed or sent, a synchronous transaction will block until the response is received. Because there are times when the network can fail and the response is lost, the maximum time to wait for a response can be set through the setMaxTime2Wait () function. A synchronous transaction object is an instance of COSincTransaction. Non-blocking type transactions provided by the present invention extend the basic class of Transaction Lockout. To send a message in non-blocking mode, the sendRequest () method is invoked. This method returns a boolean that indicates whether the request was successfully registered to be sent to the desired back end server. After the response arrives, a previously registered callback is sent to a co-registered object. Because the sendRequest () method is non-blocking, the control is returned to the caller of the method since the request is being sent. Since this mechanism is implemented using strings, the resulting return call method is invoked on a string that is different from the string that was invoked by the sendRequest () method. An asynchronous transaction is either direct or from instances derived from COAsincTransaction. When used in lock mode (sendMessage ()), it looks like a synchronous transaction. The difference between an asynchronous blocking transaction and a synchronous transaction is that the asynchronous blocking transaction sends the initial request and then combines the response. This kind of transaction allows you to send a message to a service that can not immediately satisfy the request. Instead of this kind of service, the request would be recorded and it would inform (when combined) the client when the response is ready. Nevertheless, this continuous combination is transparent. The present invention provides a type of transaction in volume. Although this transaction action can be used to send any message, its use is typically for large data transfers. Large data sets are difficult to manage successfully in volume since they are often divided into smaller data blocks. Like the other transactions, the volume transaction object handles the complexity behind the scenes. As the asynchronous transaction object, a volume transaction object used in a blocking mode looks like a synchronous transaction. Unlike asynchronous and synchronous transactions, it informs the calling process and the intermittent data arrives. This granularity of data is known as the size of the block is determined by the caller of the transaction. Both the volume block and the non-blocking mode are able to notify the caller when each block of data arrives at the customer's side from the back end service. Instances of COVolumenTransacción are able to execute transactions in volume. As the asynchronous transaction classes (COAsincTransaction), the COVolumenTransaction blocking mode is invoked with the Java message sendMessage () and its non-blocking mode is invoked with the Java message sendRequest () in the ClassConlocationTransaction class. In addition to sending a Java callback message to a registered object when the transaction ends, the COVolumenTransacción instances send another callback message when each block of data arrives. This second callback is sent in both blocking and non-blocking mode and is used to send large data sets synchronously. The COVolumenTransacción instances are able to transfer only a portion of data from a back end service. This portion can also start at any displacement within the complete data set. This functionality will mainly be used by messages that understand how to transfer data to files.

Input / Output Services In order to centralize and unify all the input / output transactions performed by the backplane and client applications, the present invention includes a set of common input / output service objects for use by the plane later and the applications. These include a framework for printing, data export and import, registration, configuration file management and statistics. Common input / output service objects provide simplified and standardized export / import interface. The containers, which need to be exported, implement the "exportable" interface. Here, "containers" is used in the widest possible sense, encompassing everything from a complete application to the smallest data container, for example, trees, queues. This architecture defines exactly how a container will be converted from an object in active memory to an array of data in static memory. The exportable interface suggests three possibly exportable data formats: a string, byte arrays, and character arrays. The "export" class contains several convenience methods for writing strings, byte arrays, or arrays of characters to a specific file. In the code example, the container "tree" implements the "exportable" interface. // First, get a reference to a file to export it File file = new file ("/ MyDirectory / tree Export"); // Then use the export class to export ... Try. { Export. exportData (file, tree .getExportableByteArray ()); } catch (IOException ioe). { ....}. The containers, which need to import data, implement "importable" interfaces. An application import and export mechanism does not need to be symmetric. The interface mechanism defines exactly which import will be presented, that is, in which way a given body of static data will be integrated into the application being executed. The interface expects to import data in one of three ways: strings, byte arrays, or character arrays. The "import" class provides convenience methods for reading strings, byte arrays, or arrays of characters from a specific file. The following code fragment represents the use of import data. Here, "tree" is a data container, which implements the "Importable" interface. // First, get a reference to a file to import ... File file = new File ("/ MyDirectory / ImportItem"); // Then use the import class to import ... byte [] data = Import. importByteData (file); tree importByteArray (data); The entry / exit services objects also include a centralized registry utility. The purpose of registering is twofold: it allows developers to get a good handle on what functions clients are using, helping with marketing, and at the same time it also gives a way to check the series of actions, which leads to a failure of the application. The global log file has global parameters, and it also serves as a container for each of the objects in the application log file. Each active application has a reference back to the log file of the application in the global object. The following represents a code example for the use of the log file. In the following code, "I myself" is the COUser object. // In the application object .... COAppLog appLog = COAppLog.getAppLog (this); applog.addEntry (COAppLog. INFO, "Key Event", "User Pushed OK"); The objects of services of entrance / exit also include object of configuration file. A configuration file represents either the user's choice of desirable application characteristics or a default feature set. The preferred structure of the configuration file is a hierarchy, which places the application at the highest level, then the version, followed by the selection and then by the parameter pair name-value: application. version. section. first name . The general architecture of the configuration file object is just like the object of the log file.

The following represents an example of the code that would be generated by the use of the application configuration file object. // In the application object .... COAppConfiguration appConf = COAppConfiguration.getAppConfiguration (This); StringCDRomDriver = appConf .getEntry ("Drivers", "CDROM"); The input / output services objects also include statistical objects to store several counters and other numeric data, which allow the backplane and the applications to maintain a numerical record. The type of object that a statistical object could save is the number of times that a data exported per user, or the number of times an application communicates back to a specific back end server. The architecture is identical to that of the registry and configuration files. The following represents the code example for use in statistics. // In the application object .... COAppStat appStat = COAppStat .getAppStat (This); appStat. incrementValue ("Communications2Server"); Security The present invention allows the backplane and client applications to use built-in security functions in the browser without having to be tied to a specific code. The present invention provides an additional module that encloses the security functionality of the specific searchers available instantaneously. Figure 12 is a diagram illustrating a security module design that has a clean separation from the specific implementations of the browser. The security module comprises the main class COSecurity 402, and the interface COBrowserSecuritylnterface 404. The COSecurity object verifies the type of search engine after the instance. It does so by requesting the proprietary system "java.vendor". if the search engine is Netscape, for example, the class then starts with the name and the full implementation of the Netscape security interface, nmco. security securityimpls .CONetscape4_0SecurityImpl 406. Otherwise, start nmco. security, securityimpls. CODefaultSecuritylmpl 408. COSecurity 402 includes a number of methods to access local resources, for example, printing, import and export data, and properties of the local get / set system. The COBrowserSecuritylnterface 404 is reflected in the methods provided by COSecurity 402. Concrete implementations such as CONetscape4_0SecurityImpl 406 for the Netscape communicator and CODefaultSecuritylmpl 408 as a default interface are also provided. Adding a new implementation 410 is as easy as implementing the COBrowserSecuritylnterface, and adding a new hook in COSecurity. After using "java.vendor" to discover which search engines are being used, COSecurity 402 urges by name the appropriate concrete implementation. This is done by loading class first, then using Class .newinstance OR to create a new instance. The newinstance () method returns a generic object; In order to use it, it must be molded to the right kind. COSecurity 402 shapes the object that is called to COBrowserSecuritylnterface 404, instead of the concrete implementation. COSecurity 402 then calls the "object" COBrowserSecuritylnterface, which is actually a concrete "disguised" implementation. This is an example of the use of an object-oriented polymorphism. This design cleanly separates specific implementations that are specific to the search engine of the COSecurity object independent of the search engine. Each COApp object can either create its own object COSecurity using public constructors, or retrieve the COSecurity object used by the backplane via COPlanoPosterior .getSecurity (). In general, the developer of the applications to be executed will use the COSecurity object whenever the COApp needs privileged access to any local resource, that is, disk access, printer, local system properties, and start external processes. The following represents an example of the code generated when the security object is used. // Instantiating COSecurity objectCOSecurity security = new COSecurity (); // Now access to privileged resource try. { String s = security.getSystemProperty ("user.home"); System. out .println (s); } catch (COSecurityException cose). { // take care in case of security exception} Help In order for the backplane and the client application to integrate a help functionality of the underlying searcher, the present invention provides a framework of assistance work. There are two semi-independent parties to provide help. The first part is the same help that is handled through the COHelp object. The second part is the "infrastructure" of help that is provided by the COHelpListener interface. They are semi-independent because they can be safely used without the other although that does not mean even though they are supposed to complement each other. The COHelp object provides a call interface with which the underlying seeker can bring the information.

To bring the information using this object, all that is needed is to pass a URL that points to the relevant help page and a reference to the COApp. For example: if (action == HELP). { try { // creating the help URL URL helpURL = new URL ("index.html"); // calling help COHelp. showHelp (thisCOApp, helpURL); } catch (MalformedURLException e). { / * do something * /} } The COHelpListener interface provides a set of convenient functions to implement the help in COApps. This interface provides functions to define a default help URL: void setHelpURL (URL help); URL getHelpUR (); The COHelpListener interface also provides the initial foundation for handling Fl help calls. Extends the KeyListener interface which is necessary to detect the Fl keys.

Handling large data sets - Instant memory management For the management of large data sets by the backplane and client applications, the present invention provides a two-level instant memory (disk / memory) mechanism. The instant memory mechanism can be useful, for example, when given the restrictions placed on the size of a runtime code in the search engine context. The instantaneous memory module is composed of two different flash memories to address different needs: a byte-based flash memory, that is, COByteBasedDataCache, and a line-based flash memory, that is, COLineBasedDataCache. Line-based flash memory is useful for cases where data is naturally divided in a row, for example, database tables. The byte-based flash memory has a freer form for specialized uses. Both instant memories have the same underlying behavior. Instant memory has several properties, such as how much data to keep in active memory: either the number of pages based on bytes or the number of rows. A reference to a remote data source and a local file is also given. Finally, the size of each page is variable: either the number of bytes per page or the number of rows per page. After installation, the buffer immediately begins to copy information from the remote data source and write it to the local file, while simultaneously calculating page limits for the local file, keeping the vector of the page files in active memory . A page limit is a file location in bytes for the beginning of a new page. When a request is made to the flash memory for a page (or a row), the result (along with the variable number of pages [or rows] preceding and following the required page) is stored instantaneously in the active memory. Specifically, when a request is made to the flash memory if the page can be immediately returned from the active memory, it does so. Otherwise, the flash memory tries to recover the disk page (along with the pages that follow it and the preceding ones), it stores the results in the active memory of the instantaneous memory. Finally, if the requested page has not been copied from the remote data source, the method is blocked. Instant memory is useful in cases where the size of the copied data set may be smaller or exceed the capabilities of the Java runtime; the search engine runtime is especially limited. It is also useful in cases where high-speed access to large data sets is necessary. Here, the assumption is that access to the disk where the data set is stored will be much faster than a network transaction. An exemplary situation is the copying and storage in instantaneous memory of thousands of rows of a database located on the public Internet behind thermosensitive walls and representatives.

Error handling To capture errors that occur during backplane processing and client application, the present invention provides a single centralized exception, COException. All exceptions specific to COApps are derived from this base exception. As previously described, the system of the present invention uses a set of common objects to implement the various functions provided by the system of the present invention. Appendix A provides descriptions of common objects that include several classes and interfaces with their properties and methods. Although the invention has been particularly shown and described with respect to preferred embodiments thereof, it will be understood by those skilled in the art that the foregoing and other changes in form and detail may be made therein without departing from the spirit and scope of the invention. invention.

APPENDIX A The description of the classes implementing the system of the present invention will be explained below. COPlanoPosterior is a class that extends the class Applet and implements the Executable interface. The backplane applet overrides the standard applet methods: init (); start (); stopO; and run (). Via the init () method, the backplane applet obtains a user context object COUserver. The user's configuration and the rights and applications provided in the user-context are used to build the toolbar of the application and the applications of the input box. When you click on an application toolbar icon,. A particular COApp is released by the throwApp () method. The launched application must then use the backplane for interaplications communications, including retrieval of input box data. The following lists the properties and methods of the COPlanoPosterior class. public class COPlanoPosterior extends Applet implements executable public static final int ALL_WINDOWS_MINIMIZED public static final int ALL_WINDOWS_MAXIMIZED public static final int WINDOWS_TILED_HORIZONTALLY public static final int WINDOWS_CASCADED protected static COBackPlane theBackPlane this is used to allow a static method to locate the backplane, for example using COApplets protected Vector availableApps Vector of available apps (by name, string vector) protected COStat globStats Global statistics object protected COAppEntitlement globEnts Global rights object protected COLog globLog Global registration object protected COConfiguration globConfig Global configuration object public COPlanoPrevious The default constructor public static COBackPlane getBackPlane () This method is used by the COApps that are not launched by the backplane (for example, applets launched from an HTML page to find the backplane Return: the COPlanoPrevious public void init () Initializes the backplane, initializing container objects, establishing a session, obtaining user context object, as well as starting toolbar and input box applications. Overlap: init in Applet class. public void start () Starts the backplane - probably bottom strings for back end communications. Overlap: start in Applet class. public void stopO Stops the backplane and removes any background rope used by the backplane. Overlap: stop in Applet class. public void destroy () Destroys the backplane and removes all running applications, and any chords that the COPlanoPosterior may have called into existence. Try to wait for all COApps to close. Overlap: destroy in Applet class. public void run () Execution method for main backplane string. public synchronized void notifyOfExit (COApp app) Called by COApp when it is exiting. public boolean isAppRunning (String appName) Returns true if the named COApp is currently running. Parameters: appName - String denoting COApp Returns: true if the named COApp is currently running. public COApp getApp (String appName) Provides a reference to the named COApp. If the COApp is not currently running, the COPlanoPartner will attempt to launch it. Parameters: appName - String denoting the COApp Returns: the named COApp, or null if it can not be released public COApp getApp (COAppDescriptionappDesc) Alternative method to recover an application. This version can launch the applet from a URL in the appDescription (if available) otherwise it will launch via the usual method. Note that the applets launched via the URL will not return a COApp so that this function will return null. Parameters: appDesc - application description for this COApp public String () getAppName O Returns a list of names of available COApps. The name includes not only the name of the class, but also its full package name. The COPlanoPosterior keeps track of applications by their full package names, because with the name of complete package, you can dynamically load and launch the applications, as necessary.

Returns: a list of available COApps names public Locale getLocale () Returns the setLocale for the backplane. Void, if there is no set. Overlays: getLocale in Applet class public void setLocale Fix the knob for the backplane Overlay: setLocale in class Component public void setSecurity (COSecurity security) Sets the security object for the backplane public COSecurity getSecurityO obtains the security object from the backplane public long getldleTiemO Returns the time in milliseconds the user has not interacted with any COApp during the current session, that is, the minimum of the responses for getldleTimeO called in each execution. Return: -1 if there are currently active apps public long getldleTiem (COApp app) Returns the time in milliseconds that the user has not interacted with a particular COApp during the current session. public void notifyAHApps (COParm message) skip COException Send a message to all COApps. Call "processMessage O" in all applications running. Parameters: Message, a COparm that encapsulates the message to be passed. Salta: COException if all the apps fail to receive the message public void launchNativeApp (String command) jumps COException Launches the original application specified Parameters: command - String denoting the command used to launch an original application Jump: COException if the original application can not be launched public synchronized void addAvailableApp (String appName) jumps COException Add the specified COApp to the backplane by name; update AppBar Parameters: app - the name of the COApp to be added to the backplane Skip: COException if COApp can not be added public synchronized void removeAvailableApp (String appName) jumps COException Removes the specific COApp from the backplane by name, closing it, if necessary, and updates AppBar Parameters: app - the name of the COApp to be removed from the backplane Jumps: COException if COApp it can not be removed public synchronized void closeApp (COApp app) jumps COException Closes the specific COApp executed locally; delete apps app running Parameters: app -a reference to the COApp to be closed Skip: COException if the COApp can not be closed public void closeAUApps () jumps COException Closes all COApps that are executed locally; clarifies runningApps Salta: COException if all COApps can not be closed public void setWindowState (COApp app, int state) Sets the window state for the specific COApp Parameters: app - a reference to the COApp whose window state is to be set state - the integer value representing the constant window state, for example , WINDOW_MINIMIZED, WINDOW_MAXIMIZED, WINDOW_TILED_VERTICALLY. public void setAHWindowStates (int state) Sets the window status for all COApps Parameters: state - the integer value representing the constant window state Jump: COException if all window states can not be set protected COApp findApp (String appName) finds the required App by name in runningApps Returns: a reference to the COApp if it is running, or null if not protected COApp launchApp (String appName) Launches the specific COApp, if it is not already running, - adds app to the runningApps Parameters: app - a reference to the COApp to be launched Skip: COException. if the COApp can not be released public boolean registerApp (COApp theApp) Allows COApps that are not launched by the backplane (for example, applets launched from an HTML page) to register with the backplane. Returns: true if the app was successfully registered protected synchronized void killApp (COApp app) protected synchronized void addRunningApp (COApp a) add a COApp to runningApps protected synchronized void removeRunningApp (COApp a) remove a COApp from runningApps public COStat getGlobalStats () The method verifies the existence of a global statistics object. If it does not exist, then build one. Returns: the global statistics object for this backplane public COAppEntitlement getGlobalEntitlements O The method verifies the existence of a rights object. If the object does not exist, then build one. Returns: the object of global rights for this posterior plane public COLog getGlobalLog 0 The method verifies the existence of a global record. If it does not exist, then build one using the COLog constructor. Returns: the global record object for this backplane public COConfiguration getGLobalConfigurationO The method verifies the existence of a global configuration object. If it does not exist, then build one. Returns: the global configuration object for this backplane The COApp class is intended to mimic an applet-like interface but is handled by the backplane. A COApp can use the standard COAppFrame as a container for COView (s), which are notified of updates to business objects (COModels) that are being prompted by this COApp (for example, appHyperScope). The COModels within a COApp implement an undo / redo of COCommands (referred to the "Controller" portion of MVC).

It also has a list of COParm objects, which contain message headers of asynchronous transactions (other than those sent by the COApp through the Inbox, for which a separate list object has been provided). The synchronous responses of the back end services are processed as they are received. An example code for the use of COApp will be illustrated. When an application icon of the AppBar is pressed, a specific COApp will be launched by the backplane. The backplane will call the startup routines similar to the COApp applet, appHyperScope. init 0; and appHyperScope. start (); A COApp can communicate with another (including the input box) via the backplane by urging a message object of the COParm class, COParm message = new COParm (...); and invoking the processMEssage method, appHyperScope.processMessage (messagge); A COApp can execute both synchronous and asynchronous transactions. Synchronous transactions involve direct service request. New strings can be extended in which transactions are executed in parallel. These strings are synchronized if multiple strings modify common business objects. COSynchTransaction st = new COSynchTransaction (clientSession); st. execute (specificService, byteArrayOfData); Asynchronous transactions involve requests for services which will require extended processing, such as requests for reports from the input box: COASynchTransaction ast = new COASynchTransaction (clientSession); ast .execute (specificService, byteArrayOfData); Each application must define the methods, minimizeAppO, maximizeApp (), tileAppO, placeApp (), appRequestFocus 0, appToFront (), appToBackO in order for the formation of windows induced by the backplane to request to work properly. The windows count must be set for each application accurately using setWindowCount (), since the backplane depends on the precise window count using getWindowCount ().

The following list of class properties COApp and methods. public interface COApp public abstract String get ppName O Returns the name of the COApp instance Returns: the name of the instance COApp, null if it is not set, public abstract COAppDescrption getAppDescription () Returns the object of the description of the application. The information in the description of the application is used by the standard app framework. public abstract COBackPlane getBackPlane O Returns the COPlanoPosterior that belongs to the instance COApp Returns: the COPlanoPosterior that belongs to the instance COApp, null if it is not fixed. public abstract COUser getUserO Returns the user and is identical to the COUser instance of the backplane Returns: the user object context, null if it is not set public abstract void minimizeAppO Minimizes the frames associated with this application. An application must overcome this method, managing with (possibly) multiple frames and open dialogues. public abstract void maximizeApp () Maximizes the framework (s) associated with this application. An application must overcome this method, possibly handling multiple frames and open dialogues. public abstract boolean tileApp (Rectangle r []) The backplane feeds the rectangles of applications, indicating the location and size that the application can take from the actual state of the screen for mosaic purposes. The individual application must be superimposed in the case where there are multiple application frameworks, dialogs, and for the other case where the application is not going to be mastered, for example, COToolBar. This method always returns false. Parameters: r - a rectangle that indicates the amount of place on the screen that the backplane is assigning to this application. Returns: true if successful, false otherwise. Also, an application such as COToolBar that is a pseudoapp, for which tiles are not presented, must override this method to return a simple false. public abstract void placeApp (Point positions []) The backplane feeds the application positions. The application must then move each of its application windows to one of the given positions. Parameters: positions - a rule of points that go from left to right, from top to bottom. public abstract int getlnsetHeight () Retrieves the height of the tile bars in the application windows. This is easily accomplished through a call to the Container.getlnserts (). top; however, each application developer must superimpose this method appropriately. The current method returns a default value of 5. Required for proper cascade formation. public abstract void appRequestFocus 0 Request that a given application have the focus.

Each application needs to define how this works in case the application has multiple windows or open dialogs. public abstract void appToFront O Request that a given application be taken to the forum. Each application needs to define how this works, as before. public abstract void appToBackO Requests that a given application be sent back. Each application needs to define how this works, as before. public abstract void setBakcPlane (COBackPlane) This method is called by the backplane immediately after launching this COApp sets the COPlanoPosterior that belongs to the COApp instance public abstract void setUser (COUser user) This method is called by the backplane immediately. It sets the user context and is identical to the COUser instance of the backplane. public abstract void processMessage (COParm message) jumps COException Implements to allow specific processing of the application for messages sent from other COApps. Each application must define this method by itself. Parameters: message - a COParm that encapsulates the message that is going to be passed. Skip: COException if app fails to process the message public abstract int getWindowCount () Returns the number of application windows that are currently open for this application. This information is necessary for the formation of adequate mosaics and cascading behavior. The default behavior for this method is to return a zero, for example, applications such as the main toolbar that does not need to be tiled or minimized simply by this method to return zero. The COPlanoPosterior can call getWindowCount () to obtain a correct windows account for each application. public abstract long getldleTimeO Returns the time in milliseconds that the user has not interacted with this COApp during the current session. public abstract void exit () throws COException Exits the application, called for example, from the close box in the main frame, if any. Skip: COException if an application can not be closed. public abstract void addChild (Window wnd) Adds a child window to this hierarchy. public abstract void removeChild (Window wnd) Removes a child window to this hierarchy. public abstract Vector getChildrenO Retrieve all the child windows associated with this COApp public abstract void setEnabled (boolean state) Enables or disables the application and the associated child windows. public abstract void init O This method is a part of the applet-like interface and if it is called by the COPlanoPosterior to inform this Applet that it has been loaded into the system. It is always called before the first time the start method is called. A subclass of COApp overrides this method if it has initialization to perform. The implementation of this method provided by the COApp class does nothing. public abstract void start () This method is a part of the similar applet interface and is called by the COPlanoPosterior to inform this COApp that it must start its execution. It is called after the init O method. A subclass of COApp overrides this method if you have an operation that you want to perform at the start of execution. This method is typically less important for COApps than for Applets, since COApps typically run continuously. The implementation of this method provided by the COApp class does nothing. public abstract void stop O This method is a part of the similar applet interface and is called by the COPlanoPosterior to inform this COApp that it should stop its execution. It is called, for example, just before the applet is going to be destroyed. Like the start O method, this method is typically less important for COApps than for Applets, since COApps typically run continuously. The implementation of this method provided by the COApp class does nothing. public abstract void destroy () Part of the similar interface Applet called by the COPlanoPosterior to inform this Applet that it is being claimed and that it must destroy some resources that it has assigned. The detention method will always be called before destroying. A subclass of COApp overrides this method if you have any operation you want to perform before it is destroyed. For example, a COApp with strings will use the init () method to create the strings and the destroy method to eliminate them. The implementation of this method provided by the COApp class does nothing. The COAppImpl class intends to implement the coa interface in a non-applet class, but with an applet-like interface. The COAppImpl class has all the functionality of an applet except that it does not derive from the Panel and thus does not have its own browser-based deployment space. A COAppImpl can use the standard COAppFrame or the COSAndarAppFrame as a container for deployment components, for example, COView (s). The COAppImpl class provides intelligent default implementations for the COApp interface functions, as well as the "applet-like" interface functions such as getlmageO and getAppletContext (). The following lists the COAppImpl class properties and methods. public class COAppImpl extends object implements COApp, WindowListener protected COBackPlane backPlane This is the COPlanoPosterior that the COApp creates. It is provided by the COApp using the setBackPlane method. protected String sAppName Name of COApp protected COAppEntitlement appEnts object of application rights for COApp. protected COAppDescription appDescription object description and application for COApp that maintains metadata such as the default help URL. protected COAppStat appStat statistics object for COApp. protected COAppConfiguration appConf configuration object for COApp. protected COAppLog appLog registration object for COApp. protected COUser user user context object, to be established by the backplane. protected int windowCount Type of integer that keeps the number of main windows currently open for the application, excluding dialogs. protected Vector children Vector that saves all the fixed windows. public COAppImpl () A single constructor, as an applet class. public String getAppName O Returns the name of the COApp instance Returns: the name of the COApp instance, null if not fixed. public COBackPlane getBackPlane OR Return the COPlanoPosterior that belongs to the instance COApp Returns: the COPlanoPosterior that belongs to the instance COApp, null if it is not fixed. public COUser getUser () Returns the user and is identical to the COUser instance of the backplane. Returns: the user context object, null if it is not fixed. public COAppDescription getAppDescription () Returns the application description object that contains metadata about this application. Returns: the application description object, null if it is not set. public Vector getlnboxItemVector () Returns the vector of the input box item header. Returns: entry box items headers, null if not fixed. public Vector getAsynchResponseVector () Returns the AsyncResponse object vector for AsynchTransaction. Returns: the AsyncResponse vector AsyncResponse objects for AsynchTransaction, null if it is not set. public void minimizeAppO Minimizes the frames associated with this application. The application must overcome this method, managing with (possibly) multiple frames and open dialogues. public void maximizedApp () Maximize the frames associated with this application. An application must overcome this method, possibly handling multiple frames and open dialogues. public boolean tileApp (Rectangle r []) The backplane feeds the application rectangles, indicating the location and size that the application can take from the screen space for mosaic purposes. The individual application must be superimposed for the case in which there are multiple application boxes, dialogs, and for the other case in which the application is not going to be mosaicked, for example, COToolBar. This method always returns false. Parameters: r - a rectangle that indicates the amount of the place on the screen that the backplane is assigning to this application. Returns: true if successful, false otherwise. Also, an application such as COToolBar which is a pseudoapp, for which the formation of mosaics will not be presented, must override this method to return a false simple. public void placeApp (Point positions []) The backplane feeds the application positions. The application must move each of its application windows to one of the given positions. Parameters: positions - a rule of points that go from left to right, from top to bottom. public int getlnsetHeight () Retrieves the height of the tile bars in the application windows. This is easily accomplished through a call to Container.getlnsets () .top; however, each application developer must superimpose this method appropriately. The current method returns a default value of 5. It is required for proper cascade formation. public void appRequestFocus () Requests that a given application has a focus. Each application needs to define how this works in case the application has multiple windows or open dialogs. public void appToFront O Request that a given application be taken to the forum. Each application needs to define what this works, as before. public void appToBackO Requests that a given application be sent back. Each application needs to define how this works, as before. public void setAppName (String yam) Sets the name of the COApp instance. public void setBackPlane (COBackPlane plañe) This method is called by the backplane immediately after launching this COApps sets the COPlanoPosterior that belongs to the instance COApp. public COAppLog getAppLogO Returns the specific record of the application. Returns: null if the record is not defined. public COAppStat getAppStatO Returns the application-specific statistics object. Returns: null if no application-specific statistics object is defined. public COAppConfiguration getAppConfiguration () Returns the specific configuration object of the application. Returns: null if no specific configuration object of the application is defined. public void setAppStats (COAppStat appStats) This method sets the record of application-specific statistics that belong to the COApp instance public void setAppLog (COAppLog log) This method sets the specific record of the application that belongs to the COApp instance. public void setAppDescription (COAppDescription appDesc) This method sets the description object of the application. public void setAppConfiguration (COAppConfiguration config) This method sets the specific configuration of the application that belongs to the COApp instance. public void setUser (COUser user) This method is called by the backplane which immediately sets the context object of the user. It is identical to the COUser instance of the backplane. public void processMessage (COParm message) trows COException This method is implemented to allow the processing of application-specific messages sent from other COApps Each application must define this method on its own. Parameters: message - a COParm that encapsulates the message that is going to be passed. skips: COException if app fails to process the message. public void processlnboxltem (COParm ItemID) strip: COEXCEption This method is implemented to allow specific processing of the application of a particular input box article. Process the data from the input box using the input box item identification. This method is provided so that the input box processing could be separated from the more generic interaplication communication using processMessage O. Each application must define this method by itself. Parameters: itemID - a COParm that encapsulates the identification for the input box item. Skip: COException if the item can not be recovered. public long getldleTimeO Returns the time in milliseconds that the user has not interacted with this COApp during the current session. protected void resetldleTime () Restores the idle time metric - it is necessary to use this in order to return a sensitive "idle-time". Typically, this method would be called whenever a user event was received, but not necessarily restricted to this. public int getWindowCount () Returns the number of application windows that are currently open for this application. This information is necessary for the proper formation of mosaics and waterfalls. The default behavior of this method is to return to zero. public void setWindowCount (intcount) sets the windows count to the specified value. public void init OR This method is a part of the applet-like interface and is called by the COPlanoPosterior to inform this Applet that it has been loaded into the system. It is always called before the first time the start method is called. A subclass of COApp must override this method if it has to perform an initialization. The implementation of this method provided by the COApp class does nothing. public void start () This method is a part of the similar applet interface and is called by the COPlanoPosterior to inform this COApp that it must start its execution. It is called after the init O method. A subclass of COApp overrides this method and if you have an operation that you want to perform at the start of execution. This method is typically less important for COApps than for Applets, since COApps typically run continuously. The implementation of this method provided by the COApp class does nothing. public void stopO This method is part of the similar applet interface and is called by COPlanoPosterior to inform this COApp that it must stop its execution. It is called, for example, just before the applet is going to destroy. As in the start () method, this method is typically less important for COApps than for Applets, since COApps typically run continuously. The implementation of this method provided by the COApp class does nothing. public void destroy () This method is part of the similar interface Applet is called by the COPlanoPosterior to inform this Applet that it is being claimed and that it must destroy any resource that it has assigned. The detention method will always be called before destroying. A subclass of COApp must override this method if it has any operation that it wants to perform before it is destroyed, for example, a COApp with strings will use the init () method to create the strings and the destroy method to eliminate them. The implementation of this method provided by the COApp class does nothing except that it will call disposeAUC ildren to get rid of the registered windows. pubic void exitO trows COException This method is used to exit the application, called, for example, from the closed box in the main frame, if there is one. Salta: COException if the application can not be closed. public void addChild (Window wnd) Adds a child window to this hierarchy. public void removeChild (Window wnd) Removes a child window to this hierarchy. public Vector getChildrenO Retrieve all the child windows associated with this COAppImp. public void setEnabled (boolean state) Enables or disables the application and the associated child windows. public void disposeAUChildren Or Itera through the daughters registered with this coapp and call their disposition method. public void windowActivated (WindowEvent e) Empty public void windowOpened (WindowEvent e) Empty public void windowClosing (WindowEvent e) It is called when the window closes public void windowClosed (WindowEvent e) Empty public void windowDeactivated (WindowEvent e) Empty public void windowlconified (WindowEvent e) Empty public void windowDeiconified (WindowEvent e) Empty public boolean isActiveO This method is part of an applet-like interface. This implementation always returns true. Coaplication subclass override this method. public URL getCodeBaseO part of the interface similar to applet. public URL getDocumentBase () part of the applet-like interface. public String getParameter (String yam) This method is a part of the interface of the applet-like interface. public AppletContext getAppletContext () This method is a part of the interface of the applet-like interface. public Image getImage (URL url) This method is a part of the interface of the applet-like interface. public Image getImage (URL url, String yam) This method is a part of the interface of the applet-like interface. public AudioClip getAudioClip (URL url) This method is a part of the interface of the applet-like interface. public AudioCLip getAudioClip (URL url, String yam) This method is a part of the interface of the applet-like interface. public Locale getLocale 0 Retrieves Locale from the backplane. Returns: null, if not fixed. public void play (URL url) This method is a part of the interface of the applet-like interface. public void play (URL url, String yam) Part of the interface similar to applet. The COApplet class extends java. applet .Applet, and implements the COApp interface by sending the various calls to the content COAppImpl object. public class COApplet extends Applet implements COApp protected COAppImpl coAppImpl This is the ob, COAppImpl to which the COApp interface will be sent. public COApplet () Single constructor, similar class Applet public String getAppName O This method is a part of the COApp interface and is sent to the content object. Returns: the name of the null COApp instance if it is not set. public COAppDescription getAppDescription () This method is part of the COApp interface and is sent to the content object. Returns: the object of description of the application, null if it is not fixed. public COBackPlane getBackPlane O This method is part of the COApp interface and is sent to the content object. Returns: the COPlanoPosterior belonging to the instance COApp, null if it is not fixed. public COUser getUser () This method is a part of the COApp interface and is sent to the content object. Returns: the user context object, null if it is not fixed. public void minimizeAppO This method is a part of the COApp interface and is sent to the content object. public void maximizeApp O This method is a part of the COApp interface and is sent to the content object. public boolean tileApp (Rectangle r [] = This method is a part of the COApp interface and is sent to the content object. public void placeApp (Point positions []) This method is a part of the COApp interface and is sent to the content object. public int getlnsetHeight () This method is a part of the COApp interface and is sent to the content object. public void appRequestFocus () This method is a part of the COApp interface and is sent to the content object. public void appToFront () This method is a part of the COApp interface and is sent to the content object. public void appToBackO This method is a part of the COApp interface and is sent to the content object. public void setAppName (String yam) This method is a part of the COApp interface and is sent to the content object. public void setBackPlane (COBackPlane plañe) This method is a part of the COApp interface and is sent to the content object. public void setUser (COUser user) This method is a part of the COApp interface and is sent to the content object. public void processMEssage (COParm message) trows COException This method is a part of the COApp interface and is sent to the content object. Skip: COException if app fails to process the message public long getldleTimeO This method is a part of the COApp interface and is sent to the content object. public int getWindowCount O This method is a part of the COApp interface and is sent to the content object. public void setWindowCount (int Count) sets the windows count to the specific value public void addChild (Window wnd) This method is a part of the COApp interface and is sent to the content object. public void removeChild (Window wnd) This method is a part of the COApp interface and is sent to the content object. public Vector getChildrenO This method is a part of the COApp interface and is sent to the content object. public void setEnabled (boolean b) This method is a part of the COApp interface and is sent to the content object, overlays: setEnabled in class component public void ini () This method is a part of the COApp interface and is sent to the content object, superimposed: init in Applet class public void start () This method is a part of the COApp interface and is sent to the content object. Overlap: start in Applet class public void stopO This method is a part of the COApp interface and is sent to the content object. Overlap: stop in Applet class public void destroy () This method is a part of the COApp interface and is sent to the content object. Overlap: destroy in Applet class. public void exitO throws COException This method is a part of the COApp interface and is sent to the content object. Skip: COException if an application can not be closed. The COAppFrame class represents a generic base frame class, in which I create the COApps. It has a fixed design, which consists of a menu bar and possibly a toolbar. With a main viewing window. The main display area is returned as a panel, in which the COApps can display the views they want. An example of code to create a frame is "COAppFrame aFrame = new COAppFrame () "; public class COAppFrame extends COFrame implements WindowListener public static final int WINDOW_MINIMIZED public static final int WINDOW_MAXIMIZED public static final int WINDOW_TILED public static final int WINDOW_HAS_FOCUS public static final int WINDOW_IN_FRONT public static final int WINDOW_IN_BACK protected COApp owner COApp that controls this frame, protected Panel viewPanel Main panel of the frame. Protected Panel toolbar protected MenuBar menubar public COAppFrame () Constructor by default.

Public COAppFrame (COAppFrame (COApp o) Constructor by default.

Public void setMenuBar (visible boolean) Send menu bar, if desired menu bar. Public void setPreferredSize (int w, int h) Set the preferred size of the COAppFrame.

Public void setPreferredSize (Dimension d) Set the preferred size of the COAppFrame.

Public void setPreferredWidth (int w) Set the preferred size of the COAppFrame.

Public void setPreferredHeight (int h) Set the preferred size of the COAppFrame.

Public void minimizeFrame () Minimize the size of this frame (do not form icons) public void maximizeFrame O Maximize the size of this frame. Try to fix on the size of the screen.

Public void setSize (Rectangle r) Sets the size of this frame to a given rectangle.

Public void setEnabledAll (boolean state) Enables / disables this frame and all its associated siblings.

Public COApp getOwnerO Returns the COApp that owns this COAppFrame. Returns: null if the owner was not fixed.

Public void setOwner (COApp owner) Sets the COApp that owns this COAppFrame.

Public void addMenus (Menu menus []) Add all menus to the menu bar at the same time.

Public void addMenuítems (Menu menu, Menultem menuitems []) Add all items to the menu at once.

Public void addMenu (Menu menu) Add a single menu to the menu bar.

Public void addMenuítem (Menu menu, Menultem menúitem) Add a menu item to a menu.

Public void addMenuToMenu (Menu addto, Menu menu) Add a menu to a menu. Parameters: addto - the menu as it is another menu will be added. Menu - the menu that is to be added.

Public void addHelpMenu (Help menu) Add a help menu to the menu bar.

Public void setToolbarVisible (visible boolean) Set a toolbar that is visible or invisible.

Public void setToolbarBackground (Color color) Set the background color of the toolbar.

Public void addTools (Component tools []) Add a collection of tools to the toolbar in the order tools [0] to tools [n-l] for any arrangement of n image buttons. Parameters: tools - an array of image buttons.

Public void addTool (Component tool) Add a tool to the toolbar. Parameters: tool - an image button.

Public Panel getViewArea 0 Returns the main display area, in which developers must add any view they wish.

Public void attachToviewArea (Component theComponent) causes the provided component to collect the entire view area.

Protected void setupPanels 0 sets the standard framework project.

Protected COApp getCOApp O Return the COApp that owns this AppFrame.

Public void windowActivated (WindowEvent e) Overlap: windowActivated in COFrame class.

Public void windowOpened (WindowEvent e) Overlap: windowOpened in class COFrame.

Public void windowClosing (WindowEvent e) Called when the window is closing. Overlap: windowClosing in COFrame class.

Public void windowClosed (WindowEvent e) Overlap: windowClosed in COFrame class.

Public void windowDeactivated (WindowEvent e) Overlap: windowDeactivated in COFrame class.

Public void windowlconified (WindowEvent e) Overlap: windowlconified in COFrame class.

Public void windowDeiconified (WindowEvent e) Overlap: windowDeiconified in COFrame class.

Protected void finalizeO throws Throwable It has the frame, if it has not been discarded for some reason. Skip: Skiptable If there is a problem during the completion. Overlap: end in object class. The COParm class represents a wrapper class for the data that is fed into each COApp after the start and the communications of interaplications, in general. The COParm maintains parameters of parameters noise table, where each parameter is a name-value pair. The data may be retrieved by name, using methods contained herein; in addition, they can also be retrieved through an enumeration, using methods of the noise table class.

Public class COParm extends Hashtable public COParm () Constructor by default.

Public COParm (COPair pairsf]) throws COException Special constructor. Parameters: pars - An array of even objects. Skip: COException if the name one of the name-value pairs is not a string.

Public void addParm (COPair pair) throws COException Add an object partially Skip: COException if the name of a name name-value is not a string.

Public void addParm (String yña, Object data) Constructs a pair object of the name and data, adds it.

Public Object getData (String yam) Returns the data associated with the name. The following paragraph describes the main COCÍientSession methods. COClientSessionO: is the default constructor for this boolean logon class (String user name, password string) jump COCÍientLogonException: executes a salutation in the system with object of required username and password transactions that then use the session instance to connect in a given service boolean logon (String user name, String password, URL resource) jump COCÍIENTLogonException: run a salutation on the system with a user name, password and URL required void setURL (String stringRep) jump MalformedURLException: sets the instance of the Internal URL COConnection connect () throws IOException: returns a connection in a save URL. This method is used in order to establish a connection after successful salutation has been presented. COConnection connect (COTransaction trans) throws IOException : Returns a connection in a saved URL. This method is used by the transactions to establish a connection to a back end service after a successful greeting has been presented. When a transaction instance (COTransaction) sends this Java message, this method starts to monitor the transaction in addition to connecting the transaction. Void disconnect (COTransaction trans) throws IOException: Disconnects a transaction from a back end service. When this Java message is sent, the session stops monitoring the transaction instance. Synchronized void uselnputTimers (boolean flag): allows the instance of the session to use input timers that count the time of the dead time for all read actions in the input streams associated with this session instance. All input streams (instances derived from InputStream) retrieved from a COConnection instance that has been accessed through one of the previous COClientSession methods. connect () are associated with the corresponding session instance. Therefore, these input currents are those that are affected by the uselnputTimers () method.

Synchronized void setMaxDeadTime (long waitSeconds): sets the maximum dead time allowed for all input streams associated with this session. See uselnputTimers () above. Synchronized long getMaxDeadTime (): returns the maximum dead time. See setMaxDeadTime 0 previous. Void setSessionlnfo (COTransactMessage toSet): sets session information in a protocol header type object. This method is also used for transactions and does not mean that it is going to be used outside of this context. Boolean logoff (): logs the session to shut down the system. After this method has been invoked the instance of the session can no longer be used for transactions until another salutation is attempted. Boolean isLoggedOn (): Test the instance to see if it is currently connected The COUser class is used to create a user object that encapsulates the user's name, password and numeric identification of the user. The following lists the methods of the COUser class.

Pubclass COUser extends Object pubCOUser (String username, String password) Creates a user COU with a given user name and password Parameters: user name - user name password - password pubCOUser (String username, String passwordID) Creates a user COU with username and password given Parameters: username - username password - enterpriseID password - company identification pubCOUser (String username, String password, String enterpriseID, String timeZone) Creates a user COU with a given username and password Parameters: username - username password - enterpriseID password - company identification timeZone - the time zone pubCOUser (int uid, String username, String password) Creates a user COU with a given user name and a password Parameters: uid - the numeric identification of the user username - the name of the user password - the password pubint getIDO Returns the user identification number. Returns: the user's identification number pubString getUserName O Returns the username Return: the username pubString getPasswordO Returns the password of the user. Returns: the user's password pubString getEnterpriseID () Returns the company identification. Return: company identification pubString getTimeZone () Returns the time zone. Come back: the time zone pubVector getEntitlements () Returns apption rights Return: a collection of apption rights pubVector getUserProfile () Returns the user profile. Return: the user profile pubvoid setPassword (String password) Sets the user password Parameters: password - the user password pubvoid setEnterpriseID (String enterpriseID) Sets the company identification Parameters: companyID - company identification pubvoid setTimeZone (String timeZone) Sets the time zone Parameters: Time zone - the time zone pubvoid setEntitlements (Vector entitlements) Sets the rights for this user Parameters: rights - rights pubvoid setUserProfile (Vector userProfile) Sets the user profile Parameters User profile - the user profile

Claims (33)

1. A system for integrating and managing one or more application programs to clients that allow a user to interact with one or more network-enabled services subscribed by a user, comprising: a web browser, resident on a client platform, the search engine network capable of receiving one or more pages from the network from a remote server; a backplane object loaded with, and launched by the network page, the backplane object capable of launching the client application programs after user initiation, the backplane object further enables inter-application communications between the client application programs and also with the backplane object, whereby the backplane object and the client application programs interoperate with each other to provide a client interface integrated with a plurality of network management services. communications subscribed by the user.

2. The system as claimed in claim 1, wherein this system further comprises: a greeting object copied with and launched by the network page, the greeting object capable of accepting user greeting transactions; and a session object created by the salutation object, the session object communicating with the remote server to provide user authentication, whereby after successful validation of the remote server user, the salutation object sends a command to the remote server. remote server to copy the application programs to the client and the page of the network that has the backplane object.

3. The system as claimed in the claim 2, wherein the system also comprises a user object to represent a current user, the user object also communicates with the remote server to determine the rights of the client to the services enabled by the network, whereby the backplane uses the rights to present to the user only the services enabled by the network in which the user has privilege.

4. The system as claimed in the claim 3, wherein the client application program is executed directly by the backplane when the user selects the service associated with the client application program, whereby the client application program runs in a frame independent of the window of the network browser.

5. The system as claimed in claim 3, wherein the client application program is a program launched by a new browser window created by the backplane. The system as claimed in claim 3, wherein the backplane object maintains session information received from the remote server in static memory for the duration of a session, and enables the client's application programs to access the static memory, by means of which a necessity of each one of the programs of application of the client is eliminated to communicate with remote servants for the information obtained once the information was obtained. The system as claimed in claim 3, wherein the client application program includes an application toolbar to present the services enabled by the network to the user, the application toolbar has the ability to launch, after the user's initiation, the client application programs associated with the services enabled by the network, the application toolbar also has a capacity to remain static in the foreground of the screen, whereby the user can select a second service enabled by the network after having executed the first service enabled by the network without having to regain the page of the network that has the backplane object. The system as claimed in claim 3, wherein the system further comprises a graphical user interface unit for enabling the client application programs and the backplane to provide common desktop computer window management features to see and feel. 9. The system as claimed in the claim 3, wherein the system further comprises a communication transaction unit for enabling the backplane and the client application programs to communicate with the server, whereby the communication transaction unit can track the messages communicated. The system as claimed in claim 3, wherein the system further comprises a security unit to provide a browser-independent interface for accessing browser-specific security implementations. The system as claimed in claim 3, wherein the system further comprises an error handling unit for handling exceptions that are presented in the customer's application programs and in the subsequent plan. The system as claimed in claim 3, wherein the system further comprises input / output services unit to provide input / output services including printing, registering, exporting and importing data, managing default configuration files and statistics, whereby the backplane and the application programs of the client use the input / output services unit for their input / output needs, by means of which all the input / output functions of the service unit are contained of entry / exit. The system as claimed in claim 3, wherein the system further comprises an instant memory unit for establishing a two-level disk instantaneous memory storage mechanism whereby after installation of an instant memory object , the instant memory object retrieves a requested page from the local disk along with pages that follow and precede it in the active memory of the instant memory object if the requested page is available on the local disk and, if the requested page is not available On the local disk, the instant memory object copies the information included in the following and preceding pages from a remote data source and writes the information to the local disk, storing the information in the active memory of the instant memory object. The system as claimed in claim 3, wherein the system further comprises a network support unit to enable the backplane and client applications to command the network browser to carry help information by passing a URL that point to a help page and a reference to the client's application or to the backplane. The system as claimed in claim 3, wherein the system further comprises a heartbeat message unit to enable client applications to periodically notify the server of status, whereby when the server does not receive notification for a period previously defined, the client's application is denoted as having come out. 1

6. The system as claimed in claim 3, wherein the pages of the network also include hyperlinks to other pages and services of the network. The system as claimed in claim 3, wherein the user object stores in its memory the rights of the user after retrieving them from the remote server. 18. A method for integrating and managing one or more client application programs to enable a user to interact with one or more services enabled by the network to which the user has subscribed, comprising the method: receiving a page from the network that has a backplane object from a remote server; copy a client application program associated with the services enabled by the network; launch the backplane object; present to the user the client application programs associated with the services enabled by the network to which the user has subscribed and which the user can select; and creating the client application program at the request of the user, whereby the backplane object and the client application programs interoperate with each other and communicate with the remote server to provide a client interface integrated with a plurality of services of administration of communication networks subscribed by the user. 19. The method according to the claim 18, wherein the method further comprises: accepting the user greeting transaction from the user; and authenticating the user's greeting transaction by communicating with the remote server, before the step of receiving a page from the network that has a backplane object from a remote server. The method according to claim 19, wherein the presentation step further comprises: determining the rights for the services to which the user has privilege; and enable only those services to which the user is entitled. 21. The method according to the claim 20, wherein the step of creating comprises launching the client application program directly from the backplane object. 22. The method according to claim 20, wherein the step of creating comprises: copying a new search window; and launch the client application program from the new search window. 23. The method according to claim 20, wherein the method further comprises: maintaining information data in a static memory during an entire session. The method according to claim 20, wherein the method further comprises: launching an application toolbar to present the services enabled by the network to the user; unfold the application toolbar in the foreground of the screen. 25. The method according to claim 20, wherein the method further comprises sending a heartbeat message to the server periodically to maintain live communications with the server. 26. The method according to claim 20, wherein the method further comprises generating one or more session keys to identify a session when communicating with the services enabled by the network. 2

7. The method according to claim 20, wherein the method further comprises passing a URL that points to a help page and a reference to the client's application or to the subsequent plane, by means of which the search engine brings help information. 2

8. The method according to claim 20, wherein the method further comprises hyperlinks to other pages and services of the network. 2

9. A system for creating integrated client applications to allow a user to interact with one or more network enabled services to which the user has subscribed, the system comprising: a backplane class of applications for managing a plurality of programs of client application; an application interface class for implementing the client application program associated with the network-enabled service, the application interface class further includes a message device for enabling communications among the plurality of client application programs; class extensions of the graphical user interface to enable the client application programs to provide common view and feel desktop window management features; and a client communications information to provide a single interface from which the client application programs can send messages and requests to one or more back end services, whereby a shared library of common objects is provided as a framework in which a family of Internet applications can be created and managed from an integrated system. 30. An application system enabled by integrated network, a session management system for maintaining a user session on the Internet, comprising the session management system: a network browser located on a client platform to copy one or more network pages and application codes, and to start the application system enabled by the integrated network; a server device for hosting and maintaining the one or more pages of the network and the application codes for copying the client platform, and for receiving communication transactions from the client platform; a greeting device for validating a user in the application system enabled by the integrated network, and creating the user session associated with the user after an appropriate validation; the server device further includes a deposit device for maintaining session information associated with the user's session; and the session information includes a time stamp of the session representing a time of receipt of a prior communication transaction associated with the user's session; wherein the deposit device, after receiving a current communication transaction from the client platform, updates the session time stamp with a current time. The system as claimed in claim 30, wherein the deposit device further includes a device for monitoring the time stamp of the session, and wherein a time difference between a current monitored time and the time stamp of the session exceeds a previously defined value, the device to monitor clarifies the information of the session from the device of the deposit, by means of which the user is required to be validated by the greeting device before having access to the application system enabled by the integrated network. 32. In a network-enabled, integrated application system, a method for maintaining a user session on the Internet, comprising the method: providing a network interface to a client platform for the application system enabled by integrated network; validate a user on the client platform to have access to the application system enabled by integrated network; create the user session associated with the user after adequate user authentication; maintain session information associated with the user's session; include a time stamp in the session information to represent a time of receiving the prior communication transaction associated with the user's session; receive a current communication transaction from the client's platform; update the time stamp with a receipt time of the current communication transaction. 33. The method according to claim 32, wherein the method further comprises: monitoring the time stamp; compare the current monitoring time with the time stamp, - clarify the information of the session that has the time stamp, if a time difference between the current monitored time and the time stamp exceeds a previously defined value.