Hyper media object management

[0002] The following related U.S. applications are hereby incorporated by reference: U.S. application Ser. No. 08/680,270 (pending) entitled “Method and Apparatus for Describing an Interface Definition Language-Defined Interface, Operation, and Data Type” by A. Schofield, filed Jul. 11, 1996; U.S. application Ser. No. 08/678,681 (pending) entitled “Method and Apparatus Using Parameterized Vectors For Converting Interface Definition Language-Defined Data Structures into a Transport and Platform Independent Format” by A. Schofield, filed Jul. 11, 1996; U.S. application Ser. No. 08/680,203 (now U.S. Pat. No. 5,860,072) entitled “Data Structure Representing An Interface Definition Language Source File” by A. Schofield, filed Jul. 11, 1996; U.S. application Ser. No. 08/680,203 (now U.S. Pat. No. 5,860,072) entitled “Method and Apparatus for Transporting Interface Definition Language-Defined Data Structures Between Heterogeneous Systems” by A. Schofield filed Jul. 11, 1996; U.S. application Ser. No. 08/678,295 (pending) entitled “Method and Apparatus for Performing Distributed Object Calls” by A. Schofield filed Jul. 11, 1996; U.S. application Ser. No. 08/680,202 (pending) entitled “Method and Apparatus for Asynchronously Calling and Implementing Objects” by A. Schofield, filed Jul. 11, 1996; U.S. application Ser. No. 08/680,266 (pending) entitled “Method and Apparatus for Performing Distributed Object Calls using Proxies and Memory Allocation” by A. Schofield filed Jul. 11, 1996.

[0003] Appendix A, which is herein incorporated by reference, shows examples of formats used to communicate between a server and an object manager.

[0004] Appendix B, which is herein incorporated by reference, shows examples of an ORM Server Support library API (Application Program Interface) supported by the object manager to access objects in a preferred embodiment of the present invention.

[0005] This application relates to object oriented programming and, in particular, to management of distributed objects via the World Wide Web.

[0006] The past several years have seen an explosive growth of the use of distributed objects. Now, a single system may be composed of objects obtained from different vendors and having different interfaces. Such objects are called “heterogeneous objects.” Thus, a system can be formed of a large and rapidly changing number of heterogeneous objects. Such a system requires a flexible and adaptive approach for system and application management. Conventionally, a heterogeneous system is managed by way of object-specific presentation facilities, i.e., by way of a user front-end that was written for each type of heterogeneous object. Such an approach is, however, too expensive in both development time and maintenance and administrative costs. In addition, conventional object management is often achieved through a single management center. Use of a single center is not efficient when a large number of objects need to be managed.

[0007] The present invention overcomes the problems and disadvantages of the prior art by using a hypermedia approach to object management. In this approach, each object is akin to a hypermedia document. The described embodiment of the present invention uses the World Wide Web hypermedia system. In a preferred embodiment of the present invention, a user initializes browser software that allows the user to browse and change various attributes of objects in the system. The browser communicates with a server that includes an http adapter and a gateway. The gateway can access objects in the system and generate HTML code in accordance with the objects.

[0008] A described embodiment of the present invention uses hierarchical tree-oriented objects. In a first embodiment, these objects are “self-describing”(also called “introspective”). The server queries the objects in response to the queries from the browser and each queried object responds with information about itself. In another preferred embodiment, the server initiates queries of the objects and retains this information for use in responding to later queries from the browser.

[0009] In accordance with the purpose of the invention, as embodied and broadly described herein the invention is a system for managing objects, including a first server, comprising: a first receiver portion configured to receive a request in a hypermedia format; a first translator portion configured to convert the hypermedia request to an object request; a sender portion configured to send the object request to an object manager; a second receiver portion configured to receive a response from the object manager; and a second translator portion configured to convert the object manager response to the hypermedia format.

