[cddlm] comments on the GGF13 notes

[Steve Loughran]

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