[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Actors, Registration, and Enrollment
Thanks to Joshua and Bill for considerable time spent Thursday afternoon. Actor ID: An Actor gets a name from a naming authority and thereafter has an Actor ID. The recommended Actor ID is of the format URI/string – in which the URI is the naming authority, and the string is the name assigned by that authority. An MRID is a valid Actor ID. An EMS Software vendor could be a Naming Authority, with the string being the [license] assigned during registration. An Actor ID MUST be globally unique, with collisions managed by the naming authorities. How an Actor gets an Actor ID is out of scope. Registration: An Actor Registers with the Registrar for a market context and is assigned a Party ID. A Party ID is unique for interactions within that context. If a market rule declares that Party IDs must be valid across market contexts, that is the responsibility of the Registrar. Registration establishes the basic business participation in a context. Registration may require considerable out-of-band interactions, including perhaps bonding, proof of insurance, posting of letters of credit. It may be possible for an Actor to declare itself as a subsidiary of an existing Customer of the Registrar/Market Context, assuming the role of Customer makes sense in that Context. Because of this potential gap and out-of-band requirements, Registration has two parts: “EiRegistrationRequest”/ “EiRegistrationRequested” initiated by the Actor, and “EiRegistrationComplete”/”EiRegistrationCompleted” initiated by the Registrar. The Registrar may also send “EiRegistrationDenial”/” EiRegistrationDenied”. “EiRegistrationComplete” includes assignment of a PartyID for use in the context. The recommended Party ID is of the format URI/string – in which the URI is the registrar or market context and the string is the name assigned by the Registrar. An Actor may request assignment of an existing PartyID to itself. This covers the use case of upgraded or replaced software or equipment. An Actor may request simultaneous assignment of an Actor ID and of a PartyID. Enrollment A Party may enroll Resources. A party is responsible creating locally unique identities for each resource. A Globally unique Resource ID can be constructed from the Party Id and the Resource Id. A Party that wishes to Enroll a Resource must support the VEN interfaces. Such a Party (hereafter “VEN”) uses its VEN interfaces to Enroll. A VEN may have zero to many Resources. A VEN can enroll and unenroll each Resource. A Resource (as defined in EMIX) is something that the VEN chooses to expose to a VTN. For what reason, and in accord with what rules the VEN makes this decision is out of scope. A Party acting as a VEN can request a list of VTNs that it will interact with. The pattern is analogous to DNS Servers, in which the client has a Primary DNS server, and a list of Alternate DNS Servers. In an analogous way, a Registrar can inform a VEN of a primary and alternate VTNs. A Registrar MAY require out of band information before completing Resource Enrollment by a VEN. Because of this potential gap and out-of-band requirements, Enrollment has two parts: “EiEnrollmentRequest”/ “EiEnrollmentRequested” initiated by the Actor, and “EiEnrollmentComplete”/” EiEnrollmentCompleted” initiated by the Registrar. The Registrar may also send “EiEnrollmentDenial”/” EiEnrollmentDenied”. Resources and VENs. When we combine the above with the statements about Resources from the other day, we have: 1) A single VEN may register Zero to many resources. It can add new ones or remove old ones. 2) The set of Resources revealed to a particular partner (VTN) are solely those that the VEN wishes to offer. Whether a there is a one-to-one correspondence between any piece of equipment and a resource publication is entirely up to the VEN and what it wishes to advertise. 3) A VEN may display different resources to different Market Contexts. 4) A VEN MAY split its service offerings into multiple Resources because of different grid-relevant characteristics OR for characteristics relevant to its internal decision making and user interfaces (say floors of a commercial building), as meets the needs of the VEN 5) A Resource may have multiple end-points specified. Each of these is a WS Addressing Points 6) All end points of a Resource SHALL receive the same operational messages from the VTN. 7) One end point SHALL receive the Administrative interactions for the Resource. This end point MAY be the sole Operational End Point. 8) If the Party exposing a VEN surface to an external VTN, is itself exposing a VTN surface to manage its internal market, the external VTN cannot “drill down” to those internal VEN interfaces, except to the extent that the external VEN chooses to offer them as Resources. "If something is not worth doing, it`s not worth doing well"
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]