Eclipse Authors: Pat Romanski, Elizabeth White, Liz McMillan, David H Deans, JP Morgenthal

Related Topics: Eclipse, Adobe Flex

Eclipse: Article

A Runtime Integration Approach to Application Development

Plug-in Integrator Pattern

The heart of the Plug-in Integrator Pattern is the configurator (the configuration file is shown in Figure 1), which contains the definition of the “Container” that needs to load components as a “plug-in component” with individual “initialization parameters” and a “message hookup” declaration of each plug-in components as shown in Figure 1.

Any component that needs to be plugged-in to the container should implement the plug-in interface exposed by the “Container”. Each plug-in component has its own implementation for “incoming message” and “outgoing message,”  but expose these messages with proper callback functions and message definitions so at runtime “message hookups” can be performed as described in the configurator. Moreover, the “incoming message” and “outgoing message” documentation should be done in the API level, which is a good programming practice anyway! After the configuration file is written, it depends on these public APIs to initialize and integrate the components.

Especially in Flex, making the container plug-in a generic interface like mx.Core.IUIComponent provides an open solution where any Flex container can be made to implement this pattern with ease to load and manage a hoard of different components at runtime.

Only one thing to note here is that the container has to be plug-in integration-enabled to make this pattern work and this can only be achieved when the integrator hookup is implemented to the container at compile time.

Advantages of the Plug-in Integrator Pattern
These are the direct advantages of using this pattern:
  • Provides runtime integration and dependency injection to maintain loosely coupled software components.
  • Provides an easy way to build new Flex applications by integrating already released tested components to cut down software development costs.
  • Doesn't really tie down developers with several interfaces to be implemented to use the pattern. For a container going with mx.core.IUIComponent interface, there is absolutely no overhead when using this pattern.
  • With this infrastructure it’s possible to build a fully functional enterprise system by integrating Flex components in the runtime by injecting dependencies.
  • This pattern is an architectural framework where the individual components can be written based on other frameworks but can be used as a plug-in component afterward.
  • This pattern exposes the components to have maximum flexibility and reusability and works as a true add-on to any project. It also tries to advocate good programming practices to follow general OOP patterns and event-driven programming.
  • The real reward for using this pattern comes while programming huge enterprise projects where there are several different groups involved in implementing different UI functionalities; all their components can then be integrated using this pattern to build a robust solution.
  • As SOA provides the basic infrastructure to businesses to tie down the business processes, this pattern provides a way to take individual UI components from disparate sources to tie them together and also maintain the UI workflow.
  • It’s very easy to set up in Flex, but provides the ultimate platform to come up with intra-widget communications to maximize a user experience that is apt for any UI technology.

Key Concepts of the Plug-in Integrator
Here are the five key roles for a plug-in integrator:


The Container

A container that exposes the plug-in capability to components

The Plug-in Interface

Plug-in interface definition for the components to implement

The Component

Component implementing the plug-in interface

The Configurator

 The core repository used by the integrator to load  components with a proper definition of components with their initialization details and internal messaging

The Integrator

Plug-in integrator implementation that is responsible for reading the configurator and then plugging in the components and wiring them up with messaging at runtime

The Container
The container is responsible for plug-in components implementing the container’s plug-in interface. In Flex, a container can be implemented either by subclassing or embedding any standard Flex containers such as mx:TabNavigator or mx:ViewStack etc.

The Plug-in Interface
The Plug-in Interface is the interface exposed by the container to populate its child list as plug-in components. This interface can be any application-specific interface that can be used by the container to load components as plug-ins. For simplicity it can be any mx.core.IUIComponent (the base Flex UI interface), so that any Flex-based UI component can be plugged in to the container. While going with a generic interface, it’s possible to plug in a lot of components but it becomes difficult to initialize and maintain them. To address this issue, it’s possible to expose some of the internal container variables as hookup points and list them in the configurator, enabling the plug-in components to be initialized through the integrator by function executions at runtime. 

The Component
The component is the implementation of the plug-in interface, which can be readily loaded as plug-ins in the container. If we go with the case of mx.core.IUIComponent as the plug-in interface, any Flex UI component is an implementation of a IUIComponent and can be used as a plug-in component, but depending on the container interface definition it’s possible to allow only stated interface implementations to be used as plug-in components. To make components plugged in to the container at runtime, these components are wrapped up in Flex modules that are used by the integrator to load these components in the container. These components are then initialized and hooked up with internal messaging among themselves according to the configurator settings.

