You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2011/10/19 14:34:21 UTC
Default mayProvides
The OASIS spec allows extension types such as bindings and
implementations to describe what intents they allwaysProvide and
mayProvide. There is a wrinkle here that there isn't a way to describe
which mayProvides intents are provided by default if no further
configuration is provided. For example, consider the bindingType
element from the definitions.xml file for binding.ws
<sca:bindingType type="sca:binding.ws"
mayProvide="sca:SOAP sca:SOAP.v1_1 sca:SOAP.v1_2
tuscany:MTOM sca:asyncInvocation"
alwaysProvides=""/>
SOAP.v1_1 and SOAP.v1_2 are mayProvides because it is either/or.
However with no configuration binding.ws will use SOAP.v1_1. So
SOAP.v1_1 is effectively the default.
I seem to feel that this has come up before but it came up this time
because I added function to read <requires> attributes in WSDL files.
Otest POL_4032 defines a reference with a WSDL with
<sca:requires intents="sca:SOAP.v1_1"/>
The reference targets a service that defines no intends but specified
binding.ws. New code that I added to address
https://issues.apache.org/jira/browse/TUSCANY-3959, where we need to
take mayProvides intents into account when matching references with
services fails because the reference has the SOAP.v1_1 intent but the
service doesn't. The service binding implements SOAP.v1_1 by default
but is not explicit about the fact.
I've been toying with adding a new defaultIntents operation to the
interface but in the first instance I've change the binding.ws binding
builder to added the default intent as follows...
boolean addDefaultSOAPIntent = true;
for(Intent intent : ((PolicySubject)binding).getRequiredIntents()){
if (intent.getName().getLocalPart().equals("SOAP.v1_1")){
addDefaultSOAPIntent = false;
break;
}
if (intent.getName().getLocalPart().equals("SOAP.v1_2")){
addDefaultSOAPIntent = false;
break;
}
}
if (addDefaultSOAPIntent){
Definitions systemDefinitions = context.getDefinitions();
if (systemDefinitions != null){
BindingType bindingType =
systemDefinitions.getBindingType(binding.getType());
Intent defaultIntent = null;
for (Intent intent : bindingType.getMayProvidedIntents()){
if (intent.getName().getLocalPart().equals("SOAP.v1_1")){
defaultIntent = intent;
}
}
if (defaultIntent != null){
((PolicySubject)binding).getRequiredIntents().add(0, defaultIntent);
}
}
}
This seemed like a more flexibly way of achieving the required result.
In theory and set of default intents or policy sets can be added in a
bindings builder.
Anyhow I felt the need to at least document the the progress of this
rather contrived change and invite comments.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Default mayProvides
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Oct 19, 2011 at 2:42 PM, Greg Dritschler
<gr...@gmail.com> wrote:
> Aren't binding builders run before the policy builder? If so, the binding
> builder will have a hard time figuring out whether to add the default intent
> because intents specified at higher levels (above the binding) won't have
> been propagated down yet.
> Greg
>
Hmmm, good spot. So if we're to do this in the builder we would need
to have a separate operation that comes after that policy processing
step. The problem then is that the endpoint/endpoint reference model
is inconsistent. It probably doesn't matter for mayProvides but it
seems untidy. I'm thinking then I should switch to the other option of
putting an operation on the model that returns the default intent so
that, if all else fails, the runtime can ask what the default is, if
there is one. The default won't then appear in any of the intent lists
and of course there won't be any policy as we're just talking about
mayProvides intents here.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Default mayProvides
Posted by Greg Dritschler <gr...@gmail.com>.
Aren't binding builders run before the policy builder? If so, the binding
builder will have a hard time figuring out whether to add the default intent
because intents specified at higher levels (above the binding) won't have
been propagated down yet.
Greg
On Wed, Oct 19, 2011 at 8:34 AM, Simon Laws <si...@googlemail.com>wrote:
> The OASIS spec allows extension types such as bindings and
> implementations to describe what intents they allwaysProvide and
> mayProvide. There is a wrinkle here that there isn't a way to describe
> which mayProvides intents are provided by default if no further
> configuration is provided. For example, consider the bindingType
> element from the definitions.xml file for binding.ws
>
> <sca:bindingType type="sca:binding.ws"
> mayProvide="sca:SOAP sca:SOAP.v1_1 sca:SOAP.v1_2
> tuscany:MTOM sca:asyncInvocation"
> alwaysProvides=""/>
>
> SOAP.v1_1 and SOAP.v1_2 are mayProvides because it is either/or.
> However with no configuration binding.ws will use SOAP.v1_1. So
> SOAP.v1_1 is effectively the default.
>
> I seem to feel that this has come up before but it came up this time
> because I added function to read <requires> attributes in WSDL files.
> Otest POL_4032 defines a reference with a WSDL with
>
> <sca:requires intents="sca:SOAP.v1_1"/>
>
> The reference targets a service that defines no intends but specified
> binding.ws. New code that I added to address
> https://issues.apache.org/jira/browse/TUSCANY-3959, where we need to
> take mayProvides intents into account when matching references with
> services fails because the reference has the SOAP.v1_1 intent but the
> service doesn't. The service binding implements SOAP.v1_1 by default
> but is not explicit about the fact.
>
> I've been toying with adding a new defaultIntents operation to the
> interface but in the first instance I've change the binding.ws binding
> builder to added the default intent as follows...
>
> boolean addDefaultSOAPIntent = true;
>
> for(Intent intent : ((PolicySubject)binding).getRequiredIntents()){
> if (intent.getName().getLocalPart().equals("SOAP.v1_1")){
> addDefaultSOAPIntent = false;
> break;
> }
> if (intent.getName().getLocalPart().equals("SOAP.v1_2")){
> addDefaultSOAPIntent = false;
> break;
> }
> }
>
> if (addDefaultSOAPIntent){
> Definitions systemDefinitions = context.getDefinitions();
> if (systemDefinitions != null){
> BindingType bindingType =
> systemDefinitions.getBindingType(binding.getType());
> Intent defaultIntent = null;
> for (Intent intent : bindingType.getMayProvidedIntents()){
> if
> (intent.getName().getLocalPart().equals("SOAP.v1_1")){
> defaultIntent = intent;
> }
> }
>
> if (defaultIntent != null){
>
> ((PolicySubject)binding).getRequiredIntents().add(0, defaultIntent);
> }
> }
> }
>
> This seemed like a more flexibly way of achieving the required result.
> In theory and set of default intents or policy sets can be added in a
> bindings builder.
>
> Anyhow I felt the need to at least document the the progress of this
> rather contrived change and invite comments.
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>