Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

COSMOS DC Design Discussions

Revision as of 14:35, 9 July 2007 by Hkyleung.ca.ibm.com (Talk | contribs) (New page: * The notion of a "component": Currently, a "component" is a collection of "source", "transform", "sink", etc. I think a "component should be at the granularity of a "source" or "sink". ...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
  • The notion of a "component": Currently, a "component" is a collection of "source", "transform", "sink", etc. I think a "component should be at the granularity of a "source" or "sink". The "assembly" specifies how the components are connected from one to another. The exploiter can provide an implementation of a component in the assembly, such as a data sink. The exploiter should not need to implement the binding service. If you look at the SampleBindingService and GLABindingService, they are almost in the same pattern. The binding service logic can be abstracted into the framework code. I like redefine the term "component" to refer to each "step" within an assembly, e.g. a data sink is a component.
  • The coupling between components
    • The components should be loosely coupled.
    • event handling: need to add listeners, events are raised on each object that passes through the assembly.
    • after each event is processed, the object is dispatched by calling the wire method of the next "component" in the assembly. This is potentially inefficient and make optimization difficult. For example, when I wrote the CBE data sink, I had to do an insert for each CBE. If I have access to the whole list of CBE objects, I can do a batch data insert operation.

Back to the top