CAMP-4 question (2) - specifying component types

[Alex Heneveld <alex.heneveld@cloudsoftcorp.com>]

Folks-

And here is an explanation of question 2, and options -- which we've not 
really discussed much though the question has been hinted at.

(And don't worry, I'm not preparing to send thoughts on 3-7 at this 
point!  If we can hammer out 1 and 2 then we start to be in good shape I 
think.)

Best
Alex


Re (2) how to express component specifications (abstract, interfaces, etc)

So far we've focussed on artifact-initiated use cases, i.e. "here's my 
script/war/xxx, run it".
If we consider a different use case, where a container/service is 
requested and configured
to run against a file or even a code repo, we get some different pressures.

Taking OpenShift as an example we might say:

    specifications:
    - name:  MyApp
      type: com.redhat.openshift:App
      cartridge: jbossas-7


I end up with a git repo which, when I push to it, causes the project to 
be built and deployed.  But where's the portability? Well, there are a 
couple of salient traits here as I see it, let's say:

        org.example.repo.git:NewProject
        org.example.paas:DeployFromSource
        org.jboss.mixin:JBossAS7

So where do we see this being represented this?  Some options...


(2a)  "requirements" again - this is what I had been thinking

    specifications:
    - name:  MyApp
      requirements:
      - org.example.repo.git:NewProject
      - org.example.paas:DeployFromSource
      - org.jboss.mixin:JBossAS7

Here the engine evaluates the requirements in order to figure out what 
type the component is.  But there is some overloading as the 
requirements here are subtly different to the requirements we've talked 
about elsewhere -- here they are ON the component type being chosen not 
on the relationships to other components.


(2b)  "provides" - these traits are listed under a _new_ camp-specified 
top-level attribute

    specifications:
    - name:  MyApp
      provides:
      - org.example.repo.git:NewProject
      - org.example.paas:DeployFromSource
      - org.jboss.mixin:JBossAS7


Here the engine looks at a defined attribute ("provides" here; could be 
"types" or "interfaces" or "traits" etc) and uses those to narrow down 
the component types which might be applicable.

So imagining that   com.redhat.openshift:App   supports these traits it 
might be selected.  Or you might get a different PaaS which runs JBoss7 
(like Betfair's AppCloud in the UK which we built).


(2c)  mixins:  just dump a type as an attribute in the component and the 
engine sorts it out (giving an value to the keys)

    specifications:
    - name:  MyApp
      org.example.repo.git:NewProject:
      org.example.paas:DeployFromSource:
      org.jboss.mixin:JBossAS7:

and if these mixins also supported aliases we could also say:

    specifications:
    - name:  MyApp
      newgit:
      org.example.paas:DeployFromSource:
      jboss7:


Thoughts?

To some extent we are moving deck chairs around -- but I submit that's 
useful so long as we're not headed for an iceberg.  :)  This DSL needs 
to be comfortable to sit in.

END