Hi Karl, On Aug 28 2007, Karl Czajkowski wrote:
For example, how do I know that a service didn't crash between the transport-level message being accepted and the application processing it?
What difference would it make? :-) Is there some difference between crashing after the transport ACK or the application ACK?
A lot and yes. A transport ack doesn't tell me the application recieved or was able to understand the content, for instance.
You seem to be assuming that the application is somehow more trustworthy than the transport to buffer/persist a message until application restart can make progress. This is an implementation choice that is not captured at all in the WSDL, but in the endpoint software stacks and the SOAP bindings that are in use...
What about server/container crashes? AFAIK TCP doesn't have a persistent buffer to protect against server crashes and most containers don't (natively) support message persistence unless you use a MOM. In this case, why not design the protocol so that it can handle these situations rather than specifying how it should be implemented?
No, not necessarily. Note that business (generally) operates quite well without third-parties and often uses unreliable messaging to form contracts. There is also a well-known example (in legal circles, anyway) used to illustrate the loss of acceptance messages where the mailbox rule is not being applied, i.e. when acceptance is delivered to the offeror. It does not require a "reliable delivery model" or "a trustworthy observer" to be in place.
I think you are bringing in some of those intuitions I warned about... your legal example works because of a presumption of courts and evidential proof of due diligence etc.
WS-Agreement is going to be used where these institutions don't exist? Any resource provider (read business) potentially charging for work can't do this in splendid isolation of the existing local regulations and law...
We could not readily assume such an environment for resolving WS-Agreement negotiations, since audit systems and legal systems are not within scope of the GRAAP-WG.
I agree about the audit systems as this would be dependent on the local regulations where the service is being provided from. But, taking into account consideration the impact on business could be considered as being in scope if WS-Agreement is to be used between businesses (or individual users and businesses). One of the documents that got me interested in this topic was [1], where it states: "[agreements for Grid resources] present a formidable challenge, not least because of different international legal frameworks within which they have to operate" - others also recognise it can't be ignored.
We just toss up our hands and say one party is at the mercy of the other party sending notice of the decision.
As I've said before - the offeree always knows the decision before you. It isn't a question of throwing your hands up - this is how it is, therefore the offeror must be sure that they a prepared to enter into the contract when they make the offer.
It becomes a separate quality of implementation or trust issue for offerors to choose offerees.
Of course, but how do you stop the bad guys? If there are no courts or we're outside the legal system (like you mentioned above) who's going to take care of them?
This was important in order to provide a stepping stone for existing, traditional resource managers to be updated with WS-Agreement. The underlying offer/accept handshake and decision bias is very much consistent with conventional job-submission systems. We were also focused on relatively frequent (and automatic) real-time negotiation, i.e. the job and transient network QoS usage scenarios that motivated the GRAAP charter and its predecessors in the GARA and SNAP work. I think concerns about legal status and financial obligations took a back seat to concerns about practical distributed resource management.
As I said in another email, I believe that the legal, distributed computing and business aspects all need to be considered together. I also said that I think a simple protocol that meets these requirements is achievable.
All the same, I think our solution MAY be applied soundly in an environment where more audit and legal rules are available to resolve conflicts in retrospect. We took pains to provide the runtime extensibility handling so that profiles/extensions could be defined for things such as digital signature of offers and acceptance messages (early public comments worried about getting digital signatures for non-repudiation, and we tried to enable this without making it mandatory for traditional Grid use cases).
I agree, this is why we use the 'mail box' rule as otherwise we get into evidential issues about how many times the accept was attempted to be delivered, etc. But the offeror is still contracted whether they like it or not.
If the obligations can be contested based on "how many times the accept was attempted to be delivered, etc.", then what does it mean to say the offeror is "contracted"? (I ask this only out of academic interest, since you have already advocated the mail box rule.)
"What does it mean to say the offeror is contracted"? That they are bound to their obligations in the contract. I don't think the offeror would be contesting the obligations though, after all they sent them to the offeree. If they made a mistake and the offer was accepted - tough. (Like I said before, the offeror better be prepared to enter into a contract based on the offer they send). I presume that what you think may be contestable is whether the contract was actually formed or not if the agreement was never recieved. I think we've covered this.
OK, I'll accept this tautology and rephrase my statement to say that there is a practical ambiguity in whether the message is an offer or not, if one is not using the mail box rule, due to the ability for the initiator to pretend not to receive the acceptance.
If there's a 'practical ambiguity' between telling the difference between an offer and not-an-offer, then how do you tell the difference between any messages? If the message semantics/schema are defined and agreed to then you should be able to tell the difference and there is no practical ambiguity. If you haven't defined the semantics/schema (or have only partially defined them) then how can you interoperate at all?
Thanks for taking the time to privide these clarifications. However they don't address the other question of the resource provider having to 'lock' it's resources in a 2PC-style when it makes an offer, as was also discussed (and a solution proposed) in our paper.
I am not sure I know what question or solution you mean here.
See the original discussion on 2PC being a blocking protocol.
All I see in my reading of the document is a statement that a resource provider should be the offeree to avoid live lock. Is this what you mean?
Yes, the resource provider should always be the offeree to avoid locking its resources until it knows the other party is willing to make a contract for those resources. It avoids any possibility of a denial-of-service attack on the resource provider.
WS-Agreement defines the initiator/responder roles (offeror and offeree as you say) and is silent on resource provider/consumer roles because these concepts are inherently domain-specific.
I don't agree - generally, this is domain-independent precisely because the supplier or provider won't want to commit their goods before they know they are being sold. It also gives them the opportunity to say 'no' in case they have made a mistake or want to offer them to someone else. I say generally, because this may happen but it's a marginal case. Can you give me some examples where the offeror is the supplier/provider?
Your example in the document has a (to my eye) unusual scenario where a user "asks for a quote" and the computing service makes the offer.
Our e-Challenges paper? If so, then this example ("computing service makes the offer") is used to illustrate why computing services shouldn't make offers - we weren't advocating it! Also, if "the computing service mak[ing] the offer" is an "unusual scenario", why does the protocol Dominic wrote up from your emails [2] describe this very situation? (Step 5).
This is something we could have handled in SNAP via our invitation message, but the GRAAP-WG intentionally removed this capability. As I described in an earlier email, one could approximate this through a sophisticated use of advertisements (templates) and some template exchange system, but I think it is safe to say we marginalized this use case.
I'm interested to know why this is a marginal use case for GRAAP-WG. I feel it is central in any agreement process in order for both parties to let the other know what they want/are providing without issuing any binding offers. I also believe it doesn't have to be "sophisticated" - eCommerce web sites (i.e. distributed Internet-based services selling finite resources) seem to do quite well with web pages.
Interestingly, we found that there are differences of opinion as to what the "resource" is in some concrete examples!
In my opinion a resource can be anything that can be traded. Time, money, a book, a house...
It really depends on the domain, market, and community as to which aspect/role of the SLA is the more rare resource worth optimizing. If we assume that SLAs are about exchange of resource/service, the question is whether one party has a worse opportunity cost in obligating their resource in exchange for the other party's resource. If so, it would be preferable to allow the party with the worst opportunity cost to act as the offeree.
Sorry, but what does "worst opportunity cost" mean? Please, in a couple of sentences :-) Michael. [1] ftp://ftp.cordis.lu/pub/ist/docs/grids/ngg3_eg_final.pdf [2] https://cit-server.cit.tu-berlin.de/trac/negmgr/wiki/TwoPhaseCommit