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

<li id="GUID-6460F0E0-26A3-5038-B8C2-0F4706547600"><p>Register and

discover interface implementations </p> </li>

<li id="GUID-78AE02BB-13BE-5DA0-B2F3-CC376654589B"><p>Provide version

control for plug-ins </p> </li>

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

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