US20040015542A1 - Hypermedia management system - Google Patents

Hypermedia management system Download PDF

Info

Publication number
US20040015542A1
US20040015542A1 US10/201,544 US20154402A US2004015542A1 US 20040015542 A1 US20040015542 A1 US 20040015542A1 US 20154402 A US20154402 A US 20154402A US 2004015542 A1 US2004015542 A1 US 2004015542A1
Authority
US
United States
Prior art keywords
link
provider
links
client
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10/201,544
Inventor
Steven Anonsen
Jason Huck
Daniel Seefeldt
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to US10/201,544 priority Critical patent/US20040015542A1/en
Assigned to MICROSOFT CORPORATION reassignment MICROSOFT CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ANONSEN, STEVEN P., HUCK, JASON A., SEEFELDT, DANIEL E.
Publication of US20040015542A1 publication Critical patent/US20040015542A1/en
Priority to US11/312,784 priority patent/US7970867B2/en
Assigned to MICROSOFT TECHNOLOGY LICENSING, LLC reassignment MICROSOFT TECHNOLOGY LICENSING, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MICROSOFT CORPORATION
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02Standardisation; Integration
    • H04L41/024Standardisation; Integration using relational databases for representation of network management data, e.g. managing via structured query language [SQL]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/955Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G06F16/9558Details of hyperlinks; Management of linked annotations

