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: Simon Holdsworth <simon_holdsworth@uk.ibm.com>
- To: sca-bindings@lists.oasis-open.org
- Date: Thu, 31 Jul 2008 11:47:47 +0100
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]