On Jun 2, 2009, at 5:36 AM, Mike Edwards wrote:
Jim,
I am concerned that the word "deploy" is being used loosely here.
I have tried to distinguish between the states
"Installed"
"Deployed"
"Running"
and my issue is about what it is valid for a runtime to do with artifacts in each of these states.
I *THINK* you are arguing that it should be *ALLOWABLE* for an SCA runtime to check artifacts
in a Contribution as it is installed - and refuse to install the contribution if it finds artifacts with errors.
Yes but we need to be clear about what "installed" means. Installed for me means exports are visible in the domain and deployables are ready for deployment. This implies the contribution has been introspected.
As a side note, I also think the states you specified above need clarification but that is a separate issue so I will not go into it here.
I am arguing the opposite - ie it should be REQUIRED that an SCA runtime installs a contribution
even if it contains artifacts with errors. I have no problem with a runtime that reports the errors - but
I do have a problem with one that refuses to install the contribution.
One big concern that I have over this install error reporting process is any hint that errors involving multiple
artifacts will be reported (eg involving comparison of a component declaration in a composite with
the componentType of the artifact providing the implementation). I don't think that this should be allowed.
All such errors are game for deployment time, but not before.
I note that the error checking process will have to be done at deployment time anyway, so doing some
checking ahead of time will probably not save very much.
Not exactly. Some errors can be checked ahead of time, such as an invalid component implementation. Those errors are never resolvable unless the artifact is modified.
I am arguing that a runtime should be allowed to report those errors in such a way that it refuses install the contribution in the domain. Other errors which can only be determined by the current state of the domain, such as wiring errors, must be reported at deployment. For the latter, rules already exist to ensure this is done (e.g. the wiring rules).
I think we need to take a step back and look at what we would be trying to achieve by *requiring* a runtime to allow contributions containing identifiable errors to be made available in a domain. In my view, runtimes should be allowed to wait until deployment to report errors, but they should not be forced to.
In fact, forcing a runtime to not report errors that can be detected upfront until deployment would be imposing behavior most people do not want and even prohibit. This discussion has come up in TC meetings on several occasions and others - including SCA users - have voiced their opinion that requiring this behavior would be a bad thing. This is consistent with the projects I am currently involved with. These projects have very strict datacenter requirements and such runtime behavior would never be accepted. Given our customer requirements, if Fabric3 were forced to adopt this behavior in order to be conformant with SCA, we would elect to forgo conformance on that point.
Jim
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
Comment below.
Jim
On May 28, 2009, at 1:12 PM, David Booz wrote:
I do not intend these words to eliminate the possibility of one action
which does both install and deploy.
> >> 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.
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.
I can see someone maybe wanting to deploy a contribution containing errors in a test environment but even then I think many people would want the deployment process to fail. In any event, my original point was we shouldn't require a runtime to support deploying contributions containing errors, although this behavior should be allowed. So I think we agree.
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