This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
documentation:architecture [2018/06/26 14:03] tjotov |
— (current) | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== ADUCID architecture ====== | ||
- | |||
- | {{: | ||
- | |||
- | This chapter describes internal functionality of ADUCID. It is a foundation of [[integration: | ||
- | |||
- | ===== Target application ===== | ||
- | |||
- | Target application is any application that uses ADUCID® services. Examples of such applications include web applications with standard thin client (standard browser), mobile applications with server counterpart, | ||
- | |||
- | From the system point of view, the application consists of a client part and a server part (TA Client and TA Server), which communicate with each other in their own manner via an R1 interface. | ||
- | |||
- | With [[integration: | ||
- | |||
- | ===== Server part of ADUCID® ===== | ||
- | |||
- | The entire server part along with the operating system and all third-party systems required to operate the server part of ADUCID are supplied as complete virtual appliance but can be installed as a set of components. | ||
- | |||
- | The server side consists of these parts: | ||
- | |||
- | ==== AIM ==== | ||
- | ADUCID< | ||
- | |||
- | AIM is controlled by the target application using the R4 interface. Using this interface, it also provides services for working with user data. | ||
- | |||
- | Using the R3 interface, it communicates with the client part of ADUCID< | ||
- | |||
- | |||
- | ==== SQL database ==== | ||
- | SQL database is used to store ADUCID identites, events and licensing logs. The default SQL DB is Postgress but can be replaced with any JPA compatible DB. | ||
- | |||
- | ==== Admin applications ==== | ||
- | |||
- | See [[documentation: | ||
- | |||
- | |||
- | ==== Proofing applications ==== | ||
- | |||
- | See [[documentation: | ||
- | |||
- | |||
- | ===== PEIG - Client part of ADUCID ===== | ||
- | |||
- | see [[: | ||
- | |||
- | |||
- | ===== Interfaces ===== | ||
- | |||
- | ADUCID uses 4 basic interfaces: | ||
- | |||
- | ==== R1 ==== | ||
- | |||
- | R1 is an application interface handled by customer application itself. In mobile application integration R1 is encapsulated in PEIG API. | ||
- | |||
- | ==== R2 ==== | ||
- | |||
- | R2 is an interface between client application and PEIG. This communication can be handled via: | ||
- | |||
- | * URI scheme on mobile phones scheme **aducid** | ||
- | * Scanning a QR code | ||
- | * Integrated using PEIG API | ||
- | * Low level R2 is implemented as UNIX Socket or Windows Pipe | ||
- | |||
- | On Windows and OS X PEIG R2 can be called using auxiliary application PEIG which acceps RUI as an arguments and sends it via Unix socket / Windows pipe | ||
- | |||
- | ==== R3 ==== | ||
- | |||
- | R3 is an internal interface between PEIG and AIM which uses http transport and SOAP protocol. | ||
- | |||
- | ==== R4 ==== | ||
- | |||
- | R4 is interface between server application and AIM. Like R3 it uses http (or https) transport and SOAP protocol. | ||
- | |||
- | R4 is “a low level” layer. It is encapsulated in ADUCID WEB Platform SDK or ADUCID Client SDK for simplified integration. | ||
- | |||
- | |||
- | ===== Communication between components ===== | ||
- | |||
- | A fundamental unit of activity in ADUCID< | ||
- | |||
- | {{: | ||
- | |||
- | == Communications diagram == | ||
- | |||
- | The server part of the target application first requests the required operation via the R4 control interface and specifies its AIM parameters. | ||
- | |||
- | The result is a unique, one-time authId operation identifier that can be initiated either by the target application or AIM. | ||
- | |||
- | The client part of the target application transmits the PEIG< | ||
- | |||
- | Communication between the client part and the server part of the target application via the R1 interface is handled by the target application. | ||
- | |||
- | The startup event from the R2 interface is sent to PEIG< | ||
- | |||
- | In terms of communication, | ||
- | |||
- | When the operation is concluded, a random, one-time secret authKey is generated on PEIG< | ||
- | |||
- | <font 11.0pt/ | ||
- | |||
- | PEIG finishes its activity by using a return URI. The return URI is transferred from AIM to PEIG during PEIG activity. The return URI is typically [[https://, | ||
- | |||