September 2006 - ogsa-hpcp-wg

wsdl/xsd modifications for BES v26
by Glenn Wasson 30 Sep '06

30 Sep '06

Hello, As part of the HPC Profile interop work, I have been trying to process the BES v26 WSDL through my tooling (Microsoft's wsdl.exe). I have found a number of problems with the BES-Factory wsdl and xsd that appears in the appendix of the BES document. Some of these issues are simple typos and some require re-formulations of the wsdl/xsd in order to work with the tooling. I have attached modified versions of both the wsdl and xsd for bes-factory and, below, I have provided a summary of the changes. I contend that these changes (apart from fixing typos) don't actually change the defined interface/data types - they are merely an alternate way of expressing the same ideas using wsdl/xsd that (at least my) tooling can handle. I am interested in: a) comments on this reformulation b) whether anyone else, who is using different tools, has had similar (or different) issues with the wsdl/xsd in the BES v26 appendix c) whether anyone using different tools encounters issues processing the attached wsdl/xsd d) whether people participating in the HPCP interop work are willing to use the attached wsdl/xsd Glenn Summary of changes: 1. bes-factory wsdl (appendix E) and bes-factory xsd (appendix B) both have <xsd:schema> elements with the same target namespace - moved schema types from bes-factory.wsdl to bes-factory.xsd - changed <schema> element in bes-factory.wsdl to only import bes- factory.xsd (other imports seemed to create problems because the same schemas were also imported in the bes-factory.xsd file) - changed target namespace of <xsd:schema> element in bes-factory.wsdl to http://schemas.ggf.org/bes/2006/08/bes-factory/WSDL (added the /WSDL) - This doesn't effect anything since no types are defined in the bes- factory.wsdl's <xsd:schema>, but was necessary to prevent the namespace collision 2. the operation "ResponseType" elements are multiply defined - both the wsdl and xsd define <xsd:element>s for, for example, CreateActivityResponse (the definitions differ only in the name of an outer element wrapper) - kept the definition with the outer element wrapper around the type (i.e. <Response> as the outer element) - moved this definition to bes-factory.xsd and simply reference it from bes-factory.wsdl 3. typos in the types of the response elements for several operations - GetActivityStatusesResponse, TerminateActivitiesResponse, GetActivityDocumentsResponse should be of types GetActivityStatusesResponseType, TerminateActivitiesResponseType, GetActivityDocumentsResponseType respectively 4. added minOccurs and maxOccurs to the GetAttributesDocument related classes - spec seems undecided here

4 6

SC06 Interop Demo Conf Call
by Richard Ciapala 28 Sep '06

28 Sep '06

When: Occurs every Friday effective 9/22/2006 until 11/30/2006 from 8:00 AM to 9:30 AM (GMT-08:00) Pacific Time (US & Canada); Tijuana. Where: Conf Call *~*~*~*~*~*~*~*~*~* Updating to agreed upon time... Weekly conf call to discuss SC06 interop demo status and issues. Toll Free Number: 866-500-6738 International: 1-203-480-8000 Passcode: 231867 Thanks

1 0

Faults in BES v26 WSDL
by Glenn Wasson 28 Sep '06

28 Sep '06

Hello, I've been trying to push the WSDL/XSD in the appendices of the BES v26 document through my tooling and I have found an issue with the fault messages. The XSD for the BES-Factory defines 3 fault types (NotAcceptingNewActivitiesFaultType, UnsupportedJSDLVersionFaultType, and UnsupportedFeatureFaultType) as extensions of the base type SOAP Fault (there is a typo here, but what I believe is intended is for these types to derive from the Fault type defined in http://www.w3.org/2003/05/soap-envelope) However, I believe that SOAP faults cannot be used as a base type (i.e. other types cannot derive from Fault). Certainly my tooling (Microsoft's WSDL.exe for .NET 2.0.50727.42) will not allow this definition. The definition of the Fault type in http://www.w3.org/2003/05/soap-envelope is: <xs:complexType name="Fault" final="extension">, which I believe means no complex type can be derived from this. So, I have two separate, but related questions (it would be nice if they had the same answer, but they don't have to). 1. How should groups building HPC Profile-compliant services address this? 2. How should the BES wg address this? For #1, I have removed the fault type definitions. Groups implementing HPCP services should comment on ogsa-hpcp-wg about whether this is acceptable. For #2, it seems that BES has a couple of options. The first is to change the xsd so that the faults do not derive from SOAP fault (without returning to WSRF BaseFaults, which I believe were recently removed from the wsdl/xsd). The second option would be to establish a "best practice" on how fault types defined by BES should be included in normal SOAP faults (for example, they could be serialized into the <Detail> element). Comments/suggestions? Glenn

