Professional Documents
Culture Documents
Introduction To Component Models and Technologies
Introduction To Component Models and Technologies
Middleware
Horizontal Services:
Operating System
application-independent
services used by different
components.
Hardware Concurrency, security,
transaction management,
Resource management
Component technologies
• Component technology = component model +
component framework
• Different component models available:
– Old and new
– Industrial or research
– General-purpose or specialized for different domains
– Having different concepts for components
– Providing a larger or smaller set of platform services
• Examples:
– Java Beans, EJB, COM, DCOM, .NET Components, CCM,
OSGI, Spring, PicoContainer, Fractal, OpenCOM, Autosar,
KOALA, PECOS, …
Introduction goals
• Motivation
– Why do we need them ?
– What is the minimum they must do ?
• Basic principles
– How do they actually do it ?
• Bibliography: Martin Fowler: Inversion of Control
Containers and the Dependency Injection Pattern,
http://www.martinfowler.com/articles/injection.html
•
The Basic Goals of CBD
• Assemble a system out of existing (third-party)
components
• Update a system by adding / replacing components
• Component:
– Is a unit of deployment
– Is handled as it is (a blackbox)
Example 1
• A simple text editor can be composed with a spell checker for
English language or with a spell checker for Romanian language
SpellChecker1
TextEditor
SpellChecker2
Example 1
• The Component Diagram shows a simple hierarchical composition
Example 2
• From: Martin Fowler: Inversion of Control Containers and
the Dependency Injection Pattern
MovieFinder1
MovieLister
MovieFinder2
Example 2
• A MovieLister is able to list movies with certain characteristics after
being provided an exhaustive list of movies by a MovieFinder
• MovieFinder is an interface;
• There could be several different MovieFinderImpl components: one
implementation finds movies by reading a text file, one finds movies
from a relational database, one finds movies crawling the web for
movie advertisings, etc.
A naive solution design
public interface MovieFinder {
List findAll();
}
public MovieLister() {
This is
finder = new MySpecialMovieFinderImplem(); BAD !!
}
}
The goal: loosely coupled
components
• MovieLister should work with any MovieFinderImplementation
• MovieLister does not need to know the particular type of finder
implementation it is using
class MovieLister...
class MovieLister...
<beans>
<bean id="MovieLister" class="spring.MovieLister">
<property name="finder">
<ref local="MovieFinder"/>
</property>
</bean>
<bean id="MovieFinder" class="spring.ColonMovieFinder">
<property name="filename">
<value>movies1.txt</value>
</property>
</bean>
</beans>
Example: Setter Injection with Spring
(3) Describing the configuration
….
}
Comparison:
Service Locator vs Dependency Injection
• Both provide decoupling (keep application code
dependent only on interfaces, not on implementations)
• Other criteria:
– How explicit are the dependencies ?
– How “intrusive” is the approach into the application code ?
– Dynamic dependencies are possible ?
Comparison: (1)
Service Locator vs Dependency Injection
• “Intrusive” into application code:
– With service locator, the application component
explicitly asks the locator for its dependency
• Every component has a dependency to the locator
• This is “intrusive” into the component development process
(such components cannot be used without the framework)
– With dependency injection, the application component
does not have to ask anything, its dependencies just
appear injected
• Less intrusive, such components could be used without the
framework
Comparison: (2)
Service Locator vs Dependency Injection
• Explicit dependencies:
– With service locator you have to search the source
code for calls to the locator.
– With dependency injection you can just look at the
injection mechanism, such as the constructor, and
see the dependencies.
Comparison: (3)
Service Locator vs Dependency Injection
• Dynamic dependencies:
– With dependency injection you don't have a
dependency from a component to the injector, the
component cannot obtain further services from the
injector once it's been configured.
– With service locator a component can locate new
services at any time or replace/update them .
Conclusion
• Component frameworks must support the assembly of
independent components into applications at
deployment time or even runtime
– lightweight IoC containers at least
• Component frameworks may support different additional
aspects:
– Component lifecycle support
– Hierarchical components
– Concurrency, distribution, transactions, …