- ogsa-bes-wg - lists.ogf.org

To many 'any' in factory attributes document
by Christopher Smith 18 Oct '06

18 Oct '06

Hi all, I don't know if others are having this issue, but my tooling doesn't like all the xsd:any that show up in the FactoryResourceAttributesDocumentType. The problem is this: BasicFactoryResourceAttributesDocumentType has: - stuff1 - stuff2 - ... - xsd:any Then the FactoryResourceAttributesDocumentType has: - stuff1 (from extension) - stuff2 (from extension) - ... - xsd:any (from extension) - otherstuff1 - otherstuff2 - ... - xsd:any That makes two xsd:any in one complex type, which is one too many in my opinion. Can we perhaps refactor this type? I've also noticed that I can only provide one OperatingSystem, CPUArchitecture, etc, etc, which doesn't allow me to list the elements of my cluster. How about something like: <xsd:complexType name="ResourceAttributesDocumentType"> <xsd:sequence> <xsd:element name="OperatingSystem" type="jsdl:OperatingSystem_Type" minOccurs="0"/> <xsd:element name="CPUArchitecture" type="jsdl:CPUArchitecture_Type" minOccurs="0"/> <xsd:element name="CPUCount" type="xsd:unsignedInt" minOccurs="0"/> <xsd:element name="CPUSpeed" type="xsd:unsignedLong" minOccurs="0"/> <xsd:element name="PhysicalMemory" type="xsd:unsignedLong" minOccurs="0"/> <xsd:element name="VirtualMemory" type="xsd:unsignedLong" minOccurs="0"/> <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="name" type="xsd:string" use="required"/> </xsd:complexType> <xsd:element name="ResourceAttributesDocument" type="ResourceAttributesDocumentType/> <xsd:complexType name="FactoryResourceAttributesDocumentType"> <xsd:complexContent> <xsd:sequence> <xsd:element ref="ResourceAttributesDocument" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="IsAcceptingNewActivities" type="xsd:boolean" minOccurs="1" maxOccurs ="1"/> <xsd:element name="CommonName" type="xsd:string" minOccurs="0" maxOccurs ="1"/> <xsd:element name="LongDescription" type="xsd:string" minOccurs="0" maxOccurs ="1"/> <xsd:element name="TotalNumberOfActivities" type="xsd:unsignedInt" minOccurs="1" maxOccurs ="1"/> <xsd:element name="LocalResourceManagerType" type="xsd:QName"/> <xsd:element name="ActivityReference" type="wsa:EndpointReferenceType" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="ContainedResourceAttributes" type="xsd:anyType" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="NamingProfile" type="xsd:QName" minOccurs="1" maxOccurs ="1"/> <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> Even if we don't refactor like I suggested, we need to control the xsd:any's. -- Chris

3 3

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

[ogsa-wg] Proposed agenda for Oct. 2nd call
by Hiro Kishimoto 29 Sep '06

