14: Component Services

Question 1

what is a naming systrem? why is it important?

Answer 1

● A naming service maps a (compound) name to
a component endpoint
● Human-readable, meaningful
● Change the bindings of names to components over
time, aids maintenance and scaling
● Name server is just a component, that can be
named itself to produce hierarchy
A naming service Maps names to endpoints, URLs,
object references or whatever the middleware uses internally
The only approach that supports the goals of
systems thinking is a naming service
● Maintainable: change the component names in one
place, change all clients uniformly
● Scalable: a single namer can support many clients,
so the number can grow slowly
● Extensible: if we can support the location of two
components, we can support lots

Question 2

how is a naming service found?

Answer 2

We obviously can’t look-up the naming service
in the naming service
●
“Bootstrapping” the clients
● So we need some more primitive mechanism
● Typically a configuration file
● …but this is the only piece of magic in the system
● After this, every other component
can be found in a structured way
● A necessary evil

Question 3

what is a Simple or flat namespace? and Hierarchical?

Answer 3

● Simple or flat: all names “at the same level”
● Hierarchical: nested names, or names that name
further namespaces
The Unix file system is an example of a
hierarchical namespace, with names seperated by “/”
No duplicate names within a namespace
● Namespaces are named objects in their own right

Question 4

what are the limitations of naming? whats the alternative>

Answer 4

Naming works when you know whom you want
● i.e. Looking up your friend's number
● What if you only know what you
want?
● i.e. Looking up a plumber
● This is a fundamentally different problem
A set of properties that identify a service, rather than
a concrete identity for it
● May be multiple “correct” choices
trading service

Question 5

what is a property?

Answer 5

A property is just a named value that relates to
some feature of a component
● Generally (but not necessarily) client-visible
Classic example is the properties that define a
printing component
● Colour depth (1-, 8, 24-bit)
● Resolution (30, 300 DPI)
● Paper types (photo, plain)
● Process (laser, thermal, movable type)

Question 6

how do we decide which component to use that satisfies the properties we’ve serach?

Answer 6

A partial specification of a component
● Required properties: component
must have in order to be acceptable
● Desired properties: a component
is more desirable if it has them
● May allow different ways to
specify the property constraints
● Several possible approaches to this
● Provide a list of all appropriate components to each
possible client in a configuration file
● Broadcast to all components asking whether they
meet the specification, choose from the set that say
“yes”
● Convert each request into a name and use a naming
service to find the best component
● Use a specialised service that’s designed to match
properties on components

Question 7

what is a trading service?

Answer 7

A trading service maps property-based queries
to one or more components
Locate a component by its features
● Find “best plus alternatives”
● Can't necessarily guarantee the existence of a
component that satisfies any request
Bring together a set of components
● Allow clients to request a component
with a particular set of (required and
desired) properties
Benefits
● Single point of control and evolution
● Can make the query language richer more easily
● Collects together “equivalent” components for
substitution
less traversal of trees etc

Question 8

A query may result in no satisfactory

components: what then?

Answer 8

Leave it to the designer: component-writers must
defend against a lack of appropriate components
● Return the best we have: might not meet the
requirements, but better than nothing
● Programming tactics: start strong and work back,
degrade functionality gracefully