Definitions

  • the present invention relates to hypermedia links. More specifically, the present invention relates to managing hypermedia links between objects.
  • the data types offered by SQL can be classified as character arrays (names), numbers, and data types related to date and time.
  • Tables can be modified or combined by several operations of relational algebra such as the application of Boolean operators, projection (i.e. selection of columns) or the Cartesian product.
  • Relational databases offer several advantages. Database queries are based on a comparison of the table contents. Thus, no pointers are required in relational databases, and all relations are treated uniformly. Further, the tables are independent (they are not related by pointers), so it is easier to maintain dynamic data sets. The tables are easily expandable by simply adding new columns. Also, it is relatively easy to create user-specific views from relational databases.
  • object oriented data base systems Another recent technology for database systems is referred to as object oriented data base systems. These systems offer more complex data types in order to overcome the restrictions of conventional relational databases.
  • object oriented data base models an “object” includes both data and the methods which can be applied to the object.
  • Each object is a concrete instance of an object class defining the attributes and methods of all its instances. Each instance has its unique identifier by which it can be referred to in the database.
  • Object oriented databases operate under a number of principles.
  • One such principle is referred to as inheritance.
  • Inheritance means that new object classes can be derived from another class.
  • the new classes inherit the attributes and methods of the other class (the super-class) and offer additional attributes and operations.
  • An instance of the derived class is also an instance of the super-class. Therefore, the relation between a derived class and its super-class is referred to as the “isA” relation.
  • a second principle related to object oriented databases is referred to as “aggregation.”
  • Aggregation means that composite objects may be constructed as consisting of a set of elementary objects.
  • a “container object” can communicate with the objects contained therein by their methods of the contained objects.
  • the relation between the container object and its components is called a “partOf” relation because a component is a part of the container object.
  • encapsulation Yet another principle related to object oriented databases is referred to as encapsulation.
  • an application can only communicate with an object through messages.
  • the operations provided by an object define the set of messages which can be understood by the object. No other operations can be applied to the object.
  • Polymorphism means that derived classes may re-define methods of their super-classes.
  • Objects present a variety of advantages. For example, operations are an important part of objects. Because the implementations of the operations are hidden to an application, objects can be more easily used by application programs. Further, an object class can be provided as an abstract description for a wide variety of actual objects, and new classes can be derived from the base class. Thus, if an application knows the abstract description and using only the methods provided by, the application can still accommodate objects of the derived classes, because the objects in the derived classes inherit these methods. However, object oriented data bases are not yet as widely used in commercial products as relational databases.
  • ADT abstract data types
  • An ADT is a data type that is constructed by combining basic alphanumeric data types. The support for abstract data types presents certain advantages. For example, the operations and methods associated with the new data type can be used to index, store, and retrieve records based on the content of the new data type.
  • Some conventional object-relational databases support an extended form of SQL, sometimes referred to as ObjectSQL.
  • the extensions are provided to support the object model (e.g., queries involving object attributes).
  • object model e.g., queries involving object attributes
  • SQL with some extensions, is the language for data definition, manipulation, and query. Both the target of a query and the result of a query are still tables.
  • the extended SQL language is often still the primary interface to the database. Therefore, there is no direct support of host object languages and their objects. This forces programmers to continue to translate between objects and tables.
  • a system supplies links between objects.
  • a link service receives a link request from a client. The request identifies a source object. The link service aggregates links from link providers for which the source object is a source of the links, and provides the aggregated links to the client.
  • the link request identifies an instance of the source object and the link service aggregates links based on the instance of the source object.
  • the link request identifies the type of the source object and the link service aggregates the links based on the type.
  • Link providers can register with the link service so they can provide links in response to requests from clients.
  • the link service can query the link provider to obtain information indicative of the links that the link provider will provide. Traversal of links yields a link result from the link providers.
  • the traversal result can be a destination object, which is the destination of the link, or an action, or a combination of an action and a destination object (or other targets) which is represented by the link.
  • FIG. 1 is a block diagram of one embodiment of an object-relational data storage system.
  • FIG. 2 is a block diagram of an environment in which the present invention can be used.
  • FIG. 3 is a block diagram of a hypermedia service system in accordance with one embodiment of the present invention.
  • FIG. 4 is a flow diagram illustrating how link requests are processed by the hypermedia service system in accordance with one embodiment of the present invention.
  • FIG. 5 is an illustration of an exemplary user interface.
  • FIG. 6 is a flow diagram illustrating how links are traversed by the system in accordance with one embodiment of the present invention.
  • FIG. 7 is a flow diagram illustrating how hypermedia providers are registered in accordance with one embodiment of the present invention.
  • FIG. 8 shows an association between objects.
  • FIG. 9 is a block diagram illustrating another embodiment of a hypermedia system.
  • FIG. 10 is a flow diagram illustrating the operation of the system shown in FIG. 9.
  • the present invention relates to maintaining links between objects.
  • the links are between objects in an object-relational (O-R) database, although the objects need not be stored in a database system at all, and the present invention can still provide benefits.
  • O-R object-relational
  • FIG. 1 is a block diagram illustrating one embodiment of a data storage and accessing system 10 in accordance with the present invention.
  • System 10 includes data access system (or entity persistence system) 12 , relational data store mechanism 14 , relational database 16 , and class-table mapping 18 .
  • System 10 is illustratively an object-relational (O-R) data storage system in which stored data can be referred to in terms of entities (or objects) and their properties, rather than elements of the data base schema, such as tables and columns.
  • O-R object-relational
  • the data can be organized in terms of entities 20 (which is used interchangeably herein with the term objects).
  • Each entity illustratively includes a metadata portion 22 and a remaining attributes portion 24 .
  • the metadata portion 22 describes the entity 20
  • the remaining attributes 24 define further attributes of entity 20 , such as the data stored therein.
  • Each of the attributes in entity 20 is mapped to a corresponding entity table 26 and a specific column 28 in a given entity table 26 .
  • Data access system 12 can receive forms of a request such as a query 30 which specifies an entity, or portions of an entity or group of entities, to be retrieved.
  • Query 30 can illustratively be expressed in terms of objects (“entities”) and properties rather than in terms of tables and columns. The particular manner in which queries are expressed does not form part of the present invention.
  • Data access system 12 receives the query 30 and accesses class-table mapping 18 . In this way, data access system 12 can determine the location of the data for the entities identified by query 30 .
  • Data access system 12 includes a translator 13 that translates query 30 into a relational database query 32 which is suitable for input to relational data store mechanism 14 .
  • relational data store mechanism 14 is a server that operates according to the SQL programming language in accessing relational database 16 . Therefore, data access system 12 receives queries 30 in terms of objects and translates those queries into an appropriate relational database query 32 that is then provided to the data store mechanism (or server) 14 which actually accesses the data in relational database 16 .
  • Relational data store mechanism 14 retrieves the requested data and returns it in the form of relational database results 34 .
  • the results are returned to data access system 12 which then formulates the relational database results 34 into a requested result set 36 .
  • result set 36 is requested in query 30 .
  • Query 30 may request that the results be output in the form of one or more objects or simply as a data set.
  • data access system 12 arranges the relational database results 34 into the proper format and outputs them as result set 36 .
  • FIG. 2 illustrates an example of a suitable computing system environment 100 on which the invention may be implemented.
  • the computing system environment 100 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing environment 100 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment 100 .
  • the invention is operational with numerous other general purpose or special purpose computing system environments or configurations.
  • Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
  • the invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer.
  • program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
  • the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.
  • program modules may be located in both local and remote computer storage media including memory storage devices.
  • an exemplary system for implementing the invention includes a general purpose computing device in the form of a computer 110 .
  • Components of computer 110 may include, but are not limited to, a processing unit 120 , a system memory 130 , and a system bus 121 that couples various system components including the system memory to the processing unit 120 .
  • the system bus 121 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures.
  • such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus.
  • ISA Industry Standard Architecture
  • MCA Micro Channel Architecture
  • EISA Enhanced ISA
  • VESA Video Electronics Standards Association
  • PCI Peripheral Component Interconnect
  • Computer 110 typically includes a variety of computer readable media.
  • Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media.
  • Computer readable media may comprise computer storage media and communication media.
  • Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.
  • Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 100 .
  • Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier WAV or other transport mechanism and includes any information delivery media.
  • modulated data signal means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.
  • communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, FR, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
  • the system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132 .
  • ROM read only memory
  • RAM random access memory
  • BIOS basic input/output system 133
  • RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120 .
  • FIG. 2 illustrates operating system 134 , application programs 135 , other program modules 136 , and program data 137 .
  • the computer 110 may also include other removable/non-removable volatile/nonvolatile computer storage media.
  • FIG. 2 illustrates a hard disk drive 141 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 151 that reads from or writes to a removable, nonvolatile magnetic disk 152 , and an optical disk drive 155 that reads from or writes to a removable, nonvolatile optical disk 156 such as a CD ROM or other optical media.
  • removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like.
  • the hard disk drive 141 is typically connected to the system bus 121 through a non-removable memory interface such as interface 140
  • magnetic disk drive 151 and optical disk drive 155 are typically connected to the system bus 121 by a removable memory interface, such as interface 150 .
  • the drives and their associated computer storage media discussed above and illustrated in FIG. 2 provide storage of computer readable instructions, data structures, program modules and other data for the computer 110 .
  • hard disk drive 141 is illustrated as storing operating system 144 , application programs 145 , other program modules 146 , and program data 147 .
  • operating system 144 application programs 145 , other program modules 146 , and program data 147 are given different numbers here to illustrate that, at a minimum, they are different copies.
  • a user may enter commands and information into the computer 110 through input devices such as a keyboard 162 , a microphone 163 , and a pointing device 161 , such as a mouse, trackball or touch pad.
  • Other input devices may include a joystick, game pad, satellite dish, scanner, or the like.
  • These and other input devices are often connected to the processing unit 120 through a user input interface 160 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB).
  • a monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190 .
  • computers may also include other peripheral output devices such as speakers 197 and printer 196 , which may be connected through an output peripheral interface 190 .
  • the computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180 .
  • the remote computer 180 may be a personal computer, a hand-held device, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110 .
  • the logical connections depicted in FIG. 2 include a local area network (LAN) 171 and a wide area network (WAN) 173 , but may also include other networks.
  • LAN local area network
  • WAN wide area network
  • Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.
  • the computer 110 When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170 .
  • the computer 110 When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173 , such as the Internet.
  • the modem 172 which may be internal or external, may be connected to the system bus 121 via the user-input interface 160 , or other appropriate mechanism.
  • program modules depicted relative to the computer 110 may be stored in the remote memory storage device.
  • FIG. 2 illustrates remote application programs 185 as residing on remote computer 180 . It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
  • the present invention can be carried out on a computer system such as that described with respect to FIG. 2.
  • the present invention can be carried out on a server, a computer devoted to message handling, or on a distributed system in which different portions of the present invention are carried out on different parts of the distributed computing system.
  • One aspect of the present invention is a system for creating links among objects or entities based on logical relationships between those objects, when no physical relationship necessarily exists.
  • One embodiment of the invention allows the logical relationships among such entities to be surfaced as links in a hyperspace, thus making the entities themselves the nodes of the hyperspace.
  • hypermedia is referred to as a mechanism for navigating a hyperspace which is comprised of a set of nodes and the hypermedia links that join those nodes.
  • FIG. 3 The hypermedia architecture 200 shows a client 202 that communicates with hypermedia service 204 .
  • Hypermedia service 204 accesses a provider register 206 and also communicates with a set of hypermedia providers 208 , 210 and 212 .
  • Hypermedia service (HMS) 204 is illustratively the central point where clients 202 request hypermedia (i.e., hypermedia links or simply links).
  • Hypermedia providers 208 - 212 are registered with HMS 204 .
  • Providers 208 - 212 are the points at which the links are actually created. New providers 208 - 212 can be registered with HMS 204 , thus allowing extensibility.
  • the data that is transferred between client 202 and HMS 204 , and between HMS 204 and providers 208 - 212 conforms, in one illustrative embodiment, to an XML schema attached as an exhibit hereto.
  • the definition of a “link” in the schema includes a link category. Link categories are discussed in greater detail below. Suffice it to say for now that new categories may be defined by a hypermedia provider, thus allowing additional extensibility.
  • FIG. 4 is a flow diagram better illustrating how a client 202 requests links from hypermedia system 200 , and it will be described in conjunction with FIG. 3.
  • the HMS 204 and link providers 208 - 212 are objects that expose application programming interfaces (APIs) having methods to accomplish the functionality described. The specific details of the API are described in greater detail in the appendix hereto.
  • client 200 is displaying a list of customer entities (where the term “entities” is used interchangeably with the term “object”).
  • the client wishes to display a set of links to the user for possible traversal.
  • Client 202 first generates a request for links in terms of a source node (i.e., a source entity or a source object). In this example, the client would request the links for the customer object.
  • the request also illustratively specifies which categories of links to be retrieved.
  • the links can represent relationships between nodes, as well as actions that can be performed on nodes, or any other destinations specified.
  • Class links have the context of a class. They represent either a relationship to a destination node, or an action that can be performed.
  • a class link provides information that is indicative of where a client can traverse to, or what operations can be performed, as they pertain to a particular class.
  • Instance and instance specific links have the context of an instance. The difference between the two types is that instance specific links are directly tied to a specific instance of an entity (or object), and instance links are tied to a class, but an instance of that class must be specified in order to traverse the link. An instance or instance specific link provides information indicative of where the client can traverse to, and what operations can be performed, with the particular instance being examined.
  • All three types of links can be traversed, which is discussed in greater detail below with respect to FIG. 6. Traversal returns the destination node of the link. If the link represents an action, traversal performs the action the link represents, and may or may not return a destination node.
  • the type of link is not the only manner in which links may be grouped.
  • Links also illustratively belong to a link category.
  • One example of a link category is a metamodel category. This is described in greater detail below. Briefly, however, links that belong to this link category represent associations between entities. These associations are captured in the metamodel (or object model) of the system.
  • a link category In addition to being a grouping mechanism, a link category also defines a protocol that is followed by the particular providers 208 - 212 that supplied the link. The link category gives client 202 an indication of what type of information the link represents, and what type of object will result from traversal of the link. All links of the same category can be handled in the same manner. In this way, client 202 is able to determine how to handle a link based on the link category to which it belongs.
  • client 202 may generate the hypermedia request by requesting class, instance, or instance specific links, or a combination of these.
  • the client 202 can also specify a set of link categories, and only links from those categories will be returned. If no category is specified, links from all categories will be returned.
  • client 202 once client 202 has generated the request for links, and identified a node which will serve as the source of the link, it provides the request to HMS 204 . Generating the request and providing it to HMS 204 is indicated by blocks 214 and 216 in FIG. 4.
  • HMS 204 then checks register 206 for information to identify the particular providers 208 - 212 that provide links that have, as a source node, the node identified by client 202 as the source of the links. This is indicated by block 218 .
  • providers 208 - 212 provided HMS 204 with information about the link categories, link types, and node classes for which the provider provides links. This information is stored in register 206 . Therefore, when HMS 204 receives a request from client 202 , it checks register 206 to determine which providers it should access.
  • HMS 204 then forwards the request generated by client 202 to the identified providers 208 - 212 which will provide links having the source node identified by client 202 as the source of the link. This is indicated by block 220 .
  • HMS 204 The providers which receive the request, in turn, return the requested links to HMS 204 . This is indicated by block 222 . HMS 204 then aggregates all of the links from the providers 208 - 212 which have responded with links, and returns those links to client 202 . This is indicated by block 224 in FIG. 4.
  • FIG. 5 shows an exemplary user interface where links have already been requested.
  • the user interface generator that generates display 300 is currently rendering a customer list that displays information about a plurality of customer objects 302 , 304 , 306 and 308 .
  • the user interface When the user selects a certain customer object, the user interface generates a request requesting links from HMS 204 where the selected customer object 302 is the source link.
  • HMS 204 goes through the process described with respect to FIG. 4 and returns a set of links for which customer entity 302 (which can also be referred to as customer node 302 ) is the source node.
  • the user interface generating the display can then display the links 310 as desired.
  • FIG. 5 shows an exemplary user interface where links have already been requested.
  • the user interface generator that generates display 300 is currently rendering a customer list that displays information about a plurality of customer objects 302 , 304 , 306 and 308 .
  • the user interface When the user selects a certain customer object, the
  • the links for which customer node 302 is the source node include an address link identifying an Address node associated with customer node 302 , an orders link which links to an Orders node corresponding to customer node 302 and a general information link which links to a General Information node corresponding to customer node 302 .
  • FIG. 6 is a flow diagram illustrating what happens when a link is traversed.
  • client 202 sends the link, along with the traversal request, to HMS 204 . This is indicated by block 350 in FIG. 6.
  • the link provided by client 202 is illustratively a class link or an instance specific link.
  • HMS 204 then identifies the particular provider 208 - 212 that provided the link. This is indicated by block 352 .
  • the specific links supplied by the providers in response to requests is maintained by HMS 204 by adding this information to the link during the hypermedia request. This information is then examined during a traversal request. Therefore, HMS 204 can identify the provider which supplied the link.
  • HMS 204 then forwards the traversal request and link to the identified provider. This is indicated by block 354 .
  • the provider traverses the link, returning traversal results to HMS 204 .
  • the traversal results can include a destination node, which is the destination of the link, or performance of an action represented by the link or both, or other targets represented by the link.
  • the link represents the relationship between a customer and a query of the customer's orders
  • traversing the link entails the provider returning the query (which is an entity, like the customer), not the results of executing the query.
  • traversing the link returns the URL, it does not open a browser window displaying the page pointed to by the URL.
  • the link does contain a destination (the URL), but the destination is not an entity or an action.
  • the traversal result may return an entity, some result which is not an entity, or there may be no substantive result returned. If the link represents an action, traversing the link performs the action and the result may indicate this. Combinations of these types of results can occur as well.
  • HMS 204 returns the traversal results to client 202 . This is indicated by block 358 .
  • Client 202 illustratively includes a handler that handles the traversal results. For example, if the traversal returns a query, the client handler executes that query against the database and displays the results to the user. If the query returns a URL, the client handler opens a browser window displaying the page pointed to by the URL, etc. Handling the traversal results at the client is indicated by block 360 in FIG. 6.
  • FIG. 7 is a flow diagram illustrating how a provider is registered with HMS 204 .
  • HMS 204 receives a request to register a provider. This is indicated by block 362 .
  • HMS 204 then checks the security of the requester. This is indicated by block 364 . This involves determining whether the requester has authorization to register a provider and can be done in any known way. This is indicated by block 366 .
  • HMS 204 then requests information from the provider about the link categories, link types and node classes for which the provider provides links. This is indicated by block 368 .
  • the provider returns the information, along with a version identifier. This is indicated by block 370 .
  • HMS 204 then caches the information in provider register 206 , and information confirming the success of the registration is returned to the requester. This is indicated by block 372 . HMS 204 is then in position to receive requests for links provided by the newly registered provider.
  • HMS 204 can operate with no knowledge about what the links are, only knowing that the provider will provide those links. The same is true for new links.
  • An existing provider can add new links and they will be provided when requested. The developer thus need not hand code the links into the system.
  • the providers simply need to implement an interface known to HMS 204 , such as those described in the Appendix hereto.
  • each HMS 204 derives from the interface implemented by the providers. Therefore, each HMS 204 can also be a provider and can thus be operably connected to another HMS 204 .
  • HMS 204 can be implemented both as an XML web service and as a class which can be called directly if client 202 resides on the same server as HMS 204 .
  • the providers can also be either deployed remotely as XML web services or on the same server as HMS 204 .
  • the links are requested based on object types (or object classes) or specific object instances.
  • the presentation of the nodes is decoupled from the nodes themselves.
  • the nodes are instances of objects rather than presentation elements, such as web pages. This allows client 202 to process or handle the destination node of the link in any manner it wishes.
  • FIGS. 8 - 10 illustrate yet another embodiment of the present invention.
  • one of providers 208 - 212 provides links between associated objects based on association metadata.
  • objects such as business objects or entities in a business application
  • Such objects in a business application may include, for example, a “Customer” object, a “SalesPerson” object and an “Order” object.
  • These objects (entities) are interrelated through different associations. For instance, an “Order” has both a “Customer” and a “SalesPerson” associated with it. Since these associations exist in the problem domain of the application, they are associations that the end user typically understands. Therefore, it may be beneficial to allow the end user to navigate between these associations.
  • FIG. 8 depicts a relationship between an “Order” entity and a “Customer” entity that is modeled during the application development process.
  • FIG. 9 is a block diagram of an embodiment of hypermedia system 201 that takes advantage of the stored association metadata. A number of the items shown in FIG. 9 are similar to those shown in FIG. 3 and are similarly numbered. However, FIG. 9 shows that system 201 also includes a metadata hypermedia provider 400 which is connected to a metadata store 402 .
  • FIG. 10 is a flow diagram illustrating the operation of system 201 in accordance with one embodiment of the present invention, and will be described in conjunction with FIG. 9.
  • Metadata hypermedia provider 400 has properly registered with HMS 204 and its link and identification data resides in provider register 206 .
  • Client 202 first generates a hypermedia request (or link request) specifying which objects are the source of the links sought, and which categories of links are to be retrieved. This request is received by HMS 204 . This is indicated by block 404 in FIG. 10. HMS 204 then forwards the request on to the appropriate providers, which in this case will include metadata hypermedia provider 400 . This is indicated by block 406 .
  • Provider 400 analyzes association information contained in metadata store 402 .
  • metadata hypermedia provider 400 examines each association in metadata store 402 which has been requested and determines whether the user has rights to access the associated entities.
  • Provider 400 can determine whether the user has rights to access the associated entities by accessing a security subsystem, or in any other suitable way. Accessing security does not form part of the present invention.
  • Provider 400 then creates a link for each association for which the user has access, and places association information in the link. This is indicated by block 408 .
  • Provider 400 identifies (using terminology defined by the Unified Modeling Language (UML)) simple associations and composition associations; these can have a variety of cardinalities, such as 1-1, 1-many or many-many relationships.
  • Provider 400 also identifies inheritance associations. For each association located by provider 400 , provider 400 creates a link between the source node and the associated node. This is indicated by block 410 .
  • UML Unified Modeling Language
  • the links are returned from provider 400 to HMS 204 as indicated by block 412 , and HMS 204 aggregates all returned links and forwards them on to client 202 . This is indicated by block 414 .
  • provider 400 does not return the associated node, but instead returns a query whose results, if executed, include only the associated node.

