Proposed resolution for issue BINDINGS-40

[Simon Holdsworth <simon_holdsworth@uk.ibm.com>]

Folks,

I propose that we resolve issue BINDINGS-40
as follows.  The only bit I'm not clear on and need help with is the
form of the updates to the JMS binding schema to enforce the rules.  I've
extended the proposed resolution with notes on schema updates:

1) ConnectionFactory and ActivationSpec
are mutually exclusive within a <binding.jms> or <response>
element. 
This is reflected in the text, but not
in the schema.  We currently have:

   <complexType name="Response">
      <sequence>
         <element
name="destination" type="sca:Destination" minOccurs="0"/>
         <element
name="connectionFactory" type="sca:ConnectionFactory"

         
        minOccurs="0"/>
         <element
name="activationSpec" type="sca:ActivationSpec" minOccurs="0"/>
      </sequence>
   </complexType>

So would need to modify this to ensure
connectionFactory and activationSpec are exclusive for response;  for
binding.jms those elements are not within a separate complex type so not
sure how to enforce that...

---> Need XML schema update help
here.

2) When specifying a ConnectionFactory
in a <binding.jms> element, the Destination is mandatory. 
This is not reflected. Update required:


line 188 add: "When this element
is present, the destination element MUST also be present" 

I don't think this can be enforced via
schema because the Destination element may optionally be specified with
the activationSpec and no ConnectionFactory.

3) When specifying a ConnectionFactory
in a <response> element, the Destination is optional. 
This is implicit, although the meaning
of the destination is not clear. Need to add some clarification: 

line 195 add: "for a service, this
destination is used to send response to messages that have a null value
for the JMSReplyTo destination. For a reference, this destination is used
to receive reply messages". 

Note that the RFC language that describes
this is included in the message exchange patterns section. 

Don't need any XML schema update for
this as Destination is already optional.

4) When specifying an ActivationSpec,
Destination is optional; when creating resources if not specified the system
provides a Destination, otherwise if specified must be consistent with
the ActivationSpec. 

line 191 add: If a destination element
is also specified it MUST refer to the same JMS destination as the activationSpec.


XML schema cannot enforce this rule
as it cannot see within the activationSpec properties.

5) A service <response> must not
specify an ActivationSpec; a reference <binding.jms> must not specify
an ActivationSpec. 

line 191 add: This element MUST NOT
be present when the binding is being used for an SCA reference. 

line 202 add: This element MUST NOT
be present when the binding is being used for an SCA service. 

I don't believe XML schema can enforce
this as it cannot know whether the binding is applied to a reference or
service.

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

---

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