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


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

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

Subject: Relationship between sca binding/service and WSDL service

Based on the agenda, it looks like I took an action to send an email 
regd the relationship between sca binding/service and WSDL service. I 
believe this was in the context of issue 11. Here are my thoughts:

In SCA, references are wired to services. Services may have bindings 
specified (default to binding.sca) and may have intents/policies 
specified. References may have intents/policies specified.

But in SCA we do not talk about how and where the service is exposed 
(except when an explicit URI is provided). If it is a local interface 
then it may not be exposed at all. A service may be available only with 
the bindings specified in SCDL, it may be made available with additional 
bindings. It may be made available with the same bindings on two 
different network endpoints -- perhaps one for clients inside the 
firewall and another (portmapped) endpoint available outside the 
firewall (perhaps with limited capabilities).

When binding.ws is used, it can specify a network endpoint (through the 
URI attribute or by pointing to a WSDL service/port) or multiple 
endpoints (by pointing to a WSDL service). OR it may not specify the 
endpoint at all (by pointing to a WSDL binding) or using defaults.

If the URL is explicitly provided in the SCDL then of course it is known 
apriori. If not, it is indeed left to the deployer/runtime to do the 
magic, where at runtime the reference knows where the SCA service is 
located. In fact, I believe it is perfectly ok for the runtime to not 
even generate a WSDL service/port element, if the binding.ws pointed to 
a WSDL binding element. All the WSDL service/port is going to do is 
provide the URL and the runtime/deployer may know exactly what value to 
inject automagically and transparently.

All this is to say that we should not impose additional restrictions on 
the generated WSDL service element than those that are required. The 
restrictions that are required are:
1) restrictions imposed by intents.
2) There must be at least one service/port in the generated wsdl that 
matches the SCDL interface and the SCDL binding.

Some of the examples of restrictions that do *not* make sense to me are:
1) how many wsdl documents should be there. Eg the binding and service 
elements can be in the same wsdl or different wsdl (with appropriate 
2) how many ports a service should contain.
3) whether the generated WSDL contains just one service element or many



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