sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-bindings] Disposition of Eric's binding spec review comments
- From: Piotr Przybylski <piotrp@us.ibm.com>
- To: Simon Holdsworth <simon_holdsworth@uk.ibm.com>
- Date: Thu, 7 Aug 2008 01:05:03 -0700
This clarification is not applicable to JCA as it does not have a concept of request and response that would allow specifying both, ActivationSpec and ConnectionFactory at the same time. The ConnectionFactory is used exclusively for outbound (from JCA Adapter perspective) connectivity, for references. The ActivationSpec is used for inbound connectivity only, for services. This could be summarized as follows, rule already present in the latest revision of the specification (e.g. line 130)
- A service must not specify an ConnectionFactory; a reference must not specify an ActivationSpec.
Piotr
Regards,
Piotr Przybylski
Architect, WPS and SCA Bindings
Phone: 650-645-8213 T/L 367-8213
Simon Holdsworth ---07/31/2008 03:55:43 AM---Eric,
Simon Holdsworth <simon_holdsworth@uk.ibm.com>
07/31/2008 03:47 AM
|
|
Eric,
My mistake, there isn't a <request> element in binding.jms, those elements just have <binding.jms> as their parent. Values that pertain to responses are contained within a <response> element. So more correctly below where it says <request> it should say <binding.jms>...</binding.jms> and <response> should be <binding.jms><response>...</response></binding.jms>
If there's no objection to the rules as stated below, I'd appreciate the help of an XML expert to look at the binding.jms schema and validate that the set of constraints in the summary is reflected in the schema where possible. Otherwise the constraints need to be reflected in the binding text (and I believe they are, but will check).
I'm happy to replace your action item with one against myself to make these checks to ensure that there is no issue. Once that's done then I believe that all of the review comments have appropriate dispositions, and that what remains is the open issues and actions against the editors to apply editorial updates.
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
Eric Johnson <eric@tibco.com>
30/07/2008 19:00 |
To | Simon Holdsworth/UK/IBM@IBMGB |
cc | sca-bindings@lists.oasis-open.org |
Subject | Re: [sca-bindings] Disposition of Eric's binding spec review comments |
|
Hi Simon,
As per my action item 20080626-1, I still need to respond to your email here.
I apologize for the delay in a response. The key reason I have not responded is that I'm simply *not* familiar enough with JCA. What you outline below sounds reasonable and correct to me, but I would hope for another pair of eyeballs - someone familiar with JCA.
One bit of formalism that confused me below - I think I know what you meant when you talk about requests and responses, but I didn't understand what you meant by "<request>", and "<response>" elements.
-Eric.
Simon Holdsworth wrote:
Eric,
On the topic of connection factory/activation spec, here's my analysis of the allowed combinations:
For a service:
For receiving requests:
<request>
ActivationSpec to receive requests. For the case where resources exist, the AS also identifies the destination (as far as the runtime is concerned).
Optional Destination in the case where resources are being created, as AS doesn't provide destination attributes. if not specified when creating resources the system provides a request queue. This could also be specified so that clients can look at the export definition and know which Destination is actually being used. In that case the Destination must be consistent with the ActivationSpec (who could check that - the SCA runtime? can't just look at the SCDL and know its wrong).
No ConnectionFactory
</request>
OR
<request>
ConnectionFactory to receive requests.
Destination to receive requests.
No ActivationSpec
</request>
For sending responses (if interface has any request/response operations):
<response>
ConnectionFactory to send responses.
Optional Destination to send responses to (if absent JMSReplyTo is used)
No ActivationSpec
</response>
No corresponding ActivationSpec case for service responses.
For a reference:
For receiving responses:
<response>
ActivationSpec to receive responses. For the case where resources exist, the ActivationSpec also identifies the destination
Optional Destination to receive responses. In the case where resources are being created, as ActivationSpec doesn't provide destination attributes. If not specified when creating resources, then system provides a response queue. There's little value in exposing the response Destination in the SCDL in the case that resources exist, but if done must be consistent with the ActivationSpec.
No ConnectionFactory
</response>
OR
<response>
ConnectionFactory to receive responses.
Optional Destination to receive responses. If not specified, then system provides a response queue.
No ActivationSpec
</response>
For sending requests:
<request>
ConnectionFactory to send requests
Destination to send requests to
No ActivationSpec
</response>
No corresponding ActivationSpec case for reference requests.
So in summary:
- ConnectionFactory and ActivationSpec are mutually exclusive within a <request> or <response> element.
- When specifying a ConnectionFactory in a <request> element, the Destination is mandatory.
- When specifying a ConnectionFactory in a <response> element, the Destination is optional.
- 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.
- A service <response> must not specify an ActivationSpec; a reference <request> must not specify an ActivationSpec.
If we agree with these rules then we need to make sure the text and the schema in the JMS and JCA binding specs agree with this.
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]