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

Difference between revisions of "I-Card Service 1.1"

(Data Model)
m (Architecture)
Line 22: Line 22:
 
=== Architecture ===
 
=== Architecture ===
  
[[Image:I-card-service.1.1.100.png|center]]
+
[[Image:I-card-service-1.1.102.png|center]]
  
 
''([[Diagram Key]])''
 
''([[Diagram Key]])''

Revision as of 07:59, 15 July 2009

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

Higgins logo 76Wx100H.jpg

The SOAP I-Card Service provides the core processing services for thin-client selectors including: AIR Selector 1.1-Win as well as for the Cloud Selector 1.1 and the iPhone Selector 1.1.

Versions

There are two variants of the I-Card Service: RPPSService and SCRPPSService. The I-Card Service was introduced in Higgins 1.0 and supported the RPPSService variant. RPPSService is used by Higgins Embedded-Selector Extension for Firefox and the I-Card Manager. In Higgins 1.1 the RPPSService has been replaced by the SCRPPSService service. The SCRPPSService is used by AIR Selector 1.1-Win, AIR Selector 1.1-Mac and the iPhone Selector.

RPPSService

The SOAP endpoint is defined here: RPPSService WSDL.

  • The service assumes transport level security
  • Most messages include a username and password for authentication
  • Approximately 110 message types

SCRPPSService

The SOAP endpoint is defined here: SCRPPSService WSDL <-- BROKEN LINK.

  • The service assumes transport level security
  • Most messages are authenticated using an AccessToken.

Implementation

Architecture

I-card-service-1.1.102.png

(Diagram Key)

Components & Packages

Components:

Packages:

Data Model

Within the I-Card Service's RPPS Package are many components that persist data objects on behalf of the user. These include user account data, the users set of cards, and other data. Some components use IdAS to persist their data. Others manage their own local data stores "above" IdAS. An attempt to document all of these different kinds of objects and stores would be a major project. Instead of looking backward, this page describes a new, updated data model that we call the Persona Data Model.

Back to the top