From andre.merzky at ogf.org  Sun Sep  3 14:03:56 2006
From: andre.merzky at ogf.org (Andre Merzky)
Date: Sun, 3 Sep 2006 21:03:56 +0200
Subject: [GRAAP-WG] [wg-all] Mailing List Changes
Message-ID: <20060903190356.GG9333@koks>

Sorry for duplicates

------------------------------------------------------------

As of yesterday, all GGF/OGF mailing lists are migrated to
the ogf domain.  They are now managed by mailman, the web
interface is available at

  http://www.ogf.org/mailman/listinfo

With that migration, all list can be now reached via

  <list>@ogf.org

The old @ggf.org addresses will be available for some time,
but are bound to disappear eventually - please start using
the ogf addresses!

A number of lists have changed their names:

  ggf-it             -->   ogf-it
  ggf-office         -->   ogf-office
  ggf-proc-wg        -->   ogf-proc-wg
  ggf-sponsors       -->   ogf-sponsors
  ggf-tutorials      -->   ogf-tutorials
  ggf-compute        -->   ogf-compute
  ggflistowners      -->   ogflistowners
  ggfstudentmembers  -->   ogfstudentmembers

Postings to the old list names get forwarded to the new ones.

With the migration we have also been able to fix the archives
- you may have noticed that list archiving stopped sometime
in mid June.  Well, now its working again, and all mails from 
June to now have been added to the archive.

The list archives can be found at:

  http://www.ogf.org/archives/<list>

If you are an list administrator, and would like to receive
the list admin password, please contact postmaster at ogf.org.
In general, however, we tried to map the old majordomo
settings to the mailman settings, in terms of privacy etc,
so no or little changes should be required from your side.

The spam avoidance policy has been changed to some extent,
and is somewhat stricter than before.  Please let us know if
you experience any trouble with that.

On all questions in respect to mailing lists, or mails in
general, please contact postmaster at ogf.org.

Best regards, 

  Andre.
-- 
"So much time, so little to do..."  -- Garfield
--
  wg-all mailing list
  wg-all at ogf.org
  http://www.ogf.org/mailman/listinfo/wg-all


From jim_pruyne at hp.com  Wed Sep  6 01:24:31 2006
From: jim_pruyne at hp.com (Jim Pruyne)
Date: Wed, 06 Sep 2006 01:24:31 -0500
Subject: [GRAAP-WG] telecon on 12/6
Message-ID: <44FE699F.8030800@hp.com>

All,

GGF is next week!  Let's finalize plans at our telecon at the usual 
times and number.

9:00AM Central Daylight Time US (UTC-5)
which should be:
10:00AM Eastern Daylight Time US
1500 UK
1600 Germany
2300 Japan
2100 Thailand

Phone Number: 866-673-8466 in the US. 702-477-6031 for those outside the 
US.
Conference code #8578310.

Thanks.

--- Jim


From Wolfgang.Ziegler at scai.fraunhofer.de  Mon Sep 11 16:28:56 2006
From: Wolfgang.Ziegler at scai.fraunhofer.de (Wolfgang Ziegler)
Date: Mon, 11 Sep 2006 23:28:56 +0200
Subject: [GRAAP-WG] [Fwd: [graap-wg] Template for dynamic SLA use case
	document]
Message-ID: <4505D518.8070404@scai.fraunhofer.de>

Dear all,

here is the link to the template for the use-cases we just discussed
during the third GRAAP session.


Best regards

Wolfgang



-------- Original-Nachricht --------
Betreff: [graap-wg] Template for dynamic SLA use case document
Datum: Wed, 10 May 2006 11:57:35 +0200
Von: Philipp Wieder <ph.wieder at fz-juelich.de>
An: graap-wg at gridforum.org

Dear All,

please find a template for the use case document which we dicussed at
GGF 17 at
https://forge.gridforum.org/projects/graap-wg/document/Dynamic-SLA-use-case_template.doc/en/1. 