1 0

WSDL and schema files
by Christopher Smith 26 Sep '06

26 Sep '06

Hey there, Does anybody have the WSDL and schema files corresponding to the latest BES spec? I've attached the HPCProfileApplication schema, so you don't have to extract it from the appendix in the specification. -- Chris

1 0

New version of HPC Profile Application extension
by Christopher Smith 26 Sep '06

26 Sep '06

Hi all, I've uploaded a new draft of the HPC Profile Application extension ... this time to the JSDL-WG gridforge site. I've made changes to the document according to resolved issues, and then added some text to address the path name syntax issues. Those I have left as version tracked changes in the document so that people can easily see the additions and review them. Todo: - add normative schema in appendix - any format beautification to reflect OGF doc formats -- Chris

1 1

Re: [ogsa-hpcp-wg] [Fwd: SC06 Demo Kickoff]
by Dave Berry 25 Sep '06

25 Sep '06

Would someone care to fill me in on these plans for an SC06 demo? Dave. -----Original Message----- From: ogsa-hpcp-wg-bounces(a)ogf.org [mailto:ogsa-hpcp-wg-bounces@ogf.org] On Behalf Of Peter G. Lane Sent: 22 September 2006 18:50 To: 'Mailing List for OGSA-HPCP-WG' Subject: [ogsa-hpcp-wg] [Fwd: SC06 Demo Kickoff]

3 2

[SC2006 Demo] informal minutes from friday's OGSA HPC Profile SC 2006 interop minutes
by Marty Humphrey 25 Sep '06

25 Sep '06

