esmith4@inf.ed.ac.uk wrote:
Hey all,
Our client/server implementation is largely complete (in the loosest sense of the word - much of the client code is of abysmal quality due to the tightness of the deadline at the end).
One feature that struck me as potentially useful in the CDDLM standard would be support for querying the deployment descriptor that the application came from. With all the security caveats aside, this is a fairly useful feature for long running services from a usability issue. Having just completed our client, I shied away from providing this functionality out of band or through one of the xsd:any loopholes CDDLM provides for various reasons. But it would be very useful to be able to query the deployment descriptor, perhaps through an optional element in the application description. Having that element strongly typed and available in WSDL would make it all a lot easier to code.
strongly typed to the extent that we let you submit arbitrary XML anyway. Maybe something an app needs to get when it is deployed is access to the bit of the graph that concerns it. Maybe as XML, maybe as a service that you talk to do resolve bits of the system. Which is essentially what smartfrog components do all the time, reading and writing back bits of the graph.
I am also somewhat converted to the magic of application names having written a moderate client now. Its easy to forget how horrific URIs are from an end user perspective and "friendly" names are probably a must. It'll be useful to have the server track them. I suggest that they should just be labels rather than rating at the same level as references: having the server return them in the application info is quite sufficient from the perspective of a client developer, and doesnt raise all the problems that I worried about before.
ah, so you've come round to the option of user-centred names now :)
I'm still working with the API from 10/11/4 so I'm not sure how far the API has progressed since then. A destroy operation in addition to terminate would've been nice, although in the end I didn't have time to implement terminate anyway, infact the only two meaningful operations on our server are "create" and "serverStatus". Its probably useful to support that kind of cut down approach though, as it broadens the scope to include people like us who are more interested in dynamic deployment of static configurations.
I havent done much to that API; still thinking about how to do a WSRF version. I am just setting up a sourceforge repository for all the schemas and some of the docs, so that they are under revision control; maybe even move the spec for the deployment API from .DOC to docbook for easier diffing and PDF/HTML generation. I'll add you as a developer, so you can fiddle with the stuff if you want. Its good to get feedback on what works, what doesnt. and interesting to see how you have applied the API to a slightly different lifecycle. For the curious, I've just been writing distributed JUnit; I can deploy Junit tests on different nodes in a network, then correlate the results into XML files (or other listeners), before XSLTing them into readable content. After test suites run they update their properties with #tests, #errors, #failures, and can be told to enter the failed state if they finish tests with an error/failure; or terminate normally if they fiinished happily. Maybe I'll add a scheduled rerun, though that is arguably a higher order feature for another component. One thing I will say, it is exceedingly painful trying to debug distributed objects, especially when they start doing things like exit when they fail. A troublespot is actually dynamic code loading itself; java doesnt let you easily set breakpoints on unloaded libraries. I know Stuart, MSVisual studio does, but it does need the full path to the DLL; if your deployment framework copies the libraries to a temp dir after validating the signatures, you don't know that full path either. -steve