[cddlm] updated deployapi tests

[Steve Loughran]

hello,

I've just checked in some changes to the deploy API

-added some more tests related to initialisation (what I was working on )

-moved some tests down into the informative category, like the one that 
says 'you must be able to create more than one application 
simultaneously', as that is not actually part of the spec.

I note that I dont have any tests yet for the resolve operation. that is 
a mistake I will have to correct. If anyone can define some tests next 
week,feel free to do so and stick them in the document.

I am busy running the latest version of my client against the hp and the 
ourgrid endpoint. the NEC endpoint is not responding to me, either the 
firewall is blocking incoming calls or the endpoint is not there. The 
endpoint is successfuly demonstrating that my client stack does not 
implement timeouts, which is something I will have to fix.

When I get back from my vacation we can start on the interop document. 
Something like

-copy of the ogsa-dai interoperability intro
-test methodology
-different implementations
-summary of tests (table)
-test result summary (appendices containing the <junitreport> results or 
similar.


Findings
  -we can demo interop between two implementations
  -things like WSRF, base faults and WS-N are problematic as they arent 
consistently implemented
  -SOAP stacks throw SOAPFaults when they feel like it, even if the spec 
mandates BaseFaults
  -Without a rigorous taxonomy of which fault to throw for which 
problem, its hard to be sure that different implementations fail for the 
expected reasons on any test that expectgs failure.
  -security. Its hard to turn security on during interop testing.
  -system load. testing clients can overload the server.
  -how do you test WS-Notification works if you are calling from behind 
a firewall?
  -discuss on what is the best model client-side. High latency links 
show the limitations of RPC as a metaphor, but what alternatives are 
there. State machine? Model the remote resources with proxy classes that 
cache (and refresh) properties?
  -unclear semantics of wsrf:Destroy in a fault tolerant world.

Future enhancements to the deploy API that testing raises
  -the hostname hint is confusing and impossible to test. If you can't 
test it works, lets drop it.
  -it would be good to have an option on addFile to declare the URL to 
which a document 'pretends' to live
  -an alternate notification mechanism (jabber/xmpp?) that goes through 
firewalls.
  -WSRF property to list all wsrf properties on a resource

Thoughts?

-steve