<?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 xml:lang="en" id="GUID-30201A05-C6CE-5D34-9BDF-CDA4EE44878D"><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><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