OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sca-assembly] Issue 37 proposal - a response



OK Folks,

This finally stirs me into action.

I have said this on the calls previously, but I want to get it into an email so that it's there in black & white.

The use case that I see being excluded by this approach to the Domain is the ability for the configuration
of a Domain level reference which is a common point for a reference to some service external to the domain
and which carries common configuration information that is then used by a number of references from
multiple domain level components.  This seems a clear use case to me and I don't think that the proposal
deals with it adequately - or rather, it removes it completely, which leaves me unhappy.


Contribution 1 - contains the Domain reference
-------------------------------------------------------------------------

<refererence name="DomainRef1" promotes="component1/ref1 component2/ref2 component3/ref3">
        <interface.wsdl interface="http://foo.com/bar#wsdl.interface(ref1name)"/>
        <binding.wsdl uri="http://foo.com/bar/ref1endpoint"/>
</reference>

-------------------------------------------------------------------------

Other contributions....
-------------------------------------------------------------------------

<component name="component1">
        <implementation.xxx .../>
        <reference name="ref1"/>
</component>

<component name="component2">
        <implementation.yyy.../>
        <reference name="ref2"/>
</component>

<component name="component3">
        <implmentation.zzz .../>
        <reference name="ref3"/>
</component>

-------------------------------------------------------------------------

The proposal makes Contribution 1 illegal or "of no meaning", with the result that I am forced to put that binding
configuration onto all of the component references directly.  The fact that all 3 components are using the same
external service is now lost.  Bad show.  We really lost something here.


==========================================
*WARNING*  Dangerous invention ahead
==========================================

If folk want to propose an alternative way of getting this same function, like the use of a "gateway" component,
then I'd like to see that proposal brought forward before I'll be happy to approve the current proposal for
Issue 37.

Let me think of something:

<component name="DomainRef1">
        <implementation.gateway interface=""http://foo.com/bar#wsdl.interface(ref1name)"/>
        <service name="service"/>
        <reference name="reference">
                <binding.wsdl uri="http://foo.com/bar/ref1endpoint"/>
        </reference>
</component>

implementation.gateway is parameterized by an interface definition.  This interface defines the interface
which applies to the single (fixed) service offered by the gateway (name = "service" always) and the single
reference offered by the gateway (name="reference" always).  

The implementation.gateway is deployed as a component into the domain.  Its service can be targeted
by any domain component reference (assuming interface compatibility).  Its reference can be configured
with any appropriate binding and endpoint target information.

How "implementation.gateway" is provided is left to the SCA runtime.  Is a "hop" implied?  I'd say "no",
but I'm open to persuasion.

I note that in principle the implementation.gateway could be used as a domain level service as well.
The usecase for this is less strong, although it could be a way of providing stable external exposure of
services on well-known URIs, independent of the vagaries of changing internal implementations.

==========================================
End of dangerous invention.


Let's see how you like or dislike that......   ;-)


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



Anish Karmarkar <Anish.Karmarkar@oracle.com>

20/05/2008 09:03

To
OASIS Assembly <sca-assembly@lists.oasis-open.org>
cc
Subject
[sca-assembly] Issue 37 proposal





Dave and I took an AI to send a proposal for issue 37. This proposal is
based on what was outlined in previous calls. I haven't had time to
consult with Dave on this, so all errors are mine.

-----
Deployable composites can contain promoted references and promoted
services. Promoting a service or a reference in the virtual domain-level
composite has no meaning. When such deployable composites containing
promoted references and/or promoted services are deployed in the domain
the SCA RUNTIME MUST ignore the promotions. The promoted services and
references are not part of the virtual domain-level composite.

Note that a deployable composite can contain composite properties,
components, include elements and wires, which when deployed to the
domain become part of the virtual domain-level composite.
-----

-Anish
--

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and 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








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]