- graap-wg - lists.ogf.org

Example for extending the agreement state for ws agreement negotiation
by Oliver Wäldrich 26 Sep '08

26 Sep '08

I just attached an example, how an extesion for an agreement state in WS-Agreement-Negotiation could look like: <wsag:AgreementState xmlns:wsag="http://schemas.ggf.org/graap/2007/03/ws-agreement"> <wsag:State>Terminated</wsag:State> <wsag-neg:NegotiationState xmlns:wsag-neg="http://schemas.ggf.org/graap/2008/10/ws-agreement-negotiat ion"> <wsag-neg:SubState>Superseeded</wsag-neg:SubState> </wsag-neg:NegotiationState> </wsag:AgreementState> We could also allow some additional element here, that points to the new created agreement. Best regards, Oliver ----------------------------------------------------------------------- Oliver Wäldrich Fraunhofer-Institute for Algorithms and Scientific Computing (SCAI) Schloss Birlinghoven, D-53754 Sankt Augustin, Germany Tel: +49 2241 14 2830; Fax: +49 2241 14 42830 CoreGRID Network of Excellence www.coregrid.net Institute on Resource Management and Scheduling www.coregrid.net/irms

1 0

Extension of agreement states for WS-Agreement-Negotiation
by Oliver Wäldrich 26 Sep '08

26 Sep '08

Dear all, After the discussion in the GRAAP group concerning the extension of the AgreementState port type for the negotiation protocol, it turned out that this is not necessary. It is still possible to define substates for the states defined in the WS-Agreement recommendation. The important structures for this are listed below: <xs:simpleType name="AgreementStateDefinition"> <xs:restriction base="xs:string"> <xs:enumeration value="Pending"/> <xs:enumeration value="PendingAndTerminating"/> <xs:enumeration value="Observed"/> <xs:enumeration value="ObservedAndTerminating"/> <xs:enumeration value="Rejected"/> <xs:enumeration value="Complete"/> <xs:enumeration value="Terminated"/> </xs:restriction> </xs:simpleType> AgreementStateDefinition defines the WS-Agreement states as an enumeration. <xs:complexType name="AgreementStateType"> <xs:complexContent> <xs:extension base="wsag:InnerAgreementStateType"> <xs:sequence> <xs:element name="State" type="wsag:AgreementStateDefinition"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="InnerAgreementStateType"> <xs:sequence> <xs:any minOccurs="0" namespace="##other" processContents="lax"/> </xs:sequence> </xs:complexType> The AgreementStateType defines one element State that can take a value defined in AgreementStateDefinition. AgreementStateType also extends InnerAgreementStateType, which allows extending AgreementStateType with an abritary XML document. Therefore, it is possible to add a document in the WS-Agreement-Negotiation namespace, which defines e.g. a substate for an AgreementState. How these extensions (e.g. substates) are defined, is then part of the WS-Agreement-Negotiation specification. However, this approach would be a fully compliant and compatible way to introduce substates in WS-Agreement-Negotiation with respect to the base WS-Agreement specification. Best regards, Oliver ----------------------------------------------------------------------- Oliver Wäldrich Fraunhofer-Institute for Algorithms and Scientific Computing (SCAI) Schloss Birlinghoven, D-53754 Sankt Augustin, Germany Tel: +49 2241 14 2830; Fax: +49 2241 14 42830 CoreGRID Network of Excellence www.coregrid.net Institute on Resource Management and Scheduling www.coregrid.net/irms

1 0

SLA examples
by Omer F. Rana 16 Sep '08

16 Sep '08

