October 2006 - ogsa-bes-wg

Some Question from EGEE project
by Alessandro Maraschini 19 Oct '06

19 Oct '06

Hi all, After a brief discussion with Steven Newhouse at EGEE06, we decided to try and participate in the SC06 interoperability DEMO with two more services coming from the european project EGEE (http://www.eu-egee.org/) CREAM & WMPROXY: those WS-based services have been working for several months now; over the last few weeks we have been trying to integrate our work with BES and JSDL implementation. Yet we still have some unsolved questions, I hope you would be so kind to answer them: 1) WS-Addressing and WS-Security According to what I read, the client will send SOAP messages including WS-addressing headers while the server might not support WS-Addressing at all and just ignore WS-addressing headers, is that correct? What about WS-security on server side? Is that a suggestion rather than a to-be-implemented feature? 2) Is there available any [template] client that will be used to call services during the demo? How will be the demo structured? Which is the client used for querying the service? 3) Can we consider the BES-factory wsdl as definitive? There had been some complains during the week, yet only minimal parts aparently are going to be changed. Can we assume the last WSDL is the one that will be used for the demo? 4) Binding and style/encoding Regarding the Binding, are we free to use both DOCUMENT/LITERAL and RPC/LITERAL or is there some restriction? cheers, Alessandro -- ----- Alessandro Maraschini Grid R&D Group Government and Institutions Division DATAMAT S.p.A. - a Finmeccanica company Via Laurentina, 760 I - 00143 Rome Italy http://www.datamat.it mailto: alessandro.maraschini(a)datamat.it phone: +39 06 5027 4501 (direct) +39 06 5027 2211 (secretary) fax: +39 06 5027 4330

1 0

ActivityStatusType in bes-factory.xsd
by Christopher Smith 19 Oct '06

19 Oct '06

Hi all, Given the text in the bes specification (v26), the type of the elements within ActivityStatusType should not be xsd:anyType, but should use the definitions as follows. This is in line with the extensible state model as described in the specification: <xsd:complexType name="ActivityStateType"> <xsd:sequence> <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="ActivityStatusType"> <xsd:choice> <xsd:element name="Pending" type="bes-factory:ActivityStateType"/> <xsd:element name="Running" type="bes-factory:ActivityStateType"/> <xsd:element name="Cancelled" type="bes-factory:ActivityStateType"/> <xsd:element name="Failed" type="bes-factory:ActivityStateType"/> <xsd:element name="Finished" type="bes-factory:ActivityStateType"/> </xsd:choice> </xsd:complexType> Um ... how can we track these issues, and (more importantly) quickly get some closure on them in order to update our implementations? -- Chris

2 2

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