Component Services

don't really know at this point!

component services idea 1

identify common features used across systems

component services idea 2

abstract common patterns of interaction

common services

naming, trading (less frequent but very useful), event and notification

uncommon services

relationship and property only found in very large systems. concurrency and security

naming

maps names to endpoints, urls, object references or whatever the middleware uses internally

options for a client finding names of servers

hardwire into code, write into config file, ask the user to enter, query another component, etc

how does naming as a service support the goals of system thinking 1

maintainable - change the component names in one place, change all clients uniformly

how does naming as a service support the goals of system thinking 2

scalable - a single namer can support many clients so the number can grow slowly

how does naming as a service support the goals of system thinking 3

extensible - if we can support the location of 2 components, we can support lots

naming service decision 1

what do names look like?

naming service decision 2

what can we name?

naming service decision 3

how can we add names to the service/ bind to named components?

naming service decision 4

how are missing/ duplicated names handled?

options for implementing naming system

file, in-memory hash table, database

hierarchical namespace issue 1

how to represent and resolve compound names

hierarchical namespace issue 2

how to represent the nested namespaces

creating nested namespace option 1

provide a method for creating nested namespaces and bind them in the current namespace

creating nested namespace option 2

provide a factory to create new simple namespaces

creating nested namespace option 3

allow namespaces to be bound to others without saying how they arise at all