[0010] In further accordance with the purpose of this invention, as embodied and broadly described herein the invention is a method for browsing objects, where a browser communicates with a server, comprising the steps, performed by the browser, of: sending an initial URL to the server; receiving first data from the server, where the first data specifies an object corresponding to the URL; sending user-entered data associated with the object to the server; and receiving second data from the server, where the second data specifies a second object corresponding to the user-entered data.

[0011] Advantages of the invention will be set forth in part in the description which follows and in part will be obvious from the description or may be learned by practice of the invention. The advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims and equivalents.

[0012] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments of the invention and, together with the description, serve to explain the principles of the invention.

[0013] FIG. 1 is a block diagram of a computer system in accordance with a preferred embodiment of the present invention.

[0014] FIG. 2 is another block diagram of a computer system in accordance with a preferred embodiment of the present invention.

[0015] FIG. 3 is a diagram of data sent between a browser, server, and object manager in accordance with the embodiment of FIG. 1.

[0016] FIG. 4 is a diagram of a format in which objects are organized.

[0017] FIG. 5 shows another example of a page displayed by the browser.

[0018] FIGS. 6(a) and 6(b) show an example of HTML that causes the browser to display a portion of the page of FIG. 5.

[0019] FIGS. 7(a) through 7(c) show further examples of HTML that result in the portions of page of FIG. 5.

[0020] FIGS. 8(a) and 8(b) show several examples of ORM (Object Resource Management) requests made by the server to the object manager and the resulting responses from the object manager.

[0021] FIG. 9 shows another page displayed by the browser.

[0022] FIG. 10 shows layers of functions available to the object manager.

[0023] Reference will now be made in detail to a preferred embodiment of the invention, an example of which is illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

[0024] FIG. 1 is a block diagram of a computer system 100 in accordance with a preferred embodiment of the present invention. Computer system 100 includes a first computer 110 and a second computer 120. First computer 110 and second computer 120 are connected together via line 106, which can be, for example, a LAN, a WAN, or an internet connection. Line 106 can also represent a wireless connection, such as a cellular network connection.

[0025] First computer 110 includes a CPU 102; a memory 104; input/output lines 105; an input device 160, such as a keyboard or mouse; and a display device 150, such as a display terminal. First computer 110 also includes an input device 161 that reads computer instructions stored on computer readable medium 162. These instructions are the instructions of e.g., browser software 130. Memory 104 of first computer 110 includes browser software 130, Hypertext Markup Language (HTML) 135, and objects 132. A person of ordinary skill in the art will understand that memory 104 also contains additional information, such as application programs, operating systems, data, etc., which are not shown in the figure for the sake of clarity.

[0026] Second computer 120 includes a CPU 102′ and a memory 104′. Memory 104′ of second computer 120 includes server software 140, an object manager (ORM) 142, and objects 144. HTML 135 in the memory of first computer 110 was downloaded over line 106 from server 140 of second computer 120. A person of ordinary skill in the art will understand that memory 104′ also contains additional information, such as application programs, operating systems, data, etc., which are not shown in the figure for the sake of clarity. Server 140, object manager 142, and objects 144 can also be located in memory 104 of first computer 110.

[0027] It will be understood by a person of ordinary skill in the art that computer system 100 can also include numerous elements not shown in the Figure for the sake of clarity, such as disk drives, keyboards, display devices, network connections, additional memory, additional CPUs, LANs, input/output lines, etc.

[0028] The following paragraphs provide a general discussion of the World Wide Web (“the Web”). The Web is built around a network of “server” computers, such as second computer 120, which exchange requests and data with each other using the hypertext transfer protocol (“http”). A human designer designs the layout of a Web page, which is then specified using HTML (“Hypertext Markup Language”). Several versions of HTML are currently in existence. Examples include HTML versions 2.0 and 3.0, as specified by the WWW Consortium of MIT. The HTML used in the described embodiment of the invention includes frames, forms, and tables, as are known to persons of ordinary skill in the art.

