<?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_d0e179619_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>