Dear Colleagues, I was wondering if you have examples of: 1. Service Level Agreements (SLAs) that you have come across. These do not need to be in WS-Agreement format -- any format would be fine. 2. If you have SLAs that have arisen from your own research/development projects that you are willing to share. 3. If you have SLAs that are encoded in WS-Agreement or some other commonly used specification. I would like to create a repository of these, and will be making this generally accessible. Would be grateful for pointers/examples.A personal email to o.f.rana(a)cs.cardiff.ac.uk would be great. regards Omer -- http://www.cs.cf.ac.uk/User/O.F.Rana/index.html / work-fax:+44(0)29-2087-4598 work:+44(0)29-2087-5542 / other:+44(0)7956-299981 / distributed collaborative computing / room n2.14 / school of computer science / cardiff university queen's buildings / newport road / cardiff cf24 3aa / wales / uk

1 0

GRAAP sessions at OGF 24 next week
by Wolfgang Ziegler 12 Sep '08

12 Sep '08

Dear GRAAPians, as agreed during the last OGF in Barcelona we will have two sessions at OGF 24: GRAAP#1 (90 mins) Wednesday, September 17, 2:15 pm - 3:45 pm, Location: Creation This session is focussing on the preparation of the experience document. Agenda: - Status of the Working group - Working on the Experience Document GRAAP#2 (90 mins) Wednesday, September 17, 4:00 pm - 5:30 pm, Location: Creation This session is dedicated to work on the negotiation protocol Agenda: - Result of last meeting and progress since then - Defining the messages - Role and handling of constraints Best regards & see you there Wolfgang -- Wolfgang Ziegler www.scai.fraunhofer.de/ziegler.html Fraunhofer-Institute for Algorithms and Scientific Computing (SCAI) Schloss Birlinghoven, D-53754 Sankt Augustin, Germany Tel: +49 2241 14 2258; Fax: +49 2241 14 42258 CoreGRID Network of Excellence www.coregrid.net Collaboration Gateway www.coregrid.net/cg Institute on Resource Management and Scheduling www.coregrid.net/irms

1 0

WG: WS-Agreement Spec Errata
by René Heek 25 Aug '08

25 Aug '08

Dear all, my colleague Roland and I discovered a minor error in the WSAG spec. We haven't found a public tracker for these kind of notifications ... maybe it's a good idea add one to the gridforge page? Regards, René ----------------------------------------------- René Heek Höchstleistungsrechenzentrum Stuttgart Universität Stuttgart Nobelstraße 19 70569 Stuttgart Phone: +49 711 685 60442 Fax: +49 711 685 65832 Skype: rh.hlrs -----Ursprüngliche Nachricht----- Von: Roland Kuebert [mailto:kuebert@hlrs.de] Gesendet: Freitag, 15. August 2008 11:03 An: Rene Heek Betreff: Zum weitersagen Hi, I just noticed that there is an error in the "Agreement Types Schema" section of the WS-Agreement Specification v1.0 (page numbers are for the document "WS-AgreementSpecification_V1.0.pdf"). In point 4.2.6.3.1 KPI Target (page 25), it says that the "KPITarget" element should contain a "KPIName" element and a "Target" element. In the schema, the second element is not named "Target" but "CustomServiceLevel" (page 57). Kind regads, Roland Kübert -- Dipl.-Inf. Roland Kübert Höchstleistungsrechenzentrum Stuttgart Universität Stuttgart Nobelstraße 19 70569 Stuttgart Phone: +49 711 685 65802 Fax: +49 711 685 65832 Skype: rkuebert

5 4

Re: [GRAAP-WG] Sessions at OGF24
by Alexander Papaspyrou 16 Jul '08

16 Jul '08

