Issue 7578: A provided port can have multiple interfaces (swradio-ftf) Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com) Nature: Uncategorized Issue Severity: Summary: Issue 1. Unable to retrieve a specific provided interface for a port (PortSupplier getPort operation) Proposed Solution: Add additional parameter to the getPort operation to qualify which provided interface object reference is needed from the getPort operation. Rationale: A provided port can have multiple interfaces Resolution: Revised Text: Actions taken: July 13, 2004: received issue August 2, 2005: closed issue Discussion: Resolution: As part of the resolution to issue 7953, a constraint has been added that states each port has a set of 1 required and 1 provided interface at most. This invalidates issue 7578. Hence, issue 7578 should be closed with no change required to the specification based on the resolution for issue 7953. Revised Text: N/A Disposition: Closed, no change End of Annotations:===== ubject: PIM and PSM Software Radio Components Issues To: issues@omg.org Cc: swradio-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Gerald_L_Bickle@raytheon.com Date: Tue, 13 Jul 2004 16:37:58 -0500 X-MIMETrack: Serialize by Router on NotesServer3/HDC(Release 5.0.13a |April 8, 2004) at 07/13/2004 04:38:04 PM X-SPAM: 0.00 PIM and PSM Software Radio Components Issues are: Issue 1. Unable to retrieve a specific provided interface for a port (PortSupplier getPort operation) Proposed Solution: Add additional parameter to the getPort operation to qualify which provided interface object reference is needed from the getPort operation. Subject: SWRADIO FTF - Proposed Resolution for Issues 7578 and 7579 Date: Sat, 16 Oct 2004 10:52:26 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: SWRADIO FTF - Proposed Resolution for Issues 7578 and 7579 Thread-Index: AcSzqCW0daLITRx1THqBy88xcUz+rQAAAZ8wAAAfViA= From: "Hayes, Persnaz N" To: X-OriginalArrivalTime: 16 Oct 2004 17:52:26.0259 (UTC) FILETIME=[E5AFAE30:01C4B3A8] Team, Please see attached file. Neli Hayes The Boeing Company Integrated Defense Systems, Network Communication Systems Software Technical Director and Principal Software Architect (714) 762-8768 persnaz.n.hayes@boeing.com Issue 7578 7579 Proposed Resolution.doc ISSUE 7578: A provided port can have multiple interfaces ISSUE 7579: Obtaining resource provided interfaces during deployment PROPOSED RESOLUTION 1. Section 8.1.4.5 (PortSupplier), Description Section Modify the getPort operation as follows: From .This interface provides the getPort operation for components that have provided ports.. To .This interface provides the getProvidedPorts operation for components that have provided ports.. 2. Section 8.1.4.5 (PortSupplier), Operations Section Modify the getPort operation as follows: From .getPort(in name: String, return Port): {raises = ( UnknownPort )} The getPort operation provides a mechanism to obtain a specific provided Port. The getPort operation shall return the provided port reference that is associated with the input port name parameter. The getPort operation shall support all of the provided ports identified in the component's descriptor. The getPort opera-tion shall raise UnknownPort if the port name is not found.. To .getProvidedPorts(inout ports: PortSequence): {raises = ( UnknownPorts )} The getProvidedPorts operation provides a mechanism to obtain a component.s provided ports in form of a sequence of name/value pairs, where each name corresponds to a provided port.s name and the corresponding value is the provided port reference to be returned. The getProvidedPorts operation shall return all the component provided ports if the ports argument is zero size. The getProvidedPorts operation shall return only those provided ports specified in the ports argument if the ports argument is not zero size. The getProvidedPorts operation shall support all of the provided ports identified in the component's descriptor. The getProvidedPorts operation shall raise UnknownPorts when one or more provided port names being requested are not known by the component.. 3. Section 8.1.4.5 (PortSupplier), Types and Exceptions Section Add the following types: .PortType (name: String, object: Port) PortType defines a structure that associates a name with a port. PortSequence PortSequence provides an unbounded sequence of PortType. PortExistsType (name: String, exists: Boolean) PortExistsType defines a structure that associates a port name with a flag indicating whether or not the port exists. PortExistsSequence PortExistsSequence provides an unbounded sequence of PortExistsType.. 4. Section 8.1.4.5 (PortSupplier), Types and Exceptions Section Change the UnknownPort exception as follows: From .<>UnknownPort The UnknownPort exception is raised if an undefined provided port is request-ed.. To .<>UnknownPorts (invalidPorts: PortSequence) The UnknownPorts exception is raised when one or more provided ports being requested are not known by the component. The invalidPorts attribute returned indicates the requested provided ports that were invalid.. 5. Section 8.3.3.1.5 (DomainManager) Modify Figure 8-39, DomainManager Definition UML diagram, to reflect the DeviceManager .portExists. operation name change to .providedPortsExist.. 6. Section 8.3.3.1.5 (DomainManager), Operations Section Modify the portExists operation as follows: From .portExists(in portName: String, return Boolean): The portExists operation shall return True if the input portName exists, or False if it does not.. To .providedPortsExist(inout portsExist: PortExistsSequence): The providedPortsExist operation provides a mechanism to determine if the specified provided ports exist. In the portsExist sequence of name/value pairs, each name corresponds to the name of the provided port and each corresponding value shall be returned as True if the specified provided port exists, or False if it does not.. 7. Section 8.3.3.1.5 (DomainManager), Semantics Section Modify the following sentence From .The portExists operation can be used to determine the Service(s) offered by a DomainManager. The getPort op-eration behavior shall be agreement with the portExists behavior.. To .The providedPortsExist operation can be used to determine the Service(s) offered by a DomainManager. The getProvidedPorts operation behavior shall be agreement with the providedPortsExist behavior.. 8. Section 8.3.3.3.1 (DeviceManager) Modify Figure 8-40, DomainManager Definition UML diagram, to reflect the DomainManager .portExists. operation name change to .providedPortsExist.. 9. Section 8.3.3.3.1 (DeviceManager), Operations Section Modify the portExists operation as follows: From .portExists(in portName: String, return Boolean): The portExists operation shall return True if the input portName exists, or False if it does not.. To .providedPortsExist(inout portsExist: PortExistsSequence): The providedPortsExist operation provides a mechanism to determine if the specified provided ports exist. In the portsExist sequence of name/value pairs, each name corresponds to the name of the provided port and each corresponding value shall be returned as True if the specified provided port exists, or False if it does not.. 10. Section 8.3.3.3.1 (DeviceManager), Semantics Section Modify the following sentence From .The portExists operation can be used to determine the Service(s) offered by a DeviceManager. The getPort oper-ation behavior shall be agreement with the portExists behavior. To .The providedPortsExist operation can be used to determine the Service(s) offered by a DeviceManager. The getProvidedPorts operation behavior shall be agreement with the providedPortsExist behavior. 11. Section 8.3.4.2.1 (Application), Operations Section Modify the getPort operation as follows: From .getPort (in name: String): {raises ( UnknownPort )} The getPort operation returns object references only for input port names that match the external port names that are in the Application.s component assembly descriptor... To .getProvidedPorts (inout ports: PortSequenceType): {raises ( UnknownPorts )} The getProvidedPorts operation returns object references only for input port names that match the external provided port names that are in the Application.s component assembly descriptor. In the ports name/value pair sequence, each name corresponds to an external provided port name and each value corresponds to the object reference of the external provided port to be returned. The getProvidedPorts operation shall return all the external provided ports if the ports argument is zero size. The getProvidedPorts operation shall return only those provided ports specified in the ports argument if the ports argument is not zero size. The getProvidedPorts operation shall raise an UnknownPorts exception when one or more requested provided ports are invalid.. 12. Section 8.3.4.2.2 (ApplicationFactory), Semantics Section Change the following sentence From .The create operation obtains provider ports in accordance with the Application's component assembly via PortSupplier's getPort operation.. To .The create operation obtains provider ports in accordance with the Application's component assembly via PortSupplier's getProvidedPorts operation.. 13. Rose Model and IDL Files Reflect the described changes to PortSupplier, DomainManager, and DeviceManager in the Rose Model and IDL files. Subject: 1st Ballot Vote - Partial To: "Demirbilek, Tansu" , "Hayes, Persnaz N" Cc: swradio-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Gerald_L_Bickle@raytheon.com Date: Mon, 1 Nov 2004 06:37:44 -0500 X-MIMETrack: Serialize by Router on NotesServer3/HDC(Release 5.0.13a |April 8, 2004) at 11/01/2004 06:37:46 AM X-SPAM: 0.00 I still have a few issues to vote on but here is my vote so far. OMG Issue No: 7578 & 7579: No, Issue 7579 did not address 7578. The following changes need to be made. What needs to be returned is provided interfaces for provided ports not provided ports. There is no provided Port definition in profile. A provided port can have more than one provided interface. name and interface name, and the corresponding value is the provided port reference to be returned. The getProvidedPorts operation shall return all the component provided ports if the ports argument is zero size. The getProvidedPorts operation shall return only those provided ports specified in the ports argument if the ports argument is not zero size. The getProvidedPorts operation shall support all of the provided ports identified in the component's descriptor. The getProvidedPorts operation shall raise UnknownPorts when one or more provided port names being requested are not known by the component. 6$805$03-23-04$Banner Program: OCI$/home/httpd/htdocs/_private/oci-banner/index.htm.cnt rtSequence PortSequence provides an unbounded sequence of PortType. The returned exception says only invalid ports are returned. Definition needs to be changed to indicate invalid port and port interface and remove nvalidPortType (portName: String, ProvidedInterfaceName: String) InvalidPortType defines a structure that indicates the provided port and nvalidPortSequence InvalidPortSequence provides an unbounded sequence of InvalidPortType. interfacption>>UnknownPorts (invalidPorts: InvalidPortSequence) The UnknownPorts exception is raised when one or more provided ports being requested are not known by the component. The invalidPorts attribute returned indicates the requested provided ports that were invalid. If PortExistsType is not used for the UnknownPorts exception then move this type of this interface and put a types section in ResourceComponents and move these types there. PortExistType needs to be modified to include provide interface name. thatPortExistsType (portName: String, providedInterfaceName: String, exists: rtExistsSequence PortExistsSequence provides an unbounded sequence of PortExistsType. OMG Issue No: 7580: Yes OMG Issue No: 7584: OMG Issue No: 7587: Yes OMG Issue No: 7596: OMG Issue No: 7655: OMG Issue No: 7656: Yes, but the superscript for range values is not depicted correctly for long, longlong, short, ulong, ulonglong, ushort. Wrong Comment in Draft Doc, should be 7656 instead of 7587 OMG Issue No: 7657: Yes, but the section name and description has a typo, rename IStatusSignal with StatusSignal OMG Issue No: 7658: No, the types are not defined For example, 9.3.1.1.1ILocalLinkManagement <> PromisciousModeType(PHYSICAL, SAP, MULTI) ConnectionIDType (sourceAddress: AddressType, destinationAddress: AddressType, priority: integer, sapAddress: SAPAddressType, linkService: LinkServiceType) etc. OMG Issue No: 7660: Yes OMG Issue No: 7672: Yes OMG Issue No: 7684: Yes OMG Issue No: 7689: Yes OMG Issue No: 7690: Yes OMG Issue No: 7691: Yes OMG Issue No: 7693: Yes OMG Issue No: 7696: Yes OMG Issue No: 7697: Yes OMG Issue No: 7698: Yes, note other changes listed in Issue were not needed? OMG Issue No: 7699: Yes OMG Issue No: 7700: Yes OMG Issue No: 7701: Yes OMG Issue No: 7702: Yes OMG Issue No: 7781: OMG Issue No: 7786: Jerry Bickle Engineering Fellow Network Centric Systems 1010 Production Rd Fort Wayne, IN 46808-4711 260-429-6280 260-429-5060 Fax Boolean) PortExistsType defines a structure that associates a provided port name and interface name with a flag indicating whether or not the provided interface exists. donexists indication. Also the exception returned the wrong type. Adst for a component. the following types: Change the following types: PortType (providedPortName: String, ProvidedInterfaceName: String, providedInterface: ObjectReference) PortType defines a structure that associates a provided interface name with a provided port. provided ports in form of a sequence of names/value pairs, where each name corresponds to a provided port Description changes noted with underlines. Subject: RE: Updated 1st Ballot Vote (Comments on Provided Vote on Issues 7578, 7579, 7596, 7660, 7684) Date: Thu, 4 Nov 2004 04:37:28 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated 1st Ballot Vote (Comments on Provided Vote on Issues 7578, 7579, 7596, 7660, 7684) Thread-Index: AcTA27UmAwj/WEEIQs61XWa2WvoitgBjY0Fw From: "Hayes, Persnaz N" To: Cc: , "Browne, Mike \(Space Technology\)" X-OriginalArrivalTime: 04 Nov 2004 12:37:28.0688 (UTC) FILETIME=[0BB46F00:01C4C26B] Jerry, Thank you for your comments below on issues 7578 and 7579. Tansu will remove these issues off the ballot so that I can correct the existing solution to include the port name in addition to the interface name in the solution, as you have outlined below. Furthermore, based on our Nov 3, 2004 discussions, I will also add a "providedInterfaceName" parameter to the portConnector::connectPort () operation. The above will be prepared as a solution for our next ballot for these issues. During the November Technical Meeting, the team did raise some valid concerns about our current solution strategy for these issues and the fact that issue 7578 was raised. I will summarize these and send them out, as I believe some further discussion is needed before we finalize the solution for these issues for our next ballot. The reason why issues 7596, 7660, and 7684 are not listed in the document is due to the fact that they are invalid issues that were raised by OMG by mistake. The requested vote is for the closure of these issues due to their invalidity. They were noted as redundant issues with no related change in the ballot distribution. Sincerely, Neli Hayes Software Technical Director and Principal Software Architect Network Communication Systems Integrated Defense Systems The Boeing Company 714-762-8768 persnaz.n.hayes@boeing.com -----Original Message----- From: Gerald_L_Bickle@raytheon.com [mailto:Gerald_L_Bickle@raytheon.com] Sent: Tuesday, November 02, 2004 4:58 AM To: Demirbilek, Tansu; Hayes, Persnaz N Cc: swradio-ftf@omg.org Subject: Updated 1st Ballot Vote Issues not listed in document: 7596, 7660, 7684, OMG Issue No: 7578 & 7579: No, Issue 7579 did not address 7578. The following changes need to be made. What needs to be returned is provided interfaces for provided ports not provided ports. There is no provided Port definition in profile. A provided port can have more than one provided interface. Description changes noted with underlines. provided ports in form of a sequence of names/value pairs, where each name corresponds to a provided port name and interface name, and the corresponding value is the provided port reference to be returned. The getProvidedPorts operation shall return all the component provided ports if the ports argument is zero size. The getProvidedPorts operation shall return only those provided ports specified in the ports argument if the ports argument is not zero size. The getProvidedPorts operation shall support all of the provided ports identified in the component's descriptor. The getProvidedPorts operation shall raise UnknownPorts when one or more provided port names being requested are not known by the component. Change the following types: PortType (providedPortName: String, ProvidedInterfaceName: String, rtSequence PortSequence provides an unbounded sequence of PortType. nvalidPortSequence InvalidPortSequence provides an unbounded sequence of InvalidPortType. Thption>>UnknownPorts (invalidPorts: InvalidPortSequence) The UnknownPorts exception is raised when one or more provided ports being requested are not known by the component. The exception says only invalid ports are returned. Definition needs to be changed to indicate invalid port and port interface and remove exists indication. Also the exception returned the wrong type. Add the following types: nvalidPortType st for a component. portName: String, ProvidedInterfaceName: String) InvalidPortType defines a structure that indicates the provided port and interface that donnvalidPorts attribute returned indicates the requested provided ports that were invalid. If PortExistsType is not used for the UnknownPorts exception then move this type of this interface and put a types section in ResourceComponents and move these types there. PortExistType needs to be modified to include provide interface name. PortExistsType (portName: String, providedInterfaceName: String, exists: returnedBoolean) rtExistsSequence PortExistsSequence provides an unbounded sequence of PortExistsType. MG Issue No: 7580: Yes OMG Issue No: 7584: No, unclear what interfaces go with what port and should ports have well defined names? For RFIF Component, why is the control port needed since the interfaces have configurable properties? OMG Issue No: 7587: Yes OMG Issue No: 7596: Yes OMG Issue No: 7655: Yes, but the superscript for range values is not depicted correctly for long, longlong, short, ulong, ulonglong, ushort. Wrong Comment in Draft Doc, should be 7655 instead of 7587. For the literal types, the attributes list does not have a space or tab after the bullet. OMG Issue No: 7657: Yes, but the section name and description has a typo, rename IStatusSignal with StatusSignal OMG Issue No: 7658: Yes, but new issue needs to be raised since the types are not defined For example, ODUCER_LOG_LEVEL ConfigureQueryProperty provides the ability to teonlydestinationAddress: AddressType, priority: integer, g message output of a SWRadioComponent. This property may be configured via the IPropertySet interface to output only specific log levels. Section 8.3.1, Replace IstateManagement with StatementManagement SnstantiatedWF: WaveformApplication [1] An instantiated waveform application runs on its associated Communication- Channel eropertySet Connecto (sourceAddress: AddressType, nd writeonlydestinationAddress: AddressType, priority: integer, m name since the stereoptypes indicate this is an interface. Jerry Bickle Engineering Fellow Network Centric Systems 1010 Production Rd Fort Wayne, IN 46808-4711 260-429-6280 260-429-5060 Fax Section 8.3.2.5 ? typo on association name, not conformat, change to :availabeOperatingEnvironment and also figure above the description. Associations etibleWF: WaveformApplication [0..n] A Logical Communication Channel may have all the capabilities required by a WaveformApplication. ction 8.3.2.2 These Associations do not agree with Figure 8-33. Update Figure Associations vailable operating environment: OperatingEnvironment [0..n] A LogicalProcessingChannel uses the interfaces provided by the operating en- vironment Section 8.3.2.6 ? typo on association names, not conformat, fix names and figure above description Associations role): Processor A LogicalIOChannel may be associated with zero or one processor aded algorithm: I MG Issue No: 7786: OMG Ussue No: 7761 (partial): no, The interface names should have the ODUCER_LOG_LEVELectionIDType (sourceAddress: AddressType, nd writeonlydestinationAddress: AddressType, priority: integer, otc. OMG Issue No: 7656: Yes OMG Issue No: 7660: Yes OMG Issue No: 7672: Yes OMG Issue No: 7684: Yes OMG Issue No: 7689: Yes OMG Issue No: 7690: Yes OMG Issue No: 7691: Yes OMG Issue No: 7693: Yes ett. OMG Issue No: 7656: Yes OMG Issue No: 7660: Yes OMG Issue No: 7672: Yes OMG Issue No: 7684: Yes OMG Issue No: 7689: Yes OMG Issue No: 7690: Yes OMG Issue No: 7691: Yes OMG Issue No: 7693: Yes 9.3.1.1.1ILocalLinkManagement <> PromisciousModeType(PHYSICAL, SAP, MULTI) WRadioComponent may implement a ConfigureQueryProperty with a name of sapAddress: SAPAddressType, linkService: LinkServiceType) emantics ? Rename OMG Issue No: 7696: Yes OMG Issue No: 7697: Yes OMG Issue No: 7698: Yes, note other changes listed in Issue were not needed? OMG Issue No: 7699: Yes OMG Issue No: 7700: Yes OMG Issue No: 7701: Yes OMG Issue No: 7702: Yes OMG Issue No: 7781: Yes, but additional typos 8.1.5.6 Constraints Valid properties for the configure operation are ConfigureQueryProperty(s) that are readwrite and writeonly mode as stated in the component's descriptor. Remove PortExistsType defines a structure that associates a provided port name and interface name with a flag indicating whether or not the provided interface exists. providedInterface: ObjectReference) PortType defines a structure that associates a provided interface name with a provided port. Subject: RE: Updated 1st Ballot Vote (Comments on Provided Vote on Issues 7578, 7579, 7596, 7660, 7684) Date: Thu, 4 Nov 2004 04:37:28 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated 1st Ballot Vote (Comments on Provided Vote on Issues 7578, 7579, 7596, 7660, 7684) Thread-Index: AcTA27UmAwj/WEEIQs61XWa2WvoitgBjY0Fw From: "Hayes, Persnaz N" To: Cc: , "Browne, Mike \(Space Technology\)" X-OriginalArrivalTime: 04 Nov 2004 12:37:28.0688 (UTC) FILETIME=[0BB46F00:01C4C26B] Jerry, Thank you for your comments below on issues 7578 and 7579. Tansu will remove these issues off the ballot so that I can correct the existing solution to include the port name in addition to the interface name in the solution, as you have outlined below. Furthermore, based on our Nov 3, 2004 discussions, I will also add a "providedInterfaceName" parameter to the portConnector::connectPort () operation. The above will be prepared as a solution for our next ballot for these issues. During the November Technical Meeting, the team did raise some valid concerns about our current solution strategy for these issues and the fact that issue 7578 was raised. I will summarize these and send them out, as I believe some further discussion is needed before we finalize the solution for these issues for our next ballot. The reason why issues 7596, 7660, and 7684 are not listed in the document is due to the fact that they are invalid issues that were raised by OMG by mistake. The requested vote is for the closure of these issues due to their invalidity. They were noted as redundant issues with no related change in the ballot distribution. Sincerely, Neli Hayes Software Technical Director and Principal Software Architect Network Communication Systems Integrated Defense Systems The Boeing Company 714-762-8768 persnaz.n.hayes@boeing.com -----Original Message----- From: Gerald_L_Bickle@raytheon.com [mailto:Gerald_L_Bickle@raytheon.com] Sent: Tuesday, November 02, 2004 4:58 AM To: Demirbilek, Tansu; Hayes, Persnaz N Cc: swradio-ftf@omg.org Subject: Updated 1st Ballot Vote Issues not listed in document: 7596, 7660, 7684, OMG Issue No: 7578 & 7579: No, Issue 7579 did not address 7578. The following changes need to be made. What needs to be returned is provided interfaces for provided ports not provided ports. There is no provided Port definition in profile. A provided port can have more than one provided interface. Description changes noted with underlines. provided ports in form of a sequence of names/value pairs, where each name corresponds to a provided port name and interface name, and the corresponding value is the provided port reference to be returned. The getProvidedPorts operation shall return all the component provided ports if the ports argument is zero size. The getProvidedPorts operation shall return only those provided ports specified in the ports argument if the ports argument is not zero size. The getProvidedPorts operation shall support all of the provided ports identified in the component's descriptor. The getProvidedPorts operation shall raise UnknownPorts when one or more provided port names being requested are not known by the component. Change the following types: PortType (providedPortName: String, ProvidedInterfaceName: String, rtSequence PortSequence provides an unbounded sequence of PortType. nvalidPortSequence InvalidPortSequence provides an unbounded sequence of InvalidPortType. Thption>>UnknownPorts (invalidPorts: InvalidPortSequence) The UnknownPorts exception is raised when one or more provided ports being requested are not known by the component. The exception says only invalid ports are returned. Definition needs to be changed to indicate invalid port and port interface and remove exists indication. Also the exception returned the wrong type. Add the following types: nvalidPortType st for a component. portName: String, ProvidedInterfaceName: String) InvalidPortType defines a structure that indicates the provided port and interface that donnvalidPorts attribute returned indicates the requested provided ports that were invalid. If PortExistsType is not used for the UnknownPorts exception then move this type of this interface and put a types section in ResourceComponents and move these types there. PortExistType needs to be modified to include provide interface name. PortExistsType (portName: String, providedInterfaceName: String, exists: returnedBoolean) rtExistsSequence PortExistsSequence provides an unbounded sequence of PortExistsType. MG Issue No: 7580: Yes OMG Issue No: 7584: No, unclear what interfaces go with what port and should ports have well defined names? For RFIF Component, why is the control port needed since the interfaces have configurable properties? OMG Issue No: 7587: Yes OMG Issue No: 7596: Yes OMG Issue No: 7655: Yes, but the superscript for range values is not depicted correctly for long, longlong, short, ulong, ulonglong, ushort. Wrong Comment in Draft Doc, should be 7655 instead of 7587. For the literal types, the attributes list does not have a space or tab after the bullet. OMG Issue No: 7657: Yes, but the section name and description has a typo, rename IStatusSignal with StatusSignal OMG Issue No: 7658: Yes, but new issue needs to be raised since the types are not defined For example, ODUCER_LOG_LEVEL ConfigureQueryProperty provides the ability to teonlydestinationAddress: AddressType, priority: integer, g message output of a SWRadioComponent. This property may be configured via the IPropertySet interface to output only specific log levels. Section 8.3.1, Replace IstateManagement with StatementManagement SnstantiatedWF: WaveformApplication [1] An instantiated waveform application runs on its associated Communication- Channel eropertySet Connecto (sourceAddress: AddressType, nd writeonlydestinationAddress: AddressType, priority: integer, m name since the stereoptypes indicate this is an interface. Jerry Bickle Engineering Fellow Network Centric Systems 1010 Production Rd Fort Wayne, IN 46808-4711 260-429-6280 260-429-5060 Fax Section 8.3.2.5 ? typo on association name, not conformat, change to :availabeOperatingEnvironment and also figure above the description. Associations etibleWF: WaveformApplication [0..n] A Logical Communication Channel may have all the capabilities required by a WaveformApplication. ction 8.3.2.2 These Associations do not agree with Figure 8-33. Update Figure Associations vailable operating environment: OperatingEnvironment [0..n] A LogicalProcessingChannel uses the interfaces provided by the operating en- vironment Section 8.3.2.6 ? typo on association names, not conformat, fix names and figure above description Associations role): Processor A LogicalIOChannel may be associated with zero or one processor aded algorithm: I MG Issue No: 7786: OMG Ussue No: 7761 (partial): no, The interface names should have the ODUCER_LOG_LEVELectionIDType (sourceAddress: AddressType, nd writeonlydestinationAddress: AddressType, priority: integer, otc. OMG Issue No: 7656: Yes OMG Issue No: 7660: Yes OMG Issue No: 7672: Yes OMG Issue No: 7684: Yes OMG Issue No: 7689: Yes OMG Issue No: 7690: Yes OMG Issue No: 7691: Yes OMG Issue No: 7693: Yes ett. OMG Issue No: 7656: Yes OMG Issue No: 7660: Yes OMG Issue No: 7672: Yes OMG Issue No: 7684: Yes OMG Issue No: 7689: Yes OMG Issue No: 7690: Yes OMG Issue No: 7691: Yes OMG Issue No: 7693: Yes 9.3.1.1.1ILocalLinkManagement <> PromisciousModeType(PHYSICAL, SAP, MULTI) WRadioComponent may implement a ConfigureQueryProperty with a name of sapAddress: SAPAddressType, linkService: LinkServiceType) emantics ? Rename OMG Issue No: 7696: Yes OMG Issue No: 7697: Yes OMG Issue No: 7698: Yes, note other changes listed in Issue were not needed? OMG Issue No: 7699: Yes OMG Issue No: 7700: Yes OMG Issue No: 7701: Yes OMG Issue No: 7702: Yes OMG Issue No: 7781: Yes, but additional typos 8.1.5.6 Constraints Valid properties for the configure operation are ConfigureQueryProperty(s) that are readwrite and writeonly mode as stated in the component's descriptor. Remove PortExistsType defines a structure that associates a provided port name and interface name with a flag indicating whether or not the provided interface exists. providedInterface: ObjectReference) PortType defines a structure that associates a provided interface name with a provided port. Subject: SWRADIO FTF - Issues 7578 and 7579 Date: Sat, 27 Nov 2004 13:03:46 -0800 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: SWRADIO FTF - Issues 7578 and 7579 Thread-Index: AcTMzBjFvtAUeX+6TCWAQAanTY8D5wH5FTKg From: "Hayes, Persnaz N" To: X-OriginalArrivalTime: 27 Nov 2004 21:03:47.0176 (UTC) FILETIME=[96321680:01C4D4C4] Mike, Thank you for your input on issues 7578 and 7579 at the November 18th, Telecon. I have them captured below from Tansu's minutes: Issue 7578/7579 Comments from November 18, 2004 Telecon · Mike says he has some issues/ problems with the current proposed solution. · Are we proposing accessing single interfaces from the ports? Complexity? · Port based vs Interface based solution 1 Mike will check UML 2.0 specification to see the approach 2 Current resolution proposes to access an interface from a port instead of a port being the combined aggregate of interfaces. Mike thinks it might be increased complexity. 3 Jerry, Neli, comments? I also went ahead and reviewed the UML 2.0 Superstructure Specification and captured the related sections that would answer our questions. Enclosed you'll find related extracts to Ports and Port Interfaces from the latest available version of the UML 2.0 Superstructure Convenience document dated October 2, 2004, that I have captured. I've hi-lited the subsections of interest in bold italic blue. <> Based on the UML 2.0 specification, a Port is an interaction point between a classifier's (e.g. a component's) internals and it's environment. These interaction points are grouped by a classifier's provided vs. required services. Furthermore, these interaction points have the option to be more than just singly typed (i.e. single interface) interaction points. They are type-checked interaction points, where the type is defined by the Port's interface. So, in the most generic case, to access a desired port, you need to distinguish between a provided and a required port, need a port name, and also need an interface name, (accounting for the fact the port may support more than one interface). The above is 100% in-line with what Jerry has suggested all along, confirms the validity of the issue raised (7578) and with the current proposed resolution along with the corrections suggested by Jerry and myself during the November Technical Meeting. The proposed resolution along with the corrections are captured in my first e-mail below. Based on the above, our suggestion is that the above is what needs to be modeled in the SWRADIO specification UML profile, as the UML profile should be kept generic. A particular PIM or PSM can be tailored further to constrain this profile. For instance, a specific PSM (for instance the SCA) based on the SWRADIO UML profile, can choose to constraint ports to have only one type, or one interface. In that case, the PSM could be constrained to only ask for port name and not care about the interface name. However, our UML Profile and our PIM (Platform Independent Model) should handle the generic case, that is account for the fact that a provided port may have more than one interface. I hope the above answers the concerns raised at the telecon and also helps you in your research. Thanks, Neli Hayes Software Technical Director and Principal Software Architect Network Communication Systems Integrated Defense Systems The Boeing Company 714-762-8768 persnaz.n.hayes@boeing.com > ______________________________________________ > From: Hayes, Persnaz N > Sent: Wednesday, November 17, 2004 9:37 AM > To: 'swradio-ftf@omg.org' > Subject: SWRADIO FTF - Consensus on Recommended Solution for Issues 7578 and 7579 > > John, Manfred, Dom, Jerry, and Tansu, > > These issues were pulled off the ballot due to a mistake in the submitted resolution. Enclosed, you'll find the original proposed resolution for issues 7578 and 7579 and Jerry's recommended correction on them. > > As discussed per the November Technical Meeting, I intend to incorporate Jerry's comments along with addition of a providedInterfaceName parameter to the PortConnector::connectPort () operation and get the resolution ready for our next ballot.> > > However, the team did raise some concerns on whether issue 7578 should even be accepted, that is, whether UML 2.0 really intends for Ports to expose their interfaces, and whether we should go this direction in the SWRADIO spec with PortSupplier::getPort (), and with the SWRADIO deployment entities in charge of connecting the components. > > From all current data at hand, and my discussions with Jerry and Bran Selic, I believe that is the intent and that we should go ahead with the existing resolution and proposed corrections. However, we do need consensus for our suggested resolution to pass the next ballot. > > I would like the team, especially John, Manfred, and Dom who raised concerns about our current direction along with Jerry, myself and Tansu as the main participants to continue their discussions on this subject so that we can come to a resolution. > > To help with starting the discussions, enclosed you'll find the original issue resolution, Jerry's corrective comments, and our meeting minute outcomes. > > Furthermore, the latest versions of the UML 2.0 Infrastructure and Super Structure specifications are available from the OMG website as follows: > > UML 2.0 Superstructure Final Adopted Spec 8/2/2003 > UML 2.0 Superstructure FTF Convenience Doc 10/2/2004 > UML 2.0 Infrastructure Final Adopted Spec 9/15/2003 > The Infrastructure latest convenience, dated 10/14/2004 is listed on the web site but not available for download yet. > > > Thank you. > > Neli Hayes > Software Technical Director and Principal Software Architect > Network Communication Systems > Integrated Defense Systems > The Boeing Company > > 714-762-8768 > persnaz.n.hayes@boeing.com > > > <> > > <> > > <> > > > SWRADIO FTF Issues 7578 and 7579 UML 2 Superstructure Extracts Related to Ports and Interfaces.doc Issue 7578 7579 Proposed Resolution 2004.10.21 Neli1.doc X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: Final 1st Ballot Vote Date: Wed, 17 Nov 2004 09:17:12 -0800 Message-ID: <829FE9F630965345A75B973E657C27F40C126E@XCH-SW-2V2.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Final 1st Ballot Vote Thread-Index: AcTDL0zl5vomp/hWRiOHDJLpJea0wgJmd+mg From: Gerald_L_Bickle@raytheon.com [mailto:Gerald_L_Bickle@raytheon.com] Sent: Friday, November 05, 2004 4:01 AM To: swradio-ftf@omg.org Subject: Final 1st Ballot Vote OMG Issue No: 7578 & 7579: No, Issue 7579 did not address 7578. The following changes need to be made. What needs to be returned is provided interfaces for provided ports not provided ports. There is no provided Port definition in profile. A provided port can have more than one provided interface. Description changes noted with underlines. provided ports in form of a sequence of names/value pairs, where each name corresponds to a provided port name and interface name, and the corresponding value is the provided port reference to be returned. The getProvidedPorts operation shall return all the component provided ports if the ports argument is zero size. The getProvidedPorts operation shall return only those provided ports specified in the ports argument if the ports argument is not zero size. The getProvidedPorts operation shall support all of the provided ports identified in the component's descriptor. The getProvidedPorts operation shall raise UnknownPorts when one or more provided port names being requested are not known by the component. Change the following types: PortType (providedPortName: String, ProvidedInterfaceName: String, rtSequence PortSequence provides an unbounded sequence of PortType. nvalidPortSequence InvalidPortSequence provides an unbounded sequence of InvalidPortType. Thption>>UnknownPorts (invalidPorts: InvalidPortSequence) The UnknownPorts exception is raised when one or more provided ports being requested are not known by the component. The invalidPorts attribute returned indicates the requested provided ports that were invalid. If PortExistsType is not used for the UnknownPorts exception then move this type of this interface and put a types section in ResourceComponents and move these types there. PortExistType needs to be modified to include provide interface name. PortExistsType (portName: String, providedInterfaceName: String, exists: returnedBoolean) rtExistsSequence PortExistsSequence provides an unbounded sequence of PortExistsType. SWRADIO_FTF_Minutes_Technical_Meeting_DC_2004_11_02_to_11_05.doc PortExistsType defines a structure that associates a provided port name and interface name with a flag indicating whether or not the provided interface exists. exception says only invalid ports are returned. Definition needs to be changed to indicate invalid port and port interface and remove exists indication. Also the exception returned the wrong type. Add the following types: nvalidPortType st for a component. portName: String, ProvidedInterfaceName: String) InvalidPortType defines a structure that indicates the provided port and interface that don providedInterface: ObjectReference) PortType defines a structure that associates a provided interface name with a provided port. Subject: FW: SWRADIO FTF - Issues 7578 and 7579 Date: Sat, 27 Nov 2004 13:16:24 -0800 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: SWRADIO FTF - Issues 7578 and 7579 Thread-Index: AcTMzBjFvtAUeX+6TCWAQAanTY8D5wH5FTKgAAUNmWA= From: "Hayes, Persnaz N" To: X-OriginalArrivalTime: 27 Nov 2004 21:16:24.0784 (UTC) FILETIME=[59C3E500:01C4D4C6] Jerry, Could you please review my input below to Mike's questions and concerns (which were also shared by Manfred, John, and Dom at the November meeting) and provide your input. I believe my research (based on the latest version of the UML 2 Superstructure Convenience) does confirm your suggestions. John, Please review the discussions below and provide us with your input. I hope the information I have provided does alleviate the concerns raised by Mike, also shared by you at the November meeting. Manfred and Dom, Please review and provide your input, as you also were sharing the same concerns. I need consensus from the team to be able to close these discussions and provide the final resolution for these issues for our second FTF ballot . The issue, and current proposed resolutions are the 1st e-mail below. My backups defending what is currently proposed are in 2nd e-mail below. Thank you. Neli Hayes Software Technical Director and Principal Software Architect Network Communication Systems Integrated Defense Systems The Boeing Company 714-762-8768 persnaz.n.hayes@boeing.com > ______________________________________________ > From: Hayes, Persnaz N > Sent: Saturday, November 27, 2004 1:04 PM > To: swradio-ftf@omg.org > Subject: SWRADIO FTF - Issues 7578 and 7579 > > Mike, > > Thank you for your input on issues 7578 and 7579 at the November 18th, Telecon. I have them captured below from Tansu's minutes: > > Issue 7578/7579 Comments from November 18, 2004 Telecon > · Mike says he has some issues/ problems with the current proposed solution. > · Are we proposing accessing single interfaces from the ports? Complexity? > · Port based vs Interface based solution > 1 Mike will check UML 2.0 specification to see the approach > 2 Current resolution proposes to access an interface from a port instead of a port being the combined aggregate of interfaces. Mike thinks it might be increased complexity. > 3 Jerry, Neli, comments? > > > I also went ahead and reviewed the UML 2.0 Superstructure Specification and captured the related sections that would answer our questions. Enclosed you'll find related extracts to Ports and Port Interfaces from the latest available version of the UML 2.0 Superstructure Convenience document dated October 2, 2004, that I have captured. I've hi-lited the subsections of interest in bold italic blue. > > > <> > > Based on the UML 2.0 specification, a Port is an interaction point between a classifier's (e.g. a component's) internals and it's environment. These interaction points are grouped by a classifier's provided vs. required services. Furthermore, these interaction points have the option to be more than just singly typed (i.e. single interface) interaction points. They are type-checked interaction points, where the type is defined by the Port's interface. So, in the most generic case, to access a desired port, you need to distinguish between a provided and a required port, need a port name, and also need an interface name, (accounting for the fact the port may support more than one interface). > > The above is 100% in-line with what Jerry has suggested all along, confirms the validity of the issue raised (7578) and with the current proposed resolution along with the corrections suggested by Jerry and myself during the November Technical Meeting. The proposed resolution along with the corrections are captured in my first e-mail below. > > Based on the above, our suggestion is that the above is what needs to be modeled in the SWRADIO specification UML profile, as the UML profile should be kept generic. A particular PIM or PSM can be tailored further to constrain this profile.> > > For instance, a specific PSM (for instance the SCA) based on the SWRADIO UML profile, can choose to constraint ports to have only one type, or one interface. In that case, the PSM could be constrained to only ask for port name and not care about the interface name. However, our UML Profile and our PIM (Platform Independent Model) should handle the generic case, that is account for the fact that a provided port may have more than one interface. > > I hope the above answers the concerns raised at the telecon and also helps you in your research. > > Thanks, > > Neli Hayes > Software Technical Director and Principal Software Architect > Network Communication Systems > Integrated Defense Systems > The Boeing Company > > 714-762-8768 > persnaz.n.hayes@boeing.com > > ______________________________________________ > From: Hayes, Persnaz N > Sent: Wednesday, November 17, 2004 9:37 AM > To: 'swradio-ftf@omg.org' > Subject: SWRADIO FTF - Consensus on Recommended Solution for Issues 7578 and 7579 > > John, Manfred, Dom, Jerry, and Tansu, > > These issues were pulled off the ballot due to a mistake in the submitted resolution. Enclosed, you'll find the original proposed resolution for issues 7578 and 7579 and Jerry's recommended correction on them. > > As discussed per the November Technical Meeting, I intend to incorporate Jerry's comments along with addition of a providedInterfaceName parameter to the PortConnector::connectPort () operation and get the resolution ready for our next ballot. > > However, the team did raise some concerns on whether issue 7578 should even be accepted, that is, whether UML 2.0 really intends for Ports to expose their interfaces, and whether we should go this direction in the SWRADIO spec with PortSupplier::getPort (), and with the SWRADIO deployment entities in charge of connecting the components. > > From all current data at hand, and my discussions with Jerry and Bran Selic, I believe that is the intent and that we should go ahead with the existing resolution and proposed corrections. However, we do need consensus for our suggested resolution to pass the next ballot. > > I would like the team, especially John, Manfred, and Dom who raised concerns about our current direction along with Jerry, myself and Tansu as the main participants to continue their discussions on this subject so that we can come to a resolution. > > To help with starting the discussions, enclosed you'll find the original issue resolution, Jerry's corrective comments, and our meeting minute outcomes. > > Furthermore, the latest versions of the UML 2.0 Infrastructure and Super Structure specifications are available from the OMG website as follows: > > UML 2.0 Superstructure Final Adopted Spec 8/2/2003 > UML 2.0 Superstructure FTF Convenience Doc 10/2/2004 > UML 2.0 Infrastructure Final Adopted Spec 9/15/2003 > The Infrastructure latest convenience, dated 10/14/2004 is listed on the web site but not available for download yet. > > > Thank you. > > Neli Hayes > Software Technical Director and Principal Software Architect > Network Communication Systems > Integrated Defense Systems > The Boeing Company > > 714-762-8768 > persnaz.n.hayes@boeing.com > > > <> > > <> > > <> > > > SWRADIO FTF Issues 7578 and 7579 UML 2 Superstructure Extracts Related to Ports and Interfaces1.doc Issue 7578 7579 Proposed Resolution 2004.10.21 Neli2.doc X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: Final 1st Ballot Vote Date: Wed, 17 Nov 2004 09:17:12 -0800 Message-ID: <829FE9F630965345A75B973E657C27F40C126E@XCH-SW-2V2.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Final 1st Ballot Vote Thread-Index: AcTDL0zl5vomp/hWRiOHDJLpJea0wgJmd+mg From: Gerald_L_Bickle@raytheon.com [mailto:Gerald_L_Bickle@raytheon.com] Sent: Friday, November 05, 2004 4:01 AM To: swradio-ftf@omg.org Subject: Final 1st Ballot Vote OMG Issue No: 7578 & 7579: No, Issue 7579 did not address 7578. The following changes need to be made. What needs to be returned is provided interfaces for provided ports not provided ports. There is no provided Port definition in profile. A provided port can have more than one provided interface. Description changes noted with underlines. provided ports in form of a sequence of names/value pairs, where each name corresponds to a provided port name and interface name, and the corresponding value is the provided port reference to be returned. The getProvidedPorts operation shall return all the component provided ports if the ports argument is zero size. The getProvidedPorts operation shall return only those provided ports specified in the ports argument if the ports argument is not zero size. The getProvidedPorts operation shall support all of the provided ports identified in the component's descriptor. The getProvidedPorts operation shall raise UnknownPorts when one or more provided port names being requested are not known by the component. Change the following types: PortType (providedPortName: String, ProvidedInterfaceName: String, rtSequence PortSequence provides an unbounded sequence of PortType. nvalidPortSequence InvalidPortSequence provides an unbounded sequence of InvalidPortType. Thption>>UnknownPorts (invalidPorts: InvalidPortSequence) The UnknownPorts exception is raised when one or more provided ports being requested are not known by the component. The invalidPorts attribute returned indicates the requested provided ports that were invalid. If PortExistsType is not used for the UnknownPorts exception then move this type of this interface and put a types section in ResourceComponents and move these types there. PortExistType needs to be modified to include provide interface name. PortExistsType (portName: String, providedInterfaceName: String, exists: returnedBoolean) rtExistsSequence PortExistsSequence provides an unbounded sequence of PortExistsType. SWRADIO_FTF_Minutes_Technical_Meeting_DC_2004_11_02_to_11_051.doc PortExistsType defines a structure that associates a provided port name and interface name with a flag indicating whether or not the provided interface exists. exception says only invalid ports are returned. Definition needs to be changed to indicate invalid port and port interface and remove exists indication. Also the exception returned the wrong type. Add the following types: nvalidPortType st for a component. portName: String, ProvidedInterfaceName: String) InvalidPortType defines a structure that indicates the provided port and interface that don providedInterface: ObjectReference) PortType defines a structure that associates a provided interface name with a provided port. Subject: FW: SWRADIO FTF - Issues 7578 and 7579 Date: Sat, 27 Nov 2004 13:35:55 -0800 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: SWRADIO FTF - Issues 7578 and 7579 Thread-Index: AcTMzBjFvtAUeX+6TCWAQAanTY8D5wH5FTKgAAUNmWAAALdUQA== From: "Hayes, Persnaz N" To: Cc: X-OriginalArrivalTime: 27 Nov 2004 21:35:55.0325 (UTC) FILETIME=[137646D0:01C4D4C9] Dear Bran, Could you please review what I have provided below (I have hi-lited in bold italic blue the text that summarizes my understanding of UML 2.0's notion of Ports and Port Interfaces in the 2nd e-mail below) and provide your critique? To summarize, our FTF's question is as follows: In UML 2.0, when asking a component for its provided Ports, is it valid to specify not only the Port name but also the desired interface name for that Port, or is it enough to simply ask for the Port name, as UML 2.0 does not intend for a Port to expose its interfaces? Some group members believe the 1st case is the intended behavior whereas others believe the latter case should be the intended behavior. We plan to model this intent (whichever one is the correct one) in the SWRADIO specification UML Profile. Thank you. With best regards, Neli Hayes Software Technical Director and Principal Software Architect Network Communication Systems Integrated Defense Systems The Boeing Company 714-762-8768 persnaz.n.hayes@boeing.com > ______________________________________________ > From: Hayes, Persnaz N > Sent: Saturday, November 27, 2004 1:04 PM > To: swradio-ftf@omg.org > Subject: SWRADIO FTF - Issues 7578 and 7579 > > Mike, > > Thank you for your input on issues 7578 and 7579 at the November 18th, Telecon. I have them captured below from Tansu's minutes: > > Issue 7578/7579 Comments from November 18, 2004 Telecon > · Mike says he has some issues/ problems with the current proposed solution. > · Are we proposing accessing single interfaces from the ports? Complexity? > · Port based vs Interface based solution > 1 Mike will check UML 2.0 specification to see the approach > 2 Current resolution proposes to access an interface from a port instead of a port being the combined aggregate of interfaces. Mike thinks it might be increased complexity. > 3 Jerry, Neli, comments? > > > I also went ahead and reviewed the UML 2.0 Superstructure Specification and captured the related sections that would answer our questions. Enclosed you'll find related extracts to Ports and Port Interfaces from the latest available version of the UML 2.0 Superstructure Convenience document dated October 2, 2004, that I have captured. I've hi-lited the subsections of interest in bold italic blue. > > > <> > > Based on the UML 2.0 specification, a Port is an interaction point between a classifier's (e.g. a component's) internals and it's environment. These interaction points are grouped by a classifier's provided vs. required services. Furthermore, these interaction points have the option to be more than just singly typed (i.e. single interface) interaction points. They are type-checked interaction points, where the type is defined by the Port's interface. So, in the most generic case, to access a desired port, you need to distinguish between a provided and a required port, need a port name, and also need an interface name, (accounting for the fact the port may support more than one interface). > > The above is 100% in-line with what Jerry has suggested all along, confirms the validity of the issue raised (7578) and with the current proposed resolution along with the corrections suggested by Jerry and myself during the November Technical Meeting. The proposed resolution along with the corrections are captured in my first e-mail below. > > Based on the above, our suggestion is that the above is what needs to be modeled in the SWRADIO specification UML profile, as the UML profile should be kept generic. A particular PIM or PSM can be tailored further to constrain this profile. > > For instance, a specific PSM (for instance the SCA) based on the SWRADIO UML profile, can choose to constraint ports to have only one type, or one interface. In that case, the PSM could be constrained to only ask for port name and not care about the interface name. However, our UML Profile and our PIM (Platform Inde> pendent Model) should handle the generic case, that is account for the fact that a provided port may have more than one interface. > > I hope the above answers the concerns raised at the telecon and also helps you in your research. > > Thanks, > > Neli Hayes > Software Technical Director and Principal Software Architect > Network Communication Systems > Integrated Defense Systems > The Boeing Company > > 714-762-8768 > persnaz.n.hayes@boeing.com > > ______________________________________________ > From: Hayes, Persnaz N > Sent: Wednesday, November 17, 2004 9:37 AM > To: 'swradio-ftf@omg.org' > Subject: SWRADIO FTF - Consensus on Recommended Solution for Issues 7578 and 7579 > > John, Manfred, Dom, Jerry, and Tansu, > > These issues were pulled off the ballot due to a mistake in the submitted resolution. Enclosed, you'll find the original proposed resolution for issues 7578 and 7579 and Jerry's recommended correction on them. > > As discussed per the November Technical Meeting, I intend to incorporate Jerry's comments along with addition of a providedInterfaceName parameter to the PortConnector::connectPort () operation and get the resolution ready for our next ballot. > > However, the team did raise some concerns on whether issue 7578 should even be accepted, that is, whether UML 2.0 really intends for Ports to expose their interfaces, and whether we should go this direction in the SWRADIO spec with PortSupplier::getPort (), and with the SWRADIO deployment entities in charge of connecting the components. > > From all current data at hand, and my discussions with Jerry and Bran Selic, I believe that is the intent and that we should go ahead with the existing resolution and proposed corrections. However, we do need consensus for our suggested resolution to pass the next ballot. > > I would like the team, especially John, Manfred, and Dom who raised concerns about our current direction along with Jerry, myself and Tansu as the main participants to continue their discussions on this subject so that we can come to a resolution. > > To help with starting the discussions, enclosed you'll find the original issue resolution, Jerry's corrective comments, and our meeting minute outcomes. > > Furthermore, the latest versions of the UML 2.0 Infrastructure and Super Structure specifications are available from the OMG website as follows: > > UML 2.0 Superstructure Final Adopted Spec 8/2/2003 > UML 2.0 Superstructure FTF Convenience Doc 10/2/2004 > UML 2.0 Infrastructure Final Adopted Spec 9/15/2003 > The Infrastructure latest convenience, dated 10/14/2004 is listed on the web site but not available for download yet. > > > Thank you. > > Neli Hayes > Software Technical Director and Principal Software Architect > Network Communication Systems > Integrated Defense Systems > The Boeing Company > > 714-762-8768 > persnaz.n.hayes@boeing.com > > > <> > > <> > > <> > > > SWRADIO FTF Issues 7578 and 7579 UML 2 Superstructure Extracts Related to Ports and Interfaces2.doc Issue 7578 7579 Proposed Resolution 2004.10.21 Neli3.doc X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: Final 1st Ballot Vote Date: Wed, 17 Nov 2004 09:17:12 -0800 Message-ID: <829FE9F630965345A75B973E657C27F40C126E@XCH-SW-2V2.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Final 1st Ballot Vote Thread-Index: AcTDL0zl5vomp/hWRiOHDJLpJea0wgJmd+mg From: Gerald_L_Bickle@raytheon.com [mailto:Gerald_L_Bickle@raytheon.com] Sent: Friday, November 05, 2004 4:01 AM To: swradio-ftf@omg.org Subject: Final 1st Ballot Vote OMG Issue No: 7578 & 7579: No, Issue 7579 did not address 7578. The following changes need to be made. What needs to be returned is provided interfaces for provided ports not provided ports. There is no provided Port definition in profile. A provided port can have more than one provided interface. Description changes noted with underlines. provided ports in form of a sequence of names/value pairs, where each name corresponds to a provided port name and interface name, and the corresponding value is the provided port reference to be returned. The getProvidedPorts operation shall return all the component provided ports if the ports argument is zero size. The getProvidedPorts operation shall return only those provided ports specified in the ports argument if the ports argument is not zero size. The getProvidedPorts operation shall support all of the provided ports identified in the component's descriptor. The getProvidedPorts operation shall raise UnknownPorts when one or more provided port names being requested are not known by the component. Change the following types: PortType (providedPortName: String, ProvidedInterfaceName: String, rtSequence PortSequence provides an unbounded sequence of PortType. nvalidPortSequence InvalidPortSequence provides an unbounded sequence of InvalidPortType. Thption>>UnknownPorts (invalidPorts: InvalidPortSequence) The UnknownPorts exception is raised when one or more provided ports being requested are not known by the component. The invalidPorts attribute returned indicates the requested provided ports that were invalid. If PortExistsType is not used for the UnknownPorts exception then move this type of this interface and put a types section in ResourceComponents and move these types there. PortExistType needs to be modified to include provide interface name. PortExistsType (portName: String, providedInterfaceName: String, exists: returnedBoolean) rtExistsSequence PortExistsSequence provides an unbounded sequence of PortExistsType. SWRADIO_FTF_Minutes_Technical_Meeting_DC_2004_11_02_to_11_052.doc PortExistsType defines a structure that associates a provided port name and interface name with a flag indicating whether or not the provided interface exists. exception says only invalid ports are returned. Definition needs to be changed to indicate invalid port and port interface and remove exists indication. Also the exception returned the wrong type. Add the following types: nvalidPortType st for a component. portName: String, ProvidedInterfaceName: String) InvalidPortType defines a structure that indicates the provided port and interface that don providedInterface: ObjectReference) PortType defines a structure that associates a provided interface name with a provided port. Subject: FW: SWRADIO FTF - Issue 7742 (M1 and M2) Discussions Date: Sat, 27 Nov 2004 13:47:18 -0800 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: SWRADIO FTF - Issue 7742 (M1 and M2) Discussions Thread-Index: AcTMzBjFvtAUeX+6TCWAQAanTY8D5wAABbaAAf9lWbA= From: "Hayes, Persnaz N" To: Cc: , "Smith, Jeff" X-OriginalArrivalTime: 27 Nov 2004 21:47:18.0556 (UTC) FILETIME=[AAB30DC0:01C4D4CA] Bran, The SWRADIO FTF would appreciate your review and critique/comments/inputs of the enclosed document. I believe this is an issue that the FTF already asked or is planning to ask for your assistance on. Thank you. Best regards, Neli Hayes Software Technical Director and Principal Software Architect Network Communication Systems Integrated Defense Systems The Boeing Company 714-762-8768 persnaz.n.hayes@boeing.com -----Original Message----- From: Hayes, Persnaz N Sent: Wednesday, November 17, 2004 10:58 AM To: 'swradio-ftf@omg.org'; 'Smith, Jeff' Subject: SWRADIO FTF - Issue 7742 (M1 and M2) Discussions Team, Please review the enclosed document and provide your comments. It addresses concerns, discussions, notes, and proposed direction for solution from our Technical Meeting on this issue, related to whether/how M1 and M2 entities should reside and be documented in the SWRADIO specification UML profile and PIM. We need to continue these related discussions so that we can come up with the correction direction for resolving this issue, and deciding how much, if any, of the correct resolution is in the scope of this FTF. I would appreciate the participation of Jerry, John, Manfred, Dr. Smith, Tansu and myself at a minimum, due to their comments and inputs during the meeting. Thank you. Neli Hayes Software Technical Director and Principal Software Architect Network Communication Systems Integrated Defense Systems The Boeing Company 714-762-8768 persnaz.n.hayes@boeing.com SWRADIO FTF Issue 7742 Discussion Points.doc To: "Hayes, Persnaz N" Cc: swradio-ftf@omg.org Subject: Re: FW: SWRADIO FTF - Issues 7578 and 7579 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 29 Nov 2004 08:31:31 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 11/29/2004 08:31:32, Serialize complete at 11/29/2004 08:31:32 Hi Neli, In reply to your e-mail: > Could you please review what I have provided below (I have hi-lited > in bold italic blue the text that summarizes my understanding of UML > 2.0's notion of Ports and Port Interfaces in the 2nd e-mail below) > and provide your critique? I'll have a look and try to get back to you by the end of the week. Is that OK? > To summarize, our FTF's question is as follows: In UML 2.0, when > asking a component for its provided Ports, is it valid to specify > not only the Port name but also the desired interface name for that > Port, or is it enough to simply ask for the Port name, as UML 2.0 > does not intend for a Port to expose its interfaces? Some group > members believe the 1st case is the intended behavior whereas others > believe the latter case should be the intended behavior. We plan to > model this intent (whichever one is the correct one) in the SWRADIO > specification UML Profile. But, if a port does not expose its interfaces, how are the users of that element going to know how to interact with it? A port has a, possibly empty, set of interfaces that it supports (provides) and a, possibly empty, set of interfaces that it requires (uses). Both of those should be exposed provided that the port has public visibility. I may be misunderstanding the issue, so I'll have a closer look at your document. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com Subject: RE: FW: SWRADIO FTF - Issues 7578 and 7579 Date: Mon, 29 Nov 2004 11:02:09 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: SWRADIO FTF - Issues 7578 and 7579 Thread-Index: AcTWF77u/CBLGphrSkSVbu+0En+z1AAGoCsw From: "Hayes, Persnaz N" To: "Branislav Selic" , X-OriginalArrivalTime: 29 Nov 2004 19:02:09.0486 (UTC) FILETIME=[ED4276E0:01C4D645] Bran, Thank you very much for your prompt follow-up. Yes. It is absolutely ok for you to get back to us when convenient. I believe though that your response does answer our question. It does clarify that a Port can have more than one interface, and that the interface must be known to the outside "user" in order to be able to connect to the Port properly. Any further input is much appreciated. Mike, John, Dom, and Manfred, I believe Bran's response below does answer the question and does confirm that the current direction for solving issues 7578/7579 that Jerry and myself have suggested and I have documented in prior communique's to the group. Please let us know if this answers your concerns and whether we can close the loop on issues 7578/7579 so that I can provide the finalized resolution. Thank you. Neli Hayes The Boeing Company Integrated Defense Systems, Network Communication Systems Principal Software Architect (714) 762-8768 persnaz.n.hayes@boeing.com -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, November 29, 2004 5:32 AM To: Hayes, Persnaz N Cc: swradio-ftf@omg.org Subject: Re: FW: SWRADIO FTF - Issues 7578 and 7579 Hi Neli, In reply to your e-mail: > Could you please review what I have provided below (I have hi-lited > in bold italic blue the text that summarizes my understanding of UML > 2.0's notion of Ports and Port Interfaces in the 2nd e-mail below) > and provide your critique? I'll have a look and try to get back to you by the end of the week. Is that OK? > To summarize, our FTF's question is as follows: In UML 2.0, when > asking a component for its provided Ports, is it valid to specify > not only the Port name but also the desired interface name for that > Port, or is it enough to simply ask for the Port name, as UML 2.0 > does not intend for a Port to expose its interfaces? Some group > members believe the 1st case is the intended behavior whereas others > believe the latter case should be the intended behavior. We plan to > model this intent (whichever one is the correct one) in the SWRADIO > specification UML Profile. But, if a port does not expose its interfaces, how are the users of that element going to know how to interact with it? A port has a, possibly empty, set of interfaces that it supports (provides) and a, possibly empty, set of interfaces that it requires (uses). Both of those should be exposed provided that the port has public visibility. I may be misunderstanding the issue, so I'll have a closer look at your document. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com From: "John Hogg" To: "'Hayes, Persnaz N'" Cc: "'Branislav Selic'" , Subject: RE: FW: SWRADIO FTF - Issues 7578 and 7579 Date: Mon, 29 Nov 2004 15:02:36 -0500 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcTWF77u/CBLGphrSkSVbu+0En+z1AAGoCswAAa6RbA= Neli, I don't believe that we have an answer here yet. Bran's message does not indicate whether he meant an interface definition or a run-time interface instance on a port. Having worked with Bran on this subject on and off since 1990, I strongly suspect that he intended the former--implying that it's not meaningful to connect to an interface instead of a port. At this point I'll stop putting words in his mouth and let Bran speak for himself. Cheers -- John John Hogg Chief Technical Officer Zeligsoft hogg@zeligsoft.com +1 613 324 4358 -------------------------------------------------------------------------------- From: Hayes, Persnaz N [mailto:persnaz.n.hayes@boeing.com] Sent: Monday, November 29, 2004 2:02 PM To: Branislav Selic; swradio-ftf@omg.org Subject: RE: FW: SWRADIO FTF - Issues 7578 and 7579 Bran, Thank you very much for your prompt follow-up. Yes. It is absolutely ok for you to get back to us when convenient. I believe though that your response does answer our question. It does clarify that a Port can have more than one interface, and that the interface must be known to the outside "user" in order to be able to connect to the Port properly. Any further input is much appreciated. Mike, John, Dom, and Manfred, I believe Bran's response below does answer the question and does confirm that the current direction for solving issues 7578/7579 that Jerry and myself have suggested and I have documented in prior communique's to the group. Please let us know if this answers your concerns and whether we can close the loop on issues 7578/7579 so that I can provide the finalized resolution. Thank you. Neli Hayes The Boeing Company Integrated Defense Systems, Network Communication Systems Principal Software Architect (714) 762-8768 persnaz.n.hayes@boeing.com -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, November 29, 2004 5:32 AM To: Hayes, Persnaz N Cc: swradio-ftf@omg.org Subject: Re: FW: SWRADIO FTF - Issues 7578 and 7579 Hi Neli, In reply to your e-mail: > Could you please review what I have provided below (I have hi-lited > in bold italic blue the text that summarizes my understanding of UML > 2.0's notion of Ports and Port Interfaces in the 2nd e-mail below) > and provide your critique? I'll have a look and try to get back to you by the end of the week. Is that OK? > To summarize, our FTF's question is as follows: In UML 2.0, when > asking a component for its provided Ports, is it valid to specify > not only the Port name but also the desired interface name for that > Port, or is it enough to simply ask for the Port name, as UML 2.0 > does not intend for a Port to expose its interfaces? Some group > members believe the 1st case is the intended behavior whereas others > believe the latter case should be the intended behavior. We plan to > model this intent (whichever one is the correct one) in the SWRADIO > specification UML Profile. But, if a port does not expose its interfaces, how are the users of that element going to know how to interact with it? A port has a, possibly empty, set of interfaces that it supports (provides) and a, possibly empty, set of interfaces that it requires (uses). Both of those should be exposed provided that the port has public visibility. I may be misunderstanding the issue, so I'll have a closer look at your document. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com Subject: RE: FW: SWRADIO FTF - Issues 7578 and 7579 Date: Mon, 29 Nov 2004 12:44:35 -0800 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: FW: SWRADIO FTF - Issues 7578 and 7579 Thread-Index: AcTWF77u/CBLGphrSkSVbu+0En+z1AAGoCswAAa6RbAAATeYUA== From: "Hayes, Persnaz N" To: "John Hogg" Cc: "Branislav Selic" , X-OriginalArrivalTime: 29 Nov 2004 20:44:36.0377 (UTC) FILETIME=[3D179890:01C4D654] John, No problem. Thank you for your input. I think you are correct and that we should wait for Bran's input to your question. If Bran's indicating what you have below, then, issue 7578 may ultimately have to be rejected. I'm sure Jerry will have strong objections to that. But, I'll wait till we hear Bran's clarification before entertaining this possibility. However, let me throw in the following: The purpose of PortSupplier::getPort () is to get a component's provided Port(s) so that using PortConnector::connectPort () the component's (Port) can then participate in a connection. Now, from what I see in the UML 2.0 spec, Ports are typed by interfaces. So, if we don't specify the desired Port interface (in addition to the desired Port name) to PortSupplier::getPort (), how would the provider component know which Port (interface) to expose to participate in the connection? This is Jerry's point and having read the UML 2.0 extracts that I had attached in a previous e-mail (I have attached my original mail message which includes the UML 2.0 extracts for convenience), I do agree with him. I'll leave to you and Bran to answer the above question when Bran provides the clarification you have specified below. Thanks again. Sincerely, Neli Hayes The Boeing Company Integrated Defense Systems, Network Communication Systems Principal Software Architect (714) 762-8768 persnaz.n.hayes@boeing.com -----Original Message----- From: John Hogg [mailto:hogg@zeligsoft.com] Sent: Monday, November 29, 2004 12:03 PM To: Hayes, Persnaz N Cc: 'Branislav Selic'; swradio-ftf@omg.org Subject: RE: FW: SWRADIO FTF - Issues 7578 and 7579 Neli, I don't believe that we have an answer here yet. Bran's message does not indicate whether he meant an interface definition or a run-time interface instance on a port. Having worked with Bran on this subject on and off since 1990, I strongly suspect that he intended the former--implying that it's not meaningful to connect to an interface instead of a port. At this point I'll stop putting words in his mouth and let Bran speak for himself. Cheers -- John John Hogg Chief Technical Officer Zeligsoft hogg@zeligsoft.com +1 613 324 4358 -------------------------------------------------------------------------------- From: Hayes, Persnaz N [mailto:persnaz.n.hayes@boeing.com] Sent: Monday, November 29, 2004 2:02 PM To: Branislav Selic; swradio-ftf@omg.org Subject: RE: FW: SWRADIO FTF - Issues 7578 and 7579 Bran, Thank you very much for your prompt follow-up. Yes. It is absolutely ok for you to get back to us when convenient. I believe though that your response does answer our question. It does clarify that a Port can have more than one interface, and that the interface must be known to the outside "user" in order to be able to connect to the Port properly. Any further input is much appreciated. Mike, John, Dom, and Manfred, I believe Bran's response below does answer the question and does confirm that the current direction for solving issues 7578/7579 that Jerry and myself have suggested and I have documented in prior communique's to the group. Please let us know if this answers your concerns and whether we can close the loop on issues 7578/7579 so that I can provide the finalized resolution. Thank you. Neli Hayes The Boeing Company Integrated Defense Systems, Network Communication Systems Principal Software Architect (714) 762-8768 persnaz.n.hayes@boeing.com -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, November 29, 2004 5:32 AM To: Hayes, Persnaz N Cc: swradio-ftf@omg.org Subject: Re: FW: SWRADIO FTF - Issues 7578 and 7579 Hi Neli, In reply to your e-mail: > Could you please review what I have provided below (I have hi-lited > in bold italic blue the text that summarizes my understanding of UML > 2.0's notion of Ports and Port Interfaces in the 2nd e-mail below) > and provide your critique? I'll have a look and try to get back to you by the end of the week. Is that OK? > To summarize, our FTF's question is as follows: In UML 2.0, when > asking a component for its provided Ports, is it valid to specify > not only the Port name but also the desired interface name for that > Port, or is it enough to simply ask for the Port name, as UML 2.0 > does not intend for a Port to expose its interfaces? Some group > members believe the 1st case is the intended behavior whereas others > believe the latter case should be the intended behavior. We plan to > model this intent (whichever one is the correct one) in the SWRADIO > specification UML Profile. But, if a port does not expose its interfaces, how are the users of that element going to know how to interact with it? A port has a, possibly empty, set of interfaces that it supports (provides) and a, possibly empty, set of interfaces that it requires (uses). Both of those should be exposed provided that the port has public visibility. I may be misunderstanding the issue, so I'll have a closer look at your document. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_004_01C4D4C9.1351F315" Subject: FW: SWRADIO FTF - Issues 7578 and 7579 Date: Sat, 27 Nov 2004 13:35:55 -0800 Message-ID: <829FE9F630965345A75B973E657C27F40BF7F8@XCH-SW-2V2.sw.nos.boeing.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: SWRADIO FTF - Issues 7578 and 7579 Thread-Index: AcTMzBjFvtAUeX+6TCWAQAanTY8D5wH5FTKgAAUNmWAAALdUQA== From: "Hayes, Persnaz N" To: Cc: Dear Bran, Could you please review what I have provided below (I have hi-lited in bold italic blue the text that summarizes my understanding of UML 2.0's notion of Ports and Port Interfaces in the 2nd e-mail below) and provide your critique? To summarize, our FTF's question is as follows: In UML 2.0, when asking a component for its provided Ports, is it valid to specify not only the Port name but also the desired interface name for that Port, or is it enough to simply ask for the Port name, as UML 2.0 does not intend for a Port to expose its interfaces? Some group members believe the 1st case is the intended behavior whereas others believe the latter case should be the intended behavior. We plan to model this intent (whichever one is the correct one) in the SWRADIO specification UML Profile. Thank you. With best regards, Neli Hayes Software Technical Director and Principal Software Architect Network Communication Systems Integrated Defense Systems The Boeing Company 714-762-8768 persnaz.n.hayes@boeing.com ______________________________________________ From: Hayes, Persnaz N Sent: Saturday, November 27, 2004 1:04 PM To: swradio-ftf@omg.org Subject: SWRADIO FTF - Issues 7578 and 7579 Mike, Thank you for your input on issues 7578 and 7579 at the November 18th, Telecon. I have them captured below from Tansu's minutes: Issue 7578/7579 Comments from November 18, 2004 Telecon · Mike says he has some issues/ problems with the current proposed solution. · Are we proposing accessing single interfaces from the ports? Complexity? · Port based vs Interface based solution 1 Mike will check UML 2.0 specification to see the approach 2 Current resolution proposes to access an interface from a port instead of a port being the combined aggregate of interfaces. Mike thinks it might be increased complexity. 3 Jerry, Neli, comments? I also went ahead and reviewed the UML 2.0 Superstructure Specification and captured the related sections that would answer our questions. Enclosed you'll find related extracts to Ports and Port Interfaces from the latest available version of the UML 2.0 Superstructure Convenience document dated October 2, 2004, that I have captured. I've hi-lited the subsections of interest in bold italic blue. <> Based on the UML 2.0 specification, a Port is an interaction point between a classifier's (e.g. a component's) internals and it's environment. These interaction points are grouped by a classifier's provided vs. required services. Furthermore, these interaction points have the option to be more than just singly typed (i.e. single interface) interaction points. They are type-checked interaction points, where the type is defined by the Port's interface. So, in the most generic case, to access a desired port, you need to distinguish between a provided and a required port, need a port name, and also need an interface name, (accounting for the fact the port may support more than one interface). The above is 100% in-line with what Jerry has suggested all along, confirms the validity of the issue raised (7578) and with the current proposed resolution along with the corrections suggested by Jerry and myself during the November Technical Meeting. The proposed resolution along with the corrections are captured in my first e-mail below. Based on the above, our suggestion is that the above is what needs to be modeled in the SWRADIO specification UML profile, as the UML profile should be kept generic. A particular PIM or PSM can be tailored further to constrain this profile. For instance, a specific PSM (for instance the SCA) based on the SWRADIO UML profile, can choose to constraint ports to have only one type, or one interface. In that case, the PSM could be constrained to only ask for port name and not care about the interface name. However, our UML Profile and our PIM (Platform Independent Model) should handle the generic case, that is account for the fact that a provided port may have more than one interface. I hope the above answers the concerns raised at the telecon and also helps you in your research. Thanks, Neli Hayes Software Technical Director and Principal Software Architect Network Communication Systems Integrated Defense Systems The Boeing Company 714-762-8768 persnaz.n.hayes@boeing.com ______________________________________________ From: Hayes, Persnaz N Sent: Wednesday, November 17, 2004 9:37 AM To: 'swradio-ftf@omg.org' Subject: SWRADIO FTF - Consensus on Recommended Solution for Issues 7578 and 7579 John, Manfred, Dom, Jerry, and Tansu, These issues were pulled off the ballot due to a mistake in the submitted resolution. Enclosed, you'll find the original proposed resolution for issues 7578 and 7579 and Jerry's recommended correction on them. As discussed per the November Technical Meeting, I intend to incorporate Jerry's comments along with addition of a providedInterfaceName parameter to the PortConnector::connectPort () operation and get the resolution ready for our next ballot. However, the team did raise some concerns on whether issue 7578 should even be accepted, that is, whether UML 2.0 really intends for Ports to expose their interfaces, and whether we should go this direction in the SWRADIO spec with PortSupplier::getPort (), and with the SWRADIO deployment entities in charge of connecting the components. From all current data at hand, and my discussions with Jerry and Bran Selic, I believe that is the intent and that we should go ahead with the existing resolution and proposed corrections. However, we do need consensus for our suggested resolution to pass the next ballot. I would like the team, especially John, Manfred, and Dom who raised concerns about our current direction along with Jerry, myself and Tansu as the main participants to continue their discussions on this subject so that we can come to a resolution. To help with starting the discussions, enclosed you'll find the original issue resolution, Jerry's corrective comments, and our meeting minute outcomes. Furthermore, the latest versions of the UML 2.0 Infrastructure and Super Structure specifications are available from the OMG website as follows: UML 2.0 Superstructure Final Adopted Spec 8/2/2003 UML 2.0 Superstructure FTF Convenience Doc 10/2/2004 UML 2.0 Infrastructure Final Adopted Spec 9/15/2003 The Infrastructure latest convenience, dated 10/14/2004 is listed on the web site but not available for download yet. Thank you. Neli Hayes Software Technical Director and Principal Software Architect Network Communication Systems Integrated Defense Systems The Boeing Company 714-762-8768 persnaz.n.hayes@boeing.com <> <> <> SWRADIO FTF Issues 7578 and 7579 UML 2 Superstructure Extracts Related to Ports and Interfaces3.doc Issue 7578 7579 Proposed Resolution 2004.10.21 Neli4.doc X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C4CCC9.46E43430" Subject: RE: Final 1st Ballot Vote Date: Mon, 29 Nov 2004 12:41:29 -0800 Message-ID: <829FE9F630965345A75B973E657C27F40C126E@XCH-SW-2V2.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Final 1st Ballot Vote Thread-Index: AcTDL0zl5vomp/hWRiOHDJLpJea0wgJmd+mg From: Gerald_L_Bickle@raytheon.com [mailto:Gerald_L_Bickle@raytheon.com] Sent: Friday, November 05, 2004 4:01 AM To: swradio-ftf@omg.org Subject: Final 1st Ballot Vote OMG Issue No: 7578 & 7579: No, Issue 7579 did not address 7578. The following changes need to be made. What needs to be returned is provided interfaces for provided ports not provided ports. There is no provided Port definition in profile. A provided port can have more than one provided interface. Description changes noted with underlines. The getProvidedPorts operation provides a mechanism to obtain a componentfs provided ports in form of a sequence of names/value pairs, where each name corresponds to a provided portfs name and interface name, and the corresponding value is the provided port reference to be returned. The getProvidedPorts operation shall return all the component provided ports if the ports argument is zero size. The getProvidedPorts operation shall return only those provided ports specified in the ports argument if the ports argument is not zero size. The getProvidedPorts operation shall support all of the provided ports identified in the component's descriptor. The getProvidedPorts operation shall raise UnknownPorts when one or more provided port names being requested are not known by the component. Change the following types: PortType (providedPortName: String, ProvidedInterfaceName: String, providedInterface: ObjectReference) PortType defines a structure that associates a provided interface name with a provided port. . PortSequence PortSequence provides an unbounded sequence of PortType. The returned exception says only invalid ports are returned. Definition needs to be changed to indicate invalid port and port interface and remove exists indication. Also the exception returned the wrong type. Add the following types: . InvalidPortType (portName: String, ProvidedInterfaceName: String) InvalidPortType defines a structure that indicates the provided port and interface that donft exist for a component. . InvalidPortSequence InvalidPortSequence provides an unbounded sequence of InvalidPortType. . <>UnknownPorts (invalidPorts: InvalidPortSequence) The UnknownPorts exception is raised when one or more provided ports being requested are not known by the component. The invalidPorts attribute returned indicates the requested provided ports that were invalid. If PortExistsType is not used for the UnknownPorts exception then move this type of this interface and put a types section in ResourceComponents and move these types there. PortExistType needs to be modified to include provide interface name. PortExistsType (portName: String, providedInterfaceName: String, exists: Boolean) PortExistsType defines a structure that associates a provided port name and interface name with a flag indicating whether or not the provided interface exists. . PortExistsSequence PortExistsSequence provides an unbounded sequence of PortExistsType. SWRADIO_FTF_Minutes_Technical_Meeting_DC_2004_11_02_to_11_053.doc To: "Hayes, Persnaz N" Cc: "John Hogg" , swradio-ftf@omg.org Subject: RE: FW: SWRADIO FTF - Issues 7578 and 7579 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 29 Nov 2004 17:12:32 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 11/29/2004 17:12:34, Serialize complete at 11/29/2004 17:12:34 SW Radio Folks, There is something not quite kosher in the text for issue 7578 which states: Unable to retrieve a specific provided interface for a port (PortSupplier getPort operation) Proposed Solution: Add additional parameter to the getPort operation to qualify which provided interface object reference is needed from the getPort operation. Rationale: A provided port can have multiple interfaces The problem is that interfaces are abstract by definition, which means that you cannot have an instance of an interface. So, it is not meaningful to talk about an "interface object reference". If some object (such as a port) realizes (provides) multiple interfaces, you cannot use an object reference to distinguish between the interfaces. Instead, you can use qualified names to access the features of one or the other realized interface. For instance, consider the following two interface definitions: Interface A { op1( ) : tA1; op2( ) : tA2; } Interface B { op1( ) : tB1; op2( ) : tB2; } Then, if some object P realizes both interface A and interface B, you could use an expression such as P.(B::op1( )) to access the "op1" that is defined for Interface B. Note, however, that this distinction is on a per-feature basis and not on a per-interface basis. In a way, it is equivalent in effect to the situation where port P realizes the merged interface: Interface C inherits A, B{ A::op1( ) : tA1; A::op2( ) : tA2; B::op1( ) : tB1; B::op2( ) : tB2; } (I have oversimplified things a bit above, but mainly to better illustrate my point). However, speaking in general and based on my experience, IF YOU ARE USING PORTS, there is really no good reason to have a port realize more than one interface (that capability was included purely for the sake of abstract generality). The whole idea of ports is to separate different kinds of collaborators (which is also the reason why we distinguish one kind of interface from another). If you start merging them, you are defeating the primary purpose of ports. I am not sure whether this answers your questions, or at least starts to answer your questions. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Hayes, Persnaz N" 11/29/2004 03:44 PM To "John Hogg" cc Branislav Selic/Ottawa/IBM@IBMCA, Subject RE: FW: SWRADIO FTF - Issues 7578 and 7579 John, No problem. Thank you for your input. I think you are correct and that we should wait for Bran's input to your question. If Bran's indicating what you have below, then, issue 7578 may ultimately have to be rejected. I'm sure Jerry will have strong objections to that. But, I'll wait till we hear Bran's clarification before entertaining this possibility. However, let me throw in the following: The purpose of PortSupplier::getPort () is to get a component's provided Port(s) so that using PortConnector::connectPort () the component's (Port) can then participate in a connection. Now, from what I see in the UML 2.0 spec, Ports are typed by interfaces. So, if we don't specify the desired Port interface (in addition to the desired Port name) to PortSupplier::getPort (), how would the provider component know which Port (interface) to expose to participate in the connection? This is Jerry's point and having read the UML 2.0 extracts that I had attached in a previous e-mail (I have attached my original mail message which includes the UML 2.0 extracts for convenience), I do agree with him. I'll leave to you and Bran to answer the above question when Bran provides the clarification you have specified below. Thanks again. Sincerely, Neli Hayes The Boeing Company Integrated Defense Systems, Network Communication Systems Principal Software Architect (714) 762-8768 persnaz.n.hayes@boeing.com -----Original Message----- From: John Hogg [mailto:hogg@zeligsoft.com] Sent: Monday, November 29, 2004 12:03 PM To: Hayes, Persnaz N Cc: 'Branislav Selic'; swradio-ftf@omg.org Subject: RE: FW: SWRADIO FTF - Issues 7578 and 7579 Neli, I don't believe that we have an answer here yet. Bran's message does not indicate whether he meant an interface definition or a run-time interface instance on a port. Having worked with Bran on this subject on and off since 1990, I strongly suspect that he intended the former--implying that it's not meaningful to connect to an interface instead of a port. At this point I'll stop putting words in his mouth and let Bran speak for himself. Cheers -- John John Hogg Chief Technical Officer Zeligsoft hogg@zeligsoft.com +1 613 324 4358 -------------------------------------------------------------------------------- From: Hayes, Persnaz N [mailto:persnaz.n.hayes@boeing.com] Sent: Monday, November 29, 2004 2:02 PM To: Branislav Selic; swradio-ftf@omg.org Subject: RE: FW: SWRADIO FTF - Issues 7578 and 7579 Bran, Thank you very much for your prompt follow-up. Yes. It is absolutely ok for you to get back to us when convenient. I believe though that your response does answer our question. It does clarify that a Port can have more than one interface, and that the interface must be known to the outside "user" in order to be able to connect to the Port properly. Any further input is much appreciated. Mike, John, Dom, and Manfred, I believe Bran's response below does answer the question and does confirm that the current direction for solving issues 7578/7579 that Jerry and myself have suggested and I have documented in prior communique's to the group. Please let us know if this answers your concerns and whether we can close the loop on issues 7578/7579 so that I can provide the finalized resolution. Thank you. Neli Hayes The Boeing Company Integrated Defense Systems, Network Communication Systems Principal Software Architect (714) 762-8768 persnaz.n.hayes@boeing.com -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, November 29, 2004 5:32 AM To: Hayes, Persnaz N Cc: swradio-ftf@omg.org Subject: Re: FW: SWRADIO FTF - Issues 7578 and 7579 Hi Neli, In reply to your e-mail: > Could you please review what I have provided below (I have hi-lited > in bold italic blue the text that summarizes my understanding of UML > 2.0's notion of Ports and Port Interfaces in the 2nd e-mail below) > and provide your critique? I'll have a look and try to get back to you by the end of the week. Is that OK? > To summarize, our FTF's question is as follows: In UML 2.0, when > asking a component for its provided Ports, is it valid to specify > not only the Port name but also the desired interface name for that > Port, or is it enough to simply ask for the Port name, as UML 2.0 > does not intend for a Port to expose its interfaces? Some group > members believe the 1st case is the intended behavior whereas others > believe the latter case should be the intended behavior. We plan to > model this intent (whichever one is the correct one) in the SWRADIO > specification UML Profile. But, if a port does not expose its interfaces, how are the users of that element going to know how to interact with it? A port has a, possibly empty, set of interfaces that it supports (provides) and a, possibly empty, set of interfaces that it requires (uses). Both of those should be exposed provided that the port has public visibility. I may be misunderstanding the issue, so I'll have a closer look at your document. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com ----- Message from "Hayes, Persnaz N" on Sat, 27 Nov 2004 13:35:55 -0800 ----- To: cc: Subject: FW: SWRADIO FTF - Issues 7578 and 7579 Dear Bran, Could you please review what I have provided below (I have hi-lited in bold italic blue the text that summarizes my understanding of UML 2.0's notion of Ports and Port Interfaces in the 2nd e-mail below) and provide your critique? To summarize, our FTF's question is as follows: In UML 2.0, when asking a component for its provided Ports, is it valid to specify not only the Port name but also the desired interface name for that Port, or is it enough to simply ask for the Port name, as UML 2.0 does not intend for a Port to expose its interfaces? Some group members believe the 1st case is the intended behavior whereas others believe the latter case should be the intended behavior. We plan to model this intent (whichever one is the correct one) in the SWRADIO specification UML Profile. Thank you. With best regards, Neli Hayes Software Technical Director and Principal Software Architect Network Communication Systems Integrated Defense Systems The Boeing Company 714-762-8768 persnaz.n.hayes@boeing.com ______________________________________________ From: Hayes, Persnaz N Sent: Saturday, November 27, 2004 1:04 PM To: swradio-ftf@omg.org Subject: SWRADIO FTF - Issues 7578 and 7579 Mike, Thank you for your input on issues 7578 and 7579 at the November 18th, Telecon. I have them captured below from Tansu's minutes: Issue 7578/7579 Comments from November 18, 2004 Telecon · Mike says he has some issues/ problems with the current proposed solution. · Are we proposing accessing single interfaces from the ports? Complexity? · Port based vs Interface based solution 1 Mike will check UML 2.0 specification to see the approach 2 Current resolution proposes to access an interface from a port instead of a port being the combined aggregate of interfaces. Mike thinks it might be increased complexity. 3 Jerry, Neli, comments? I also went ahead and reviewed the UML 2.0 Superstructure Specification and captured the related sections that would answer our questions. Enclosed you'll find related extracts to Ports and Port Interfaces from the latest available version of the UML 2.0 Superstructure Convenience document dated October 2, 2004, that I have captured. I've hi-lited the subsections of interest in bold italic blue. <> Based on the UML 2.0 specification, a Port is an interaction point between a classifier's (e.g. a component's) internals and it's environment. These interaction points are grouped by a classifier's provided vs. required services. Furthermore, these interaction points have the option to be more than just singly typed (i.e. single interface) interaction points. They are type-checked interaction points, where the type is defined by the Port's interface. So, in the most generic case, to access a desired port, you need to distinguish between a provided and a required port, need a port name, and also need an interface name, (accounting for the fact the port may support more than one interface). The above is 100% in-line with what Jerry has suggested all along, confirms the validity of the issue raised (7578) and with the current proposed resolution along with the corrections suggested by Jerry and myself during the November Technical Meeting. The proposed resolution along with the corrections are captured in my first e-mail below. Based on the above, our suggestion is that the above is what needs to be modeled in the SWRADIO specification UML profile, as the UML profile should be kept generic. A particular PIM or PSM can be tailored further to constrain this profile. For instance, a specific PSM (for instance the SCA) based on the SWRADIO UML profile, can choose to constraint ports to have only one type, or one interface. In that case, the PSM could be constrained to only ask for port name and not care about the interface name. However, our UML Profile and our PIM (Platform Independent Model) should handle the generic case, that is account for the fact that a provided port may have more than one interface. I hope the above answers the concerns raised at the telecon and also helps you in your research. Thanks, Neli Hayes Software Technical Director and Principal Software Architect Network Communication Systems Integrated Defense Systems The Boeing Company 714-762-8768 persnaz.n.hayes@boeing.com ______________________________________________ From: Hayes, Persnaz N Sent: Wednesday, November 17, 2004 9:37 AM To: 'swradio-ftf@omg.org' Subject: SWRADIO FTF - Consensus on Recommended Solution for Issues 7578 and 7579 John, Manfred, Dom, Jerry, and Tansu, These issues were pulled off the ballot due to a mistake in the submitted resolution. Enclosed, you'll find the original proposed resolution for issues 7578 and 7579 and Jerry's recommended correction on them. As discussed per the November Technical Meeting, I intend to incorporate Jerry's comments along with addition of a providedInterfaceName parameter to the PortConnector::connectPort () operation and get the resolution ready for our next ballot. However, the team did raise some concerns on whether issue 7578 should even be accepted, that is, whether UML 2.0 really intends for Ports to expose their interfaces, and whether we should go this direction in the SWRADIO spec with PortSupplier::getPort (), and with the SWRADIO deployment entities in charge of connecting the components. From all current data at hand, and my discussions with Jerry and Bran Selic, I believe that is the intent and that we should go ahead with the existing resolution and proposed corrections. However, we do need consensus for our suggested resolution to pass the next ballot. I would like the team, especially John, Manfred, and Dom who raised concerns about our current direction along with Jerry, myself and Tansu as the main participants to continue their discussions on this subject so that we can come to a resolution. To help with starting the discussions, enclosed you'll find the original issue resolution, Jerry's corrective comments, and our meeting minute outcomes. Furthermore, the latest versions of the UML 2.0 Infrastructure and Super Structure specifications are available from the OMG website as follows: UML 2.0 Superstructure Final Adopted Spec 8/2/2003 UML 2.0 Superstructure FTF Convenience Doc 10/2/2004 UML 2.0 Infrastructure Final Adopted Spec 9/15/2003 The Infrastructure latest convenience, dated 10/14/2004 is listed on the web site but not available for download yet. Thank you. Neli Hayes Software Technical Director and Principal Software Architect Network Communication Systems Integrated Defense Systems The Boeing Company 714-762-8768 persnaz.n.hayes@boeing.com <> <> <> [attachment "SWRADIO FTF Issues 7578 and 7579 UML 2 Superstructure Extracts Related to Ports and Interfaces.doc" deleted by Branislav Selic/Ottawa/IBM] [attachment "Issue 7578 7579 Proposed Resolution 2004.10.21 Neli.doc" deleted by Branislav Selic/Ottawa/IBM] ----- Message from Unknown on Mon, 29 Nov 2004 12:41:29 -0800 ----- Subject: RE: Final 1st Ballot Vote From: Gerald_L_Bickle@raytheon.com [mailto:Gerald_L_Bickle@raytheon.com] Sent: Friday, November 05, 2004 4:01 AM To: swradio-ftf@omg.org Subject: Final 1st Ballot Vote OMG Issue No: 7578 & 7579: No, Issue 7579 did not address 7578. The following changes need to be made. What needs to be returned is provided interfaces for provided ports not provided ports. There is no provided Port definition in profile. A provided port can have more than one provided interface. Description changes noted with underlines. The getProvidedPorts operation provides a mechanism to obtain a componenfs provided ports in form of a sequence of names/value pairs, where each name corresponds to a provided porfs name and interface name, and the corresponding value is the provided port reference to be returned. The getProvidedPorts operation shall return all the component provided ports if the ports argument is zero size. The getProvidedPorts operation shall return only those provided ports specified in the ports argument if the ports argument is not zero size. The getProvidedPorts operation shall support all of the provided ports identified in the component's descriptor. The getProvidedPorts operation shall raise UnknownPorts when one or more provided port names being requested are not known by the component. Change the following types: PortType (providedPortName: String, ProvidedInterfaceName: String, providedInterface: ObjectReference) P returnedortType defines a structure that associates a provided interface name with a provided port. rtSequence PortSequence provides an unbounded sequence of PortType. The returned exception says only invalid ports are returned. Definition needs to be changed to indicate invalid port and port interface and remove exists indication. Also the exception returned the wrong type. Add the following types: . InvalidPortType (portName: String, ProvidedInterfaceName: String) InvalidPortType defines a structure that indicates the provided port and interface that doft exist for a component.. InvalidPortSequence InvalidPortSequence provides an unbounded sequence of InvalidPortType. . <>UnknownPorts (invalidPorts: InvalidPortSequence) The UnknownPorts exception is raised when one or more provided ports being requested are not known by the component. The invalidPorts attribute returned indicates the requested provided ports that were invalid. If PortExistsType is not used for the UnknownPorts exception then move this type of this interface and put a types section in ResourceComponents and move these types there. PortExistType needs to be modified to include provide interface name. PortExistsType (portName: String, providedInterfaceName: String, exists: Boolean) PortExistsType defines a structure that associates a provided port name and interface name with a flag indicating whether or not the provided interface exists.. PortExistsSequence PortExistsSequence provides an unbounded sequence of PortExistsType.[attachment "SWRADIO_FTF_Minutes_Technical_Meeting_DC_2004_11_02_to_11_05.doc" deleted by Branislav Selic/Ottawa/IBM] From: "John Hogg" To: "'Hayes, Persnaz N'" Cc: "'Branislav Selic'" , Subject: RE: FW: SWRADIO FTF - Issues 7578 and 7579 Date: Mon, 29 Nov 2004 18:08:22 -0500 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcTWF77u/CBLGphrSkSVbu+0En+z1AAGoCswAAa6RbAAATeYUAACCzXA Neli, Thanks for extracting portions of the UML 2.0 superstructure specification and furthermore for highlighting relevant sentences. I'll go one stage further and single out some key words: "a provided Interface...is the TYPE of a provided Port...". That word "type" (emphasis mine) is critical. There is no run-time manifestation of an interface as a separate entity; it merely types the port to which it is assigned. If there are multiple provided interfaces on a port then the port's type is the union of these. For instance, given a Control interface with start() and stop() and a Data interface with data(), a port P with provides interfaces Control and Data will provide start(), stop() and data() operations (or understand these messages or methods or your domain-dependent nomenclature of choice). In a clean design, this issue will be moot. In this example mixing control and data is generally iffy. They should be two separate ports at design time (although all sorts of optimizations can occur during transformations). I would strongly support constraining ports to have a single interface in either direction. Given these misunderstandings, I will lead that charge if I see anybody lining up behind me. If we do indeed support multiple provides interfaces on a port, the complexity doesn't occur in getPort(); it occurs in connectPort() for the (CORBA) PSM. There are several possible solutions, but I'd prefer to sidestep them all. Cheers -- John John Hogg Chief Technical Officer Zeligsoft hogg@zeligsoft.com +1 613 324 4358 -------------------------------------------------------------------------------- From: Hayes, Persnaz N [mailto:persnaz.n.hayes@boeing.com] Sent: Monday, November 29, 2004 3:45 PM To: John Hogg Cc: Branislav Selic; swradio-ftf@omg.org Subject: RE: FW: SWRADIO FTF - Issues 7578 and 7579 John, No problem. Thank you for your input. I think you are correct and that we should wait for Bran's input to your question. If Bran's indicating what you have below, then, issue 7578 may ultimately have to be rejected. I'm sure Jerry will have strong objections to that. But, I'll wait till we hear Bran's clarification before entertaining this possibility. However, let me throw in the following: The purpose of PortSupplier::getPort () is to get a component's provided Port(s) so that using PortConnector::connectPort () the component's (Port) can then participate in a connection. Now, from what I see in the UML 2.0 spec, Ports are typed by interfaces. So, if we don't specify the desired Port interface (in addition to the desired Port name) to PortSupplier::getPort (), how would the provider component know which Port (interface) to expose to participate in the connection? This is Jerry's point and having read the UML 2.0 extracts that I had attached in a previous e-mail (I have attached my original mail message which includes the UML 2.0 extracts for convenience), I do agree with him. I'll leave to you and Bran to answer the above question when Bran provides the clarification you have specified below. Thanks again. Sincerely, Neli Hayes The Boeing Company Integrated Defense Systems, Network Communication Systems Principal Software Architect (714) 762-8768 persnaz.n.hayes@boeing.com -----Original Message----- From: John Hogg [mailto:hogg@zeligsoft.com] Sent: Monday, November 29, 2004 12:03 PM To: Hayes, Persnaz N Cc: 'Branislav Selic'; swradio-ftf@omg.org Subject: RE: FW: SWRADIO FTF - Issues 7578 and 7579 Neli, I don't believe that we have an answer here yet. Bran's message does not indicate whether he meant an interface definition or a run-time interface instance on a port. Having worked with Bran on this subject on and off since 1990, I strongly suspect that he intended the former--implying that it's not meaningful to connect to an interface instead of a port. At this point I'll stop putting words in his mouth and let Bran speak for himself. Cheers -- John John Hogg Chief Technical Officer Zeligsoft hogg@zeligsoft.com +1 613 324 4358 -------------------------------------------------------------------------------- From: Hayes, Persnaz N [mailto:persnaz.n.hayes@boeing.com] Sent: Monday, November 29, 2004 2:02 PM To: Branislav Selic; swradio-ftf@omg.org Subject: RE: FW: SWRADIO FTF - Issues 7578 and 7579 Bran, Thank you very much for your prompt follow-up. Yes. It is absolutely ok for you to get back to us when convenient. I believe though that your response does answer our question. It does clarify that a Port can have more than one interface, and that the interface must be known to the outside "user" in order to be able to connect to the Port properly. Any further input is much appreciated. Mike, John, Dom, and Manfred, I believe Bran's response below does answer the question and does confirm that the current direction for solving issues 7578/7579 that Jerry and myself have suggested and I have documented in prior communique's to the group. Please let us know if this answers your concerns and whether we can close the loop on issues 7578/7579 so that I can provide the finalized resolution. Thank you. Neli Hayes The Boeing Company Integrated Defense Systems, Network Communication Systems Principal Software Architect (714) 762-8768 persnaz.n.hayes@boeing.com -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, November 29, 2004 5:32 AM To: Hayes, Persnaz N Cc: swradio-ftf@omg.org Subject: Re: FW: SWRADIO FTF - Issues 7578 and 7579 Hi Neli, In reply to your e-mail: > Could you please review what I have provided below (I have hi-lited > in bold italic blue the text that summarizes my understanding of UML > 2.0's notion of Ports and Port Interfaces in the 2nd e-mail below) > and provide your critique? I'll have a look and try to get back to you by the end of the week. Is that OK? > To summarize, our FTF's question is as follows: In UML 2.0, when > asking a component for its provided Ports, is it valid to specify > not only the Port name but also the desired interface name for that > Port, or is it enough to simply ask for the Port name, as UML 2.0 > does not intend for a Port to expose its interfaces? Some group > members believe the 1st case is the intended behavior whereas others > believe the latter case should be the intended behavior. We plan to > model this intent (whichever one is the correct one) in the SWRADIO > specification UML Profile. But, if a port does not expose its interfaces, how are the users of that element going to know how to interact with it? A port has a, possibly empty, set of interfaces that it supports (provides) and a, possibly empty, set of interfaces that it requires (uses). Both of those should be exposed provided that the port has public visibility. I may be misunderstanding the issue, so I'll have a closer look at your document. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com Subject: RE: FW: SWRADIO FTF - Issues 7578 and 7579 To: Branislav Selic Cc: "John Hogg" , "Hayes, Persnaz N" , swradio-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Gerald_L_Bickle@raytheon.com Date: Tue, 30 Nov 2004 07:50:17 -0500 X-MIMETrack: Serialize by Router on NotesServer3/HDC(Release 6.5.2|June 01, 2004) at 11/30/2004 07:55:31 AM X-SPAM: 0.00 X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id iAUCvLHB025818 Your last sentence "Instead, you can use qualified names to access the features of one or the other realized interface." is the intend of modifying the getport by adding a qualified input name to indicate to the port what you are trying to retrieved. Can you not ask a port based upon a qualified name (e.g., interface name) to obtain a reference of some element that realizes that interface instead of specific feature of an interface? I don't see why the restriction to a specific feature when one may want the whole capabilities of an interface that an object is realizing. Jerry Bickle Engineering Fellow Network Centric Systems 1010 Production Rd Fort Wayne, IN 46808-4711 260-429-6280 260-429-5060 Fax Branislav Selic m> cc: "John Hogg" , swradio-ftf@omg.org Subject: RE: FW: SWRADIO FTF - Issues 7578 and 7579 11/29/2004 05:12 PM SW Radio Folks, There is something not quite kosher in the text for issue 7578 which states: Unable to retrieve a specific provided interface for a port (PortSupplier getPort operation) Proposed Solution: Add additional parameter to the getPort operation to qualify which provided interface object reference is needed from the getPort operation. Rationale: A provided port can have multiple interfaces The problem is that interfaces are abstract by definition, which means that you cannot have an instance of an interface. So, it is not meaningful to talk about an "interface object reference". If some object (such as a port) realizes (provides) multiple interfaces, you cannot use an object reference to distinguish between the interfaces. Instead, you can use qualified names to access the features of one or the other realized interface. For instance, consider the following two interface definitions: Interface A { op1( ) : tA1; op2( ) : tA2; } Interface B { op1( ) : tB1; op2( ) : tB2; } Then, if some object P realizes both interface A and interface B, you could use an expression such as P.(B::op1( )) to access the "op1" that is defined for Interface B. Note, however, that this distinction is on a per-feature basis and not on a per-interface basis. In a way, it is equivalent in effect to the situation where port P realizes the merged interface: Interface C inherits A, B{ A::op1( ) : tA1; A::op2( ) : tA2; B::op1( ) : tB1; B::op2( ) : tB2; } (I have oversimplified things a bit above, but mainly to better illustrate my point). However, speaking in general and based on my experience, IF YOU ARE USING PORTS, there is really no good reason to have a port realize more than one interface (that capability was included purely for the sake of abstract generality). The whole idea of ports is to separate different kinds of collaborators (which is also the reason why we distinguish one kind of interface from another). If you start merging them, you are defeating the primary purpose of ports. I am not sure whether this answers your questions, or at least starts to answer your questions. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Hayes, Persnaz N" To 11/29/2004 03:44 PM "John Hogg" cc Branislav Selic/Ottawa/IBM@IBMCA, Subject RE: FW: SWRADIO FTF - Issues 7578 and 7579 John, No problem. Thank you for your input. I think you are correct and that we should wait for Bran's input to your question. If Bran's indicating what you have below, then, issue 7578 may ultimately have to be rejected. I'm sure Jerry will have strong objections to that. But, I'll wait till we hear Bran's clarification before entertaining this possibility. However, let me throw in the following: The purpose of PortSupplier::getPort () is to get a component's provided Port(s) so that using PortConnector::connectPort () the component's (Port) can then participate in a connection. Now, from what I see in the UML 2.0 spec, Ports are typed by interfaces. So, if we don't specify the desired Port interface (in addition to the desired Port name) to PortSupplier::getPort (), how would the provider component know which Port (interface) to expose to participate in the connection? This is Jerry's point and having read the UML 2.0 extracts that I had attached in a previous e-mail (I have attached my original mail message which includes the UML 2.0 extracts for convenience), I do agree with him. I'll leave to you and Bran to answer the above question when Bran provides the clarification you have specified below. Thanks again. Sincerely, Neli Hayes The Boeing Company Integrated Defense Systems, Network Communication Systems Principal Software Architect (714) 762-8768 persnaz.n.hayes@boeing.com -----Original Message----- From: John Hogg [mailto:hogg@zeligsoft.com] Sent: Monday, November 29, 2004 12:03 PM To: Hayes, Persnaz N Cc: 'Branislav Selic'; swradio-ftf@omg.org Subject: RE: FW: SWRADIO FTF - Issues 7578 and 7579 Neli, I don't believe that we have an answer here yet. Bran's message does not indicate whether he meant an interface definition or a run-time interface instance on a port. Having worked with Bran on this subject on and off since 1990, I strongly suspect that he intended the former--implying that it's not meaningful to connect to an interface instead of a port. At this point I'll stop putting words in his mouth and let Bran speak for himself. Cheers -- John John Hogg Chief Technical Officer Zeligsoft hogg@zeligsoft.com +1 613 324 4358 From: Hayes, Persnaz N [mailto:persnaz.n.hayes@boeing.com] Sent: Monday, November 29, 2004 2:02 PM To: Branislav Selic; swradio-ftf@omg.org Subject: RE: FW: SWRADIO FTF - Issues 7578 and 7579 Bran, Thank you very much for your prompt follow-up. Yes. It is absolutely ok for you to get back to us when convenient. I believe though that your response does answer our question. It does clarify that a Port can have more than one interface, and that the interface must be known to the outside "user" in order to be able to connect to the Port properly. Any further input is much appreciated. Mike, John, Dom, and Manfred, I believe Bran's response below does answer the question and does confirm that the current direction for solving issues 7578/7579 that Jerry and myself have suggested and I have documented in prior communique's to the group. Please let us know if this answers your concerns and whether we can close the loop on issues 7578/7579 so that I can provide the finalized resolution. Thank you. Neli Hayes The Boeing Company Integrated Defense Systems, Network Communication Systems Principal Software Architect (714) 762-8768 persnaz.n.hayes@boeing.com -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, November 29, 2004 5:32 AM To: Hayes, Persnaz N Cc: swradio-ftf@omg.org Subject: Re: FW: SWRADIO FTF - Issues 7578 and 7579 Hi Neli, In reply to your e-mail: > Could you please review what I have provided below (I have hi-lited > in bold italic blue the text that summarizes my understanding of UML > 2.0's notion of Ports and Port Interfaces in the 2nd e-mail below) > and provide your critique? I'll have a look and try to get back to you by the end of the week. Is that OK? > To summarize, our FTF's question is as follows: In UML 2.0, when > asking a component for its provided Ports, is it valid to specify > not only the Port name but also the desired interface name for that > Port, or is it enough to simply ask for the Port name, as UML 2.0 > does not intend for a Port to expose its interfaces? Some group > members believe the 1st case is the intended behavior whereas others > believe the latter case should be the intended behavior. We plan to > model this intent (whichever one is the correct one) in the SWRADIO > specification UML Profile. But, if a port does not expose its interfaces, how are the users of that element going to know how to interact with it? A port has a, possibly empty, set of interfaces that it supports (provides) and a, possibly empty, set of interfaces that it requires (uses). Both of those should be exposed provided that the port has public visibility. I may be misunderstanding the issue, so I'll have a closer look at your document. Cheers, Bran Selic IBM Distinguished