United States Patent
`Sudama et al.
`
`[19]
`
`[54] MECHANISM FOR LOCATING WITHOUT
`SEARCH DISCRETE APPLICATION
`RESOURCES KNOWN BY COMMON NAME
`ONLY IN A DISTRIBUTED NETWORK
`COMPUTING ENVIRONMENT
`
`[75]
`
`Inventors: Ram Sudama, Concord; David L.
`Magid, Worcester; Kenneth W.
`Ouellette, Groton, all of Mass.
`
`[73] Assignee: Digital Equipment Corporation,
`Maynard, Mass.
`
`[21] Appl. No. : 185, 617
`Jan. 24, 1994
`[22] Filed:
`[51] Int. Cl.
`[52] U. S. Cl. . . . . . . . . . . . . . . . . . . .
`[58] Field of Search
`
`G06F 17/30
`. . . . 395/600; 364/DIG. 1
`395/600
`
`[56]
`
`References Cited
`
`U. S. PATENT DOCUMENTS
`2/1987 Feigenbaun et al. . .
`4, 644, 470
`5/1994 Hendricks et al. . . . .
`5, 313, 646
`. . . . . . . . . . . .
`5, 377, 323 12/1994 Vasudevan
`
`. . . . 395/200. 02
`. . . . . . . . . 395/600
`. . . . 395/200. 16
`
`OTHER PUBLICATIONS
`
`Sato, "Network Directory Concept for an Intelligent Net-
`'89, IEEE Global Telecommunications
`work", Globecom
`Conference, 27 — 30 Nov. 1989.
`'The Global Directory — An Overview, " IEE Collo-
`Hodson,
`quium on 'The Global Directory' (Digest No. 67), 19 — Apr.
`1990, pp. 11-15.
`Kille, "Implementing The Directory", IEE Colloquium on
`'The Global Directory'
`(Digest No. 67), 19 Apr. 1990, pp.
`5/1-5/4.
`Rosenberry et al, Understanding DCE, O'Reilly & Associ-
`
`IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
`US005483652A
`[11] Patent Number:
`[45] Date of Patent:
`
`5, 483, 652
`Jan. 9, 1996
`
`IEEE
`
`ates, 1992, pp. 1 — 238.
`"Unclogging Distributed Computing",
`Hartman,
`Spectrum, May 1992, pp. 36 — 39.
`Orr et al, "Strange Bedfellows: Issues
`in Object Naming
`in Operating Systems 1993
`Under Unix", Object Orientation
`International Conference, 9 — 10 Dec. 1993, pp. 141 — 145.
`Primary Examiner — Thomas G. Black
`Assistant Examiner — Wayne Amsbury
`Attorney, Agent, or Firm — Kenneth F. Kozik
`ABSTRACT
`[57]
`
`the processing of a request
`Method and apparatus facilitating
`for a service, or for access to a
`from a client application
`resource, in a distributed computing environment. A shared
`is organized
`in such a manner
`that binding
`repository
`information, defining how a server is accessed, can be stored
`in the repository and accessed by multiple clients without
`their having knowledge of more than the common name for
`service, or the common name of a specific
`the requested
`resource for performing
`the service. The binding
`informa-
`tion for each server is stored in a server entry sub-hierarchy
`of the namespace
`in the shared repository, and the full names
`of server entries are stored in a service entry sub-hierarchy
`of the namespace and a resource entry sub-hierarchy of the
`namespace. When a client requests access to a service or to
`the server entry names are accessible
`a specific resource,
`from the service entry sub-hierarchy of the namespace or the
`resource entry sub-hierarchy of the namespace, using only
`common names for the service or resource. Once a server
`is retrieved
`entry name is obtained,
`information
`the binding
`for the client, and a logical connection can be established
`service or resource,
`the client and the requested
`between
`infor-
`to provide each client with detailed
`without having
`the location or name of the server binding
`mation about
`information.
`
`16 Claims, 6 Drawing Sheets
`
`/DOST5(DIN)
`
`/SERVICES (DHI)
`
`/DATABASE
`
`(DNI)
`
`/I'RIHT tDIR)
`
`/SERVICES IOIRI
`
`SERVER I
`
`SERVER5 tSERVER GDOUPI
`/. :/HOSTS/HOST
`0/SERVICES/PRINT/SERVER
`
`I
`
`/POINT(OIR)
`
`5ERVER 2 5ERVEHS(SERVER GROUP)
`/. :/HOSTS/HOST R/STIIY)CES/PRINT/SERVER
`
`2
`
`h
`/DATABASE IOIRI h SERVER ! SERVERS(5ERVER GROUP)
`
`/. :/HOSTS/DOS)M/SERVICES/PRINT/SERVEIL
`
`I
`
`SERVED 2 SERVERS(SERVER GROUPI
`/. :/HOSTS/DOST
`I/5). HVICES/DATABASE/SERVER
`
`2
`
`/. :(ROOT OIR)
`
`/APPLICATIOHS
`
`IDIRI
`
`SERVE)tS (SERVICE GROUP)
`/. :/BUSTS/HOST&/SERVICES/PRINT/SERVERS
`/. :/HOSTS/DOST&/SEHPICES/PRINT/SERVERS
`
`RESOUACE5(RESOURCE GROUP)
`/. :/APPLICATIONS/RESOURCES/PRINTERS/PRINTER
`/. :/APPLICATIOHS/RESOURCES/PHIHIERS/PRIHTEILE
`/. :/APPLICATIOHS/RESDURCE5/PRIIITERS/PRINTER
`
`I
`
`3
`
`5ERVERS (SERVICE GROUPI
`/. :/HOSTS/HOST&/SERVICES/DATABASE/SERVERS
`/. :/H05TS/DOST B/StHVICES/DATABASE/SERVERS
`
`RESOURCES(RESOURCE GROUP)
`/. :/APPLICATIONS/RESOURCES/OATABA5E5/DATABASE
`/. :/APPLICATIONS/REStlURCES/DATABASES/DATABASE
`
`I
`2
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1010 - Page 1
`
`

`

`US. Patent
`
`Jan. 9, 1996
`
`4 I
`
`I
`
`Sheet 1 of 6
`I
`
`I
`
`5,483,652
`I
`a
`
`10
`
`)
`~
`DIRECTORY SERVICE
`~
`~
`REPOSITORY
`
`18
`
`
`
`~
`
`~
`
`$
`
`~ 0
`
`e
`
`~
`
`g
`
`~
`
`e
`
`I
`
`
`
` RESOURCE
`
`12
`
`FIG.
`
`1
`
`~ ~
`(PRIOR ART)
`
`16
`
`g 1, ~
`
`HOST: A
`
`0
`SERVER:
`
`SERVER_1
`
`SERVER:
`
`S
`SERVER_1
`
` HOST: B
`
`
`~ ~
`PRINTER—1
`
`~ ~
`PRINTER_2
`
`PRINTER_3
`
`FIG. 3
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1010 - Page 2
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1010 - Page 2
`
`

`

`U. S. Patent
`
`Jan. 9, 1996
`
`Sheet 2 of 6
`
`5, 483, 652
`
`CC
`
`I z
`
`GC
`
`I
`
`)
`
`0
`
`U~
`
`gg
`
`I ) In ~O IZI
`
`In In Lb
`
`~ ~
`
`In N
`
`Ccl
`
`CC
`A
`
`Z
`
`0
`
`A
`
`Kl
`
`i
`A
`
`CC
`A
`
`U
`
`CC
`In
`
`O
`O
`
`CC
`A
`In
`In
`O
`
`CC
`
`I
`
`i
`O
`
`A
`
`I
`
`O
`
`CC
`
`g )
`
`OIn
`U g)
`
`I
`
`O
`CC ~
`In
`
`CC O
`
`i
`
`A
`
`g
`OIn
`U~
`~In
`~ In
`
`CC
`
`I
`
`I
`
`In Vl
`CC O
`)& ~ ~
`
`In N
`
`IX
`
`A
`
`i
`
`In
`
`CA
`
`i-
`A
`
`)
`
`CQ
`
`A
`In
`U
`
`LLl
`
`0
`
`I
`
`I
`
`U~
`IX
`~(n
`O
`(n ~
`In M CO
`CLl ~
`
`cn
`
`e ~
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1010 - Page 3
`
`

`

