Fwd: Re: [cddlm] deployment API

[Steve Loughran]

esmith4 at 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