[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

482.0. "Bypassing Parental Supervision" by COOKIE::KITTELL (Richard - Architected Info Mgmt) Wed Nov 21 1990 13: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?
T.RTitleUserPersonal
Name
DateLines
482.1looks okGOSTE::CALLANDERMon Nov 26 1990 18:453
    I hope not, otherwise the mcc children are doing something wrong
    -- or I am misunderstanding your question.
    
482.2We have very strict parents around hereCAPN::SYLORArchitect = Buzzword GeneratorMon Nov 26 1990 19:3634
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
482.3Request pointer to white paper "Distributed Entities"GDJUNK::HOULESteve, OSI NM is OUR future!Wed Nov 28 1990 09:313
    Mark,
    A pointer to the white paper "Distributed Entities" please.
    Thanks, ===Steve
482.4COOKIE::KITTELLRichard - Architected Info MgmtWed Nov 28 1990 15:422
All the white papers are in FILES::EMA$:[Public]
482.5In FILES::EMA$:[Public]CAPN::SYLORArchitect = Buzzword GeneratorThu Nov 29 1990 01:054
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