29 Sep '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on Oct. 2nd Monday from 5pm to 7pm (CDT). The dial-in number for Monday; US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 (0)207 3655269 (London) Japan: +81 (0)3 3570 8225 (Tokyo) PIN: 4371991 See more information: - https://forge.gridforum.org/sf/go/wiki1477?nav=1 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 1002 See more explanation: https://forge.gridforum.org/sf/go/wiki1584?nav=1 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (Sept. 25) - https://forge.gridforum.org/sf/go/doc13903?nav=1 Action Items status review (see the bottom of this email) Agenda bashing 2) Information/data modeling Xquery (Ellen, 30 min) Minutes from GGF18: > generate 3 to 5 queries that might be issued; would like to use as a > starter set for usefulness of XML document and to show how it would > look like in XQuery. 3) Separation of service/info model (Tom, 30 min) Minutes form Sept. 25: > - Another open issue is how does the Information Model work (in > context of DMTF) comes together with the EGA reference model > (dags). > - A possible viewpoint is that the EGA Reference Model is the > overarching model: > - With specific/concrete stuff mapping to CIM > - But some more abstract stuff do not map to CIM easily > - There is some more abstract work in the SMIS space and this > will end up at some point in DMTF schema > - So the DMTF might be an eventual consumer for some of this work > Tom will send a note to the list (to: Ellen S and Fred M) on why the current separation of service/info model may not be quite right. 4) Removal of container model from BES spec appendix (Ellen, 10 min) Ellen's email: > The intent of this appendix is to provide the container model as an > 'informational' appendix so it can be submitted to DMTF as concrete > proposal for inclusion in the DMTF CIM and a context for why a container > model is necessary. > > The inclusion of the model in the BES spec does not imply that OGSA must > implement this CIM container model to implement BES; it is merely an > abstraction for a general container model where BES can provide context > for the need and implementation of a specific container model. If this > point doesn't come across in the appendix text, I have no problem > modifying the text. 5) Wrap up (10 min) AOB <*NEXT CALL*> https://forge.gridforum.org/sf/go/wiki1477?nav=1 Oct. 5 (Thu): Security, secure channel profile review Oct. 9 (Mon): EGA reference model, OGSA roadmap Oct. 12 (Thu): <No call?> Oct. 16 (Mon): Information/data modeling Oct. 19 (Thu): Security, secure channel profile review Oct. 23 (Mon): EGA reference model, OGSA roadmap <*ACTION ITEMS*> https://forge.gridforum.org/sf/go/wiki1569?nav=1 > From Sept. 25 call. AI-0925a: Hiro to setup wiki page with names of people who have expressed interest in the security team AI-092625b: Jem to pull definitions together and produce a new merged first draft. - Send a mail to the ogsa list about this work - Set Oct. 9 as the target for the first Glossary draft AI-0925c: Hiro to ask Alan Clark to ask EGA TC member who want to contribute to join the OGSA list and this convergence work. - Members may have changed but organizations have not AI-0925d: Paul Strong to send EGA Glossary MS-Word file to Jem Treadwell AI-0925e: Hiro to talk with Andrew Grimshaw and Mark Morgan and bring back a concrete proposal for the HPC Profile use case as a convergence candidate. AI-0925f: Hiro to talk with Ellen Stokes and add more items in DMTF register in the context of this convergence work AI-0925g: Tom will send a note to the list (to: Ellen S and Fred M) on why the current separation of service/info model may not be quite right. > From Sept. 21 call. AI-0921b: Security members to discuss the BoF proposal(s) further - For example, one outcome could be some standards activity to mirror CAOPS activities and tie-in to OGSA AI-0921c: Dave S (as Standards VP) to talk to the next Security AD (when one is selected) about the Security Area task list. AI-0921d: Dave S to collect additional material in order to identify security issues better. - (AI-0921e is an issue instance) AI-0921i: Dave S to provide an agenda for the next security call. - Draft agenda items for Oct. 5th: - What needs to be done to achieve simple interop generally and to bootstrap more - Profile to get authentication information from a secure channel for authentication - Profile for other methods to get authentication informatin for authorization > From Sept. 15 OGSA F2F AI-0915a: (A Savva, S McGough): Set up a telephone conference to collect workflow (BPEL) experience AI-0915b: Ellen to check the status of the items on the DMTF work register: report which have been done, and what DMTF is doing for the rest. AI-0915c: Ellen to propose new text to update the DMTF register AI-0915d: Tom will post BP base faults issue to tracker AI-0915e: Hiro to talk with OGF Editor to start an errata process > From Sept. 14 OGSA F2F AI-0914a (Andreas Savva): Integrate the simple Data scenario just presented into the scenarios document AI-0914f (Fred Brisard and Hiro Kishimoto): Fix the location of the next F2F and inform the group vial the mailing list > From GGF18 EMS session (Sept. 13) AI-0913a: Andreas to update function names of BES. AI-0913b: Andrew to write-up a couple of such JM functionalities (short paragraph for each, e.g. time constraint as JSDL extension.) AI-0913c: Andreas to add another scenario to use this “terminate” method of activity interface. AI-0913e: Andreas to separate un-deployment as a separate scenario. AI-0913f: Andreas to describe relation between ACS and CDDLM. AI-0913g: Donal to provide his proposal on "ActivityExecutionCandidate." > From Sept. 7 call AI-0907b: Takuya will search for an external reliable source of strong (or deprecated) ciphers to reference. AI-0907c: Andreas will revise the explanatory text and send the new version to Takuya. AI-0907d: Takuya will update the documents and issue a final call on the list. (Probably during GGF18.) > From Aug. 31 call AI-0831e: (A Savva) Talk to ACS working group for refining this scenario. AI-0831f: (A Savvva) Research RNS and probably update the EMS Arch Scenarios document > From Aug. 17 call AI-0817a: Dave Berry and Jay Unger will approach groups (GIN, Globus, etc) that have implemented practical grids and start a discussion on how they handle data: - how data is treated as a resource that can be scheduled - how transfers are modeled - how files are advertised - how applications find files (query, by knowledge,?) (Due Oct. 9) > From Aug. 3 call AI-0803e: Jun will provide an example of the CDL mechanism and why using ID/IDREF is not a good idea. AI-0803f: Jun will update the CDL document to remove the Environment variables > From July 20 F2F - EGR-WG (Ravi) will contact Geoffrey Fox and invites him to contribute use cases. - Andreas to go through the minutes and formulate a reply mail to Geoffrey on each artifact covered in these minutes. ---- Hiro Kishimoto

