Well I've just spent two superb weeks down in Cornwall at a place called St Mawes and it appears that those Cornish folks have cracked the question as to when you should be paying for using a service.
As you drive into Cornwall on the A30 there are no speed cameras but as you come out of Cornwall there are a bunch. Which is as it should be in a decent service architecture. Charging people to initiate a transaction is an extremely dangerous position to get into as it leads to charging yourself when you just "ping" the service to check it is up and it leads to customers being charged for network failure. Charging on exit ensures that the consumer isn't paying without getting something for it (the real-world effect of the service).
However while the Cornish model works because the A30 is really the only way in or out it shouldn't be applied as a blanket statement for all services. The reason is that consumers can get cunning about this sort of element.
At University they took away our free printer and made us pay, per sheet, for printouts. The cost was only payable however if the whole print out was successful, you didn't have to pay if there were any errors. Given then we were using lp/lpr and had a course that taught us how to code in postscript it was a matter of moments before a quick alias occured that appended a postscript error to any document sent to the printer. Thus meaning that we got all of the real-world effects that we required, but the service provider received none of the money. They could have switched to payment on all sheets that didn't have errors, but we could have faked that too :)
So there is no one solution in complex process environments as consumers may only be after part of the effect. This does mean that when planning charging models for SOA you have to think not about just "pay for call" but about the most appropriate charging model for a given method of interaction, and of course have an automated way of measuring that.
When defining a service think about whether something is interruptable, whether additional information can be appended after the effect to invalidate payment, but not the request and about the point at which the consumer receives the value the service delivers.
I'd suggest three broad groups
1) Have a returns policy - charge on entry. In this case you charge for invocation but have to have a returns policy for people to object to charges. This should only be used in cases where you can really minimise the amount of returns
2) Charge on exit - This requires a clear process in which value is obtained purely at the end of the transaction and requires you to prevent people exiting or corrupting post this value
3) Charge at key points, identify key points in the interaction that deliver incremental pieces of value to the consumer and charge for these
In reality these charging models are part of the business activity monitoring exercise for the service and the two elements should be very much in step.
If dealing externally remember people will play silly buggers to avoid paying, and they will internally unless you put in place some sort of remediation plan, like preventing them from accessing the service or changing their charging model (initiation with no returns).
Charging for service isn't something that has had a lot of thought so far with people tending to assume that payment on initiation is fine. Cornwall has clearly planned its speed camera strategy on SOA principles, so should you.
Technorati Tags: SOA, Service Architecture
No comments:
Post a Comment