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.
Difference between revisions of "PDS Client 2.0 Design"
| Line 13: | Line 13: | ||
[[Image:Pds_design_2.0_hi-lvl_iterations.png|center]] | [[Image:Pds_design_2.0_hi-lvl_iterations.png|center]] | ||
3) After overview of current Azigo3 APIs was discovered that PDS client provides few logical groups of APIs and we can realize them as PDS Client's services as shown below. | 3) After overview of current Azigo3 APIs was 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). 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). So each start of IPC Server updates its IOR data. 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). | ||
[[Image:Pds_design_2.0_client-server_interactions.png|center]] | [[Image:Pds_design_2.0_client-server_interactions.png|center]] | ||
| Line 26: | Line 28: | ||
*[[Components 2.0#IdAS_Client_C.2B.2B|Components 2.0#IdAS Client C++]] - communicates with [[Personal Data Store 2.0]] | *[[Components 2.0#IdAS_Client_C.2B.2B|Components 2.0#IdAS Client C++]] - communicates with [[Personal Data Store 2.0]] | ||
| + | |||
| + | === Security === | ||
| + | |||
| + | We have to figure out how to identify clients which can get access to PDS Client. | ||
[[Category:Higgins_Packages]] | [[Category:Higgins_Packages]] | ||
Revision as of 12:48, 6 April 2010
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 components grouped by process on user's machine:
2) On the second picture interactions between high-level components is represented:
3) After overview of current Azigo3 APIs was 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). 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). So each start of IPC Server updates its IOR data. 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).
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#Persona Data Provider - An API for the Persona Data Model 2.0
- Components 2.0#IPC Lib - planned.
- Components 2.0#Auth Client
- Components 2.0#IdAS Client C++ - communicates with Personal Data Store 2.0
Security
We have to figure out how to identify clients which can get access to PDS Client.