[0029] A user views a Web page using one of a number of commercially available “browser” programs. The browser submits an appropriate http request to establish a communications link with a Web server of the network. A typical http request references a Web page by its unique Uniform Resource Locator (“URL”). A URL identifies the Web server hosting that Web page, so that an hftp request for access to the Web page can be routed to the appropriate Web server for handling. Web pages can also be linked graphically to each other.

[0030] FIG. 2 is an additional block diagram of a computer system in accordance with a preferred embodiment of the present invention. Browser 130 communicates with server 140. Server 140 includes an http adapter 202 and a management gateway 204. Http Adapter 202 handles communication via the known http protocol. Management gateway 204 communicates with object manager 142. Server 140 communicates with one or more objects 132, 144 using a request/response (RR) protocol, such as the ORM (Object Resource Management) protocol, which is discussed below. Note that objects 132 and 144 can be located on the same or different physical computers or machines. Server 140 also communicates with external interface 206, which communicates using the known SNMP and CMIP protocols. Server 140 also communicates with external gateway 208, which communicates using the known SNMP and CMIP protocols. The system can contain more than one servers 140 and more objects than are shown in FIG. 4.

[0031] FIG. 3 is a diagram of data sent between a browser, server, and object manager in accordance with the embodiment of FIG. 1. In the example of FIG. 3, the user has already begun execution of browser software 130. In step 302, the user enters the URL of server 140 by way of browser 130. The browser sends a request to the server and, in step 304, the server responds with the HTML to generate a home page. The home page allows the user to enter a URL (or to chose a URL from those known provided within the HTML of the home page). The user can then chose to set/browse objects in the system, as described below. The user can also request information and statistics about once or more objects in the system.

[0032] In step 306, the user enters a URL of an object by way of browser 130. Server 140 converts the URL to a request to an object manager. For example, in the described embodiment, server 140 converts the URL to an ORM request, as described below. The ORM request is sent to the object manager, which returns object data in steps 308 and 310. Server 140 converts the object data into HTML, which is sent to browser 130 in step 312. The HTML may be based on a predetermined page template known to the server. Alternately, the format of a page may be determined “on the fly” based on the information obtained from the object manager. Server 140 converts all pathnames, such as object-links in the object data (see FIG. 4) to URLs in HTML and vice versa. Thus, if a user clicks on an area in a page displayed by the browser that corresponds to an object-link, browser 130 has the URL corresponding to that object-link. This new URL is sent to the server, which obtains the page information and sends HTML to display information for the object connected to the object-link.

[0033] Steps 314 through 320 represent a “set” mode, in which the user enters new values for an object by way of browser 130. In step 314, the user indicates that he wishes to enter “set” mode. This indication is usually accomplished by clicking on a button in the current page (thus, the HTML generated by server 140 should include HTML for this button). In step 316, server 140 sends a “form” for set mode. In step 318, the user enters new values into the form and clicks on “submit” (or “apply”, (see FIG. 5), as is known to persons of ordinary skill in the art. Server 140 converts the submitted form to, for example, an ORM request, as described below. The ORM request is sent to the object manager, which returns object data in steps 317 and 319. Server 140 converts the object data of step 319 into HTML, which is sent to browser 130 in step 320.

[0034] Steps 322 through 332 represent a “browse” mode, in which the user views values associated with an object by way of browser 130. In step 322, the user indicates that he wishes to enter “browse” mode. This indication is usually accomplished by clicking on a button in the current page (thus, the HTML generated by server 140 should include HTML for this button). In step 324, server 140 sends a “form” for browse mode. In step 326, the user enters new values into the form and clicks on “submit” (or “apply”, see FIG. 5), as is known to persons of ordinary skill in the art. Server 140 converts the submitted form to, for example, an ORM request, as described below. The ORM request is sent to the object manager, which returns data corresponding to the object in steps 328 and 330. Server 140 converts the response of step 330 into HTML, which is sent to browser 130 in step 332.

[0035] A. Object Organization

[0036] FIG. 4 is a diagram of a format in which objects are organized in a preferred embodiment. This organization is transparent to server 140 and browser 130. It will be understood that the present invention can be used with a number of object organizations and with a number of object management protocols. The embodiment described herein uses the ORM protocol, as described below.

[0037] The model of FIG. 4 assumes the following:

[0038] 1) Management operations can be mapped to two basic operations: a) Get an attribute (or a set of attributes) of an object and b) set an attribute (or set of attributes) of an object.

