Subject: RE: Meeting preparation -- Reconciling the Boeing OEP with CCM From: "Noll, Dennis D" Date: Fri, 16 May 2003 13:36:26 -0500 To: "Sharp, David C" , "John Hatcliff (E-mail)" , "Gurdip Singh (E-mail)" , CC: "Sanders, Carol L" , "McDonald, James D" , "Roll, Wendy C" First off, thanks again for putting this document together. This is a great starting point for our evolving discussions. I made several markups that we need to discuss internally here first, but below are a few comments / embellishments to go with: Sec 2.2.3: -------------- I am not proud of the event supplier UPDATE_RATE attribute. For consumers, it makes sense as a specification of the rate group in which a full channel event will be delivered. For suppliers, there is no dispatching of the event so the meaning is not the same. In actuality, this is a hook to seed the runtime scheduler when the dependency chain cannot be inferred from a full channel event dependency tree (eg - a LazyActive component pushes an event from an invocation). If we can export an appropriate dependency chain from tools like Cadena I would be very happy to get rid of this. Sec 2.2.5: -------------- Null Locks: As Dave mentioned below, null locks are a common implementation in adaptable middleware services and application components. Look no further than ACE for examples of this. The basic idea is that a service/component/etc. is coded with pluggable locks and the appropriate calls to support concurrency, but can be optimized with a null lock strategy when applied to a single-threaded use case. This could benefit from aspect weaving once the technology arrives. Synchronous Proxies: "Note that this is a synchronization avoidance strategy rather than a synchronization strategy." Yes and no, in the sense that one result is to minimize locking an the resource being cached. More importantly, remember that this is a mechanism to maintain state coherency throughout a long chain of processing without locking the underlying state provided from updates from other threads. I mentioned before an example with 20 Hz airframe data being cached in a proxy for access by the 5Hz thread. This data must be coherent for the entire duration of a 5 Hz frame to ensure coherency of the final results. In these instances, it may not be as important that all inputs be the latest available as it is that all inputs represent the same point in time. In concrete terms, imagine if a targeting/release algorithm used different positional inputs from a terrain following algorithm flying to the target. Shared Locks: "It seems only 2 components can share a lock which raises doubts about its purpose." - The Representative MP scenario has 4 components sharing a lock. Sec. 2.2.6 -------------- Classification: This descriptor is not used for access control within the mission. Instead, it is a tag used to designate classified persistent data for unique identification and special treatment by the underlying persistence service (e.g. safe erase). Sec. 2.3 -------------- "In terms of event port, typed approach enables introspection of the events by intermediate entities such as an event channel, hence, adding new possibilities to the framework." This is a very important statement that I will come back to later. "Pure" CCM seems completely realizable using the standard CORBA Event Service, but even the OMG has recognized that CosEvent is too simple to construct real systems. Hence, we have non-standardized solutions (like RTEC) and subsequent OMG standards (like the Notification Service) to provide additional capabilities like event filtering based upon introspection of events, QoS specification, glommed delivery of events, etc. I would rather extend CCM descriptors to provide these new capabilities as opposed to reverting back to an unrealistic model of system composition, but more on this later... Sec 5.2.1, Issue #1 - Solution 1: -------------- Subsect a. "The presence of a source_id indicates that the consumer can identify the publisher, but this should not be the case in a component-based system." We strongly disagree. Source_id is an integer attribute used to further differentiate unique events for filtering in our system. As long as this is controlled by the assembly and not the generic component (eg - the component is not coupled to a give source), the generic composition of component systems should be maintained. Subsect b. To support the filtering attributes of higher fidelity middleware implementations (RTEC, Notification, etc.) we will need a richer specification language to identify behavior sets based upon event attributes (back to introspection in the event channel). Subsect c. This statement confuses me. I think the source of confusion is that we are trying to map OEP / RTEC event type ids (event_ids in your idl) into CCM typed events. Given the solution 1 approach, wouldn't inheritance be implemented by extending the GenericEvent (a structural extension of the event) instead of changing the event_id? One a side note, we rarely push data with an event, so the "payload" attribute could be removed. The only case where I could see subtyping be used in the current OEP approach would be for those rare cases that data is passed with the event, in which case a subtype event could be specified with the appropriate payload allowing enforcement at the modeling level. Even in this instance, the runtime middleware (aka - the physical instantiation) would probably be constructed to carry an optimized composite of all subtypes for performance considerations. Sect 5.2.1, Issue #2 -------------- I assume that you mean conjunctive correlation cannot be represented in CCM? Is there anything prohibiting disjunctive correlation. Also a question on solution #2... Don't we need event introspection to map multiple incoming events to a single event? For the OEP, it is not an issues as we do not generally pass data, but for systems with payload presumably we need a specification to compose the delivered event from attributes in the correlated event stream? Sect 5.2.3, Issue #2 -------------- Other options here include the Boeing Replication Service and the soon-to-be standardized OMG Data Publishing Service. Section 5.2.4 -------------- Solution #1 - External locking is distinct from internal locking. It is required where a component needs coherent access to multiple components and/or must perform multiple accesses on a single component and ensure coherency. In this case, the accessed components do not have the requisite knowledge of concurrency to manage it internally. RE Synchronous Proxies... this needs some more brainstorming. Let's discuss this when Wendy is back. Thanks again for starting this, -Dennis -----Original Message----- From: Sharp, David C Sent: Thursday, May 15, 2003 4:45 PM To: John Hatcliff (E-mail); Gurdip Singh (E-mail); rvprasad@cis.ksu.edu Cc: Noll, Dennis D; Sanders, Carol L; McDonald, James D; Roll, Wendy C Subject: RE: Meeting preparation -- Reconciling the Boeing OEP with CCM John, Gurdip, Venkatesh- I just did a quick read through parts of the document Dennis forwarded. One of the most important things we obviously need to do at this point is to identify the consistencies and inconsistencies between CCM/Cadena/CIAO/OEP, etc. I think the paper provides a really good start at that. I wish, however, that we were having our May 30th get together before next week's meeting though, because I think there are a number of misperceptions embodied in the paper that could lead discussions slightly astray next week. And perhaps some of these issues were clarified during the telecon earlier this week. Our OEP Config XML expert, Wendy, is out right now, so I'll apologize in advance for any related comments that are slightly off. Here are some examples of concerns I noticed: 1: Sec 2.2.2 Receptacles. The COMPONENT_ID is more specific than the HOME_ID, since the COMPONENT_ID identifies an instance, and the HOME_ID identifies a type. So we could do without the HOME_ID, but not the COMPONENT_ID. That matches what's recommended later, so that's good. 2: Sec 2.2.5 Concurrency: "It also supports no lock and it is unclear why would one want to specify a locking policy and then specify no lock to participat in the locking policy." It's important to remember the separation between component developers and component integrators. Component developers need to code their implementations for the most general usage. Component integrators do the exact opposite- they try to make the usage specific and wring as much optimization as possible out of the result. So in this case, the component developer would code it to support a specific locking strategy, but a component integrator might find that, based on his specific configuration, no locking is required (e.g. if a project ran all components at 20 hz). If we have a nirvana Aspect C++-ized world where the original developer didn't have to specify any of the configurable parts, this issue would be significantly reduced. But that's not where we are now. 3: Sec 2.2.5 Concurrency, about SYNC_PROXY locking: "Note that this is a synchronization avoidance strategy rather than a synchronization strategy". It's more like a "sync movement and reduction" strategy. There's still synchronization going on, it's just done between the master and proxy instead of between the component and it's clients. For some cases, this results in a large reduction in the amount of required locking. 4: Sec 2.2.6 Persistence: "However, it would be better if the store returned a key that could be used during later retrieval." "Better" is definitely in the eyes of the beholder here . Our projects would not typically be interested in a key based solution here because it's not as fast. I understand that it's more flexible, and we'll want it for other use cases. But probably not this one. 5: Sec 2.3 Conclusion: "Few aspects of the component that are represented in the XML file can benefit from services such as ... event service... as defined along with CORBA". I don't understand. Obviously a major part of the XML is associated with events. Is this just alluding to the OEP event service not being completely standard CORBA? 6: Sec 2.3 Conclusion: "In terms of event ports, typed approach enables...". We would be advocates of as strong a typing as possible that meets the flexibility requirements imposed by our product line approach. Component developers writing suppliers know exactly what event types they will generate. Component developers writing clients often do not want to know what event types they will consume. A large number of our component consumers are only interested in receiving a notification- it doesn't matter what event type was supplied. This relates back to item 2. 7: (jumping ahead...) Sec 5.2.1 Sol 1 sub section a) "consumer can identify the publisher, but this should not be the case in a component-based system." This is completely opposite our typical "push-events-pull-data" flow policy. I agree that unnecessary, accidental dependencies should be removed, but this is not necessarily one of them. sub section c) "The encoding of event types as event_id does not scale." Scale with respect to what? I haven't seen any F/A-18s dropping out of the sky recently due to this problem, and they tip the scales pretty substantially --------------- I'm guessing we really need to talk through most of the issues and potential solutions. I'm sure there are a number that we've always been aiming for (e.g. connections at the facet-receptacle level instead of just at the component level). But there are probably others that warrant additional discussion. We need to be careful not to make decisions that lead to an approach that won't give the necessary performance. It might very well be that I read the document as something closer to a finished product than intended. We just need to close the loop on the issues. It might make sense for us to either set up a half day telecon or something soon, or extend our meeting on 30 May. If the room arrangement is supportive, it would probably be helpful to tie Dennis and/or Wendy in on the phone during this portion of the meetings next week. Thanks for wading through this! --Dave -------------------------------------------------------- -- Dave Sharp david.sharp@boeing.com -- -- Boeing (voice) (314) 233-5628 -- -- St. Louis, MO (fax) (314) 233-8323 -- -----Original Message----- From: Noll, Dennis D Sent: Thursday, May 15, 2003 10:21 AM To: Sanders, Carol L; McDonald, James D; Roll, Wendy C Cc: Sharp, David C Subject: FW: Meeting preparation -- Reconciling the Boeing OEP with CCM Guys, I'll send a preliminary list of response issues to KSU tonight, which will hopefully refine their discussions next week. Any comments on this document between now and then are greatly appreciated. -Dennis -----Original Message----- From: John Hatcliff [mailto:hatcliff@cis.ksu.edu] Sent: Thursday, May 15, 2003 10:04 AM To: bala@cse.wustl.edu; Nanbor Wang; Aniruddha Gokhale; schmidt@cs.wustl.edu; 'kitty@cs.wustl.edu'; 'parsons@cs.wustl.edu'; Boris Kolpakov; Tao Lu; Chris Gill; Noll, Dennis D Cc: Matthew Dwyer; Gurdip Singh; masaaki@cis.ksu.edu; rvprasad@cis.ksu.edu; Jesse Greenwald; 'Mitchell L. Neilsen' Subject: Meeting preparation -- Reconciling the Boeing OEP with CCM Hi all, The attached document addresses a number of issues in moving the Boeing OEP (with its various RT attributes associated with the RT event-channel) to CCM. This document primarily addresses issues related to component IDL (interface issues) and CAD (XML configuration issues). In particular, we will want to begin the some of the points raised in this document when trying to come up with a CCM compliant configuration format that can be shared between Cadena and CIAO that also supports the RT event channel. Thanks to Venkatesh Ranganath for his work on putting this document together. -- ------------------------------------------------------------------------ ---- John Hatcliff Phone: 785-532-6350 Associate Professor Fax..: 785-532-7353 Department of Computing and Information Sciences Email: hatcliff@cis.ksu.edu 234 Nichols Hall WWW..: http://www.cis.ksu.edu/~hatcliff Kansas State University Manhattan, KS 66506 ------------------------------------------------------------------------ ----