Wolfgang, I'll be there, too. -Alexander 2008/7/14 Sebastian Hudert <sebastian.hudert(a)uni-bayreuth.de>: > Hi all, > > unfortunately I will not be able to come to Singapore. So I will only be > able to contribute to the discussion on the mailing list. > > Best regards, > Sebastian > > --------------------------------------------------------------------------- > Sebastian Hudert > Dipl. Wirtsch.Inf. > > Department of Information Systems Management > University of Bayreuth > Universitaetsstr. 30 > 95447 Bayreuth > Building Applied Informatics > > Tel: +49 921 557665 > Fax: +49 921 557662 > > -----Ursprüngliche Nachricht----- > Von: graap-wg-bounces(a)ogf.org [mailto:graap-wg-bounces@ogf.org] Im Auftrag > von Philipp Wieder > Gesendet: Freitag, 11. Juli 2008 08:47 > An: Wolfgang Ziegler > Cc: GRAAP-WG > Betreff: Re: [GRAAP-WG] Sessions at OGF24 > > Hi Wolfgang, > > I would vote for two only (ok, I normally take minutes) and yes, I will be > in Singapore. > > Best regards, Philipp. > >> Dear GRAAPians, >> >> as discussed during OGF23 some of us plan to attend >> OGF24 and we intend to organise one or more sessions >> focussing on the experience document and the negotiation >> protocol. >> >> Since I expect the session request procedure soon I'd >> like to know who is planning to attend OGF24. Moreover, if >> you plan to participate I would be interested in your opinion >> on how many GRAAP sessions we should have there. >> >> My first guess would be at least two: one for the advancement >> of the experience document and the second one for the negotiation >> protocol. But I am open for having three as we had in the past. >> >> >> Best regards >> >> Wolfgang >> >> >> -- >> Wolfgang Ziegler www.scai.fraunhofer.de/ziegler.html >> Fraunhofer-Institute for Algorithms and Scientific Computing (SCAI) >> Schloss Birlinghoven, D-53754 Sankt Augustin, Germany >> Tel: +49 2241 14 2258; Fax: +49 2241 14 42258 >> >> CoreGRID Network of Excellence www.coregrid.net >> Collaboration Gateway www.coregrid.net/cg >> Institute on Resource Management and Scheduling >> www.coregrid.net/irms >> -- >> graap-wg mailing list >> graap-wg(a)ogf.org >> http://www.ogf.org/mailman/listinfo/graap-wg > > > -- > graap-wg mailing list > graap-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/graap-wg > > -- > graap-wg mailing list > graap-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/graap-wg > -- Dipl.-Inform. Alexander Papaspyrou http://ds.e-technik.uni-dortmund.de/~alexp Robotics Research Institute phone : +49(231)755-5058 Information Technology Section fax : +49(231)755-3251 Dortmund University of Technology, Germany

1 0

Sessions at OGF24
by Wolfgang Ziegler 14 Jul '08

14 Jul '08

Dear GRAAPians, as discussed during OGF23 some of us plan to attend OGF24 and we intend to organise one or more sessions focussing on the experience document and the negotiation protocol. Since I expect the session request procedure soon I'd like to know who is planning to attend OGF24. Moreover, if you plan to participate I would be interested in your opinion on how many GRAAP sessions we should have there. My first guess would be at least two: one for the advancement of the experience document and the second one for the negotiation protocol. But I am open for having three as we had in the past. Best regards Wolfgang -- Wolfgang Ziegler www.scai.fraunhofer.de/ziegler.html Fraunhofer-Institute for Algorithms and Scientific Computing (SCAI) Schloss Birlinghoven, D-53754 Sankt Augustin, Germany Tel: +49 2241 14 2258; Fax: +49 2241 14 42258 CoreGRID Network of Excellence www.coregrid.net Collaboration Gateway www.coregrid.net/cg Institute on Resource Management and Scheduling www.coregrid.net/irms

3 2

Sessins at OGF 23 in Barcelona
by Wolfgang Ziegler 18 May '08

18 May '08