`U. S. Patent
`
`Jan. 9, 1996
`
`Sheet 3 of 6
`
`5, 483, 652
`
`41 V)
`CC K
`
`X GC
`M fA
`
`zz
`CC K
`0 0
`MM
`
`))
`
`I
`
`I
`
`~~ca
`)Ob
`~ Vl4h
`M Vl
`~OO
`
`IZI IZE
`
`~ 0
`
`~ ~
`
`A
`
`CL
`
`A
`
`rn z O
`
`O
`
`O
`
`IX
`M
`
`f
`
`f zzz
`
`0 0
`
`le N W
`
`i zzz
`CC X CC
`L C40
`Lh VI M
`OOOO
`0 CCCCCC
`OOOO
`M l/J
`C4 CC X
`cc 'z z z
`(/l 41
`O ~~~
`OOOO
`Mi
`i
`CCOOO
`~0 C40
`0 CL
`
`I
`
`O
`
`~ I ~ 0
`~
`~
`
`te
`~
`
`CC
`A
`
`Cl
`
`[/1 Cfl
`
`Lh 4h
`
`Cl Cl
`
`AA
`4h Vl
`OO
`
`C~~
`~wctu
`
`I
`
`I
`
`OO
`~ V) Ch
`4h Lh OO
`
`I
`
`f
`
`1 ~
`~
`
`~ ~
`
`~
`
`I
`I
`lh M
`ill CQ
`
`i
`
`i
`
`AA
`
`Vl M
`
`CCl Cl
`
`AA
`
`~OO
`0
`OOO
`K Vl V)
`UN&
`CC K
`cc z z
`DOO
`Lh i
`
`~0 oa a
`
`~ 1
`
`~ ~
`
`N~~
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1010 - Page 4
`
`

`

`U. S. Patent
`
`Jan. 9, 1996
`
`Sheet 4 of 6
`
`5, 483, 652
`
`CC
`
`f
`
`0
`
`~ Vl
`
`O
`
`gO
`
`R
`
`~ CCl
`O Vl
`
`I
`
`M Vl
`
`~ ~
`
`~ e
`
`CC
`0
`
`A
`
`R
`
`4
`
`zz
`CC K
`0
`Vl Vl
`
`X CC
`~VlVl
`~ K CQ
`+Vl Vl
`OOO
`
`I
`
`Vl Vl
`
`tl ~ 0
`
`~
`
`~
`
`0
`
`lX
`A
`
`C5
`
`i
`A
`
`1
`
`C5
`
`Vl
`
`I
`
`~ CC
`O
`~O
`
`WO
`Vl ~
`
`gQ
`
`~ ~
`e
`
`IX
`
`Cl
`
`A
`Vl
`
`Vl
`
`t
`
`O
`
`O
`
`CC
`
`Vl ~ f
`Vl ~
`
`gQ
`
`~ ~
`o
`
`A
`
`Vl
`
`O
`O
`
`Vl
`
`O
`Vl
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1010 - Page 5
`
`

`

`U. S. Patent
`
`Jan. 9, 1996
`
`Sheet 5 of 6
`
`5, 483, 652
`
`NAMESPACE
`
`SERVICE GROUP
`
`RESOURCE GROUP
`
`I
`I
`I
`I
`l
`I
`
`I
`
`I
`
`I
`
`MEMBER: SERVER GROUP
`MEMBER: SERVER GROUP
`
`MEMBER: RESOURCE ENTRY
`
`MEMBER: RESOURCE ENTRY
`
`SERVICE
`
`ID
`
`NO
`
`ID
`
`SERVER GROUP
`
`RESOURCE ENTRY
`
`MEMBER: SERVER ENTRY
`MEMBER: SERVER ENTRY
`
`MEMBER: SERVER ENTRY
`MEMBER: SERVER ENTRY
`
`SERVICE ID
`
`RESOURCE
`
`ID
`
`SERVER ENTRY
`
`C
`
`I
`
`)
`
`I
`
`BINDING
`
`INFORMATION
`
`INCLUDES SERVICE ID
`
`BINDING
`
`INFORMATION
`
`INCLUDES SERVICE ID
`
`I
`
`I
`
`J
`
`I
`
`SERVER ID
`
`FIG.
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1010 - Page 6
`
`

`