1 1

Re: [OGSA-BES-WG] re-evaluate removal of container model from BES spec appendix
by Ian Foster 29 Sep '06

29 Sep '06

I'd like to argue strongly against this. As I said earlier, I think this is good material and I don't have any objection to it being published as an OGSA informational document. I just don't think it belongs in a BES specification, which should contain the minimum information needed to specify BES. Ian. At 09:49 AM 9/27/2006 -0500, Ellen Stokes wrote: >Andrew, > >Per our discussion at the OGSA F2F Sep 14, I'd like the workgroup to >re-evaluate the decision to remove the (general) container model from the >BES specification appendix. > >The intent of this appendix is to provide the container model as an >'informational' appendix so it can be submitted to DMTF as concrete >proposal for inclusion in the DMTF CIM and a context for why a container >model is necessary. > >The inclusion of the model in the BES spec does not imply that OGSA must >implement this CIM container model to implement BES; it is merely an >abstraction for a general container model where BES can provide context >for the need and implementation of a specific container model. If this >point doesn't come across in the appendix text, I have no problem >modifying the text. > >I know the BES calls are generally scheduled for Thursdays; however, I am >not available this Thursday Sep 28. >Let me know when this topic can be scheduled as part of BES workgroup call. > >Ellen > > >Ellen Stokes >STSM, Grid Computing >TC Member, IBM Academy of Technology >Austin, Texas >tl 678 0552 outside +1 512 838 0552 >stokese(a)us.ibm.com >-- > ogsa-bes-wg mailing list > ogsa-bes-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/ogsa-bes-wg _______________________________________________________________ Ian Foster -- Weblog: http://ianfoster.typepad.com Computation Institute: www.ci.uchicago.edu & 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

8 11

Regrets this morning
by Maguire_Tom＠emc.com 28 Sep '06

28 Sep '06

