Here is the URI and test JSDL for MS CCS HPCBasicProfile web service. I will need to create an account per user so please send me an email with your phone number and I will call you with your credentials. The URI is https://hpc.msftlabs.com/SC06Demo/HPCBasicProfile.svc. Peter, per your email regarding EPRs, we all agreed on using SSL for transport security and WS-Security UsernameTokens for message authentication so from my understanding, folks only need my address to be able to connect. Also the security policy for my service can be viewed via https://hpc.msftlabs.com/SC06Demo/HPCBasicProfile.svc?WSDL. Thanks
Richard Ciapala wrote:
Here is the URI and test JSDL for MS CCS HPCBasicProfile web service. I will need to create an account per user so please send me an email with your phone number and I will call you with your credentials.
The URI is https://hpc.msftlabs.com/SC06Demo/HPCBasicProfile.svc.
Peter, per your email regarding EPRs, we all agreed on using SSL for transport security and WS-Security UsernameTokens for message authentication so from my understanding, folks only need my address to be able to connect. Also the security policy for my service can be viewed via https://hpc.msftlabs.com/SC06Demo/HPCBasicProfile.svc?WSDL.
I don't understand. Security has nothing to do with EPRs. Peter
Thanks
------------------------------------------------------------------------
<?xml version="1.0" encoding="utf-8" ?> <jsdl:JobDefinition xmlns:jsdl="http://schemas.ggf.org/jsdl/2005/11/jsdl" xmlns:jsdl-hpcp="http://schemas.ggf.org/jsdl/2006/07/jsdl-hpcp" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <jsdl:JobDescription> <jsdl:JobIdentification> <jsdl:JobName>SC06 Demo Job Sample</jsdl:JobName> <jsdl:JobProject>SC06 Demo</jsdl:JobProject> </jsdl:JobIdentification> <jsdl:Application> <jsdl-hpcp:HPCProfileApplication name="Time" > <jsdl-hpcp:Executable>time.exe</jsdl-hpcp:Executable> <jsdl-hpcp:Argument>/T</jsdl-hpcp:Argument> <jsdl-hpcp:Output>time.txt</jsdl-hpcp:Output> <jsdl-hpcp:Error>time_err.txt</jsdl-hpcp:Error> <jsdl-hpcp:WorkingDirectory>\\10.6.30.167\SC06DemoOutput</jsdl-hpcp:WorkingDirectory> </jsdl-hpcp:HPCProfileApplication> </jsdl:Application> <jsdl:Resources> <jsdl:ExclusiveExecution>false</jsdl:ExclusiveExecution> <jsdl:TotalCPUCount> <jsdl:UpperBoundedRange>1.0</jsdl:UpperBoundedRange> <jsdl:LowerBoundedRange>1.0</jsdl:LowerBoundedRange> </jsdl:TotalCPUCount> </jsdl:Resources> </jsdl:JobDescription> </jsdl:JobDefinition>
------------------------------------------------------------------------
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
Let me elaborate on why I need EPRs to be a requirement. Our implementation will be a stateful service with a static state resource for each resource manager that we interact with on the back end (i.e. fork/exec, PBS, LSF, Condor, ...). What this means is that you have to have a resource reference that cannot be obtained from the WSDL in order for our service dispatcher to know what state resource is associated with a particular CreateActivity (or any other BES-Factory operation) call. This is what EPRs are primarily good for. I realize stateless services don't need it, but if EPRs aren't supported then there's no realistic way we can participate seeing as thought we'd have to rewrite GRAM to, I guess, only do fork/exec. I know .Net has support for EPRs (heck, Microsoft was a coauthor for the WS-Addressing spec!), so I don't see this as a huge burden. And as I said before, we are assuming EPRs for the Activity references, so it's a bit puzzling that anybody would use anything else for the factory. Peter Peter G. Lane wrote:
Richard Ciapala wrote:
Here is the URI and test JSDL for MS CCS HPCBasicProfile web service. I will need to create an account per user so please send me an email with your phone number and I will call you with your credentials.
The URI is https://hpc.msftlabs.com/SC06Demo/HPCBasicProfile.svc.
Peter, per your email regarding EPRs, we all agreed on using SSL for transport security and WS-Security UsernameTokens for message authentication so from my understanding, folks only need my address to be able to connect. Also the security policy for my service can be viewed via https://hpc.msftlabs.com/SC06Demo/HPCBasicProfile.svc?WSDL.
I don't understand. Security has nothing to do with EPRs.
Peter
Thanks
------------------------------------------------------------------------
<?xml version="1.0" encoding="utf-8" ?> <jsdl:JobDefinition xmlns:jsdl="http://schemas.ggf.org/jsdl/2005/11/jsdl" xmlns:jsdl-hpcp="http://schemas.ggf.org/jsdl/2006/07/jsdl-hpcp" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <jsdl:JobDescription> <jsdl:JobIdentification> <jsdl:JobName>SC06 Demo Job Sample</jsdl:JobName> <jsdl:JobProject>SC06 Demo</jsdl:JobProject> </jsdl:JobIdentification> <jsdl:Application> <jsdl-hpcp:HPCProfileApplication name="Time" > <jsdl-hpcp:Executable>time.exe</jsdl-hpcp:Executable> <jsdl-hpcp:Argument>/T</jsdl-hpcp:Argument> <jsdl-hpcp:Output>time.txt</jsdl-hpcp:Output> <jsdl-hpcp:Error>time_err.txt</jsdl-hpcp:Error>
<jsdl-hpcp:WorkingDirectory>\\10.6.30.167\SC06DemoOutput</jsdl-hpcp:WorkingDirectory>
</jsdl-hpcp:HPCProfileApplication> </jsdl:Application> <jsdl:Resources> <jsdl:ExclusiveExecution>false</jsdl:ExclusiveExecution> <jsdl:TotalCPUCount> <jsdl:UpperBoundedRange>1.0</jsdl:UpperBoundedRange> <jsdl:LowerBoundedRange>1.0</jsdl:LowerBoundedRange> </jsdl:TotalCPUCount> </jsdl:Resources> </jsdl:JobDescription> </jsdl:JobDefinition>
------------------------------------------------------------------------
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
------------------------------------------------------------------------
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
All, Peter G. Lane wrote:
Let me elaborate on why I need EPRs to be a requirement. Our implementation will be a stateful service with a static state resource for each resource manager that we interact with on the back end (i.e. fork/exec, PBS, LSF, Condor, ...). What this means is that you have to have a resource reference that cannot be obtained from the WSDL in order for our service dispatcher to know what state resource is associated with a particular CreateActivity (or any other BES-Factory operation) call. This is what EPRs are primarily good for. I realize stateless services don't need it, but if EPRs aren't supported then there's no realistic way we can participate seeing as thought we'd have to rewrite GRAM to, I guess, only do fork/exec. I know .Net has support for EPRs (heck, Microsoft was a coauthor for the WS-Addressing spec!), so I don't see this as a huge burden. And as I said before, we are assuming EPRs for the Activity references, so it's a bit puzzling that anybody would use anything else for the factory.
I strongly support Peter here on requiring EPRs. It really shouldn't be that difficult to define a simple (I mean *really* simple!) factory WSDL having one method with no input that returns exactly one EPR. Agreeing on a transport binding shouldn't be that difficult either, shouldn't it? Implementing that factory should be a finger excercise. Problem solved? Cheers, Michel -- Michel <dot> Drescher <at> uk <dot> fujitsu <dot> com Fujitsu Laboratories of Europe +44 20 8606 4834
Michel Drescher wrote:
All,
Peter G. Lane wrote:
Let me elaborate on why I need EPRs to be a requirement. Our implementation will be a stateful service with a static state resource for each resource manager that we interact with on the back end (i.e. fork/exec, PBS, LSF, Condor, ...). What this means is that you have to have a resource reference that cannot be obtained from the WSDL in order for our service dispatcher to know what state resource is associated with a particular CreateActivity (or any other BES-Factory operation) call. This is what EPRs are primarily good for. I realize stateless services don't need it, but if EPRs aren't supported then there's no realistic way we can participate seeing as thought we'd have to rewrite GRAM to, I guess, only do fork/exec. I know .Net has support for EPRs (heck, Microsoft was a coauthor for the WS-Addressing spec!), so I don't see this as a huge burden. And as I said before, we are assuming EPRs for the Activity references, so it's a bit puzzling that anybody would use anything else for the factory.
I strongly support Peter here on requiring EPRs.
It really shouldn't be that difficult to define a simple (I mean *really* simple!) factory WSDL having one method with no input that returns exactly one EPR. Agreeing on a transport binding shouldn't be that difficult either, shouldn't it?
Not to look a gift horse in the mouth, but why are you suggesting a method to retrieve the EPR? I'd still need an EPR to call an operation that returns the service's EPR, so it doesn't make much sense to me. If there's no discovery mechanism, then I'd suggest just writing the EPR to a log file and distributing it from that. As for a transport binding, I thought we already agreed on anonymous https. Peter
Implementing that factory should be a finger excercise.
Problem solved?
Cheers, Michel
Can I be clear on something? Instead of: https://aristotle.dreadnought.org:9090 You want: <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing"> <wsa:Address>https://aristotle.dreadnought.org:9090</wsa:Address> </wsa:EndpointReference> ... for my endpoint, at any rate. 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 the way ... it's not anonymous https ... we are authenticating the server with SSL. -- Chris On 14/10/06 10:47, "Peter G. Lane" <lane@mcs.anl.gov> wrote:
Michel Drescher wrote:
All,
Peter G. Lane wrote:
Let me elaborate on why I need EPRs to be a requirement. Our implementation will be a stateful service with a static state resource for each resource manager that we interact with on the back end (i.e. fork/exec, PBS, LSF, Condor, ...). What this means is that you have to have a resource reference that cannot be obtained from the WSDL in order for our service dispatcher to know what state resource is associated with a particular CreateActivity (or any other BES-Factory operation) call. This is what EPRs are primarily good for. I realize stateless services don't need it, but if EPRs aren't supported then there's no realistic way we can participate seeing as thought we'd have to rewrite GRAM to, I guess, only do fork/exec. I know .Net has support for EPRs (heck, Microsoft was a coauthor for the WS-Addressing spec!), so I don't see this as a huge burden. And as I said before, we are assuming EPRs for the Activity references, so it's a bit puzzling that anybody would use anything else for the factory.
I strongly support Peter here on requiring EPRs.
It really shouldn't be that difficult to define a simple (I mean *really* simple!) factory WSDL having one method with no input that returns exactly one EPR. Agreeing on a transport binding shouldn't be that difficult either, shouldn't it?
Not to look a gift horse in the mouth, but why are you suggesting a method to retrieve the EPR? I'd still need an EPR to call an operation that returns the service's EPR, so it doesn't make much sense to me. If there's no discovery mechanism, then I'd suggest just writing the EPR to a log file and distributing it from that.
As for a transport binding, I thought we already agreed on anonymous https.
Peter
Implementing that factory should be a finger excercise.
Problem solved?
Cheers, Michel
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
Chris, Peter, all, Christopher Smith wrote:
Can I be clear on something?
Instead of:
https://aristotle.dreadnought.org:9090
You want:
<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing"> <wsa:Address>https://aristotle.dreadnought.org:9090</wsa:Address> </wsa:EndpointReference>
Yes. Well, I would expect whatever EPR as long as it addresses your interop service.
On 14/10/06 10:47, "Peter G. Lane" <lane@mcs.anl.gov> wrote:
Michel Drescher wrote:
All,
It really shouldn't be that difficult to define a simple (I mean *really* simple!) factory WSDL having one method with no input that returns exactly one EPR. Agreeing on a transport binding shouldn't be that difficult either, shouldn't it?
Not to look a gift horse in the mouth, but why are you suggesting a method to retrieve the EPR? I'd still need an EPR to call an operation that returns the service's EPR, so it doesn't make much sense to me. If there's no discovery mechanism, then I'd suggest just writing the EPR to a log file and distributing it from that.
Call that factory a "discovery mechanism". That factory just doesn't use WS-Addressing (i.e. does not make use of the "wsaw:useAddressing" (or something like that) attribute in its WSDL) except that it returns an EPR to the interop service itself. The only thing you have to publish is the factory's URL. Cheers, Michel -- Michel <dot> Drescher <at> uk <dot> fujitsu <dot> com Fujitsu Laboratories of Europe +44 20 8606 4834
Christopher Smith wrote:
Can I be clear on something?
Instead of:
https://aristotle.dreadnought.org:9090
You want:
<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing"> <wsa:Address>https://aristotle.dreadnought.org:9090</wsa:Address> </wsa:EndpointReference>
... for my endpoint, at any rate. 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....
I'm not sure what else I can tell you. We require EPRs for interop and I expected this not to be a problem since it's being used in the spec. I didn't think it was optional to support just enough of WS-Addressing to be able to return an Activity EPR. Saying BES uses WS-Addressing to me means we completely support WS-Addressing.
By the way ... it's not anonymous https ... we are authenticating the server with SSL.
Right, "https" means http over SSL. "Anonymous" means anonymous SSL authentication. What am I missing? Peter
-- Chris
On 14/10/06 10:47, "Peter G. Lane" <lane@mcs.anl.gov> wrote:
Michel Drescher wrote:
All,
Peter G. Lane wrote:
Let me elaborate on why I need EPRs to be a requirement. Our implementation will be a stateful service with a static state resource for each resource manager that we interact with on the back end (i.e. fork/exec, PBS, LSF, Condor, ...). What this means is that you have to have a resource reference that cannot be obtained from the WSDL in order for our service dispatcher to know what state resource is associated with a particular CreateActivity (or any other BES-Factory operation) call. This is what EPRs are primarily good for. I realize stateless services don't need it, but if EPRs aren't supported then there's no realistic way we can participate seeing as thought we'd have to rewrite GRAM to, I guess, only do fork/exec. I know .Net has support for EPRs (heck, Microsoft was a coauthor for the WS-Addressing spec!), so I don't see this as a huge burden. And as I said before, we are assuming EPRs for the Activity references, so it's a bit puzzling that anybody would use anything else for the factory. I strongly support Peter here on requiring EPRs.
It really shouldn't be that difficult to define a simple (I mean *really* simple!) factory WSDL having one method with no input that returns exactly one EPR. Agreeing on a transport binding shouldn't be that difficult either, shouldn't it? Not to look a gift horse in the mouth, but why are you suggesting a method to retrieve the EPR? I'd still need an EPR to call an operation that returns the service's EPR, so it doesn't make much sense to me. If there's no discovery mechanism, then I'd suggest just writing the EPR to a log file and distributing it from that.
As for a transport binding, I thought we already agreed on anonymous https.
Peter
Implementing that factory should be a finger excercise.
Problem solved?
Cheers, Michel
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
On 16/10/06 08:38, "Peter G. Lane" <lane@mcs.anl.gov> wrote:
By the way ... it's not anonymous https ... we are authenticating the server with SSL.
Right, "https" means http over SSL. "Anonymous" means anonymous SSL authentication. What am I missing?
Sorry ... anonymous to me mean http over SSL so there is an encrypted connection but with no authentication using SSL. We're requiring connecting to a server that has a proper certificate, so the server is authenticated via SSL. The client is authenticated using the WS-Security Username Token. -- Chris
Christopher Smith wrote:
On 16/10/06 08:38, "Peter G. Lane" <lane@mcs.anl.gov> wrote:
By the way ... it's not anonymous https ... we are authenticating the server with SSL. Right, "https" means http over SSL. "Anonymous" means anonymous SSL authentication. What am I missing?
Sorry ... anonymous to me mean http over SSL so there is an encrypted connection but with no authentication using SSL. We're requiring connecting to a server that has a proper certificate, so the server is authenticated via SSL. The client is authenticated using the WS-Security Username Token.
I think we're on the same page. I'm probably just not using terminology properly. Also, the WS-Security Username Token stuff is in the SOAP message, so I wasn't considering it since it isn't part of the transport protocol. At any rate, the main point is that we don't need to discover the transport binding since we agreed on this already. Yes? Peter
-- Chris
Right ... transport is pre-defined. -- Chris On 16/10/06 10:41, "Peter G. Lane" <lane@mcs.anl.gov> wrote:
Christopher Smith wrote:
On 16/10/06 08:38, "Peter G. Lane" <lane@mcs.anl.gov> wrote:
By the way ... it's not anonymous https ... we are authenticating the server with SSL. Right, "https" means http over SSL. "Anonymous" means anonymous SSL authentication. What am I missing?
Sorry ... anonymous to me mean http over SSL so there is an encrypted connection but with no authentication using SSL. We're requiring connecting to a server that has a proper certificate, so the server is authenticated via SSL. The client is authenticated using the WS-Security Username Token.
I think we're on the same page. I'm probably just not using terminology properly. Also, the WS-Security Username Token stuff is in the SOAP message, so I wasn't considering it since it isn't part of the transport protocol.
At any rate, the main point is that we don't need to discover the transport binding since we agreed on this already. Yes?
Peter
-- Chris
Chris tells me that this was discussed at one of the calls I missed, so I took a look at what the issues are for us. I can probably implement a singleton resource that acts as a default factory resource so that clients don't have to implement the full WS-Addressing spec. I've been told that our service framework should interpret this as a stateless service call and be ok. And since everybody else is using URLs, you'll probably just ignore any WS-A markup that might come in with the SOAP message created by our clients. The caveat is that no operations will be available on the Activity. I think this was assumed already, but I just wanted to make sure for certain. All Activity manipulation will be through the factory. Is this correct? One last concern was the version of the WS-Security Username Token spec. Was there agreement on which version everyone should use? Thanks, and I think we're finally ready to commit to doing this. Hopefully I can get something working in a week or so. Peter Peter G. Lane wrote:
Christopher Smith wrote:
Can I be clear on something?
Instead of:
https://aristotle.dreadnought.org:9090
You want:
<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing"> <wsa:Address>https://aristotle.dreadnought.org:9090</wsa:Address> </wsa:EndpointReference>
... for my endpoint, at any rate. 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....
I'm not sure what else I can tell you. We require EPRs for interop and I expected this not to be a problem since it's being used in the spec. I didn't think it was optional to support just enough of WS-Addressing to be able to return an Activity EPR. Saying BES uses WS-Addressing to me means we completely support WS-Addressing.
By the way ... it's not anonymous https ... we are authenticating the server with SSL.
Right, "https" means http over SSL. "Anonymous" means anonymous SSL authentication. What am I missing?
Peter
-- Chris
On 14/10/06 10:47, "Peter G. Lane" <lane@mcs.anl.gov> wrote:
Michel Drescher wrote:
All,
Peter G. Lane wrote:
Let me elaborate on why I need EPRs to be a requirement. Our implementation will be a stateful service with a static state resource for each resource manager that we interact with on the back end (i.e. fork/exec, PBS, LSF, Condor, ...). What this means is that you have to have a resource reference that cannot be obtained from the WSDL in order for our service dispatcher to know what state resource is associated with a particular CreateActivity (or any other BES-Factory operation) call. This is what EPRs are primarily good for. I realize stateless services don't need it, but if EPRs aren't supported then there's no realistic way we can participate seeing as thought we'd have to rewrite GRAM to, I guess, only do fork/exec. I know .Net has support for EPRs (heck, Microsoft was a coauthor for the WS-Addressing spec!), so I don't see this as a huge burden. And as I said before, we are assuming EPRs for the Activity references, so it's a bit puzzling that anybody would use anything else for the factory. I strongly support Peter here on requiring EPRs.
It really shouldn't be that difficult to define a simple (I mean *really* simple!) factory WSDL having one method with no input that returns exactly one EPR. Agreeing on a transport binding shouldn't be that difficult either, shouldn't it? Not to look a gift horse in the mouth, but why are you suggesting a method to retrieve the EPR? I'd still need an EPR to call an operation that returns the service's EPR, so it doesn't make much sense to me. If there's no discovery mechanism, then I'd suggest just writing the EPR to a log file and distributing it from that.
As for a transport binding, I thought we already agreed on anonymous https.
Peter
Implementing that factory should be a finger excercise.
Problem solved?
Cheers, Michel
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
------------------------------------------------------------------------
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
participants (4)
-
Christopher Smith -
Michel Drescher -
Peter G. Lane -
Richard Ciapala