OK, I'm happy to take 107 (and 108 I
expect) as top priority.
For BINDINGS-96 as far as the use of
JMS ReplyTo for one-way operations in bidirectional interfaces, I would
be OK with having rules that say that the scaCallbackDestination is only
used for request/response operations, and that for oneway operations JMSReplyTo
is always used which does make it somewhat more symmetrical. However
making that change does affect quite a lot of text in the JMS binding so
I'd propose we discuss these last after we've got the other "simpler"
ones out of the way.
So then for BINDINGS-96 the updates
would be as follows:
BJM60002 would need to be updated to
apply only to unidirectional services:
For an SCA service with a JMS binding
>> and unidirectional interface <<, when a request message
is received as part of a one-way MEP, the SCA runtime MUST ignore the JMSReplyTo
destination header in the JMS message, and not raise an error [BJM60002].
The words in section 6.4 would need
to be updated from:
Messages that correspond to one-way
or request/response operations on a bidirectional interface use either
the scaCallbackDestination user property or the JMSReplyTo destination,
or both, to identify the destination to which messages are to be sent when
operations are invoked on the callback interface.
to:
Messages that correspond to one-way
or request/response operations on a bidirectional interface use either
the scaCallbackDestination user property (for request/reply) or the JMSReplyTo
destination (for one-way) to identify the destination to which messages
are to be sent when operations are invoked on the callback interface.
BJM60011 needs to be specific to request/reply:
For an SCA reference with a JMS binding
and a bidirectional interface, when a request message is sent >>
as part of a request/response MEP << the SCA runtime MUST set the
destination to which callback messages are to be sent as the value of the
scaCallbackDestination user property in the message it creates [BJM60011].
BJM60012 needs changing to only apply
to one-way and not mention scaCallbackDestination, so change:
For an SCA reference with a JMS binding
and bidirectional interface, when a request message is sent the SCA runtime
MAY set the JMSReplyTo destination to the same value as the scaCallbackDestination
user property [BJM60012].
to
For an SCA reference with a JMS binding
and bidirectional interface, when a request message is sent as part of
a one-way MEP the SCA runtime MUST set the destination to which callback
messages are to be sent as the JMSReplyTo destination in the message it
creates [BJM60012].
In section 6.4.2 the definition needs
rewording from:
An SCA service with a callback interface
can invoke operations on that callback interface by sending messages to
the destination identified by the scaCallbackDestination user property
in a message that it has received, the JMSReplyTo destination of a one-way
message that it has received, or the destination identified by the service's
callback reference JMS binding.
For an SCA service with a JMS binding,
the callback destination is identified as follows, in order of priority:
• The
scaCallbackDestination identified by an earlier request, if not null;
• the
JMSReplyTo destination identified by an earlier one-way request, if not
null;
• the
request destination of the service’s callback reference JMS binding, if
specified
To:
An SCA service with a callback interface
can invoke operations on that callback interface by sending messages to
the destination identified by the scaCallbackDestination user property,
the JMSReplyTo destination or the destination identified by the service's
callback reference JMS binding.
For an SCA service with a JMS binding,
the callback destination is identified as follows, in order of priority:
• The
scaCallbackDestination identified by an earlier request/response operation,
if not null;
• the
JMSReplyTo destination identified by an earlier one-way operation, if not
null;
• the
request destination of the service’s callback reference JMS binding, if
specified
Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair,
AT&T and Boeing Lab Advocate
MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK
Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
Internet -
From:
Mike Edwards/UK/IBM@IBMGB
To:
Date:
10/12/2009 16:01
Subject:
Re: [sca-bindings] Proposed resolutions
for issues - overview
Folks,
Comments:
1) BINDINGS 107 - like Dave, I want this to be top priority - it may impact
the SCA Assembly spec which we are trying to close
other comments inline...
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:
From:
Simon Holdsworth/UK/IBM@IBMGB
To:
Date:
07/12/2009 11:34
Subject:
[sca-bindings] Proposed resolutions
for issues - overview
Folks,
This is a summary of the set of open issues that we currently have with
proposed resolutions, and my take on them. Hopefully this will expedite
resolution of the issues in the TC - I would really like to get these resolved
prior to the Christmas break, allowing a new revision of the bindings specs
and TA documents early in the new year which the TC could then consider
for the next committee draft.
I would encourage you to take a look at these proposed resolutions if at
all possible before Thursday's meeting and raise any concerns via email
prior to the meeting so that we can progress through the resolutions quickly.
http://www.osoa.org/jira/browse/BINDINGS-94:
scaCallbackDestination destination name unclear
Proposed resolution in email: http://lists.oasis-open.org/archives/sca-bindings/200911/msg00008.html
Latest email: http://lists.oasis-open.org/archives/sca-bindings/200912/msg00001.html
Summary:
Clarify the syntax of the destination "name" that appears in
the scaCallbackDestination user property - proposal is that this should
be a JMS URI.
<mje>
It looks like a client SCA app needs to set both the scaCallbackDestination
property and the JMSReplyTo, just in case it is talking
to a non-SCA service? In which case, why not just use JMSReplyTo
all the time?
</mje>
http://www.osoa.org/jira/browse/BINDINGS-95:
BJM30032 and BJM30035 conflict
Proposed resolution: http://lists.oasis-open.org/archives/sca-bindings/200911/msg00010.html
Summary:
These normative statements conflict because the conditions under which
they apply overlap.
The proposal is to make the statements more specific by including additional
conditions under which they apply which were previously implicit from the
context of the statements; it covers issues 95, 105 and 106 which all affect
the same overall set of statements.
Linked email provides two alternatives: modify existing statements to ensure
conditions on the statements are exclusive, or replace all the statements
with single statements that define behaviour via a prioritised list of
conditions.
<mje>
I prefer the alternative version with explicit ordering (simpler to understand)
</mje>
http://www.osoa.org/jira/browse/BINDINGS-96:
BJM60012 and BJM60013 conflict
Status: Proposed resolution in JIRA
Summary:
These normative statements conflict because the conditions under which
they apply overlap.
The proposal is to make one of the statements more specific by including
another condition under which it applies which was previously implicit
from the context of the statement.
<mje>
Of course, we could require JMSReplyTo to always be set for any forward
message... as per my comment under issue 94
</mje>
http://www.osoa.org/jira/browse/BINDINGS-103:
optional used in normative statement
Status: Proposed resolution in email http://lists.oasis-open.org/archives/sca-bindings/200911/msg00037.html
Summary:
"optional" is used in a normative statement without normative
meaning.
Proposal is to replace the use of "optional" and ensure that
the normative statements are clear, along with a schema update to make
the schema reflect the intended optionality of the jndiName attribute.
<mje>
+1
</mje>
http://www.osoa.org/jira/browse/BINDINGS-104:
Expected @create attribute value not clear in some normative statements
Status: Proposed resolution in JIRA
Summary:
Another case where statements overlap due to omission of contextual information.
Proposal is to explicitly state the conditions in the normative statements
that previously were implicit from context.
<mje>
+1
</mje>
http://www.osoa.org/jira/browse/BINDINGS-105:
BJM30025 has no normative keyword
Proposed resolution: http://lists.oasis-open.org/archives/sca-bindings/200911/msg00010.html
Summary:
This issue overlaps with BINDINGS-95, see above.
http://www.osoa.org/jira/browse/BINDINGS-106:
BJM30027 has no normative keyword
Proposed resolution: http://lists.oasis-open.org/archives/sca-bindings/200911/msg00010.html
Summary:
This issue overlaps with BINDINGS-95, see above.
http://www.osoa.org/jira/browse/BINDINGS-107:
What is the purpose of definitions/binding element?
Status: Proposed resolution in email http://lists.oasis-open.org/archives/sca-bindings/200911/msg00035.html
Summary:
Use of bindings element in definitions file is not necessary, some agreement
on just removing all mention of it from bindings specs, reflected in the
proposed resolution. This would also apply to BINDINGS-108 when opened.
http://www.osoa.org/jira/browse/BINDINGS-101:
Opaque references - need for a terminology list?
Status: no proposed resolution
Summary:
Needs editors to look at the specifications and come up with a way to define
references to SCA assembly and policy terms.
http://www.osoa.org/jira/browse/BINDINGS-102:
Need to specify all valid enumerations for @create attribute and others
Status: no proposed resolution
Summary:
Needs editors to look at the specifications and identify where enumeration
values are not fully defined.
Regards, Simon
Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair,
AT&T and Boeing Lab Advocate
MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK
Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
Internet -
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
