Articles Forum Examples Download Open Source
Copyright(c) 2009 by Pocomatic Software. All rights reserved.
This example demonstrates a straightforward way to support dynamic-wiring in PocoCapsule as a domain specific modeling (DSM) enhancement. Here, the "dynamic wiring" means an application is deployed with some of its dependent services not being wired immediately and unchangably but being wired and rewired later when each individual service become available or being updated.
In this example, a movie lister component (MovieLister.h and MovieLister.C) depends on a movie finder service (of MovieFinder type declared in MovieFinder.h) to function. Initially, the movie lister component is deployed without being wired with any movie finder service. At this time, this component will not fully functioning. For instance, its listMoviesDirectedBy() method will only be able to print an error message of "There is no movie finder service wired to the movie lister". Then, a service bundle providing a movie finder service is installed and application is transparently rewired. Now, the movie lister application is able to list some movies known by this movie finder service. Next, another service bundle that provides a more powerful movie finder service is installed and application is again rewired. After this rewiring, the movie lister is updated to use the new movie finder service and is able to list more movies.
setup.xml: This is the application initial setup description. It describes an application with a MovieLister bean instance that depends on a MovieFinder service. This dependency is declared to be a dynamic property:
<bean id="movie-lister" class="MovieLister">
<dynamic-property
name="setMovieFinder"
reference-type="MovieFinder"
reference-name="movie-finder"/>
</bean>Hence, the service "movie-finder" is not necessary to be available at the time of this bean's instantiation and will be injected and re-injected through the specified property setting method by PocoCapsule IoC container whenever the service becomes available or being updated.
bundle-1.xml: This is a service bundle installation description. It describes a movie finder implementation in class MyMovieFinder1 to be published in type "MovieFinder" and name "movie-finder":
<service class="MyMovieFinder1"
publish-type="MovieFinder"
publish-name="movie-finder"/>On installing this bundle, this service reference will be injected to all beans that have a dynamic property with reference (type, name) pair matches the service's publishing (type, name) pair.
bundle-2.xml: Similarly, this is another service bundle installation description. It describes a different movie finder implementation (class MyMovieFinder2) is be published in type "MovieFinder" and name "movie-finder":
<service class="MovieFinder"
factory-method="MyMovieFinder2::create"
publish-name="movie-finder"/>Note that the publish-type of this service element is not explicitly declared. This implies that the service is to be published in the type declared in the class attribute of this service element (i.e. the "MovieFinder"). If a service with a same publishing (type, name) pair is already installed, it will be replaced by the new installation.
main.C: This is a simple mini container, used to deploy the example application and then install the two service bundles on after another. On each step, namely after MovieLister creation, after movie finder service bundle-1 installation, and then, after service bundle-2 installation, this simple application calls the movie lister bean to list movies. This illustrates different behaviors when no or different movie finder services is wired to the bean.
MovieLister.h and MovieLister.C: The movie lister bean's implementation class. This bean depends on an MovieFinder service to be injected through the setMovieFinder() setter method.
MovieFinder.h: The movie finder service's common abstract class declaration. All movie finder implementations are to be inherited from this abstract class.
MyMovieFinder1.h/MyMovieFinder1.C and MyMovieFinder2.h/MyMovieFinder2.C: Two different movie finder implementations.
ServiceRegistry.h/ServiceRegistry.C: An example service registry internally used by this example dynamic wiring engine.
poco-dynamic-context.dtd: The definition of an example domain-specific-modeling (DSM) schema that supports dynamic wiring primitives.
dynamic-context2poco.xsl: The schema transformation stylesheet that specifies the mapping from dynamic-wiring DSM schema to PocoCapsule's core schema.
Makefile.build: the makefile for gcc on Linux
Makefile.buildWindows_NT: the makefile for C on Windows
To build this example, the environment variable POCOCAPSULE_DIR should point to the PocoCapsule/C++ installed directory. Then, this example can be built by simply invoking gmake/make on linux/unix or nmake on windows.
· Before starting the application deployment container (i.e. the main executable), make sure the LD_LIBRARY_PATH (on linux and solaris) or the PATH (on windows) environment variable is set correctly to include the ${POCOCAPSULE_DIR}/lib directory.
· start the main executable:
prompt> main
It will print out the following result:
[1] The movie lister has been deployed
[2] Listing moves directed by Ron Howard
There is no movie finder service wired to the movie lister
[3] Installing the MovieFinder service bundle-1
[4] Rewiring services to components
An initial movie finder is wired to the movie lister
[5] Listing movies directed by Ron Howard
The MyMovieFinder1 is called for listing all movies
1. Appollo 13
[6] Installing the MovieFinder service bundle-2
[7] Rewiring services to components
A replacing movie finder is rewired to the movie lister
[8] Listing movies directed by Ron Howard
MyMovieFinder2 is called for listing all movies
1. Appollo 13
2. A Beautiful Mind
3. The Da Vinci Code