[OGSA-BES-WG] BES question

[dejw]

Hi,


Joseph Bester napisał(a):
> On Mar 15, 2007, at 7:33 AM, dejw wrote:
>
>> 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.
>>
>
> The endpoint reference type is a web services standard way of
> describing how to contact a web service, potentially including
> references to some state managed by the service via the
> ReferenceParameters (these are similar in concept to http cookies).
> The ReferenceParameters are to be considered an opaque data block to
> service clients.
>
> There is no guarantee that any sort of meaningful local identifier
> will be present in the EPR. It is meant to be used by the Web Service
> hosting system to  address  Web Service operation requests to the
> particular stateful resource associated with the created activity.
>
>> 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.
>
> The EndpointReferenceType can be sent in the body of the
> GetActivityStatus operation directly. Why do you think you need to
> know about the contents of the EPR?
In our portal solution we need job id to present it in our web pages
with job statuses and other information, we have also plugins for other
non-BES services and we need job ids to get all informations about jobs.
The other thing is that from my observation so far the
ReferenceParameters contains only job id and that's all, no other
information is there. So I don't know if job id is something which
should be hidden for BES services? The other thing it is easier later to
debug some problems - user knows job id and he can also directly contact
administrator of the target system and get known about source of the
problem, he can give exact job id which let do it much easier. So I
think there are scenarios where the client must know job id  and has to
parse ReferenceParameters to get this job id as it is often in case of
BES services. Other case I had that there was noting in
ReferenceParameters and the job id was added to the uri which was in the
Address element of the EndpointReferenceType.

So finally I had common interface to different job management systems -
BES - and this is very good, but what is not so comfortable - I have to
test evey new BES service I want to use and write another part of code
to get job id and later to create ActivityIdentifier where
ReferenceParameters is a little different if it was used.

Dawid