Building Feedly

Entries categorized as ‘Architecture’

What is OpenSocial?

October 31, 2007 · No Comments

Introduction to OpenSocial

Google unveils their OpenSocial initiative. We have had the chance to play with OpenSocial over the last 6 weeks. In a nutshell, OpenSocial is interesting because it allows widgets and applications to asks containers (iGoogle, Orkut and others) information about you, about your contacts and your friends, in a very simple and inter-operable way. It also formalizes the concept of activity stream so that some applications can contribute events and some other applications can filter them, mash them up and display them to the user.

OpenSocial is a natural evolution of shared-authentication systems: It makes a lot of sense for each application to NOT have to have its own copy of who you are, who your contacts and friends are.

OpenSocial is also a natural evolution of personalization frameworks such as iGoogle: widgets can offer much more value to users if they have a way to learn more about you and your friends.

What does it mean for feeddo?

The biggest value for feeddo users is that it is going to simplify the task of finding the recommendation feeds of your friends. We will most likely allow you to add your most recommended feeds as a widget to iGoogle and Orkut (similar to what we do today with Facebook).

Anything else?

OpenSocial is yet another proof that JSON-driven RESTful Web Services are the right abstraction layer for exposing services on the web and that people should look at sharpening their Javascript/Actionscript skills because that is where the next wave of innovation is going to take place.

Kudos to Patrick Chanezon and the rest of the Google team for pulling this initiative off!

Categories: Architecture · Mashups · Software

Assembly, Composition or Orchestration

August 18, 2007 · 4 Comments

This podcast from David Chappell tries tries to address a though question: what is SCA? What makes this challenging is that the terms assembly, composition and orchestration are abstract concepts which do not really have clear boundaries in peoples minds.

So what is the difference between orchestration and assembly?!?

Orchestration defines a set of steps/activities which represent a business process (step 1: verify the user account, step 2: verify inventory, step 3: process credit card, step 4: send email to the user). Some of these steps can be performed sequentially, some of them in parallel, exceptions can occur, manual intervention might be required, etc… Some orchestrations can be simple, some can be very sophisticated. Orchestrations are modeled using a standard language called BPEL. [ (Updated based on the comment from Greg Pavlik) Note: Orchestration logic is not usually captured in one monolitic business process. It can include subprocess steps (which can be distributed physically across the enterprise or across enterprises). The process itself or some of it steps can be implemented in Java or C.]

But what is assembly then?

As part of step 1, the BPEL process needs to integrate with an LDAP service. As part of step 2, the BPEL process need to integrate with an SAP system. As part of exception processing, it needs to integrate with a workflow sub-system. These integration points (links between BPEL processes and external systems) are called bindings. Bindings usually include location of the different services, protocols to use, security, logging and reliability requirements. The SCA Assembly spec defines a language for modeling these bindings.

[(Updated based on the comment from Greg Pavlik) Note: In the case where a process include subprocess or other component written in a variety of languages, the binding problem extends beyond linking to external systems to the need for linking to internal parts.]

The benefit of SCA is that is makes bindings much easier to monitor, manage and change - not super sexy but the potential for a significant step forward in terms of deployment and change management.

Categories: Architecture