Next in thread →
Next in month →
Re: [sca-bindings] BINDINGS-118: BWS40005 is ambiguous
Apologies, of course what I should have
said in my reply was that I think its a valid issue ("not otherwise
determined" is NOT clear without any context) so I think we should
open the issue so that we can discuss a proposed resolution. And
when we do, I might point to my previous note as a suggestion ;)
Regards, Simon
Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair,
AT&T and Boeing Lab Advocate
MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK
Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
Internet -
Simon Holdsworth/UK/IBM@IBMGB wrote on 25/02/2010
15:32:38:
> [image removed]
>
> Re: [sca-bindings] BINDINGS-118: BWS40005 is ambiguous
>
> Simon Holdsworth
>
> to:
>
> sca-bindings
>
> 25/02/2010 15:33
>
>
> Anish,
>
> +1 to the statement that if you want the binding to look a
> particular way, then point to a WSDL binding from binding.ws -
> that's the mechanism that has always been there to step outside of
> the simple default behaviour.
>
> The goal of the default rules was to make simple scenarios simple
> and predicatable. Where there are no other constraints, you
can
> just use <binding.ws> on a service and know what you are going
to
> get. Beyond that, point at a WSDL binding. In either case,
its
> still known from the SCA definitions exactly what you are going to
> get. There's also possibly the use of policy to influence the
> binding, which is again at least explicit in the SCA definitions,
> however it seems to me an amount of hoop-jumping vs. just pointing
> at a binding that has been generated as needed. Allowing some
> other mechanism which is not explicit in the SCA definitions to
> influence the WSDL generation for the case where no WSDL is
> referenced leads to unpreditable/non-portable behaviour.
>
> My proposal would be to rewrite BWS40005 to be explicit:
> 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 <> 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
>
>
>
>
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
Next in thread →
Next in month →