Service Oriented Platform: 4 ModesFebruary 22nd, 2008 by jeremychone
Over the last few years, we have witnessed the emergence of a new type of software platform – the Service Oriented Platform (SOP). The SOP concept is to offer an application platform as a network service (inside or outside an enterprise firewall), providing a centralized runtime to execute and manage distributed or centralized applications.
SOP services can range from application aggregation, presentation, linking (e.g, Mashup), provisioning, componentization, and context augmentation (e.g., Social Graph and common application data). As SOPs mature, it would not be surprising to see these platforms offer most, if not all, of the traditional application platform services in a service-oriented manner, such as application testing, versioning, data migration, and much more.
In the consumer space, the best SOP examples would be Facebook, OpenSocial, and Ning. In the enterprise, a good example would be SalesForce.com (including their latest Force.com addition) and some of the newer smaller players such as Coghead, DabbleDB, and BungeeConnect. Note that SOP solutions can be offered as a hosted service (Platform as a Service, aka PaaS), or can be packaged as a product (not as common yet). In many ways, enterprise portal architecture can be considered the SOP ancestor.
We can identify four distinct but complementary main SOP access modes. Most SOP providers (such as Facebook and SalesForce.com) offer more than one access mode. Others, like OpenSocial, have thus far focused only on one.
Below is a simplified visualization of these modes and their corresponding descriptions.
A) Proxy Mode:
In this mode, the SOP is in between the user-browser and the application, and proxies all browser requests to the applications. The best known example of this model is the Facebook FBML application model.
Here is the simplified application lifecycle for the SOP Proxy mode:
- Each page request goes through the SOP server, which forwards the request to the application with some additional SOP context (e.g., Identification and Social Graph information).
- The application then returns the requested page to the SOP server in a specific presentation format (e.g., FBML for Facebook). The SOP server then translates the “SOP-formatted page” into a standard HTML/AJAX format for the browser to read.
This mode allows developers to focus on the content of the application while reusing pre-built SOP components and delegating presentation to the SOP server.
The main caveat of this approach is performance, since each page request [usually] requires an additional http-request to get the result back to the user. Another caveat is the SOP dependence. Usually, this model also requires applications to output a proprietary XML (e.g., FBML and SNML), which limits application portability.
B) iFrame Mode:
In this mode, the SOP server is between the browser and the application only at initialization time, and all subsequent application users’ interactions are forwarded directly to the application (usually using the browser’s iFrame client-sandboxing mechanism). This is commonly known as the Facebook “iFrame mode,” or the not-yet-released Google OpenSocial “type=URL.” This mode also requires the SOP server to have a strong set of REST/SOAP APIs, since this will be the only way for the application to access SOP context information (e.g., Social Graph).
Here is the simplified application lifecycle for the iFrame mode:
- When a user clicks on the application page, the SOP server initializes the application and returns an HTML page to the browser with an iFrame pointing directly to the application.
- Every subsequent user’s interaction with the application will be in the context of the applications, as if the application had its own browser window.
This mode enables full user interface control and maximum application portability. However, developers will not be able to use the SOP presentation and component services, and will have to re-implement common components and look & feel.
Note: To my knowledge, most Facebook applications are using the Proxy mode mainly for to avoid these two caveats.
C) Client-Mashup Mode:
Here is the simplified application lifecycle for the Client-Mashup mode:
D) Server-Embedded Mode
The Server-Embedded SOP mode is probably the most involved from an SOP implementation standpoint. In this mode, the SOP server stores, manages, and executes the application codes and data. This approach usually requires the SOP server to provide a browser interface to develop, test, and manage the application. In the consumer market, Ning, Coghead, DabbleDB, and BungeeConnect are good examples of such a model, as well as Force.com on the enterprise side.
This mode works very similarly to the Proxy mode, except that now the application runs in the process (theoretically speaking) of the SOP server.
So, here is a first pass at the Service Oriented Platform concepts. SOP has already made a significant impact on the software industry, as we have seen with Facebook and SalesForce.com. It is probably safe to assume that SOP will become even more relevant to the consumer and enterprise software market as time goes on. From a theoretical architecture point of view, it is interesting to see the lines between online, hosted, distributed, and centralized being blurred.
Note to self: Probably a good time to update my Buzzpad.