[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] BINDINGS-23: Proposed resolution v5
Simon, Thanks for reviewing this ahead of the call. Please see my responses inline below. Simon Simon Holdsworth wrote: > > 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 topic of multiplicity came up in one of our earlier discussions, and I added this statement to try to clarify the position. I think the point of the statement is to make clear that the binding fills a single multiplicity slot for the reference (using a port selected dynamically by the SCA runtime from all those available) rather than using the available ports to fill separate multiplicity slots. The alternative wording you are proposing does not carry the same meaning because it relates to runtime invocation rather than wiring/binding resolution. > 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" > I don't understand how adding this to the second normative statement could replace the non-normative definition of the set of available ports (if this is what you are suggesting). This definition is used in both the first and second normative statements. I am probably not clear about the exact wording change that you are proposing. > 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. > I added this to cover the case where the port selected is valid, but the runtime cannot use it. For example, the port could be a SOAP 1.2 port but the runtime might not be able to handle SOAP 1.2. Would it help if I reworded this as "or raise an error if it does not support the configurations of all the available ports"? > 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. > I was trying to make the point that the reason that the port cannot be exposed is because of SCA runtime limitations rather than something being wrong with the port definition. We could preserve this thought with simpler language by rewording the statement as "The SCA runtime MUST expose an endpoint for the specified port, or raise an error if it does not support the configuration of the port." Simon > 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]