Conference azur::mcc

482.0. "Bypassing Parental Supervision" by COOKIE::KITTELL (Richard - Architected Info Mgmt) Wed Nov 21 1990 10:25

        Suppose you have a main library and several branches. Unlike
        most libraries, there is only one copy of any book. The main
        library doesn't actually store any books, but only acts to
        coordinate the bar code IDs used to track the books: each
        branch is assigned one or more ranges of ID codes.

        Now, I want to model the main library as a global entity and the
        branches as children of the main library. I can find all the
        known branches by showing the children of the main library:

        MCC> SHOW MAIN LIBRARY tnsg BRANCH *

        I can issue directives to a branch:

        MCC> SHOW MAIN LIBRARY tnsg BRANCH aim BOOK *

        No sweat so far. Except for assignment of IDs when new books
        are brought into a branch, the branches don't communicate with
        the main library in their daily operations.

        I wrote that so I can ask this: can I issue management
        directives to a branch without going "through" the main
        library? I think the answer is yes, but I wonder whether I'm
        violating architectures and/or common sense in doing so.

        What I have in mind is that when a branch is created as a
        child of a main library, the branch is registered in DNS with
        a name of the form (for the above example)
        .MCC.BRANCHES.TNSG.AIM. Then the directive dispatch table is
        set so that directives with an entity spec of <mcc_entity,
        <MAIN_LIBRARY, *>, <BRANCH, *>> go to an entry point that does
        the lookup of the branch directly and sends the directive to it.

        Anything wrong with that?

    I hope not, otherwise the mcc children are doing something wrong
    -- or I am misunderstanding your question.
    

Yes, there is a reason why you *can't* do that

In your example, a branch is really a global entity as well as being a child
of a MAIN LIBRARY. Since no entity can be both, what you've done
(or what you'ld like to do) is "clone" an entity, i.e. present two classes
of entities, each of which has exactly the same set of operations. This isn't
prohibited, and has the same affect as what you want, but is described
in very different terms.

The difference comes (or could come) in the details of
the naming of the two entities. For the local case of a branch, what 
you'ld define is something like...

GLOBAL ENTITY Main Library = <TBD-A>:
	IDENTIFIER ATTRIBUTE Name = 1: FullName;
	...
    CHILD ENTITY Branch = 1:
	IDENTIFIER ATTRIBUTE Short Name = 1: SimpleName;
	...stuff...

For the global case you'ld define

GLOBAL ENTITY Branch = <TBD-B>:
	IDENTIFIER ATTRIBUTE Name = 1: FullName;
	...same stuff...

As of today, there's no automatic way of defining things so the operations
on the two entities are "the same". It will be easier with the next version
of EMA.

For examples of this sort of thing (and reasons why this is a good idea and 
why it is a bad idea) look in the White Paper on "Distributed Entities".

					Mark

    Mark,
    A pointer to the white paper "Distributed Entities" please.
    Thanks, ===Steve

All the white papers are in FILES::EMA$:[Public]

Start with README.FIRST.

At the very least you ought to get on the EMARG implementors list if
you are implementing anything to do with management