Dear All, we will have three GRAAP sessions during the next OGF in Barcelona: GRAAP#1, Tuesday, June 3, 11:0 - 12:30 am Agenda: Progress since last OGF meeting - Interoperability/Compliance Document - Negotiation Document GRAAP#2, Tuesday, June 3, 5:30 - 7:00 pm Agenda: Interoperability: continuation of session 1 if necessary Negotiation: Presentation "A Proposal for a Protocol-Generic Negotiation Framework for WS Agreement" (Sebastian Hudert) Discussion on converging to a single proposal. Discussion of the new GFD Draft outline of the document Assignment of responsibilities for writing GRAAP#3, Wednesday, June 4, 9:00 - 10:30 am Agenda: Continuation of discussion on negotiation and preparation of the GFD draft Best regards Wolfgang -- Wolfgang Ziegler www.scai.fraunhofer.de/ziegler.html Fraunhofer-Institute for Algorithms and Scientific Computing (SCAI) Schloss Birlinghoven, D-53754 Sankt Augustin, Germany Tel: +49 2241 14 2258; Fax: +49 2241 14 42258 CoreGRID Network of Excellence www.coregrid.net Collaboration Gateway www.coregrid.net/cg Institute on Resource Management and Scheduling www.coregrid.net/irms

1 0

***SPAM*** WS Agreement Negotiation Framework
by Sebastian Hudert 17 Apr '08

17 Apr '08

Dear GRAAP Working Group, my name is Sebastian Hudert and I am affiliated with the Department of Information Systems Management at the University of Bayreuth. I have been working on a negotiation framework for WS-Agreement together with Dr. Heiko Ludwig (IBM Research) and Prof. Guido Wirtz (University of Bamberg). After meeting Wolfgang Ziegler at the CoreGRID Integration Workshop he suggested to introduce our ideas to the GRAAP WG in order to contribute to the WSAgreementNegotiation standard. Our main idea was to create a framework with which not only one particular negotiation protocol (e. g. an English Auction) can be executed, but one that allows for a variety of different negotiation protocols to be used according to the particular situation the system is in. We proposed an XML-based language that can be used to define a negotiation protocol in a machine-processable manner. A protocol description, coded as an XML document, therefore represents all the input needed by a service requestor or provider in order to take part in the particular negotiation process. Using the derived data structure we propose a two-staged negotiation process: 1. Exchange process: During this phase a negotiation protocol description document is created (possibly based on pre-defined protocol types and referring to a given WS-Agreement Template) and distributed to the future negotiators within the system. This process is implemented as a set of simple interfaces and valid method invocation sequences in analogy to the WS-Agreement standard itself. 2. Negotiation process: After supplying all negotiators with the protocol description these nodes engage in the actual negotiation process. We propose a set of generic interfaces able to cope with all negotiation protocols that can be described with the description language we defined. This way the logical steps from an initial need for a resource or the will to sell one to reaching a valid WS-Agreement are: Protocol Definition (XML-based Documents) à Exchange of protocol description to future negotiators (Exchange process) à Negotiation (Negotiation process) à Agreement formation I included a Paper presented at KIVS 07 on this topic. We hope that you find our ideas an interesting input for the ongoing standardization effort. I will attend the OGF 23 in Barcelona which would also be a possibility for me to present our work in the working group session, if there is interest among the WG. Best Regards, Sebastian Hudert --------------------------------------------------------------------------- Sebastian Hudert Dipl. Wirtsch.Inf. Department of Information Systems Management University of Bayreuth Universitaetsstr. 30 95447 Bayreuth Building Applied Informatics Tel: +49 921 557665 Fax: +49 921 557662

1 0

FW: Re-negotiation Protocol Proposal
by Toshiyuki Nakata 04 Mar '08

04 Mar '08

