<?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 <xref href="GUID-6482956D-C3A3-5B68-A37F-4250C85B0D82.dita">polymorphic interface DLLs</xref>.
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_d0e173024_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>