playing with Oasis CAMP PDP syntax

0-three-tier-as-yaml.txt

# yaml variant, similar to #3 below, with an explicit load balancer
# this format makes it much easier for mortals to read and write,
# based significantly on https://wiki.openstack.org/wiki/Heat/DSL
name: "Hello WebApp Cluster with Database"
components:
  # key here equivalent to supplying a map with this as the value for key 'id'
  hello_war:
    content: hello.war
    requires:
    - type: com.example.java:WarDeploymentRequirement    # explicit req type says to "deploy"
      fulfillment: id:frontend
  hello_sql: 
    content: hello.sql
    type: com.example.database:Schema   # here, type of component defined
    requires: id:backend                # assume Schema defines default req type "DB"
  frontend:                # "platform component" implied by WarDeplReq above
    requires:
      database:            # frontend type must recognise a named "database" req
        mode: CDI          # assume that req supports various injection modes
        fulfillment: id:backend
      com.example.lb:LoadBalanced:     # longhand req form: this is the 'type'
        protocol: https                # assume that type recognises these attributes
        algorithm: round-robin
        sticky-sessions: true
        fulfillment: id:lb
  lb: { tags: [ "load-balancer" ] }    # tag it so we can monitor it afterwards

1-simple-webapp.json.txt

SIMPLE: org.java:WAR is a defined type, extending ApplicationComponentType,
perhaps developed through the JCP.  its definition might look like:
> WAR extends ACT defining one additional attribute, "content", 
> giving a link to the binary archive content of the WAR,
> and containing a PCR of id "appserver" and type org.java:AppServerRequirement.
> it’s _SPEC_ (i.e. what is specified in the PDP) takes a link to the content
> which may be external or may be local in which case the file:/ protocol is used;
> the URL supplied in the spec may be different to the URL returned by the 
> WAR ACT, but the content is guaranteed to be the same

with that defined, a PDP ZIP containing a hello-world.war and 
a "camp.json" file with the following content would create a launchable hello-world app:

[ {
	"type": "org.java:WAR",
	"content": {
		"type": "link",
		"href": "/hello-world.war"
		// some discussion whether we want to have file:/// 
		// (or something else like  thiszip:///  )
	}
	// (implicit requirement for an appserver)
} ]

2-cluster.json.txt

a webapp running in a cluster, with sticky sessions, and presenting a given certificate:

[ {
	"type": "org.java:WAR",
	"content": { "type": "link", "href": "file:///hello-world.war" },
	"requirements": [
		{ "type": "org.java:AppServerRequirement",
		  "id": "appserver",
		  // this is now extending the requirement
		  // overriding default values set in the parent requiremnt
		  "clustered": true,
		  "stickysessions": true,
		  "protocols": ["https"],
		  // this requirement is also performing a configuration role:
		  "certificate": { "type": "link", "href": "id:certificate" }
		}
	]
}, { 
	// the type Certificate extends AppComponentTemplate
	// and has two attributes, "private.cert" and "passphrase"
	"type": "org.java:Certificate", 
	"id": "certificate",
	"private.cert": { "type": "link", "href": "file:///server.crt" },
	"passphrase": "foo"
} ]

3-fairly-advanced-withDB-and-VM-config.json.txt

COMPLEX: specify that VM of appserver(s) where WAR is deployed has a minimum amount of RAM
         and a database with indication of how they should be wired together (and in a way
         that multiple such DB's, messaging systems, JNDI, etc can be supported)

[ {
	"type": "AssemblyTemplate",
	"id": "MyAt1", // (optional user supplied id, locally scoped only)
	"applicaitonComponentTemplates": [
		{ "type": "link", "id": "hello-war" },
		{ "type": "link", "id": "hello-schema" }
	]
  }, {
	"type": "org.java:WAR",
	"id": "hello-war",
	"content": { "type": "link", "href": "file:///hello-world.war" },
	"requirements": [
		{ "type": "org.java:AppServerRequirement",
		  "id": "appserver",
		  // this is now saying _how_ the requirement will be fulfilled
		  "fulfilment": { "type": "link", "href": "id:hello-appserver" }
	}
  }, {
	"type": "org.jboss:JBoss7Server",
	"id": "hello-appserver",
	// this component is used to fulfill the AppServerRequirement on the WAR
	// that requirement defines that the WAR will be deployed to this instance
	"requirements": [
		{ "type": "VirtualMachineRequirement",
		  "id": "vm",
		  // TRANSIENT DEPENDENCY
		  // this requirement is defined by JBoss7Server
		  // but here we are extending it to need more memory
		  // and look for a specific tag on the image
		  "minRam", "8192m",
		  "imageTagsRequired": [ "iluvjb" ]
		},
		{ "type": "AppserverDatabaseRequirement",
		  // this requirement specifies that a database be created
		  // it is configurable in a variety of ways
		  // WIRING: these (below) tell how the AppServer should be told where the DB is
		  "dbUrlInjectionMode": "jvmSystemProperty",
		  "dbUrlInjectionJvmSystemProperty": "my.apps.db",
		  // as before we are going to indicate the DB we require
		  "fulfilment": { "type": "link", "href": "id:hello-db" }
		},
  }, {
	"type": "PlatformComponentTemplate",
	// we are not indicating the concrete implementation of this instance
	// that will be decided by the platform based on its requirement;
	// the id below forces it to be something which fulfills AppserverDatabaseRequirement
	// (ie it will be the platform's preferred database PCT)
	"id": "hello-db"
	// we will now indicate some SQL to run
	// note we are doing this in the opposite way to how we did for the WAR
	// ie the PCT runs the SQL whereas the WAR forces the APPSERVER
	// (either is fine)
	"requirements": [ {
	  "type": "DatabaseSqlExecution",
	  "content": { "type": "link", "href": "id:hello-schema" }
	} ]
  }, {
	"type": "ApplicationComponentTemplate",
	"id": "hello-schema",
	"content": { "type": "link", "href": "file:///hello-world.sql" }
} ]

add'l req from anish, url can refer to the containing bundle. e.g.

"content": { "type": "link", "href": "self:" }

need scheme for loading objects in other jsons

adrian and gil notes: needs package signing

comments:

• multiple components referring to the same requirement instance (means all components share same fulfillment, i.e. the same database, or same message bus -- very useful)
• requirement pointing to multiple components

hmmm after discussions at openstack summit i think it's got to be yaml and there are some cool proposals floating around there, see e.g. https://wiki.openstack.org/wiki/Heat/DSL

activity has migrated to https://github.com/ahgittin/heat-hot-dsl-prototyping