[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (CAMP-183) Decouple the Plan Repository from the Platform
[ https://issues.oasis-open.org/browse/CAMP-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60531#comment-60531 ]
Gilbert Pilz edited comment on CAMP-183 at 8/13/15 7:58 PM:
------------------------------------------------------------
I think we may be talking past each other due to what I now see as a flaw in the spec. The current WD of the spec defines the following two things as "the same thing":
------ Thing 1 -----
name: VitaMinder
description: Vitamin and Supplement Tracking
camp_version: CAMP 1.1
origin: http://www.oracle.com/nCAMP/Hand
artifacts:
-
name: VitaMinder WAR
artifact_type: com.oracle.nCAMP:WAR
content: { href: VitaMinder.war }
requirements:
-
requirement_type: com.oracle.nCAMP:ConnectTo
com.oracle.nCAMP.dbName: SupplDB
JNDIResourceName: VitaDB
fulfillment:
id: db
characteristics:
-
characteristic_type: com.oracle.nCAMP:MySQL
-
requirement_type: com.oracle.nCAMP:HostOn
fulfillment:
characteristics:
-
characteristic_type: com.oracle.nCamp:ServletContainer
-
name: Supplement SQL
artifact_type: com.oracle.nCAMP:SQL_script
content: { href: supplDB.sql }
requirements:
-
requirement_type: com.oracle.nCAMP:LoadInto
fulfillment: id:db
-----
----- Thing 2 -----
{
name: "VitaMinder",
type: "plan",
uri: "http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/Plan/115";,
description: "Vitamin and Supplement Tracking",
camp_version: "CAMP 1.1"
origin: "http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/Plan/115";,
artifacts: [
{
name: "VitaMinder WAR",
artifact_type: "com.oracle.nCAMP:WAR",
content: {
href: "http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/pkgs/VitaMinder/VitaMinder.war";
},
requirements: [
{
requirement_type: "com.oracle.nCAMP:ConnectTo",
JNDIResourceName: "VitaDB",
fulfillment: {
id: "db",
characteristics: [
{
characteristic_type: "com.oracle.nCAMP:SQL",
version: "org.ansi.SQL:2008"
},
{
characteristic_type: "com.oracle.nCAMP:MySQL",
version: "5.5.21"
}
],
href: "http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/Service/97";
},
com.oracle.nCAMP.dbName: "SupplDB"
},
{
requirement_type: "com.oracle.nCAMP:HostOn",
fulfillment: {
characteristics: [
{
servletVersion: "3.0",
javaVersion: "1.6.0_33",
characteristic_type: "com.oracle.nCamp:ServletContainer",
jspVersion: "2.2"
},
{
characteristic_type: "com.oracle.nCAMP:Tomcat",
version: "7.0.29"
}
],
href: "http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/Service/96";
}
}
]
},
{
name: "Supplement SQL",
artifact_type: "com.oracle.nCAMP:SQL_script",
content: {
href: "http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/pkgs/VitaMinder/supplDB.sql";
},
requirements: [
{
requirement_type: "com.oracle.nCAMP:LoadInto",
fulfillment: "id:db"
}
]
}
],
}
-----
It's pretty obvious that Thing1 and Thing2 have the same structure and carry much of the same information, but there are some important differences:
* Due to its references, Thing2 is bound to the Platform at "http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/.."; Some of the referenced resources may not even be visible to other users of this Platform, much less visible to or usable by actors outside that Platform.
* Thing1 is deliberately designed to be portable to other Platforms. It's requirements are general; they can be satisfied by any service that matches the stated characteristics. Thing2 is designed to be a specific description of exactly what will be instantiated when you use it to create an Assembly. The difference between "../Service/97" and "../Service/98" could involve a good deal of money.
* While it makes sense to manage Thing1 and other things like it are outside the scope of a particular Platform, I don't think it makes sense to manage Thing2 and other things like it outside of the Platform that contains the (majority of) resources that it references.
While it is accurate to say that Thing2 is derived from Thing1 I think it is misleading to say they are the same thing. We confuse ourselves and the readers by referring to them by the same name. I think some renaming is in order. For example, we could continue to call Thing1 a Plan and call Thing2 a Schematic. We could then say things like "Schematics are a created from Plans by POSTing Plans to the schematic_factory resource."
was (Author: gilbert.pilz):
I think we may be talking past each other due to what I now see as a flaw in the spec. The current WD of the spec defines the following two things as "the same thing":
------ Thing 1 -----
name: VitaMinder
description: Vitamin and Supplement Tracking
camp_version: CAMP 1.1
origin: http://www.oracle.com/nCAMP/Hand
artifacts:
-
name: VitaMinder WAR
artifact_type: com.oracle.nCAMP:WAR
content: { href: VitaMinder.war }
requirements:
-
requirement_type: com.oracle.nCAMP:ConnectTo
com.oracle.nCAMP.dbName: SupplDB
JNDIResourceName: VitaDB
fulfillment:
id: db
characteristics:
-
characteristic_type: com.oracle.nCAMP:MySQL
-
requirement_type: com.oracle.nCAMP:HostOn
fulfillment:
characteristics:
-
characteristic_type: com.oracle.nCamp:ServletContainer
-
name: Supplement SQL
artifact_type: com.oracle.nCAMP:SQL_script
content: { href: supplDB.sql }
requirements:
-
requirement_type: com.oracle.nCAMP:LoadInto
fulfillment: id:db
-----
----- Thing 2 -----
{
name: "VitaMinder",
type: "plan",
uri: "http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/Plan/115";,
description: "Vitamin and Supplement Tracking",
camp_version: "CAMP 1.1"
origin: "http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/Plan/115";,
artifacts: [
{
name: "VitaMinder WAR",
artifact_type: "com.oracle.nCAMP:WAR",
content: {
href: "http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/pkgs/VitaMinder/VitaMinder.war";
},
requirements: [
{
requirement_type: "com.oracle.nCAMP:ConnectTo",
JNDIResourceName: "VitaDB",
fulfillment: {
id: "db",
characteristics: [
{
characteristic_type: "com.oracle.nCAMP:SQL",
version: "org.ansi.SQL:2008"
},
{
characteristic_type: "com.oracle.nCAMP:MySQL",
version: "5.5.21"
}
],
href: "http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/Service/97";
},
com.oracle.nCAMP.dbName: "SupplDB"
},
{
requirement_type: "com.oracle.nCAMP:HostOn",
fulfillment: {
characteristics: [
{
servletVersion: "3.0",
javaVersion: "1.6.0_33",
characteristic_type: "com.oracle.nCamp:ServletContainer",
jspVersion: "2.2"
},
{
characteristic_type: "com.oracle.nCAMP:Tomcat",
version: "7.0.29"
}
],
href: "http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/Service/96";
}
}
]
},
{
name: "Supplement SQL",
artifact_type: "com.oracle.nCAMP:SQL_script",
content: {
href: "http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/pkgs/VitaMinder/supplDB.sql";
},
requirements: [
{
requirement_type: "com.oracle.nCAMP:LoadInto",
fulfillment: "id:db"
}
]
}
],
}
-----
It's pretty obvious that Thing1 and Thing2 have the same structure and carry much of the same information, but there are some important differences:
* Due to its references, Thing2 is bound to the Platform at "http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/.."; Some of the referenced resources may not even be visible to other users of this Platform, much less visible to or usable by actors outside that Platform.
* Thing1 is deliberately designed to be portable to other Platforms. It's requirements are general; they can be satisfied by any service that matches the stated characteristics. Thing2 is designed to be a specific description of exactly what will be instantiated when you use it to create an Assembly. The difference between "../Service/97" and "../Service/98" could involve a good deal of money.
* While it makes sense to manage Thing1 and other things like it outside the scope of a particular Platform, I don't think it makes sense to manage Thing2 and other things like it outside of the Platform that contains the (majority of) resources that it references.
While it is accurate to say that Thing2 is derived from Thing1 I think it is misleading to say they are the same thing. We confuse ourselves and the readers by referring to them by the same name. I think some renaming is in order. For example, we could continue to call Thing1 a Plan and call Thing2 a Schematic. We could then say things like "Schematics are a created from Plans by POSTing Plans to the schematic_factory resource."
> Decouple the Plan Repository from the Platform
> ----------------------------------------------
>
> Key: CAMP-183
> URL: https://issues.oasis-open.org/browse/CAMP-183
> Project: OASIS Cloud Application Management for Platforms (CAMP) TC
> Issue Type: Improvement
> Components: Spec
> Affects Versions: 1.2
> Reporter: Michael Norman
> Assignee: Michael Norman
> Priority: Critical
>
> At the moment a Platform has many Plans, and a Plan belongs to a Platform. We would like to decouple the notion of a Plan Repository from a Platform. So a top-level entity (which we refer to as an Enterprise) would have zero or many Platforms, and also have zero or many Plan Repositories. A Plan Repository would have zero or many Plans (and so on through the child entities of a Plan). An Assembly would instantiate a Plan (loosely, a Plan would have zero or more Assemblies in zero or more Platforms). Then everything is back to the existing domain model.
--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]