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
*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.
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@univa.com
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
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
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
participants (3)
-
Jim Pruyne -
Karl Czajkowski -
Tianchao Li