Re: An opes usage question.

Thanks for your input Geetha. I have found that billing can be a 
difficult problem because people expect solutions to fit into their 
existing billing model/system, no matter how it might work (it might be 
good for some things and a problem for others). So a solution that 
accommodates a number of  billing approaches would be the best because 
it is flexible and will be able to handle in-line billing, pre-paid, 
pay-per-use...etc.

Also, I'd like to build an open infrastructure to solve my problem. The 
feedback that I have gotten from past opes e-mails leads me to believe 
that using the opes framework would be the best way accomplish this 
important  goal. But is seems the opes framework needs a solution to the 
flow participant discovery problem. I emphasis the word discovery. My 
thoughts are that once you know the other flow participant you can 
always establish out of band communications to do whatever you need. 
This seems to be the most flexible approach. Your thoughts?
Regards  John

Geetha Manjunath wrote:

>On the contrary, I feel the accounting model should be slightly
>different in the OPES case:
>(a) We should charge the consumer for bytes output from the content
>server (we can debate on whether the #bytes is pre-adaptation or not)
>PLUS
>(b)A pay-per-use model for specific adaptation services used - this
>information can be provided  to the billing server by the adaptation
>server.
>
>Comments?
>
>regards
>Geetha
>
>
>"The Purple Streak, Hilarie Orman" wrote:
>  
>
>>If the billing is based on actual bytes delivered to the consumer,
>>there must be a business relationship between the billing stage
>>servers and adaptation servers.  The relationship will usually allow
>>the adaptation servers to cache the content and report to the billing
>>servers about the number of bytes delivered.  However, the reporting
>>is a reverse flow in the client-server model, and that is why it seems
>>problematical.  By convention, the adaptation server might make a
>>request back to the provider with the number of bytes encoded in the
>>request, or it might, on occasion, upload a report.  The rules
>>governing this behavior would most naturally be encoded on the
>>adaptation server, not on the OPES callout server.  So, this seems to
>>me to be an issue for the rules language.
>>
>>An alternative model would have this byte reporting functionality
>>handled on the callout server, and it would directly contact
>>the provider's billing service with reports.
>>
>>Hilarie
>>    
>>
>
>  
>