Issue 9229: Flexibility to Perform Allocation, Load and Execute Behavior (swradio-rtf) Source: Boeing (Ms.Neli Hayes, persnaz.n.hayes@boeing.com) Nature: Uncategorized Issue Severity: Summary: Flexibility to Perform Allocation, Load and Execute Behavior at Component as well as Device Level Problem: For software radio deployment, the ability to perform capacity allocation/deallocation, object module load/unload, and process/thread execution/termination should not be restricted to devices. Flexibility should be provided such that for an application component, it would be possible for such behavior to be managed by the ApplicationFactory at the component level, without the constraint of having to use a device. Proposed Solution: Operations load () and unload (), execute () and terminate (), and allocate () and deallocate () in addition to all related types and behavior should be broken out of the Device, LoadableDevice and ExecutableDevice interfaces, each put into their own separate interfaces (e.g. LoadableInterface, ExecutableInterface, AllocableInterface), used (not inherited) from the Device, LoadableDevice and ExecutableDevice interfaces, and then used optionally by the ApplicationFactory for deployment of components that have load, execute or capacity behavior and do not need a device for deployment. Rationale: Need for flexibility in the SWRADIO UML Profile to accommodate deployment of an application component with or without a device. Resolution: Revised Text: The changes to the Component Framework volume spec are as follows: Replace Figure 7.9 - Device Component Interfaces Definition with the following figure Add the following text to end of 7.1.5.1 Device Component Interfaces "Types and Exceptions o <<exception>>InvalidState (msg: String) The InvalidState exception indicates that the device is not capable of the operation being attempted due to its state(s) (e.g., admin, operational or usage)." Change 7.1.5.1.1 Device description as follows: From "Description The Device, as shown in Figure 7.9, defines an interface that abstracts the underlying hardware. The Device is a specialization of Resource and ManagedServiceComponent interfaces with additional capacity behavior." To "Description The Device, as shown in Figure 7.9, defines an interface that abstracts the underlying hardware. The Device is a specialization of Resource, CapacityManager, and ManagedServiceComponent interfaces with additional attributes and release behavior." 7.15.1.1 Device Attributes section remains Remove Exception section and its contents Create a new section before 7.1.5.1.1 Device as follows: "7.1.5.1.1 CapacityManager Description The CapacityManager, as shown in Figure 7.9, defines an interface that provides the mechanisms for managing capacities. Operations Move the allocateCapacities and deallocateCapacities operations from 7.1.5.1.1 Device to here. Remove "<<optional>>" from text. Types and Exceptions Move the InvalidCapacity Exception from 7.1.5.1.1 Device to Here." Rename 7.1.5.1.2 ExecutableDevice as Executable and change description as follows: "Description The Executable interface, as shown in Figure 7.9, provides generic execute and terminate behavior." Add a new section after 7.1.5.1.2 Executable called ExecutableDevice with a description as follows: "Description The ExecutableDevice interface, as shown in Figure 7.9, extends the LoadableDevice by adding execute and terminate behavior." Rename 7.1.5.1.4 LoadableDevice as Loadable and change description as follows: "Description The LoadableDevice interface, as shown in Figure 7.9, provides generic software loading and unloading behavior." Add a new section after 7.1.5.1.4 Loadable called LoadableDevice with a description as follows: "Description The LoadableDevice interface, as shown in Figure 7.9, extends the Device interface by adding software loading and unloading behavior." 7.2.1.1.1 CapabilityModel Replace Figure 7.21 - CapabilityModels Definition with the following figure 7.2.1.1.1 CapabilityModel, M1 Associations section From "o serviceProperty: ServiceProperty [1] A ServiceProperty is associated with a CapabilityModel that determines the feasibility of the ServiceProperty satisfying a deployment requirement." To "o serviceProperty: ServiceProperty [1..n] A ServiceProperty(s) is associated with a CapabilityModel that determines the feasibility of the ServiceProperty(s) satisfying a deployment requirement." 7.2.3.2.3.1 ApplicationManager, Figure 7.40 - ApplicationManager Definition replace figure as follows: This figure has precedence over issue 9612 resolution. 7.2.3.2.4 ApplicationFactoryComponent Replace Figure 7.41 - ApplicationFactory Capability Manager Relationshipswith the following figure Replace Figure 7.42 - ApplicationFactory M1 Illustration with the following figure This figure has precedence over issue 9612 resolution. 7.2.3.2.4 ApplicationFactoryComponent, Constraints section From "When capacityManager attribute is False the ApplicationFactoryComponent shall only use ServiceCapacityProperty(s) that are locally managed by a ManagedServiceComponent, otherwise the ApplicationFactory manages the ServiceCapacityProperty(s). Characteristic properties can be either managed or unmanaged by the ApplicationFactoryComponent." To "When capabilityManager attribute is False the ApplicationFactoryComponent shall only use ServiceProperty(s) that are locally managed by a ServiceComponent, otherwise the ApplicationFactory manages the ServiceProperty(s). Characteristic properties can be either managed or unmanaged by the ApplicationFactoryComponent." Add constraints as follows: "When the capabilityManager attribute is true then the ApplicationFactoryComponent shall support the ServiceProperty's capabilityModel for CapacityProperty." "The ApplicationFactoryComponent shall support the ServiceProperty's capabilityModels for CharacteristicProperty, CharacteristicSelectionProperty, and CharacteristicSetProperty. Characteristic properties can be either managed or unmanaged by a ServiceComponent" Make the following changes in the Component Framework profile and Devices.idl file. Actions taken: December 6, 2005: received issue April 19, 2007: closed issue Discussion: Resolution: Make new interface called CapacityManager that is basically the same definition as Device but without the specialization relationship and attributes. Move InvalidState exception definition at the package level instead at the interface level since other interfaces will need it. Have the LoadableDevice be a specialization of Device and Loadable interfaces. Make new interface called Loadable that is basically the same definition as LoadableDevice but without the specialization relationship. Have the LoadableDevice be a specialization of Device and Loadable interfaces. Make new interface called Executable that is basically the same definition of ExecutableDevice but without the specialization relationship. Have the ExecutableDevice be a specialization of LoadableDevice and Executable interfaces. End of Annotations:===== ubject: SWRADIO RTF Issue - Flexibility to Perform Allocation, Load, and Execute Behavior at Component as well as Device Level Date: Tue, 6 Dec 2005 17:20:00 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SWRADIO RTF Issue - Flexibility to Perform Allocation, Load, and Execute Behavior at Component as well as Device Level Thread-Index: AcX6zFe6u9Y/mzuzQ+K/37U/FDuKxQ== From: "Hayes, Persnaz N" To: Cc: X-OriginalArrivalTime: 07 Dec 2005 01:20:00.0805 (UTC) FILETIME=[58163550:01C5FACC] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id jB71FRHY010174 Title: Flexibility to Perform Allocation, Load and Execute Behavior at Component as well as Device Level Problem: For software radio deployment, the ability to perform capacity allocation/deallocation, object module load/unload, and process/thread execution/termination should not be restricted to devices. Flexibility should be provided such that for an application component, it would be possible for such behavior to be managed by the ApplicationFactory at the component level, without the constraint of having to use a device. Proposed Solution: Operations load () and unload (), execute () and terminate (), and allocate () and deallocate () in addition to all related types and behavior should be broken out of the Device, LoadableDevice and ExecutableDevice interfaces, each put into their own separate interfaces (e.g. LoadableInterface, ExecutableInterface, AllocableInterface), used (not inherited) from the Device, LoadableDevice and ExecutableDevice interfaces, and then used optionally by the ApplicationFactory for deployment of components that have load, execute or capacity behavior and do not need a device for deployment. Rationale: Need for flexibility in the SWRADIO UML Profile to accommodate deployment of an application component with or without a device. Neli Hayes Associate Technical Fellow Principal Software Architect JTRS Cluster 1 Program Network Communication Systems The Boeing Company 714-762-8768 Subject: RE: ***DO NOT POST YET*** SWRADIO RTF Issue - Flexibility to Perform Allocation,Load, and Execute Behavior at Component as well as Device Level Date: Wed, 7 Dec 2005 18:08:28 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ***DO NOT POST YET*** SWRADIO RTF Issue - Flexibility to Perform Allocation,Load, and Execute Behavior at Component as well as Device Level Thread-Index: AcX6zFe6u9Y/mzuzQ+K/37U/FDuKxQAAC3swABsrawAAClbH8A== Priority: Urgent From: "Hayes, Persnaz N" To: "Jerry Bickle" , "Juergen Boldt" , Cc: X-OriginalArrivalTime: 08 Dec 2005 02:08:28.0498 (UTC) FILETIME=[479EB320:01C5FB9C] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id jB823muA028228 Jerry, Thank you. I'll take care of making the corrections. Juergen, Please do not post this issue until I make the necessary corrections. I need further collaboration with Jerry before I do so. Thank you again. Neli -----Original Message----- From: Jerry Bickle [mailto:Jerry.Bickle@prismtech.com] Sent: Wednesday, December 07, 2005 6:23 AM To: Hayes, Persnaz N Subject: RE: SWRADIO RTF Issue - Flexibility to Perform Allocation,Load, and Execute Behavior at Component as well as Device Level Slight Misunderstanding The intention is to be able offer lightweight Service Components such as Device Components that don't need StateManagement and Capacity interfaces but just provide load and process management behavior. The compliance point is left up users or implementers of the spec. Similar concept of having lighter weight application components that don't have to be full blown resource components. ------------------------------------------ Jerry Bickle Chief Scientist, SDR Products 6511 Constitution Drive Fort Wayne, IN 46804 1 260-436-7168 (Work) 1 260-436-6708 (Fax) 1 260-249-8162 (Mobile) www.prismtech.com -----Original Message----- From: Hayes, Persnaz N [mailto:persnaz.n.hayes@boeing.com] Sent: Tuesday, December 06, 2005 8:29 PM To: swradio-rtf@omg.org Subject: RE: SWRADIO RTF Issue - Flexibility to Perform Allocation, Load, and Execute Behavior at Component as well as Device Level Team, This is an issue that I agreed to raise per Jerry's request at the SDR Forum and I would like to be in charge of resolving it. So, it can be assigned to me. I was supposed to come up with the exact concept of operation in form of changes to the specification and related UML diagrams during this meeting. Unfortunately, I will not be able to do so this week, but, will do so shortly, at the latest, early in the new year. With best regards, Neli > _____________________________________________ > From: Hayes, Persnaz N > Sent: Tuesday, December 06, 2005 5:20 PM > To: issues@omg.org > Cc: swradio-rtf@omg.org > Subject: SWRADIO RTF Issue - Flexibility to Perform Allocation, > Load, and Execute Behavior at Component as well as Device Level > > Title: Flexibility to Perform Allocation, Load and Execute Behavior > at Component as well as Device Level > > Problem: For software radio deployment, the ability to perform > capacity allocation/deallocation, object module load/unload, and > process/thread execution/termination should not be restricted to > devices. Flexibility should be provided such that for an application > component, it would be possible for such behavior to be managed by the > ApplicationFactory at the component level, without the constraint of > having to use a device. > > Proposed Solution: Operations load () and unload (), execute () and > terminate (), and allocate () and deallocate () in addition to all > related types and behavior should be broken out of the Device, > LoadableDevice and ExecutableDevice interfaces, each put into their > own separate interfaces (e.g. LoadableInterface, ExecutableInterface, > AllocableInterface), used (not inherited) from the Device, > LoadableDevice and ExecutableDevice interfaces, and then used > optionally by the ApplicationFactory for deployment of components that > have load, execute or capacity behavior and do not need a device for > deployment. > > Rationale: Need for flexibility in the SWRADIO UML Profile to > accommodate deployment of an application component with or without a > device. > > Neli Hayes > Associate Technical Fellow > Principal Software Architect > JTRS Cluster 1 Program > Network Communication Systems > The Boeing Company > > 714-762-8768 > persnaz.n.hayes@boeing.com Subject: SWRADIO RTF - Issue 9229 Comments Date: Wed, 26 Apr 2006 13:12:57 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SWRADIO RTF - Issue 9229 Comments Thread-Index: AcZpbcvqUB8V5TM5QQaMovvaA18rCA== From: "Hayes, Persnaz N" To: "Jerry Bickle" Cc: X-OriginalArrivalTime: 26 Apr 2006 20:12:58.0230 (UTC) FILETIME=[CF9F1960:01C6696D] Jerry, I was supposed to forward you our agreed upon comments on how to resolve this issue which was originally assigned to me, in case I don't get to it for our 2nd vote. For this attachment as well as the full problem proposal, rationale, and resolution, please refer to our 4/24/06 and later issues list, distributed since Monday April 24th. I submitted this issue based on our discussions at SDR '05. My understanding of the issue and how you wanted it resolved was slightly incorrect and in the discussion below, you corrected my misunderstanding. <> Thank you. Neli Neli Hayes Associate Technical Fellow SDR Specialist & Principal Software Architect JTRS Cluster 1 Program Network Communication Systems The Boeing Company 714-762-8768 persnaz.n.hayes@boeing.com Subject: SWRadio RTF 2nd Vote Date: Thu, 21 Sep 2006 15:09:27 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SWRadio RTF 2nd Vote Thread-Index: AcbdypsQdOYECvZqTZmIVK7Ah27wyw== From: "Browne, Mike \(Space Technology\)" To: X-OriginalArrivalTime: 21 Sep 2006 22:09:28.0123 (UTC) FILETIME=[9B0F20B0:01C6DDCA] *** SWRadio RTF Ballot 2nd Poll *** *** Voting Deadline Friday, September 22nd, 2006, 20:00 GMT *** Company: Northrop Grumman Voter: Michael Browne Please vote with Yes/No/Abstain for each issue resolution, as detailed in the attachment. Note: A short reason for No votes is mandatory. OMG Issue No: 7584: yes OMG Issue No: 7898: yes OMG Issue No: 8344: yes OMG Issue No: 8870: yes OMG Issue No: 9229: no. Seems to be missing some updates in section 7.1.5.1 to into the added interfaces. Table 7.4 needs updates as Device has additional parent. Also, it seems that the goal of the Issue is not met. Capacity manager seems to be still required to be a Device, where as the issue implied the desire was to allow lighter weight device components. Finally (and a nit I know), the resolution doc does not seem to match the changes in the convenience doc, at least not the one with change bars dated 0604. OMG Issue No: 9301: yes. Note however that the resolution uses providesPort in the port type definition whereas the convenience doc only has provides. Which one is correct? OMG Issue No: 9304: yes OMG Issue No: 9348: yes OMG Issue No: 9350: yes OMG Issue No: 9612: yes OMG Issue No: 9909: yes OMG Issue No: 9916: yes OMG Issue No: 9918: yes OMG Issue No: 9919: yes OMG Issue No: 9924: yes OMG Issue No: 9927: yes persnaz.n.hayes@boeing.com