Issue 1618:  subscription_change issue (notif_service-rtf)
Source:  (, )
Nature:  Revision
Severity: 
Summary: Summary: The text describing the behaviour of implementations calling
 subscription_change on their suppliers:
 
 Suppliers that are not interested in the event types currently
 subscribed to will not invoke obtain_subscription_types, and will
 raise the NO_IMPLEMENT exception in their implementation of the
 subscription_change operation.
 
 The mechanism (raising NO_IMPLEMENT) is crude, and the continuing
 behaviour of the channel is unspecified; i.e. should the channel
 always call subscription_change and just put up with the exception? I
 should think not. However, should the channel assume that this
 supplier will never be interested in subscriptions ever again? Perhaps
 not. What if the supplier raises NO_IMPLEMENT, and then later calls
 obtain_subscription_types - does this indicate that it is now
 interested in subscription changes?
 

Resolution: 
Revised Text: 
Actions taken:
June 30, 1998: received issue
February 23, 1999: closed issue
Discussion: 

End of Annotations:=====
Return-Path: <dud@dstc.edu.au>
To: notif_service-rtf@omg.org
Cc: issues@omg.org
Subject: subscription_change issue
X-face:
*A\_v+D,~Jx_g]`m,s61-x|*;H4hgZeE=<s8=ep^q96kcoR,N|3]/;|F"C);wi^I6"-X}\#
 NxV@i.&hb;o3+@m{cTE\D;uA&N`N2kHXc"<\2N8-+GJJSsAk3DcF6I@fM8[k,t$)^*YO=1F)A&[+-m
  Jivdt{kFM4&a"}5Mi08HK6J8\W!tYX//<Jr4nX"u~65X0<R5172|K7-I"9/HcB}ENVsBq{lq
Date: Tue, 30 Jun 1998 16:25:05 +1000
From: Keith Duddy <dud@dstc.edu.au>

Hi all,

Julian's found another problem:

The text describing the behaviour of implementations calling
subscription_change on their suppliers:

Suppliers that are not interested in the event types currently
subscribed to will not invoke obtain_subscription_types, and will
raise the NO_IMPLEMENT exception in their implementation of the
subscription_change operation.

The mechanism (raising NO_IMPLEMENT) is crude, and the continuing
behaviour of the channel is unspecified; i.e. should the channel
always call subscription_change and just put up with the exception? I
should think not. However, should the channel assume that this
supplier will never be interested in subscriptions ever again? Perhaps
not. What if the supplier raises NO_IMPLEMENT, and then later calls
obtain_subscription_types - does this indicate that it is now
interested in subscription changes?

A preferable mechanism would be to allow the supplier to indicate to
its proxy when it wants subscription info sent to it, and when it does
not. In other words, over the lifetime of a connection to a proxy, a
supplier should be able to turn subscription feedback on and off. 

If this can be considered to be in the domain of an RTF then it could
be fixed in a number of ways. 

1) add a new operation to ProxyConsumer to turn subscription feedback
    on and off.

    void subscription_changes_required(in boolean required);

2) to avoid synchronisation problems with the list obtained from
    obtain_subscription_types, this operation could be augmented to
    allow the supplier to get subscriptions in several ways:

    enum SubType { ALL_NOW_UPDATES_OFF, 
		   ALL_NOW_UPDATES_ON,
		   NONE_NOW_UPDATES_ON,
		   NONE_NOW_UPDATES_OFF 
    }; // these tags would be simplified when full text can accompany
them

    CosNotification::EventTypeSeq obtain_subscription_types(in SubType
which);

    In this way, a supplier can be assured that when it asks for
    ALL_NOW_UPDATES_ON, that it can maintain a correct subscription
    type list based on the returned value and diffs from
    subscription_change. In (1) above a case can arise where a call is
    made to obtain_subscription_types, followed by a call to
    subscription_changes_required(TRUE), the supplier will be unsure
    whether it has missed a subscription_change happenning inbetween.

If this is not in the scope of an RTF, then the text should be updated
to clarify what the channel should do upon receiving a NO_IMPLEMENT.

K
--
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Keith Duddy  ::  dud@dstc.edu.au  ::
http://www.dstc.edu.au/AU/staff/dud
	    CRC for Distributed Systems Technology (DSTC)
       Gehrmann Labs, University of Queensland, 4072, Australia
	    ph: +61 7 336 5 4310  ::  fx: +61 7 336 5 4311
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
 2nd edition of my book ``Java Programming with CORBA'' now in
bookshops 
      >>>       http://www.wiley.com/compbooks/vogel         <<<
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::