[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim minutes of 6/1 meeting
The prelim minutes are attached. Please post corrections to the entire list before Friday. tom Rutt -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003
Preliminary Minutes of WSRM TC Conference Call –May 25, 2004 The meeting of the WSRM TC took place by teleconference 1
Draft
Agenda:
Draft Agenda to WSRM TC Conference Call 1 Roll Call 2 Minutes Discussion 2.1 Appointment of Minute Taker 2.2 Approval of previous meeting minutes – 3 Action Item Status Review 4 Discussions of unresolved editorial comments 5 Discussion of Document progression 6 Discussion of FAQ for WS-Reliability 2
Roll
Call
Attendance:
Meeting is quorate. 3
Minutes
Discussion
3.1 Appointment of Minute TakerTom Rutt will take minutes. Minutes will serve to record issue resolutions. 3.2 Approval of previous meeting minutesThe minutes of the May 25 teleconf are posted at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/6979/MinutesWSRM-052504.htm
Alan moved to approve the minutes, Iwasa seconded. No opposition, minutes approved. 4 Status of Action Items4.1 Action
052501-1 (Tom Rutt) pending
New Action: Tom took a new action item to complete the status column of pre public review issues list, with correct URLs.
Open
4.2 Action
052501-2 (Sunil) pending
:Action: Sunil will come up with a proposal for the namespace for all four of our schemas.
Closed
4.3 Action
052501-3 (Iwasa) Pending
Action: Iwasa sould have a new document, .999 available by Wed . appling agreed changes from 5/25 minutes
Still needs to use the agreed definition from minutes for Payload
closed
4.4 Action
052501-4 (Anish and Tom) pending
Action: small team of Anish and Tom will come up with a http binding clarification proposal for next week.
closed 5
Discussion
of Issues and editorial Comments
The following issues list includes open items which need further discussion: 5.1 PC11.24 · Definition
of Payload the newest version
(.999) has the following definition for payload: Lines 169 and 170 Payload: The contents within the SOAP
body of a Reliable Message. This needs to be changed to the definition we
agreed on at the meeting: Payload information intended for
the consumer of the reliable message. -- Agreed change. 5.2 PC13 HTTP POST as Mandatory
· Action item
052504-4 - Clarification of HTTP Binding Mail from Anish: Tom, ------------------------------------------------------------------------
1
Clarification of the Introduction of section 6, HTTP Binding. Replace the intro paragraph for section 6 (lines
1206 thru 1211) from: “ This section describes the three binding pattern
- “Response”, “Callback”, and “Poll” binding pattern for HTTP. These binding pattern is identified by the value of ReplyPattern element (See Section4.2.3 for detail). This specification
expects that the transport layer will not deliver a corrupted message to the
reliability layer. When a request message contains AckRequested element, upon receipt of a reliable message,
the Receiving RMP MUST send a reply. This reply MUST be either an Acknowledgment
Indication or an RM Fault Indication. This reply MUST be sent by specified
binding pattern in the ReplyPattern element of the
request message. “ to “ This section specifies two normative bindings of
WS- Reliability header elements to SOAP header blocks carried using HTTP as a
transport protocol. • SOAP
1.1 over HTTP POST binding: An implementation of WS-Reliability MAY support
mapping the ws reliability header elements as soap
header blocks in accordance with the SOAP 1.1 HTTP Binding, as specified in
Section 6 of SOAP 1.1. • SOAP
1.2 over HTTP POST: An implementation of WS- Reliability MAY support mapping
the ws reliability header elements as soap header
blocks in accordance with the SOAP 1.2 HTTP binding for the request/response
MEP, as specified in Section 7, SOAP HTTP Binding, of SOAP 1.2 Part 2: Above text agreed “ If a reliable message request is invoked using
SOAP 1.1 over HTTP POST binding, all subsequent message exchanges pertaining to
that message ID MUST use the SOAP 1.1 over HTTP POST binding. “ Suggested amendment: "If a reliable message request is invoked
using SOAP 1.1, all subsequent message exchanges pertaining to that message ID
MUST use the SOAP 1.1 protocol." Agreed to amended text “ A ReplyTo element
present in a Request element or Poll Request element sent using the SOAP 1.1
over HTTP POST binding, MUST use the URI form of
reference, with an http: uri to use for invoking the ws reliability response, in accordance with the SOAP 1.1
over POST binding. “ Suggested amendment: "If a ReplyTo
element present in a Request element or Poll Request header element, sent using
the SOAP 1.1 protocol, contains only a URL and uses the 'http:' URL scheme,
then the WS reliability response MUST be sent using the HTTP binding specified
in section 6 of SOAP 1.1. “ Agreed to amendment “ If a reliable message request is invoked using
SOAP 1.2 over HTTP POST binding, all subsequent message exchanges pertaining to
that message ID must use the SOAP 1.2 over HTTP POST binding. “ Suggested amendment: "If a reliable message request is invoked
using SOAP 1.2, all subsequent message
exchanges pertaining to that message ID MUST use the SOAP 1.2 protocol." Agreed to amendment “ A ReplyTo element
present in a Request or Poll Request header element sent using the SOAP 1.2 over HTTP POST binding,
MUST use the URI form of reference, with an http uri
to use for invoking the ws reliability response, in accordance
with the SOAP 1.2 over POST binding. “ Suggested amendment: "If a ReplyTo
element present in a Request element or Poll Request header element, sent using
the SOAP 1.2 protocol, contains only a URL and uses the 'http:' URL scheme,
then the WS reliability response MUST be sent using the HTTP binding for
request/response MEP specified in SOAP 1.2 agreed to amendment The following subsections specify the mapping of
ws reliability header
elements to HTTP request and response messages, for the three rm-reply patterns. The Poll reply pattern has two variations (synchronous and asynchronous). The specific reply pattern in use is identified by the value of ReplyPattern element (See Section4.2.3 for detail). This specification expects that the transport layer
will not deliver a corrupted message to the reliability layer. When a request
message contains AckRequested element, upon receipt
of a reliable message, the Receiving RMP MUST send a reply. This reply MUST be either
an Acknowledgment Indication or an RM Fault Indication. For the Callback and Poll reply patterns, a ws reliability response element can contain multiple acknowledgement
and/or rm fault indications. For simplicity, the detailed examples only show
the use of SOAP 1.1. However, the
figures showing the mapping of ws reliability
elements to HTTP POST request messages and HTTP response messages apply to both
the SOAP 1.1 over HTTP POST binding, and the SOAP 1.2 over HTTP POST binding. 2
change Binding Pattern to reply pattern Lines: 1212, 1223, 1253, 1274, 1289, 1328, 1348,
1354, 1369, 1410, 1414, 1430, agreed 3 clarification that response goes on
http post for callbacks the text for lines 1285
and 1286 “ (3) The Acknowledgment Indication is sent with
another HTTP connection from the Receiving RMP to the
Sending RMP. Example 14 is an
example of this message. “ does not require
sending the rm: response on an HTTP Post operation. Also the text for lines 1425 thru 1427: “ (5) The HTTP request corresponding to the Poll
request in (3) includes
Acknowledgment Indication and/or Reliable Messaging Fault.
Example 18 is an example for this message. This request
is sent to the listener identified the ReplyTo
element in the PollRequest element. “ does not require
sending the rm: response on an HTTP Post operation. Clarify both of these sentences by stating that
the HTTP POST operation is used to send the response. Agreed with amendments. Anish moved to accept
proposal as amended, Iwasa seconded. No opposition, motion passes. 5.3 Editorial Comments5.3.1 Namespace for Schema, and locationSchemas and
Namespaces
WSRM TC has the
following 4 schemas:
Except for one
know change (removing ReplyTo property from wsrmf.xsd), I'm assuming the contents are going Currently, these
schemas are not referencible as the schema files are
hosted at a different location than If we do want to
make them referencible, then the namespaces should
start with: There are 2 options w.r.t. to the remaining part of the namespace and that of the suffix/extension. a) Remaining part of the namespace.
Option 1: Using the date/year convention that is followed by many
specifications now OASIS folks recommend the above, although they don't mandate it.
Option 2: Is to use the version in the namespace, something similar to what we
have currently. If we do decide to go with Option 2, we may need to further polish them.
Between these 2 options, I prefer Option 1 as that seem
to be practice these days. b) Other piece to this puzzle is whether to use the suffix .xsd in the namespace.
Option 1: with the suffix/extension: Option 2: without any suffix/extension:
Example: http://docs.oasis-open.org/wsrm/1.1/ws-reliability
Comments???? -Sunil WS security has .xsd in name space. Tom: is there a problem with having the namespace name be the filename Propose: schema name and file name being the same name. Sunil: does not look good. This is a style issue. a) use xsd in file name - b) do not use xsd in file name 2 xsd 2 no xsd many abstains The file will be names .will be xsd Anish: How the file is stored at the web server. Tom: I am concerned about delaying the spec. Jeff: you hand somebody the URI, they will get an Http get on the schema. Sunil: How sophisticated is the HTTP server that OASIS is running. Tom: the brute force approach of WS-security works. We do not have to wait. Better wait till next week to get oasis response. Next issues: dates or version numbers. Tom: does WS security have a version number. Jeff: I would prefer a version number. Agree to Put version 1.1 in title of spec.. WSS has version number in file name as well as the dates. Sunil will try to use both the dates and the version number. Action: sunil will continue on this one. 5.3.2 Pete Wenzel comments on draft .999· Re: [wsrm]
Groups - WS-Reliability-2004-05-26.pdf uploaded Here are a few comments based on my quick review
of 0.999. Proposed changes that may require discussion: 18-22:
Comment process: Should describe use of the comment web form, not the mailing list(?)
Perhaps there is new boilerplate available for this. Using the Web Form for comments. Pete: took action to find out the latest convention.
1205-1206: This section describes the three binding pattern - "Response", "Callback", and "Poll"
binding pattern for HTTP. These binding pattern is -> This
section describes the HTTP bindings for the three message reply patterns - "Response", "Callback", and "Poll". These patterns are [Other uses of "binding pattern" throughout this chapter?] agreed 1474:
Insert new paragraph: It has implemented all required syntax, features and behaviors. Pete moved to add the new paragraph after 1494, seconded by Bob Freund. No discussion. No opposition, motion passes, add paragraph to conformance. [Are
the requirements identified in some consistent manner throughout the document?] Pete: what about MUSTs within MAYs. Tom: currently you have to read to spec to see if it is mandatory 1563: mustUnderstand ... value equal to 1 or "true" BP 1.0 conformance was an issue. Doug: XML schema data type there is no logical value 1, the only values are “true” or “false”. Anish: currently states value = 1, it does not state value space or lexical space. For 1.1: put “1” in quotes, Doug: describe the soap must understand element being in the same namespace as used for the soap envelope element. And then state that for our spec it should be “1”. Anish: For soap 1.2 do we want to restrict it to “1”. Would such a thing be required for soap 1.2. Doug: I would agree if we do not have a reason to restrict beyond soap 1.2. Agreed : wherever soap must understand is mentioned in document add two sentences:
Tom: action to have a complete proposal. Tom will get it out right after the meeting. Iwasa will implement after discussion. In 4.2, in 4.2 Editorial issues: Table of
Contents: Page numbers off by one beginning around Chapter 6. Can
the ToC items be turned into hyperlinks for easier
navigation? 105-106,
946-952: extraneous highlighting 240:
extraneous hyphen 248:
distinguishes two -> distinguishes between two 250:
reliable -> reliability 254:
derive -> are derived 270: to
-> of 277: as
different -> as a different 358: to
initially have knowledge of the RM Agreement -> to have knowledge of the RM Agreement initially 382:
will however greatly -> will, however, greatly 393:
notify a delivery error to the Payload Producer -> notify the
Payload Producer of a delivery error 394:
receiving -> Receiving 407:
with same identity -> with the same Message Identifier 656: of ReplyTo element -> of the ReplyTo
element 674:
Request/ MessageOrder -> Request/MessageOrder 905-906:
extraneous line break and spaces 1022,
1308: extraneous blue text color 1472:
conform -> conformant 1485: to
NOT implement -> NOT to implement Section numbering: 579:
4.2.1.3 584: 4.2.1.4 592:
4.2.1.5 599:
4.2.1.6 655:
4.2.3.2.1 --Pete Iwasa should apply the editorial changes above, and the agreed changes from the motions. 5.3.3 Clarification of When Soap Fault must be sent· issue with
use of SOAP Faults · RE: [wsrm]
issue with use of SOAP Faults · Section 4.5
editorial update (4.5) Fault
Codes and Processing For Reliable Messaging Failures The protocol
defines two fault categories: ·
The Message Format fault set, which includes all
faults generated because of a malformed Reliable Message header. ·
The Message Processing fault set, which includes
all faults generated while processing the message. They are
explained in detail in the following sections. These protocol specific fault
codes are returned by the Receiving RMP
within the response header element. Reliable Message Faults are carried in the
SOAP Header, and do not rely on the SOAP Fault model for the following reasons: ·
The SOAP Fault model does not allow batching
several faults in the same message. ·
RM faults may be carried by business messages
that are not concerned by these faults, and for this reason they should not
affect the SOAP body of these messages. The rules for
processing faults are: ·
A message for which an RM Fault is published
MUST NOT be delivered by the Receiving RMP, and
therefore MUST NOT be acknowledged. ·
In case a “Response” ReplyPattern
was required, and when the message cannot be delivered to the Consumer due to a
failure in processing the RM headers, then a SOAP Fault must be generated in
addition to the RM Reply that contains the RM Fault. Because either a
well-formed response or a SOAP Fault is expected on the Sending side, then the
response leg of the transaction must contain a SOAP Fault in the SOAP Body when
no business response is available. More details are given in the HTTP Binding
section. ·
In case a
“Callback” or “Poll” ReplyPattern was required, and
when the message cannot be delivered to the Consumer due to a failure in
processing the RM headers, then no SOAP Fault shall be returned. The HTTP
binding section gives more details on the recommended behavior in such case. (6) HTTP Binding (6.1)
Reliable Messaging with “Response” binding pattern Add: “In case the message cannot be delivered to the
Consumer due to a failure in processing the RM headers, then it is RECOMMENDED
that the response be conforming to the WS-I Basic
Profile 1.0. To achieve this, the SOAP Fault element MUST be returned in an
HTTP response with “500 Internal Server Error” HTTP status code. (see R1126 in [WS-I BP1.0]) (6.2) Reliable Messaging
with “Callback” binding pattern Add: In case the message cannot be delivered to the
Consumer due to a failure in processing the RM headers, then it is RECOMMENDED
that the HTTP response be conforming to the WS-I Basic
Profile 1.0. To achieve this, no SOAP Fault must be returned, and the HTTP
response entity-body MUST be empty, with a “400 Bad Request “ HTTP status code if the RM Fault is a Message Format
fault. (See R1113 in [WS-I BP1.0]). The status code should be “500
Internal Server Error” otherwise, in case of a Message Processing fault. . (6.3) Reliable Messaging
with “Poll” binding pattern Add: In case the message cannot be delivered to the
Consumer due to a failure in processing the RM headers, then it is RECOMMENDED
that the HTTP response be conforming to the WS-I Basic
Profile 1.0. To achieve this, no SOAP Fault must be returned, and the HTTP
response entity-body MUST be empty, with a “400 Bad Request “
HTTP status code if the RM Fault is a Message Format fault. (See R1113 in [WS-I BP1.0]). The status code should be “500
Internal Server Error” otherwise, in case of a Message Processing fault. Jacques moved to accept these changes to 4.5
and section 6, Mark Peel seconded. No opposition, motion passes. 5.3.4 Comments from Tony Graham on .999Line Comment 93, etc. Change
the many occurrences of two spaces, e.g. in 'else "notify"', to a single space. 105 Add a
comma after "side" 107 Change
"quality of service" to either "quality-of-service" or "QoS". The
present text reads like it's about the quality of the "service contracts". 118 Change
"and and" to "and". 119 Change
"Message resending" to "message resending". 135, 138 Add a space after "Table". 135 Remove
"Cardinality =". 135 Change
"And type" to "The type". 138 Some
of the namespace URIs end with '/' and some
don't. Is there any value in being consistent? Sunil: mapping of a context URI it has to end with a /. If it was .xsd it would not have a /. Resolve with overall issue. 140 Add a
new paragraph stating that XPaths are used in titles
and other places in Section 4. Also
add a reference to XPath 1.0 in Section 8. 165 Change
"will be" to "is". 176 Change
"receiving RMP" to "Receiving RMP". 185, 188 Change
"producer party" to "Producer" "Party"
was used without explanation in Section 1.2 for the combination of the Producer and the Sending RMP. It should not be used again for something different. 185 Change
"sending RMP" to "Sending RMP". 186, 190 Be
consistent about whether the parallel sentences are one sentence or two and about whether the sentences finish
inside or outside the parentheses. 192 Remove
the comma after "header". 192 Change
"identifies reliable messages" to "identifies a reliable message". 204 Change
"message which encountered" to "message that encountered". 227 Change
"E.g., Sending RMP" to "E.g., the Sending RMP". 228 Change
"sent with Callback" to "sent using the Callback". 229 The
definition of "Reply Publishing" uses none of the previously-defined terminology. For example, "error or acknowledgment" isn't consistent with other terminology. 239 Put
the definition for "Intermediary" in the terminology section since it also appears in Section 1.2. 277 Change
"response to this request" to "response to this second request". 288 Change
"sequence number which is an integer, and which is unique within a group" to "sequence number, which
is an integer that is unique within a group". 291 Change
"althouh allowed" to "although it is
allowed". 294 Change
"a sequence number" to "a unique sequence number". 300 Change
"A Reliability agreement for messaging" to "An agreement for messaging reliability". 300 Change
the hyphens to en-dash (0x2013 in the StarOffice "Special
Character" dialog box). 303 Change
"protocol features, including details about choreography between sending and receiving RMPs,
and timing parameters" to "protocol features, including timing parameters and details about choreography between sending and receiving RMPs". It
currently sounds like "timing parameters" is a third level. 311 Change
the first sentence to "Table 3 shows the Agreement Items that this specification uses." Regards, Tony Graham Iwasa: will put these editorial into the next version of the document. 6 Discussion of Document Progression.Soap must understand wording. New document .9991 ready by Thursday morning Pacific time. Question: CD numbering versus version numbering. Doug: OASIS process requires that a CD must be referenencable. It could be the may version. Keep protocol version 1.1 separate from the CD name. Iwasa will use 1.01 for the next CD name. For next week the only open is the schema names issue. Post editorial comments by Monday evening, so everone has a chance to look at them. Tentative Schedule: June 1 – all changes agreed at TC Teleconf. June 2 – Frozen document available for informal 6 day review. June 7 – editorial changes required to be posted to list. June 8 – TC votes to approve CD at Teleconf, and also votes to submit to OASIS member vote. June 15 – submission sent to OASIS Staff 1 Frequently Asked Questions· Updated Draft FAQ for comment Frequently Asked Questions about WS-Reliability Specification
Q:What is the need for the WS-Reliability specification?
Answer:
As Web Services (WS) start to be deployed across enterprise boundaries and for collaborative e-business and e-transaction scenarios, message reliability becomes a critical issue. This is because communications over the Internet (and Intranets) is inherently unreliable, as usage of the “transport protocols” (e.g., HTTP, SMTP, and other message delivery protocols) admit conditions which do not offer guaranteed or ordered delivery. Yet WS messages need be delivered to the ultimate receiver, even in the presence of component, system, or network failures. If a message can’t be reliably delivered, then the user must be so informed.
Q: What are the reliability features supported by the WS-Reliability specification?
Answer:
A] Guaranteed delivery Delivery at least once - the sent message must be delivered at the receiver, or else a notification of potential delivery failure is given to the sender.
B] Duplicate elimination - Delivery at most once -with duplicates detected and eliminated by the receiver,
C] Guaranteed message ordering – messages are delivered in the order sent
Q: How does the WS-Reliability protocol relate to WSDL operation types? Answer: WS-Reliability has been designed to support One-Way and Request-Response operations. The two following requirements are observed by WS-Reliability: 1- An implementation of WS-Reliability is not supposed to be aware of the type of WSDL operation associated with the messages it is processing. 2- The RM protocol specified is compatible with current WS-I profiles. One-Way operations: All specified RM features apply to these operations, with the following restriction: In order to comply with current WS-I profiles, the "Response" reply pattern must not be used with these operations. Request-Response operations: All specified RM features apply to these operations, with the exception of the "response" leg of the operation, to which the Guaranteed Delivery protocol as defined does not apply: the HTTP binding required by current WS-I profiles requires a particular handling of re-sending that is beyond V1.0. It should be noted that the benefits of RM features may not be as obvious for this operation type as for the previous one: because Request-Response is often supported in a synchronous way by SOAP implementations, the application will generally have a level of control that may supersede some RM features. For example, an application can be certain that a delivery of a request occurred, when it receives the correlated response. Because an implementation is not required to distinguish messages based on their associated WSDL operation type, an appropriate use of RM features will depend on the user layer. Q: When will the WS Reliability spec be completed and what is it based on?
Answer:
Agreement was reached in Nov 2003 on a committee draft spec (v0.52), which was implemented in a demo at the Philadelphia XML Conference, in Deceber 2003. The TC has recently voted on a committee draft spec (v.0.992) which completed its 30 day public review, Note that the spec is based on Requirements issues that have been compiled for the committee’s internal use (over 100 requirements have been identified).
- An OASIS standard could be approved in the 2nd Quarter of 2004
Q: What is the relationship between WS-R and ebXML V2.0?
Answer:
Overall, they both have same messaging reliability contracts as objectives: guaranteed delivery, no duplicate delivery, ordered delivery, and combinations of these.
However, WS-R has improved on scalability and performance by generalizing the use of sequence numbers, and can accommodate different security and access conditions on each party, as this is more frequently the case with a Web service and its clients, compared to more symmetrical access conditions in messaging. The reliability contract is more "application-oriented" in WS-R, where acknowledgment is on final delivery, in contrast to "on receipt" by the message handler in ebMS.
Q: Why does the spec have a different name than the TC?
Answer:
The difference in naming of the TC (WS Reliable Messaging) and the specification (WS Reliability) is a result of how materials were originally submitted to OASIS to initiate this activity. The TC chose not to rename the specification to avoid confusion with a similarly named, though unrelated, specification (WS-ReliableMessaging) that has not been submitted to a standard body. This permits one to unambiguously refer to the exact specification being discussed.
· FAQ on Reply Pattern Support Action Item work from Jacques, Sunil and Tom: The
following is a proposal for a FAQ on reply pattern support. 'Why
several reply patterns.? Answer:
Because there are different use case and deployment
scenarios and different WSDL MEPs/operations,
limiting to just one reply pattern will adversely affect its usage and
importance of the protocol. For
example, a Sender behind a firewall may prohibit incoming requests, as required
by the callback reply pattern and, hence, needs
to use some kind of polling mechanism to poll for the message. Similarly
a one-way WSDL operation cannot use a Response pattern as it is against the
WS-I Basic Profile 1.0 for a one-way operation to have a SOAP envelope in its
response. Because of such common, yet different use cases, different reply
patterns have to be supported by WS-Reliability." Ask : anybody disagree with posting
the agreed text above. Jacques moved to accept these FAQ items, abover, for first version, Seconded by Iwasa. Not discussion No opposition, motion passes. Send to carol and Ask her how
to post them. The following one needs more work: Action: Jacques, will propose further edits, on the following. Q: How is WS-Reliability designed to compose with other web service protocols?
Answer:
Web service specifications which can compose with WS-Reliability are likely to fall under the following (fuzzy) categories :
(a)- "Under WS-R": Add-ons to SOAP transport like routing, addressing, that WS-R may need to accommodate or profile. Status: nothing in the open space yet
(b)- "Supporting WS-R" specifications (policies, WSDL annotation), that support some function assumed by WS-R but not central to its deployment: Status: not finalized or not open.
(c)- "Over WS-R", Higher level specifications (BPEL, Choreography, CAF, ASAP...) would use/profile reliability, not the reverse.
(d)- "Complementary to WS-R" specifications (Security, transactions, Context...) that support other business requirements likely to be used in conjunction with reliability, and share message footprint.
SOAP header composability and processing model makes this possible.. An important consideration in design of the WS-Reliability protocol was to have it be orthogonal to any other web services protocols which define the use of soap header elements. WS-Reliability defines elements to be sent in Soap headers . Our header elements only contain parameters essential for the operation of the WS-reliability protocol. For example, WS-reliability defines a reply to element for the sending Reliable Message Processor to convey a call back address for the Reliable messaging reply. This address is independent of any other reply mechanisms used for other protocols (e.g., WSDL response is not influenced by the WS-Reliability reply To parameter). Apparent redundancy (message ID, reply to address for callback) should not be an issue
Appropriate profiling and guidelines may apply. Bob has text on the letters to send aroung Bob F mad motion to adourn. Anish seconded. Admourned at |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]