[OASIS Issue Tracker] (CAMP-218) Enumerate use cases wrt external DBs, shared DB, components, services, assemblies and their relationship

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ https://issues.oasis-open.org/browse/CAMP-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anish Karmarkar updated CAMP-218:
---------------------------------

    Issue Type: New Feature  (was: Bug)

> Enumerate use cases wrt external DBs, shared DB, components, services, assemblies and their relationship
> --------------------------------------------------------------------------------------------------------
>
>                 Key: CAMP-218
>                 URL: https://issues.oasis-open.org/browse/CAMP-218
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: New Feature
>            Reporter: Michael Norman
>            Assignee: Anish Karmarkar
>
> Documenting the way we extend CAMP and/or don't use certain features.
> Loosely, an Assembly represents a running program, although in fact the lifecycle of the Assembly allows it to be in a state that hasn't yet been run, or it may be running, or it may be suspended, or it may even be permanently stopped. 
> An Assembly can be instantiated either from a user-defined Plan (in which it would in Cloud Foundry be described as an Application), or from a Plan which is opaque to the Platform (in which case in Cloud Foundry it may be described as a 'Service Instance').
> An assembly has many Ports to which other assemblies may Bind and has many Bindings to other assemblies via their Ports.
> A binding represents the relationship between two running Assemblies, for example an application to database binding or a microservice-to-microservice relationship. 
> An assembly binds to a Port, which is exposed by an Assembly. Ports have characteristics which are used for matching at Assembly instantiation, and thus Ports perform a similar role to Services in the CAMP spec.
> The connections between Assemblies through Ports and Bindings represent the communication between Assemblies at runtime, but do not imply their lifecycle is tied together.  For this we use a direct Assembly to Assembly parent-child relationship.  This is similar to the Assembly/Component relationship except that it allows arbitrary nesting.  
> To support this we have a parent/child relationship amongst Plans. At instantiation the Plan becomesn assembly.  The Service Specification is a specification of a Port, and the  Requirement Specification is a specificaiton of a Binding.
> A use case may be an App (e.g. an instantiated WAR file) in a Cloud Foundry instance connecting to an external Database which has been instantiated in a mySql Instance in a Galera Cluster.
> We would represent the App as an Assembly in the Cloud Foundry, and represent the database as an Assembly, instantiated by another Assembly representing the MySQL instance inside the Galera Cluster represented as a Platform. The database Assembly would expose a Port to which the App would Bind, and operations related to the database itself.  The database Instance assembly would expose operations relating to the database instance, the Galera Cluster Platform would expose Operations relating to the cluster.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)