Hi, maybe some example what I meant so far: The case is when I get ActivityIdentifier from BES service which is as the BES schema says: <xsd:element name="ActivityIdentifier" type="wsa:EndpointReferenceType"/> and wsa:EndpointReferenceType is: <xs:complexType name="EndpointReferenceType" mixed="false"> <xs:sequence> <xs:element name="Address" type="tns:AttributedURIType"/> <xs:element name="ReferenceParameters" type="tns:ReferenceParametersType" minOccurs="0"/> <xs:element ref="tns:Metadata" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> So as you can see I can have always Address so uri of target service, and its ok here. But the problem is with 'ReferenceParameters'. The definition of this is: <xs:complexType name="ReferenceParametersType" mixed="false"> <xs:sequence> <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> So it can contain any xml blob. And many BES services have their own xml here inside it. So I as a programmer have to parse these xml's and get the job id which is always some string and that's all. So I think this xml is useless here unless it is common for every service. Now I have to now what "type" of underlying system I have i.e. crown, unicore, gridsam etc. and then I have to built a little different ActivityIdentifier to get job status for example. It's a little strange. If there would be some additional parameters then ok, I can understand. But there is always only one string with job id. The BES serivces we tested didn't have other parameters there. But even then I can imagine that a common xml schema snippet could be defined for this and why it couldn't be a part of BES spec? Regards, Dawid Szejnfeld dejw napisał(a):
Hi all,
I have a question about BES :
We implemented a plugin to our portal solution which let us run jobs to any BES service (compatible with first version of this standard). So our solution should work well with any service which conforms to this standard.
But we met some small problems although.
For our perspective we need to extract the job identifier - and here we had to write suitable part of code for different BES services - why? becuase ActivityIdentifier is a type of wsa:EndpointReferenceType and here lies the problem. Every BES service use different tactics here. For example when I tried BES service build upon LSF (platform.com) the job id was added simply to the Address which is simply url with parameter containing job ID. Other services always uses ReferenceParameters which can be any xml data which is characteristic to the target underlying system. So for every new BES service built on different middleware, job managament service I had to write something like let say transition code which extracts for me job id from different xml data. This way actually I don't know if some new service will work well with my plugin.
This is a little confusing for me why in some common interface (let me say that about BES) can have different job id notation. It is always some string by the way which looks a little different for every underlying system. So why it couldn't be also one xml schema concerning job id?
Regards, Dawid Szejnfeld, PSNC