Allow fine grained update of services in a deployment

[dreedyman]

Consider I deploy the following (pseudo) opstring (for argument's
sake, file-based deployment in the Rio deployments directory):

deployment(name:'My Deployment')
{
service(name: 'Service A')
{
interfaces
{
classes 'com.my.A'
artifact ref: 'a-dl'
}

 implementation(class:'com.my.AImpl') 
 { 
     artifact ref: 'a' 
 } 

 maintain 1 

}

service(name: 'Service B')
{
interfaces
{
classes 'com.my.B'
artifact ref: 'b-dl'
}

 implementation(class:'com.my.BImpl') 
 { 
     artifact ref: 'b' 
 } 

 maintain 1 

}
}

And I then make a change to Service B. Now, most changes people are
likely to make over time is to simply refer to a newer version in the
artifact declaration, but let's consider a more explicit change of
implementation class. So I change the opstring, and Rio's deployment
scanner picks up the updated file:

deployment(name:'My Deployment')
{
service(name: 'Service A')
{
interfaces
{
classes 'com.my.A'
artifact ref: 'a-dl'
}

 implementation(class:'com.my.AImpl') 
 { 
     artifact ref: 'a' 
 } 

 maintain 1 

}

service(name: 'Service B')
{
interfaces
{
classes 'com.my.B'
artifact ref: 'b-dl'
}

 // Implementation class Changed 
 implementation(class:'com.my.alt.AlternativeBImpl') 
 { 
     artifact ref: 'b-alt' 
 } 

 maintain 1 

}
}

Is it reasonable to assume that my instance of A will not be
destroyed / re-created, but that only B will? Now, consider A having
an association to B, as follows:

deployment(name:'My Deployment')
{
service(name: 'Service A')
{
interfaces
{
classes 'com.my.A'
artifact ref: 'a-dl'
}

 implementation(class:'com.my.AImpl') 
 { 
     artifact ref: 'a' 
 } 

 association( type: 'requires', serviceType: 'com.my.B', 

property: 'b', name: 'Service B')

 maintain 1 

}

service(name: 'Service B')
{
interfaces
{
classes 'com.my.B'
artifact ref: 'b-dl'
}

 implementation(class:'com.my.BImpl') 
 { 
     artifact ref: 'b' 
 } 

 maintain 1 

}
}

If I then re-deploy with a changed B (as in the previous example), is
it still safe to assume that A will be left intact, and that it will
simply be associated with a new B thereafter?

if I may dwell on a previously-mentioned detail, a very typical
requirement will be to change a deployment to refer to a newer version
of an artifact (say after a bugfix) - so a new opstring will be
deployed where nothing but the artifact identifier has changed (e.g.
"com.my:artifact:1.1" -> "com.my:artifact:1.2"). What would the
redeployment behaviour be in this case?

In an environment where we have a number of core services running,
with several customisations / additions for each of our clients, we
are trying a strategy where we have a single opstring for the core
environment (specifying all the services and SLAs) and a single
opstring for each client (specifying all additional services and
SLAs). There would be a certain elegance to a single set of deployment
requirements, totally separate from the code base. We are thus not
following the typical example model where every service specifies its
own opstring, instead building libraries of components which separate
opstrings may "draw from". In such an approach, it's vital that we can
change the deployment requirements, without unnecessarily destroying a
large number of services that have not changed.