[0039] 2) All entities to be managed can be organized as a directed tree with nodes and leaves where the nodes are either (callable) objects or components (sub-parts of objects) with attributes as the leaves (with combined name/pair values), and

[0040] 3) All knowledge about management operations and attributes is built into and controlled by the managed object.

[0041] FIG. 4 shows the following types of entities:

[0042] 1) Objects

[0043] Objects encapsulate and control management aspects and respective management operations. In the described embodiment, an object is identified by a “pathname,” which is the destination for object calls. Each manageable object has its own virtual tree of components, attributes, and object-links.

[0044] 2) Components

[0045] Components are the primary structuring mechanism within an object. Component sub-trees may be of arbitrary depth and component nodes may contain any number of object-links, other sub-components, or attributes.

[0046] 3) Attributes

[0047] Attributes describe specific aspects of a component within an object (for example, “status=running” describes the state of a resource). Attribute nodes have additional properties beyond name and value, such s access mode and data type. Attribute nodes are leaves and do not have children.

[0048] 4) Object-links

[0049] Object-links contain an object reference to a related object. As every object is responsible for its own virtual tree of resources, one object can provide a reference (hyperlink) to another object. Thus, in the described embodiment, a first object can have links to a second object, so that objects can be “walked” by way of browser 130.

[0050] 5) Relations

[0051] Objects and components are the primary means for structuring and navigation in the described embodiment. Attributes have values that characterize the state of the resource. All operations (browsing and attribute retrieval/setting) are performed with respect to a single level of the tree (e.g., relative to a specific parent).

[0052] Server 140 preferably issues the following requests to object manager 142:

[0053] 1) Get a list of linked objects,

[0054] 2) Get a list of components and/or sub-components,

[0055] 3) Get a list of attributes,

[0056] 4) Set a list of attributes (Along with name/value pairs for each attribute), and

[0057] 5) Get an extended list of attributes, which returns meta-information about the attribute, such as data type, allowed access mode (ro, rw) or valid ranges of new attribute values. Within the ORM model, all management operations are mapped to these five operations. Thus, every managed object preferably supports these five operations.

[0058] It should be understood that the attributes and object types shown in the examples herein are included only for the purposes of example. The present invention can be practiced using any appropriate object organization and type.

[0059] B. Server Interface

[0060] In the described embodiment, all messages passing in and out of server 140 are ASCII messages.

[0061] A example URL for object 402 of FIG. 4 would look like:

[0062] Http://ham/get/objectRoot/Component1/Component2/

[0063] A example URL for attribute 404 of FIG. 4 would look like:

[0064] Http://ham/get/objectRoot/Component1/Component2/Attr1/

[0065] In both of these URLS, “ham” stands for “HyperMedia Adapter to Management” and represents the address of server 140; “get” (this could also be “set”) represents an operation to be performed on an object or attribute; and the remainder of the URL represents the tree of the object or attribute known to the object manager. Other URLs may also include additional information use, for example, by the object manager.

[0066] FIG. 5 shows a page displayed by browser 130 in “set” mode. FIG. 5 shows the values of attributes for a “Configuration” object component. These attributes include:

[0067] 1) Status 520,

[0068] 2) Maximum Concurrency 523,

[0069] 3) Trace Level 524,

[0070] 4) OSL Traces Enabled 526,

