Issues for Mailing list of the Notication/JMS Interworking Finalization Task Force
To comment on any of these issues, send email to notification-jms-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.
List of issues (green=resolved, yellow=pending Board vote, red=unresolved)
Issue 6339: Remove the CosEventDomainAdmin::NotificationStyle
Issue 6340: Rename two operations in the Bridge interface
Issue 6341: Adding InvalidExternalEndpoint Exception to new Bridge::start_bridge() ope
Issue 6342: Remove read-only attributes from EndpointSender and EndpointReceiver
Issue 6339: Remove the CosEventDomainAdmin::NotificationStyle (notification-jms-ftf)
Click here for this issue's archive.
Source: PrismTech (Dr. Ramzi Karoui, ramzi.karoui(at)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
Issue 6340: Rename two operations in the Bridge interface (notification-jms-ftf)
Click here for this issue's archive.
Source: PrismTech (Dr. Ramzi Karoui, ramzi.karoui(at)prismtech.com)
Nature: Uncategorized Issue
Severity:
Summary: 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.
Resolution: Accept proposed changes
Revised Text: In sections 2-3 and 3-1
Change the operation name "start" to "start_bridge"
Change the operation name "stop" to "stop_bridge"
Actions taken:
October 20, 2003: received issue
September 24, 2004: closed issue
Issue 6341: Adding InvalidExternalEndpoint Exception to new Bridge::start_bridge() ope (notification-jms-ftf)
Click here for this issue's archive.
Source: PrismTech (Dr. Ramzi Karoui, ramzi.karoui(at)prismtech.com)
Nature: Uncategorized Issue
Severity:
Summary: 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
Resolution: see above
Revised Text: In section 3.1:
add "InvalidExternalEndpoints" to exception list for Bridge::start_Bridge operation definition..
Add the following paragraph to the end of 3.1.2.1:
"
Passing wrong external end point raises the InvalidExternalEndPoints exception.
"
Actions taken:
October 20, 2003: received issue
September 24, 2004: closed issue
Discussion: The exception name is InvalidExternalEndpoints. accept proposal to add InvalidExternalEndpoints exception to start_Bridge operation
Issue 6342: Remove read-only attributes from EndpointSender and EndpointReceiver (notification-jms-ftf)
Click here for this issue's archive.
Source: PrismTech (Dr. Ramzi Karoui, ramzi.karoui(at)prismtech.com)
Nature: Uncategorized Issue
Severity:
Summary: 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.
Resolution: Accept proposed resolution
Revised Text: In 3.1:
Change Introductory paragraph from:
"
The CosBridgeAdmin module defines the ExternalEndPoint data type, along with EndPointSender and EndPointReceiver types. In addition, this module provides declarations for administrative interfaces which are defined for managing the Bridge Life cycle.
"
to
"
The CosBridgeAdmin module defines the ExternalEndPoint data type. In addition, this module provides declarations for administrative interfaces which are defined for managing the Bridge Life cycle.
Note that the EndPointSender and EndPointReeceiver described in section 2 are implementation objects, therefore they are not specified in the public IDL files.
"
In the Bridge interface idl:
Delete "#include <CosNotifyComm.idl>"
Add "#include<orbdefs.idl>"
Replace:
"
readonly attribute EndpointReceiver end_point_receiver;
readonly attribute EndpointSender end_point_sender;
"
With:
"
readonly attribute ExternalEndpoint end_point_receiver;
readonly attribute ExternalEndpoint end_point_sender;
"
Remove from the IDL definitions:
the union EndpointReceiver ,
the enum EndpointReceiverType,
the union EndpointSender , and
the enum EndpointSenderType
Remove Sections 3.1.2 and 3.1.3 from the specification
Change Beginning of second paragraph of 3.1.4:
From:
"
Each instance of the Bridge interface has two readonly attributes: EndPointSender, EndPointReceiver both of them exist upon creation of the bridge. Due to the architectural restriction described in section 2.3 this interface does not allow the creation of new Endpoint instances.
"
to:
"
Each instance of the Bridge interface has two ExternalEndPoint readonly attributes that describes JMS and Notification service destinations: . Due to the architectural restriction described in section 2.3 this interface does not allow the creation of new Endpoint instances.
"
Actions taken:
October 20, 2003: received isusue
September 24, 2004: closed issue
Discussion: