Issue 7579: Obtaining resource provided interfaces during deployment (swradio-ftf) Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com) Nature: Uncategorized Issue Severity: Summary: Obtaining resource provided interfaces during deployment. Does it make sense to retrieve a set of provided interfaces from a resource? Proposed Solution: Modify getPort operation to return a list back or add a new operation. Rationale: Efficiency could be achieved by returning all the provided or the requested interfaces from a resource thus eliminating multiple calls to a resource. Resolution: Revised Text: Resolution: As per resolution of issue 7953, the definition of Port in the UML Profile for Software Radio is restricted to at most 1 provided and 1 required interface. As such, a provided port which is the return result of this operation will have only one interface. However, as it is possible for a component to have more than one provided port, PortSupplier::getPort operation will be modified to allow to retrieve a set of one or more desired provided ports for a component. Another consideration in support of the above resolution is performance efficiency. The getPort operation will be used quite frequently to retrieve the set of provided ports for a component during application instantiation for component connections. Having an operation that can return a list back, vs. numerous calls to return a provided port back one at a time is a lot more efficient. In implementing the above change, the getPort operation should behave like PropertySet::query and provide the implementers with the option to return all provided interfaces or just one. This also provides backward compatibility with the SCA and familiarity for SCA developers who are comfortable with the SCA CF::PropertySet interface. Additionally, the name of the operation should be modified to reflect the true intent of the operation, which will be to return a set of one or more provided ports for a component. Revised Text: 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, objectRef: Port) PortType defines a structure that associates a name with a port. PortSequence PortSequence provides an unbounded sequence of PortType. 4. Section 8.1.4.5 (PortSupplier), Types and Exceptions Section Change the UnknownPort exception as follows: From "<<exception>>UnknownPort The UnknownPort exception is raised if an undefined provided port is request-ed." To "<<exception>>UnknownPorts (invalidPorts: StringSequence) 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.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." 6. 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." 7. ManagedCommChannel Description Modify 9.6.1.3 ManagedCommChannel Description section From "The <<commchannel>> ManagedCommChannel component takes on the definition as described in the UML Profile for SWRadio::Infrastructure::Radio Management in addition to the specializations of the CommChannel and ManagedServiceComponent (UML Profile for SWRadio::Infrastructure::Radio Services)." To "The <<managedservicecomponent>> ManagedCommChannel component takes on the definition as described in the UML Profile for SWRadio::Infrastructure::Radio Services in addition to the specialization of the CommChannel." 8. ManagedRadioManager Description Modify 9.6.1.4 ManagedRadioManager Description section From "The <<radiomanager>> ManagedRadioManager component takes on the definition as described in the UML Pro- file for SWRadio::Infrastructure::Radio Management in addition to the specializations of the RadioManager and ManagedServiceComponent (UML Profile for SWRadio::Infrastructure::Radio Services). The ManagedRadioManager provides the mechanism of a managed RadioManager with state behavior." To "The <<managedservicecomponent>> ManagedRadioManager component takes on the definition as described in the UML Profile for SWRadio::Infrastructure::Radio Services in addition to the specialization of the RadioManager. The ManagedRadioManager provides the mechanism for a managed RadioManager with state behavior." 9. Rose Model and IDL Files Reflect the described changes to PortSupplier, DomainManager, and DeviceManager in the Rose Model and IDL files. Actions taken: July 13, 2004: received issue August 2, 2005: closed issue Discussion: End of Annotations:===== ssue 2. Obtaining resource provided interfaces during deployment. Does it make sense to retrieve a set of provided interfaces from a resource? Proposed Solution: Modify getPort operation to return a list back or add a new operation. Rationale: Efficiency could be achieved by returning all the provided or the requested interfaces from a resource thus eliminating multiple calls to a resource. Subject: SWRADIO FTF - Proposed Solution for Issue 7579 Date: Mon, 26 Jul 2004 14:12:35 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SWRADIO FTF - Proposed Solution for Issue 7579 Thread-Index: AcRzVUYFOatAFuRTSlGZpQp+HUcj8g== From: "Hayes, Persnaz N" To: X-OriginalArrivalTime: 26 Jul 2004 21:12:35.0807 (UTC) FILETIME=[460FC6F0:01C47355] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i6QLMnlj016798 Team, For issue 7579 we have a choice of modifying the getPort operation to return a list back or add a new operation (i.e. getPorts ()?) Note that the solution for issue 7579 is tied to the solution to issue 7578. Jerry asked me to a get a poll from the group to see which solution is more agreeable to the group. The above issues, rationale, proposed solutions and their related comments can be found at: Latest SWRADIO FTF Internal Issues Database: ftp://ftp.omg.org/pub/swradio-ftf/issues/. July 26th version. A copy of the spec can be found at ftp://ftp.omg.org/pub/swradio-ftf/. The document name is dtc-04-05-04-draft-2.pdf. Thank you. Neli Hayes The Boeing Company Integrated Defense Systems, Network Communication Systems Principal Software Architect (714) 762-8768 persnaz.n.hayes@boeing.com From: To: swradio-ftf@omg.org Subject: Re: SWRADIO FTF - Proposed Solution for Issue 7579 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Date: Tue, 27 Jul 2004 14:48:12 -0500 X-MIMETrack: Serialize by Router on CollinsCRSMTP02/CedarRapids/RockwellCollins(Release 6.5.2|June 01, 2004) at 07/27/2004 02:48:15 PM, Serialize complete at 07/27/2004 02:48:15 PM The Rockwell Collins thought, is that if you add a new interface, instead of modifying the the existing one, you would have better backward compatability with the current SCA approach. David "Hayes, Persnaz N" 07/26/2004 04:12 PM To: cc: Subject: SWRADIO FTF - Proposed Solution for Issue 7579 Team, For issue 7579 we have a choice of modifying the getPort operation to return a list back or add a new operation (i.e. getPorts ()?) Note that the solution for issue 7579 is tied to the solution to issue 7578. Jerry asked me to a get a poll from the group to see which solution is more agreeable to the group. The above issues, rationale, proposed solutions and their related comments can be found at: Latest SWRADIO FTF Internal Issues Database: ftp://ftp.omg.org/pub/swradio-ftf/issues/. July 26th version. A copy of the spec can be found at ftp://ftp.omg.org/pub/swradio-ftf/. The document name is dtc-04-05-04-draft-2.pdf. Thank you. Neli Hayes The Boeing Company Integrated Defense Systems, Network Communication Systems Principal Software Architect (714) 762-8768 persnaz.n.hayes@boeing.com Subject: Re: SWRADIO FTF - Proposed Solution for Issue 7579 Date: Wed, 28 Jul 2004 11:03:06 -0400 Thread-Topic: SWRADIO FTF - Proposed Solution for Issue 7579 Thread-Index: AcRzVUYFOatAFuRTSlGZpQp+HUcj8gAxYowgACU2S6A= From: "Pilhofer, Frank" To: "Demirbilek, Tansu" , "Kulp, Jim" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i6SFDOlj010725 > > For issue 7579 we have a choice of modifying the getPort > operation to return a list back or add a new operation (i.e. > getPorts ()?) Note that the solution for issue 7579 is tied > to the solution to issue 7578. > > Jerry asked me to a get a poll from the group to see which > solution is more agreeable to the group. > My 2 cents is that I am ambivalent on issue 7579. Let me explain: It is crucial to avoid a message "storm" during application startup. It is not possible to achieve low-latency startup of large applications when synchronous, sequential IPC messages are exchanged on a per-port basis. However, in D+C, we see the startup issue separate from the runtime issue. D+C deals with the startup on the container (i.e., NodeManager) level: using a single message, NodeManagers first return all object references for all provided ports on a node, and in a second message, they are told all references that are used by any component within the node. This way, D+C solves the startup latency issue without change to the component model, as the NodeManager can always have a local interface to the components it manages: it doesn't have to send GIOP messages across the network to repeatedly invoke "getPort" operations, but can use local, collocated operations and attributes. That's an implementation detail of the NodeManager. So, when D+C is used, it is irrelevant whether there is only a "getPort" operation returning a single reference at a time, or whether there were a "getAllPorts" operation -- either way, they would be used only at runtime, by the application itself, or by clients that are external to the application and which want to connect to a specific port. Based on the above, the "keep it simple" principle suggests to keep the interface as is. However, if you decide to go ahead with the change, similar modifications should be made to the connectPort operation, so that multiple connections can be supplied with a single invocation. > > Note that the solution for issue 7579 is tied to the solution to > issue 7578. > I see them as separate. Issue 7578 is basically an abstract modeling issue, whether a port can provide or use multiple unrelated interfaces, instead of a single, most-derived interface. This is not possible in either CCM or SCA, but allowed by UML 2. Issue 7579 addresses the concrete platform-specific problem of network latency -- which doesn't exist in the PIM. Either decision is independent of the other. Frank Subject: RE: SWRADIO FTF - Proposed Solution for Issue 7579 Date: Thu, 29 Jul 2004 11:19:36 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SWRADIO FTF - Proposed Solution for Issue 7579 Thread-Index: AcRzVUYFOatAFuRTSlGZpQp+HUcj8gCKcFYw From: "Paniscotti, Dominick (US SSA)" To: "Hayes, Persnaz N" , X-OriginalArrivalTime: 29 Jul 2004 15:19:36.0929 (UTC) FILETIME=[75B4B510:01C4757F] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i6TFU6lj027056 I prefer one operation vs. two. Otherwise we are just bloating the interface. Returning a list is OK with me. Dom > -----Original Message----- > From: Hayes, Persnaz N [mailto:persnaz.n.hayes@boeing.com] > Sent: Monday, July 26, 2004 5:13 PM > To: swradio-ftf@omg.org > Subject: SWRADIO FTF - Proposed Solution for Issue 7579 > > Team, > > For issue 7579 we have a choice of modifying the getPort > operation to return a list back or add a new operation (i.e. > getPorts ()?) Note that the solution for issue 7579 is tied > to the solution to issue 7578. > > Jerry asked me to a get a poll from the group to see which > solution is more agreeable to the group. > > The above issues, rationale, proposed solutions and their > related comments can be found at: > Latest SWRADIO FTF Internal Issues Database: > ftp://ftp.omg.org/pub/swradio-ftf/issues/. July 26th version. > > A copy of the spec can be found at > ftp://ftp.omg.org/pub/swradio-ftf/. The document name is > dtc-04-05-04-draft-2.pdf. > > Thank you. > > Neli Hayes > The Boeing Company > Integrated Defense Systems, Network Communication Systems > Principal Software Architect > > (714) 762-8768 > persnaz.n.hayes@boeing.com > > 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. thatChange the following types: 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: 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: 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. 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: pPortType (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 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. 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 comp