[0071] 5) Script directory/Vol. 528,

[0072] 6) Script File 530,

[0073] 7) Cache Tcl Scripts 532,

[0074] 8) Tcl Trace Enabled 534, and

[0075] 9) Maximum Size of Synthesized Page 536.

[0076] FIG. 5 also shows an entry 522 for changing the status attribute. It should be understood that the attributes of FIG. 5 are presented for the sake of example only and are not to be taken in a limiting sense. FIG. 5 also shows a reset button 540 and an apply button 550. When the user clicks reset button, original attribute values are returned. When apply button 550 is clicked, browser 130 posts a form, as is known to persons of ordinary skill in the art.

[0077] FIGS. 6(a) and 6(b) show an example of HTML generated by server 140. When browser 130 interprets the HTML of FIG. 6, it generates the portion containing attribute values 520-536 and buttons 540, 550 of FIG. 5. FIGS. 7(a) through 7(c) show an example of HTML generated by server 140. When browser 130 interprets the HTML 702, 704, and 706 of FIGS. 7(a) through 7(c), it generates portions 502, 506, and 504, respectively, of FIG. 5.

[0078] FIG. 9 shows another page displayed by browser 130 in accordance with HTML generated by server 140. The page of FIG. 9 is used to browse objects, but cannot change the attributes of objects.

[0079] The previous paragraphs discuss the browser GUI presented to the user and how server 140 translates between HTML and a protocol understood by the object manager. The following paragraphs describe the protocol used to communicate with object manager 142 about objects and to change objects in accordance with the HTML received by the server.

[0080] FIGS. 8(a) and 8(b) show several examples of ORM requests made by the server 140 to object manager 142 and the resulting responses from object manager 142. Appendix A shows formats of such requests and responses. Request 802 is an example of an OrmGet request sent from server 140 to object manager 142. The format of an OrmGet request is:

[0081] OrmGet: pathname

[0082] entity types

[0083] where pathname is a name of an object or an attribute. Possible entity types are: “Object” (all known objects at this level), “Component” (a list of all components below the level of the path specified in the OrmGet), “Attribute” (a list of attributes for the current node; for every attribute, its name and “stringified value is returned; if the pathname already navigates to an attribute, the object manager returns the empty string), “Info” (returns “meta-attributes” such as mode, range and unit), and <none> (i.e., an empty string).

[0084] In request 802 of FIG. 8, the server “knows” about an object “HyperMedia Adapter NSK”, possibly from receiving a URL from browser 130. Line 820 represents a version of the server (e.g., version 1.0). Line 822 is an “OrmGet” request for object “HyperMedia Adapter NSK”. Server 140 requests information from object manager 142 about entity types (Info), Component, and Object (lines 824).

[0085] Response 804 is generated by object manager 142 and sent to server 140. The object has four components, no info, and no objects at the same level. As seen in step 312 of FIG. 3, server 140 generates HTML 604 of FIG. 7(c) in accordance with response 804 and sends the generated HTML to browser 130.

[0086] Assuming that the user wants to browse information about the Configuration component of object “HyperMedia Adapter NSK”, browser 130 sends a request to server 140 to this effect. Server 140 then sends request 806 to the object manager, which responds with response 808. Request 806 is similar to request 802, but the pathname in line 830 is “HyperMedia Adapter NSK/Configuration”.

[0087] Response 808 includes attributes for the “Info” entity. Thus, the response includes an attribute value, mode, field, and range for each of ten attributes of the component “Configuration”. As seen in step 332 of FIG. 3, server 140 generates the HTML of FIGS. 6(a) and 6(b) in accordance with response 808 and sends the generated HTML to browser 130 (see FIG. 5).

[0088] Assuming that the user wants to change one or more attributes of the Configuration component of object “HyperMedia Adapter NSK”, browser 130 sends a request to server 140 to this effect (assuming that the browser is in “set” mode). Server 140 then sends request 810 to the object manager, which responds by sending a status value (not shown).

