Issue 6339: Remove the CosEventDomainAdmin::NotificationStyle                                                                                                                                                       (notification-jms-ftf)
Source: PrismTech (Dr. Ramzi Karoui, ramzi.karoui@prismtech.com)
Nature: Uncategorized Issue
Severity: 
Summary: Removing the CosEventDomainAdmin::NotificationStyle by CosBridgeAdmin::FlowStyle, defined hereafter :
enum FlowStyle {  PUSH,  PULL }. The rational for that is to avoid having dependencies with the CosEventDomainAdmin module defined in the Event domain manager specification. In fact, few notification service providers provide today this CoS. 

Resolution: 
Revised Text: Resolution: Accept proposed change, to replace use of CosEventDomainAdmin::NotificationStyle by new type FlowStyle defined in module CosBridgeAdmin.  .
Revised Text: In section 3.1:

Delete   "#include <CosEventDomainAdmin.idl>"


Add new type to module CosBridgeAdmin: as follows:
"
enum FlowStyle
   {
      PUSH,
      PULL
   };
"

Change:
":
   struct ExternalEndpoint
   {
      ExternalEndpointRole role;
      ExternalEndpointConnector connector;
      CosEventDomainAdmin::NotificationStyle style;
      MessageType type;
   };
"
to
"
   struct ExternalEndpoint
   {
      ExternalEndpointRole role;
      ExternalEndpointConnector connector;
      FlowStyle style;
      MessageType type;
   };
"

In section 3.1.2 and 3.1.3 (: replace "CosEventDomainAdmin::NotificationStyle" with "FlowStyle".    (note another issue proposes removing these sections)

Actions taken:
October 20, 2003: received issue
September 24, 2004: closed issue
Discussion: 

End of Annotations:=====
Proposed Changes in the Notification/JMS Interworking Specification
Change 1
Removing the CosEventDomainAdmin::NotificationStyle by CosBridgeAdmin::FlowStyle, defined hereafter :
enum FlowStyle {  PUSH,  PULL }. The rational for that is to avoid having dependencies with the CosEventDomainAdmin module defined in the Event domain manager specification. In fact, few notification service providers provide today this CoS. 
m: Tom Rutt <tom@coastin.com> 
Reply-To: tom@coastin.com 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 
X-Accept-Language: en-us, en 
To: "Ramzi" <Ramzi.karoui@prismtechnologies.com> 
CC: Juergen Boldt <juergen@omg.org>, notification-jms-ftf@omg.org, 
   SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com> 
Subject: Re: issues 6339 - 6342 -- Notification JMS FTF issues 


Juergen Boldt wrote:
I have a few questions, inline


This is issue # 6339


Remove the CosEventDomainAdmin::NotificationStyle


Removing the CosEventDomainAdmin::NotificationStyle by CosBridgeAdmin::FlowStyle, defined hereafter :
enum FlowStyle {  PUSH,  PULL }. The rational for that is to avoid having dependencies with the CosEventDomainAdmin module defined in the Event domain manager specification. In fact, few notification service providers provide today this CoS. 



Where is the text changes for the document.  Is this proposal fully enabling?





===========================================


This is issue # 6340


Rename two operations in the Bridge interface


Rename two operations in the Bridge interface name have been made:
·    Original Name; Bridge::start();  New Name: Bridge::start_bridge()
·    Original Name; Bridge::stop();  New Name: Bridge::stop_bridge()
The Start and stop names are common operation names. Those names may clash with other implementation components. 



This seems harmless





=============================================


This is issue # 6341


Adding InvalidExternalEndpoint Exception to new Bridge::start_bridge()  ope


Adding InvalidExternalEndpoint Exception to new Bridge::start_bridge()  operation.
·    The Bridge::start_bridge operation is now raises two exceptions: BridgeAdlreadyStarted and InvalidExternalEndpoint.
The rational behind this extension is that during Bridge::start_bridge operation, consumer and publisher are created. If any ExternalEndpoint information (be it source or sink) is invalid, client cannot be created,   thus InvalidExternalEndpoint will be raised 



Where is this exception syntax defined.  Is the full enabling text avaialable for this resolution?





==============================================


This is issue # 6342


Remove  read-only attributes from EndpointSender and EndpointReceiver


Removing the read-only attributes from EndpointSender and EndpointReceiver from the Bridge Interface and replacing them by two external ExternalEndpoints.


The Bridge interface change from:
interface Bridge {
readonly attribute EndpointReceiver end_point_receiver;
readonly attribute EndpointSender end_point_sender;
void start () raises (BridgeAlreadyStarted);
void stop () raises (BridgeInactive);
status get_status();
void destroy ();
}
to:
interface Bridge
   {
      readonly attribute ExternalEndpoint end_point_receiver;
      readonly attribute ExternalEndpoint end_point_sender;
      void start_bridge () raises (BridgeAlreadyStarted,InvalidExternalEndPoints);
      void stop_bridge () raises (BridgeInactive);
      status get_status();
      void destroy ();
   }


The EndpointReceiver and EndpointSender types should be removed from the IDL also.


The rational behind this change is that the EndpointReceiver and EndpointSender object interfaces were exposing internal implementation parts that no third party needs to have access to. Removing those interfaces from the public IDL of the bridge improves the bridge security.


Note that for the purposes of connection the bridge implementation has to manage internally these objects and publish their interfaces to the appropriate Notification Service or JMS. 



Where is the syntax and exlanatory texs for "ExternalEndpoint".  Is more text needed for the
document to be complete?


----------------------------------------------------
Tom Rutt                email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133