''How many NonGraphicalComponents have you seen?''  What are useful units of reuse?

	* Database interfaces (''stipulated'')

	* XML/SGML/HTML parser/generator libraries
	* Graphic-file libraries
	* Transaction processors/monitors
	* Network-protocol handlers (libwww, all those Perl and Python libraries)

''Those are almost all class libraries. The components in question here are ComponentBasedDevelopment things - you know, COM, CORBA, ...''


Here are some examples that are more component based:

	* DirectShow components for media processing
	* Components of configurable transport protocol stacks, such as Conduits+, Regent, iBus or Horus.
	* IBM has many non-graphical JavaBeans on its alphaBeans site [1].
	* Phillips have designed a component model, called "Koala", for the software in their TV sets.

----

Interesting question.  I have experience in evolving the decidedly graphical
components of the UnidrawFramework toward other uses.  So far we've dealt with
map features, decision trees, vehicle models, and raster objects.  Although
each component has a certain aspect that isn't completely about how
they will be rendered on the screen, it was convenient to reuse the graphical
component architecture of Unidraw.  And all but the vehicle models made
direct use of the graphical mechanisms when integrated into a viewer.

JohnVlissides tried to tease apart components from graphical components when
he originally wrote the software.  The ultimate base class is Component, but
the base class that everything derives from is GraphicComp.  I think in a
server there is certainly room for components without a graphic nature.
But we needed to retain all the other capabilities, like serialization, 
property lists, scripting language, etc..  And we wanted to be able to export a view of the component in some graphical language.  Which
for the most part required graphics software. 

--ScottJohnston


Take a look at Microsoft's DirectShow ComponentFramework.  Most of the components are non-graphical: they produce, process or render frames of continuous media.  The components that render graphical media (such as frames of video) are adapters between two different frameworks, acting as DirectShow media sinks and ActiveX embeddable objects.

--NatPryce

Is there any persistent information in a DirectShow component that is there
specifically for the use of an eventual ActiveX object?

No.  DirectShow and ActiveX are two completely separate ComponentFramework s. Because they are both from Microsoft they are both based on COM, but do not use the same COM interfaces (beyond core COM interfaces such as IUnknown).  Therefore most DirectShow components have no knowledge of ActiveX at all -- ie: they do not use ActiveX interfaces for embedding etc.  The only DirectShow component that needs ActiveX interfaces is the "ActiveMovie" component that can be embedded into a web-page or VB form.

See http://www.microsoft.com/directx/dxm for more information (however, the site is unusable with anything but Internet Explorer).

''Nat, this is a great example of how components can partipate in a ComponentBus on one hand (e.g., DirectShow source) via outgoing interfaces and be subject to ThirdPartyBinding or ComponentGlue on the other (e.g., any ActiveX client) via incoming interfaces.  I'll try to factor this example into some of the Component Interaction Patterns I'm submitting to PLoP'99 --PhilipEskelin''

DirectShow components don't use a ComponentBus -- they are connected via ThirdPartyBinding by the programmer or a filter graph factory (AutomatedAssembly).  DirectShow sources read media from files or HTTP connections.  I guess that one could, at a stretch, consider a multiparty NetMeeting videoconference a ComponentBus but it isn't really within the usual meaning of the term.

On the subject of incoming and outgoing interfaces, DirectShow bindings are an example of where ThirdPartyBinding is used to set up multidirectional communication between components.  Each binding establishes a flow of media frames from producer to consumer and a flow of control signals in the other direction.  I've found that most ComponentFramework s use bidirectional interactions like this: E.g. ActiveX/OLE "sites" for embedded objects, data flow in the Regent transport framework, interactions between geometry managers and GUI widgets.  It seems very rare to have a ComponentFramework  that can be described only in terms of client-initiated request/reply invocations.

''I would still say it sounds like a ComponentBus even though a third party binds them.  To me, the source-sink theme (ObserverPattern) is popularly used in component busses whether a third party binds the components via AutomatedAssembly or not.  And I agree that this interaction theme is commonly used in COM where we see bidirectional interactions, including those that occur between OLE DB consumers and producers (e.g., ADO consumer, Sybase provider).  --PhilipEskelin'' 

It's not a ComponentBus because filters must be explicitly bound to their upstream and downstream filters.  Components talking through a ComponentBus do not have a direct connection to other components, just like electronic components that communicate through a hardware bus.  PCI cards (for example) communicate by raising and lowering voltages on the bus without needing to know what reacts to those signals or what is done to handle them.  Similarly a software component on a ComponentBus sends events to a MultiCaster or places tuples into a TupleSpace without needing to be explicitly bound to the components that react to those events or process the tuples.  It is this indirection that makes it easy to dynamically reconfigure a system built around a ComponentBus, compared to a system built from explicitly bound components.

----

Component technologies aside, I hope that we can successfully capture present themes in uni- and bi-directional component interactions, via the "Component Interaction Patterns" sub-language I submitted to PLoP'99, that lead to living, well-designed systems.  CIP contains AbstractInteractions, ComponentBus, ThirdPartyBinding, and ComponentGlue.  They make use of lower-level design patterns such as ObserverPattern, AdapterPattern, MediatorPattern, and NullObject (to name a few).  I'm working on translating them to the Alexandrian form as we speak and will make sure I get them out to you when I've got something we can work with.

--PhilipEskelin