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] Disposition of Eric's binding spec review comments



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:

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]