Re: An opes usage question.
"John G. Waclawsky" <[email protected]>
| Newsgroups | gmane.ietf.opes |
|---|---|
| Organization | Cisco Systems |
| Message-ID | <[email protected]> |
My comments are in-line below: The Purple Streak, Hilarie Orman wrote: >I think I see your problem, but I don't think you've established a >need for communication between a specific billing server and a >specific adaptation server. If this sort of thing is the model: > But I believe a solution is needed that allows communication between a specific billing server and a specific adaptation server. I think or thought that was clear from the past e-mails. > > ContentServer ContentServer ContentServer > | | | > \ | / > \ | / > ---------------------------- > | Load Balancer | > ---------------------------- > | | | > | | | > | | | > BillingServer BillingServer BillingServer > | | | > \ | / > \ | / > ---------------------------- > | Load Balancer | > ---------------------------- > | | | > | | | > | | | > AdaptServer AdaptServer AdaptServer > | | | > \ | / > \ | / > ---------------------------- > | Load Balancer | > ---------------------------- > ..... > > > Yes, that is the model. >Then I'd think that a Billing Server, upon seeing a request and >response, might open a record saying "customer A got 10K bytes at 10 >am", but the Adaptation Server would send back a "request" encoding >the information "the customer really got 8K bytes at 10am". Your >question is "how would that information get back to the same billing >server?" and my first reaction is to say it just naturally would >if they keep their connection open. > I am not sure I understand why this would be true if there is a load balancer between stages of the services pipeline? Also connections can be very short lived. >If they decide to close the connection, then they need to agree on >some kind of identifier for the transaction. If the Billing Server >wants to include an OPES header with a unique ID, it can do that, and >it can write a billing record into its database saying "8K bytes for >unique ID xyzzy". The Adaptation Server then sends back the >information, using the same ID. This might not get delivered to the >same Billing Server, but it doesn't matter, it all goes into one >database and can be correlated for billing purposes. > You are proposing billing system changes. This introduces an additional dependency and complicates deployment and can lead to other problems. I would prefer not to have to modify the billing system. >In any case, the Adaptation Server needs to do extra communication, >above and beyond proxying. That extra work should be encodable in >the Rules Language, I believe. It is what I'd call a "local callout >service". > I believe this extra communication can be done out of band Is the reconciliation of billing information what you are referring to as a local call out service? > >I agree that in general the problem of identifying entities in a >pipeline that is interesting. Load-balancing, hot backup, failover, >etc. all introduce some interesting problems. If there are provably >correct solutions that can be encoded with OPES (without complicating >it), that would be very interesting. Perhaps out of charter for OPES, >but possibly worth a new WG (unless there already is one!). > As I mentioned before, I believe that any extra communication (for billing reconciliation) can be done out of band and therefore may not have to be part of opes, but I believe finding a flow participant is an opes issue that needs resolution. Thanks for the discussion Regards John > >Inimitably, on Sat, 06 Mar 2004 at 17:11:45 -0500 John G. Waclawsky >murmured: > > >> I think we are talking about the same thing which I have been calling a >> "flow participant discovery" problem (not a services discovery problem). >> The question is how, within the opes framework, do I establish this >> business relationship between two proxies in different stages of a >> services pipeline separated by a load balancer. Packets can travel >> through the billing server and later be changed by any adaptation proxy >> where (in the billing by bytes case) bytes could be reduced >> (compression) or increased (adding banners or advertisements or other >> correlated content). >> >> > >Hilarie > > > >