I'm revising the deployment API. Here are my comments on the GGF13 notes. Feedback welcom. -steve Dejan: Why are we required to invoke "run" on the system. Stuart: it may be possible to come up with a thin client at the portal who could replace naïve users and invoke sequences of these calls. Steve: We could make this a standard option for the create() operation; run after creation. That way you dont need to listen for a response to run something; no need for external workflow/WS-N callbacks to initiate something. Note of course that there is nothing to stop you sending a run() operation to the EPR, even while it is busy instantiating itself; it will be queued for interpretation in whatever state it enters next. Dejan: there is a different state diagram for system and for component model. Stuart, yes, this is required because of the WSRF and not exposing faults to outside world. Dejan: Can you please introduce a few sentences describing your reasoning why there is a difference. steve: I've removed the state model from the deployment API. Stuart: WS component or endpoint reference should be instead of xsd:any for system epr resolveRequest.sic services, Steve: I'd kind of envisaged that you could resolve to anything, beyond just a component. So if I resolve to an attribute of a component, I get that attribute back. Do you imagine the operation to just get the component EPR that you talk to directly? That would just be the special case where you resolve the name of a component. (including /, the root component of the app). Question (Dejan) : What about CDL across multiple deployment engines? Steve: The deployment API is designed so that you can delegate stuff across to different engine clusters inside an existing deployment descriptor. That is, you could write a meta-descriptor that would delegate stuff to one framework impl, different bits to another. Question (Dejan) : Can SmartFrog be translated into CDL? -A subset can. There are some things in the smartfrog language that do not map. Question (Dejan) : Can you envision GUIs for writing CDL? Steve:Any graphical thing with boxes and lines doesn't scale past the simple demo. Case in point: BizTalk, UML design tools. Certainly you could enhance an XML editor. Question (Dejan) : Will we provide verification tools? Steve: XSD validation is relatively easy, apart from the bits where extra types are defined inline/in the <types> section. This is why the xsd:any bits in the configuration/system elements are marked as processContents=lax; to tell a validating parser to skip validating those bits. Validating that is more complex. The other bit of validation is parse time matching of all non-lazy references, and evaluation of expressions. These dont show up in the XSD, and need interpretation to validate. Question : How difficult is it to implement this? Steve:I think dynamic typing (with extra XSD) is going to be tricky. Not impossible (WSDL processors do it), just fiddly. You need to extract/generate the schemas, add them to parser dynamically and then get it to validate the docs. Steve: I expect that my GGF14 implemenation will not do this. That is, it wont fail if the deployment descriptor doesn't match the XSD-defined <types>. typing via attribute declarations in the templates is probably easier. We need test documents for both of these. comments from Keisuke Fukui (ACS Chair) - people from Naregi will a driving force - ACS and CDDLM have tight relationship -- especially: addfile operation, deployment API Steve: addfile is a very primitive file upload mechanism; but it is simple enough to work without too much engineering effort. Note that there is nothing to stop an implementation or third party components providing extra library integration. As an example, here is smartfrog supporting dynamic download of verisioned artifacts from the Maven2 repository, home to all the open source JAR files #include "/org/smartfrog/services/filesystem/components.sf" #include "/org/smartfrog/services/os/java/components.sf" #include "/org/smartfrog/services/os/java/library.sf" sfConfig extends Compound { sfSyncTerminate true; library extends Maven2Library { } commons-logging extends JarArtifact { library LAZY PARENT:library; project "commons-logging"; version "1.0.4"; sha1 "f029a2aefe2b3e1517573c580f948caac31b1056"; md5 "8a507817b28077e0478add944c64586a"; } axis extends JarArtifact { library LAZY PARENT:library; project "axis"; version "1.1"; sha1 "edd84c96eac48d4167bca4f45e7d36dcf36cf871"; } tcpmonitor extends Java { classname "org.apache.axis.utils.tcpmon"; classpath [ LAZY axis:absolutePath, LAZY commons-logging:absolutePath]; logLevel 5; } } Here I am declaring that I want axis1.1 and commons-logging 1.04, the pair of them forming the classpath for a JVM. This is working code incidentally, the maven2 library is http://ibiblio.org/maven2 ; the maven2 library component contains the policy to construct a full URL for each artifact, the artifact components themselves download/cache the JAR files at initialization time, then the tcpmonitor program runs using the classpath to the cache. Repository management is an interesting area of ongoing work. If the ACS group is interested, they could join in the Apache mailing list, repository@apache.org, which has de-facto ownership of the problem of providing a global, mirrored repository of all open source java libraries. It would make a lot of sense if the URLs and signatures of versioned artifacts matched those expected by the next generation of Java applications. Note that the addFile() operation has a metadata element that supports arbitrary XML. This could be RDF metadata, but it could equally well be a Maven2 POM describing an artifact, in the relevant maven2 namespace. If a file were uploaded to a maven2-aware system, the maven2 layout could then be used for download -at the expense of portability across CDDLM implementations.