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:
OFCC8DD3EE.C829962D-ON80257479.004538DB-80257479.00457A3F@uk.ibm.com"
type="cite">
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
|