Remote API Research

Document created by resplin Employee on Jun 6, 2015Last modified by alfresco-archivist on Aug 31, 2016
Version 2Show Document
  • View in full screen mode

Obsolete Pages{{Obsolete}}

The official documentation is at: http://docs.alfresco.com



Research For Future Features
NOTE: This page represents research.  Features mentioned in this page are not necessarily going to be part of the Alfresco product or added to the development time line.


Goals


Alfresco currently supports the following remote APIs:


  1. Alfresco Web Services
  2. JCR-RMI to allow remote JSR-170 access

Both of these APIs are fully supported, but do not expose the full capabilities of Alfresco.  Also, the development of new Web Services is expensive.

With this in mind, and looking to future features we'd like to support, it's time to take a look at how we provide a full-featured Remote API.

Providing a Remote API in itself is not a technical issue.  However, it touches on many (current & future) aspects of Alfresco and so some thought-time is worth while.  In parallel, the industry is focusing on standardising content management repository & services interfaces.

Moving forward, we would like to achieve the followings goals:


  1. Stand-alone Repository Server (equivalent to database)
  2. Detached Alfresco Web Client
  3. Multiple Alfresco Web Clients against single Repository Server
  4. Federated Repository Servers (distributed, not clustered)
  5. Consistent API approach for server communication / application development
  6. Make it easier to expose new Web Service APIs

Also, potentially touches on:


  1. Federated Search (remote api is just one of many implementation approaches)
  2. Public Query Language
  3. Server Administration (run-time configuration)

Requirements


  1. Remote API is the definitive specification of public Repository capabilities
  2. Remote API is specified in Java??
  3. Provides all functions required by detached Web Client
  4. Designed for remote access (really - latency, bandwidth)
  5. Also accessible in-process
  6. Support pluggable remoting protocols
    • RMI
    • SOAP
    • HTTP
    • ...
  7. Allow direct client access to remoting protocol
    1. BPEL engine (SOAP), Ajax client/Browser (HTTP)
  8. Support de-referencable (cross-repository) content/meta-data/node handles
  9. Authentication context
  10. Transaction context (start, commit, rollback as part of protocol?)
  11. Support content/meta-data,node caching
  12. Client API Factory (ala JDBC connection)
  13. Support for client-side object-oriented API wrappers for developer
    1. Batching statements
    2. Statement order
    3. Transient references for new objects
    4. ...
  14. Rid Apache Axis

Also, potentially touches on:


  1. Allow a RESTful HTTP remoting plug-in

How the APIs fit together


600px


Federated Repository Servers


TODO: List out typical network topologies (repos, caching, clients, search etc)


Tasks


  1. Catalog
    1. Current Foundation, Web Service API methods
    2. Web Client / API interactions (very important)
  2. Research
    1. XFire
    2. Spring Remoting
    3. Atom, Atom Publishing, OpenSearch, Micro-formats, REST vs. Web-Services
    4. Restlets
  3. Java API definition
    1. Cross-cutting concerns (auth, trx, references)
    2. Services
    3. Java API / remoting protocol mappings (cross-cutting concerns to RMI/SOAP)
  4. Java API Implementation
    1. Client API Factory
    2. Service implementations
    3. RMI bindings
    4. SOAP bindings
    5. In-process bindings
  5. Developer API re-hosting
    1. JSR-170
    2. PHP?
    3. Javascript?
  6. Custom Remoting protocol definition
    1. RESTful HTTP (future?)

API Services


TODO: Define

Attachments

Outcomes