[OASIS Issue Tracker] (CAMP-196) should links attribute of collection resource be consumer mutable

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

    [ https://issues.oasis-open.org/browse/CAMP-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60472#comment-60472 ] 

Michael Norman commented on CAMP-196:
-------------------------------------

I think at the core of this is that a component can be in multiple assemblies. If this is the case, then we have a many-to-many relationship, and It is worth thinking what this actually means.  Based on conversations with Alex, I think we are dealing with two very distinct notions: instantiation and  binding.  As an example we consider two running applications (assemblies) that are bound to the same messaging service (component), which is I think a common use-case that the model would seek to represent.

There are two possible scenarios, either
1) the messaging service component was instantiated by the instantiation of one or other of the application assemblies
2) the messaging service component was instantiated separately from either application assembly, of which there are two subcases
a) the messaging service component was instantiated by the instantiation of a third assembly
b) the messaging service component was instantiated in a way that is not represented in the model - these might be viewed as Platform Services

So, in all cases  zero-or-one assemblies instantiate each component, and an assembly instantiates one-to-many components, and so far we haven't actually changed the API.

We can then move to the question of how we represent the fact that an assembly consumes a service component.  Here it is clear that actually it is not the assembly that is consuming the service component, it is one or more components within the assembly, so on the face of it we a many-to-many relationship amongst components.  This component-component relationship I would naturally represent through an intermediate entity known as a service binding.  A component has zero to many service bindings, a service is bound to by zero to many components.  The creation and deletion of a service binding entity represents the binding of a component to a service component, and we will be able to use our existing POST-style API calls to create one of these (i haven't worked through the details).

Then I come to the question  of why we want the notion of a service binding to exist separately in the model f.  Is it a real entity? or is it just an result of having a many-to-many relationship? So I think this is a real entity because the way that the service binds to the component may be different for different components bound to the same service.  For example, they may use different credentials, or we may want to distinguish between them so that we can independently bill each service user.
 



> should links attribute of collection resource be consumer mutable
> -----------------------------------------------------------------
>
>                 Key: CAMP-196
>                 URL: https://issues.oasis-open.org/browse/CAMP-196
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>            Reporter: Tom Rutt
>            Assignee: Tom Rutt
>
> The resolution to issue 192 has the links attribute of the collection resource as Mutable true.
> However it does not make a requirement for it to be consumer mutable true or false.
> In cases of shared components, the administrative user may need to update the collection member links



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