Service Oriented Platform: 4 Modes

February 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 (including their latest 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 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.

SOP 4 Modes

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:

  1. 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).
  2. 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:

  1. 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.
  2. 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:

Another mode similar to the iFrame mode is the Mashup mode, which executes the application on the client side (in JavaScript) by providing AJAX APIs to get data from the SOP server (i.e., SOP Context) and the application server.

Here is the simplified application lifecycle for the Client-Mashup mode:

  1.  When a user clicks on the application page or component, the SOP server initializes the application and returns the HTML and JavaScript content for the browser to execute.
  2. The application (JavaScript) code can make AJAX calls to the applicationaccess content and methods.
  3. A JavaScript API is also provided to the application to access SOP data and methods.

For heavy JavaScript developers, this approach can be very attractive. It also forces the application to take maximum advantage of the AJAX model and offer a consistent way to access SOP and application data and methods. It is a common and convenient means for developing widgets (note: OpenSocial is based on the Google Gadgets application model).

However, for full applications, this approach can be a little too JavaScript-heavy and limits portability. It also requires the developer to re-implement some basic browser functionalities, such as page navigation, since each user click will need to be handled in JavaScript.

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 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 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.

Related Links:

4 Responses to “Service Oriented Platform: 4 Modes”

  1. Evert Says:

    thats what we need.. more hype and abbreviations for things that have been around for years

  2. Jeremy Chone Says:

    Agreed, SOP and PaaS are a little bit buzzy terms, but nevertheless, I think these are interesting and promising trends.

  3. Charlie Says:

    I checked out Bungee’s platform yesterday.

    The Good:

    IDE-in-a-browser is cool. Get to your dev environment from anywhere just by logging in from a browser. Office apps are moving to the browser so why not an IDE?

    GUI includes simple tools for testing and deploying. You can move different versions from the version control system directly into production, switch the deployed app to another version, and all that kind of stuff. Awesome!

    Free development, they just charge for hosting (after a limited free hosting trial). Pay for what you use, traffic-wise, like Amazon’s Web Services. This is an attractive idea to me.

    The Bad:
    They have their own proprietary language. What if I want to take my app elsewhere? Apparently I would be stuck with Bungee. Makes me less enthusiastic about investing the effort in the first place. Why not just pick some solid, open language and framework and standardize on it?

    From what I can tell, you can’t type code in. You have to drag and drop a statement at a time into a code window, and then edit the pieces of the statement via a properties page. This drag-and-drop ability could be great for getting up to speed with a language and framework, but don’t make that the only way to write the code! On the other hand, you can never mistype anything so you won’t get any syntax errors. I suspect it won’t let you do anything that won’t compile (and run?)

    I can’t find anything along the lines of developing applications for some of the platforms discussed above.

    The ugly:

    The IDE is pretty full-featured and powerful for something running in a browser. The downside of that turns out to be that it was very slow to respond to mouse clicks, and very slow to draw on the screen. At least, it was for me, and I have a fast connection and a fast machine. And I’m in Denver, where I understand one of their hosting centers resides. Hopefully this will change, because with the issues above about having to do _everything_ – even write code – with the mouse, I can’t even consider using it for anything right now.

    My Ideal hosting service:

    How about a service like this that provides the IDE, task management, team development, version control and deployment management system and remains agnostic to which language and framwork you decide to use to actually write your app? No more need to ftp stuff around, manage different versions, and deal with all those SCM issues. It would be cool if the version control underneath were something free and powerful like git, and they provided access to the repository but still provided a nice visual scm tool on top to manage and deploy various versions.

  4. Ted Haeger Says:

    Thanks for providing such a thorough comment reviewing Bungee Connect. I work for Bungee Labs, provider of Bungee Connect, and I’d like to take a moment to provide a couple words in response.

    Re: Proprietary Language
    Your comments here are fair, and it’s an area in which we are applying significant effort. Part of the challenge of providing a platform that couples rich interaction in the browser with ample power in application logic is orchestration–keeping the user interface at the browser in sync with the application in the data center. To provide the static web pages that are the standard today, or the single-interaction AJAX widget, is done easily enough. But how do you update different views of the very same data on a single page as the data state changes? How about when your application uses multiple browser windows? And, unless you want all the application logic to run inside the browser (as with Flash and Silverlight), then you also have to deal with having the application view being very remote from where the application actually runs.
    This state management challenge is one of many that Bungee Labs takes on with Bungee Connect. We found that we needed to take the classic Model-View-Controller architectural pattern and refine it for this situation. The language that we use is a result of that. The downside is that we could not simply use an existing language. Nevertheless, it’s fair to ask why didn’t we at least follow an existing language’s syntax when we developed Bungee Connect. I suspect you won’t be surprised to learn that that is exactly what we recently tasked a small team of our engineers to figure out. Our goal is have a language that better follows the conventions of an established language, making it easier to extract your code from Bungee Connect should you decide that our service is not for you.

    Bungee Labs’ CTO Dave Mitchell also adds (in another blog comment response):
    “We wanted a language that would be best suited to on-demand development and deployment. In effect, we wanted all the flexibility of a dynamic language during the development process in the cloud (that requires no compilation or linking or p-code translation for any incremental code edits and testing, etc.), but then all the power and performance of a intricately instrumented hand-crafted 3GL language like C++, C#, and Java (that can reduce down to a compiled, highly optimized format) during the deployment stage. It would be very difficult to achieve both attributes simultaneously with a traditional language offering where the emphasis is on one or the other (dynamic/interpreted VS compiled/highly optimized).”

    Re: Mouse-driven vs. Free Text Editing
    Again, a fair criticism. We hear from many that they would prefer to be able to edit freely. Developing with Bungee Connect is rather mouse-intensive. Part of the language project mentioned above will address this, and thereby liberate the developer’s other 9 fingers.

    The upside of the current system is that with a few mouse gestures, the IDE handles what would normally amount to tens of lines of code. The amount of automation is significant, and our top developer-users are able to create really sophisticated apps in very little time at all.

    Re: “I can’t find anything along the lines of developing applications for some of the platforms discussed above.”
    I didn’t get which platforms you referred to, but if AWS was one, I offer for that case that we have importable code for Amazon FPS and SimpleDB, among others.

    Re: Slow performance
    You’re right that we have a data center right where you are in Denver, so I’m curious to know when you last tested this. If it was recently (past couple months) then, I’d like to find out more about your setup so that we can figure out why this happened to you. You can reach me at ted [at] bungeelabs [dot] com.


    Ted Haeger
    Director, Bungee Connect Developer Network
    Bungee Labs