Unfortunately I won't be able to make this call. But I'll toss a few
thoughts into the fray...
I don't know that I see compelling functionality reasons to be move
to the final WSRF specifications. So I think any moves, and the
details of such moves, should be motivated by compatibility and
interoperability, both present and future. It sounds like the big
issue from that perspective is WS-Addressing -- I think it makes
sense to move to the final version that everyone else is implementing.
Of course, in moving to WS-Addressing, we're going to break
compatibility. So then the question is what else should we consider
changing at the same time, in order to improve our interoperability
situation and/or position ourselves better for the future? Moving
the final WSRF specs probably makes sense from this perspective.
My bigger concern, though, is the whole WSRF vs WS-Man morass.
Recall that last August IBM, HP, Intel, Microsoft and others
reconciled on a converged set of specifications (e.g. WS-
ResourceTransfer, etc). Now, I am NOT advocating that we immediately
move to that set of specifications. I fully expect that these specs
are going to change a few more times before they finally settle down,
and I don't think it makes sense to chase a moving target. However,
I also believe we are going to need to support these new specs at
some point down the road. So I think a key question is what can we
do to position ourselves so that we incrementally add support for WS-
Transfer, WS-ResourceTransfer, WS-Eventing, WS-EventNotification,
etc. in the future, without breaking backward compatibility again?
One definite concern is WS-BaseFaults. Last fall in the OSGF BES HPC
profile discussion, Microsoft stated that they won't use WS-
Post by Rachana Ananthakrishnan-------------------------
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)
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.
i. Limited duplicate of SOAP1.2 fault codes and sub-codes.
Uri associated with fault should be represented by the wsa:Action
i. duplicates SOAP 1.2 Fault reason
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.
-----------------------------
Right or wrong, there is resistance to WS-BaseFaults, and they are
not likely to end up in whatever converged WSRF/WS-Man spec
eventually makes it into the world. So perhaps we should stop using
WS-BaseFaults now for all of our own operations in Globus, and only
continue to use them for the WSRF operations that require it. There
is alternative pattern for passing faults that is used in the various
Microsoft/IBM WS-* specs, so perhaps we should move to that pattern
for the non-WSRF operations in services like WS-GRAM, RFT, etc. Can
we make changes to the Java and C WS Core runtimes to make it easy to
program to either pattern?
More generally, what if somebody wants to write a client to, for
example, WS-GRAM using some other WS client tooling, and does not
(for whatever reason) want to use any of the WSRF operations
(particularly WSRP query and WSN subscribe). Is there a straight-
forward thing we can do to make this straight-forward, perhaps with
reduced functionality? Removing the use of WS-BaseFault in WS-GRAM
operations would be one step. Another might be to make it easy to
add individual RP get operations, and maybe support the WS-Transfer
full RP document get. This would allow a client that wants to use
WSRF to get full functionality vis WSRP query, WSN subscriptions,
etc. But a client that does not want to use WSRF can get reduced
functionality by using the individual getters, and full-document
get. And then we should be able to add all the other WS-Man specs as
additional operations, without breaking backward compatibility.
I know I'm doing some hand waving here, and would be happy to talk
about this more in person or on a call. Unfortunately I just can't
make this morning's call.
-Steve
Post by Rachana AnanthakrishnanHi GT-users,
Just a reminder that we will be having a call to discuss the
proposed core technology upgrade. There will be a short
presentation from the Core Tiger team followed by discussion
concerning requirements, desires, and thoughts from the larger
community.
Please join us, your input is crucial to the future of GT!
Dan
----- Original Message -----
From: Dan Fraser
Sent: Wednesday, May 09, 2007 6:22 PM
Subject: [gt-user] Fw: Core options writeup
Thank you for your responses to the Core technologies so far. There
seems to be a lot of interest in Axis 2, as well as the upgraded
specs, and we certainly are interested in hearing more from the
community. We are planning a call on Monday to discuss this further
11am chicago time, May 14
1-712-580-8020
Participant Access Code 26738
We look forward to hearing from you on Monday!
Dan
----- Original Message -----
From: Dan Fraser
Sent: Tuesday, May 01, 2007 3:27 PM
Subject: Fw: Core options writeup
Hi GT-users,
The CDIGS team is currently evaluating whether we need to update
the Java WS Core and C WS Core at this time to conform to the final
version of the WSRF specifications. Depending on the implementation
model, this could increase both the support and implementation
complexity of the toolkit. We would like to have some email
discussion on this topic to understand what your requirements are
and determine the best course to pursue.
Joe, Rachana, Charles, and Ravi have been diligently working to put
together the attached document. Please help us understand if the
benefits of upgrading are worth the increased support/
implementation complexity and lack of backward compatability for
our user community.
I would also like to propose a concall meeting on Monday May 14 at
11:00am CT to discuss this further.
Thank you,
Dan