0 *H÷ 010 +0 *H÷ $Content-Type: multipart/mixed; boundary="----=_NextPart_000_00B1_01C6E2DC.8A7A2120" X-MS-TNEF-Correlator: E0B38811FEE2C601 This is a multi-part message in MIME format. ------=_NextPart_000_00B1_01C6E2DC.8A7A2120 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Internal meeting that I MUST attend. Tom _______________________________________________ Tom Maguire Senior Technologist, Office of CTO EMC2 maguire_tom(a)emc.com +1(845) 729-4806 "The only difference between a rut and grave is the depth." - Ralph Waldo Emerson ------=_NextPart_000_00B1_01C6E2DC.8A7A2120 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IhsNAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQOQBgD0FQAAHwAAAAsAHw4BABIAAgH4DwEAAAAQAAAAGTFs0enA QU+TG+xdGMv50gIB+g8BAAAAEAAAAEcAeBfHkKxKr+8LploFF7ADAP4PBQAAAAMADTT9PwUAAwAP NP0/BQACARQ0AQAAABAAAABUlKHAKX8QG6WHCAArKiUXHgD6PwEAAAANAAAATWFndWlyZSwgVG9t AAAAAAsABIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAA0KAwARgAggBgAAAAAAwAAAAAAAAEYA AAAAAYUAAAAAAABAABOACCAGAAAAAADAAAAAAAAARgAAAABghQAAAAjW6CkAAAALABCACCAGAAAA AADAAAAAAAAARgAAAAADhQAAAABibAsABoAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAADt3AwAD gAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAGqACCAGAAAAAADAAAAAAAAARgAAAAAYhQAA AAAAAAsAcIAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABADtmAgEJEAEAAADwEgAA7BIAADUrAABM WkZ12LLsDQcABgEBC2BuZzEwMmY1AGQAcmNwDdAOADIdDGBjDUQBNAExc3Rz4mgFcGJjaBA1CQAQ x2ZoDrAQ1mJpAUMNpDPyMxLmZmUTYgH3AqQDY0cCABDACsBzZXQC0XAocnEyAAAqCqFuby0WICAN 8BdxNhNwMDWcMDQX8QHQF+A0fQdt3RbCZgdABUAHbX0CgwBQ9wPUFc8W22IXsRggF4IeVIcYoAcT GbdoZWx2HIDlDrBhGzQzOBuvHL8dx1cX5B4yGKBWBJBkAHBhdwKDDwIVbTIg4iIyGj4g/ENFGb8a yw4AE5AlfhgQ+yafJ6V5CLEoTylbDhAVbVwxNhuRK48DgkcJ0WvrLQ8pPTYvHzYlUTBvA4JuVAhw Mg8pPTcCABKwZHZpAzYviDc44TVvA4IoyEhlYglwdyk27yk9/yDxOR86JCaPO5YHEAGgDrDrPH8p Ljk/Dzg0AUBfA4J+QkJxDrBCLyk8F8BEPzbXKiFFjzvDVgiQdCTAB4H+ZUIfSD4lUSEsJmgHEyf6 /x/9SRAqIU7dK0dQVSzpUW//LwEhLDAYUFQxvFVPNAFWjv81NlBUNrpZTzjoVo06d1BU/zwPXS8+ iF7eT9xBr2HPRCHfVo1FR1BURt1mbjcLwlad70pmYFVL/2pPZkpQTq8maP8kdSfxb4VSfys4cacs 4G+F/1ZfMBhxpjGzb4VaXzUYcab/NrFvhWd/RThxpkbUb4QYIH97X0pXcaZtmgKAApEI5jv1CW8w gg9lLuGDOi7ihB//hSiDJC7ig6+Hf4c9hr+E7/ODPxQwMjiNCo4hjd+O6f+DJI8SjX+RT5ENkI+O v5KE/jkPIJXUlzGPU5cwAoIQULx5bAeQH/Ah4AAAcQMhHmwSwQUQAUAD8GRjdC5sCrGaEEHAcAEB YXV7TQAAYHMKsJpwIaCbcm5MdW1M0ZswdG8NUWrmdRBQBRBnaJtgBRAKAcuZoAoBaQGQcDADMAAg pmwQwCFxczEDMGEBMf+fgAvwK1AHQA21mYGdQJ70/56Rn9MTJxPoCNAJwD7AodMcbnCiKaPEAzBz bmX+eCHwB7AFsADAAnMW4J8xf56RDWA+0CBAICCk8SHQbU5pEgCmsAnwIESbFCAaUArAYQnAmuBo IEZ3AiGl5BBgMQBQEGADYHcnCzCdQAGAc1c+wHRo3kITkJ1ACrCmsGwN4CDwfatUcqvIDZCrNgGA rTdi/a03cqsxAmALgAmRrzSYsNxwZasxBPAgAGyaIasA+6qhr5FzICAAIEzxqbE8MP+sULH2CVCy FAyxsiOaoLIUfGRnsva0cLP2nwCyFHb/AzCZb5p/m4+cn52vnr+fwv+7kaDduuENtKHEFCKf8aMs /76nwCSk9angpyylhE0gAaD/mNCl56Chpqi7zb0cuEAI0PslIKTxYriACYACIKZimKE7IcA+wDg+ cGLAdXAgSN+wIbLgC4B386YjNsQvxT//xkrHwsdPyFepILCwqkAJgP/I7zpgyh+fFwBRvN8bdAwB 78zfp0oQQMkBcwIgUIEQQNkFoG1wFzLH7kUAwAMQvlOYsjpggTMW4AtgdAnwZxBgmLO2kHNkEFAH cGHeeMQANADaERFRawmAAQEWMKXzgiB2AlEge1XzyVAXIHdu2NXIItwy3VN9JmA0XiHd81pARUHI IzT8NTErUMgi36DfkDUh3fPvSRAO8BOQ4IQ3DxAAUMgi/XVwM9+g4RR1cGdgVkHIIv40DeAN8N8U 3lAB0A8R4/XsNzlEIONDOMigxADdU/sXwBfAOeMkAcDiQEUw5qV+OEAQtsHmwm/glyDlNDjv36BF QN50lzAwAcDpVi7w/+R1DeDnoeOA38QB0ODx37X/6cHiQOEUDvDmQSoR65RrcP+r0N507OAO8Jcg 63XoYWtg3+q1IOAX4Mig7oU5dXAO8P/fxUpQ5ZDs9eIx5oDfFMQA+Dk0N+BV81HIYEQR39P9F8E0 8TD0heJg35D0dUAQ/Y+gM+515RAYEPOQ9sbjAP/2cN/E9zD2cd+16bEXsOz1/+MAXiDy5vgB8RHd 5Bfw8sH/+zflIPCl4bCrwWdh/NTxMP/1EOHE4MAX4t8U5wHp0PXl/SZgN/OA34Dd5OJg5+D+5v/f gOAx37Q4weJB/vXtkeOg/+EV/5AwIANnXiD8Yd3k33D/E4DnNY+g5SBv4N8UF+DlIO/zcOMk5cHf cDLlNOJAMCD/ezAH9Rfh5RDedBOAVkDeUP8GdeJg4mDjAOHU5PEJ0eHU/wAw34Cf8QvV6FEJdeGQ 4PH/DTZ4UeR1IOBFQO2WIODxMv/nRBgg9nCXIuNEF8AH4N50/wfQ/5DfgBG3+lHjJfaB8sH/4zQY IAehEDUYIDAg4FUMMP/zkBfR4+Uu8OcR4+V+IABW/95R8HHkht9y5TXm8AfQAqX/DPLu4eVF/tAu 4hrVONDpAP/lRUAQFgAQNe8gWkD0MB0G/+aA08HIIv7QHAHzgB6FfiD/RBAfNvZh7yUlQGdg6FDf FP8DMNPABiAgtW/gyKAMZQMw//Nwj6AgtSVAI1HhFDPw9RD/6dDlNDjQ+LFiwR6TyKByoP86cSYU IFHsJScRGZHjJEQQ/14gcQAlNeUgojDmhTAgyKH/4FU1IPQw8TDfFH4g4MDzcP/ftH4gIhESZSTh 7OBrceYD/xvy7+VWQBFxKCVaQGtgB9D/4RQEsXaQ9zAvxfox5zX4Ef8BkjFFCpDlAeX09zDmcHER /+azojDs4OnQM4UGIOWh5qT/OmAKkPFlIVHkYeaV44Apkf82duGQMRYAMAlgOmDn9RzR/3mQ5pV2 oJch50Xn4OJg7OX/59FnYAoAOkWksEUw5pUlwf/4Fhyx+lHlNEAQ8TCr0Du1/+Ug6FAAMN8k6dEJ YOf0+wH/b+Dp9fZw46DhkOEUELGr0P/l1SXBJqAlJSXC9DA/dfEg/xYRQPUhETYxRMXIg98kLpH/ P1dWQA5i3yTm8Jcg/5DfJP/n4PgBQnX9URhW5aD3IAkR/98k8TD3IBtlBiH+wPal9zH/9aHftEvy cqBM9+hQ8uX3MP9+IPWx6WSp4GdR4GTvIFox/wBlLTFfsedE7yDpMSvllzD/DDA3oellfiDtUEz1 GnEplv8HEWLABiDpZOMQ7OASZUAR//dA/uU4cQki6WQooQVx6sX/ojAAMHah6tTu8SNRWRbfcf/i ZTwzeZDqtnxQJaHnRKBx/+px5oWgcSaBDGW+gvQhXef//tC+kurUUTFrYl+l08Dg0f9flk5BAGWk sefg4laksAfQ/wexYsd1cFHR6sUk0Ttx6sb/CUJd³Ft9xYmHfxGZiDDDrdf+ksPNwdqBdFangGNHu Zu7x/3hg3wVPoRCxC6Wp4HhgTkH/Z6ZMEfRXxAAKAEDWqeDmYf/94W1mHZEW5W2x8tEKJang//OR LTFm5TthBtFwpnmB83D/cKY8IeUlcpIVIF3WcqE7kf9cRSHxj6BcNmnBIFHsNt+g/wlgHyVZgzSx 64UhIW7X4XL/q8J4BekA+KF5lyagWcZUMf9h0eq1VDFJsXsmFSEe0XzW/8hwdvgZkQqQfZbfkC+B 63b/EBEk8X9G5oBWcYDn58Bvtv/g0QqQB9DtBhsRWPYDEfBy/+3G/rHIcO3GyIFyJo+g90D/8teG 8Sag6/CGlxyihpZacf9y9uex3kF7JvQwTKFgVTQR//7AK+Xu0eiB7OZRMfEgSGX/7tEmYTul7tHx MY6XRGHfgf/uhd+Q+7KQVupwBJGQVidR/1gmRiCCQXFWZCF/ou6F+aD/8tGLZmBA84ByJl2xkBGR Fv/m8PHxk4ZMkkYl8RHzoN5B//DG85BVFvERMmHxZ+ZxZPH/38V1AqSwm7b0UVFlnAH6Mf/rZuJg h+GcZ/9h5ZDxdlXR/2UX9bHpMaCHCiCksPL1AOH/ftGghhIRGcGjBmoA84Dudf8MMPiiWDVmkTog 4xXgEhwB/6ImmPEzIacXB8fx0eOApFH/8YZCUfmmqeIlofGGgjFh5v+kcW3goUfzcBzBm6bmgPZR /54W5oClQaVm4wDwkWBV/tD/UeLudf7QKKEDZZDR47BPof+xpgGhgMaQwQNR8jb9EDDi/7QWCeHy JyEh/IG0FjSxZSb/6qDqYRhlxABzoowmuIFzkf+2duOACVG454FBWpYWsfch/6/2AbFEUfJFMNEQ 4Lz3VRH/buaSYhCxvqYUYXHwvqauAf+YVshwWlHAJ3VRA/HzBisR/+2mNjHmgKSG5EEG0Vt1+aD/ fTFaluMQKvHF1w6R9PDy9V9voVvwBmWdwkOxOc/zeBhtbG7ZoN2xfVxwumHPcXd4QZuRyjNoB6Jj YFDYIHJnbHEBy5RyLcwHdKNRy5RizUNndTp02WByYFDSsdbgY3Sd0pB3WHDcwM8AcmzTYPB0bmJq 0fDZcNtg2yCKXNyweNlBdG952XCAXGV4cHNocs/wrdCxdc6x2uBw0KBk2YBj3bDJsGJkYtCx1dBh cmPbgG9y0jDP0NPwbaXRsGHbcFxo0/B60IK0ZGfLsmnRYNVgaNOT23EB1VF21inU4WnVsarh/1kA 1rHXpUPS1fLU4MqA1qN12XNq0YFh0GDSsNUwdAZ5ylBbcHZpZXdrh9fgHsDbU3NjYWzXIKWnwXDN wHJkyzBl1KAj3MXUQG90XNOQbHl4dHdu1+DUwM/h3ldo/nTNkM5A05DQscmg36DUoLJqydFcdc7g zrBi3GD/1dDhYcnR27HOoN5g3FHPAP3J4HfiI8nR0dDMgM6g0AA8cmvUAdTA03Dj4Xdy8nDgwnNu ywDRIMyAWHBb1+DTwGzUINxgbM9wZn3bcGzUsNBg4RHPMOTAcPZ15dDeEGHq4NqQ4+ZYUm5y3fFF 1t6wd8nRycB5vdQBc9CxzIDPcN/Rb+aAoc8RZmV0MMlCd8yAcGZmbXTmgM6wymAg+WKQM2bKEOxw 1EDNkNxQ8+JgyaB1cM6TyjDssN4gvc7xZM8gzrXOoN6heGBQ/9BR4GDKYNTAzuLvouWCNiF/7qTT 0N/QzrDtwN4gz+MgzclCcMmwzvBsdsvw8yH8dWPUYPMi4IDR0POy27Gd0VB0lnHzIdSQbmfy4Ynz MHR44IAgLn3JM//zNltw89LOsfQ/9U/2X/OQf1gw8zDUsNCg+C/5P/pPbL9d4PMw4pD37/y//cUp 9qyPXRD7jwB//aViICjJMf8Br/NjahD/TwQfBS8GP/OB/5RQB5L0Hwj/Cg8CHVxAB5//DS8OPw9P 84FZ0AwvEc8S3/8T5coh3QDKINDw1+DvA+5h/FxxyfDvkWBRGmHPQfDB/xnS5LDLAPHl58HKMBsg 1JD/HCLt4BWA8gDq4tAw4KDhAO/PoNfA36AagW7OkR5y6zBdywAwzyDR0OKQaM/QY2RzMc8gYWZg UCAwc/9d0dxg/WFfEu8DH6QfQSCD3yDkWCEg4utwItNj5YIig/xucCLZJHTy4R98WQAgcn8fQSGL WQAm4iPAIEHX4HN5RZkgSdLQymDlMMnwbW5l64DX4P2AdNSQzxBJwCBNVVNUINEB0FF/9pAlvybP J98o6iPA1JBy+Sj6DQoY0jD2GMQZjxqf/xunHTUebiwOZsEtL+tRZsG/Locg5SJ0I2Jd0dNwcOjh hmYovslCYmttaxXDSCBfTRlQbEHq8VP518B9VO1gK/8tA3HwLX+/P2IuwUJhOZ86rzB+X0R//0WP Rlo+LyABP805X0IvQz//MbJHfz9PQF9J70r/KTY98bUrIGHOMGnwcDEFU9FQbmnUUFLAzvBo4DHl cGlRycAsIE/sIGnTwCDh6xAgQ1RPTP9If0mP/1DvS69Mv03PTt9P71lfKOv4RU1DW69cv13PXt9z wd5z7fDKYGAPKUUyYb9XL79YP1+fWl9bZeaDyUJm5rB/KMHPEGgfaS9qP2tPKOtIAFlQRVJMSU5L zCAizZDscW86zZBTMwJf0SBtQGVtYy76Y+1gImgPb99w73H/Ly+/MDOyQIWQsjCE0PLjZNEANyAw 5pLPIGLX4MkQIAAA0Mnqefm6zhEAjIIAqgBLqQtUAgB+4AN+4eB97TYBfuFtAGEAaQBsQAB0AG8A OoCDZwQAdYDBcgBlAF8bgQOAkECCIYCQYwAu/4MhgpJ+4PagbZLmsIXQzrD/bs9iz2Pa1BFkn3l/ KNx1D/8+Afaidn93j3ifiQ9sf1ufH4W/Y8+Of4+PKRgrMSiR2QA1KSAWsDktrUD/oGAxDZG/ks+T 3JTPld8pGNwiVN0wVaDfASDlsOwg0/Bh5dEgYuuAdypQGXAv/hDUAM8Q2pEgzIBhdj9VkFTwKrFV kNSw5NBoLiAiIC0gUhxiIFf/3GDPYGFwKkClgJ+AmW+NL/+cP51PkF8xrzK803AznzSv/zW/LG+l bzkPpz+oT6lfqm//M48b3xzvHf+uHyAEIWwu2fvKkCOgNsMwfaA8RtBRPRwJtDZ9AMBAHgBwAAEA AAAVAAAAUmVncmV0cyB0aGlzIG1vcm5pbmcAAAAAAgFxAAEAAAAWAAAAAcbi/hFhlVX6VmTLQ+yR 5Ok8Yi32dgAAAwAmAAAAAAALAAIAAQA8LwsAAQ4AAGU+AgEKDgEAAAAuAAAAAAAAAEcAeBfHkKxK r+8LploFF7ABAPwVTdjvdXlKhysGywQ4l68AAAADrAUAAAAAAwAJWQMAAAADAN4/n04AAAIBfwAB AAAAEQAAAEUwQjM4ODExRkVFMkM2MDEAAAAAAwAGELsR/00DAAcQrwAAAAMAEBAAAAAAAwAREAAA AAAeAAgQAQAAAGUAAABJTlRFUk5BTE1FRVRJTkdUSEFUSU1VU1RBVFRFTkRUT01UT01NQUdVSVJF U0VOSU9SVEVDSE5PTE9HSVNULE9GRklDRU9GQ1RPRU1DMk1BR1VJUkVUT01ARU1DQ09NKzEoODQ1 AAAAANPw ------=_NextPart_000_00B1_01C6E2DC.8A7A2120-- Ê0=0ŠÍºVðßäŒTþ"¬³rªU0 *H÷ 0_10 UUS10U VeriSign, Inc.1705U.Class 1 Public Primary Certification Authority0 960129000000Z 280801235959Z0_10 UUS10U VeriSign, Inc.1705U.Class 1 Public Primary Certification Authority00 *H÷ 0å¿m£Va-HqögÞ¹ë· ú8%¯Fåsš $] Ìen°ÐV¡sßŽX9knÁöÕšš?ª1¬°4×4g ÍâNEVixÚÜG)»6Éc\Åà×-{¡·2°{0º*/1ªî£gÚÛ0 *H÷ L?žÆhßîC3]éŠËMz3ÿô6Ø"6hl|BÌó.Ä?°OÿvùâŒJéÍ ÷Å)ñ"]ž±Ý#£{%F0yøêKÂÈã·ô@<Ã_SèHäŽ{¡5°{%ºžÓ«?84óÑq0b0Ë ÚÁ?« tzŽÎ.30 *H÷ 0_10 UUS10U VeriSign, Inc.1705U.Class 1 Public Primary Certification Authority0 980512000000Z 080512235959Z0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not Validated00 *H÷ 0»ZD»Uýz-Ox6ž J²oT¿Œèw*¹ðh»Ù1ApzK¹HV-ÇáB«À¢«D\ªBðé/ûÂ;»ŸÉ' ]¶°6B3µnTOJ¿Úùè¶ãÌÆj$ãüàeº§±~ïÉÛ7jÈJÈ ä£°00U0ÿ0GU @0>0<`HøE0-0++www.verisign.com/repository/RPA01U*0(0& $ " http://crl.verisign.com/pca1.crl0U0 `HøB0 *H÷ }oEK8 žÞéSd!ŒäL+þ@¬Ø 9j¡2!,«YþÒb}U8°7sÜôfcbœáSpRçšØRé[-ªáÞÏ¬1TÔÈØ#šï+2},È|š.wòDÑe MtµîÓst.;5rç@1Ó²Ä«çVŸãû00 aI±thÆãøSÈ¬1ÌÀ .0 *H÷ 0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not Validated0 060419000000Z 070419235959Z010U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. by Ref.,LIAB.LTD(c)9810UPersona Not Validated1402U+Digital ID Class 1 - Microsoft Full Service10UThomas Maguire1"0 *H÷ maguire_tom@emc.com00 *H÷ 0«ŒåO!² cuû!ç_ãÚFÒWðçínøíy>ÏŒ³$"ÎñÜeq¶Úß©Çï«t úK?@K¬þ[REæâËH¶#»ÇS1w\¯lúèŸa7Š)ì_eÎËê66$±s²ùxT¿4×íËª/ç£µ0²0 U00DU =0;09`HøE0*0(+https://www.verisign.com/rpa0U 0U%0++03U,0*0( & $"http://crl.verisign.com/class1.crl0 *H÷ <¢A·ë¡ø'¿ÎáÜßTî$ñ<Ü{nDa6gWÛÈØ¿€«ÉšO³Eq!ÛÃnw) Žæ5ÜÊ£Á×eF¹Dö¬«úÄ()ÌLç£4œä×Å²AÿÅ,^56¥¢Ò°®oI÷ñ¿AÿæÅ1>0:0á0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaI±thÆãøSÈ¬1ÌÀ .0 + ²0 *H÷ 1 *H÷ 0 *H÷ 1 060928130027Z0# *H÷ 1»0"&íÊÜÕOÛ¢}ÁðÚ0g *H÷ 1Z0X0 *H÷ 0*H÷ 0 *H÷ @0+0 *H÷ (0+0 *H÷ 0ò +71ä0á0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaI±thÆãøSÈ¬1ÌÀ .0ô*H÷ 1ä á0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaI±thÆãøSÈ¬1ÌÀ .0 *H÷ F7äÕÖ1l©·µz F=¯¥ÄMuø«û0ÅýnO°§c"¢Žüý:2¶€=Ä*=¢sÕÛ8N±8pÖòòÎº÷Bã¯}»çÉšÉoîtàE9AÚ»f¯V@èöIÖî

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

