Re: [sca-assembly] [NEW ISSUE] Assembly specification unclear onContribution vs Deployment - when can errors in artifacts be reported?

[Simon Nash <oasis@cjnash.com>]

Comments inline.

   Simon

David Booz wrote:
> I like this in general, just a few comments inline in a few places.
> 
> Dave Booz
> STSM, BPM and SCA Architecture
> Co-Chair OASIS SCA-Policy TC and SCA-J TC
> "Distributed objects first, then world hunger"
> Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> e-mail:booz@us.ibm.com
> 
> Jim Marino <jim.marino@gmail.com> wrote on 05/27/2009 02:40:30 PM:
> 
>  > [image removed]
>  >
>  > Re: [sca-assembly] [NEW ISSUE] Assembly specification unclear on
>  > Contribution vs Deployment - when can errors in artifacts be reported?
>  >
>  > Jim Marino
>  >
>  > to:
>  >
>  > OASIS Assembly
>  >
>  > 05/27/2009 02:42 PM
>  >
>  >
>  > On May 27, 2009, at 8:58 AM, Simon Nash wrote:
>  >
>  > > See comment inline.
>  > >
>  > >  Simon
>  > >
>  > > Mike Edwards wrote:
>  > >> Raiser:                        Mike Edwards
>  > >> Target:                        sca-assembly-1.1-spec-cd03.pdf
>  > >> Description:
>  > >> The Assembly Model spec does not have a clear distinction between  
>  > >> the state of a Contribution being contributed to the Domain
>  > >> and the process of deploying one or more artifacts from that  
>  > >> Contribution.
>  > >> The particular problem that has emerged when building the testcases  
>  > >> for the Assembly spec is that it is necessary to define when
>  > >> it is valid to raise an error relating to an artifact that is in  
>  > >> error.
>  > >> It is necessary to say that it is NOT valid to raise an error for  
>  > >> an artifact that is in error when it is merely present within a  
>  > >> Contribution
>  > >> that is contributed to the Domain.  Only artifacts that are  
>  > >> actually deployed can be checked for static errors - and so this  
>  > >> can only
>  > >> take place when deployment occurs.
>  > >> Proposal:
>  > >> Add a new section to the spec after line 3649 as follows:
>  > >> 11.3. States of Artifacts in the Domain
>  > >> Artifacts in the SCA domain are in one of 3 states:
>  > >> 1. Installed
>  > >> 2. Deployed
>  > >> 3. Running
>  > >> Installed artifacts are artifacts that are part of a Contribution  
>  > >> that is installed into the Domain.
>  > >> Installed artifacts are available for use by other artifacts that  
>  > >> are deployed, See "install Contribution"
>  > >> and "remove Contribution" to understand how artifacts are installed  
>  > >> and uninstalled.
>  > >> Deployed artifacts are artifacts that the SCA runtime is given to  
>  > >> execute.  Artifacts are deployed
>  > >> either through explicit deployment actions or through the presence  
>  > >> of <deployable/> elements
> 
> Just want to make sure that the mere presence of <deployable> composites
> in an installed contribution does not automatically cause deployment.
> I think we need to reword to say: "Artifacts are deployed through
> explicit deployment actions."
> 
> I do not intend these words to eliminate the possibility of one action
> which does both install and deploy.
> 
+1 for these clarifications.

>  > >> in sca-contribution.xml files within a Contribution. If an artifact  
>  > >> is deployed which has dependencies
>  > >> on other artifacts, then those dependent artifacts are also deployed.
>  > >> When the SCA runtime has one or more deployable artifacts, the  
>  > >> runtime attempts to put those artifacts
>  > >> and any artifacts they depend on into the Running state.  This can  
>  > >> fail due to errors in one or more of the artifacts
>  > >> or the process can be delayed until all dependencies are available.
>  > >> 11.3.1
>  > >> Checking for errors in artifacts MUST NOT be done for artifacts in  
>  > >> the Installed state (ie where the artifacts are
>  > >> simply part of installed contributions] {ASM120xx]
>  > > This seems over-restrictive.  For example, what about malformed  
>  > > artifacts
>  > > such as .composite files with XML syntax errors?  It might be useful  
>  > > to
>  > > inform the user about such problems when the artifacts are  
>  > > installed, but
>  > > the proposed rule would apparently prohibit an SCA runtime from even
>  > > discovering these problems at installation time.  I think a better  
>  > > rule
>  > > would be to allow such errors to be detected as long as this does not
>  > > prevent any artifacts from being deployed.  For example: Any errors in
>  > > artifacts in the Installed state (i.e., where the artifacts are part  
>  > > of
>  > > installed contributions and have not been deployed) MUST NOT prevent  
>  > > the
>  > > SCA runtime from deploying artifacts.
>  > >
>  >
>  > I agree with the general statement that runtimes should be allowed to  
>  > detect syntactic errors upfront since that is what users would expect  
>  > and want (i.e. contributions should not be installed if they contain  
>  > invalid artifacts). However, I don't follow the part about not  
>  > preventing artifacts from being deployed. Is it the case that an error  
>  > in some random contribution artifact A, does not prevent a composite C  
>  > in the same contribution from being deployed? Many users would want to  
>  > prevent that scenario. For example, I would expect most users would  
>  > only want "clean" contributions in a production environment.
>  >
> I think (I hope) what Simon means is that it's ok for a runtime to
> detect errors at install time (if possible and reasonable) as long as
> it's also possible to go ahead and deploy those artifacts even when
> the deployment engine knows there are errors in the artifacts.
> 
In Jim's scenario above, if A has a known error but C does not have
a known error, I think compliant runtimes should be allowed to deploy
C if requested.  I am leaning towards going further and saying that
compliant runtimes should be required to deploy C if requested.

A more interesting question is if another composite B has a known
error, should compliant runtimes be required or allowed to deploy B
if requested?  I think this depends on the kind of error.  Some
errors might be severe enough to prevent the deployment from
succeeding.  Some errors might be less severe so that it would be
possible to allow deployment, even though some of the resulting
components would not be executable.  The SCA specs should define
which errors fall into which of these categories.

   Simon

> I agree with you Jim, that in a production environment one would not
> want to allow deployment of artifacts with any known errors, but
> in development environments it it often useful to allow this so that
> testing can proceed.  Of course, if the runtime stumbles across one
> of these errors, it should not run the component.  We have language
> to this effect already in the spec.
> 
>  > IMO it is better to only mandate the runtime report errors for  
>  > deploying composites and dependent artifacts but not specify the  
>  > precise point in the deployment process when those errors must be  
>  > raised. Specifically, errors can be raised at install time or the  
>  > actual include/add-to-domain step. In some cases, errors can only be  
>  > raised during the include/add phase. For example, most wiring errors  
>  > (non-existent target) can only be detected at that point. However,  
>  > those cases are already handled by wiring rules.
>  >
>  > Also, if an artifact not in the set of transitive deploying  
>  > dependencies contains an error, the runtime should be free to report  
>  > the error. Actually, I would expect a runtime by default would report  
>  > this error at install-time (in some cases overriding this behavior may  
>  > be required).
>  >
>  > I don't see how this is an issue for the conformance tests since they  
>  > should use runtime-specific mechanisms to perform deployment and  
>  > report back the results of that operation.  I don't completely grok  
>  > the test cases (they seem to make Tuscany-specific assumptions) but my  
>  > thought is they should have some type of SPI that contains an  
>  > interface similar to the following:
>  >
>  > public interface RuntimeBridge {
>  >
>  >    DeploymentResult deployUsingIncludeInDomain(URL contributionUrl,  
>  > Set<QName> deployables);
>  >
>  >    DeploymentResult deployUsingAddDomain(URL contributionUrl, 
> Set<QName>  
>  > deployables);
>  >
>  >    DeploymentResult removeFromDomain(Set<QName> deployables);   // note  
>  > I'm not quite sure about the parameters to this operation but  
>  > deployables seems reasonable
>  >
>  >
>  > // ....
>  >
>  > }
>  >
>  > This SPI interface would be used to drive testing of the domain  
>  > operations (inclusion, addition and removal). DeploymentResult could  
>  > report back expected raised errors. The actual runtime-specific  
>  > implementations could use a single step or multiple steps to perform  
>  > these operations. (As an aside, the name "RuntimeBridge" is probably  
>  > not the most descriptive and It's interesting to note that the  
>  > interface is actually the start of a Java-based deployment API.)
>  >
>  > Given this, I'm not sure the contribution states need to be specified  
>  > at this point. Doing so may provide value but there is also the risk  
>  > of under-specifying them. FWIW, in Fabric3 we use a state-machine  
>  > approach to manage contributions that contains a number of states,  
>  > including stored, installed, deployed, undeployed, uninstalled, and  
>  > removed. A stored contirbution, for example, is not loaded in memory  
>  > and used when a contribution is uploaded to the domain (which can be a  
>  > remote operation) to check integrity. Further, certain operations may  
>  > not be performed if a contribution is in a particular state. For  
>  > example, an administrator cannot remove a contribution without first  
>  > undeploying all contained deployed composites. Properly defining these  
>  > states will likely require significant effort so it may be best to  
>  > defer this until a later revision.
>  >
>  > Jim
>  >
>  >
>  >
>  > >  Simon
>  > >
>  > >> Errors in artifacts MUST be detected either during the Deployment  
>  > >> of the artifacts, or during the process of putting the
>  > >> artifacts into the Running state, {ASM120xx]
>  > >> Yours,  Mike.
>  > >> Strategist - Emerging Technologies, SCA & SDO.
>  > >> Co Chair OASIS SCA Assembly TC.
>  > >> IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great  
>  > >> Britain.
>  > >> Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  Email:  
>  > mike_edwards@uk.ibm.com
>  > >> 
> ------------------------------------------------------------------------
>  > >> /
>  > >> /
>  > >> /Unless stated otherwise above:
>  > >> IBM United Kingdom Limited - Registered in England and Wales with  
>  > >> number 741598.
>  > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire  
>  > >> PO6 3AU/
>  > >
>  > >
>  > >
>  > > ---------------------------------------------------------------------
>  > > To unsubscribe from this mail list, you must leave the OASIS TC that
>  > > generates this mail.  Follow this link to all your TCs in OASIS at:
>  > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>  >
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe from this mail list, you must leave the OASIS TC that
>  > generates this mail.  Follow this link to all your TCs in OASIS at:
>  > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>  >
>