[0089] A format of the OrmSet request is:

[0090] OrmSet: pathname

[0091] Attribute: name

[0092] Value: val

[0093] where “name” and “val” respectively, represent an attribute name and an attribute value. This command is shown in line 840. The command can include more than one Attribute/Value pairs.

[0094] In the example, request 810 specifies new values for eight attributes of component “Configuration.” Assuming that no error occurs when the object manager changes the attribute values, server 140 generates HTML reflecting the new attribute values in accordance with the response and sends the generated HTML to browser 130 (not shown).

[0095] A preferred embodiment of the present invention has a server that interfaces with “self describing” (or “introspective”) objects. The server sends requests to and receives responses from an ORM (Object Resource Manager). The system may include more than one ORM and more than one server. Each server may “know” about zero or more ORMs. Thus, the system is not centralized and does not necessarily depend on a central point to interface with the objects.

[0096] C. The Object Manager

[0097] 1. Self Describing Objects

[0098] FIG. 4 shows an example of object organization in a preferred embodiment of the present invention. Appendix B, which is herein incorporated by reference, shows examples of an ORM Server Support Library API (Application Program Interface) supported by the object manager to access objects in a preferred embodiment of the present invention. The routines in the API of Appendix B are used by object manager (e.g., ORM 142 of FIG. 1) to receive requests from server 140 and to prepare responses to the requests. It will be understood be persons of ordinary skill in the art that any object manager can be used in conjunction with the present invention, as long as the object manager is capable of communicating with server 140 and of fulfilling GetOrm and SetOrm requests from server 140.

[0099] FIG. 10 shows layers of functions available to the object manager. A Protocol layer 1002 handles the ORM protocol, e.g., decodes the request from server 140, initiates the corresponding functions, and assembles an ORM response. Protocol layer 1002 is the lowest layer and drives all calls to the upper layers by calling “registered” functions. A Node layer 1004 handles navigation between nodes, ie.e, parsing the pathname to locate the virtual node, which represents some management entity.

[0100] A Handle layer 1006 maps “virtual nodes” to real objects/data. Such a mapping results in a “handle.” Handles are explicitly requested and released. An Aspects layer 1008 handles instances that are made up from more than one ORM tree. For example, the “statistics” Component is not a single Component n the tree, but is generated by the object manager. As another example, some attributes depend on others and cannot be modified independently, but have to be treated as a single, atomic operation. These groups of attributes within an instance are called “aspects” and the corresponding Aspect layer is provided to extract and modify groups of attributes within an instance.

[0101] An Attribute layer 1010 retrieves or updates a single attribute (of an aspect) and provides the meta information corresponding to this attribute. A Conversion layer handles the actual conversion of attributes between the external (ORM) and the internal (native) presentation. This layer also converts states and bitmaps to “friendly strings.”

[0102] 2. Web Agents

[0103] In another preferred embodiment of the present invention, the objects are not self-describing. In such an embodiment, one or more servers 140 in the system performs a “worm” function, i.e., one or more servers 140 follow object-links between objects and save all the information available concerning those objects. When a request is received from browser 130, server 140 sends its collected data to browser 130 (assuming that the collected data is not older than a threshold age value).

[0104] In summary, the present invention allows a user to manage objects by way of hypermedia, such as the world wide web. In a preferred embodiment, the objects are self-describing and respond to questions about themselves from one or more object managers. A server communicates with the object manager(s) and generates HTML from responses received from the object manager. Conventional browser software allows a user to indicate which objects he wishes to browse or change. Using a conventional hypermedia request/response protocol, the browser and server communicate to obtain information about objects and their attributes. The server also translates HTML/URLs received from the browser to requests to the object manager. Such a system allows a non-centralized object management system.

[0105] Other embodiments will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope of the invention being indicated by the following claims and equivalents.