Management of Event Domains Avatar
  1. OMG Specification

Management of Event Domains — Open Issues

  • Acronym: MED
  • Issues Count: 3
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

idl for the DiamondCreationForbidden

  • Key: MED-2
  • Legacy Issue Number: 5469
  • Status: open  
  • Source: Prismtechnologies ( Alison Maclean)
  • Summary:

    The idl for the DiamondCreationForbidden is as follows:

    exception DiamondCreationForbidden

    { Diamond diamond }

    ;

    It should be

    exception DiamondCreationForbidden

    { DiamondSeq diam }

    ;

  • Reported: MED 1.0 — Tue, 9 Jul 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

EventDomain::get_diamonds/0

  • Key: MED-3
  • Legacy Issue Number: 5485
  • Status: open  
  • Source: Ericsson ( Niclas Eklund)
  • Summary:

    The operation get_diamonds/0, CosEventDomainAdmin::EventDomain, seems to
    be incorrectly described (page 2-10):

    "The get_diamonds operation is invoked to retrieve a list of diamonds
    that exist within any topology of channels formed by connections that were
    established between these channels by the target domain. The operation
    accepts no input parameters, and returns as a result a sequence of
    diamonds, whereas each diamond is itself a sequence of member identifiers
    of channels within the domain that are involved in the diamond."

    The IDL-file contains the following the typedefs:
    ... CUT ...
    typedef MemberIDSeq Route;
    typedef sequence<Route> RouteSeq;

    typedef Route Cycle;
    typedef sequence<Cycle> CycleSeq;

    typedef RouteSeq Diamond;
    typedef sequence<Diamond> DiamondSeq;
    .. CUT ..

    The problem is:

    "... each diamond is itself a sequence of member identifiers ..."

    which contradicts:
    ...
    typedef RouteSeq Diamond;
    ...

    To solve this problem it should be sufficient to change the last sentence
    to something like:

    "The operation accepts no input parameters, and returns as a result a
    sequence of diamonds, whereas each diamond is itself a sequence of paths,
    each path being a sequence of channel member identifiers, that are
    involved in the diamond

  • Reported: MED 1.0 — Fri, 12 Jul 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

module CosEventDomainAdmin IDL

  • Key: MED-1
  • Legacy Issue Number: 5453
  • Status: open  
  • Source: Ericsson ( Niclas Eklund)
  • Summary:

    It seems to be a difference between the Management of Event Domains
    spec and the module CosEventDomainAdmin IDL
    http://www.omg.org/cgi-bin/doc?formal/2001-06-03

    The interface CosEventDomainAdmin::EventDomain contains the operation
    'add_connection', which raises, among others, the DiamondCreationForbidden
    exception:
    ... CUT ...
    ConnectionID add_connection (in Connection connection)
    raises (CosNotifyChannelAdmin::ChannelNotFound,
    CosEventChannelAdmin::TypeError,
    AlreadyExists,
    CycleCreationForbidden,
    DiamondCreationForbidden);
    ... CUT ...

    On page 2-9 it's described as follows:

    "Likewise, if the DiamondDetection QoS property of the target event
    domain is set to the value of ForbidDiamond, and the creation of the
    requested connection would result in a diamond being created within the
    topology of channels to which the connection is being added, then the
    DiamondCreationForbidden exception is raised. This exception contains as
    data a sequence of conflicting paths, each path being a sequence of
    channel member identifiers."

    The CosEventDomainAdmin::EventDomain interface also contains the operation
    'get_diamonds':

    ... CUT ...
    DiamondSeq get_diamonds();:
    ... CUT ..

    On page 2-10:
    "The get_diamonds operation is invoked to retrieve a list of diamonds
    that exist within any topology of channels formed by connections that were
    established between these channels by the target domain. The operation
    accepts no input parameters, and returns as a result a sequence of
    diamonds, whereas each diamond is itself a sequence of member identifiers
    of channels within the domain that are involved in the diamond."

    IMHO, the specification states that the return value from get_diamonds and
    the in the DiamondCreationForbidden should be the same (i.e. a sequence of
    diamonds, where each diamond is a sequence of Id:s).

    But the IDL-file contains:

    ... CUT ...
    typedef MemberIDSeq Route;
    typedef sequence<Route> RouteSeq;

    typedef Route Cycle;
    typedef sequence<Cycle> CycleSeq;

    typedef RouteSeq Diamond;
    typedef sequence<Diamond> DiamondSeq;

    exception CycleCreationForbidden

    { Cycle cyc; }

    ;

    exception DiamondCreationForbidden

    { Diamond diam; }

    ;
    ... CUT ...

    In the above, a DiamondSeq is defined as a sequence of sequences of
    Diamonds, which in turn is a sequence of ID:s.

    The best solution would probably be to change parts of the above to:

    ... CUT ...
    typedef Route Diamond;
    ... CUT ...
    exception DiamondCreationForbidden

    { DiamondSeq diam; }

    ;
    ... CUT ...

    This change makes the defintion of a CycleSeq and DiamondSeq to be
    equivalent.

  • Reported: MED 1.0 — Fri, 12 Jul 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT