Where will these name symbols be registered? Not sure IANA is a
good place for it.
Ask OASIS to host a registry?
All the best, Ashok
On 11/14/2012 3:05 PM, Adrian Otto wrote:
TC,
Today's follow up comments on the "[camp] Cloud Foundry Core"
thread have inspired me to think a bit more about common
requirements between various CAMP implementations. I recognize
that some of these areas may be beyond the scope of our charter
because they define functional interfaces, but the use of these
functional interfaces would be optional. We might need to have a
discussion about whether we are willing to pursue this even if
it goes beyond our current scope.
Goal: Interoperability. Give application developers a way to
develop applications that will work on numerous CAMP compliant
platforms by referring to generic requirements using a common
set of "name symbols" that are well understood, and generally
high level.
I suggest:
1) We create a definition of "standard" platform component
"name symbols" that name various popular services that many
platforms are likely to offer.
A good example of this would be a hosted MySQL 5.1 service.
In order to strengthen the application portability story with
CAMP, there are more things needed. I suggest we create some
form of a catalog that each implementor of the spec can choose
to populate. The service catalog must be implemented, but the
CAMP specific symbols would not be required to be listed in
the catalog for interoperability purposes only.
Example:
Service Symbol : camp_mysql_5.1
Requirements: Provides MySQL protocol services for
at least one user, password credentials, and one
corresponding logical database. Must be protocol compatible
with MySQL 5.1. ...
Required Component Attributes: [ (string)
hostname, (int) port, (string) username, (string)
database_name, (string) version ] … that are set when the
service boots.
Optional Parameters: [ (string) username, (string)
password, (string) database_name ] … to be passed in when
creating the Component from the Template
2) Specify an API to get the service catalog to list the
relations between the various "name symbols", and the platform
components provided. Perform a GET on the /services resource
(as identified by the Platform resource) to get the service
catalog, which is a JSON representation of an associative
array keyed by "name symbols". Each value in the array would
be an array of Link types that refer to Platform Component
Templates. Exactly one of the link types would be indicated as
a 'default' for that camp_* symbol. This allows the platform
to offer multiple choices for complaint platform components.
Each "name symbol" must have at least one Platform Component
Template listed.
Example:
{
"services"
: {
"camp_mysql_5.1"
: [
],
"camp_linux_apache_2.2"
: [
],
...
}
}
Implementors of the CAMP spec can choose to support the
camp_* "name symbols", or not. Querying the service catalog
and verifying whether the needed symbols are present or not
would be an indication of a given application would be
runnable on a given target platform. If a CAMP compliant
service provider wanted to offer all of the CAMP "name
symbols", they could make at least one Platform Component
Template that supported all of them, and list it for each of
the standard symbols, like I do above with
the Rackspace_Cloud_Server_LAMP Template.
If the application wants to be more specific, and pick a
non-default template, it can GET each of the
PlatformComponentTemplates listed, and find the best one based
on the attributes provided, such as version numbers, version
ranges, memory size, or whatever. These attributes do not need
to be specified. Use of them would be completely optional.
3) Offer an API call for passing in an array of one or more
"symbol names", and if all are offered by the platform, to
return a "200 OK" response with an abbreviated service catalog
that lists the requested "symbol names" along with the arrays
of Platform Component Templates available for each. If one or
more is missing, then a 400 reply is provided, indicating that
one or more of the requested "name symbols" are not supported,
and listing each.
Thoughts? I'm looking forward to discussion on this. If
there is adequate support for it I will submit it as an issue.
Adrian
|