[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]