1. Hardware engineers create circuits by mounting pre-fabricated chips on circuit boards. Component-based development extends this idea to software engineering: software engineers should be able to create applications by deploying and connecting pre-fabricated software components into containers that provide infrastructure services such as discovery, lifecycle management, and communication. Ideally, deploying and connecting components could be done using some graphical drag-and-drop interface. There should be no need to understand how the components are implemented.
Examples:
· Several companies provide components for enterprise resource planning (logistics, human resources, billing, etc.) and a container for these components. Customers can buy the components they need and can afford. Examples include SAP and Netsuite.
· Servlets and Java Beans are examples of component architectures for J2EE web servers (e.g., Tomcat) and application servers (e.g., JBoss).
· Visual Basic was the original component container. Users could drag calendar, calculator, input, and output components into the container, graphically connect them and compile. This idea later evolved into OLE containers and components.
· Service-Oriented Architectures are closely related to Container-Component architectures. Web service architectures are an example of SOA.
2. Two competitors A and B have similar products. Company A uses a proprietary architecture. This forces their customers to purchase add-on components from them or companies explicitly licensed by them. A collects the profits and controls the price. Company B uses an open architecture. They publish the interfaces implemented by their product and invite random third-party developers to build add-on components and sell them directly to A's customers. Although company B does not directly profit from the sales of these components, a large, competitive market develops. B's customers can choose from a large selection of competitively-priced components. In turn, this drives sales of B's product.
Examples:
· Companies A and B are veiled references to Apple and IBM. IBM published details of the PC motherboard, thus creating a market for expansion cards.
· Eclipse championed the container-component architecture.
· Most browsers employ some form of container-component architecture.
Internally, a component is a collection of encapsulated functions and data.
Externally, a component is a set of realized interfaces together with a set of required interfaces.
An interface is a set of related operations, attributes, and receptions (i.e., signal receptors or handlers).
In the following diagram Component1 realizes (or implements) Interface1 and requires Interface2, which is realized by Component2.
Modern UML favors using class icons with a component decoration or stereotype:
(I don't like this notation because it's hard to draw by hand.)
At one level a program can be viewed as a collection of collaborating components.
At a more refined level, the same program may be viewed as a collection of collaborating objects.
Objects often represent entities, views, controls, etc. Components more often represent services or sub-systems.
While a component may be implemented as a collection of collaborating objects, a component is simply a collection of related services. It may or may not represent anything. Internally it may just be a collection of functions and data structures.
Often a component is implemented as a collection of objects that collaborate to realize the component's interfaces.
A collaboration is a set of objects together with a set of interactions between the objects.
An interaction is analogous to a scene from a play, objects (the actors) play roles (client, server, broker, etc.). In these roles the objects exchange messages with each other in a prescribed order. Examples of messages include synchronous or asynchronous method calls, replies (e.g., return values), and asynchronous signals (i.e., broadcast messages).
We use UML sequence diagrams to describe interactions:
A component needs some infrastructure to execute. For example, how will a component advertise its services? How will a component discover which components realize its required interfaces? Once discovered, how will the component communicate with these provider components? How will the component save important data? How will a component learn about signals broadcast by other components? Usually a container application such as a .Net server or a J2EE server provides these services.
Components and other UML classifiers can asynchronously broadcast signals. Signals can have attributes.
Components and other UML classifiers can also have receptions. A reception is an operation that is automatically called when a signal of the specified type is received.
For example, a nuclear reactor broadcasts an "overheating" signal when it gets too hot. The signal contains the current temperature of the reactor as an attribute. Components that implement the IAlarm interface must provide a reception for this signal. In other words, they must handle these signals when they are received.
A port is a service access point such as a URI or IP address with port number:
<<service>>
<<entity>>
<<process>>
<<subsystem>>
The physical manifestation of a component is called an artifact-- for example an exe, html, or jar file.
An artifact is deployed on a node.
There are two types of nodes: devices and execution environments. Examples of devices include servers, client desktops, mobile devices, and embedded devices. Examples of execution environments include operating systems and component containers (.Net, J2EE container, Web Server).
Nodes are connected by communication paths usually labeled by the communication protocols they use.
(I also use deployment arrows to show execution environments hosted by devices.)
I usually don't bother with artifacts and show components deployed on nodes:
· Examples
· Container-Component Architecture Pattern