Abstract

A system supplies links between objects. A link service receives a link request from a client. The request identifies a source object. The link service aggregates links from link providers for which the source object is a source of the links, and provides the aggregated links to the client.

Description

    BACKGROUND OF THE INVENTION
  • The present invention relates to hypermedia links. More specifically, the present invention relates to managing hypermedia links between objects. [0001]
  • A number of different databases will first be discussed, although it will be appreciated that the objects need not reside in a database at all. In conventional relational databases that can be used to store the objects, all data are stored in named tables. The tables are described by their features. In other words, the rows of each table contain items of identical type, and the definitions of the columns of the table (i.e., the column names and the data types stored in the column) describe the attributes of each of the instances of the object. By identifying its name, its column names and the data types of the column contents, a table is completely described. Queries to a relational data base are formulated in a query language. One such language is SQL (Structure Query Language) which is widely used in commercial relational data base systems. The data types offered by SQL can be classified as character arrays (names), numbers, and data types related to date and time. Tables can be modified or combined by several operations of relational algebra such as the application of Boolean operators, projection (i.e. selection of columns) or the Cartesian product. [0002]
  • Relational databases offer several advantages. Database queries are based on a comparison of the table contents. Thus, no pointers are required in relational databases, and all relations are treated uniformly. Further, the tables are independent (they are not related by pointers), so it is easier to maintain dynamic data sets. The tables are easily expandable by simply adding new columns. Also, it is relatively easy to create user-specific views from relational databases. [0003]
  • There are, however, a number of disadvantages associated with relational databases as well. For example, access to data by reference to properties is not optimal in the classical relational data model. This can make such databases cumbersome in many applications. [0004]
  • Another recent technology for database systems is referred to as object oriented data base systems. These systems offer more complex data types in order to overcome the restrictions of conventional relational databases. In the context of object oriented data base models, an “object” includes both data and the methods which can be applied to the object. Each object is a concrete instance of an object class defining the attributes and methods of all its instances. Each instance has its unique identifier by which it can be referred to in the database. [0005]
  • Object oriented databases operate under a number of principles. One such principle is referred to as inheritance. Inheritance means that new object classes can be derived from another class. The new classes inherit the attributes and methods of the other class (the super-class) and offer additional attributes and operations. An instance of the derived class is also an instance of the super-class. Therefore, the relation between a derived class and its super-class is referred to as the “isA” relation. [0006]
  • A second principle related to object oriented databases is referred to as “aggregation.” Aggregation means that composite objects may be constructed as consisting of a set of elementary objects. A “container object” can communicate with the objects contained therein by their methods of the contained objects. The relation between the container object and its components is called a “partOf” relation because a component is a part of the container object. [0007]
  • Yet another principle related to object oriented databases is referred to as encapsulation. According to encapsulation, an application can only communicate with an object through messages. The operations provided by an object define the set of messages which can be understood by the object. No other operations can be applied to the object. [0008]
  • Another principle related to object oriented databases is referred to as polymorphism. Polymorphism means that derived classes may re-define methods of their super-classes. [0009]
  • Objects present a variety of advantages. For example, operations are an important part of objects. Because the implementations of the operations are hidden to an application, objects can be more easily used by application programs. Further, an object class can be provided as an abstract description for a wide variety of actual objects, and new classes can be derived from the base class. Thus, if an application knows the abstract description and using only the methods provided by, the application can still accommodate objects of the derived classes, because the objects in the derived classes inherit these methods. However, object oriented data bases are not yet as widely used in commercial products as relational databases. [0010]
  • Yet another database technology attempts to combine the advantages of the wide acceptance of relational data bases and the benefits of the object oriented paradigm. This technology is referred to as object-relational database systems. These databases employ a data model that attempts to add object oriented characteristics to tables. All persistent (database) information is still in tables, but some of the tabular entries can have richer data structure. These data structures are referred to as abstract data types (ADTs). An ADT is a data type that is constructed by combining basic alphanumeric data types. The support for abstract data types presents certain advantages. For example, the operations and methods associated with the new data type can be used to index, store, and retrieve records based on the content of the new data type. [0011]
  • Some conventional object-relational databases support an extended form of SQL, sometimes referred to as ObjectSQL. The extensions are provided to support the object model (e.g., queries involving object attributes). However, these object-relational databases are still relational because the data is stored in tables of rows and columns, and SQL, with some extensions, is the language for data definition, manipulation, and query. Both the target of a query and the result of a query are still tables. The extended SQL language is often still the primary interface to the database. Therefore, there is no direct support of host object languages and their objects. This forces programmers to continue to translate between objects and tables. [0012]
  • Thus, in prior object-relational databases, an object can be queried for in terms of the object's fields, rather than using the relational database column names. [0013]
  • However, a number of problems exist with respect to conventional user interface (UI) technology for object-relational technology and other databases or environments (other than databases) where links between objects are desired. [0014]
  • Conventional user interfaces are hand written. This includes the links between different pieces of data in the databases. Each time such a link is desired, it must be hand written again. For example, if an order entry page has been coded to include a link that references customer information, that link has typically been placed by hand. If the order appears elsewhere in the user interface, the link must be hand coded again. Therefore, if a third party integrates an application to the order object, the order page will not show that information or provide links to it, because such links have not been hand coded, even though there may be a link in a representation of the order object that is independent of the UI. [0015]
  • SUMMARY OF THE INVENTION
  • A system supplies links between objects. A link service receives a link request from a client. The request identifies a source object. The link service aggregates links from link providers for which the source object is a source of the links, and provides the aggregated links to the client. [0016]
  • In one embodiment, the link request identifies an instance of the source object and the link service aggregates links based on the instance of the source object. In another embodiment, the link request identifies the type of the source object and the link service aggregates the links based on the type. [0017]
  • Link providers can register with the link service so they can provide links in response to requests from clients. When a link provider requests to register with the link service, or another system makes the request on behalf of the link provider, the link service can query the link provider to obtain information indicative of the links that the link provider will provide. Traversal of links yields a link result from the link providers. The traversal result can be a destination object, which is the destination of the link, or an action, or a combination of an action and a destination object (or other targets) which is represented by the link.[0018]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a block diagram of one embodiment of an object-relational data storage system. [0019]
  • FIG. 2 is a block diagram of an environment in which the present invention can be used. [0020]
  • FIG. 3 is a block diagram of a hypermedia service system in accordance with one embodiment of the present invention. [0021]
  • FIG. 4 is a flow diagram illustrating how link requests are processed by the hypermedia service system in accordance with one embodiment of the present invention. [0022]
  • FIG. 5 is an illustration of an exemplary user interface. [0023]
  • FIG. 6 is a flow diagram illustrating how links are traversed by the system in accordance with one embodiment of the present invention. [0024]
  • FIG. 7 is a flow diagram illustrating how hypermedia providers are registered in accordance with one embodiment of the present invention. [0025]
  • FIG. 8 shows an association between objects. [0026]
  • FIG. 9 is a block diagram illustrating another embodiment of a hypermedia system. [0027]
  • FIG. 10 is a flow diagram illustrating the operation of the system shown in FIG. 9.[0028]
  • DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS
  • The present invention relates to maintaining links between objects. In one exemplary embodiment, the links are between objects in an object-relational (O-R) database, although the objects need not be stored in a database system at all, and the present invention can still provide benefits. However, for the sake of the present example, prior to discussing details of the present invention, an environment in which the invention may be used will be discussed [0029]
  • FIG. 1 is a block diagram illustrating one embodiment of a data storage and accessing [0030] system 10 in accordance with the present invention. System 10 includes data access system (or entity persistence system)12, relational data store mechanism 14, relational database 16, and class-table mapping 18. System 10 is illustratively an object-relational (O-R) data storage system in which stored data can be referred to in terms of entities (or objects) and their properties, rather than elements of the data base schema, such as tables and columns. FIG. 1 illustrates one mechanism for doing this.
  • As shown in FIG. 1, the data can be organized in terms of entities [0031] 20 (which is used interchangeably herein with the term objects). Each entity illustratively includes a metadata portion 22 and a remaining attributes portion 24. The metadata portion 22 describes the entity 20, while the remaining attributes 24 define further attributes of entity 20, such as the data stored therein. Each of the attributes in entity 20 is mapped to a corresponding entity table 26 and a specific column 28 in a given entity table 26.
  • [0032] Data access system 12 can receive forms of a request such as a query 30 which specifies an entity, or portions of an entity or group of entities, to be retrieved. Query 30 can illustratively be expressed in terms of objects (“entities”) and properties rather than in terms of tables and columns. The particular manner in which queries are expressed does not form part of the present invention.
  • [0033] Data access system 12 receives the query 30 and accesses class-table mapping 18. In this way, data access system 12 can determine the location of the data for the entities identified by query 30. Data access system 12 includes a translator 13 that translates query 30 into a relational database query 32 which is suitable for input to relational data store mechanism 14. In one illustrative embodiment, relational data store mechanism 14 is a server that operates according to the SQL programming language in accessing relational database 16. Therefore, data access system 12 receives queries 30 in terms of objects and translates those queries into an appropriate relational database query 32 that is then provided to the data store mechanism (or server) 14 which actually accesses the data in relational database 16.
  • Relational [0034] data store mechanism 14 retrieves the requested data and returns it in the form of relational database results 34. The results are returned to data access system 12 which then formulates the relational database results 34 into a requested result set 36. In one illustrative embodiment, result set 36 is requested in query 30. Query 30 may request that the results be output in the form of one or more objects or simply as a data set. In any case, data access system 12 arranges the relational database results 34 into the proper format and outputs them as result set 36.
  • FIG. 2 illustrates an example of a suitable computing system environment [0035] 100 on which the invention may be implemented. The computing system environment 100 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing environment 100 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment 100.
  • The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like. [0036]
  • The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices. [0037]
  • With reference to FIG. 2, an exemplary system for implementing the invention includes a general purpose computing device in the form of a [0038] computer 110. Components of computer 110 may include, but are not limited to, a processing unit 120, a system memory 130, and a system bus 121 that couples various system components including the system memory to the processing unit 120. The system bus 121 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus.
  • [0039] Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 100. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier WAV or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, FR, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
  • The [0040] system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during startup, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way o example, and not limitation, FIG. 2 illustrates operating system 134, application programs 135, other program modules 136, and program data 137.
  • The [0041] computer 110 may also include other removable/non-removable volatile/nonvolatile computer storage media. By way of example only, FIG. 2 illustrates a hard disk drive 141 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 151 that reads from or writes to a removable, nonvolatile magnetic disk 152, and an optical disk drive 155 that reads from or writes to a removable, nonvolatile optical disk 156 such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive 141 is typically connected to the system bus 121 through a non-removable memory interface such as interface 140, and magnetic disk drive 151 and optical disk drive 155 are typically connected to the system bus 121 by a removable memory interface, such as interface 150.
  • The drives and their associated computer storage media discussed above and illustrated in FIG. [0042] 2, provide storage of computer readable instructions, data structures, program modules and other data for the computer 110. In FIG. 2, for example, hard disk drive 141 is illustrated as storing operating system 144, application programs 145, other program modules 146, and program data 147. Note that these components can either be the same as or different from operating system 134, application programs 135, other program modules 136, and program data 137. Operating system 144, application programs 145, other program modules 146, and program data 147 are given different numbers here to illustrate that, at a minimum, they are different copies.
  • A user may enter commands and information into the [0043] computer 110 through input devices such as a keyboard 162, a microphone 163, and a pointing device 161, such as a mouse, trackball or touch pad. Other input devices (not shown) may include a joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 120 through a user input interface 160 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190. In addition to the monitor, computers may also include other peripheral output devices such as speakers 197 and printer 196, which may be connected through an output peripheral interface 190.
  • The [0044] computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a hand-held device, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110. The logical connections depicted in FIG. 2 include a local area network (LAN) 171 and a wide area network (WAN) 173, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.
  • When used in a LAN networking environment, the [0045] computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user-input interface 160, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, FIG. 2 illustrates remote application programs 185 as residing on remote computer 180. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
  • It should be noted that the present invention can be carried out on a computer system such as that described with respect to FIG. 2. However, the present invention can be carried out on a server, a computer devoted to message handling, or on a distributed system in which different portions of the present invention are carried out on different parts of the distributed computing system. [0046]
  • As stated in the background, conventional user interfaces have traditionally had any links between objects hand coded. This presents a number of disadvantages. One aspect of the present invention is a system for creating links among objects or entities based on logical relationships between those objects, when no physical relationship necessarily exists. One embodiment of the invention allows the logical relationships among such entities to be surfaced as links in a hyperspace, thus making the entities themselves the nodes of the hyperspace. [0047]
  • In general, “hypermedia” is referred to as a mechanism for navigating a hyperspace which is comprised of a set of nodes and the hypermedia links that join those nodes. One embodiment of a hypermedia architecture is illustrated in FIG. 3. The [0048] hypermedia architecture 200 shows a client 202 that communicates with hypermedia service 204. Hypermedia service 204 accesses a provider register 206 and also communicates with a set of hypermedia providers 208, 210 and 212. Hypermedia service (HMS) 204 is illustratively the central point where clients 202 request hypermedia (i.e., hypermedia links or simply links). Hypermedia providers 208-212 are registered with HMS 204. Providers 208-212 are the points at which the links are actually created. New providers 208-212 can be registered with HMS 204, thus allowing extensibility.
  • The data that is transferred between [0049] client 202 and HMS 204, and between HMS 204 and providers 208-212 conforms, in one illustrative embodiment, to an XML schema attached as an exhibit hereto. The definition of a “link” in the schema includes a link category. Link categories are discussed in greater detail below. Suffice it to say for now that new categories may be defined by a hypermedia provider, thus allowing additional extensibility.
  • FIG. 4 is a flow diagram better illustrating how a [0050] client 202 requests links from hypermedia system 200, and it will be described in conjunction with FIG. 3. In one embodiment, the HMS 204 and link providers 208-212 are objects that expose application programming interfaces (APIs) having methods to accomplish the functionality described. The specific details of the API are described in greater detail in the appendix hereto. Assume that client 200 is displaying a list of customer entities (where the term “entities” is used interchangeably with the term “object”). Assume also that the client wishes to display a set of links to the user for possible traversal. Client 202 first generates a request for links in terms of a source node (i.e., a source entity or a source object). In this example, the client would request the links for the customer object. The request also illustratively specifies which categories of links to be retrieved. The links can represent relationships between nodes, as well as actions that can be performed on nodes, or any other destinations specified.
  • There are three types of links that can be retrieved: class links, instance links and instance specific links. Class links have the context of a class. They represent either a relationship to a destination node, or an action that can be performed. A class link provides information that is indicative of where a client can traverse to, or what operations can be performed, as they pertain to a particular class. [0051]
  • Instance and instance specific links have the context of an instance. The difference between the two types is that instance specific links are directly tied to a specific instance of an entity (or object), and instance links are tied to a class, but an instance of that class must be specified in order to traverse the link. An instance or instance specific link provides information indicative of where the client can traverse to, and what operations can be performed, with the particular instance being examined. [0052]
  • All three types of links can be traversed, which is discussed in greater detail below with respect to FIG. 6. Traversal returns the destination node of the link. If the link represents an action, traversal performs the action the link represents, and may or may not return a destination node. [0053]
  • In accordance with one embodiment of the present invention, the type of link is not the only manner in which links may be grouped. Links also illustratively belong to a link category. One example of a link category is a metamodel category. This is described in greater detail below. Briefly, however, links that belong to this link category represent associations between entities. These associations are captured in the metamodel (or object model) of the system. [0054]
  • In addition to being a grouping mechanism, a link category also defines a protocol that is followed by the particular providers [0055] 208-212 that supplied the link. The link category gives client 202 an indication of what type of information the link represents, and what type of object will result from traversal of the link. All links of the same category can be handled in the same manner. In this way, client 202 is able to determine how to handle a link based on the link category to which it belongs.
  • Therefore, [0056] client 202 may generate the hypermedia request by requesting class, instance, or instance specific links, or a combination of these. The client 202 can also specify a set of link categories, and only links from those categories will be returned. If no category is specified, links from all categories will be returned. In any case, once client 202 has generated the request for links, and identified a node which will serve as the source of the link, it provides the request to HMS 204. Generating the request and providing it to HMS 204 is indicated by blocks 214 and 216 in FIG. 4.
  • [0057] HMS 204 then checks register 206 for information to identify the particular providers 208-212 that provide links that have, as a source node, the node identified by client 202 as the source of the links. This is indicated by block 218. In other words, during the registration process, providers 208-212 provided HMS 204 with information about the link categories, link types, and node classes for which the provider provides links. This information is stored in register 206. Therefore, when HMS 204 receives a request from client 202, it checks register 206 to determine which providers it should access.
  • [0058] HMS 204 then forwards the request generated by client 202 to the identified providers 208-212 which will provide links having the source node identified by client 202 as the source of the link. This is indicated by block 220.
  • The providers which receive the request, in turn, return the requested links to [0059] HMS 204. This is indicated by block 222. HMS 204 then aggregates all of the links from the providers 208-212 which have responded with links, and returns those links to client 202. This is indicated by block 224 in FIG. 4.
  • FIG. 5 shows an exemplary user interface where links have already been requested. In FIG. 5, the user interface generator that generates [0060] display 300 is currently rendering a customer list that displays information about a plurality of customer objects 302, 304, 306 and 308. When the user selects a certain customer object, the user interface generates a request requesting links from HMS 204 where the selected customer object 302 is the source link. HMS 204 goes through the process described with respect to FIG. 4 and returns a set of links for which customer entity 302 (which can also be referred to as customer node 302) is the source node. The user interface generating the display can then display the links 310 as desired. In the example shown in FIG. 5, the links for which customer node 302 is the source node include an address link identifying an Address node associated with customer node 302, an orders link which links to an Orders node corresponding to customer node 302 and a general information link which links to a General Information node corresponding to customer node 302.
  • In one example, to traverse one of the [0061] links 310, the user simply selects it (such as by clicking on it with the mouse cursor). FIG. 6 is a flow diagram illustrating what happens when a link is traversed. After being selected by the user, client 202 sends the link, along with the traversal request, to HMS 204. This is indicated by block 350 in FIG. 6. The link provided by client 202 is illustratively a class link or an instance specific link.
  • [0062] HMS 204 then identifies the particular provider 208-212 that provided the link. This is indicated by block 352. The specific links supplied by the providers in response to requests is maintained by HMS 204 by adding this information to the link during the hypermedia request. This information is then examined during a traversal request. Therefore, HMS 204 can identify the provider which supplied the link.
  • [0063] HMS 204 then forwards the traversal request and link to the identified provider. This is indicated by block 354.
  • The provider traverses the link, returning traversal results to [0064] HMS 204. This is indicated by block 356. The traversal results can include a destination node, which is the destination of the link, or performance of an action represented by the link or both, or other targets represented by the link. For example, if the link represents the relationship between a customer and a query of the customer's orders, traversing the link entails the provider returning the query (which is an entity, like the customer), not the results of executing the query. Likewise, if the link represents the relationship between a customer and a URL of a particular web page containing a map of the customer's address, traversing the link returns the URL, it does not open a browser window displaying the page pointed to by the URL. In that example, the link does contain a destination (the URL), but the destination is not an entity or an action. Thus, the traversal result may return an entity, some result which is not an entity, or there may be no substantive result returned. If the link represents an action, traversing the link performs the action and the result may indicate this. Combinations of these types of results can occur as well.
  • [0065] HMS 204, in turn, returns the traversal results to client 202. This is indicated by block 358.
  • [0066] Client 202 illustratively includes a handler that handles the traversal results. For example, if the traversal returns a query, the client handler executes that query against the database and displays the results to the user. If the query returns a URL, the client handler opens a browser window displaying the page pointed to by the URL, etc. Handling the traversal results at the client is indicated by block 360 in FIG. 6.
  • FIG. 7 is a flow diagram illustrating how a provider is registered with [0067] HMS 204. First, HMS 204 receives a request to register a provider. This is indicated by block 362.
  • [0068] HMS 204 then checks the security of the requester. This is indicated by block 364. This involves determining whether the requester has authorization to register a provider and can be done in any known way. This is indicated by block 366.
  • [0069] HMS 204 then requests information from the provider about the link categories, link types and node classes for which the provider provides links. This is indicated by block 368.
  • The provider returns the information, along with a version identifier. This is indicated by [0070] block 370.
  • [0071] HMS 204 then caches the information in provider register 206, and information confirming the success of the registration is returned to the requester. This is indicated by block 372. HMS 204 is then in position to receive requests for links provided by the newly registered provider.
  • A number of other features of the present invention should be noted. It can be seen from the architecture that any number of providers can be added, at any time. Third party providers who integrate applications to the entities or objects stored in the database can be added and links to those third party applications will automatically be returned by [0072] HMS 204, so long as an appropriate provider is registered with HMS 204.
  • Also, third parties can define new link categories for which their providers will provide links. [0073] HMS 204 can operate with no knowledge about what the links are, only knowing that the provider will provide those links. The same is true for new links. An existing provider can add new links and they will be provided when requested. The developer thus need not hand code the links into the system. In one illustrative embodiment, the providers simply need to implement an interface known to HMS 204, such as those described in the Appendix hereto.
  • In another illustrative embodiment, the interface implemented by [0074] HMS 204 derives from the interface implemented by the providers. Therefore, each HMS 204 can also be a provider and can thus be operably connected to another HMS 204.
  • Also, [0075] HMS 204 can be implemented both as an XML web service and as a class which can be called directly if client 202 resides on the same server as HMS 204. The providers can also be either deployed remotely as XML web services or on the same server as HMS 204.
  • It can thus be seen that, in accordance with one embodiment of the present invention, the links are requested based on object types (or object classes) or specific object instances. The presentation of the nodes is decoupled from the nodes themselves. The nodes are instances of objects rather than presentation elements, such as web pages. This allows [0076] client 202 to process or handle the destination node of the link in any manner it wishes.
  • FIGS. [0077] 8-10 illustrate yet another embodiment of the present invention. In that embodiment, one of providers 208-212 provides links between associated objects based on association metadata. In other words, when developing an application, it is common for a set of objects (such as business objects or entities in a business application) to be defined. Such objects in a business application may include, for example, a “Customer” object, a “SalesPerson” object and an “Order” object. These objects (entities) are interrelated through different associations. For instance, an “Order” has both a “Customer” and a “SalesPerson” associated with it. Since these associations exist in the problem domain of the application, they are associations that the end user typically understands. Therefore, it may be beneficial to allow the end user to navigate between these associations.
  • The information that defines these associations is captured in a metamodel (or object model) of the applications as they are being developed. This information is typically stored as metadata. For example, FIG. 8 depicts a relationship between an “Order” entity and a “Customer” entity that is modeled during the application development process. [0078]
  • There are known tools which can be run against object models generated during development of an application. Such tools compile the models into association metadata. In accordance with an illustrative embodiment of the invention, this is done and the association metadata is stored. [0079]
  • FIG. 9 is a block diagram of an embodiment of [0080] hypermedia system 201 that takes advantage of the stored association metadata. A number of the items shown in FIG. 9 are similar to those shown in FIG. 3 and are similarly numbered. However, FIG. 9 shows that system 201 also includes a metadata hypermedia provider 400 which is connected to a metadata store 402.
  • The metadata associations developed during the application development process (such as the information shown in FIG. 8 which illustrates an association between an “Order” entity and a “Customer” entity) is stored in [0081] metadata store 402. FIG. 10 is a flow diagram illustrating the operation of system 201 in accordance with one embodiment of the present invention, and will be described in conjunction with FIG. 9.
  • It is assumed that [0082] metadata hypermedia provider 400 has properly registered with HMS 204 and its link and identification data resides in provider register 206. Client 202 first generates a hypermedia request (or link request) specifying which objects are the source of the links sought, and which categories of links are to be retrieved. This request is received by HMS 204. This is indicated by block 404 in FIG. 10. HMS 204 then forwards the request on to the appropriate providers, which in this case will include metadata hypermedia provider 400. This is indicated by block 406.
  • [0083] Provider 400 analyzes association information contained in metadata store 402. One illustrative design of metadata hypermedia provider 400 is discussed in greater detail in the Appendix hereto. Briefly, however, provider 400 examines each association in metadata store 402 which has been requested and determines whether the user has rights to access the associated entities. Provider 400 can determine whether the user has rights to access the associated entities by accessing a security subsystem, or in any other suitable way. Accessing security does not form part of the present invention. Provider 400 then creates a link for each association for which the user has access, and places association information in the link. This is indicated by block 408.
  • [0084] Provider 400 identifies (using terminology defined by the Unified Modeling Language (UML)) simple associations and composition associations; these can have a variety of cardinalities, such as 1-1, 1-many or many-many relationships. Provider 400 also identifies inheritance associations. For each association located by provider 400, provider 400 creates a link between the source node and the associated node. This is indicated by block 410.
  • The links are returned from [0085] provider 400 to HMS 204 as indicated by block 412, and HMS 204 aggregates all returned links and forwards them on to client 202. This is indicated by block 414. In one embodiment, provider 400 does not return the associated node, but instead returns a query whose results, if executed, include only the associated node.
  • Although the present invention has been described with reference to particular embodiments, workers skilled in the art will recognize that changes may be made in form and detail without departing from the spirit and scope of the invention. [0086]
    Figure US20040015542A1-20040122-P00001
    Figure US20040015542A1-20040122-P00002
    Figure US20040015542A1-20040122-P00003
    Figure US20040015542A1-20040122-P00004
    Figure US20040015542A1-20040122-P00005
    Figure US20040015542A1-20040122-P00006
    Figure US20040015542A1-20040122-P00007
    Figure US20040015542A1-20040122-P00008
    Figure US20040015542A1-20040122-P00009
    Figure US20040015542A1-20040122-P00010
    Figure US20040015542A1-20040122-P00011
    Figure US20040015542A1-20040122-P00012
    Figure US20040015542A1-20040122-P00013
    Figure US20040015542A1-20040122-P00014
    Figure US20040015542A1-20040122-P00015
    Figure US20040015542A1-20040122-P00016
    Figure US20040015542A1-20040122-P00017
    Figure US20040015542A1-20040122-P00018
    Figure US20040015542A1-20040122-P00019
    Figure US20040015542A1-20040122-P00020
    Figure US20040015542A1-20040122-P00021
    Figure US20040015542A1-20040122-P00022
    Figure US20040015542A1-20040122-P00023
    Figure US20040015542A1-20040122-P00024
    Figure US20040015542A1-20040122-P00025
    Figure US20040015542A1-20040122-P00026
    Figure US20040015542A1-20040122-P00027
    Figure US20040015542A1-20040122-P00028
    Figure US20040015542A1-20040122-P00029
    Figure US20040015542A1-20040122-P00030
    Figure US20040015542A1-20040122-P00031
    Figure US20040015542A1-20040122-P00032
    Figure US20040015542A1-20040122-P00033
    Figure US20040015542A1-20040122-P00034
    Figure US20040015542A1-20040122-P00035
    Figure US20040015542A1-20040122-P00036
    Figure US20040015542A1-20040122-P00037
    Figure US20040015542A1-20040122-P00038
    Figure US20040015542A1-20040122-P00039
    Figure US20040015542A1-20040122-P00040
    Figure US20040015542A1-20040122-P00041
    Figure US20040015542A1-20040122-P00042
    Figure US20040015542A1-20040122-P00043
    Figure US20040015542A1-20040122-P00044
    Figure US20040015542A1-20040122-P00045
    Figure US20040015542A1-20040122-P00046
    Figure US20040015542A1-20040122-P00047
    Figure US20040015542A1-20040122-P00048
    Figure US20040015542A1-20040122-P00049
    Figure US20040015542A1-20040122-P00050
    Figure US20040015542A1-20040122-P00051
    Figure US20040015542A1-20040122-P00052
    Figure US20040015542A1-20040122-P00053
    Figure US20040015542A1-20040122-P00054
    Figure US20040015542A1-20040122-P00055
    Figure US20040015542A1-20040122-P00056
    Figure US20040015542A1-20040122-P00057
    Figure US20040015542A1-20040122-P00058
    Figure US20040015542A1-20040122-P00059
    Figure US20040015542A1-20040122-P00060
    Figure US20040015542A1-20040122-P00061
    Figure US20040015542A1-20040122-P00062
    Figure US20040015542A1-20040122-P00063
    Figure US20040015542A1-20040122-P00064
    Figure US20040015542A1-20040122-P00065
    Figure US20040015542A1-20040122-P00066
    Figure US20040015542A1-20040122-P00067
    Figure US20040015542A1-20040122-P00068
    Figure US20040015542A1-20040122-P00069
    Figure US20040015542A1-20040122-P00070
    Figure US20040015542A1-20040122-P00071
    Figure US20040015542A1-20040122-P00072
    Figure US20040015542A1-20040122-P00073
    Figure US20040015542A1-20040122-P00074
    Figure US20040015542A1-20040122-P00075
    Figure US20040015542A1-20040122-P00076
    Figure US20040015542A1-20040122-P00077
    Figure US20040015542A1-20040122-P00078
    Figure US20040015542A1-20040122-P00079
    Figure US20040015542A1-20040122-P00080
    Figure US20040015542A1-20040122-P00081
    Figure US20040015542A1-20040122-P00082
    Figure US20040015542A1-20040122-P00083
    Figure US20040015542A1-20040122-P00084
    Figure US20040015542A1-20040122-P00085
    Figure US20040015542A1-20040122-P00086
    Figure US20040015542A1-20040122-P00087
    Figure US20040015542A1-20040122-P00088
    Figure US20040015542A1-20040122-P00089
    Figure US20040015542A1-20040122-P00090
    Figure US20040015542A1-20040122-P00091
    Figure US20040015542A1-20040122-P00092
    Figure US20040015542A1-20040122-P00093
    Figure US20040015542A1-20040122-P00094
    Figure US20040015542A1-20040122-P00095
    Figure US20040015542A1-20040122-P00096
    Figure US20040015542A1-20040122-P00097
    Figure US20040015542A1-20040122-P00098
    Figure US20040015542A1-20040122-P00099
    Figure US20040015542A1-20040122-P00100
    Figure US20040015542A1-20040122-P00101
    Figure US20040015542A1-20040122-P00102
    Figure US20040015542A1-20040122-P00103
    Figure US20040015542A1-20040122-P00104
    Figure US20040015542A1-20040122-P00105
    Figure US20040015542A1-20040122-P00106
    Figure US20040015542A1-20040122-P00107
    Figure US20040015542A1-20040122-P00108
    Figure US20040015542A1-20040122-P00109
    Figure US20040015542A1-20040122-P00110
    Figure US20040015542A1-20040122-P00111
    Figure US20040015542A1-20040122-P00112
    Figure US20040015542A1-20040122-P00113
    Figure US20040015542A1-20040122-P00114
    Figure US20040015542A1-20040122-P00115
    Figure US20040015542A1-20040122-P00116
    Figure US20040015542A1-20040122-P00117
    Figure US20040015542A1-20040122-P00118
    Figure US20040015542A1-20040122-P00119
    Figure US20040015542A1-20040122-P00120
    Figure US20040015542A1-20040122-P00121
    Figure US20040015542A1-20040122-P00122
    Figure US20040015542A1-20040122-P00123
    Figure US20040015542A1-20040122-P00124
    Figure US20040015542A1-20040122-P00125
    Figure US20040015542A1-20040122-P00126
    Figure US20040015542A1-20040122-P00127
    Figure US20040015542A1-20040122-P00128
    Figure US20040015542A1-20040122-P00129
    Figure US20040015542A1-20040122-P00130
    Figure US20040015542A1-20040122-P00131
    Figure US20040015542A1-20040122-P00132
    Figure US20040015542A1-20040122-P00133
    Figure US20040015542A1-20040122-P00134
    Figure US20040015542A1-20040122-P00135
    Figure US20040015542A1-20040122-P00136
    Figure US20040015542A1-20040122-P00137
    Figure US20040015542A1-20040122-P00138
    Figure US20040015542A1-20040122-P00139
    Figure US20040015542A1-20040122-P00140
    Figure US20040015542A1-20040122-P00141
    Figure US20040015542A1-20040122-P00142
    Figure US20040015542A1-20040122-P00143
    Figure US20040015542A1-20040122-P00144
    Figure US20040015542A1-20040122-P00145
    Figure US20040015542A1-20040122-P00146
    Figure US20040015542A1-20040122-P00147
    Figure US20040015542A1-20040122-P00148
    Figure US20040015542A1-20040122-P00149
    Figure US20040015542A1-20040122-P00150
    Figure US20040015542A1-20040122-P00151
    Figure US20040015542A1-20040122-P00152
    Figure US20040015542A1-20040122-P00153
    Figure US20040015542A1-20040122-P00154
    Figure US20040015542A1-20040122-P00155
    Figure US20040015542A1-20040122-P00156
    Figure US20040015542A1-20040122-P00157
    Figure US20040015542A1-20040122-P00158
    Figure US20040015542A1-20040122-P00159
    Figure US20040015542A1-20040122-P00160
    Figure US20040015542A1-20040122-P00161
    Figure US20040015542A1-20040122-P00162
    Figure US20040015542A1-20040122-P00163
    Figure US20040015542A1-20040122-P00164
    Figure US20040015542A1-20040122-P00165

