Re: [sca-assembly] ISSUE 5: component type allows to specify wire targets on references

[Scott Vorthmann <scottv@tibco.com>]

Thank you, Mike... that clarifies some things for me.

Since I neglected this last time... here's the issue link:

http://www.osoa.org/jira/browse/ASSEMBLY-5

Though I have advocated the "implementationDeploymentData" notion in  
the past (modulo the ugly name), that's not what I'm actually  
suggesting this time.  ;-)

Failing to include such metadata in the componentType does not require  
us to specify a separate generic mechanism.  The PHP use-case simply  
requires a mechanism that works in the simple runtime it envisions.

Let's examine that runtime.  It's only notion of contribution appears  
to be a PHP script, which incidentally simultaneously corresponds to  
"installContribution", generation of a deployment composite within  
that contribution, and "add to domain composite".  The use-case  
demands a way to wire the generated components together.  It does not  
demand that the same mechanism works in more capable runtimes (ones  
that understand deployment composites).

No matter what, the use-case demands an annotation of some kind in the  
PHP script to indicate a reference target.  (It also suggests an  
annotation to control the component instance name.)  The question is:  
who defines those annotations?

Possibility A: the vendor building the simple PHP runtime.

Possibility B: the PHP C&I spec.

In either case, I would suggest that the annotations are defined for  
the specific purpose of generating default deployment composites, NOT  
as contributing metadata to the componentType.  Even if the PHP group  
would deem it important to specify support for "simple runtimes", I  
don't feel that it is important for us to support it in Assembly,  
since the concept essentially bypasses most of what Assembly is about.

Call me a purist if you will, but I'd much rather avoid the  
configuration-in-componentType overriding rules completely, and keep  
the model and roles clear and cleanly separated.

Thus my suggestion for issue 5: accept Henning's proposal in the Jira,  
and remove the ability to put targets on componentType references.

Scott


On Dec 2, 2008, at 6:47 AM, Mike Edwards wrote:

>
> Scott,
>
> Thanks for opening the debate on this one.
>
> I think that may main objection here is that if this metadata is NOT  
> included into the componentType information,
> then I believe we are into the business of creating a separate set  
> of metadata (Let me give it a bad name -
> "implementationDeploymentData").  This does not seem to simplify  
> anything - I argue that it makes it much more complex.
>
> Now, for each implementation type, I not only have to specify how  
> the component type is computed from the
> implementation artifact(s), I also have to specify how the  
> "implementationDeploymentData" is computed as well.
>
> How did this help anyone?  What is achieved by the separation of the  
> data?  In my view, nothing except a pile of work.
>
> Not only do I have to say how the implementationDeploymentData is  
> computed - I also have to say how its values
> can be overridden when I reuse the implementation in some new context.
>
> For me, the whole thing is simply and easily handled via the  
> componentType metadata - one single batch
> of metadata about the implementation, which contains configuration  
> defaults in addition to the declaration of
> the configuration points of the implementation.  All that's needed  
> is a single definition of the rules by which a
> component's configuration overrides the default values and we're  
> done...
>
>
> 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
>
>
> From:
> Scott Vorthmann <scottv@tibco.com>
> To:
> OASIS Assembly <sca-assembly@lists.oasis-open.org>
> Date:
> 02/12/2008 07:55
> Subject:
> [sca-assembly] ISSUE 5: component type allows to specify wire  
> targets on references
>
>
>
>
>
> Re: my action item 2008-10-30-5, to create a proposal for a potential
> solution for issue 5
>
> I've been trying to reconstruct our discussion from the F2F, but I
> need a little help from others present.  (I cannot find my notes, and
> they were pretty minimal in any case.)
>
> According to my recollection, Mike likes wire targets on references in
> a componentType to support what I'll call the "PHP use-case": a very
> simple deployment mechanism of dropping files in a folder.  In that
> scenario, the developer and deployer are likely to be the same user,
> so the developer may reasonably know what services the deployer has
> deployed.
>
> I don't dispute the use-case, but I suggested (IIRC) that the simple
> deployment mechanism would necessarily consist of generating some
> deployment artifacts from the annotated PHP script dropped in the
> folder, and those generated artifacts need not be limited to a
> ComponentType; a deployment Composite could just as easily be
> generated, and that could easily represent the wire that the deployer
> included via annotation.  Put another way, PHP script annotations need
> not be restricted to producing a ComponentType, and could, in fact,
> produce a default deployment Composite.
>
> This is where my memory runs out, and I'd like to ask Mike to remind
> me what his counterpoint was... I've lost it.
>
> I suggest that we carry this discussion on via email, rather than
> wasting time on the call.
>
> Scott
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
>
>
>
>
>
> 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
>
>
>
>
>
>