« 2007-02 | HomePage | 2007-05 »
Saturday, 24 March 2007
The SaaS project – Part six – Federation
Other articles on the SaaS project
The Software as a Service (SaaS) Project
The SaaS project - part 2 - challenges and provisioning
The SaaS project - Part 3 - Plans and plan management
The SaaS project - part 4 - Orders and Operations
The SaaS project - part 5 - Metering and billing
The SaaS project - part 6 - Federation
Co-writer on this article is Sergey Marchenko from Sitecore Ukraine.
6. FEDERATION
If the tenant has purchased several different software items, how can we ensure that the tenant only need to log on once for all applications?
A frequent challenge lies in a homogeneous security layer, allowing seamless integration between various software applications. Through time, attempts on solving this issue are frequent, and a number of semi-standards have grown, depending on the vendor. Microsoft technologies all supports Windows Authentication, and most of this directory services would support LDAP.
Even with the challenge of keeping transferring a user from application to application has been solved, another issue remains; how do we execute the actual authentication, - and how do we make sure that the software can exchange this information without compromising security (e.g. by passing sensitive information such as passwords).
An additional frequent topic in this discussion is that organizations would want to maintain the user structure within their infrastructure. In other words, the user structure and their roles should reside in a foreign (operation system independent) environment.
Finally, the security authentication should be separate from the authorization; for example, users from a Microsoft Windows Environment should not enforce a Windows security model upon the ISV’s application.
In order to successfully achieve this, a trust relationship must be configured. Various attempts have been sought through time, usually through trusted certificates.
A new technology supporting the industry web service architecture has emerged recently. This OASIS standard is based on the WS-* specifications and are supported by virtually every important major player on the market; IBM, SUN, VeriSign, Microsoft etc. all supports this standard.
You can review the standard here: http://www.oasis-open.org/specs/index.php#wssv1.0
Microsoft has wrapped this standard in a service layer, Active Directory Federation Services (ADFS).
During the SaaS POC, we attempted, and succeeded building support for this single-sign-on (SSO) technology.
What exactly is ADFS?
Active Directory Federation Services (ADSF) is a component in Microsoft Windows Server 2003 that provides the Web single-sign-on (SSO) technologies to authenticate a user to multiple Web applications over the life of a single online session. ADFS accomplishes this by securely sharing digital identity and entitlement rights, or "Claims" across security and enterprise boundaries
Benefits of using ADFS
- Your do not need to care about storing the user credentials in your own storage. All uses are stored on a remote federation server (which in Microsoft’s case gets its users from the active directory). Thus you are able to have the same users for different web applications and manage them in common way. All that you need in your application is to check that user is logged in and redirect to the login form if it doesn’t.
- Interoperability of your application with other security products that support the WS-* Web Services Architecture
- Extensible architecture that supports the Security Assertion Markup Language (SAML) token type and Kerberos authentication (in the Federated Web SSO with Forest Trust scenario).
Click here, to learn more about ADFS
How did Sitecore integrate to ADFS?
Naturally you would need to configure your federation server which is the trustee server, and this was actually the greatest challenge in the federation integration. The server must be configured in your environment, and trust relationships must be set up with one or more remote federation servers and to the application servers.
Usually this task must be completed once by the hosting provider, then new applications can be plugged directly into it.
And from the ISV’s point of view?
From the ISV’s side, federation support works like a charm, and is easily implemented. This is what we did:
IIS configuration:
- Configure SSL port for your Web Site
- Press “Edit” button in the “Authentication and access control” section on the “Directory security” tab and clear the “Integrated Windows Authentication” check box in the “Authentication Methods” dialog box.
- Assign the Server Authentication Certificate to the Web Site
Web configuration file:
- Modify the <configSections> section by adding new ”websso” section the “system.web” section group
- Add two assemblies (System.Web.Security.SingleSidnOn and System.Web.Security.SingleSidnOn.ClaimTransforms) to the <assemblies> section
- Change the authentication mode to “None”
- Add “Identity Federation Services Application Authentication Module” to the <httpModules> section
- Define the <websso> section (note: all definitions in this section are case sensitive)
Finally, you will also need to do the actual login to your software
This required very little coding:
All that you need to do is to use the “SingleSignOnIdentity” API to verify user credentials.
In our example we configured the ADFS only for the Sitecore backend, and not to the visitors of the web site, which would have been just as easy.
By modifying the <websso> section of the Web.config file, you could configure the default page after authentication to be “/sitecore/shell/default.aspx” (the Sitecore default logon page).
We modified the default logon page to pass user credentials to the internal Sitecore domain, or if the user was not authenticated in ADFS, display a traditional forms logon page.
Here is the code we added to the “/sitecore/shell/default.aspx” page (added to the Page_Load method):
protected void Page_Load(object sender, EventArgs e) {
SingleSignOnIdentity ssoId =
User.Identity as SingleSignOnIdentity;
if(ssoId == null){
Sitecore.Diagnostics.Log.Warn(
"Single Sign On isn't installed...", this);
}
else{
if(ssoId.IsAuthenticated == false){
Sitecore.Diagnostics.Log.Warn(
"User is not uathenticated", this);
Response.Redirect(ssoId.SignInUrl);
}
else{
Sitecore.SecurityModel.UserItem user =
Sitecore.Context.Domain.BuildVirtualUser(
Sitecore.Data.ID.NewID, ssoId.Name);
Sitecore.SecurityModel.RoleItem[] roles =
Sitecore.Context.Domain.GetRoles();
if(roles != null){
System.Collections.Generic.List<Sitecore.Data.ID>IDs =
new List<Sitecore.Data.ID>();
// iterate throughout Sitecore roles and assign it to
// the virtual user if this user is member of this role
// in the Active Directory
foreach(Sitecore.SecurityModel.RoleItem role in roles){
if(((System.Security.Principal.IPrincipal)User).IsInRole(
role.Name)){
IDs.Add(role.ID);
}
}
user.BeginEdit();
user.Roles.RoleIDs = IDs.ToArray();
user.EndEdit();
}
Sitecore.Context.Domain.Login(user);
}
}
}
So, now you don’t have to create new users in the Sitecore backend, you just need to add new user into your Active Directory.
You can manage the user roles which will be assigned in the Sitecore from the Active Directory as well. For these purposes you should create (if it doesn’t exist) the role in the AD with the same name as you have in the Sitecore and assign this role to the User.
As you can see you should write only a couple lines of code to use ADFS in the Sitecore CMS. The much harder part which takes a lot of time is configuration ADFS on your Servers.
Keywords: Active Directory Federation Services (ADFS)
Thanks to: Co-writer, Sergey Marchenko from our Sitecore Ukraine office.
14:05 Permalink | Comments (2) | Email this
Friday, 23 March 2007
The SaaS project – Part five – Metering and billing
Other articles on the SaaS project
The Software as a Service (SaaS) Project
The SaaS project - part 2 - challenges and provisioning
The SaaS project - Part 3 - Plans and plan management
The SaaS project - part 4 - Orders and Operations
The SaaS project - part 5 - Metering and billing
The SaaS project - part 6 - Federation
5. METERING AND BILLING
The tenant has purchase a “per usage” service. How do we bill her?
Let’s assume that the hosting providers offering of the ISV software is based on a per software item usage, e.g. per Sitecore document, or in a CRM system it could be per account. How can we build a generic interface that allows the hoster to get this information from the ISV software on a per-tenant-basis?
The application manifest offers metering points, the plan defines which to use
The different measuring offerings for a given piece of software are usually decided by the software itself. Sitecore, for example can configure and measure limits on a per item level, per concurrent content author, the total of content authors, per database size, etc.
The application manifest, which holds information about requirements for a piece of software as well as the actual installation script, also contains a metering section with zero or more metering (web) services for the software item.
<am:monitors>
:
<am:metering>
<am:usagemetering type="applicationitems"
id="SC_ItemCount">
/sitecore/itemcount.asmx?tenant=$(tenantname)
</am:usagemetering>
</am:metering>
</am:monitors>
When the hosting provider defines the plan, they also configure the pricing models. Each pricing model for the software will define the rules of the billing routine, such as “every month, check on the (max) content items, then bill the tenant 5 cents per item”. This rule will point to the metering point, ruled by the manifest.
The plan naturally can reside in any database, but in XML it could look something like:
<Plan>
<Item id=”SCBox”>
<MeteringPointIntervals>
<Point id=”SC_ItemCount” Refer=”x” meteringInterval=”24h” />
<Point id=”SC_DBUsage” Refer=”y” meteringInterval=”1h” />
</MeteringPointIntervals>
<LicensePacks>
<LicensePack name=”LowFlatHighItem">
<Limitation type=”flatfee”>2$</Limitation>
<Limitation type=”Items”>0,5$ * $SC_ItemCount</Limitation>
</LicensePack>
<LicensePack name=”HighFlatLowItem”>
<Limitation type=”flatfee”>20$</Limitation>
<Limitation type=”Items”>0,05$ * $SC_ItemCount</Limitation>
</LicensePack>
:
<LicensePacks>
<Item>
<Item id=”SCBoxMailing”>
:
</Item>
:
</Plan>
Measuring intervals
Naturally, the hoster could choose to use the metering point web service once a month, but this would allow the tenant to decrease the number of content item every month right before the hoster read the value.
To solve this issue, the hosting provider should supply a measuring (windows) service that, with regular intervals (also defined in the plan) can use the measuring web service and store this value in a measuring point database.
When the hoster has defined the plan, and publishes it to the front end ordering system, the plan management system also generates a plan interval manifest.
The windows services operate from this plan interval manifest and as such the service simply receives a number of operations, executes them and stores the return value into a database. E.g.:
<?xml version="1.0" encoding="utf-8" ?>
<PlanManifest>
<Plan name="Premium">
<SoftwareItem id="Sitecore" intervalMinutes="10">
<MeteringPoint id="SC_ItemCount" tenantId="customer1"
action="http://sitecore/itemcount.asmx?tenant=customer1"/>
<MeteringPoint id="SC_ItemCount" tenantId="customer2"
action="http://sitecore/itemcount.asmx?tenant=customer2"/>
</SoftwareItem>
<SoftwareItem id="SitecoreMailingList" intervalMinutes="15">
<MeteringPoint id="SCML_Mailboxcount" tenantId="customer1"
action="http://sitecore/mailboxes.asmx?tenant=customer1"/>
</SoftwareItem>
</Plan>
</PlanManifest>
Once a month, or when the plan defines to bill the customer, they will query the measuring point database through method with an interface looking something like:
float GetMeeteringPoint (
MeteringPoint, TenantID, StartDate,
EndDate, AggreegationType)
Where the last parameter, aggregation type is allowing, sum, count, average, max and min values.
When the plan management system receives this value, it can calculate the max number of items and add this with the agreed upon price.
CRM or ERP integration
This process can be initiated from the CRM or ERP system (which too can be connected to the ordering flow), or the billing engine could be a separate piece of simple software which passes the data to the CRM.
The hosting provider must be aware of the potential need to deliver billing information to any 3 part billing provider; this could be a service provider who’s an expert in collecting fees, or it could be the ISV who must handle invoices.
13:41 Posted in SaaS | Permalink | Comments (0) | Email this
Tuesday, 20 March 2007
The SaaS project – Part four – Orders and Operations
Other articles about the SaaS project:
The Software as a Service (SaaS) Project
The SaaS project - part 2 - challenges and provisioning
The SaaS project - Part 3 - Plans and plan management
The SaaS project - part 4 - Orders and Operations
The SaaS project - part 5 - Metering and billing
The SaaS project - part 6 - Federation
3. ORDERS AND ORDERS MANAGEMENT
A customer (tenant) purchases a product (the application).
The previous post described how to address the plan building. A plan is referring to one or more software items in the application manifest. When the hosting provider publishes the plan, tenants can start purchase the service.
The orders management is closely related to the ISV and hosting provider’s agreement: In some cases, the ISV would want to sell the software, in some cases its being done through the hosting provider. For example, Sitecore would want to sell the basis Sitecore software themselves as it’s from a price perspective in the high end, whereas Sitecore box, a tool based on Sitecore, might be an option on the hosting provider’s platform as costs for a web site is very low.
Whoever sells the software should provide an interface for orders fulfillment. This interface should obtain overall information from the plan, but upon purchase it should intercommunicate with the other part; Sitecore to hosting provider and vice versa, with information about the current order.
Furthermore, the system should communicate to the Platform service with a notification to initiate provision of a new tenant for the selected software item. The provisioning system would copy files, move data and execute web services according to the instructions in the application manifest for “tenant installation” for the software item.
In the Sitecore box case, the platform service would look at the application manifest, and execute a single web service (requiring a few parameters, e.g. domain name and tenant name); where after Sitecore box would create a new web site in the platform.
4. OPERATIONS
The hoster uploads the service level agreement by keeping an eye on the tenant’s application.
This is also a very important key feature, when hosting applications: The honoring of service levels. For example, most hosters provide an up-time and break-down notification whenever somebody hosts their application at the hoster.
It’s obvious that most hosters must somehow monitor the web site, or in the SaaS environment several different web sites. This can be done through traditional monitoring tools, such as Microsoft Operations Manager (MOM): The monitoring software checks at regular interval one or more pages to see if the page has the expected result (otherwise the page or site may be corrupt). Also the monitoring software, e.g. MOM can get some information from the Windows Performance Counters.
This is very essential for your software application, if you want it to be ready for SaaS; make sure that your application, upon installation, configures several custom performance counters such as “data count”, “number of users”, “memory consumption” etc.
Naturally Sitecore does this, but in addition Sitecore also supplies even more services for checking the health of the application, or even parts of the application. Sitecore has a web service which can check for multiple elements of the application; for example the speed of the connection to the SQL server, if a sub site is healthy, if security has been truly locked down and much more. The idea is that the monitoring software can call this web service and immediately get several issues checked up upon through a simple XML response (where each topic can be rated, info, warning, error).
The application manifest, holds information on relevant performance counters for each software item. For example, Sitecore has more than 80 relevant performance counters that are being offered to a hosting platform. Other applications, such as Sitecore Box which can hold an unlimited “tenants”, or sub sites, generate a single performance counter which returns the number of items per tenant. An item in the Sitecore terminology is equivalent to a document.
During the SaaS project, one of my colleagues, Sergey Marchenko, attempted to generate a MOM installation package directly from the application manifest. This IS feasible, but as the SDK for MOM is extremely new (in fact under documentation and development), we did not succeed due to time pressure. However, it is worth pursuing: Imagine a scenario where the hoster’s operations system automatically is being updated from the ISV’s abstract description document, the application manifest without human interaction!
Keywords: Microsoft Operations Manager (MOM).
06:10 Posted in SaaS | Permalink | Comments (0) | Email this
Monday, 19 March 2007
The SaaS project – Part three - Plans and Plan management
Other articles about the SaaS project:
- The Software as a Service (SaaS) Project
- The SaaS project - part 2 - challenges and provisioning
- The SaaS project - Part 3 - Plans and plan management
- The SaaS project - part 4 - Orders and Operations
- The SaaS project - part 5 - Metering and billing
- The SaaS project - part 6 - Federation
In my last post, I explained about the platform management system and the provisioning engine. This post will describe the plans and plan management service.
2. PLANS AND PLAN MANAGEMENT
Hoster defines what to sell, and publishes it to the orders system.
When the hoster has imported the application manifest and the platform diagram into the platform management system, they will need to define a number of plans. A plan is a single or collection of software items referring to the application manifest. For example, the hoster may not want to offer all the software items the ISV supports, but instead select some of these and combine it with the hosters own services (up-time services, back-up plans etc.).
The hoster can make any plan as long as they honor the rules of the application manifest. Let’s assume the following dependency hierarchy in the Sitecore manifest:
- Sitecore CMS
-
- Sitecore Box
-
- Sitecore box forum
- Sitecore mailing list
- Sitecore Forum
If the hoster decides to sell Sitecore box forum, the manifest would also force the hoster to include the Sitecore Box and Sitecore CMS in then plan as box is based on Sitecore as well as the forum only runs in a Box environment.
The hoster could create a number of different plans:
- Sitecore box (would automatically require installation of Sitecore)
- Sitecore box forum (would require the tenant had first purchased the Sitecore box)
The hoster must also define how to bill the user; for example, a plan could be based on a per editor usage, or per item usage (e.g. 1 cent per content item per month). This means that the plan must refer to a valid software item (e.g. Sitecore) as well as the metering service that allows this plan (e.g. a Sitecore web service that can return the number of items for a web site usage). This adds another section to the manifest; the metering counters.
When the plan or several plans has been defined by the hosting provider, it’s published to the front end shop where regular tenants can select the service.
As an ISV it’s optional if you want to supply one or more plans for the hoster. This would be beneficial for the hoster as a plan would refer valid metering points.
07:40 Posted in SaaS | Permalink | Comments (0) | Email this
Friday, 16 March 2007
The SaaS project – part two. Challenges and Provisioning system
As I wrote in my previous article, “The Software as a Service (SaaS) Project, Sitecore has been involved in a SaaS pilot project, keyword “the SaaS incubation project”.
The role of the software provider, the company that provides the software as a service, was in this project split between the company that hosts the software, Cohasio, and the ISV, Sitecore. Other operations, such as large corporations might both design the software and host the solution themselves, are being the full software provider.
Microsoft, in the other hand was trying to solve the frequent challenge of bringing a piece of software towards the hosted platform: Easier installation, better operations (daily surveillance and maintenance), upgrade paths, billing (e.g. per month usage etc.).
THE PRACTICAL CHALLANGES
As an ISV, you must know what the hoster need to run their operation in order to create a successful application built for hosting at a “remote” location. For example, a piece of software must supply various measuring points allowing the hosting provider to check the health (and current temperature) of the application.
In the other hand, the hosting provider too must support other interfaces; reporting to the ISV, notifications when the system fails, gets slow or unstable, etc.
Some tasks are shared; ISV must supply their software along with a long range of instructions (security configuration, database creation, database connection, file copying etc.), while the hosting provider must on every single installation spend time executing these instructions.
The Microsoft SaaS framework will define a number of interfaces each player must implement, but otherwise know very little about the other side operation. This will allow any ISV, - like Sitecore, to pass their software to any hoster, like Cohasio, along with a single transparent instruction set (manifest). The hosting provider on their side will need nothing more than their physical server setup (e.g. a Visio drawing), then apply the manifest to it; viola: Installation, monitoring, reporting… all running. Or so is the vision.
The elements of the SaaS framework
During this process we identified and solved the following six challenges. This “shorter” description will not go in-depth, but will be explained in later articles:
- Provisioning: Initial software installation and installation each time a tenant purchases a service or a software item.
- Plans and Plan management: Hoster defines what to sell, and publishes it to the orders system.
- Orders: A customer (tenant) purchases a product (the application).
- Operations: The hoster uploads the service level agreement by keeping an eye on the tenant’s application.
- Metering and billing: The tenant has purchase a “per usage” service. How do we bill her?
- Federation: If the tenant has purchased several different software items, how can we ensure that the tenant only need to log on once for all applications?
The task of installing a piece of Sitecore is usually handled through our executable Microsoft Installer which installs files, attaches SQL (or other database), and creates a new web site on your IIS installation. During the installation process, the administrator are prompted a number of times, e.g. for file location, SQL connection string, new domain name. Also, in order to install through the MSI, you must log on to the local machine as a user profile with sufficient install rights (e.g. local administrator).
This is usually not an option for many hosting companies; manual operations and granting full rights to an “unknown” application for installation would usually pose a problem. Also, it’s not a very effective approach to distribution on a entire hosting platform as well as it does not take care of creating new domains etc.
Provisioning systems
Most existing hosters have solved this issue by implementing a provisioning system; this system can be configured to copy files from one location to another, configure security settings, create domain names etc. Microsoft has an entire server product, Microsoft Provisioning System (MPS) which is a series of dedicated servers. The current challenge of this approach is that the hosting provider must define these operations for each individual piece of software.
Traditionally this is solved by the ISV supplies a document with instructions in human form. The hoster processes the instructions manually for the software in their provisioning system.
For the research project, we identified, and generated a method to pass this information from the ISV to the hosting provider in a unified format, called a manifest. The manifest contains installation instructions on one or more “software items” and the relationship between these. For example Sitecore basis installation and Sitecore Box which is a solution built on top of the Sitecore CM Framework.
The manifest also contains much more instructions that described above. Each software item defines a requirement specification (e.g. “test access to a SQL server”), an initial installation section (when the hoster want to offer the software for tenants, what should be installed before first tenant signs on) and a tenant installation section (what should we do, when a tenant purchases the software; in Sitecore box we execute a web service and create a new domain).
MVP vs. LPS vs. other provision systems
During the project we discarded the MPS as an option, as this would require a real live setup and much more resources than our team could afford during the three week. The system configuration was simply too much work for a POC, but would be an excellent choice in a live hosting environment.
Also, if the idea of a provision idea should catch on for hosters and individual ISVs who would play the role of a hoster as well, we decided to implement our own provisioning system; the Lightweight Provisioning System (LPS), which can be installed on a single Windows 2003 or Vista server. Simply install Windows PowerShell, and then attach the 8 custom PowerShell commands.
For all fairness I need to explain that other provisioning systems can handle the same task as the LPS and MPS, not necessary based on the Windows platform. Also, most existing hosters have already adapted these systems.
The ISV and the manifest
If the ISV has designed the software ready for SaaS (see other requirements), all the ISV need to do is to define the manifest once, then pass it to any hosting provider (which is “ready for SaaS”) along with a source CD.
The hoster and the manifest
The hoster must ensure their provisioning system “understands” the manifest; this might require initial configuration or manifest transformation to the selected platform. I’m sure Microsoft will supply a method allowing the MPS to understand the manifest. Naturally the LPS already understand and can execute the manifest.
Platform diagram and platform management service
The hoster must also design their physical server architecture in an XML format (in our case we did it in Microsoft Visio 2007); draw the servers (e.g. 4 web servers, one SQL cluster, with IP real numbers) then store this Platform diagram as in the platform management software.
The platform management software has several purposes, but in reality it’s a thin piece of software whose sole purpose is to deliver and store different data structures and pass these documents to other systems. For example, the hosting provider uses the platform service to store a new manifest or platform diagram, or execute the provisioning of the manifest with either initial installation or tenant installation.
When the platform management system is asked to initiate provisioning, the platform services finds the appropriate manifest and the platform diagram in the database, then merge these two documents into a single XML document (set of instructions for each server; some for the SQL server, some for the IIS-servers). This document, the provisioning manifest is then passed to the provisioning system.
Provisioning
The provisioning system (in our case, our LPS, written in PowerShell), receives the provisioning manifest and simply executes the instructions (in Sitecore’s case, copies the files, create domain names, add IIS site, assign security to folders, attach databases to SQL server, configure ASP.NET web.config etc.).
Whats next?
You can read more about this scenario at Michel Baladi's Blog, "SHP #5: The first two scenarios – the a basic meta-data “goo” (define, map & persist)".
Jimmy Rasmussen has written an excellent Blog post on LPS and the techniques. Read this to build your own provisioning system: http://blogs.msdn.com/jimmytr/archive/2007/03/17/saas-in-...
Next articles in this series will describe the different elements identified as part of the SaaS challenge (Plans and Plan management, Orders fulfillment, Operations, Federation etc.).
Keywords
Lightweight Provisioning system (LPS), Microsoft Provisioning System (MPS), Windows PowerShell.
12:35 Posted in SaaS | Permalink | Comments (0) | Email this
Tuesday, 13 March 2007
The Software as a Service (SaaS) Project - Part one
The last three weeks, I and a very skilled team of developers and architects have had the pleasure of visiting the Microsoft Technology Center, just north of Copenhagen.
The purpose of this project was to build a proof of concept on Software as a Service, and at the same time cover and define some of the standards and elements that would be required in Software as a Service setup.
The participants of this project was Microsoft Technology Center (EMEA), Sitecore and a hosting provider, who each gave input and developer resources to cover five major scenarios.
The next couple of weeks, I will cover these scenarios through several Blog posts, as well as relay the experiences from an ISV perspective in a SaaS environment.
What is SaaS?
Software as a Service (SaaS) means delivering software over the Internet. Traditional companies have been running their own infrastructure, purchasing, installing and maintaining their software. In the SaaS scenario, a company, the software provider, is responsible the application (installation, maintenance, scalability, availability etc.) while another company, the tenant, pays for these services.
The tenant
The benefits from the tenant are obvious, regardless of the size of the company: The risk of software acquisition is greatly reduced and the company will not need to invest in application operations knowledge. It also means that the company for a time being can test the application in parts of their organization, and if successful, instantaneously roll it out to the rest of the organization.
However, there may also be drawbacks; costs of renting the software, especially for large scale companies may exceed the proprietary approach of traditional software acquisition. The organization must also trust the software provider to handle potential compromising data. Also, the ability for integration between the company’s existing software and the SaaS software may be decreased greatly.
Gianpaolo Carraro and Fred Chong from Microsoft have written an excellent article on the adaption of SaaS from an enterprise perspective.
http://msdn2.microsoft.com/en-us/architecture/aa905332.aspx
The software provider
The benefits from the software provider are obvious; the application target market share is often increased and it’s possible to centralize upgrade and maintenance, hence reduce support for older or outdated versions of your software.
Risks also applies to the software provider; solutions built for SaaS require special architecture, and for existing ISV’s these requirements may end up in rewriting parts or the entire application.
The hosting provider and the ISV
While the most popular examples of SaaS, such as salesforce.com (www.salesforce.com) hosts the solutions themselves, this may not always be the case. Smaller software companies, or software companies that solemnly focuses on the product itself, such as Sitecore, will not be able or willing to configure a hosting center. In this scenario, they will be depending on a 3 part hosting provider. In this case the software provider is divided into two entities; the ISV and the hoster.
The SaaS incubation project
The SaaS incubation project is all about these 3 parties, and the requirements for these entities: The tenant renting the application. The ISV delivering the software, and the hoster, naturally, hosting the software.
In this article series about SaaS, I will thrive to describe the requirements for SaaS and the various aspects and scenarios that must be covered. With a twist: It will be from a ISVs perspective; what the SOFTWARE must support.
Do not expect to learn everything about SaaS on this Blog. It’s my personal experience as lead solution architect that are relayed; Sitecore, Microsoft or the hoster is quite innocent.
As a final (personal) note
As a personal note, I must grant my highest regards to the developers that have been involved during the entire project; Sitecore and Sitecore Express very dedicated and professional developers, Søren and Sergey, Microsoft Technology Centers awesome team; Michel, Jimmy, Mario, Kevin and the 3 hardworking developers from the hoster (whom I cannot not mention at this stage). Also, my regards to the other involved advisors that have been willing to spend time on our project.
20:10 Posted in SaaS | Permalink | Comments (1) | Email this
Wednesday, 07 March 2007
Excellent post
A few days ago, MVP (Most Valuable Professional) Alex de Groot, did a small notice on a presentation he did in his company Lectric. He's linking to a slideshow, which I can only recommend. Nice stuff:
http://sitecore.alexiasoft.nl/2007/03/02/developers-knowl...
09:05 Posted in Sitecore | Permalink | Comments (0) | Email this
Tuesday, 06 March 2007
Sitecore and stat analyzers
Here are two often asked questions:
Question 1: How well does Sitecore work with site analyzer tools, such as WebTrends, Google Analytics or Instadia?
All of these systems basically are very generic statistics tools; they offer stats on most requested pages, walkthrough paths, browser types, operation types, pipe lines and success rates for your site. This kind of information is often unrelated to Sitecore; it can be extracted from the IIS log or from a section cookie (e.g. being passed to the server through script).
Every time the web site visitor requests a page, her behavior are being logged; what page is being requested and the previous page, user profile (browser type, resolution) etc. As Sitecore use friendly URL’s by default, you do not need to handle specific URL parsing to drop a logical name in the log, simply log /products/fruits/apple.aspx, and you will know that someone requested the apple documents which resides in the fruits category and which is a product.
Installation is very easy with all of these tools, and is entirely unrelated to your Sitecore installation, though you in some cases will need to add some JavaScript to your web page (see installation section).
Beside this, some stat systems allow you to set up individual campaigns where special URLs are logged. Sometime these campaigns would also require modification of the web site solution, such as adding a campaign ID to URLs related to the campaign. This has nothing to do with your Sitecore installation but is related to the solution itself. However, Sitecore do allow you to, when designing your solution to add whatever you wish to your campaign.
In other word, Sitecore is very suitable for all major analytics tools, hosted or log parsing.
What about installation?
WebTrends, Instadia and Google Analytics supplies two methods of retrieving data from the web site:
- Script based instructions (include javascript on your site which on every request sends session/request details to collection server).
- Log parsing (reads data from IIS Log, not Google Analytics, which is a hosted service only).
Both methods offer benefits and disadvantages:
Using JavaScript
Using the JavaScript approach, you will need to place one or more lines of JavaScript on your web page. The purpose of this script is to pass details on the current user request and user object to the remote (hosted) analysis server. Putting JavaScript on your page potentially raises two problems:
- User browser may not support JavaScript whereas stats on this user profile group are lost.
- Putting JavaScript on your page may compromise the accessibility or web standard (such as XHTML) you have chosen.
To be counted on the benefit side is the ability to get your statistics hosted hence simplifying your server architecture and lessen the administration.
Using log parsing
To use a log parser you must usually install some software on your local server which at specific intervals parses the IIS log.
Benefits is that your web page will remain unaffected; as all session state and user state is written to the IIS log, - you are not bound to send this data through JavaScript.
A disadvantage is that you are bound to install the server locally which usually increases maintenance and initial installation.
Do we not need to do anything at all?
You can always choose to enhance your local installation; for example I would love to see some of the readers out there upload a “Google Analytics” extension that would eliminate the Google JavaScript: This can naturally be achieved by adding a pipe line entry to the HTTPRequest pipeline which passes a POST request to the Google server with whatever information they need.
Another idea of extending the integration between traditional major hosting solutions would be extending the Sitecore Content Manager interface to reflect how many times an item in the data structure has been read: User logs on to Sitecore, and browses the data structure; a context menu would display stats on the item.
But really, you do not need to do anything specific if you can live with either a hosted solution (or JavaScript on your server), or if you are to install locally.
Question2: How do traditional stat tools differ from Sitecore StatCenter?
Well, Sitecore StatCenter is unrelated to traditional analytics tools: The traditional tools can pick up generic user data behavior and overall stats such as browser types, screen resolutions, referring site, page statistics etc. This is not something Sitecore Statcenter does very well. If you need this kind of information, WebTrends, Google Analytics or Instadia is much better (and looks much better too).
But StatCenter excels in another field: Statcenter hooks deeply into Sitecore and exploits the knowledge of the user and content. This allows you to see exactly what any user have been doing on the web page, e.g. how many time the user has returned, what pages the user visits and how long the user have spent on the page. Also, it’s possible to see if other users from same IP number have been visiting your web page, and what they did.
You can tag specific Sitecore pages and through the API award pages points. When a certain amount of points have been reached, you can raise an internal event, and e.g. modify your web page according to the user behavior (personalize the page).
So, what would I need?
Some organizations are very interested in the general stats. If you find yourself in this category, you should use one of the excellent 3 part web site analyzers.
Some organizations want to follow and act on the individual user behavior, and do not focus at all on general stats. They should use StatCenter.
Finally some organizations may find interest in both general stats as well as the ability to trace individual user behavior and page behavior. They should consider using both.
17:25 Posted in Sitecore | Permalink | Comments (1) | Email this