Issue 2917: Why one to one association between a TcPduUser and TcPduProvider interface? (incorba-ftf)
Source: Ericsson (Mr. Neill Jones, etlnljs(at)etlxdmx.ericsson.se)
Nature: Uncategorized Issue
Severity: 
Summary: There is an assumption in the design that there is a one to one
association between a TcPduUser and a TcPduProvider
during a TC Session. This is enforced in the IDL through the
call

TcPduProvider::get_dialog_id()

and the factory call

TcPduProvider create_tc_pdu_provider(
     in TcPduUser user,
     out DialogId d_id)
raises(NoMoreDialogs);

Since the TcPduUser reference (or some sort of reference)
is not passed over in get_dialog_id(), the only conclusion
is that the reference has to be the one passed over in the
create, and therefore that each TcPduProvider is tied to
one and only one TcPduUser.

Resolution: 
Revised Text: 
Actions taken:
September 22, 1999: received issue
Discussion: 

End of Annotations:=====
Date: Thu, 23 Sep 1999 16:10:30 +0100
From: Neill Jones <jonesn@Teltec.DCU.IE>
Organization: Teltec DUC
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: issues@omg.org, brennanr@Teltec.DCU.IE, jonesn@Teltec.DCU.IE,
        vasicj@Teltec.DCU.IE
Subject: incorba-ftf
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: G#1!!BYG!!:0jd9;iDe9

Hi all,

Subject: Why is there a one to one association between
a TcPduUser and TcPduProvider interface?

There is an assumption in the design that there is a one to one
association between a TcPduUser and a TcPduProvider
during a TC Session. This is enforced in the IDL through the
call

TcPduProvider::get_dialog_id()

and the factory call

TcPduProvider create_tc_pdu_provider(
     in TcPduUser user,
     out DialogId d_id)
raises(NoMoreDialogs);

Since the TcPduUser reference (or some sort of reference)
is not passed over in get_dialog_id(), the only conclusion
is that the reference has to be the one passed over in the
create, and therefore that each TcPduProvider is tied to
one and only one TcPduUser.

This is wasteful of resources, since it is not necessary
to assume that there is a one to one association
between provider and user. The only
important correspondence is between the TcUser and the
dialog id. That is the relationships between the
objects only needs to be

 --------              ----------
| TcPdu  |1+         1| TcPdu    |
| User   |------------| Provider |
 --------              ----------
      \ 1               1 /
       \                 /
        \1+ --------    /
         \ | Dialog |1+/
           |  Id    | /
            --------

That is, each TcPduUser has one TcPduProvider (there
isn't an obvious need for any more than this, although
multiple gateway instances within a fault tolerant
system might alter this), but a TcPduProvider can
be associated with multiple TcPduUser interfaces. Each
Dialog Id corresponds to one TcPduUser and one TcPduProvider
only.

This allows an optimisation of implementation (which
is important to consider in a very high-performance system
such as this)with one TcPduProvider handling all dialogs,
or a pool of TcPduProviders perhaps running on different
threads or machines, as opposed to having to have a pool
of TcPduProviders handling each TcPduUser interface.

A proposed solution to this requires a change to the
idl of get_dialog_id, with the passing in of the
TcPduUser interface.

interface TcPduProvider
{
...
    DialogId get_dialog_id(in TcPduUser user)
        raises (NoMoreDialogs);
...
};


Regards

Neill Jones
Teltec, DCU