SourceForge : Post

Project: Editor Discussion > REC: WS-Agreement Spec > Flexibility of WS-A.(+ other, archiving, etc) > List of Posts

Forum Topic - Flexibility of WS-A.(+ other, archiving, etc): (2 Items)

View: as

Update

Viktor Yarmolenko

12/21/2005 12:44 PM

post4794

Flexibility of WS-A.(+ other, archiving, etc)

Here are some:

1. Flexibility of WS-Agreement. Answers some comments made by Donal and Shamima.
There were some concerns about the separation of negotiation from the actual contract (SLA) and need for WS-Agreement to
support any negotiation protocol. While I agree with this, I also want to point out that it is a shame that WS-A, even
after allowing the flexibility of negotiation, turns into a rigid contract as it is. It would be so much better, in my
opinion, for future services to be able to create flexible yet unambiguous SLAs. For example: I don't care how many CPUs
resource will utilize for my task, but I want it to finish in certain time and my task is capable of running on 1,2,3,.
..N processors, however the time required varies. So I describe SLO:duration_of_the_job and SLI to be not a constant but
say a function which is = k/Ncpu. Why? because Resource can reschedule the job as many times as it likes without
bothering me with re-negotiation. The same is true for price/penalty, bandwidth/traffic and other terms. Please see the
paper below for a more detailed discussion:
http://portal.acm.org/citation.cfm?doid=1101499.1101511
or ask me for a copy

2. I see the problem when a client harasses a resource asking for the service hundreds of times with slightly changed
configuration of the request. The client may want to do this in order to find the best option in the scenario when the
offer of the service narrows the negotiation process to take-it-or-leave-it formula. I suggest to introduce some small
price per request (visible from the template presumably), in order to discourage clients pinging all the time. This
should regulate the load on the service nicely. Make it free for the first 5 attempts, etc.

3. It seems that WS-Agreement is a contract between two parties, namely "initiator" and "responder". Although I cannot
give some sensible examples now of the case in which there are more than 2 parties participating in the Agreement (that
cannot be split into 2-party SLAs), it does not mean that such cases will not occur in the future. So, will the current
WS-Agreement fall apart when a third party, say a "mediator", appears?

4. WS-A Repository/Library Service.
This comment is not directly a WS-A problem but may affect it (similar to negotiation problem discussed by many people
here). Whether WS-Agreement refers to another Agreement or not, the need may arise for all WS-Agreements to be stored by
a trusted party/registry for at least N years, in which case Library Services may be required, which may use WS-A
themselves, and so on. How friendly is the current WS-A to cataloging/filing and digital signature bearing? Shouldn't
the tagging or more or less the entire archiving experience be well defined in WS-A?

Jim Pruyne

01/11/2006 11:32 AM

post4795

Response from GRAAP WG

- 1. We don't think the current WS-Agreement prohibits what he's
         suggesting, but we also don't define it.
    - 2. Basically DoS attack concerns.  Agreed, that this might be a
         nice thing to be able to do, but we consider it outside the
         scope of WS-Agreement.  Many of these issues are true for any
         web service, and not specific to WS-Agreement, though how one
         searches the possible agreement space is somewhat more
         relevant.
    - 3. We specifically restricted to 2 parties to avoid specific
         remediation of multiple parties.  That is, who specifically
        is at fault when there are more than two parties with specific
        responsibilities to one another.  Therefore, we limit WS-Agreement
        to two party.
    - 4. Agreed that a library service is useful, but it is outside
         the scope of WS-Agreement.  For signing, and authentication, other
         general practices for web services should be applicable.

Return