During my presentation in the SaaS Summit in Dublin last week, I mentioned two examples of a "Service Delivery Platform" and their characteristics (especially around application compliance and its consequences and benefits).
One was LitwareHR & Northwind Hosting, the imaginary scenario I've been documenting for some time in this blog. The other one was a more concrete and real example based on Microsoft Silverlight Streaming.
Silverlight Streaming (SLS) is a Microsoft service offering that allows you to host and deliver rich media content that is accessed via the the Silverlight plug-in.
By using this service, you have access to a world class hosting platform (think global presence, optimized networking, availability, performance management, etc) that could be too expensive for many to run on their own.
Microsoft built this specialized platform to be been optimized for Silverlight media streaming.
Let's start by mapping some basic concepts in the Litware/Northwind Hosting case study to Silverlight Streaming:
|Litware / Northwind Hosting case study||Silverlight Streaming|
|Who is the Hoster? (who runs the
|Who builds the "app"?||Litware||Anyone with a Silverlight Streaming account|
|What is the app?||LitwareHR||Any SLS compatible content|
|What kind of apps?||.NET based Line Of Business Applications built with WCF, SQL and ASP.NET||Silverlight compatible content|
SLS defines and publishes a number of requirements and restrictions on the application it can host: you are not free to structure the content in any way you like, or even upload any type of files. This is equivalent to Northwind Hosting's application model and associated restrictions. Notice how conventions are required for the service to work (red is mine):
- Instead of hosting Silverlight.js on your own web site and using it, you should use http://agappdom.net/g/silverlight.js.
- In your CreateSilverlight.js or equivalent file, call Sys.Silverlight.createHostedObjectEx() instead of Sys.Silverlight.createObject() (or createObjectEx). Because the application specifies most of the startup parameters in its manifest.xml files, the only two meaningful parameters are "source" and "parentElement".
- For the "source" parameter, instead of naming a XAML file, you give the service name for the hosted application. These always have the form "streaming:/accountId/applicationName". where accountId is your account id and applicationName is the name you gave your application when you uploaded it."
Also, when packaging an "application", you have to follow certain predefines rules:
"The Application Package
To upload an application to the Silverlight Streaming service, the developer must create a single ZIP archive file containing all the pieces used by the application. It consists of one or more of the following file types:
- XAML files (.xaml)
- Silverlight assemblies (.dll)
- Images (.png, .jpg)
- Sounds (.wav, .mp3, etc.)
- XML and Text files (.xml, .txt) "
This is the equivalent of NWH "Hosting Pack" we discussed in this article when we talked about on-boarding. I'm sure if you try to upload anything different from these types of files, SLS will reject your package.
Finally, SLS has the notion of the "Application Manifest":
"The Application Manifest
In addition, a file must be present to describe the application to the hosting service. This file is always named "manifest.xml". Its general schema is shown below. Most of the elements are have the same syntax as the corresponding parameter to Sys.Silverlight.createObject().
<source>name of the initial XAML file</source>
<width>desired width, in browser units or percentage</width>
etc., see below
<js>js file to load first</js>
<js>js file to load second</js>
Which is the exact equivalent to Northwind Hosting Application Manifest we talked about in the same article and illustrated in here. We didn't define any implementation schema yet, but the concept is the same.
Full details on SLS requirements are available here.