sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-bindings] Re: Proposed resolution to issue 54, attempt #5
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: OASIS Bindings <sca-bindings@lists.oasis-open.org>
- Date: Thu, 7 May 2009 14:57:52 +0100
Simon,
I don't think it is desirable to have
SCA metadata fix the deployment endpoints. (See also Dave B's email
response to my previous email)
I wanted to make the point that THIS
is really the question under debate.
In relation to your proposal for resolution
- I think that this is a classic case for MAY rather than SHOULD - ie an
SCA runtime can decide
whether it wants to implement this piece
of function in any way at all, while still providing guidance to runtimes
that would like A standard
way to do things. SHOULD is not
particularly helpful here.
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
From:
| Simon Nash <oasis@cjnash.com>
|
To:
| OASIS Bindings <sca-bindings@lists.oasis-open.org>
|
Date:
| 07/05/2009 14:35
|
Subject:
| Re: [sca-bindings] Re: Proposed resolution
to issue 54, attempt #5 |
Mike,
In my proposal, it is not possible for SCA metadata to mandate
the runtime deployment endpoint of an SCA service in a normative
fashion for all SCA runtimes on which the SCA metadata might be
deployed. Some SCA runtimes might allow this, subject to
certain constraints on the contents of the URI.
If you think it's desirable to have some form of SCA metadata
that does fix the deployment endpoint (or cause an error to be
raised if the requested endpoint can't be honoured), I'm open
to this as a refinement to my proposal.
Simon
Mike Edwards wrote:
>
> Folks,
>
> I suppose one question here is whether ANY of the SCA configuration
> fixes the final endpoint URI of a service - or is this
> a piece of metadata that is not contained anywhere in the SCA
> configuration data?
>
>
> Yours, Mike.
>
> Strategist - Emerging Technologies, SCA & SDO.
> Co Chair OASIS SCA Assembly TC.
> IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
> Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
> Email: mike_edwards@uk.ibm.com
>
>
> From:
David Booz <booz@us.ibm.com>
> To:
sca-bindings@lists.oasis-open.org
> Date:
07/05/2009 13:50
> Subject:
Re: [sca-bindings] Re: Proposed resolution to issue
54, attempt #5
>
>
> ------------------------------------------------------------------------
>
>
>
> Simon,
> What do you think it means to 'derive the service endpoint URI'?
>
> Suppose:
> <binding.ws uri="http://www.mycompany.com/services/financial"/>
>
> But this configured URI above violates a corporate naming policy or
some
> other policy and so the following endpoint URI is deployed instead:
> _
> __http://www.mycompany.banking.com/accounting/services_
>
> Would you consider the deployed URI to be derived from the configured
> URI? Or would you consider this a case of an SCA Runtime ignoring
the
> SHOULD?
>
> My point is simply that the "SHOULD" and the "derived
from" language are
> redundant.
>
> Dave Booz
> STSM, BPM and SCA Architecture
> Co-Chair OASIS SCA-Policy TC and SCA-J TC
> "Distributed objects first, then world hunger"
> Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> e-mail:booz@us.ibm.com
>
> Inactive hide details for Simon Nash ---05/07/2009 05:53:07 AM---As
> promised, here are some proposed words for service URIs. I Simon Nash
> ---05/07/2009 05:53:07 AM---As promised, here are some proposed words
> for service URIs. I believe these words (together with the
>
> From:
> Simon Nash <oasis@cjnash.com>
>
> To:
> Eric Johnson <eric@tibco.com>
>
> Cc:
> OASIS Bindings <sca-bindings@lists.oasis-open.org>
>
> Date:
> 05/07/2009 05:53 AM
>
> Subject:
> Re: [sca-bindings] Re: Proposed resolution to issue 54, attempt #5
>
>
> ------------------------------------------------------------------------
>
>
>
> As promised, here are some proposed words for service URIs.
> I believe these words (together with the BINDINGS-23 proposal)
> address Mike's comments in
> _http://www.oasis-open.org/apps/org/workgroup/sca-bindings/email/archives/200903/msg00106.html_
> and Dave's comments in
> _http://www.oasis-open.org/apps/org/workgroup/sca-bindings/email/archives/200903/msg00107.html_
>
> The following text is a replacement for lines 284-287 in proposal-06.
>
> - - - - - - - - begin replacement text - - - - - - - - - -
>
> As the first step in determining the URI(s) for a service binding,
> an SCA runtime MUST evaluate the following steps in the order given,
> stopping with the first rule that either raises an error, or
> establishes one or more URIs.
> 1. If the @uri attribute is present
> • and absolute, then use this value for the URI
> • and relative, then use the result of combining this
value
> with the structural URI for the service, relative
to the
> URI of the SCA domain
> 2. If the endpointReference element is present, then use the URI
> from the wsa:Address element contained therein
> 3. If the @wsdlElement attribute is present and references a
> wsdl:port element, then use the URI indicated by the
port element
> 4. Otherwise, use the structural URI for the binding, relative to
> the URI of the SCA domain
>
> As the second step for determining a URI for a service endpoint, the
> SCA runtime needs to assess the URI determined by the above steps.
> The deployment environment, including runtime policies, the target
host,
> and available ports, might constrain the acceptable URIs. Having
> determined a URI from the above steps, the SCA runtime SHOULD either
> use this URI for the service endpoint or derive a service endpoint
URI
> from this URI.
>
> - - - - - - - - end replacement text - - - - - - - - - -
>
> See inline below for other responses to Eric's comments.
>
> Simon
>
> Eric Johnson wrote:
> > Hi Simon,
> >
> > Simon Nash wrote:
> >> Eric Johnson wrote:
> > [snip]
> >>> I'm almost ready to throw in the towel, because
I don't see that we
> >>> can tightly define this in a sensible way. For
services, I'd suggest
> >>> adding text on the order of this:
> >>>
> >>> In determining the URI for a service, implementations
are encouraged
> >>> to attempt to honor the value(s) of @uri attribute,
the URI in a
> >>> wsa:Address element from an endpointReference,
the URI indicated by
> >>> WSDL port via a @wsdlElement attribute references,
and the structural
> >>> URI for the binding.
> >>>
> >>> Comments?
> >>>
> >> I think this is too vague and we need to be more prescriptive.
> >>
> >> I don't think the <binding.sca> case is comparable.
An important
> >> difference is that <binding.ws> is an interoperable
binding, so the
> >> URI used to expose a service with <binding.ws>
is significant for
> >> interoperability with non-SCA clients.
> > To the contrary, though, the URI that appears in a WSDL
is important for
> > interoperability with non-SCA clients. My concern
is that we're trying
> > to define a clear relationship between a URI specified
in the composite
> > document with the one in use at runtime, and generated
in a WSDL.
> >
> In the "first step" part of my proposal above I'm trying
to define
> a clear relationship between all the different ways that a URI can
> be specified in a composite document (including any WSDL that is
> referenced by the composite document). I think it's necessary
for
> the SCA spec to be explicit on this relationship. For example,
> the proposal says that a URI specified in @uri will always take
> precedence over a URI specified in wsdlElement+wsdl.port.
>
> The other aspect to consider is the relationship between the URI
> provided in the composite document (as defined by the SCA spec)
> and the URI used at runtime. I agree that we need to avoid being
> prescriptive on this aspect, and I have attempted to word the
> "second step" paragraph in a way that provides the necessary
> flexibility.
>
> > Fundamentally, my question is this: What use cases
do we have for
> > putting parameters on this relationship? Given all
the time we've spent
> > on this, and the continued vagueness of the problem, I
don't think we
> > have any use cases that affect the specification. The
best use-case I
> > can come up with is that I may want to specify an @uri
value so that at
> > deployment time, I have some indication of a default to
use. Yet I
> > think there are so many ways to solve that problem, and
I don't see any
> > reasons for SCA to specify a particular choice. For
example, I could
> > imagine even defining a deployment time mapping, which
maps URI X -->
> > {base deployment URI}+ path Y. That, however, is
an arbitrary
> > relationship, and there's nothing for us to specify!
> >
> The wording of the "second step" paragraph allows the SCA
runtime to
> do something like this. The SCA spec would only be prescriptive
in
> establishing the precedence of the different ways that SCA documents
> can provide a URI. After that, it's over to the runtime to do
what
> it wishes with the URI provided by the SCA documents.
>
> > We can get interoperability at the binding.ws to binding.ws
level via a
> > fixed URI on the referencing binding. We can get
interoperability from
> > a non-SCA client to an SCA service by having the non-SCA
client use a
> > generated WSDL.
> >
> My point regarding interoperability was that for binding.ws, the
> runtime URIs on the service and reference ends need to match.
> This aspect of needing to match runtime URIs on the reference and
> service sides doesn't apply in the case of binding.sca. I agree
> that there are other ways that reference/service URI matching can
> be done for binding.ws. However I think there are some cases
> where it is helpful to have a well-defined way of specifying a
> "suggested URI" for an SCA service using SCA documents.
>
> > So I allege that I have given up precisely zero interoperability
by
> > side-stepping this question.
> >> This consideration does not
> >> apply to a service with <binding.sca> which only
has SCA clients
> >> wired to it using SCA mechanisms. Services using
<binding.sca>
> >> might not even have a URI, depending on what transport
they use.
> > I agree that the binding.sca scenario is different. However
I find it
> > indicative that there are no normative requirements on
the @uri
> > attribute for binding.sca.
> >
> There are clear normative requirements for the meaning of @uri on
> binding.sca, i.e., that it MUST be used at the target for a reference
> and it MUST be ignored when specified on a service. I am suggesting
> that we need similarly clear normative statements for the meanings
> of the various ways of specifying URIs that binding.ws provides.
>
> Simon
>
> >> Tomorrow I will try to come up with some alternative
words for
> >> service URIs, based on the previous proposal draft.
> > OK. Thanks.
> >
> > -Eric.
> >
> >
> > ---------------------------------------------------------------------
> > 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/
>
>
>
>
>
>
---------------------------------------------------------------------
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]