Folks, These are off the top of my head, so apologies if I miss anything/anyone. Attendees: Marty Humphrey, UVA; Glenn Wasson, UVA; Duane Merrill, UVA; Mark Morgan, UVA; Dave Snelling, Fujitsu; Chris Smith, Platform; Rich Ciapala, Microsoft; Peter Lane, Globus We first agreed that this mailing list (OGSA HPC Profile) would be used for communications regarding the demo and/or interop in general. No separate mailing list is warranted. We then agreed that we would move this call FROM Fri 2pm EDT to Fri 11am EDT from this point forward, to better support our colleagues from Europe (note: as of now, we don't have any Asian-Pacific participants, who might feel a negative impact from moving this call). Topic 1: Security. After a good discussion, we decided that everyone would implement "WS-Security Username Profile (plaintext)", server-only-authentication HTTPS, and maybe client-side certificates if time permits. Consensus was that this is an excellent and pragmatic choice. We did not directly discuss authorization because of lack of time on this call. Topic 2: WS-Addressing. We agreed to use the W3C recommendation: 2005-08 namespace. This is a good forward-looking choice, and spreads the pain around fairly evenly. Topic 3: Deliverables and testing. We agreed that we would keep a web page to keep track of progress. The URL is: http://www.cs.virginia.edu/~humphrey/SC2006.htm This page will ULTIMATELY (soon?) become password-protected. The current content just captures the general flow of the process and information for the SC 2006 demo. This page content and style will be refined in the coming weeks. This version right now reflects the nuts-and-bolts" nature of the immediate job before us; the final version of the demo is the subject of future calls. Everyone agreed that this was an excellent and very productive kick-off meeting! Additional participants are greatly encouraged to participate. Please contact me directly or submit email to the mailing list. -- Marty Marty Humphrey Assistant Professor Department of Computer Science University of Virginia

3 3

[Fwd: SC06 Demo Kickoff]
by Peter G. Lane 22 Sep '06

22 Sep '06

1 0

SC06 Demo Kickoff
by Peter G. Lane 22 Sep '06

22 Sep '06

Forwarded from private emails... [From: Marty Humphrey <humphrey(a)cs.virginia.edu>] > Toll Free Number: 866-500-6738 > International: 1-203-480-8000 > Passcode: 231867 > > 2pm EDT today > [From: David Snelling <David.Snelling(a)UI.Fujitsu.com>] > Now to the point: There has been some chat about security among some of us. I will try to summarize what the options are and we can discuss them on a call. > > 1) No security: We use basics http without any protection. This would work fin in a closed setting, but interops work much better when we can test them remotely before hand. Not all of us will be allowed to publish unprotected endpoints. > > FLE View: We can do this, but only with the client also on the phone. Not a preferred option. > > 2) Use Mutually Authenticated HTTPS: This is effectively the "OGSA Basic Security Profile 1.0 - Secure Channel" specification. It assumes that both client and service have the root CA cert of the other's certificate. This is used to set up the SSL connection and the identity extracted from connection and used for authorization and account mapping. I believe this can be made to work with primary certs or with proxy certs. > > FLE View: This is our preferred option (with primary certs, but I think we can make proxies work with some effort). > > 3) WS-Security User Name Profile: As I understand it this encodes a user name (and possibly password) in a SOAP header element. The underlying transport is assumed to be HTTPS, because I don't believe that the message itself is encrypted. > > FLE View: We don't implement this at present and have no plans to do so. User names are not very Grid-like and so not on our roadmap. > > 4) WS-Security X.509 Profile: As I understand it this encodes the user's X.509 certificate in a SOAP header element. As above, the underlying transport is assumed to be HTTPS, and the message is not encrypted, although this is possible within this profile. This actual profile is very complicated and we would need to define very carefully which parts of it's many optional bits we use. > > FLE View: We don't implement this at present, but would be willing to do so. However, this would put our participation at risk depending on how complicated a profile the group chooses and how soon we decide. > > I look forward to a call. > -- > Take care: > > Dr. David Snelling < David . Snelling . UK . Fujitsu . com > > Fujitsu Laboratories of Europe > Hayes Park Central > Hayes End Road > Hayes, Middlesex UB4 8FE > > +44-208-606-4649 (Office) > +44-208-606-4539 (Fax) > +44-7768-807526 (Mobile)

1 0

Proposed rephrasing of the restriction on BES vector operations in the HPC Profile
by Marvin Theimer 18 Sep '06

18 Sep '06

Hi; As you may recall from the discussions at the Tokyo GGF conference, it was agreed that the HPC Profile base case would be kept as simple as possible in order to make it as easy as possible to create a compliant BES service (and to forestall feature creep). Among other things, that meant that we agreed upon requiring the HPC Profile-compliant BES services would only be required to support BES vector operations of length 1. But of course we'd like to allow compliant BES services to support vectors of length greater than 1 if they so desire (which we expect to be the common case). Enclosed is a rewording of the paragraph in section 4 of the HPC Profile specification draft that restricts vector lengths of BES operations. I've rewritten it to clarify that vector lengths greater than 1 are allowed but may result in a fault. Please let me know if you would like additional rewording to occur. If I don't hear any rewording suggestions in the next few days then I'll go ahead and insert the rewording shown into the HPC Profile document. Reworded paragraph: The BES GetActivitiesStatus, TerminateActivities, and GetJSDLDocuments operations include a vector input parameter that specifies the set of activities that the operation should be applied to. A Compliant system MUST be prepared to support a vector length of 1. A Compliant system SHOULD support input vector lengths greater than 1 but MAY return a Not_Supported fault in response to input vector lengths greater than 1. Thanks, Marvin.

5 5