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