`U. S. Patent
`
`3an. 9, 1996
`
`Sheet 6 of 6
`
`5, 4S3, 652
`
`l . : /APPLICATIONS/SERVICES/PRINT/SERVERS
`SERVICE GROUP
`MEMBERS:
`/. :/HOSTS/HOST A/SERVICES/PRINT/SERVERS
`/. ;/HOSTS/HOST~/SERVICES/PRINT/SERVER
`SERVICE ID
`
`FIG. 5
`
`/. :/HOSTS/HOST A/SERVICES
`/PRINT/SERVERS
`
`SERVER GROUP
`MEMBERS:
`/. :/HOSTS/HOST A/SERVICES
`/PRINT/SERVER
`1
`SERVICE ID
`
`/. :/HOSTS/HOST~/SERVICES
`/PRINT/SERVERS
`
`SERVER GROUP
`MEMBERS:
`
`/. : /HOSTS/HOSTS/SERVICES
`/PRINT/SERVER
`SERVICE ID
`
`1
`
`l. :/HOSTS/HOST A/SERVICES/PRINT/SERVER
`
`1
`
`SERVER ENTRY
`INFORMATION WITH SERVICE ID
`BINDING
`SERVER ID
`
`/. :/HOSTS/HOST~/SERVICES/PRINT/SERVER
`SERVER ENTRY
`INFORMATION WITH SERVICE ID
`BINDING
`SERVER ID
`
`1
`
`/. : /APPLICATIONS/RESOURCES/PRINTERS/PRINTER
`RESOURCE ENTRY
`MEMBERS:
`/. :/HOSTS/HOST~/SERVICES/PRINT/SERVER
`RESOURCE
`ID
`
`1
`
`1
`
`/. :/APPLICATIONS/RESOURCES/PRINTERS/PRINTER
`
`2
`
`RESOURCE ENTRY
`MEMBERS:
`/. ;/HOSTS/HOST~/SERVICES/PRINT/SERVER
`ID
`RESOURCE
`
`1
`
`/. :/APPLICATIONS/SERVICES
`/PRINT/RESOURCES
`
`RESOURCE GROUP
`MEMBERS:
`/. :/APPLICATIONS/RESOURCES
`/PRINTERS/PRINTER
`/. :/APPLICATIONS/RESOURCES
`2
`/PRINTERS/PRINTER
`/. :/APPLICATIONS/RESOURCES
`3
`/PRINTERS/PRINTER
`
`1
`
`/. :/APPLICATIONS/RESOURCES/PRINTERS/PRINTER
`RESOURCE ENTRY
`MEMBERS:
`
`l. :/HOSTS/HOST A/SERVICES/PRINT/SERVER
`/. . /HOSTS/HOST~/SERVICES/PRINT/SERVER
`
`1
`1 i
`
`RESOURCE
`
`ID
`
`3
`
`NO
`
`ID
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1010 - Page 7
`
`

