OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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



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








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]