Claims (38)

What is claimed is:
1. A system for supplying links between objects comprising:
a link service receiving a link request from a client, the link request identifying a source object, the link service aggregating links from link providers for which the source object is a source of the links and providing the aggregated links to the client.
2. The system of claim 1 wherein the link request identifies an instance of the source object and wherein the link service aggregates the links based on the instance of the source object.
3. The system of claim 1 wherein the link request identifies the class of the source object and wherein the link service aggregates the links based on the class of the source object.
4. The system of claim 1 and further comprising:
a link provider operably coupled to the link service, the link service requesting links having the source object as the source of the links from the link provider.
5. The system of claim 4 and further comprising:
a provider register, operably coupled to the link service, storing register information corresponding to the provider, the register information being indicative of links provided by the link provider.
6. The system of claim 5 wherein the register information is indicative of source objects for which the link provider provides links.
7. The system of claim 6 wherein the register information is indicative of classes of objects for which the link provider provides links.
8. The system of claim 6 wherein the register information is indicative of instances of objects for which the link provider provides links.
9. The system of claim 6 and further comprising:
a plurality of link providers, the provider register storing register information for each of the plurality of link providers.
10. The system of claim 9 wherein the link service accesses the provider register to identify link providers from which to request links, based on the identified source object.
11. The system of claim 10 wherein the link service is configured to receive a traversal request from the client, the traversal request identifying a link to traverse.
12. The system of claim 11 wherein the link service is configured to determine which link provider provided the link and to request that link provider to traverse the link, the link provider returning a traversal result.
13. The system of claim 12 wherein the link represents an association with a destination object and wherein the traversal result comprises the destination object.
14. The system of claim 12 wherein the link represents an action and wherein the traversal result comprises an indication that the link provider has taken the action.
15. The system of claim 12 wherein the link belongs to a link category and wherein the traversal result comprises:
a destination object belonging to the link category.
16. The system of claim 15 wherein the link category is defined by a link provider.
17. The system of claim 12 wherein the link service returns the traversal result to the client.
18. The system of claim 17 and further comprising: a handler operably coupled to the client and configured to handle the traversal result.
19. The system of claim 5 wherein the link service is configured to receive a registration request for an additional link provider.
20. The system of claim 19 wherein the link service queries the additional link provider for register information corresponding to the additional link provider and stores the register information in the provider register.
21. A method of maintaining links between objects comprising:
receiving a link request at a link service from a client, the link request identifying an object that is a source object in links being requested;
requesting links from a plurality of providers, based on the identified object;
aggregating links from the providers, at the link service; and
returning the aggregated links to the client.
22. The method of claim 21 wherein the link request identifies an instance of the source object and wherein requesting comprises:
requesting links based on the instance of the source object.
23. The method of claim 22 wherein the link request identifies a specific instance of the source object and wherein requesting comprises:
requesting links based on the specific instance of the source object.
24. The method of claim 21 wherein the link request identifies a class of the source object and wherein requesting comprises:
requesting links based on the class of the source object.
25. The system of claim 21 wherein requesting comprises:
accessing a provider register storing register information corresponding to the providers, the register information being indicative of links provided by the providers.
26. The method of claim 21 and further comprising:
receiving a traversal request from the client, the traversal request identifying a link to traverse.
27. The method of claim 26 and further comprising:
determining which link provider provided the link; and
requesting that link provider to traverse the link, the link provider returning a traversal result.
28. The method of claim 27 wherein the link represents a destination object and further comprising:
returning the destination object to the client.
29. The method of claim 27 wherein the link represents an action and further comprising:
returning an indication that the link provider has taken the action to the client.
30. The method of claim 21 and further comprising:
receiving a registration request for an additional link provider.
31. The method of claim 30 and further comprising:
querying the additional link provider for register information corresponding to the additional link provider; and
storing the register information.
32. A method of maintaining hypermedia links, comprising:
receiving, at a hypermedia service, a registration request for a link provider that provides links between objects;
querying the link provider for register information indicative of source nodes for which the link provider provides links; and
storing the register information.
33. The method of claim 32 wherein querying comprises:
querying the link provider for object classes for which the link provider provides links.
34. The method of claim 32 wherein querying comprises:
querying the link provider for instances of objects for which the link provider provides links.
35. A method of traversing links between objects the method comprising:
receiving, at a hypermedia service, a traversal request from a client, the traversal request identifying a link to traverse;
determining which of a plurality of link providers provided the link; and
requesting that link provider to traverse the link, the link provider returning a traversal result.
36. The method of claim 35 wherein the link represents a destination object and further comprising:
returning the destination object to the client.
37. The method of claim 35 wherein the link represents an action and further comprising:
returning an indication that the link provider has taken the action to the client.
38. The method of claim 35 and further comprising:
returning the traversal result to the client; and
the client returning the traversal result to a handler that handles the traversal result.
US10/201,544 2002-07-22 2002-07-22 Hypermedia management system Abandoned US20040015542A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US10/201,544 US20040015542A1 (en) 2002-07-22 2002-07-22 Hypermedia management system
US11/312,784 US7970867B2 (en) 2002-07-22 2005-12-20 Hypermedia management system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/201,544 US20040015542A1 (en) 2002-07-22 2002-07-22 Hypermedia management system

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/312,784 Division US7970867B2 (en) 2002-07-22 2005-12-20 Hypermedia management system