The Configurator
This is the repository where the container’s configuration information is stored. This includes plug-in information for containers with detailed initialization and messaging hookup information for all the individual plug-in components. The configurator may be implemented as relational database tables or a simple XML file depending on the implementation needs. The XML schema that describes the basic structure of the configurator can be found in Annexure-A, but the crucial types are described below:

<xs:complexType name="containerConfigurationType">
        <xs:element ref="keepStaticChildren" minOccurs="1"/>
<xs:element name="pluginComponent" type="pluginComponentType"
    <xs:attribute name="clazz" type="xs:string" use="required"/>
    <xs:attribute name="pluginInterface" type="xs:string" use="required"/>

Complex type “containerConfigurationType” defines the basic structure to hook up plug-in integrator functionality to any container. “clazz” attribute is the unique identifier of the container and the “plugInInterface” refers to the plug-in interface being exposed by the container to plug-in components. “keepStaticChildren” tells the container to keep the already-added components or just to add components from the configurator definitions.

<xs:complexType name="pluginComponentType">
    <xs:element name="property" type="propertyType" maxOccurs="unbounded"/>
            <xs:element ref="moduleURL"/>
            <xs:element ref="asClass"/>
            <xs:element name="initParam" type="initParamType" maxOccurs="unbounded"/>
            <xs:element name="msgMap" type="msgMapType" maxOccurs="unbounded"/>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="name" type="xs:string" use="required"/>

The “pluginComponentType” complex type definition is self-explanatory. The two important attributes here are “moduleURL” and “asClass”. To load the component as an external module(runtime loading), moduleURL is used, but to load a component statically, asClass attribute is used. The moduleURL is given precedence over the asClass to enable the loading of new versions of components in the production environment.

“property” elements are a generic way to define public component-specific properties that could be set to the component implementing the container’s plug-in interface.

<xs:complexType name="initParamType">
        <xs:element name="selfFunction" type="selfFunctionType"
    <xs:attribute name="type" use="required">
            <xs:restriction base="xs:NMTOKEN">
                <xs:enumeration value="funcHookup"/>
                <xs:enumeration value="varHookup"/>
    <xs:attribute name="bindToContainerProperty" type="xs:string" use="required"/>
    <xs:attribute name="selfpropertyName" type="xs:string"/>

There are two ways to effectively plug in a component to a container:
  1. Using the classical interface-based approach where at compile time the components are compiled with the interface being exposed by the container and the hookup to container is automatic
  2. If the interface is generic enough, then the actual hookup between the container and the plug-in component may be injected in the runtime where the public variables or functions in the container can be hooked up to the plugged-in component’s variable or functions using the configurator definitions.

The first case is more obvious and more extensively used but the second way is more robust and integration friendly. The “initparamType” is used mostly to hook up a container to plug-in components using the second method. This hookup can be performed in two ways: as function hookup or a variable hookup. In a function hookup any public function in the plug-in component is hooked up and bound to a container variable, while in the variable hookup it’s a variable in the plug-in component that is bound to a container variable. To ActionScript programmers, data binding is very familiar, where as for Java or any other language, data binding means depending on the state change of the source field and the destination of data binding automatically gets a property change event to reflect the change.

Implementing the container on a very specific plug-in interface works but limits the plug-in components, which can be easily plugged in to the container, but a more generic plug-in interface enables a wide range of components to be plugged in and readily hooked up and bound in the runtime, enabling easy integration. 

<xsd:complexType name="msgMapType">

    <xsd:element name="srcExtentionPoint" type="srcExtentionPointType"/>
    <xsd:element name="destHandler" type="destHandlerType"/>
<xsd:attribute name="id" type="xsd:string" use="required"/>
<xsd:attribute name="handler" use="required">
        <xsd:restriction base="xsd:NMTOKEN">
            <xsd:enumeration value="event"/>
            <xsd:enumeration value="function"/>

msgMapType” is a very important complex type that defines the mechanism to exchange messages between the individual plug-in components. This provides an easy way to integrate plug-in components to enhance and develop new functionality. Any message map element of type msgMapType has a “srcExtentionPointType” and a desination handler of type “destHandlerType”. With this approach it is possible to map a source message or callback function to a destination message or directly to any public function in the destination plug-in component. This provides a loosely coupled event-driven way to hook up plug-in components in the runtime to build functional applications.

The other important complex types defined are various “functionTypes”, “objectType” and “objectRefType”. All these are self-explanatory and can be found in Annexure-1.

The Integrator
This is the most important piece in the whole Plug-in Integrator Pattern. The integrator is responsible for containers to load components as plug-ins, initialize them, and maintain messaging integration points depending on the configurator details. The Integrator is responsible for making any container to load and manage components as plug-ins and integrating the plug-in components together using messaging or function callbacks.

Here is the list of core duties of the integrator:

  1. Loads the configuration details from the configurator
  2. Depending on the configuration, initializes the containers for plug-in integration
  3. Loads plug-in components statically (as inline compiled class) or as a separate binary executable (as a Flex module).
  4. Plugs in the loaded plug-in component to the container
  5. Initializes the plug-in component according to configuration details.
  6. Hooks up messaging with other deployed plug-ins.
As the integrator plugs in components to the mentioned container dependant on the configuration details, it uses the concept of IOC (Inversion of Control) and DI (Dependency Injection) to load new classes and make dynamic function and messaging hookup possible.

The integrator can be implemented in any platform and in any language such as ActionScript, JavaScript, Java, and C#.

Now let’s consider a simple example where a Flex viewer/editor needs to be written to view/edit an object.

More Stories By Indroniel Deb Roy

Indroniel Deb Roy works as an UI Architect for BlueCoat Systems.He has more than 10 years of development experience in the fields of J2EE and Web Application development. In his past he worked in developing web applications for Oracle, Novell, Packeteer, Knova etc. He has a passion for innovation and works with various Web2.0 & J2EE technologies and recently started on Smart Phone & IPhone Development.

More Stories By Alex Nhu

Alex Nhu works as a manager, UI Development at Packeteer Inc. He has more than 11 years of work experience designing and architecting complex server-side J2EE and XML applications. He loves developing Web applications with Flex now after getting a taste of developing UI using other RIA platforms.

Comments (1)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

IoT & Smart Cities Stories
To Really Work for Enterprises, MultiCloud Adoption Requires Far Better and Inclusive Cloud Monitoring and Cost Management … But How? Overwhelmingly, even as enterprises have adopted cloud computing and are expanding to multi-cloud computing, IT leaders remain concerned about how to monitor, manage and control costs across hybrid and multi-cloud deployments. It’s clear that traditional IT monitoring and management approaches, designed after all for on-premises data centers, are falling short in ...
We are seeing a major migration of enterprises applications to the cloud. As cloud and business use of real time applications accelerate, legacy networks are no longer able to architecturally support cloud adoption and deliver the performance and security required by highly distributed enterprises. These outdated solutions have become more costly and complicated to implement, install, manage, and maintain.SD-WAN offers unlimited capabilities for accessing the benefits of the cloud and Internet. ...
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-c...
The Founder of NostaLab and a member of the Google Health Advisory Board, John is a unique combination of strategic thinker, marketer and entrepreneur. His career was built on the "science of advertising" combining strategy, creativity and marketing for industry-leading results. Combined with his ability to communicate complicated scientific concepts in a way that consumers and scientists alike can appreciate, John is a sought-after speaker for conferences on the forefront of healthcare science,...
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
DXWorldEXPO LLC announced today that Ed Featherston has been named the "Tech Chair" of "FinTechEXPO - New York Blockchain Event" of CloudEXPO's 10-Year Anniversary Event which will take place on November 12-13, 2018 in New York City. CloudEXPO | DXWorldEXPO New York will present keynotes, general sessions, and more than 20 blockchain sessions by leading FinTech experts.
Apps and devices shouldn't stop working when there's limited or no network connectivity. Learn how to bring data stored in a cloud database to the edge of the network (and back again) whenever an Internet connection is available. In his session at 17th Cloud Expo, Ben Perlmutter, a Sales Engineer with IBM Cloudant, demonstrated techniques for replicating cloud databases with devices in order to build offline-first mobile or Internet of Things (IoT) apps that can provide a better, faster user e...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science" is responsible for guiding the technology strategy within Hitachi Vantara for IoT and Analytics. Bill brings a balanced business-technology approach that focuses on business outcomes to drive data, analytics and technology decisions that underpin an organization's digital transformation strategy.