RE: [sca-assembly] Composition Question

["Peshev, Peter" <peter.peshev@sap.com>]

Hi Michael,

well, the sample was from the ws.binding spec 

There all the sample interface are interface.java, perhaps an issue can
be raised to have at least one interface.wsdl  as a sample

Peter

-----Original Message-----
From: Michael Rowley [mailto:mrowley@bea.com] 
Sent: Wednesday, 27. February 2008 16:10
To: Peshev, Peter; Mark.Hapner@Sun.COM; OASIS Assembly
Subject: RE: [sca-assembly] Composition Question


I agree with Peter, although in this case I would expect the interface
to be interface.wsdl, pointing at the PortType of the same WSDL that
defines the Stock Quote endpoint (or Google Search, Paypal payment,
etc).

Michael

-----Original Message-----
From: Peshev, Peter [mailto:peter.peshev@sap.com] 
Sent: Wednesday, February 27, 2008 4:07 AM
To: Mark.Hapner@Sun.COM; OASIS Assembly
Subject: RE: [sca-assembly] Composition Question

Hi Mark

In my opinion such exposure of business logic offered on the web by
someone else should not be represented as SCA service.

The recommended way to consume such functionality would be via a binding
that should define the mapping to some standard or vendor specific
protocol

   <reference name="StockQuoteService">
      <interface.java
interface="services.stockquote.StockQuoteService"/>
      <binding.ws uri="http://www.sqs.com/StockQuoteService";
                  requires="soap/1.2"/>
   </reference>

In my view the composition and assembly usecase should target only
contributions within a domain, which is made from a single runtime
implementation.

Best Regards
Peter

-----Original Message-----
From: Mark.Hapner@Sun.COM [mailto:Mark.Hapner@Sun.COM] 
Sent: Wednesday, 27. February 2008 01:25
To: OASIS Assembly
Subject: [sca-assembly] Composition Question

When an SCA component uses a service provided by some entity on the  
web say Google Search, Paypal payments, or any service it expects is  
available for access via the net, this dependency is fundamentally  
different from using a 'service' whose implementation it expects to be  
'composited' with in a deployable bundle.

SCA expects services in a composite to provide the full range of SCA  
metadata and to be 'typed' so that alternative implementations can be  
substituted. Services on the net are often provider specific. No one  
expects to be able to substitute a NetSuite CRM data service for a  
SalesForce CRM data service, i.e. there are no service 'types' on the  
net - just unique service instances.

Clearly, implementing services that rely on network services that you  
have no control over and that are unique is a very common case.

I don't seem to find anything in the SCA assembly spec that formally  
treats this case as a 'first class' part of the service composition  
problem. At best, it seems to be treated as a degenerate case that SCA  
doesn't need to deal with beyond what is already defined by Soap,  
WSDL, etc.

Is this the case, or does SCA provide metadata that simplifies  
composing these, by definition, non-compositable, services? Is it  
correct to say that SCA is focused on composing service  
implementations into composite deployment bundles and leaves  
composition across independent, network services to other  
technologies? Is it expected that network services will find it useful  
to provide SCA 'typing' metadata even though they will never be  
'instanced' with properties nor 'composed' within SCA composites?

-- Mark



---------------------------------------------------------------------
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 


---------------------------------------------------------------------
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