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

[Jim Marino <jim.marino@gmail.com>]

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
>> 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.

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