Add-on System¶
This section describes the add-on system from the perspective of a developer.
The implementation of the add-on system is located in the maven module with the group Id org.openecard and the artifact Id addon.
All classes are in a sub namespace of org.openecard.addon. The module is divided into the following five packages:
- org.openecard.addon
In this package are the main classes of the add-on system, for example the AddonManager or the different AddonRegistries.
- org.openecard.addon.bind
This package includes all classes representing the interface between an addon and a specific binding. That is to say, here are the classes needed to convert a specific request, for example a HTTP request that arrives via the localhost binding, into a generic request, which is independent from binding and vice versa for the response.
- org.openecard.addon.ifd
In here are the classes that specify the interface for an IFD protocol and the factory to instantiate such a protocol.
- org.openecard.addon.manifest
This package accumulates all classes needed to convert (automatically) between the XML represantation of the add-on description and it's java object pendants.
- org.openecard.addon.sal
In here are the classes that specify the interface for an SAL protocol and the factory to instantiate such a protocol.
Types of add-ons
TODO¶
Add-on development¶
This section describes the steps to take when developing an add-on.
As first step a new XML file called Addon.xml in the META-INF directory of the project should be created and the fields that describe the general part of the add-ons can already be filled.
An example file for a PIN Management addon could look like this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AddonBundleDescription>
<ID>PIN-Plugin</ID>
<Version>1.0</Version>
<About />
<License />
<LocalizedName xml:lang="DE">PIN Verwaltung</LocalizedName>
<LocalizedDescription xml:lang="DE">Verwaltung von PIN/ PUK und gegebenenfalls anderen Geheimnissen der Chipkarte.
</LocalizedDescription>
<LocalizedName xml:lang="EN">PIN Management</LocalizedName>
<LocalizedDescription xml:lang="EN">Management of PIN/ PUK and possibly other secrets of the smart-card.</LocalizedDescription>
<Logo>images/logo.png</Logo>
<ConfigDescription />
<BindingActions />
<ApplicationActions />
<IFDActions />
<SALActions />
</AddonBundleDescription>
As can be seen, some fields can be localized. That fields are: LocalizedName, LocalizedDescription and About
The next step is to think about what actions should be offerd by the add-on and of what type these actions are.
For the PIN management example there are two actions. An action to change a PIN and a second action to unblock a PIN.
These actions are not of type ProtocolPlugin nor AppPluginAction, but of type AppExtensionAction, as they expand the function of the "Open an e-card app" independent from a binding or protocol.
TODO ...