Re: [sdd] Alternate definition of artifact

[Christine Draper <cdraper@us.ibm.com>]

There's a "thing" that gets passed to the hosting environment, with a bunch of parameters to customize it, in order to perform a lifecycle operation. The "thing" is everything the hosting environment needs, other than the parameters which provide variability. It may simply be a binary image, or an archive of multiple files. It may be a script (e.g. BAT, Perl), a set of instructions or a declarative definition of a resource to be created (e.g. DDL file, queue definition file). It may include metadata needed by the hosting environment (e.g. EAR).

For some lifecycle operations, it may not be necessary to pass a "thing" at all, simply some parameters. This would be particularly true for uninstall/rollback, but could be true for some create operations.

The "thing" is distinct from the declarative information which is part of the SDD and that is used to plan the change, although this may duplicate information in the "thing". The "thing" is about executing a leaf node of the change plan.

We could try to subdivide the "thing" into "instructions/definitions" and "real content that continues to exist in some form in the hosting environment". I think this is perhaps where the disagreement is. I don't see the value of doing this. From an SDD perspective, I want to declare that each hosting environment knows how to deploy things of specified types. I don't care about the internal structure of the "things". I care about what types of "thing" can be processed (so I can create a valid SDD), and the resources that result (so I can plan deployments). There may not be a clear 1:1 - e.g. a DDL script may create multiple tables in an existing database. An image may expand to multiple instances of installed software. There may be multiple "things" that can result in the same resource (ZIP, InstallShield exe...).

I am using "artifact" to mean "thing". We could change to another name... but I think we need a term for it.

BTW, the implementation of IUDD V1 did go down the path of separating the instructions and the "real content". We found this was not a good approach at the IUDD level, even if it would likely be a good approach if we were defining a new artifact type (e.g. a standard cross-platform OS install format). It led to us creating "wrappers" for perfectly good existing artifact types, for no benefit. Anyway, if the SDD supports the concept of operating on opaque "things" of defined types, it can accommodate "things" with or without the separation into instructions and real content.

My opinion :-)

Regards,
Christine



Senior Technical Staff Member
IBM, 11501 Burnet Road, Mail Point 901-6B10
Austin, TX 78758
1-512-838-3482 tl 678-3482
James Falkner <james.falkner@sun.com>

James Falkner <james.falkner@sun.com>

04/20/2006 09:58 AM

To	sdd@lists.oasis-open.org
cc
Subject	Re: [sdd] Alternate definition of artifact

I am in agreement with Julia.  We need a definition of payload if we
are going to use it in the context of another definition.

In my opinion, end users who are deploying solutions
don't care how it works -- they care that the appropriate bits are
put in place and the appropriate services are started.  I consider the
"appropriate bits" as the payload.  Everything else (the SDD, the RPM
metadata, etc) is just ancillary to the ultimate goal of getting the
bits laid down and services started.

In other words, when I hear "payload" I think of that as the
"appropriate bits" that the end user is interested in deploying,
not the support metadata and "helper applications" that help (aid)
in getting the payload in place.  payload == the load that pays.

When I hear "artifact" I think of all the ancillary, helper bits that
aid in getting the payload deployed, but aren't of interest to the
end user doing the deployment, and don't typically live on to see the
light of day after deployment operation is complete.

So, I am uncomfortable with including "payload" as part of the
artifact definition.  I think of artifact as anything that
is not the "payload".  Artifacts are short-lived, helper stuff (SDD XML,
deployer tools, XSLTs used at deploy time, etc) used to get
the bits in place (or "perform a lifecycle operation on a resource").

-jhf-

Christine Draper wrote:
> How about:
>
> *Artifact:* zero or more files representing the payload (e.g. binary
> content, instructions, definitions, scripts) necessary to perform a
> lifecycle operation on a resource.
>
> Regards,
> Christine
>
>
> Senior Technical Staff Member
> IBM, 11501 Burnet Road, Mail Point 901-6B10
> Austin, TX 78758
> 1-512-838-3482 tl 678-3482
> Inactive hide details for Julia McCarthy/Raleigh/IBM@IBMUSJulia
> McCarthy/Raleigh/IBM@IBMUS
>
>
>                         *Julia McCarthy/Raleigh/IBM@IBMUS*
>
>                         04/19/2006 06:44 PM
>
>
>
> To
>
>
> cc
>
> sdd@lists.oasis-open.org
>
> Subject
>
> Re: [sdd] Alternate definition of artifact
>
>
>
>
> This proposal depends on the definition of payload. You seem to be
> defining it as only the solution content that is so closely similar to
> the resulting solution resources that people think of it as the same thing.
>
> Note that even when the package content is closely similar to the
> deployed resource, it is never the same thing. A file in a package is
> not the same thing as a file created in a filesystem. To my thinking,
> all of the content of a solution package is instructions for creating
> the solution. The instructions might happen to be a list of the exact
> bits that will be created on the file system - for example, a readme
> file that gets created in a particular location by copying the set of
> bits included in the solution package. I don't yet see any value in
> distinguishing between instructions that are closely similar to the
> resulting resource and instructions that are clearly different from the
> resulting resource. And since I don't see value in that distinction, I
> am not inclined to define payload as only the solution content that is
> closely similar to the resulting solution resources. Which means I am
> not inclined to agree with your proposal.
>
> Julia McCarthy
> Tivoli Development
> Deployment Engine Design
> julia@us.ibm.com
> 349/8156
> 877-261-0391
>
>
>
> Inactive hide details for "Josh Allen" <jallen@macrovision.com>"Josh
> Allen" <jallen@macrovision.com>
>
>                                                 *"Josh Allen"
>                                                 <jallen@macrovision.com>*
>
>                                                 04/19/2006 07:23 PM
>
>
> To
>
> <sdd@lists.oasis-open.org>
> cc
>
> Subject
>
> [sdd] Alternate definition of artifact
>
>
>
>
> Hi all,
>
> On the call today I suggested an alternative definition of the term
> *artifact* that might help us feel more comfortable with this term. At
> request I've included it here for review:
> *
> Artifact:* zero or more files representing a payload and if necessary a
> set of instructions about how to use that payload to perform a lifecycle
> operation on a resource.
>
> Thanks,
> Josh
>