`

`5, 483, 652
`
`1
`MECHANISM FOR LOCATING WITHOUT
`SEARCH DISCRETE APPLICATION
`RESOURCES KNOWN BY COMMON NAME
`ONLY IN A DISTRIBUTED NETWORK
`COMPUTING ENVIRONtVIENT
`
`BACKGROUND OF THE INVENTIOiN
`
`that facili-
`This invention
`to techniques
`relates generally
`tate sharing of resources
`in computer networks. More par-
`to a distributed
`relates
`the invention
`ticularly,
`computing
`resources
`environment
`are
`in which multiple
`computer
`a
`interconnected
`and are
`distributed
`physically
`through
`network, or multiple networks. Further,
`the resources are
`accessed by multiple application "clients, " which are also, in
`
`the network.
`general, distributed
`through
`to grow in both size and
`Computer networks continue
`complexity. The principal reason for connecting computers
`to networks, and connecting networks
`to other networks,
`is
`to enable computers
`to work
`together efficiently, and to
`simplify sharing of resources. Shared resources include files,
`(in the form of computer
`applications
`software), printers,
`and special computers.
`Examples of distributed applications
`include an electronic
`service, a distributed printing
`service, and a
`conferencing
`service. Each of these
`calendar management
`distributed
`a set of resources. In a typical dis-
`applications maintains
`entities known as "serv-
`tributed computing
`environment,
`ers" manage access to the shared resources, and entities
`as "clients" seek access
`the resources. For
`to
`known
`example, 'the resources of an electronic conferencing service
`conferences, or "bulletin boards, " that
`are the individual
`users access. The resources of a distributed printing service
`are the actual printers. The resources of a distributed calen-
`service are the individual
`calendar data-
`dar management
`bases.
`Users of applications
`seek access to specific
`frequently
`resources rather than to application
`resources at large. For
`example, a user of an application
`that prints will typically
`seek access to a specific printer rather than to any printer.
`Similarly, a user will commonly want to access a specific
`conference in a distributed conferencing application, and to
`in a distributed
`a specific database
`calendar management
`there can be a potentially
`In large networks,
`application.
`large number of application
`servers for each service, and a
`even larger number of application resources
`correspondingly
`these servers. Therefore, client applica-
`distributed
`among
`tions require a consistent means for locating application
`resources on behalf of users. Unfortunately,
`there has been
`in the naming and location of
`no consistency or uniformity
`servers and resources.
`application
`location of a distributed
`In the past,
`the
`application
`resource had to be fully specified by the user each time the
`resource was accessed. For example, a user seeking network
`access to a remote file would have to specify a host system
`name or address where the file was located, and a complete
`"path" between the user and the file server managing access
`to
`to the file. Some distributed
`have
`tried
`applications
`location information
`improve on this approach by providing
`that is specific to a particular application. For example, a
`user need then only specify an application-specific "alias" to
`refer to a remote file. The alias name would be translated by
`the application client system into the required file name and
`the user of the burden of
`location
`information,
`relieving
`having to remember all the specifics of addressing
`required
`the use of aliases
`to access each resource. However,
`is
`
`time a new resource
`to manage because every
`difficult
`is
`created, or the location of an existing resource is changed,
`this information has to be communicated
`in some way to
`every client system, for updating
`tables.
`translation
`Distributed name services have been developed
`to help
`with the problem of accessing remote services. These ser-
`access to a common database,
`vices provide network-wide
`in which location information can be stored, and shared by
`all clients. Unfortunately,
`these directory
`services simply
`provide a repository
`for information,
`and do not prescribe
`how applications should use the repository. Each application
`the "namespace"
`for utilizing
`devises
`its own mechanism
`that defines the names and locations of servers and resources
`in such a way
`that clients can locate
`them as needed.
`Creating
`these mechanisms
`complicates
`the design
`and
`of distributed
`and also com-
`implementation
`applications,
`of the distributed
`plicates
`the management
`environment,
`since there may be a large number of difTerent, and poten-
`tially conflicting, uses of the distributed namespace.
`Many of the difficulties of distributed computing,
`includ-
`ing the difficulty of locating shared resources, have been
`addressed by a software system known as Distributed Com-
`(DCE), promulgated by the Open Soft-
`puting Environment
`ware Foundation (OSF). The scope, objectives, and function
`of DCE are concisely explained
`in a book entitled "Under-
`standing DCE, " by Ward Rosenberry
`et al. , published
`in
`1992 by O'Reilly 8z Associates, Sebastopol, Calif. 95472.
`DCE provides a distributed directory service consisting of
`a shared
`an associated
`hierarchical
`repository
`having
`namespace. The DCE standard provides a minimal structure
`for the purpose of distinguishing
`to the namespace
`the
`addresses of, and management
`information associated with,
`It also provides primitive
`in the network.
`multiple hosts
`operations for creating and managing
`individual elements
`in
`the namespace, such as directories, server entries and several
`types of group entries. However,
`it does not provide any
`that would aid in the common manage-
`additional
`structure
`ment of application
`services, servers or resources.
`In short, although DCE provides a hierarchical
`structure
`for naming and locating "objects" that contain information
`about servers, it provides no guidance as to how the structure
`might be used to avoid potential conflict between names, or
`from a user standpoint. The
`to simplify
`resource sharing
`is directed to these ends.
`invention
`present
`
`SUMMARY OF THE INVENTION
`
`The present
`in a method and related
`resides
`invention
`for use in a distributed computing environment,
`apparatus,
`for transferring
`information between a server entity and a
`in such a manner as to avoid conflicts and to
`client entity
`to request access to a service or
`the client entity
`permit
`resource without knowledge of any more than a common
`name for the service or resource. For example, a common
`name for a printing service might be "print" and a common
`name for a particular printing
`resource might be "printer
`t 'I
`
`In general
`to be a
`the invention may considered
`terms,
`method for structuring a hierarchical namespace accessible
`in a distributed
`host systems
`from multiple
`computing
`the steps of defining a
`environment. The method comprises
`host sub-hierarchy containing for each host, and each service
`provided by the host, a list of storage locations to be used by
`for storing
`server applications
`information
`to
`pertaining
`respective
`the service; and defining a
`servers performing
`for each service available
`service sub-hierarchy
`containing
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1010 - Page 8
`
`

`

