[ogsa-wg] RE: [ogsa-bes-wg] Create a revised BES spec draft that reflects the decisions of the July F2F mtg
Marvin Theimer
theimer at microsoft.com
Tue Aug 29 20:02:53 CDT 2006
Hi;
Apologies for replying to this email thread so late.
At the BES telecon call last week we decided to not require WS-BaseFaults in the BES specification. As Tom Maguire pointed out in his emails (below), there are issues with requiring that only WS-BF faults be returned, including that one must be prepared to accept non WS-BF faults from intermediaries in any case. I had made a statement in email and on telecon calls that people I had queried at Microsoft had also raised various concerns related to tooling. Included below is part of an email from a colleague that sheds a bit more light on the issues that have people concerned.
Here is my quick skim through:
Main goal of the spec is to introduce base type for detail element of the fault
1) Not clear what value base fault type provides over SOAP 1.2 Fault , except for d)
a. Originator EPR:
i. Originator EPR is always known via Addressing facilities.
ii. Mix in of infrastructure details into application message parts: application may not know what it's EPR is.
b. ErrorCode:
i. Limited duplicate of SOAP1.2 fault codes and sub-codes. Uri associated with fault should be represented by the wsa:Action
c. Description:
i. duplicates SOAP 1.2 Fault reason
d. FaultCause:
i. this is the only valuable piece IMHO - common representation of nested exceptions.
ii. This can be provided by using open content model for SOAP1.2 Fault detail .
2) Child elements of Base fault are not namespace qualified - this leads to known threats of having unqualified elements. Does not map to DataContract.
3) Should not require name='fault' on the message - there is no need for this and this blocks existing WSDL-generators.
4) Folks need to define Action uris for individual fault messages, since Addressing is assumed to be used.
Our WSDLs generated by default for Faults will not adhere to 2 and 3.
Points 2 and 3 are the key issues:
* Point 2 implies a security issue and I'm leery about introducing anything that even hints of a security problem.
* Point 2 also references the fact that Microsoft (and others') tooling is headed in the direction of generating (and analyzing) contracts over web service protocols. Making a web service protocol into a statically analyzable contract implies that you either explicitly expose all the possible nested fault details - implying that you've tightly coupled things and made them brittle with respect to internal service behaviors that might change over time - or that you have protocol content that can't be determined until runtime.
* Point 3 is a good example of WS-BF breaking the tooling.
Marvin.
________________________________
From: Maguire_Tom at emc.com [mailto:Maguire_Tom at emc.com]
Sent: Monday, August 21, 2006 12:44 PM
To: Maguire_Tom at emc.com; foster at mcs.anl.gov; Marvin Theimer; ogsa-bes-wg at ggf.org; ogsa-wg at ggf.org
Subject: RE: [ogsa-bes-wg] Create a revised BES spec draft that reflects the decisions of the July F2F mtg
As an aside I am not quite sure how BaseFaults breaks tooling. The BaseFault element is carried as an extensibility item in the s11:detail or s12:Detail elements. Isn't that what these items were designed for??
Tom
_______________________________________________
Tom Maguire
+1(845) 729-4806
________________________________
From: owner-ogsa-bes-wg at ggf.org [mailto:owner-ogsa-bes-wg at ggf.org] On Behalf Of Maguire_Tom at emc.com
Sent: Monday, August 21, 2006 3:30 PM
To: foster at mcs.anl.gov; theimer at microsoft.com; ogsa-bes-wg at ggf.org; ogsa-wg at ggf.org
Subject: RE: [ogsa-bes-wg] Create a revised BES spec draft that reflects the decisions of the July F2F mtg
Apologies for the cross post but some of this discussion is relevant to the OGSA-WG
I would agree that WS-BaseFaults are not required for BES. In WS-ResourceProperties the use of BaseFaults is optional (SHOULD). The OGSA Basic Profile for WSRF has mandatory (MUST) use of BaseFaults for WS-Resources.
7.1.1 BaseFault Structure
R0711 A MESSAGE for a fault from a WS-Resource MUST conform to the structure specified in Web Services Base Faults Section 2, "Base Fault Type."
As I re-read this section it is not nearly clear enough about the scope of 'WS-Resource'ness. I could interpret this requirement several ways:
* ALL faults from a WS-Resource MUST be extensions of BaseFaults
* ALL faults from a WS-Resource based portType MUST be extensions of BaseFaults
* ALL faults from a WS-Resource base portType that match the semantics of existing BaseFaults MUST use the BaseFault extension type that is defined for that portType (basically what this does is turn the SHOULD in WSRF specs for faults into MUSTs)
Clearly, point 1 is a non-starter; no implementation will be able to guarantee that all faults are extension of BaseFaults. Point 2 is also extremely difficult as there are significant numbers of interceptors between the consumer and the provider implementation all of which are likely to not fault with WS-BaseFaults. Which leads us to point 3, I think this is the only reasonable interpretation of the requirement; that faults that are defined in WSRF specs MUST be used (as opposed to the SHOULD requirement in WSRF).
Perhaps we should clarify this requirement in the Basic Profile.
w.r.t the subject at hand I think that any consumer will need to deal both SOAP faults and BaseFaults and as such I don't see much of a need to fuss about the fault definitions in BES. I do however, agree with Ian that there is value in having a common base type for faults.
Tom
_______________________________________________
Tom Maguire
+1(845) 729-4806
________________________________
From: owner-ogsa-bes-wg at ggf.org [mailto:owner-ogsa-bes-wg at ggf.org] On Behalf Of Ian Foster
Sent: Friday, August 18, 2006 11:27 AM
To: Marvin Theimer; ogsa-bes-wg at ggf.org
Subject: RE: [ogsa-bes-wg] Create a revised BES spec draft that reflects the decisions of the July F2F mtg
Marvin:
David's proposal, which is realized in the current draft, is that we define BES to just have "GetStatus" and "GetProperties" operations (as well as CreateActivity etc.). We can then compose WS-Transfer operations or WSRF operations, if desired, in a particular BES implementation.
This seems to me to be a really nice solution to the "problem" that we thought we had, in that it avoids the need for multiple renderings.
The one tricky issue is the rendering of faults. In the current BES document, we use WS-BaseFaults. You report that the Microsoft WS team has problems with that. I don't think we should let this be a show stopper, as I don't think it is essential that we use WS-BaseFaults in BES. At the same time, WS-BaseFaults was introduced for a reason. Thus I'd like to propose that we proceed as follows:
a) We set up a phone call with the Microsoft WS team and the WS-BaseFaults guys to talk this over, in case it turns out that we can in fact all agree that WS-BaseFaults is useful.
b) In the (likely) case that the Microsoft WS team still doesn't want to see WS-BaseFaults included, we check with the BES team that it is ok to use a different fault model for the BES core vs. the specs that might be composed with the BES core, such as WSRF.
Thoughts?
Ian.
At 05:17 PM 8/16/2006 -0700, Marvin Theimer wrote:
Hi;
Another comment/question on Dave Snellings proposal: I dont really understand how it avoids distinct renderings since it is still the case that we have at least 3 different WSDLs, one per rendering option:
* WSRF version that employs WS-ResourceProperties, etc.
* WS-Transfer version that employs WS-Transfer, etc.
* Resource model-free version that employs an explicit QueryStatus operation (and potentially additional QueryFoo operations).
It is certainly the case that there is a coreset of operations that is common to all 3 interface choices and we should certainly write the spec that way. But dont we still end up with 3 different rendering versions?
Marvin.
________________________________
From: Ian Foster [mailto:foster at mcs.anl.gov]
Sent: Friday, August 04, 2006 2:20 PM
To: Marvin Theimer; ogsa-bes-wg at ggf.org
Subject: Re: [ogsa-bes-wg] Create a revised BES spec draft that reflects the decisions of the July F2F mtg
Marvin:
I've claimed the pen on the document, but have been finding it hard to find time to make a lot of progress. I will try to do some work on it tomorrow morning.
That said, I want to mention an important development that Dave Snelling may or may not have mentioned on calls. Dave argues that we can avoid the need for distinct renderings by defining our interfaces carefully. The basic idea, as I understand it, is that:
a) the "core interface" has the basic operations for creating jobs, modifying their status, etc., and an operation for grabbing all of the factory state;
b) then, if desired, a WSRF service (for example) can also implement the WS-ResourceProperties, WS-ResourceLifetime, WS-BaseNotification, operations;
c) while a WS-Resource service would implement the WS-Resource equivalents of those.
So we exploit the power of interface composition to avoid the need for separate bindings.
The only problematic issue, as I understand it, is that of faults. The question is how we render faults. The WSRF binding must (by the spec) use WS-BaseFaults. If we can all agree to use that, then we are ok. If not, then we still have problems.
Ian.
At 01:29 PM 8/4/2006 -0700, Marvin Theimer wrote:
x-ms-exchange-organization-recipient-p2-type: To
Content-Type: text/plain; charset="us-ascii"
Hi;
The HPC Profile (HPCP) work depends critically on BES. The recent face-to-face meeting at Argonne made substantial progress in terms of reshaping the proposed BES specification in a way that would make it suitable for supporting the HPCP on top of it. Are there plans to generate a new revision of the BES specification draft in the near future? As soon as the revised version comes into existence we'll be able to seriously start doing the actual HPCP work (which will take place on the hpcp-ogsa-wg mailing list and in weekly telecom calls that will be starting shortly).
Since the HPCP WG is effectively gated on this revised spec, having a draft of a revised spec sometime in the next week or so would be really helpful. I would be willing to help rewrite the BES spec if that would be useful to the BES WG.
Marvin.
_______________________________________________________________
Ian Foster, Director, Computation Institute
Argonne National Laboratory & University of Chicago
Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439
Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637
Tel: +1 630 252 4619. Web: www.ci.uchicago.edu<http://www.ci.uchicago.edu/>.
Globus Alliance: www.globus.org<http://www.globus.org/>.
_______________________________________________________________
Ian Foster -- Weblog: http://ianfoster.typepad.com<http://ianfoster.typepad.com/>
Computation Institute: www.ci.uchicago.edu<http://www.ci.uchicago.edu/> & www.ci.anl.gov<http://www.ci.anl.gov/>
Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439
Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637
Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org<http://www.globus.org/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20060829/e0062b91/attachment.html
More information about the ogsa-wg
mailing list