Office Live architectures
It has to be said that one of the best things about Microsoft Office Live is that is fits very neatly into a number of different application architectures. I tend to think of an Office Live installation as an on-line managed data store that is available to my applications and then work from there. Whilst such concepts aren’t new, the fact that Office Live is based on WSS 3.0 makes it an attractive proposition for me.
As someone who works for an ISV my main concern is how we can use Office Live as a basis for software solutions whilst protecting our IPR and license revenue. With this in mind, let’s consider some of the possible architectures developers can use to deliver Office Live solutions.
Simple customisation
Out of the box, Office Live can be customised in a number of different ways:
- Creating lists and document libraries.
- Creating workflows to perform business processes.
- Using SharePoint Designer to customise pages.
- Writing javascript to interact with the WSS API.
- Using the built in site designer to create web sites.
These techniques are available to end users and ISV’s in equal measure, and a great deal can be achieved using them. There are examples of sites which use external services such as those provided by Windows Live to extend the functionality of the core system to great effect. From an ISV’s point of view the biggest weakness is that it is very difficult to protect IPR tied up in customisations.
Provision of external services
For my money, the best compromise is to combine customisation of Office Live with provision of external services. For example, an ISV may provide reporting services, invoicing, and other business logic as web services and utilise them within an Office Live application. In this way they can protect their IPR and at the same time implement some kind of licensing model in the services (pay as you go or monthly for example).
In this scenario, scripts within the Office Live site (but running on the client browser) collate information using the WSS web services and pass it to the ISV services. The ISV services process the data and return to the calling script which can then present the results to the user. In a recent project, I used just such a scheme to collate invoice data from a list in Office Live. This data was passed to a web service which generated a PDF invoice. This PDF was then passed back to the client which used further WSS calls to store it the PDF in a document library. This protected the IPR of the invoice generator and provided an external service that could be used to generate license revenue. The user remains blissfully unaware that they are using two distinct services.
Smart clients
Another method of extending the functions of Office Live is to provide a Windows client. This can utilise Windows Live ID services to connect to an Office Live site and query data using web services.
It is easy to see how very powerful applications can be built in this way- although there are weaknesses too. For example, the client must be shipped, installed, and updated as the software changes. However, a number of distinct advantages quickly become apparent.
- The application may use more advanced UI components to build a UI specifically designed for the user base.
- Off-line data stores may be used to allow disconnected operation of applications whilst maintaining the advantage of centralised data storage when connected.
Of course, a Windows client can still make use of external services and so protection of IPR is still available as is the posibility of a subscription model similar to that of Office Live itself.
There are lots of options then. It’s just a matter of picking the model (or combination of models) that best suits your needs.