`5, 483, 652
`
`5
`
`35
`
`a list of the same
`in the distributed computing environment
`storage locations defined in the host sub-hierarchy. With this
`structure, a client application can access the service sub-
`hierarchy using a common name of a desired service, and
`can thereby obtain
`from a server application
`information
`without knowledge of more than the common name of the
`service.
`the steps of defin-
`The method preferably also comprises
`ing a resource sub-hierarchy
`for each service
`containing
`in the distributed computing environment a list of to
`available
`resources available
`through each service; and defining for
`each resource a list of the same storage locations defined in
`the host sub-hierarchy. A client application can then access
`using a common name of a
`the resource
`sub-hierarchy
`from a t5
`desired resource, and can thereby obtain information
`server application without knowledge of more
`the
`than
`common name of the resource.
`the steps of
`In more specific terms the method comprises
`from a server to a server entry in a
`information
`exporting
`the server entry being accessed by a "full
`shared repository,
`name, " i. e. a name that completely
`identifies
`the server by
`host name and server name; and storing in a service entry of
`the full name of the server entry used
`the shared repository
`in the exporting step. The service entry
`is accessed by a
`name that includes a common name for the service provided
`by the server, and the service entry itself contains
`the full
`name of the server entry. The method further
`includes
`the
`step of importing
`into a client
`the exported
`information
`the common name of the service. The
`entity, using only
`the service entry to obtain
`importing step includes retrieving
`the full name of the server entry, then retrieving
`the server
`entry before importing
`the information.
`Even more specifically,
`the importing
`step also includes
`the full name of the service entry
`from
`generating
`the
`common name of the service, prior to retrieving
`the service
`entry to obtain the full name of the server entry.
`The same principles are used to handle a request from a
`client for a specific resource, rather
`than for a service in
`general. In this case, the method includes storing in at least 4o
`one resource entry of the shared repository
`the full name of
`the server entry used in the exporting step. Each resource
`entry is accessed by a name that includes a common name
`for the resource accessed by the server, and each resource
`the full names of all server entities
`entry contains
`through
`the resource can be accessed. The importing
`which
`step
`the common name of the resource,
`requires
`only
`and
`includes
`the resource entry
`to obtain
`retrieving
`the full
`names of all server entries associated with the resource, then
`selecting one of the server entries and retrieving
`the server 5o
`entry before importing
`the information.
`The method of the invention may also be defined as
`utilizing a shared hierarchical
`to facilitate
`storage structure
`passing of information
`from a server entity to a client entity
`in a distributed computing environment. The method corn- 55
`prises the steps of defining
`the shared storage structure
`to
`of the namespace
`include a server entry
`sub-hierarchy
`accessible by host name and server name, a service entry
`sub-hierarchy of the namespace accessible by service com-
`of the 6o
`and a resource entry
`mon name,
`sub-hierarchy
`accessible
`service
`namespace
`common
`name
`and
`by
`resource common name. The method further
`includes, for
`each server entity, storing binding
`in the server
`information
`entry sub-hierarchy of the namespace,
`to define how
`to
`access the server entity; for each service, storing
`in the 65
`service entry sub-hierarchy of the namespace a full name for
`the service; and for each resource,
`each server providing
`
`45
`
`storing in the resource entry sub-hierarchy of the namespace
`a full name for each server providing access to the resource.
`Then the method performs the steps of requesting,
`in a client
`entity, access to a desired service or resource, using only a
`common name; retrieving an appropriate
`server entry name
`from the service entry sub-hierarchy of the namespace,
`if
`access to a service has been requested;
`retrieving an appro-
`from
`server entry name
`the resource entry
`sub-
`priate
`hierarchy of the namespace, if access to a particular resource
`has been requested;
`server entry
`the retrieved
`and using
`name to retrieve binding
`information
`from the server entry
`sub-hierarchy of the namespace.
`each of the steps of retrieving
`More specifically,
`an
`server entry name
`a full
`includes generating
`appropriate
`name from the common name supplied
`in the requesting
`step; using the full name to retrieve at least one server entry
`name to fulfill the request; and selecting from the retrieved
`server entry names one that will be used
`to satisfy
`the
`request.
`The invention may also be defined in terms of apparatus
`of approximately
`equivalent scope to the methods described
`above. For example,
`the invention may be defined as appa-
`a shared hierarchical
`ratus utilizing
`to
`storage structure
`facilitate passing of information
`to a
`from a server entity
`in a distributed
`client entity
`environment. The
`computing
`comprises a shared storage structure,
`apparatus
`including
`means for defining
`to include a
`the shared storage structure
`server entry sub-hierarchy of the namespace accessible by
`host name and server name, a service entry sub-hierarchy of
`the namespace accessible by service common name, and a
`resource entry sub-hierarchy of the namespace accessible by
`service common name and resource common name. The
`further
`includes means for storing binding
`infor-
`apparatus
`for each server entity,
`mation,
`in the server entry
`sub-
`hierarchy of the namespace,
`to define how to access each
`server entity; means for storing
`in the service entry sub-
`hierarchy of the namespace, for each service, a full name for
`each server providing
`the service; and means for storing in
`the resource entry sub-hierarchy of the namespace, for each
`resource, a full name for each server providing access to the
`resource. The apparatus
`further includes means for request-
`ing, in a client entity, access to a desired service or resource,
`using only a common name; means for retrieving an appro-
`priate server entry name from the service entry sub-hierar-
`if access to a service has been
`chy of the namespace,
`requested; means for retrieving an appropriate
`server entry
`of
`resource
`from
`name
`the
`sub-hierarchy
`entry
`the
`if access to a particular
`resource has been
`namespace,
`requested; and means for using
`the retrieved server entry
`name to retrieve binding
`information
`from the server entry
`sub-hierarchy of the namespace.
`It will be appreciated
`from the foregoing that the present
`represents a significant advance in techniques
`for
`invention
`in a distributed
`sharing resources
`computing environment.
`In particular, a procedure
`is prescribed for servers to export
`in such a way that there will be no
`information
`binding
`in the use of shared space, and binding
`naming conflicts
`information may be conveniently
`retrieved and imported by
`multiple clients with knowledge of only the common names
`of the requested services and resources. Other aspects and
`advantages of the invention will become apparent
`from the
`following more detailed description,
`considered
`together
`with the drawings.
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1010 - Page 9
`
`

`

