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] Proposed resolution for issue BINDINGS-40



Mike,

Given that we can "include" this information from another binding.jms element via the definitions file, then these elements have to be optional, although the overall effect must be that one of connection factory or activation spec is specified.

Given the definitions file capability, I think we have to go with minOccurs = 0, maxOccurs = 1

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



Mike Edwards/UK/IBM@IBMGB

29/09/2008 18:31

To
sca-bindings@lists.oasis-open.org
cc
Subject
Re: [sca-bindings] Proposed resolution for issue BINDINGS-40






Simon,


My pennyworth on your 1) below.


  <complexType name="Response">

    <sequence>

       <element name="destination" type="sca:Destination" minOccurs="0"/>

        <choice minOccurs="0">
          <element name="connectionFactory" type="sca:ConnectionFactory"/>

          <element name="activationSpec" type="sca:ActivationSpec"/>

        </choice>
    </sequence>

 </complexType>



Not sure that you really want minOccurs="0", however.  I thought that you had to have either one or the

other in which case minOccurs="1" and maxOccurs="1" would apply to the <choice/>



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 Holdsworth/UK/IBM@IBMGB
To: sca-bindings@lists.oasis-open.org
Date: 29/09/2008 12:36
Subject: [sca-bindings] Proposed resolution for issue BINDINGS-40







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










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












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]