It is just the GSA-RG use case document
(http://www.ggf.org/documents/GFD.64.pdf) without content and has to be
adopted to the GRAAP needs.

Best regards, Philipp.


-- 
           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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2093 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/graap-wg/attachments/20060911/6a76aa36/attachment.bin 

From nakata at mtg.biglobe.ne.jp  Mon Sep 11 20:43:01 2006
From: nakata at mtg.biglobe.ne.jp (nakata)
Date: Tue, 12 Sep 2006 10:43:01 +0900
Subject: [GRAAP-WG] [Fwd: [graap-wg] Template for dynamic SLA use case
 document]
In-Reply-To: <4505D518.8070404@scai.fraunhofer.de>
References: <4505D518.8070404@scai.fraunhofer.de>
Message-ID: <450610A5.3080001@mtg.biglobe.ne.jp>

Hi Philipp:
Due to Gridforge reconstruction, the link seems to be broken..
Could you please upload?

Best Regards
Toshi

Wolfgang Ziegler wrote:

> Dear all,
>
> here is the link to the template for the use-cases we just discussed
> during the third GRAAP session.
>
>
> Best regards
>
> Wolfgang
>
>
>
> -------- Original-Nachricht --------
> Betreff: [graap-wg] Template for dynamic SLA use case document
> Datum: Wed, 10 May 2006 11:57:35 +0200
> Von: Philipp Wieder <ph.wieder at fz-juelich.de>
> An: graap-wg at gridforum.org
>
> Dear All,
>
> please find a template for the use case document which we dicussed at
> GGF 17 at
> https://forge.gridforum.org/projects/graap-wg/document/Dynamic-SLA-use-case_template.doc/en/1. 
>
> It is just the GSA-RG use case document
> (http://www.ggf.org/documents/GFD.64.pdf) without content and has to be
> adopted to the GRAAP needs.
>
> Best regards, Philipp.
>
>
>------------------------------------------------------------------------
>
>--
>  graap-wg mailing list
>  graap-wg at ogf.org
>  http://www.ogf.org/mailman/listinfo/graap-wg
>



From nakata at mtg.biglobe.ne.jp  Mon Sep 11 20:43:01 2006
From: nakata at mtg.biglobe.ne.jp (nakata)
Date: Tue, 12 Sep 2006 10:43:01 +0900
Subject: [GRAAP-WG] [Fwd: [graap-wg] Template for dynamic SLA use case
 document]
In-Reply-To: <4505D518.8070404@scai.fraunhofer.de>
References: <4505D518.8070404@scai.fraunhofer.de>
Message-ID: <450610A5.3080001@mtg.biglobe.ne.jp>

Hi Philipp:
Due to Gridforge reconstruction, the link seems to be broken..
Could you please upload?

Best Regards
Toshi

Wolfgang Ziegler wrote:

> Dear all,
>
> here is the link to the template for the use-cases we just discussed
> during the third GRAAP session.
>
>
> Best regards
>
> Wolfgang
>
>
>
> -------- Original-Nachricht --------
> Betreff: [graap-wg] Template for dynamic SLA use case document
> Datum: Wed, 10 May 2006 11:57:35 +0200
> Von: Philipp Wieder <ph.wieder at fz-juelich.de>
> An: graap-wg at gridforum.org
>
> Dear All,
>
> please find a template for the use case document which we dicussed at
> GGF 17 at
> https://forge.gridforum.org/projects/graap-wg/document/Dynamic-SLA-use-case_template.doc/en/1. 
>
> It is just the GSA-RG use case document
> (http://www.ggf.org/documents/GFD.64.pdf) without content and has to be
> adopted to the GRAAP needs.
>
> Best regards, Philipp.
>
>
>------------------------------------------------------------------------
>
>--
>  graap-wg mailing list
>  graap-wg at ogf.org
>  http://www.ogf.org/mailman/listinfo/graap-wg
>



From ph.wieder at fz-juelich.de  Tue Sep 12 05:55:46 2006
From: ph.wieder at fz-juelich.de (Philipp Wieder)
Date: Tue, 12 Sep 2006 12:55:46 +0200
Subject: [GRAAP-WG] [Fwd: [graap-wg] Template for dynamic SLA use case
 document]
In-Reply-To: <450610A5.3080001@mtg.biglobe.ne.jp>
References: <4505D518.8070404@scai.fraunhofer.de>
	<450610A5.3080001@mtg.biglobe.ne.jp>
Message-ID: <45069232.10607@fz-juelich.de>

Dear All,

you can find the Document at
https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.graap-wg/docman.root.current_drafts/doc6095

Best regards, Philipp.

nakata wrote:
> Hi Philipp:
> Due to Gridforge reconstruction, the link seems to be broken..
> Could you please upload?
> 
> Best Regards
> Toshi
> 
> Wolfgang Ziegler wrote:
> 
>> Dear all,
>>
>> here is the link to the template for the use-cases we just discussed
>> during the third GRAAP session.
>>
>>
>> Best regards
>>
>> Wolfgang
>>
>>
>>
>> -------- Original-Nachricht --------
>> Betreff: [graap-wg] Template for dynamic SLA use case document
>> Datum: Wed, 10 May 2006 11:57:35 +0200
>> Von: Philipp Wieder <ph.wieder at fz-juelich.de>
>> An: graap-wg at gridforum.org
>>
>> Dear All,
>>
>> please find a template for the use case document which we dicussed at
>> GGF 17 at
>> https://forge.gridforum.org/projects/graap-wg/document/Dynamic-SLA-use-case_template.doc/en/1. 
>>
>> It is just the GSA-RG use case document
>> (http://www.ggf.org/documents/GFD.64.pdf) without content and has to be
>> adopted to the GRAAP needs.
>>
>> Best regards, Philipp.
>>
>>
>> ------------------------------------------------------------------------
>>
>> --
>>  graap-wg mailing list
>>  graap-wg at ogf.org
>>  http://www.ogf.org/mailman/listinfo/graap-wg
>>
> 
> --
>   graap-wg mailing list
>   graap-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/graap-wg



From ph.wieder at fz-juelich.de  Tue Sep 12 05:55:46 2006
From: ph.wieder at fz-juelich.de (Philipp Wieder)
Date: Tue, 12 Sep 2006 12:55:46 +0200
Subject: [GRAAP-WG] [Fwd: [graap-wg] Template for dynamic SLA use case
 document]
In-Reply-To: <450610A5.3080001@mtg.biglobe.ne.jp>
References: <4505D518.8070404@scai.fraunhofer.de>
	<450610A5.3080001@mtg.biglobe.ne.jp>
Message-ID: <45069232.10607@fz-juelich.de>

Dear All,

you can find the Document at
https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.graap-wg/docman.root.current_drafts/doc6095

Best regards, Philipp.

nakata wrote:
> Hi Philipp:
> Due to Gridforge reconstruction, the link seems to be broken..
> Could you please upload?
> 
> Best Regards
> Toshi
> 
> Wolfgang Ziegler wrote:
> 
>> Dear all,
>>
>> here is the link to the template for the use-cases we just discussed
>> during the third GRAAP session.
>>
>>
>> Best regards
>>
>> Wolfgang
>>
>>
>>
>> -------- Original-Nachricht --------
>> Betreff: [graap-wg] Template for dynamic SLA use case document
>> Datum: Wed, 10 May 2006 11:57:35 +0200
>> Von: Philipp Wieder <ph.wieder at fz-juelich.de>
>> An: graap-wg at gridforum.org
>>
>> Dear All,
>>
>> please find a template for the use case document which we dicussed at
>> GGF 17 at
>> https://forge.gridforum.org/projects/graap-wg/document/Dynamic-SLA-use-case_template.doc/en/1. 
>>
>> It is just the GSA-RG use case document
>> (http://www.ggf.org/documents/GFD.64.pdf) without content and has to be
>> adopted to the GRAAP needs.
>>
>> Best regards, Philipp.
>>
>>
>> ------------------------------------------------------------------------
>>
>> --
>>  graap-wg mailing list
>>  graap-wg at ogf.org
>>  http://www.ogf.org/mailman/listinfo/graap-wg
>>
> 
> --
>   graap-wg mailing list
>   graap-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/graap-wg



From oaum47sul at zcwe.ogf.org  Fri Sep 22 05:40:26 2006
From: oaum47sul at zcwe.ogf.org (Cruz Culver)
Date: Fri, 22 Sep 06 10:40:26 GMT
Subject: [GRAAP-WG] Promote your business
Message-ID: <t3r39$d-w$-cq8$u19$g3$u9-h0-yp@wdo.lyuyz38h>

An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/graap-wg/attachments/20060922/4868ff1d/attachment.html 

From r108fi at zcwe.ogf.org  Mon Sep 25 03:16:18 2006
From: r108fi at zcwe.ogf.org (Maryann Jeffers)
Date: Mon, 25 Sep 06 08:16:18 GMT
Subject: [GRAAP-WG] hi
Message-ID: <5$3rqij2t396@tjccjw9uv>

An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/graap-wg/attachments/20060925/028951c1/attachment.html 

From Stephen.Pickles at manchester.ac.uk  Tue Sep 26 11:20:39 2006
From: Stephen.Pickles at manchester.ac.uk (Stephen M Pickles)
Date: Tue, 26 Sep 2006 17:20:39 +0100
Subject: [GRAAP-WG] agreement state diagram
Message-ID: <20060926172039385.00000002632@Wombat>

While reading the latest WS-Agreement specification
(2006/09), I was puzzled by the existence of the transitions
from "PendingAndTerminating" to "ObservedAndTerminating",
and "ObservedAndTerminating" to "Observed" in the
agreement state diagram in section 7.1.

Is this because the responder is allowed to choose to observe
an agreement even after it has received a Terminate message
from the initiator?

Stephen



From jim_pruyne at hp.com  Tue Sep 26 17:10:44 2006
From: jim_pruyne at hp.com (Jim Pruyne)
Date: Tue, 26 Sep 2006 17:10:44 -0500
Subject: [GRAAP-WG] telecon on 9/27
Message-ID: <4519A564.2050304@hp.com>

Folks,

As discussed at GGF two weeks ago, we're moving to an every other week 
telecon schedule.  We'll start that tomorrow, 9/27 at the regular times, 
and we'll continue to meet on Wednesdays.  Details are below.

9:00AM Central Daylight Time US (UTC-5)
which should be:
10:00AM Eastern Daylight Time US
1500 UK
1600 Germany
2300 Japan
2100 Thailand

Phone Number: 866-673-8466 in the US. 702-477-6031 for those outside the 
US.
Conference code #8578310.


For this call, we'll discuss the outcomes of the most recent GGF, and 
share the recommendation from the GFSG on the most recent submission of 
WS-Agreement to them.

--- Jim




From lit at in.tum.de  Wed Sep 27 09:24:42 2006
From: lit at in.tum.de (Tianchao Li)
Date: Wed, 27 Sep 2006 16:24:42 +0200
Subject: [GRAAP-WG] Problems of WS-Agreement Specification
In-Reply-To: <4519A564.2050304@hp.com>
References: <4519A564.2050304@hp.com>
Message-ID: <451A89AA.4000807@in.tum.de>

*Hello,
*

*
while I am currently working on an implementation of WS-Agreement on 
Globus Toolkit 4, I found some potential problems with the current 
specification.*

*Many of them are minor issues, but some can be important. I have 
documented those I have found up to now and sending it to the mail list 
so that we have a chance to improve it in the next draft.
*

*best regards,*

*Tianchao Li*

*LRR, Technische Universitaet Muenchen, Germany
*

==========================================================

1. non symmetric names

TerminateRequest <-> TerminateResponse (operation input/output)

TerminateInputMessage <-> TerminateOuputMessage (input/output message)
TerminateInput <-> TerminateResponse (input/output element)

recommendation:

(1) A simple choice:

TerminateResponse should be modified to TerminateOutput to be consistent 
with the other definitions.

This will force the input and output type of the service method to be 
TerminateInput and Terminate output, which is a little bit strange to me.

(2) A better choice:

TerminateInput <-> TerminateOutput (operation input/output)

TerminateInputMessage <-> TerminateOuputMessage (input/output message)
TerminateRequest <-> TerminateResponse (input/output element)

2. Agreement Template Property of Agreement Factory and Pending 
Agreement Factory Service

The agreement factory has a property of agreement template. However, the 
agreement template retrieval should be regarded as a part of the 
resource negotiation process to accommodate the different modes of 
negotiation. For example, the service provider might post their 
agreement template in a category (index) service as advertisement.

This might also cause security problems. For example, the service 
provider might want to provide different templates for different 
clients, or restrict certain clients to access template at all.

recommendation:

do not define the agreement template property in agreement factory and 
pending agreement factory service.

Instead, move the derivation of agreement template to the layer of 
agreement negotiation.

3. Separation of Agreement port type and agreement status port type

The agreement port type and status port type is separated in the current 
specification. I understand that this is mainly to separate the resource 
properties that are related with agreement definition and agreement status.

However, the current specification does not define the link between the 
agreement resource property and agreement status resource property 
explicitly.

The AgreementFactory and PendingAgreementFactory service only creates 
agreement and how the agreement status is created is not specified.

recommendation:
We have different choices:

(1) merge agreement and agreement status port type

(2) modify AgreementFactory and PendingAgreementFactory portType

(3) specify the relation more explicitly in the documentation

4. Inconsistent name conventions

Resource parameters and message names are sometimes big camel case and 
some times lower camel case. For example: agreementProperties is used 
with first character in lower case.

recommendation:

make them consistent.

5. rejectAgreementInput/Ouput with type AgreementAcceptanceInputType and 
AgreementAcceptanceOutputType . This is a littlble bit confusing name, 
as in the Java program, object with type AgreementAcceptanceInputType 
and AgreementAcceptanceOutputType will be used for rejectAgreement.

Recommendation:

Improve the schema definition by using type extensions.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/graap-wg/attachments/20060927/6ce4856d/attachment.html 

From jim_pruyne at hp.com  Wed Sep 27 09:43:28 2006
From: jim_pruyne at hp.com (Jim Pruyne)
Date: Wed, 27 Sep 2006 09:43:28 -0500
Subject: [GRAAP-WG] minutes from Sep 27 telecon
Message-ID: <451A8E10.30009@hp.com>

Are attached.  The next call will be in two weeks, on Oct. 11.

--- Jim


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Sep2706-minutes.txt
Url: http://www.ogf.org/pipermail/graap-wg/attachments/20060927/80aa8879/attachment.txt 

From karlcz at univa.com  Wed Sep 27 09:50:33 2006
From: karlcz at univa.com (Karl Czajkowski)
Date: Wed, 27 Sep 2006 21:50:33 +0700
Subject: [GRAAP-WG] minutes from Sep 27 telecon
In-Reply-To: <451A8E10.30009@hp.com>
References: <451A8E10.30009@hp.com>
Message-ID: <20060927145033.GN3621@moraine.localdomain>

We have been discussing interoperability issues in Globus, and one
thing that is glaringly obvious is that we have to revise many of our
WSDLs to support a new WS-Addressing specification, because the
explicit elements/type are used in, e.g., the factory-like operations.

Would it be worth loosening the WSDL here for WS-Agreement to have an
xsd:any "envelope" to hold the endpoints, and English text explaining
that a version of the WS-Addressing concept should be included?  This
would allow people to profile WS-Agreement for use in specific
implementation environments without requiring a modified version of
the WSDL.

At worst, I guess we'd need to add a resource property to list the
"supported addressing versions", e.g. element or type QNames, and
maybe an extra factory extension element to express the client's
restricted set of acceptable EPR versions for the newly created
Agreement resource (in case the deployed service can handle more than
one version)...

What do you guys think?


karl

-- 
Karl Czajkowski
karlcz at univa.com


From karlcz at univa.com  Wed Sep 27 09:57:49 2006
From: karlcz at univa.com (Karl Czajkowski)
Date: Wed, 27 Sep 2006 21:57:49 +0700
Subject: [GRAAP-WG] Problems of WS-Agreement Specification
In-Reply-To: <451A89AA.4000807@in.tum.de>
References: <4519A564.2050304@hp.com> <451A89AA.4000807@in.tum.de>
Message-ID: <20060927145749.GO3621@moraine.localdomain>

On Sep 27, Tianchao Li modulated:
...
> 2. Agreement Template Property of Agreement Factory and Pending
> Agreement Factory Service
> 
> The agreement factory has a property of agreement template. However,
> the agreement template retrieval should be regarded as a part of the
> resource negotiation process to accommodate the different modes of
> negotiation.  For example, the  service provider might post their
> agreement template in a category (index) service as advertisement.
> 
> This might also cause security problems. For example, the service
> provider might want to provide different templates for different
> clients, or restrict certain clients to access template at all.
> 
> recommendation:
> 
> do not define the agreement template property in agreement factory and
> pending agreement factory service.
> 

I disagree with this recommendation. I think there are several less
invasive alternatives:

   1. an implementation is free to apply authorization checks to 
      control what templates are viewed by what clients during RP query

   2. an implementation is free to only list a limited set of "public" 
      templates in the PR, and provide an extended retrievel mechanism
      to get the "private" templates, as part of an extended negotiation
      system, etc.

   3. the process by which templates might find their way into indexes
      or registries is not defined nor restricted by the spec.

...
> We have different choices:
> 
> (1) merge agreement and agreement status port type
> 
> (2) modify AgreementFactory and PendingAgreementFactory portType
> 
> (3) specify the relation more explicitly in the documentation
> 

I am surprised by this. I think the specification should be stating
(3) that the result of our factory is a resource which implements
both. The reason for separating them is to allow someone else to reuse
just portions of the protocol, I think.  (But perhaps I have missed
some other discussion on this...)


karl

-- 
Karl Czajkowski
karlcz at univa.com


From karlcz at univa.com  Wed Sep 27 09:57:49 2006
From: karlcz at univa.com (Karl Czajkowski)
Date: Wed, 27 Sep 2006 21:57:49 +0700
Subject: [GRAAP-WG] Problems of WS-Agreement Specification
In-Reply-To: <451A89AA.4000807@in.tum.de>
References: <4519A564.2050304@hp.com> <451A89AA.4000807@in.tum.de>
Message-ID: <20060927145749.GO3621@moraine.localdomain>

On Sep 27, Tianchao Li modulated:
...
> 2. Agreement Template Property of Agreement Factory and Pending
> Agreement Factory Service
> 
> The agreement factory has a property of agreement template. However,
> the agreement template retrieval should be regarded as a part of the
> resource negotiation process to accommodate the different modes of
> negotiation.  For example, the  service provider might post their
> agreement template in a category (index) service as advertisement.
> 
> This might also cause security problems. For example, the service
> provider might want to provide different templates for different
> clients, or restrict certain clients to access template at all.
> 
> recommendation:
> 
> do not define the agreement template property in agreement factory and
> pending agreement factory service.
> 

I disagree with this recommendation. I think there are several less
invasive alternatives:

   1. an implementation is free to apply authorization checks to 
      control what templates are viewed by what clients during RP query

   2. an implementation is free to only list a limited set of "public" 
      templates in the PR, and provide an extended retrievel mechanism
      to get the "private" templates, as part of an extended negotiation
      system, etc.

   3. the process by which templates might find their way into indexes
      or registries is not defined nor restricted by the spec.

...
> We have different choices:
> 
> (1) merge agreement and agreement status port type
> 
> (2) modify AgreementFactory and PendingAgreementFactory portType
> 
> (3) specify the relation more explicitly in the documentation
> 

I am surprised by this. I think the specification should be stating
(3) that the result of our factory is a resource which implements
both. The reason for separating them is to allow someone else to reuse
just portions of the protocol, I think.  (But perhaps I have missed
some other discussion on this...)


karl

-- 
Karl Czajkowski
karlcz at univa.com


From t-nakata at cw.jp.nec.com  Wed Sep 27 10:23:59 2006
From: t-nakata at cw.jp.nec.com (t-nakata at cw.jp.nec.com)
Date: Thu, 28 Sep 2006 00:23:59 +0900
Subject: [GRAAP-WG] minutes from Sep 27 telecon
In-Reply-To: <451A8E10.30009@hp.com>
References: <451A8E10.30009@hp.com>
Message-ID: <isapiwc.6197d101.4a5b.451a978f.ee06d.65@mail.jp.nec.com>

Hi : Just to check,

 > - Toshi can work on a change summary by extracting from the slides
 >  he did at previous GGFs.

Can I concentrate on the 2nd round of Public Comments or would it
be necessary to address the first round also?

#My memory being as bad as it is, it would be easier to concentrate on 
#the 2nd round but if necessary, I can try the first round as well.

#I just want to avoid unnecessary work ;-)

Best Regards
Toshi
-------
NEC ????????????
??????
Toshiyuki Nakata
Executive Chief Engineer
Central Research Laboratories 
NEC Corporation
+81-44-431-7653


From karlcz at univa.com  Wed Sep 27 10:39:16 2006
From: karlcz at univa.com (Karl Czajkowski)
Date: Wed, 27 Sep 2006 22:39:16 +0700
Subject: [GRAAP-WG] minutes from Sep 27 telecon
In-Reply-To: <20060927155711.B26380-100000@nessie.mcc.ac.uk>
References: <20060927145033.GN3621@moraine.localdomain>
	<20060927155711.B26380-100000@nessie.mcc.ac.uk>
Message-ID: <20060927153916.GP3621@moraine.localdomain>

On Sep 27, Mark McKeown modulated:
> 
> Hi Karl,
>        I am not sure I understand your issue but I have
> recently read the WS-Agreement spec and have some questions
> regarding the use of WS-Addressing with WS-Agreement.
> 

The basic issue is that the factory output message includes the EPR of
the newly created Agreement resource. Currently, I believe the WSDL
has used a specific wsa:EndpointReference_Type for this.  Making it
xsd:any would prevent us from having to reissue the WSDL, e.g. with a
new namespace, each time someone wants to support a different endpoint
reference type.  The question is whether we want WS-Agreement to be
generic in the face of multiple WS-Addressing versions, for whatever
EPRs we must encode in the WS-Agreement message bodies.

This is an issue today, with people trying to implement the
specification in different tooling environments which use different
drafts etc.  I am not sure whether this issue will ever disappear,
e.g. is there a "final" WS-Addressing specification which will never
be revised and require more updates of WS-Agreement implementations in
practice...


...
> To me this means that the wsag:initiatorAgreementEPR
> and wsag:agreementAcceptanceEPR elements in Section 9.1.1.1
> and 9.2.1.1 are not required: WS-Addressing provides the
> required functionality. Also there is no requirement for the
> Accept/Reject operation on the AgreementAcceptance resource;
> WS-Addressing wsa:MessageId and wsa:RelatesTo can be used to
> map agreement requests to responses.
> 

The initiatorAgreement is not just for a "reply".  It is making the
service aware of an (optional) peer resource representing the same
agreement, but from the "offering party's point of view".  It would
potentially be the target for multiple operations, resource propery
queries, notification subscriptions etc. 

Many aspects of the WS-Agreement WSDL is geared to being implementable
with "yesterday's and today's" WS tooling, where abstract in/out
patterns are naively mapped to synchronous "RPC over SOAP over HTTP"
implementations.  The reason behind the PendingAgreement and
AgreementAcceptance mechanism is to support a long delay in the
agreement decision process, while not making WS-Agreement too
difficult to use with older or simplistic tooling.

For example, we can have unbounded delays in a resource manager, and
we cannot depend on the SOAP tooling being capable of correlating the
in/out message pair of the synchronous agreement creation across such
a delay.  With the naive SOAP over HTTP bindings, we would have a very
fragile system if the "out" messages would be dropped frequently due
to HTTP and TCP timeouts.  Also, the forced ordering of in/out message
pairs over HTTP would be a problem for making multiple agreement
offers and needing to hear the responses in a different natural order
than the offers were sent.

Similarly, the Accept/Reject is known to be redundant in the face of
notification.  It provides an optional callback for environments where
general subscription to monitor the agreement state is not possible.


karl

-- 
Karl Czajkowski
karlcz at univa.com


From karlcz at univa.com  Wed Sep 27 10:39:16 2006
From: karlcz at univa.com (Karl Czajkowski)
Date: Wed, 27 Sep 2006 22:39:16 +0700
Subject: [GRAAP-WG] minutes from Sep 27 telecon
In-Reply-To: <20060927155711.B26380-100000@nessie.mcc.ac.uk>
References: <20060927145033.GN3621@moraine.localdomain>
	<20060927155711.B26380-100000@nessie.mcc.ac.uk>
Message-ID: <20060927153916.GP3621@moraine.localdomain>

On Sep 27, Mark McKeown modulated:
> 
> Hi Karl,
>        I am not sure I understand your issue but I have
> recently read the WS-Agreement spec and have some questions
> regarding the use of WS-Addressing with WS-Agreement.
> 

The basic issue is that the factory output message includes the EPR of
the newly created Agreement resource. Currently, I believe the WSDL
has used a specific wsa:EndpointReference_Type for this.  Making it
xsd:any would prevent us from having to reissue the WSDL, e.g. with a
new namespace, each time someone wants to support a different endpoint
reference type.  The question is whether we want WS-Agreement to be
generic in the face of multiple WS-Addressing versions, for whatever
EPRs we must encode in the WS-Agreement message bodies.

This is an issue today, with people trying to implement the
specification in different tooling environments which use different
drafts etc.  I am not sure whether this issue will ever disappear,
e.g. is there a "final" WS-Addressing specification which will never
be revised and require more updates of WS-Agreement implementations in
practice...


...
> To me this means that the wsag:initiatorAgreementEPR
> and wsag:agreementAcceptanceEPR elements in Section 9.1.1.1
> and 9.2.1.1 are not required: WS-Addressing provides the
> required functionality. Also there is no requirement for the
> Accept/Reject operation on the AgreementAcceptance resource;
> WS-Addressing wsa:MessageId and wsa:RelatesTo can be used to
> map agreement requests to responses.
> 

The initiatorAgreement is not just for a "reply".  It is making the
service aware of an (optional) peer resource representing the same
agreement, but from the "offering party's point of view".  It would
potentially be the target for multiple operations, resource propery
queries, notification subscriptions etc. 

Many aspects of the WS-Agreement WSDL is geared to being implementable
with "yesterday's and today's" WS tooling, where abstract in/out
patterns are naively mapped to synchronous "RPC over SOAP over HTTP"
implementations.  The reason behind the PendingAgreement and
AgreementAcceptance mechanism is to support a long delay in the
agreement decision process, while not making WS-Agreement too
difficult to use with older or simplistic tooling.

For example, we can have unbounded delays in a resource manager, and
we cannot depend on the SOAP tooling being capable of correlating the
in/out message pair of the synchronous agreement creation across such
a delay.  With the naive SOAP over HTTP bindings, we would have a very
fragile system if the "out" messages would be dropped frequently due
to HTTP and TCP timeouts.  Also, the forced ordering of in/out message
pairs over HTTP would be a problem for making multiple agreement
offers and needing to hear the responses in a different natural order
than the offers were sent.

Similarly, the Accept/Reject is known to be redundant in the face of
notification.  It provides an optional callback for environments where
general subscription to monitor the agreement state is not possible.


karl

-- 
Karl Czajkowski
karlcz at univa.com


From jim_pruyne at hp.com  Wed Sep 27 10:41:28 2006
From: jim_pruyne at hp.com (Jim Pruyne)
Date: Wed, 27 Sep 2006 10:41:28 -0500
Subject: [GRAAP-WG] minutes from Sep 27 telecon
In-Reply-To: <isapiwc.6197d101.4a5b.451a978f.ee06d.65@mail.jp.nec.com>
References: <451A8E10.30009@hp.com>
	<isapiwc.6197d101.4a5b.451a978f.ee06d.65@mail.jp.nec.com>
Message-ID: <451A9BA8.8090006@hp.com>

Just the second round should be sufficient.

Thanks again.

--- Jim

t-nakata at cw.jp.nec.com wrote:
> Hi : Just to check,
>
>  > - Toshi can work on a change summary by extracting from the slides
>  >  he did at previous GGFs.
>
> Can I concentrate on the 2nd round of Public Comments or would it
> be necessary to address the first round also?
>
> #My memory being as bad as it is, it would be easier to concentrate on 
> #the 2nd round but if necessary, I can try the first round as well.
>
> #I just want to avoid unnecessary work ;-)
>
> Best Regards
> Toshi
> -------
> NEC ????????????
> ??????
> Toshiyuki Nakata
> Executive Chief Engineer
> Central Research Laboratories 
> NEC Corporation
> +81-44-431-7653
> --
>   graap-wg mailing list
>   graap-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/graap-wg
>   


From Mark.McKeown at manchester.ac.uk  Wed Sep 27 16:46:38 2006
From: Mark.McKeown at manchester.ac.uk (Mark.McKeown at manchester.ac.uk)
Date: Wed, 27 Sep 2006 22:46:38 +0100 (BST)
Subject: [GRAAP-WG] minutes from Sep 27 telecon
In-Reply-To: <20060927153916.GP3621@moraine.localdomain>
References: <20060927145033.GN3621@moraine.localdomain>
	<20060927155711.B26380-100000@nessie.mcc.ac.uk>
	<20060927153916.GP3621@moraine.localdomain>
Message-ID: <Pine.LNX.4.64.0609272129340.31281@localhost.localdomain>


Hi Karl

>>        I am not sure I understand your issue but I have
>> recently read the WS-Agreement spec and have some questions
>> regarding the use of WS-Addressing with WS-Agreement.
>>
>
> The basic issue is that the factory output message includes the EPR of
> the newly created Agreement resource. Currently, I believe the WSDL
> has used a specific wsa:EndpointReference_Type for this.  Making it
> xsd:any would prevent us from having to reissue the WSDL, e.g. with a
> new namespace, each time someone wants to support a different endpoint
> reference type.  The question is whether we want WS-Agreement to be
> generic in the face of multiple WS-Addressing versions, for whatever
> EPRs we must encode in the WS-Agreement message bodies.
>
> This is an issue today, with people trying to implement the
> specification in different tooling environments which use different
> drafts etc.  I am not sure whether this issue will ever disappear,
> e.g. is there a "final" WS-Addressing specification which will never
> be revised and require more updates of WS-Agreement implementations in
> practice...
>

Perhaps the issue is more fundamental than you realise.
WS-Agreement is dependent on WS-RF, which is in turn
dependent on WS-Addressing. This means that messages in the
WS-Agreement protocol will include WS-Addressing elements
in the SOAP Headers. Mis-matchs between client/service
versions of WS-Addressing might bite before processing of
the SOAP Body even begins.

Since WS-Addressing[1] is now a W3C Recommendation I assume
that is the only version of the standard that should be
referenced in another specification. Quoting the WS-Addressing
standard:

"It is a stable document and may be used as reference material or cited 
from another document. W3C's role in making the Recommendation is to draw 
attention to the specification and to promote its widespread deployment. 
This enhances the functionality and interoperability of the Web."

Clearly changes to WS-Addressing from now on will have enormous
impact as soo many specifications are now reliant on it.

However as you point out there are practical issues. Perhaps
implementations could apply Postel's Law[2]:

"Be conservative in what you do; be liberal in which you accept
from others."

In which case an implementation could accept any version of
WS-Addressing, or some subset of the versions. A service recieving
a message could check the SOAP Headers to see which version of
wsa is being used by the client, and then it can use the same
version in the response. However, I am not really sure how
practical this is as many people feel Postel's law does not
apply to XML[3].

(As I pointed out below WS-Addressing could be used in a way to
avoid needing to include EPRs in the SOAP Body.)

>
> ...
>> To me this means that the wsag:initiatorAgreementEPR
>> and wsag:agreementAcceptanceEPR elements in Section 9.1.1.1
>> and 9.2.1.1 are not required: WS-Addressing provides the
>> required functionality. Also there is no requirement for the
>> Accept/Reject operation on the AgreementAcceptance resource;
>> WS-Addressing wsa:MessageId and wsa:RelatesTo can be used to
>> map agreement requests to responses.
>>
>
> The initiatorAgreement is not just for a "reply".  It is making the
> service aware of an (optional) peer resource representing the same
> agreement, but from the "offering party's point of view".  It would
> potentially be the target for multiple operations, resource propery
> queries, notification subscriptions etc.
>
> Many aspects of the WS-Agreement WSDL is geared to being implementable
> with "yesterday's and today's" WS tooling, where abstract in/out
> patterns are naively mapped to synchronous "RPC over SOAP over HTTP"
> implementations.  The reason behind the PendingAgreement and
> AgreementAcceptance mechanism is to support a long delay in the
> agreement decision process, while not making WS-Agreement too
> difficult to use with older or simplistic tooling.
>
> For example, we can have unbounded delays in a resource manager, and
> we cannot depend on the SOAP tooling being capable of correlating the
> in/out message pair of the synchronous agreement creation across such
> a delay.  With the naive SOAP over HTTP bindings, we would have a very
> fragile system if the "out" messages would be dropped frequently due
> to HTTP and TCP timeouts.  Also, the forced ordering of in/out message
> pairs over HTTP would be a problem for making multiple agreement
> offers and needing to hear the responses in a different natural order
> than the offers were sent.
>
> Similarly, the Accept/Reject is known to be redundant in the face of
> notification.  It provides an optional callback for environments where
> general subscription to monitor the agreement state is not possible.
>
>

I can appreciate the problems with WS-*/SOAP that you outlined,
and have tried to avoid in the WS-Agreement specification. However,
the GRAAP group must inherently have faith in the future of
WS-*/SOAP, or else it would not have choosen to use them in the
first place. I am reading WS-Agreement from a historical perspective
as I haven't followed the work closely. From this perspective it
seems strange that WS-Agreement has a dependence on WS-Addressing,
yet doesn't fully utilise it.

cheers
Mark

[1] http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/
[2] http://en.wikipedia.org/wiki/Robustness_Principle
[3] http://www.tbray.org/ongoing/When/200x/2004/01/11/PostelPilgrim


From karlcz at univa.com  Wed Sep 27 17:06:41 2006
From: karlcz at univa.com (Karl Czajkowski)
Date: Thu, 28 Sep 2006 05:06:41 +0700
Subject: [GRAAP-WG] minutes from Sep 27 telecon
In-Reply-To: <Pine.LNX.4.64.0609272129340.31281@localhost.localdomain>
References: <20060927145033.GN3621@moraine.localdomain>
	<20060927155711.B26380-100000@nessie.mcc.ac.uk>
	<20060927153916.GP3621@moraine.localdomain>
	<Pine.LNX.4.64.0609272129340.31281@localhost.localdomain>
Message-ID: <20060927220641.GA16278@moraine.localdomain>

On Sep 27, Mark.McKeown at manchester.ac.uk modulated:

> Perhaps the issue is more fundamental than you realise.
> WS-Agreement is dependent on WS-RF, which is in turn
> dependent on WS-Addressing. This means that messages in the
> WS-Agreement protocol will include WS-Addressing elements
> in the SOAP Headers. Mis-matchs between client/service
> versions of WS-Addressing might bite before processing of
> the SOAP Body even begins.
> 

The difference is that an implementation of the transport can strip
that off and support multiple versions without the application-level
logic caring about the version.  I agree that this has to be addressed
(no pun intended) before deploying WS-Agreement on another standards
stack makes sense. However, having explicit WS-Addressing references
in the service WSDL, e.g. inside the application message content,
means that even if the transport/container environment supports the
new version, a valid WS-Agreement message would not allow the newer
EPR.

I agree on the SOAP header points, but in our implementation in
Globus, that is a different layer of code than the application
code. Our observation is that the "factory pattern" where EPRs are
returned in application payload ties the application to a specific
version, even if our container were to support multiple versions. The
"be liberal in what you accept" means we would have to put an xsd:any
in the position where we currently have an element with a versioned
wsa:EndpointReference_Type, in the application's message schema.

I am afraid I do not see where you have addressed the question of how
the WS-Addressing features solve these practical problems:

How can WS-Addressing solve the issue of arbitrary delay between the
in and out message without "losing the connection", in any
contemporary tooling environment?  The EPR of an acceptance resource
is passed specifically to simulate a very delayed "out" message using
a new "in" message.  This seems to me to require a more suitable
transport than SOAP over HTTP, rather than an addressing solution.

How can WS-Addressing allow one to convey a new EPR to an application
without exposing the EPR in the application payload?  The optional
passing of an Agreement resource EPR is to establish a symmetric
peer-to-peer environment where each side can initiate new message
exchanges with the other.


-- 
Karl Czajkowski
karlcz at univa.com


From lit at in.tum.de  Fri Sep 29 11:16:58 2006
From: lit at in.tum.de (Tianchao Li)
Date: Fri, 29 Sep 2006 18:16:58 +0200
Subject: [GRAAP-WG] Problems of WS-Agreement Specification
In-Reply-To: <20060927145749.GO3621@moraine.localdomain>
References: <4519A564.2050304@hp.com> <451A89AA.4000807@in.tum.de>
	<20060927145749.GO3621@moraine.localdomain>
Message-ID: <451D46FA.6060300@in.tum.de>

Karl Czajkowski wrote:

>On Sep 27, Tianchao Li modulated:
>...
>  
>
>>2. Agreement Template Property of Agreement Factory and Pending
>>Agreement Factory Service
>>
>>The agreement factory has a property of agreement template. However,
>>the agreement template retrieval should be regarded as a part of the
>>resource negotiation process to accommodate the different modes of
>>negotiation.  For example, the  service provider might post their
>>agreement template in a category (index) service as advertisement.
>>
>>This might also cause security problems. For example, the service
>>provider might want to provide different templates for different
>>clients, or restrict certain clients to access template at all.
>>
>>recommendation:
>>
>>do not define the agreement template property in agreement factory and
>>pending agreement factory service.
>>
>>    
>>
>
>I disagree with this recommendation. I think there are several less
>invasive alternatives:
>
>   1. an implementation is free to apply authorization checks to 
>      control what templates are viewed by what clients during RP query
>
>   2. an implementation is free to only list a limited set of "public" 
>      templates in the PR, and provide an extended retrievel mechanism
>      to get the "private" templates, as part of an extended negotiation
>      system, etc.
>
>   3. the process by which templates might find their way into indexes
>      or registries is not defined nor restricted by the spec.
>  
>
Yes. These alternatives looks better to me.

>
>  
>
>>We have different choices:
>>
>>(1) merge agreement and agreement status port type
>>
>>(2) modify AgreementFactory and PendingAgreementFactory portType
>>
>>(3) specify the relation more explicitly in the documentation
>>
>>    
>>
>
>I am surprised by this. I think the specification should be stating
>(3) that the result of our factory is a resource which implements
>both. The reason for separating them is to allow someone else to reuse
>just portions of the protocol, I think.  (But perhaps I have missed
>some other discussion on this...)
>  
>
Thanks. I've found the description to the AgreementState porttype:
"The purpose of this port type is to define a resource document type for 
monitoring
the state of the agreement. This port type is not meant to be used as is 
but instead,
its resource properties MAY be composed into a domain-specific Agreement 
port
type".

>karl
>
>  
>



From lit at in.tum.de  Sat Sep 30 10:01:19 2006
From: lit at in.tum.de (Tianchao Li)
Date: Sat, 30 Sep 2006 17:01:19 +0200
Subject: [GRAAP-WG] AgreementServiceReference
In-Reply-To: <451D46FA.6060300@in.tum.de>
References: <4519A564.2050304@hp.com>
	<451A89AA.4000807@in.tum.de>	<20060927145749.GO3621@moraine.localdomain>
	<451D46FA.6060300@in.tum.de>
Message-ID: <451E86BF.7060803@in.tum.de>

I'm not quite understanding the meaning of the 
wsag:AgreementServiceReferenceList resource property of Agreement port 
type and wsag:AgreementServiceReference. There is no further 
explanations in the specification, except for the following sentence:
"This OPTIONAL property specifies a list of named handles to the 
services of the agreement. The property MAY be empty and some services 
MAY be empty and some services MAY be omitted."
What exactly is the "services of the agreement"? And how is this 
resource property intended to be used?

Best regards,
Tianchao Li



From lit at in.tum.de  Sat Sep 30 10:12:58 2006
From: lit at in.tum.de (Tianchao Li)
Date: Sat, 30 Sep 2006 17:12:58 +0200
Subject: [GRAAP-WG] AgreementServiceReference
In-Reply-To: <451E86BF.7060803@in.tum.de>
References: <4519A564.2050304@hp.com>
	<451A89AA.4000807@in.tum.de>	<20060927145749.GO3621@moraine.localdomain>
	<451D46FA.6060300@in.tum.de> <451E86BF.7060803@in.tum.de>
Message-ID: <451E897A.3060508@in.tum.de>

To be more exact, I am wondering how this AgreementServiceReference is 
related with the ServiceReference element of ServiceDescriptionTerm.
If they are the same, then why is this information duplicated? And if 
they are different, in which aspect?

Best regards,
Tianchao Li

========================
*LRR, Technische Universitaet Muenchen, Germany*


Tianchao Li wrote:

> I'm not quite understanding the meaning of the 
> wsag:AgreementServiceReferenceList resource property of Agreement port 
> type and wsag:AgreementServiceReference. There is no further 
> explanations in the specification, except for the following sentence:
> "This OPTIONAL property specifies a list of named handles to the 
> services of the agreement. The property MAY be empty and some services 
> MAY be empty and some services MAY be omitted."
> What exactly is the "services of the agreement"? And how is this 
> resource property intended to be used?
>
> Best regards,
> Tianchao Li
>