`iden-
`
`5, 483, 652
`
`showing
`
`the relationship
`
`5
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. I is a block diagram
`between a client and a server;
`FIGS. 2A, 2B and 2C together comprise a diagram
`showing an example of a hierarchical namespace used in
`accordance with the invention;
`FIG. 3 is a block diagram showing
`the logical relationship
`between a print service managed by two servers and three
`print resources comprising
`three different printer
`types;
`FIG. 4 is a block diagram of a namespace
`in generalized
`type (server, server group, ser-
`form, including each entry
`vice group, resource and resource group) and the indicating
`the data stored in each; and
`FIG. 5 is a block diagram of a namespace
`including
`entries for a print service, print servers and print resources,
`the relationships between these entries, as well
`and showing
`(UUIDs) stored with
`identifiers
`as the universally
`unique
`each entry.
`
`DESCRIPTION OF THE PREFERRED
`EMBODIMENT
`
`As shown in the drawings for purposes of illustration,
`the
`for facili-
`is concerned with a technique
`invention
`present
`tating sharing of resources
`in a distributed computing envi-
`ronment. Prior to this invention, available distributed direc-
`in naming
`tory services have permitted complete flexibility
`that defines how to access
`and locating server information
`resources. It would be helpful
`to have a basic
`computer
`of a software system known as Distributed
`understanding
`(DCE), promulgated by the Open
`Computing Environment
`to a detailed
`(OSF), before
`Software Foundation
`turning
`description of the present invention. DCE was developed
`in
`an effort to improve a number of problematic
`aspects of
`one of which
`is the difficulty of
`distributed
`computing,
`in the distributed environment.
`locating resources
`The following are definitions of some of the terms used in
`this specification:
`such as a mainframe
`A host is a computing
`system,
`computer or a desktop personal computer.
`is a set of hosts,
`interconnected
`A network
`by some
`physical and logical communications
`infrastructure.
`A user is a human user of the network environment.
`is a collection of well-defined procedures
`An interface
`that can be invoked remotely.
`and/or functions
`A service is a unique collection of well-defined
`interfaces.
`A service interface is an interface in the service not used
`in any other service.
`of a service. Each
`is an implementation
`An application
`is composed of a client component and a server
`application
`component.
`is the component of an
`A client or client application
`functions of a
`invokes procedures
`that
`application
`and
`the term client may be used to refer to
`service. Sometimes
`the system or host on which
`the client application
`is
`executed, or to a human user of the client application.
`is the component of an
`A server or server application
`that implements and executes the procedures and
`application
`functions of a service in response to client requests. The term
`server by itself may also be used to refer to the system or
`is executed.
`host on which the server application
`A server instance refers to an individual copy of a server
`executing on a host.
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`entry
`
`that
`
`is the
`A resource
`is an application-specific
`that
`entity
`object of functions performed by a server. For example, a
`is the resource of a printing
`service. A file is the
`printer
`resource of a file service.
`A service is a replicated service if more than one server of
`the service runs on the network.
`A replicated resource is one that is the object of more than
`one server.
`A UUID is a universally unique machine-readable
`tifier.
`An interface ID is a UUID for an interface.
`A service ID is a UUID for a service interface.
`A server ID is a UUID for a server instance.
`A resource ID is a UUID for a resource.
`is part of a namespace
`entry. It
`An object attribute
`contains an ID which can be a service, server or resource ID.
`Binding information contains locations of servers. It also
`the interfaces
`that a server supports.
`contains
`is part of a namespace
`A server attribute
`information.
`contains binding
`Locations of servers
`information may be
`in binding
`incomplete. Part of the location is the location of a server on
`a host. DCE provides an extension to the global namespace
`on each host, known as the endpoint mapper, which provides
`the locations of servers keyed by interface and optional
`UUID.
`is a machine-readable
`entity which contains
`A binding
`and, optionally, a UUID. The
`server location
`information
`UUID on a binding is available to a server when a client uses
`it to make a remote procedure call. If the binding
`location
`in the namespace from which the a binding was
`information
`created was not complete, the binding's server location will
`not be complete either. A binding's
`location information can
`the endpoint mapper on a par-
`be completed by accessing
`ticular host.
`should be
`Given
`these component
`definitions, which
`to be discussed, one can
`further clarified from examples
`using a basic client-
`construct a distributed
`environment
`server relationship. However, a client application wishing to
`access a selected resource managed by a server application
`must have specific knowledge of the name and location of
`the server application. Since there may be a large number of
`server applications associated with a particular service, and
`an even larger number of application
`resources distributed
`locating
`the server applications,
`an appropriate
`among
`server application by name and location is often extremely
`difficult. The difficulty has been reduced, to some degree, by
`the provision of directory services, such as the cell directory
`service (CDS) and global directory service (GDS) provided
`services of this
`by DCE. Directory
`type have a shared
`repository with a hierarchical namespace,
`that is to say there
`is a standardized way of naming directories
`that make up the
`repository means a
`repository. The
`term shared
`shared
`structure that is accessible from any host in the network. The
`a single
`is
`shared
`storage
`repository
`logically
`entity,
`it may be located in more than one
`in practice
`although
`physical location. Entries (i. e. information) may be stored in
`the shared repository by one host and retrieved by another.
`In the context of the client-server
`a server
`relationship,
`in the shared reposi-
`application stores binding
`information
`tory provided by CDS, and a client application may retrieve
`for use in calling
`to
`information,
`the server
`the binding
`access a resource. A server application
`storing binding
`is said to be exporting binding
`in the repository
`information
`and a client application
`information,
`retrieving
`binding
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1010 - Page 10
`
`

`

