[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: keyNames and keyValues for categories
In reviewing the GRID requirements can I just check something as to how categories work. My understanding is that the value of the keyName in the keyedReference is intrinsically linked to to the keyValue, i.e. it provides a human readable name for that value. I ask because one GRID implementation of UDDI which adds an extensions requires key/value pairs to expose GRIDService data, and I'm wondering if this can be slotted into the existing UDDI structures or whether this might require something new. Essentially, the sort of information that would be useful to add to a GRID service/resource would be information such as CPU type, CPU speed, no. of processors, available memory, available disk etc. There are three ways to do this as far as I can see - i) Add a new structure for key/value pair type data. ii) use categories as is - this would imply in the above case new tModels for CPU type, CPU speed, memory etc. this could lead to a large amount of tModels! iii) Allow key/value pairs in keyedReferences i.e. we could have something like: <keyedReference tModelKey="grid:serviceData" keyName="CPU Type" keyValue="Intel 586" /> <keyedReference tModelKey="grid:serviceData" keyName="CPU Speed" keyValue="2GHz" /> <keyedReference tModelKey="grid:serviceData" keyName="Processors" keyValue="64" /> <keyedReference tModelKey="grid:serviceData" keyName="Memory" keyValue="4GB" /> <keyedReference tModelKey="grid:serviceData" keyName="Disk" keyValue="3TB" /> Option 3 seems the neatest to me - but is this breaking the keyedReference semantics in a direction that people don't want to go in? Is there something nasty in this approach which I'm not seeing? Matthew
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]