[GRAAP-WG] Problems of WS-Agreement Specification
Tianchao Li
lit at in.tum.de
Wed Sep 27 09:24:42 CDT 2006
*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
More information about the graap-wg
mailing list