Publications (1)

Publication Number Publication Date
US20040015542A1 true US20040015542A1 (en) 2004-01-22

Family

ID=30443637

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/201,544 Abandoned US20040015542A1 (en) 2002-07-22 2002-07-22 Hypermedia management system
US11/312,784 Active 2024-11-01 US7970867B2 (en) 2002-07-22 2005-12-20 Hypermedia management system

Family Applications After (1)

Application Number Title Priority Date Filing Date
US11/312,784 Active 2024-11-01 US7970867B2 (en) 2002-07-22 2005-12-20 Hypermedia management system

Country Status (1)

Country Link
US (2) US20040015542A1 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050027677A1 (en) * 2003-07-31 2005-02-03 Alcatel Method, a hypermedia communication system, a hypermedia server, a hypermedia client, and computer software products for accessing, distributing, and presenting hypermedia documents
US20080301259A1 (en) * 2007-06-04 2008-12-04 Herbert Hackmann Method and system for accessing a business object by using a service provider class
US20090138844A1 (en) * 2007-11-26 2009-05-28 Benjamin Halberstadt Decorated Model Architecture for Efficient Model-Driven Application Development
US20090138436A1 (en) * 2007-11-26 2009-05-28 Benjamin Halberstadt Model Augmentation in a Model-Driven Application Development Environment
US20090217145A1 (en) * 2008-02-27 2009-08-27 Actionthis Limited Methods and devices for post processing rendered web pages and handling requests of post processed web pages

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8887045B2 (en) * 2008-06-11 2014-11-11 Caterpillar Inc. System and method for providing data links