Hi Karl: > > Apparently, you want to consider the original agreement responder as a > "server side" component, so you don't feel complete until the original > initiator holds an EPR to an agreement representing the renegotiation > back on this "server side". Am I correct? > > I would not say that the agreement responder would be on the "Server" side. I had just assumed that the agreement factory would be on the Agreement responder side. > > A better rendering might eliminate this round-trip. What you could do > is send a PendingAgreement EPR in the initial renegotiation offer, so > the renegotiation responder already has an EPR before he decides to > accept. This would also support the Accept message, so the responder > could simply invoke that and be done with it. > WOuld this be same for both the cases of MI=AI and MI=AR? We were discussing in the group about the appplicability of having a modified EPR for MI=AR case... Best Regards Toshi ----- Toshiyuki Nakata 中田　登志之 Executive Chief Engineer, Central Research Lab. NEC 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60035) Fax +81-44-431-7609 (NEC Internal 22-60509) > -----Original Message----- > From: Karl Czajkowski [mailto:karlcz@univaud.com] > Sent: Friday, February 29, 2008 5:16 PM > To: Toshiyuki Nakata > Subject: Re: [GRAAP-WG] Re-negotiation Protocol Proposal > > On Feb 29, Toshiyuki Nakata modulated: > > > Hi Karl: we had three interesting sessions today. > > For the preparation of the sessions I created (today ;-) > > Some slides trying to see the roles. > > In pages 6-7 I tried to depict my interpretation of your comments. > > Please see if they are wrong or right. > > a)If wrong: Please tell me where I'd gone wron (and a > picture would help > > :-))) > > b)If OK please give us comments on my question in slide 7. > > ie. How can ADF verify thatAR agreed to the modification? > > > > I wouldn't say slide 7 captures my comment. My endpoint rendering > doesn't imply a third entity, just that the responder entity is > rendered with multiple endpoints to allow a more general scenario such > as renegotiation that could combine multiple agreements (something you > couldn't do if the preceding agreement is always implied like the > "this" pointer in a simple object system): > > 1. agreement initiator sends offer to agreement factory > > 2. agreement factory sends accept (sync or async reply) > > ... repeat 1-2 for multiple agreements... > > 3. renegotiation initiator sends offer to agreement factory > > 4. agreement factory sends accept (sync or async reply) > > in step (3) the renegotiation offer includes a reference to the > initial agreement(s) and the responder needs to validate that it makes > sense, e.g. that the right parties are involved and that the terms > would meaningfully supercede all of the referenced agreements. > > I would also disagree with your reversed roles being a 2-phase > decision protocol. The fact that you have an extra round-trip to find > the agreement EPR is an artifact of your rendering. Due to the nature > of the obligation assumed by the offerer when he sent the offer, he > doesn't have the right to refuse to give you the agreement when you > decide to accept. Having this fail is no different than any other > communication or implementation fault; it can happen in the real > world, but it is clear that the contract is binding anyway if the > responder got an offer and "sent an accept" based on the post-box rule > mentioned in the renegotiation proposal paper. > > Apparently, you want to consider the original agreement responder as a > "server side" component, so you don't feel complete until the original > initiator holds an EPR to an agreement representing the renegotiation > back on this "server side". Am I correct? > > A better rendering might eliminate this round-trip. What you could do > is send a PendingAgreement EPR in the initial renegotiation offer, so > the renegotiation responder already has an EPR before he decides to > accept. This would also support the Accept message, so the responder > could simply invoke that and be done with it. > > This same thing would apply in any symmettric peer-to-peer scenario as > well, just as with the existing WS-Agreement mechanism. By > maintaining Agreement and RenegotiatedAgreement resources "on both > sides", we can see the decoupled state of the negotiations from each > party's perspective. > > > karl > > -- > Karl Czajkowski > Software Architect > > Univa UD > 1001 Warrenville Road, Suite 550 > Lisle, IL 60532 > > karlcz(a)univaud.com > www.univa.com > ________________________________________________________________ > www.univa.com. > > The Leaders of Open Source Cluster and Grid Software > > The information contained in this e-mail message is from Univa UD and > may be privileged, confidential, and protected from > disclosure. If you > are not the intended recipient, any further disclosure or use, > dissemination, distribution, or copying of this message or any > attachment is strictly prohibited. If you think that you have received > this e-mail message in error, please delete the e-mail, and either > e-mail the sender at the above address or notify us at our address.

3 2