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.
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).
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).
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.
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.
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.
- 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.
- 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.
- an implementation allows non-SCA means to affect WSDL generation,
but otherwise conforms to the defined default. The customer will know
where they've done this customization, and will not be surprised by the
result.
- 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.
-Eric
On 02/11/2010 03:26 PM, Anish Karmarkar wrote:
4B749243.6030600@oracle.com" type="cite">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
|