[ogsa-hpcp-wg] Globus Status

[Peter G. Lane]

I'm a little frustrated because I thought I made it clear when I was pushing for EPRs as a 
requirement that we needed clients to support the WS-Adressing headers. But since it sounded as 
though people didn't want to bother with this, I capitulated and made my service use a singleton 
resource that didn't need an EPR, limiting it's capabilities and wasting time. So now I find that 
people have agreed off list to support such a scenario and I'm left with not being interoperable.

What I'm saying is that I don't have an objection to this in principle, but it would have been nice 
if someone would have clarified this earlier on the list when I was arguing the that my service 
would also need to add a ReferenceParameters element. I saw no discussion of people implementing the 
soap headers in clients so that they could interop with such services.

Peter

Mark Morgan wrote:
> Well, personally, I believe that the discussion before revolved around
> whether or not people were required to post EPRs to the WIKI pages for
> degenerate EPRs where only the Address field had a value (i.e., where
> metadata and reference parameters were empty or null as allowed by spec.).
> Since such an EPR is identical in informational content to a play URL,
> people believed that they shouldn't be required to post EPRs.  However, at
> no point did we decide to dissalow WS-Addressing of endpoint should an
> implementation choose to use them.  Chris (and please correct me Chris if I
> mis-represent you) certainly expressed a desire to avoid implementing
> WS-Addressing on his client side, but has since done so in order to achieve
> interoperability with the GenesisII endpoint as our endpoint requires the
> ReferenceParameters header elements.  Others in the HPC interop group, can
> you confirm or deny my interpretation of the early discussion?  Is my
> endpoint out of spec., or am I correct in assuming that I am welcome to use
> WS-Addressing for my endpoint (i.e., to require ReferenceParameters in the
> headers.)?
> 
> -Mark
> 
> --
> Mark Morgan
> Research Scientist
> Department of Computer Science
> University of Virginia
> http://www.cs.virginia.edu
> mmm2a at virginia.edu
> (434) 982-2047 
> 
>> -----Original Message-----
>> From: Peter G. Lane [mailto:lane at mcs.anl.gov] 
>> Sent: Monday, November 06, 2006 11:09 AM
>> To: Mark Morgan
>> Cc: ogsa-hpcp-wg at ggf.org
>> Subject: Re: [ogsa-hpcp-wg] Globus Status
>>
>> This is what Chris said:
>>
>> I'm guessing that yours will require me to set some SOAP 
>> header blocks based on the WS-Addressing SOAP binding. I had 
>> hoped to avoid this detail for now....
>>
>> By this I was under the impression that nobody was going to 
>> build clients that added WS-Addressing SOAP headers. If that 
>> was the case, then services shouldn't publish EPRs that have 
>> anything more than an address field.
>>
>> Chris, did you change your mind? Was this only your point of 
>> view, or did you think that everyone was going to skip the 
>> SOAP headers as well?
>>
>> At any rate, I should still be able to interop with those 
>> services that aren't expecting the SOAP headers. It just 
>> means I have to exclude at least the Genesis II 
>> implementation since I won't have enough time to implement 
>> the agreed upon version of WS-Addressing.
>>
>> Peter
>>
>> Mark Morgan wrote:
>>> I think you misunderstood the result of that discussion.  The end 
>>> result was that services that didn't NEED EPRs, could use URLs.  
>>> However, we didn't dissalow EPRs, only allowed the more 
>> degenerate case of them (the pure URL).
>>> -Mark
>>>
>>> --
>>> Mark Morgan
>>> Research Scientist
>>> Department of Computer Science
>>> University of Virginia
>>> http://www.cs.virginia.edu
>>> mmm2a at virginia.edu
>>> (434) 982-2047
>>>
>>>> -----Original Message-----
>>>> From: ogsa-hpcp-wg-bounces at ogf.org
>>>> [mailto:ogsa-hpcp-wg-bounces at ogf.org] On Behalf Of Peter G. Lane
>>>> Sent: Monday, November 06, 2006 10:28 AM
>>>> To: ogsa-hpcp-wg at ggf.org
>>>> Subject: [ogsa-hpcp-wg] Globus Status
>>>>
>>>> I have the create and terminate operations implemented and working 
>>>> locally. I will put up an endpoint sometime today, and by 
>> them will 
>>>> hopefully have the other operations implemented. Is there a WSDL 
>>>> snipit or something of this "Show job output" operation, 
>> or does this 
>>>> just mean that I have an FTP server running?
>>>>
>>>> Problems
>>>> --------
>>>> I am unable to get responses from either of the .Net 
>> implementations 
>>>> using my client. My SOAP message logging show that the 
>> client message 
>>>> is going out, but nothing is ever received back. Are these 
>> services 
>>>> still up?
>>>>
>>>> I tried using my client on the Platform service (service URL 
>>>> https://plato.dreadnought.org), but I got an error saying that the 
>>>> client couldn't find the correct CA. I did download and 
>> install the 
>>>> CA cert and have debug output showing it was loaded, so 
>> I'm wondering 
>>>> if anyone has had success with this service recently. If 
>> so, Chris, 
>>>> could I get the public certificate of the server to help in my 
>>>> debugging?
>>>>
>>>> After agreeing that we wouldn't use EPRs, I'm confused 
>> about the use 
>>>> of them on the wiki. I did what others did and didn't bother 
>>>> implementing support for the WS-Addressing SOAP headers. 
>> The Platform 
>>>> EPR is trivial so that's not a problem.
>>>> The GenesisII EPR, though, is very non-trivial. That said, 
>> I see that 
>>>> some clients have indeed talked to the GenesisII endpoint, so I'm 
>>>> rather confused. Did I miss a discussion where it was decided that 
>>>> full WS-Addressing support was now mandatory?
>>>>
>>>> Finally, I tried to use the CROWN endpoint too, but I get the 
>>>> following error:
>>>>
>>>> Authentication failed [Caused by: Defective credential detected 
>>>> [Caused by: [JGLOBUS-96] Certificate 
>>>> "C=CN,ST=Beijing,L=Beijing,O=company,OU=department,CN=localhos
>>>> t" expired]]
>>>>
>>>> Peter
>>>>
>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3804 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/ogsa-hpcp-wg/attachments/20061106/09976f0c/attachment-0001.bin