[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: CAMP-4 question (2) - specifying component types
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-7I 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:JBossAS7Here 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:JBossAS7Here 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]