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
- From: Simon Nash <NASH@uk.ibm.com>
- To: "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
- Date: Tue, 20 May 2008 15:15:18 +0100
+1 for Mike's use case. However,
I'm not sure why we would remove a capability that currently exists, and
then add back a new construct that provides the same capability.
I'd like to present a use case for allowing
promotion to be meaningful on the service side. ( I believe this
is more compelling than the case I described last week.) I have a
composite C containing components A and B. B provides a service S
using the default binding. A contains a reference R wired to S, also
using the default binding. S is promoted to a composite service T,
and a <binding.ws uri=....> is applied to T. Composite C is
deployed to the domain by inclusion. If T is deployed as part of
the deployment of C rather than being ignored, this allows S to be accessible
outside the domain as a Web service endpoint as well as inside composite
C using the default binding.
So here is my proposal.
When deployable composites are deployed
in the domain, the SCA RUNTIME MUST deploy all of the contents of the composite,
including any promoted references and/or promoted services.
Simon
Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156 Fax +44-1962-818999
Mike Edwards/UK/IBM@IBMGB
20/05/2008 12:12
|
To
| "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
|
cc
|
|
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
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]