Draft text on resource/ven multiplicity - from EITC meeting November 2

Here's a rough draft. This may well belong in section 3.
Different business structures will typically drive different
technical deployments.
First, an actor, representing application code, may take on the
Virtual End Node (VEN) role. The same application code may also
support the Virtual Top Node (VTN) role. This is how the graph of
VTNs and VENs in Figure 3-5 is constructed.  In that figure, actor G
implements the role of VEN with respect to actor ;B, and the role of
VTN with respect to actors I, J, and L.
A Party interacts in transactive environments; the distinction is
that a market may have many relationships. While it might seem
attractive to make the actor that interacts with a market take on
the VEN role (with the market taking on the VTN role), this is too
restrictive. We can determine, view, and transact regardless of the
VEN/VTN relationships that we have--and so the transactive
interfaces use Party and CounterParty.
Continuing with the VTN/VEN relationship, in a deployment one must
make decisions about how the roles are selected, discovered, or
assigned; this is out of scope of this specification.
in contrast, a Resource is a thing, rather than an actor. A resource
does not participate in relationships such as the actor/application
interfaces in the figure.
It would be easy to require that a Resource is related to (or
possibly  managed by ) exactly one actor.  That actor must be a VEN
in the Energy Interoperation architecture. This would allow
requests, reports, and other interactions to and from a single VEN
which is uniquely related to that Resource.
But other business cases would be simpler with potentially many
Resources to a single VEN. In a transactive environment, that VEN
may offer capabilities of its Resources to a market (as a Party),
and without requiring a fine structure of collaborating VENs and
VTNs.
For example, a distributed application conforming to this
specification MIGHT deploy in one of the following ways;
(a) assign a single actor presenting the VEN role to each floor of a
building, and a VTN related to them. For external interactions, that
VTN for the building would present the VEN interface to receive and
interact with the Energy Interoperation Services, and could present
the Party role to tender, buy, and sell in a market,
(b) assign a single actor presenting the VEN role to the building
controller, and use other services to manage or convey information
to the floor controllers
(c) assign a single actor presenting the VEN role at the building
controller, have that same actor present the VTN role to the
individual floor controllers. The floor controllers present the VEN
role to the building controller, while presenting the VTN role to
its devices, each of which presents the VEN role to the floor
controller.
Clearly there are many deployments possible, including many not
described here.
Were we to require exactly one Resource to one VEN, these
deployments would not be possible. Therefore, we make no requirement
that a Resource be related to exactly one VEN, as this would make
realistic deployments unnecessarily complex.
ANOTHER SECTION - on roles
An application finds, discovers, or is configured to use a
particular Registrar. By using the EiREgisterParty service, that
application obtains a PartyID.
With that PartyID, the application can implement and interact using
the Party Role in the Transactive Services.
One thing that a Party may do is Enroll. The application may, when
it has a PartyID and is identified, Enroll. There are a number of
Enrollee Types, reflecting different business roles and enrollments,
which are out of scope for this specification--only the names are
defined, except in the case of a Resource which extends the emix
Resource Description Type.
The information required for Enrollment varies across Enroll
Administrators--for example in North American wholesale markets on
ISO will likely require different information or documentation than
another. Since that information is out of scope, a deployment or
profile would specify what information is required, and convey that
information in an extension of the Enrollee types.
Once Enrolled, a Party may have other capabilities, the definition
and description of which is also out of scope.  The service
operations supported are listed in SECTION FOR EiENROLL SERVICE.
The operations for Party Registration and Enrollment are designed,
as are all other operations and data types, to be both extensible
(with conventions described in SECTIONXXX) and evolvable over time
to add new or extended functionality to future versions of Energy
Interoperation, or by extension of information definitions in
specific profiles.
(FOOTNOTE? A series of brief Technical Notes is planned that will
explain the process of defining profiles)
Thanks!
bill

--
William Cox
Email:  
Web:  http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax