<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-30201A05-C6CE-5D34-9BDF-CDA4EE44878D" xml:lang="en"><title>ECom Architecture</title><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>In C++, the existence of abstract base classes and virtual functions
allows the programs to call, or access interfaces without knowing
the actual implementation. This mechanism gives a flexibility of writing
the implementation independent of the interface. The implementations
are known as Plug-ins. </p>
<p>When an application wishes to use a plug-in, an object is to be
instantiated to perform the required processing. The object specifics are not known until run-time. The general characteristics
of the processing are known, and these are presented as an interface
API. </p>
<p>In early versions of Symbian platform, implementations were provided
by polymorphic interface DLLs. All the frameworks within the Symbian
platform that needed to use plug-ins had to provide own mechanisms
for the clients to discover and instantiate the implementations. The
above method resulted in duplication of functionality. </p>
<p>The Plug-in (ECom) Framework introduces a generic framework that
provides a single mechanism to: </p>
<ul>
<li id="GUID-6460F0E0-26A3-5038-B8C2-0F4706547600"><p>Register and
discover interface implementations </p> </li>
<li id="GUID-4045CA55-1286-5ACD-A532-240667125469"><p>Select an appropriate
implementation </p> </li>
<li id="GUID-78AE02BB-13BE-5DA0-B2F3-CC376654589B"><p>Provide version
control for plug-ins </p> </li>
</ul>
<section id="GUID-561303EB-F0EA-4BB5-B7BB-3AE31176E79C"><title>Essentials
of a Plug-In System</title> <p>A client wishes to access an object
to perform some processing. The specifics of this object are not known
until run-time. The general characteristics of the processing are
known, and are defined in an interface, but several variants of required
processing could exist, which are provided by implementations that
support the interface. </p> <p>There are four clearly-defined roles
in such a system. </p> <ul>
<li id="GUID-B77969AC-EE5C-53C1-8906-07CF3B2BD11A"><p>The <b>Client</b> that wishes to access services. </p> </li>
<li id="GUID-2E175B1C-7A50-5A00-BBF6-C54F2FC71FFA"><p>The <b>Interface
API</b> that defines how to request services. </p> </li>
<li id="GUID-C8F67E1A-2175-5093-BCFD-06BD90EF59C6"><p>The <b>Interface
Implementation </b> that provides the required processing. </p> </li>
<li id="GUID-A6817508-C5D1-5A7A-B50A-667272292362"><p>The <b>Framework</b> that provides the clients with the required access to the implementations. </p> </li>
</ul> <p>The relationships can be represented as follows: </p> <fig id="GUID-185BDADA-4576-5175-B53B-03C2633E9EA0">
<title>              Plug-in relationships            </title>
<image href="GUID-F78F12AE-64CA-50BD-A715-8F254FBDB793_d0e178049_href.png" placement="inline"/>
</fig> <p>The instantiation mechanism forms the backbone of such a
system, and is responsible for providing the services that identify,
and load the correct interface implementation at run-time. ECom is
such a framework. </p> <p>We'll now look at the system from the perspectives
in turn of each of the interface client, interface implementation,
and interface definition, before summarising the functions of the
ECom. </p> </section>
</conbody></concept>