Difference between revisions of "Org.eclipse.higgins.cardsync.web"

Revision as of 12:59, 6 July 2009

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

Web app that exposes a RESTful endpoint over the I-Card Service.

Version

org.eclipse.higgins.cardsync.web is being developed as part of Higgins 1.1.

Used By

• This web app will be first used by the GTK Selector 1.1-Win solution
• Specifically, it is consumed by the Synchronizing Card Store that is mentioned here: Selector_Architecture_Harmonization#Synchronizing_Card_Store.

Requirements

1. Support a RESTful interface (not SOAP)
2. Only use protocols and technologies that are available royalty-free, are well documented
3. Support selectors that support N>1 cardstores
4. Allow a selector to work completely offline
5. Support bi-directional synchronization of individual cards and individual metadata entries about these cards
6. Support strong authentication from client to CardSync server

RESTful API

• CardSync JAX-RS API - RESTful API
• CardSync Authentication - RESTful API Authentication
• CardSync Exceptions - coming soon

Data Transfer Objects

• CardSync Data Transfer Objects

Server component diagram

Closed Issues

Should we use WebDAV?

Reasons For:

• reduces our development effort as this protocol is designed for resource synchronization. And that's what we're doing
• mature, widely supported. Being used in new projects such as Mozilla Weave.

Reasons Against:

• Not RESTful. WebDAV extends the HTTP verb set. As such is deprecated by the W3C.
• Can interfere with web cache architectures

Decision:

• We will NOT use WebDAV

Should we use Google protocol buffers?

Reasons For:

• Mature
• High performance
• Good libraries in both C++ and Java

Reasons Against:

• Question: Might using protobuf reduce the likelyhood of the CardSpace team collaborating with us and potentially adopting the CardSync Protocol? <-- an outcome that would increase interoperability in the industry

Decision:

• We will NOT use Google protocol buffers