AW: [sca-assembly] Issue 37 proposal - a response

["Barack, Ron" <ron.barack@sap.com>]

+1 to the idea of allowing components deployed into the domain composite to have the bindings associated with their services and references overridden through the use of composite level services and references.

 

I think there is a bit of a disconnect between the meaning of promotion (which I agree, is meanless on the domain level) and the use of the construct, to override the binding provided in the component definition.

 

To make this concrete, I'm imagining a component "A" in the domain.  The component defines a service "aService", but does not specify a binding for it.  I could then deploy the composite

 

<composite ...>

    <service promote="A/aService">

        <binding.ws .../>

     </service>

</composite>

         

Thus, I can define the exposure of A without modifying its contribution.  By examining the services and references at the domain, I have effectively a system overview of the exposure of my system.

 

I can understand the problem with the semantics, but is there anything that is actually broken that is motivating us to remove functionality?

 

Ron

 

---

Von: Simon Nash [mailto:NASH@uk.ibm.com]
Gesendet: Dienstag, 20. Mai 2008 16:15
An: OASIS Assembly
Betreff: Re: [sca-assembly] Issue 37 proposal - a response

+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