sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-bindings] BINDINGS-23: Proposed resolution v5
- From: Simon Holdsworth <simon_holdsworth@uk.ibm.com>
- To: OASIS Bindings <sca-bindings@lists.oasis-open.org>
- Date: Wed, 6 May 2009 10:45:58 +0100
Simon,
Overall I'm happy with the approach
now, but have some comments on wording:
I'm not sure of the value of the statement
"The set of available ports represents a single
SCA reference binding (i.e., it has multiplicity 1)."
The intention here is to document non-normatively
the fact that while the service may have multiple ports, an invocation
using this reference will only result in the invocation of a single available
port. We can express that in the existing normative statement, and
if we need some additional clarification, perhaps something along the lines
of:
If the binding is for an SCA reference, the service's
ports are considered equivalent ways to access the same web service and
a single port is used when an invocation is made.
The set of available ports for the SCA reference consists
of...
I think we could clarify this in the
second normative statement by replacing "MUST use a port"...
to "MUST use one of the ports"
For "or
raise an error if the configurations of all the available ports prevent
them from being used by the SCA runtime."
I'm not sure what's meant there - is
this a hangover from the service case? Given that we've already done
the static interface and policy checks on the port, I'm not sure what other
"configuration" can prevent the port from being used other than
the fact that the URL is invalid or the target service is inaccessible.
If the runtime picks a port an fails to call it, its going to return an
error, I don't think we need to say that as part of this normative statement.
The same comment applies to 2) and 3) for the SCA reference cases.
In 2) "The
SCA runtime MUST expose an endpoint for the specified port, or raise an
error if the configuration of the port prevents it from being exposed by
the SCA runtime." and
other similar statements I think the last "by the SCA runtime"
is superfluous.
Regards, Simon
Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair
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.com
Simon Nash <oasis@cjnash.com>
05/05/2009 19:28
|
To
| OASIS Bindings <sca-bindings@lists.oasis-open.org>
|
cc
|
|
Subject
| [sca-bindings] BINDINGS-23: Proposed
resolution v5 |
|
Based on the discussion on today's call, here is a
revised set
of proposed spec changes to resolve BINDINGS-23:
1) In the first bullet (Service) under the /binding.ws/@wsdlElement
description, replace all the current text by the following:
If the binding is for an SCA service, the wsdlElement attribute
MUST NOT specify the wsdl.service form of URI.
If the binding is for an SCA reference, the set of available ports
for the reference consists of the ports in the WSDL Service that
. have portTypes which are compatible supersets of the SCA reference
as defined in the SCA Assembly Model specification [SCA-Assembly],
and
. are able to satisfy all the policy constraints of the SCA reference.
The set of available ports for the reference MUST contain at least
one port. The set of available ports represents a single
SCA reference binding (i.e., it has multiplicity 1). When
an
invocation is made using the SCA reference, the SCA runtime MUST
use
a port from the set of available ports for the reference (with
port
selection on a per-invocation basis permitted), or raise an error
if the configurations of all the available ports prevent them from
being used by the SCA runtime.
2) In the second bullet (Port) under the /binding.ws/@wsdlElement
description, replace all the current text by the following:
If the binding is for an SCA service, the portType associated with
the specified port MUST be compatible with the SCA service interface
as defined in section 2.1, and the port MUST be able to satisfy
all
the policy constraints of the SCA service. The SCA runtime
MUST
expose an endpoint for the specified port, or raise an error if
the configuration of the port prevents it from being exposed by
the SCA runtime.
If the binding is for an SCA reference, the portType associated
with
the specified port MUST be a compatible superset of the SCA reference
interface as defined in the SCA Assembly Model specification
[SCA-Assembly], and the port MUST be able to satisfy all the policy
constraints of the SCA reference. The SCA runtime MUST use
the
specified port for invocations made using the SCA reference, or
raise
an error if the configuration of the port prevents it from being
used
by the SCA runtime.
3) In the third bullet (Binding) under the /binding.ws/@wsdlElement
description, replace the first two sentences of the current text by
the following:
If the binding is for an SCA service, the portType associated with
the specified WSDL Binding MUST be compatible with the SCA service
interface as defined in section 2.1, and the WSDL Binding MUST
be
able to satisfy all the policy constraints of the SCA service.
The SCA runtime MUST expose an endpoint for the specified WSDL
Binding,
or raise an error if the configuration of the WSDL Binding prevents
it
from being exposed by the SCA runtime.
If the binding is for an SCA reference, the portType associated
with
the specified WSDL binding MUST be a compatible superset of the
SCA reference interface as defined in the SCA Assembly Model
specification [SCA-Assembly], and the WSDL binding MUST be able
to
satisfy all the policy constraints of the SCA reference. The
SCA runtime MUST use the specified WSDL Binding for invocations
made
using the SCA reference, or raise an error if the configuration
of
the WSDL Binding prevents it from being used by the SCA runtime.
4) Insert the following new section 2.1 and renumber the current
section 2.1 and subsequent sections.
2.1 Compatibility of SCA Service Interfaces and WSDL portTypes
A WSDL portType is compatible with an SCA service interface if
and
only if all of the following conditions are satisfied:
1. The SCA service interface is remotable.
2. The operations on the portType are the same as the operations
on the SCA service interface, with the same operation
name,
same input types (taking order as significant), same
output types
(taking order as significant), and same fault/exception
types.
If the SCA service interface is not a WSDL portType,
it is
mapped to a WSDL portType for the purposes of this
comparison.
The mapping is defined in the relevant SCA specification
for the
interface type. If the interface cannot be mapped
to WSDL, the
SCA service is not compatible with the WSDL portType.
3. WSDL 1.1 message parts can point to an XML Schema element
declaration or an XML Schema type. When determining
compatibility
between two WSDL operations, a message part that points
to an
XML Schema element is considered to be incompatible
with a
message part that points to an XML Schema type.
4. If either the portType or the SCA service interface declares
an SCA callback interface, then both the portType
and the
SCA service interface declare callback interfaces
and these
callback interfaces are compatible according to points
1 through 3 above.
Simon
---------------------------------------------------------------------
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]