Great start! Just a couple of comments: 1) I'd prefer something like "ManagedJobFactoryResourcePropeties" instead of "JobFactoryRPDocument". That way everything is spelled out and it's named after the full port type name. 2) I think the unnamed complexType under the "JobFactoryRPDocument" element should be named. Following my preference from #2, this is what I would like to see (or something similar): <xsd:element name="ManagedJobFactoryResourceProperties" type="tns:ManagedJobFactoryResourcePropertiesType"/> <xsd:complexType name="ManagedJobFactoryResourcePropertiesType"> . . . </xsd:complexType> This is primarily motivated by implementation concerns, but it's not like working around broken tooling. I just don't like leaving class names up to the tooling. Specifying a name explicitly usually dictates what it will be seen as in the API. In addition, it mandates that any reuse of the element be done via a ref (like Subscribe). 3) The port type name is specified as "JobFactoryPortType" instead of "ManagedJobFactoryPortType" from the spec. If this was something decided upon in the last call I apologize. Peter On Fri, 2006-04-28 at 15:36 +0100, Michel Drescher wrote:
Folks,
I took a shot and hacked a WSDL that is OGSA WSRF Basic Profile compliant (I hope).
It is fairly incomplete with respect to a) the operations, messages and faults taken from WSRF- ResourceProperties, WSRF-ResourceLifetime and WS-Notification specifications. b) the ManagedJob interface completely missing as this in a constant flux at the moment (and will probably merge eventually with the existing BES specification)
The documents differ from the draft specification in that the resource properties that define the (POSIX) limits of a Job Factory retain the "Limit" suffix to avoid a naming conflict of the per ManagedJob limit "VirtualMemory" with the capability resource property "VirtualMemory".
As I am either not allowed or not capable otherwise to add documents to GridForge, would please one of the project admins do so for me.
Cheers, Michel