re-evaluate removal of container model from BES spec appendix
by Ellen Stokes 27 Sep '06

27 Sep '06

Andrew, Per our discussion at the OGSA F2F Sep 14, I'd like the workgroup to re-evaluate the decision to remove the (general) container model from the BES specification appendix. The intent of this appendix is to provide the container model as an 'informational' appendix so it can be submitted to DMTF as concrete proposal for inclusion in the DMTF CIM and a context for why a container model is necessary. The inclusion of the model in the BES spec does not imply that OGSA must implement this CIM container model to implement BES; it is merely an abstraction for a general container model where BES can provide context for the need and implementation of a specific container model. If this point doesn't come across in the appendix text, I have no problem modifying the text. I know the BES calls are generally scheduled for Thursdays; however, I am not available this Thursday Sep 28. Let me know when this topic can be scheduled as part of BES workgroup call. Ellen Ellen Stokes STSM, Grid Computing TC Member, IBM Academy of Technology Austin, Texas tl 678 0552 outside +1 512 838 0552 stokese(a)us.ibm.com

1 0

Nominations sought for co-chair of HPC Profile WG
by Marty Humphrey 14 Sep '06

14 Sep '06

Folks, As we discussed in the HPC Profile session yesterday, Marvin Theimer must step down as the co-chair of the HPC Profile WG because of his new job responsibilities. (Note that I have been assured that this by no means implies that Microsoft will reduce or eliminate their effort in our WG). Marvin is a tremendous guy and has done a FANTASTIC job as the co-chair and we will miss his energy, experience, and vision. As a group, we have a number of things that we still need to push through, namely the finalization of the three documents of the group as well as our emerging interop/compliance suite efforts. Please send me email if you would like to nominate yourself or someone else as the co-chair of the HPC Profile group. The deadline for submissions is Friday Sept 22 (1 week from today). Thanks, Marty Marty Humphrey Assistant Professor Department of Computer Science University of Virginia

1 0

Something else
by Andrew Grimshaw 14 Sep '06

14 Sep '06

All, It has been brought to my attention that the BES spec is mute on how long information about the status of an activity is kept around once it has transitioned to cancelled, finished, or failed. (This is a problem with many queuing systems as well.) I propose that I add a sentence explicitly stating that it is undefined how long status information will persist once an activity enters one of those three states. Thoughts? A Andrew Grimshaw Professor of Computer Science University of Virginia 434-982-2204 grimshaw(a)cs.virginia.edu

4 3

Minutes from GGF18, BES Section
by Mark Morgan 13 Sep '06

13 Sep '06

-- Mark Morgan Research Scientist Department of Computer Science University of Virginia http://www.cs.virginia.edu mmm2a(a)virginia.edu (434) 982-2047

1 0