Folks, please find attached my proposal on how DMI could model the fault communication for the DTI. I deliberately did not fully write the proposal as a finished text for the specification. I first wanted to make clear why I designed the proposal as it is. If we agree to go ahead with whatever solution, we then still can add the solution to the spec, and bang our heads together on the words. :) Cheers, Michel
With one minor suggested change, I think that Michel's proposal is acceptable. The one exception is on page 3. The last paragraph before the box with the XML in it is too weak. The "must" in line 2 should be "MUST". IN the text placed into the actual DMI spec, I assume that the first sentence of this paragraph will start something like "If the underlying data transfer protocol could not be instantiated, the DMI implementation...". I also wonder if the use of the idea that this fault is associated with instantiating the transfer protocol is correct. Is it the case that the error will always manifest itself when the DTI attempts to instantiate the transfer protocol? Are there cases where the error will only be detected when an attempt is made to move the first set of bytes? I would also observe that this proposal is essentially the same as that which I proposed on 8 November, differing only in that the modified DEPRs are "MAY" and not "MUST". Allen Luniewski IBM WebSphere Cross Brand Services IBM Silicon Valley Laboratory 555 Bailey Ave. San Jose, CA 95141 408-463-2255 408-930-1844 (mobile) Michel Drescher <Michel.Drescher@ uk.fujitsu.com> To Sent by: OGSA-DMI <ogsa-dmi-wg@ogf.org> ogsa-dmi-wg-bounc cc es@ogf.org Subject [ogsa-dmi-wg] Proposal on fault 11/29/2007 08:59 communication for the DTI AM Folks, please find attached my proposal on how DMI could model the fault communication for the DTI. I deliberately did not fully write the proposal as a finished text for the specification. I first wanted to make clear why I designed the proposal as it is. If we agree to go ahead with whatever solution, we then still can add the solution to the spec, and bang our heads together on the words. :) Cheers, Michel [attachment "DTI-Fault-Proposal.doc" deleted by Allen Luniewski/Almaden/IBM] [attachment "PGP.sig" deleted by Allen Luniewski/Almaden/IBM] -- ogsa-dmi-wg mailing list ogsa-dmi-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-dmi-wg
These refinements on the proposal seem fine. If we need to extend this to other failure cases we now have a mechanism we can use. Steven From: ogsa-dmi-wg-bounces@ogf.org [mailto:ogsa-dmi-wg-bounces@ogf.org] On Behalf Of Allen Luniewski Sent: Thursday, November 29, 2007 9:21 AM To: Michel.Drescher@uk.fujitsu.com; OGSA-DMI Subject: Re: [ogsa-dmi-wg] Proposal on fault communication for the DTI With one minor suggested change, I think that Michel's proposal is acceptable. The one exception is on page 3. The last paragraph before the box with the XML in it is too weak. The "must" in line 2 should be "MUST". IN the text placed into the actual DMI spec, I assume that the first sentence of this paragraph will start something like "If the underlying data transfer protocol could not be instantiated, the DMI implementation...". I also wonder if the use of the idea that this fault is associated with instantiating the transfer protocol is correct. Is it the case that the error will always manifest itself when the DTI attempts to instantiate the transfer protocol? Are there cases where the error will only be detected when an attempt is made to move the first set of bytes? I would also observe that this proposal is essentially the same as that which I proposed on 8 November, differing only in that the modified DEPRs are "MAY" and not "MUST". Allen Luniewski IBM WebSphere Cross Brand Services IBM Silicon Valley Laboratory 555 Bailey Ave. San Jose, CA 95141 408-463-2255 408-930-1844 (mobile) [cid:image001.gif@01C832D7.9A00F2D0]Michel Drescher <Michel.Drescher@uk.fujitsu.com> Michel Drescher <Michel.Drescher@uk.fujitsu.com> Sent by: ogsa-dmi-wg-bounces@ogf.org 11/29/2007 08:59 AM To OGSA-DMI <ogsa-dmi-wg@ogf.org> cc Subject [ogsa-dmi-wg] Proposal on fault communication for the DTI Folks, please find attached my proposal on how DMI could model the fault communication for the DTI. I deliberately did not fully write the proposal as a finished text for the specification. I first wanted to make clear why I designed the proposal as it is. If we agree to go ahead with whatever solution, we then still can add the solution to the spec, and bang our heads together on the words. :) Cheers, Michel [attachment "DTI-Fault-Proposal.doc" deleted by Allen Luniewski/Almaden/IBM] [attachment "PGP.sig" deleted by Allen Luniewski/Almaden/IBM] -- ogsa-dmi-wg mailing list ogsa-dmi-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-dmi-wg
Hi, Overall I'm ok with this too but I shared the sentiment that Allen expressed:
I also wonder if the use of the idea that this fault is associated with instantiating the transfer protocol is correct. Is it the case that the error will always manifest itself when the DTI attempts to instantiate the transfer protocol? Are there cases where the error will only be detected when an attempt is made to move the first set of bytes?
Although, I can't think of specific use case my concern would be if there were some systematic effect that caused a transfer to terminate at some point during its transmission and repeated usage of the same protocol might lead to the same failure - do we already cater for this? else it might be good to promote the proposed fault to be more generic (possibly change the name TransferProtocolNotInstantiatableFault too) otherwise I'm fine ... Mario +-----------------------------------------------------------------------+ |Mario Antonioletti:EPCC,JCMB,The King's Buildings,Edinburgh EH9 3JZ. | |Tel:0131 650 5141|mario@epcc.ed.ac.uk|http://www.epcc.ed.ac.uk/~mario/ | +-----------------------------------------------------------------------+
Folks, as per yesterday's conf call I took the pen and updated the functional specification with the consented proposal on fault communication for the DTI (agreed changes included). The resulting new version of the functional specification is up on GridForge: https://forge.gridforum.org/sf/go/doc14200?nav=1 Some remarks: As opposed to the proposal document, I separated the definition of the dmi:Status element from the fault definition that would be conveyed in the new dmi:Detail section. The reason being for clarity in the specification that the usual, expected flow of DTI lifecycle would not require the use of faults at all, and that only unexpected (hopefully) rare occasions would need faults. Also, faults keep being collected and specified in one place, being section 5.3 in the current specification. I hence release the pen. Cheers, Michel On 5 Dec 2007, at 13:17, Mario Antonioletti wrote:
Hi, Overall I'm ok with this too but I shared the sentiment that Allen expressed:
I also wonder if the use of the idea that this fault is associated with instantiating the transfer protocol is correct. Is it the case that the error will always manifest itself when the DTI attempts to instantiate the transfer protocol? Are there cases where the error will only be detected when an attempt is made to move the first set of bytes?
Although, I can't think of specific use case my concern would be if there were some systematic effect that caused a transfer to terminate at some point during its transmission and repeated usage of the same protocol might lead to the same failure - do we already cater for this? else it might be good to promote the proposed fault to be more generic (possibly change the name TransferProtocolNotInstantiatableFault too) otherwise I'm fine ...
Mario
+--------------------------------------------------------------------- --+ |Mario Antonioletti:EPCC,JCMB,The King's Buildings,Edinburgh EH9 3JZ. | |Tel:0131 650 5141|mario@epcc.ed.ac.uk|http://www.epcc.ed.ac.uk/ ~mario/ | +--------------------------------------------------------------------- --+
Hi,
As opposed to the proposal document, I separated the definition of the dmi:Status element from the fault definition that would be conveyed in the new dmi:Detail section. The reason being for clarity in the specification that the usual, expected flow of DTI lifecycle would not require the use of faults at all, and that only unexpected (hopefully) rare occasions would need faults. Also, faults keep being collected and specified in one place, being section 5.3 in the current specification.
Does all this mean that the WSDL on GridForge is now out of alignment with the spec. Would it be worthwhile using the Source Code section on Grid Forge to modify this? No idea how it works but it might allow distribution of the maintenance of the WSDL and Schema - thoughts? Mario +-----------------------------------------------------------------------+ |Mario Antonioletti:EPCC,JCMB,The King's Buildings,Edinburgh EH9 3JZ. | |Tel:0131 650 5141|mario@epcc.ed.ac.uk|http://www.epcc.ed.ac.uk/~mario/ | +-----------------------------------------------------------------------+
Mario, though I didn't check it, I would expect the WSDL to be out of sync. Last time I tested the source code section it didn't work even though I requested a repository. But that's a long time ago, and it might work now. On the other hand, I wonder whether this is a feature OGF should offer, as software development is certainly not the main focus of OGF - and versioning the files using the document area is good enough, I think. Cheers, Michel On 6 Dec 2007, at 09:13, Mario Antonioletti wrote:
Hi,
As opposed to the proposal document, I separated the definition of the dmi:Status element from the fault definition that would be conveyed in the new dmi:Detail section. The reason being for clarity in the specification that the usual, expected flow of DTI lifecycle would not require the use of faults at all, and that only unexpected (hopefully) rare occasions would need faults. Also, faults keep being collected and specified in one place, being section 5.3 in the current specification.
Does all this mean that the WSDL on GridForge is now out of alignment with the spec. Would it be worthwhile using the Source Code section on Grid Forge to modify this? No idea how it works but it might allow distribution of the maintenance of the WSDL and Schema - thoughts?
Mario
+--------------------------------------------------------------------- --+ |Mario Antonioletti:EPCC,JCMB,The King's Buildings,Edinburgh EH9 3JZ. | |Tel:0131 650 5141|mario@epcc.ed.ac.uk|http://www.epcc.ed.ac.uk/ ~mario/ | +--------------------------------------------------------------------- --+
Hi,
Last time I tested the source code section it didn't work even though I requested a repository. But that's a long time ago, and it might work now. On the other hand, I wonder whether this is a feature OGF should offer, as software development is certainly not the main focus of OGF - and versioning the files using the document area is good enough, I think.
Just thought that would provide a way of keeping the WSDL up to date in a public manner. I would agree with you that it should not be a code repository but the WSDL is our interface definitions so I would view that differently and whoever chaned the spec with an effect on the WSDL or schema could then make the appropriate WSDL/Schema files without burdening any single one person, you for instance :) ... I think it would be worth trying out but if the majority of folks are not in favour then I'll let the matter rest ... Mario +-----------------------------------------------------------------------+ |Mario Antonioletti:EPCC,JCMB,The King's Buildings,Edinburgh EH9 3JZ. | |Tel:0131 650 5141|mario@epcc.ed.ac.uk|http://www.epcc.ed.ac.uk/~mario/ | +-----------------------------------------------------------------------+
participants (4)
-
Allen Luniewski -
Mario Antonioletti -
Michel Drescher -
Steven Newhouse