Platform-enabled website
 |
This article is an orphan, as few or no other articles link to it. Please introduce links to this page from related articles; suggestions may be available. (February 2009) |
A platform-enabled website is a website in which additional functionality can be seamlessly integrated by means of an external application programming interface (API)[1]. The platform should provide integration points[2]. These integration points are places in the application where new functionality can be plugged in.
Contents |
[edit] Terminology
[edit] Platform
The Platform is the website on which new functionality is added via an external API. Often the platform provides client libraries for writing platform Applications (also known as Plug-ins)
[edit] Application
Application refers to the external module that integrates with the platform via an external API. The term application is a bit ambiguous since the platform itself is also an application. However, for convenience, this article will typically refer to the plug-ins as applications.
[edit] Plug-in
Same as Application. This article typically refers to Plug-ins as Applications.
[edit] Architecture
A platform-enabled web application exchanges data with plug-in applications. When designing a platform, it is necessary to determine what data is exposed by the platform and under what conditions. This exchange of data is fundamental to the design of a platform-enabled website. Designed correctly, the platform and the applications that extend it are loosely coupled, yet maintain a seamless look and feel.
A loosely coupled relationship between the platform and a plug-in application exists when:
- the platform does not depend on the plug-in application (i.e., the platform will still operate even if a plug-in is removed);
- plug-in applications can be added and removed easily;
- there is a well-defined interface for communication between the platform and the plug-in application;
- unexpected termination or errors in a plug-in application will not be detrimental to the platform;
- there are minimal expectations about the internal operation of each component (i.e., the platform and the plug-in application are black boxes).
[edit] Design Considerations
[edit] Execution
- In what environment will plug-in applications be executed?
- Will plug-in applications execute in a protected sandbox?
- Will plug-in applications be hosted on servers external to the platform?
[edit] Security
- Will your platform run trusted and approved plug-ins only?
- Will your platform protect the end-user from malicious code?
- How will you authenticate and authorize plug-in applications?
[edit] Privacy
- Will your platform protect the company's proprietary data?
- Will your application protect sensitive end-user data?
[edit] Conformity
- Will applications written for your platform maintain a seamless look and feel?
[edit] Installation
- Can users add and remove plug-in applications (this might not always be necessary)?
- How can users find new plug-in applications?
[edit] Communication
- What mechanism will the platform and plug-in applications use to communicate (REST, JSON, XML, JavaScript, etc.)?
[edit] Integration Points
- What integration points will the platform support?
[edit] Presentation
- How will the plug-in be displayed?
- Will you need an IFRAME canvas?
- Will the platform serve as proxy for data exchange between the plug-in canvas and remote web application?
[edit] Agility
- How will the platform handle changes to the Application Programming Interface (API)?
- Will the platform support deprecation of older versions of the API?
- Will multiple revisions of the API be supported simultaneously?
[edit] Standards
- Will your platform's external API conform to any industry standards (e.g., OpenSocial).
[edit] Standards
Certain social networking websites are attempting to create external APIs that conform to the OpenSocial specification. Participants include MySpace, Orkut, Bebo, and LinkedIn.
