OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: Gil's picking components question



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

On Apr 12, 2013 9:40 PM, "Gilbert Pilz" <gilbert.pilz@oracle.com> wrote:
Document Name: camp-spec-v1.1-wd08-issue-4-v2-gp.doc

Description
Comments on Alex's v2 proposal.
Download Latest Revision
Public Download Link

Submitter: Mr. Gilbert Pilz
Group: OASIS Cloud Application Management for Platforms (CAMP) TC
Folder: Proposals
Date submitted: 2013-04-12 13:40:34





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]