Citations (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6003040A (en) * 1998-01-23 1999-12-14 Mital; Vijay Apparatus and method for storing, navigating among and adding links between data items in computer databases
US6211874B1 (en) * 1998-05-15 2001-04-03 International Business Machines Corporation Method for parallel selection of URL's
US6298476B1 (en) * 1995-12-04 2001-10-02 International Business Machines Corporation Object oriented software build framework mechanism
US6421675B1 (en) * 1998-03-16 2002-07-16 S. L. I. Systems, Inc. Search engine
US20020099738A1 (en) * 2000-11-22 2002-07-25 Grant Hugh Alexander Automated web access for back-end enterprise systems
US20020169759A1 (en) * 2001-05-14 2002-11-14 International Business Machines Corporation Method and apparatus for graphically formulating a search query and displaying result set
US20030004956A1 (en) * 2001-07-02 2003-01-02 Sun Microsystems, Inc. Methods and system for efficient association traversals
US20030046311A1 (en) * 2001-06-19 2003-03-06 Ryan Baidya Dynamic search engine and database
US20030097301A1 (en) * 2001-11-21 2003-05-22 Masahiro Kageyama Method for exchange information based on computer network
US20030105744A1 (en) * 2001-11-30 2003-06-05 Mckeeth Jim Method and system for updating a search engine
US20030126136A1 (en) * 2001-06-22 2003-07-03 Nosa Omoigui System and method for knowledge retrieval, management, delivery and presentation
US6606654B1 (en) * 2000-02-14 2003-08-12 Netjumper, Inc. Link delivery for subsequent retrieval of networked information
US20030187964A1 (en) * 2001-10-31 2003-10-02 The University Court Of The University Of Glasgow Method and system for updating data on an information appliance based on changes in local and remote data sources
US20030208493A1 (en) * 2002-04-12 2003-11-06 Hall Bradley S. Object relational database management system
US6674453B1 (en) * 2000-07-10 2004-01-06 Fuji Xerox Co., Ltd. Service portal for links separated from Web content
US6701321B1 (en) * 1996-12-04 2004-03-02 Daniel E. Tsai Method and apparatus for navigation of relational databases on distributed networks
US6721726B1 (en) * 2000-03-08 2004-04-13 Accenture Llp Knowledge management tool
US20050289120A9 (en) * 1999-05-28 2005-12-29 Goto.Com, Inc. System and method for influencing a position on a search result list generated by a computer network search engine
US7013303B2 (en) * 2001-05-04 2006-03-14 Sun Microsystems, Inc. System and method for multiple data sources to plug into a standardized interface for distributed deep search

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6044205A (en) * 1996-02-29 2000-03-28 Intermind Corporation Communications system for transferring information between memories according to processes transferred with the information
US6301581B1 (en) * 1994-08-01 2001-10-09 Texas Instruments Incorporated Method and system for managing access to a plurality of data objects
US5873093A (en) * 1994-12-07 1999-02-16 Next Software, Inc. Method and apparatus for mapping objects to a data source
KR0175264B1 (en) * 1996-08-21 1999-04-01 김광호 Monitor control device and control method of video communication system
US5995946A (en) * 1997-11-03 1999-11-30 Mci Communications Corporatioin System and method for establishing and managing links among customer accounts maintained within a telecommunications system
US6775674B1 (en) * 1998-03-26 2004-08-10 Sap Aktiengesellschaft Auto completion of relationships between objects in a data model
AU5460299A (en) * 1998-07-24 2000-02-14 Jarg Corporation Distributed computer database system and method for performing object search
US6501491B1 (en) * 1998-09-21 2002-12-31 Microsoft Corporation Extensible user interface for viewing objects over a network
US6772139B1 (en) * 1998-10-05 2004-08-03 Smith, Iii Julius O. Method and apparatus for facilitating use of hypertext links on the world wide web
US6405209B2 (en) * 1998-10-28 2002-06-11 Ncr Corporation Transparent object instantiation/initialization from a relational store
US6523035B1 (en) * 1999-05-20 2003-02-18 Bmc Software, Inc. System and method for integrating a plurality of disparate database utilities into a single graphical user interface
US7010742B1 (en) * 1999-09-22 2006-03-07 Siemens Corporate Research, Inc. Generalized system for automatically hyperlinking multimedia product documents
US6571232B1 (en) * 1999-11-01 2003-05-27 Sun Microsystems, Inc. System and method for browsing database schema information
US6591295B1 (en) * 1999-11-05 2003-07-08 Oracle International Corp. Methods and apparatus for using multimedia data stored in a relational database in web applications
US6418448B1 (en) * 1999-12-06 2002-07-09 Shyam Sundar Sarkar Method and apparatus for processing markup language specifications for data and metadata used inside multiple related internet documents to navigate, query and manipulate information from a plurality of object relational databases over the web

Patent Citations (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6298476B1 (en) * 1995-12-04 2001-10-02 International Business Machines Corporation Object oriented software build framework mechanism
US6701321B1 (en) * 1996-12-04 2004-03-02 Daniel E. Tsai Method and apparatus for navigation of relational databases on distributed networks
US6003040A (en) * 1998-01-23 1999-12-14 Mital; Vijay Apparatus and method for storing, navigating among and adding links between data items in computer databases
US6421675B1 (en) * 1998-03-16 2002-07-16 S. L. I. Systems, Inc. Search engine
US6211874B1 (en) * 1998-05-15 2001-04-03 International Business Machines Corporation Method for parallel selection of URL's
US20050289120A9 (en) * 1999-05-28 2005-12-29 Goto.Com, Inc. System and method for influencing a position on a search result list generated by a computer network search engine
US6606654B1 (en) * 2000-02-14 2003-08-12 Netjumper, Inc. Link delivery for subsequent retrieval of networked information
US6721726B1 (en) * 2000-03-08 2004-04-13 Accenture Llp Knowledge management tool
US6674453B1 (en) * 2000-07-10 2004-01-06 Fuji Xerox Co., Ltd. Service portal for links separated from Web content
US20020099738A1 (en) * 2000-11-22 2002-07-25 Grant Hugh Alexander Automated web access for back-end enterprise systems
US7013303B2 (en) * 2001-05-04 2006-03-14 Sun Microsystems, Inc. System and method for multiple data sources to plug into a standardized interface for distributed deep search
US20020169759A1 (en) * 2001-05-14 2002-11-14 International Business Machines Corporation Method and apparatus for graphically formulating a search query and displaying result set
US20030046311A1 (en) * 2001-06-19 2003-03-06 Ryan Baidya Dynamic search engine and database
US20030126136A1 (en) * 2001-06-22 2003-07-03 Nosa Omoigui System and method for knowledge retrieval, management, delivery and presentation
US20030004956A1 (en) * 2001-07-02 2003-01-02 Sun Microsystems, Inc. Methods and system for efficient association traversals
US20030187964A1 (en) * 2001-10-31 2003-10-02 The University Court Of The University Of Glasgow Method and system for updating data on an information appliance based on changes in local and remote data sources
US20030097301A1 (en) * 2001-11-21 2003-05-22 Masahiro Kageyama Method for exchange information based on computer network
US20030105744A1 (en) * 2001-11-30 2003-06-05 Mckeeth Jim Method and system for updating a search engine
US6763362B2 (en) * 2001-11-30 2004-07-13 Micron Technology, Inc. Method and system for updating a search engine
US20030208493A1 (en) * 2002-04-12 2003-11-06 Hall Bradley S. Object relational database management system

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7594164B2 (en) * 2003-07-31 2009-09-22 Alcatel Method, a hypermedia communication system, a hypermedia server, a hypermedia client, and computer software products for accessing, distributing, and presenting hypermedia documents
US20050027677A1 (en) * 2003-07-31 2005-02-03 Alcatel Method, a hypermedia communication system, a hypermedia server, a hypermedia client, and computer software products for accessing, distributing, and presenting hypermedia documents
US20080301259A1 (en) * 2007-06-04 2008-12-04 Herbert Hackmann Method and system for accessing a business object by using a service provider class
US8307015B2 (en) 2007-11-26 2012-11-06 International Business Machines Corporation Decorated model architecture for efficient model-driven application development
US20090138436A1 (en) * 2007-11-26 2009-05-28 Benjamin Halberstadt Model Augmentation in a Model-Driven Application Development Environment
US8095570B2 (en) * 2007-11-26 2012-01-10 International Business Machines Corporation Decorated model architecture for efficient model-driven application development
US20090138844A1 (en) * 2007-11-26 2009-05-28 Benjamin Halberstadt Decorated Model Architecture for Efficient Model-Driven Application Development
US8635253B2 (en) 2007-11-26 2014-01-21 International Business Machines Corporation Decorated model architecture for efficient model-driven application development
US8671121B2 (en) 2007-11-26 2014-03-11 International Business Machines Corporation Model augmentation in a model-driven application development environment
US9513879B2 (en) 2007-11-26 2016-12-06 International Business Machines Corporation Model augmentation in a model-driven application development environment
US10509632B2 (en) 2007-11-26 2019-12-17 International Business Machines Corporation Model augmentation in a model-driven application development environment
US20090217145A1 (en) * 2008-02-27 2009-08-27 Actionthis Limited Methods and devices for post processing rendered web pages and handling requests of post processed web pages
US20100077294A1 (en) * 2008-02-27 2010-03-25 Aptimize Limited Methods and devices for post processing rendered web pages and handling requests of post processed web pages
US7886218B2 (en) 2008-02-27 2011-02-08 Aptimize Limited Methods and devices for post processing rendered web pages and handling requests of post processed web pages

Also Published As

Publication number Publication date
US7970867B2 (en) 2011-06-28
US20060095513A1 (en) 2006-05-04

Similar Documents

Publication Publication Date Title
US7734657B2 (en) Containment hierarchy in a database system
US7634478B2 (en) Metadata driven intelligent data navigation
US7546226B1 (en) Architecture for automating analytical view of business applications
US7480661B2 (en) Query services for database system
US7165075B2 (en) Object graph faulting and trimming in an object-relational database system
US7599948B2 (en) Object relational mapping layer
US7613715B2 (en) Map and data location provider
US7412436B2 (en) System and interface for manipulating a database
JP5710851B2 (en) System and method for impact analysis
US7136873B2 (en) Dynamic filtering in a database system
US7359912B2 (en) Result set formatting and processing
US7275024B2 (en) Automatic generation of a dimensional model for business analytics from an object model for online transaction processing
US7552151B2 (en) System, method and program product for adding, updating and removing RDF statements stored on a server
EP1387297A2 (en) Translation of object property joins to relational database joins
EP1383056A2 (en) Querying an object-relational database system
EP1473640A2 (en) Automatic generation of a dimensional model for online analytical processing (OLAP) from an object model for online transaction processing (OLTP)
US8122044B2 (en) Generation of business intelligence entities from a dimensional model
US20080201330A1 (en) Software repositories
US7543004B2 (en) Efficient support for workspace-local queries in a repository that supports file versioning
US7426521B2 (en) Property and object validation in a database system
US7970867B2 (en) Hypermedia management system
US7769750B2 (en) Metadata based hypermedia management system

Legal Events

Date Code Title Description
AS Assignment

Owner name: MICROSOFT CORPORATION, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ANONSEN, STEVEN P.;HUCK, JASON A.;SEEFELDT, DANIEL E.;REEL/FRAME:013493/0788

Effective date: 20021018

STCB Information on status: application discontinuation

Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION

AS Assignment

Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034766/0001

Effective date: 20141014