Hi Gil-
I think this would all be fine. Concrete example:
webapp1 needs sql1 installed in a DB
webapp2 needs sql2 installed in a DB
your platform "foo" resovles this by giving me two different
db's. perhaps on two different vm's.
your platform "baz" however sets up one db on a vm, with the two
different sql's installed.
(and another platform "boo" might have a cloud database service
which it uses.)
Beyond this there are ways to say this should be:
- the same (currently you use fulfillment pointing to the same
spec)
- different (could use fulfillment pointing to different spec
components; or someone could have an "unshared" requirement)
- up to the platform (don't use fulfillment -- ie the default)
It is hinting towards a close correspondence between component
specs and components (or at least injective). That is how I am
thinking of it, although (currently) it is not mandated. WDYT?
--A
On 16/04/2013 15:40, GILBERT PILZ wrote:
Suppose there was a PDP that contained to Components, A and B.
Suppose A had a requirement X and B had a requirement Y.
We register this PDP on platform "Foo". For whatever reason, the
implementation of Foo represents A and B as separate Application
Component Templates. After completing the registration operation,
Foo contains a ACT-A (corresponding to Component A) and a ACT-B
(corresponding to Component B). It turns out that Foo had PCTs
that were good matches for X and Y, PCT-X and PCT-Y respectively.
Either by auto-wiring or my direct manipulation by the Application
Admin, ACT-A gets linked to PCT-X and ACT-B gets linked to PCT-Y.
Now suppose we register our PDP on platform "Baz". For whatever
reason, the implementation of Baz rolls A and B up into a single
ACT. Although Baz has combined A and B into a single ACT, it must
preserve the requirements of each component - so ACT-AB would have
two requirements, X and Y. If you resolved these requirements
against PCTs (assuming Baz has the appropriate PCTs), you would
see ACT-AB linked to both PCT-X and PCT-Y.
None of this addresses how the code and configuration in A and B
actually go about connecting to or using the service represented
by the PC that the PCT is a template of - but that's a separate
issue.
~ gp
On 4/13/2013 9:17 AM, Alex Heneveld
wrote:
Hi Gil-
How do you see Component Templates getting pulled in to apps?
I was thinking if someone just specifies requirements the
platform chooses but where the user gives a component spec
then I think it has to be obeyed. eg if I need to disambiguate
between 2 database instances -- easy if I can spec that there
will be two components (not saying the type but speccing that
they provide a DB requirement) and I can say to have tags
"db1" and "db2" put on them, but hard if I don't have that
insight -- and that would seem important if I, say, need to
manage them afterwards (bearing in mind this is a management
API!).
If there's a better way I'm eager to see it. However I would
be disappointed if we can't support this still-fairly-simple
use case.
Best,
Alex
|