Freigeben über

Hosting LitwareHR on a Service Delivery Platform - Part III - Billing, Metering

  • Artikel

Billing is obviously a very important concern, after all Litware has to get paid! As described in Part I, Litware is looking at two models for Billing:

  • • Subscription based: (For example: $X/tenant/month up to 5 seats/tenant + $Y/month for additional seats)

  • • Usage based: $Z/"Submitted Resume"

In our imaginary scenario, we'll assume that Litware billing requirements are easily met by NWH billing capabilities. NWH Billing system supports these two modus operandi and offers rich customization, reporting, tax considerations, etc. So, for the purposes of this exercise, NWH Billing is state of the art.

But the question is: how does NWH Billing know what and when to bill? or in other terms, how to "glue" LitwareHR to the billing system? And, more importantly from Litware perspective is how intrusive this is. Remember, Litware is willing to change the app, but only if benefits they get out-weight the liabilities.

Everybody favors a non intrusive mechanism, because it minimizes changes to the app. Not by chance, NWH knows that the least requirements and constraints the more ISV they will attract.   

NWH Application Model actually makes this fairly easy, by using an interception mechanism:

 

NWH-BILLING

Figure 1 - Northwind Hosting Operations Interception 

 

Because the application is expected, by design, to expose all it's functionality through WCF web services, it gives NWH the chance to intercept all traffic to it (between the Web Client or any client calling the app web services. WCF provides a very powerful foundation for this kind of architecture (see behaviors and message inspectors).  

What NWH does is very simple:

  1. When the application is on-boarded, it looks in the app manifest for any "Business Action" definition (remember, Business Actions are just "managed" Operations) and stores any information in the Business Action database.
  2. One of the pieces of information is a "Billable Event". A name that identifies the billing event that is triggered each time the associated Operation is invoked.   
  3. At runtime, the interceptor will forward the event to the Billing System for processing.

 

The sub-optimized interceptor in pseudo-code is illustrated in Figure 2. Message represents the incoming request, Operation is the Action being invoked, CurrentContext represents the contextual information associated with this particular invocation (It will normally contain the tenant identifier, credentials, and any other out-of-band data).  

 

NWH-BILLING-PSEUDOCODE

Figure 2: Pseudo-code for an interceptor

 

Notice that the first thing the interceptor checks, is if the Operation is enabled or not. "Enabling/Disabling" an Operation allows NWH to put a gatekeeper for execution. This might be necessary when a request arrives from an overdue tenant for example. The Billing system might flip the bit for those in debt automatically as hinted in Figure 1.

This mechanism perfectly serves Litware's requirement of "turning the application to read-only" for non-paying customers. But there might be other good scenarios for this feature: isolating malfunctioning operations, maintenance, etc. The Control Panel allows manipulation of the metadata for users or NWH Operators.

Notice there's no change required in Litware if it complies to the Application Model.  

Because nothing of value is free in this world, this approach has a cost. If the interceptor is poorly written it has the potential of causing a lot of trouble: degrading performance, bringing instability, etc. It is definitely a piece of code that needs some good developers assigned to it. A good implementation will use lot's of smart strategies like caching, short circuiting through appropriate configuration, asynchronous calls to decouple bill event processing from the main thread, etc.   

Also, appropriate for the billing example. When should the event be generated? At the beginning or at the end of the execution? If whatever the Operation does fails and throws an exception, should the event be generated anyway? Or consider this: if the Operation runs in a transactional context, should the event be associated with the transaction? Real world interception mechanisms have all these provisions.

Now, if you are wondering whether this approach is actually used or not in the real world or if it's just Eugenio's design after drinking grappa , just take a look at CRM Live services design as presented in last MIX (red highlight is mine):

 

NWH-BILLING-MIX-CRM-LIVE

Figure 3: CRM Live Architecture

 

(Full deck & video here: https://sessions.visitmix.com/default.asp?event=1011&session=2012&pid=DEV09&disc=&id=1518&year=2007&search=DEV09)

Technorati tags: SaaS, On Demand, Service Delivery Platform, On Demand Billing, Hosted Applications, CRM Live

Comments

  • Anonymous
    June 11, 2007
    Eugenio spent the last couple of weeks exploring the implications of hosting LitwareHR on a hypothetical

  • Anonymous
    June 12, 2007

  • well exposed thx Eugenio - but do you intend to re-invent CSF? which is here for billing events, along with other functions that are of interest for real-time services delivery platforms.
  • nothing about CAS!!! shared hosting with monetizable SLA means trust=medium. Do you assume that each customer is required to be isolated? in a separate server/virtual server/virtuozzo machine?
  • WCF is NOT trust=medium friend.
  • is entlib built for trust=medium?
  • good to see database not accessed by customer apps directly. but if it is a shared database, how to ensure that it is not locked down for maintenance by another ISV??
  • what about user directory? authentication, authorization? central repository with AD, or each app with it's own SQL access control?

  • Anonymous
    June 13, 2007
    Thanks Laurenbo - No, I don't want to reinvent anything :-). I just want to surface the requirements. Actually, we are working on a prototype integrating Litware and CSF provisioning. Very cool stuff, I hope I'll be able to show soon (TechReady for sure for you MSFTies). Your observations are right on. I'll try to cover in the next articles. Thanks for the feedback! eugeniop

  • Anonymous
    June 20, 2007
    Part III of this series of articles introduced a common design pattern (using an interceptor) to provide

  • Anonymous
    February 10, 2008
    For the last months our team has invested a lot of time exploring and researching the relationship between

  • Anonymous
    February 10, 2008
    For the last months our team has invested a lot of time exploring and researching the relationship between