`5, 483, 652
`
`information
`is said to be importing binding
`information.
`Although directory services, such as the CDS of DCE,
`provide a basic mechanism
`for establishing
`connection
`between a client application and a server application,
`they
`provide no guidance at all as to how the mechanism
`should
`the CDS namespace
`be used. Even though
`is a hierarchical
`a server application may
`someone designing
`structure,
`choose any name at all for the server, and place it in any
`desired level or location in the structure. A client application
`to locate a specific service, such as a print service,
`wishing
`must have knowledge of how the namespace hierarchical
`structure has been used by the server applications. The
`design philosophy of the CDS hierarchical
`structure pro-
`flexibility of design
`vides complete
`to servers and clients
`to allow designers of server
`alike. The goal was apparently
`and client applications
`to devise a naming
`and resource-
`locating scheme that best meets their needs. Unfortunately,
`is of little help
`this approach
`in extremely
`large network
`configurations, where literally hundreds of servers and cli-
`ents may be seeking to establish communication,
`and not all
`of them are within
`the control of a single designer or
`network administrator. Clearly, a simpler approach is needed
`to permit clients to locate appropriate
`resources and efi'ect a
`logical connection between a client application
`and an
`server application.
`appropriate
`The present
`specifies the information a server
`invention
`to the namespace
`and how a client establishes a
`exports
`connection
`to the server using this binding
`In
`information.
`aspect of the invention,
`accordance with an important
`a
`(such as the CDS namespace)
`directory service namespace
`is configured
`in such a manner
`that a service can be more
`easily selected by a client application, using only a common
`name for the service, such as "print" for a printing service,
`and a particular