Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

PDS Client 2.0 Design

Revision as of 13:18, 6 April 2010 by Vlakhno.aquasoft.dp.ua (Talk | contribs) (Architecture)

The following design is just proposal to replace current Azigo3 architecture and extend PDS Client 2.0

The PDS Client is packaged as code library and triggered by separate operating system process with permissions of current logged-in user, so each user in the system has his own instance of PDS.

Architecture

The following three pictures show design of PDS Client 2.0. The given architecture is based on current components of Azigo3 and includes potentially new components. Communication with remote servers is the same as shown on PDS Client 2.0 architecture as well as internal communication between PDS Client low-level components.

1) First picture shows all components grouped 'by process' on user's machine:

Pds 2.0 design components.png

2) On the second picture interactions between high-level components is represented:

Pds design 2.0 hi-lvl iterations.png

3) As a result of overview of current Azigo3 APIs it has been discovered that PDS Client provides few logical groups of APIs and we can realize them as PDS Client's services as shown below.
IPC Server endpoint is configured by ORB engine (ACE/TAO) during IPC Server initialization. This info and server objects references with POA configuration are stored in IOR Storage. It might be user-specific storage or e.g. TAO Naming Service (but in system context). IOR data is updated after each start of IPC Server. Using IOR data clients (browser extensions, PDS Dashboard etc) of PDS Client will be able to configure their IPC clients and get access to the IPC server. Hence, IPC clients of several logged-in users will know their IPC server endpoints (because IOR data is user specific) and it gives the chance to avoid a situation when clients of one user access to a server of other users in the system.

Pds design 2.0 client-server interactions.png

It consists of the following C++ components:

  • Components 2.0#PAUL - Personal Agent Utility Layer (PAUL) - the higher level logic of the PDS Client 2.0
  • Components 2.0#IPC Lib - planned.
  • Components 2.0#Auth Client

Security

We have to figure out how to identify clients which can get access to PDS Client.

Back to the top