[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] BINDINGS-118: BWS40005 is ambiguous
In the event that the transport details are not determined by use of the @wsdlElement attribute, policy intents, or extensions to the binding.ws element, an SCA runtime MUST enable the default transport binding rules.
This then ensures at least that the
WSDL for the following are predictable:
<binding.ws/>
<binding.ws uri="http://....."/>
<binding.ws><endpointReference>...</endpointReference></binding.ws>
Anish Karmarkar <Anish.Karmarkar@oracle.com>
wrote on 24/02/2010 23:00:54:
> [image removed]
>
> Re: [sca-bindings] BINDINGS-118: BWS40005 is ambiguous
>
> Anish Karmarkar
>
> to:
>
> sca-bindings
>
> 24/02/2010 23:06
>
> My responses inlined below.
>
> -Anish
> --
>
> On 2/11/2010 6:04 PM, Eric Johnson wrote:
> > Hi Anish,
> >
> > Let me see if I can give a specific example.
> >
> > Our current rules include this one:
> > "For SOAP 1.1 messages, the SOAPAction HTTP header described
in section
> > 6.1.1 of [SOAP11] represents the empty string, in quotes ("");"
> >
> > For the purposes of some intermediary that examines the content
of a
> > message before it arrives at the SCA provided SOAP/HTTP endpoint,
that
> > intermediary may need the SOAPAction value to be non-empty (I
am
> > imagining a security intermediary, like Amberpoint). Perhaps
this
> > constraint applies to all services hosted on a particular machine,
due
> > to network configuration.
> >
>
> The reason for using empty quotes is for interop and for security,
so
> this, I think, is a bad example to bring up. A security intermediary
> that insists on a value for SOAPAction HTTP header should go stand
in
> the corner :-)
> But I completely understand what you are trying to get at with this
example.
>
> > Unless I've missed it, I don't have any SCA way, in any SCDL
files, to
> > specify a set of constraints that apply to a particular host
(I'm weak
> > on SCA policy, I admit).
> >
>
> I think Dave already answered this.
>
> > How, then might this be indicated to the SCA runtime? I
can throw some
> > vendor specific file into an SCA contribution, and add that to
the SCA
> > Domain. Or I could try to put something into the originating
composite
> > file, but that could be the wrong place to put this information,
as it
> > is a deployment concern not covered by the SCA specification).
> >
>
> I view extensions (by that I'm including intents, policy sets, extension
> elements in the composites etc), as addressing all the things that
the
> spec does not cover. So this seems like a good use of extensions.
>
> > If we limit the controls on WSDL generation, then I cannot satisfy
this
> > scenario without somehow stepping out of the box you've just
force us into.
> >
>
> I would just point to a WSDL binding, which allows me to specify the
> value of SOAPAction. The WSDL generation then just requires generating
> the WSDL service part.
>
> But of more importance is: why do we have the default transport
> rules/wsdl generation algorithm?
> I don't think the default WSDL transport/generation affects portability.
> But it does allow for consistent generated WSDLs across implementations.
> From that perspective, I think, it makes sense to require that
> deviation from defaults be explicitly specified. Otherwise I don't
see
> the point of us specifying a default.
> I hope I'm not completely misunderstanding your point. If I have,
apologies.
>
> > Also, we risk pushing this particular scenario into the trivial
here.
> > We've defined a default databinding that only applies when it
is a bare
> > element. If we over-constrain this, I suspect a vendor's
response is
> > something like the following (a completely made up example):
> >
> > <binding.ws tibco:customize="true" />
> >
> > Sure, the vendor can "support" <binding.ws />
as a bare element, but due
> > to the limitations that you'd insist on imposing on it, we may
never see
> > our SCA users employ it that way, and instead it will for all
practical
> > purposes show up like the above. Vendors can then claim "conformance",
> > but will encourage their customers to never use the bare element.
> >
>
> I think this to be a good thing. Vendors should be explicit (either
via
> intents, policy sets, or extensions similar to the one in the example).
> That way a user is very clear that they are using Tibco's (or any
one
> else's) extension and the behavior is different from what is specified
> in the spec.
>
> If you wanted to enable allowing one to change the default rules without
> extensions/intent/policy set, why are we defining a default? I don't
see
> the point in doing that. I don't want a vendor to be able to say that
it
> didn't follow the rules because it was high tide on a blue moon night.
>
> > Here's how I see this breaks down, then. For the bare <binding.ws
/>
> > element something like the following:
> >
> > * The ?wsdl endpoint becomes a conformance placeholder,
and the
> > useful WSDL generation and customization
moves somewhere else -
> > "?real-wsdl" for example.
>
> I think this is a fine choice. Perhaps "?customized-wsdl"
to not make it
> sound like "?wsdl" is a fake wsdl ;-)
>
> > * WSDL generation may only be affected by policy.
Vendors will then
> > define their own policies that affect the
output, or not allow
> > customization of <binding.ws /> WSDL
generation, and force some
> > sort of flag (as I did above with @customize)
everywhere people
> > might want to customize, however trivially.
In fact, composite
> > developers will likely just put this flag
on whether or not it
> > applies, just so they can dynamically customize
at runtime.
> > o This form will not migrate
from vendor to vendor, either
> > because those custom
policies will not be supported, or
> > because @customize
has such an open-ended meaning.
>
> Couldn't you just install a customization policy at the domain? This
> would move the customization out of the composite (and the contribution)
> making it completely portable.
>
> > * an implementation allows non-SCA means to affect
WSDL generation,
> > but otherwise conforms to the defined default.
>
> This is exactly what I have a problem with. It essentially says: it
> conforms to the default, expect when it doesn't.
>
> > The customer will
> > know where they've done this customization,
and will not be
> > surprised by the result.
>
> Not sure I understand. An implementation may decide to have its own
> default (which is different than SCA default) and require that customers
> do something explicit (perhaps change an implementation specific config
> file) to change that. In such a case, how would the customer be aware
> that they changed the default?
>
> > o Migration to new SCA environments
will be mostly correct.
> >
> > This last option sounds like the best one to me.
> >
> > I understand your point about this potentially being too open-ended,
but
> > I don't see how you avoid over-constraining if you require more
than we
> > have.
>
> Maybe what we need to discuss is -- what is the motivation for providing
> a normative default and what it achieves
> (portability/consistency/interop/??). Or do we need more of a
> non-normative suggestion.
>
> >
> > -Eric
> >
> >
> > On 02/11/2010 03:26 PM, Anish Karmarkar wrote:
> >> On 2/11/2010 8:50 AM, Eric Johnson wrote:
> >>> Hi Anish,
> >>>
> >>> On 02/10/2010 08:34 PM, Anish Karmarkar wrote:
> >>>> On 2/10/2010 6:02 PM, Eric Johnson wrote:
> >>>>> All right, now that it is logged, I can be first
to comment....
> >>>>>
> >>>>> This seems obvious to me, and potentially easy
to over specify. The
> >>>>> introductory paragraph to section 4 already spells
out possibilities.
> >>>>> Do the possibilities need to be specified as
part of the normative
> >>>>> statement?
> >>>>
> >>>> Not necessary to inline it, we could just point to
it. The problem I
> >>>> have with the text in section 4 is that it doesn't
say that it is an
> >>>> exhaustive list. We are talking about what the runtime
MUST do in
> >>>> 40005. The current wordings in section 4 leave enough
wiggle room for
> >>>> vendors to create extensions outside the lines that
we draw for vendor
> >>>> extensions and get away with it. For example, what
if a vendor had a
> >>>> proprietary side file/configuration file that contained
default
> >>>> transport details (which were different than what
is in 4.2) and no
> >>>> extension in the<binding.ws> element.
> >>>
> >>> I can think of two answers here.
> >>>
> >>> 1) What you describe is one way of conceiving of policies.
I can just
> >>> define new vendor-specific policy intents, or even just
new policies,
> >>> and apply them. Seems like you can characterize
this as "proprietary
> >>> side file/configuration file" if you wish to be
pejorative.
> >>>
> >>
> >> I think creating new policies, intents, SCA extensions or
WSDL
> >> extensions are just fine. And good ways to innovate through
extensions.
> >> What we are trying to do is define the default rules -- rules
used
> >> when nothing else is specified. Nothing else being: extensions,
> >> wsdlElement, URL, intents, policies. If the default changes
from
> >> system to system and if there are ways to specific an
> >> implementation-specific default that is transparent to the
user, I
> >> don't think it helps. For example, if an SCA implementation
is
> >> installed with a SOAP 1.2 flag, whereby the default is SOAP
1.2, then
> >> there is no way of knowing that by looking at all the artifacts
in the
> >> contribution. I.e., not portable. Furthermore, if we have
a test for
> >> this and run that test against such an impl, it will fail,
but the
> >> creator of the implementation can legitimately say that the
bug is in
> >> the test -- since we leave a huge escape hatch by saying
'... not
> >> otherwise determined ...' in the normative stmt.
> >>
> >>> 2) WSDL defined endpoints have the unique characteristic
amongst
> >>> everything that we're talking about, in that they can
serve as
> >>> compatibility entry points for the universe of non-SCA
clients. So it
> >>> may be very useful for a vendor to allow for customizing
the generated
> >>> WSDL in one way or another that isn't really amenable
to policy intents,
> >>> although I suppose you could invent a policy description
language that
> >>> was sufficiently capable to allow for any flexibility.
We could require
> >>> that vendors must express these customizations in a policy
document, but
> >>> that would seem to be a requirement that should be in
the assembly or
> >>> policy spec, not in bindings.
> >>>
> >>
> >> I don't quite follow this. This is the case where the SCA
Binding
> >> doesn't specify a WSDL binding/service/port. If the vendor
doesn't
> >> want to generate the WSDL per our default rules, the SCDL
(or
> >> something pointed to by the SCDL) has to tell the WSDL generating
> >> algorithm how to generate the WSDL. Not sure why WSDL's unique
> >> characteristics are relevant here.
> >>
> >> -Anish
> >> --
> >>
> >>> -Eric.
> >>>
> >>>>
> >>>> -Anish
> >>>> --
> >>>>
> >>>>>
> >>>>> Is there really an issue here?
> >>>>>
> >>>>> -Eric.
> >>>>>
> >>>>>
> >>>>> On 02/10/2010 05:56 PM, Eric Johnson wrote:
> >>>>>> Logged as: http://www.osoa.org/jira/browse/BINDINGS-118
> >>>>>>
> >>>>>> -Eric.
> >>>>>>
> >>>>>> On 02/10/2010 04:33 PM, Anish Karmarkar wrote:
> >>>>>>
> >>>>>>> Title: BWS40005 is ambiguous
> >>>>>>>
> >>>>>>> Spec: WS Binding
> >>>>>>>
> >>>>>>> Description:
> >>>>>>> BWS40005 says --
> >>>>>>> "In the event that the transport
details are not otherwise
> >>>>>>> determined,
> >>>>>>> an SCA runtime MUST enable the default
transport binding rules."
> >>>>>>>
> >>>>>>> It is not clear as to under what conditions
the transport details
> >>>>>>> are
> >>>>>>> not otherwise determined
> >>>>>>>
> >>>>>>> Proposal:
> >>>>>>>
> >>>>>>> List the conditions that lead to this.
> >>>>>>>
> >>>>>>>
> >>>>>>> -Anish
> >>>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe from this mail list, you must
leave the OASIS TC that
> >>>>>> generates this mail. Follow this link
to 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. Follow this link to 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. Follow this link to 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]