Notes from 1/26, F2F Day 1

[Pete Wenzel <pete@seebeyond.com>]

This is what we've covered so far today.

> 1. Review of completed reliability section with special attention to
   the pull functionality to ensure consistency.

Begin walkthrough of Jacques' Reliability document.
He proposes several definitions of terms to be used throughout.

Discussion of Section 6, MEPs becomes necessary:
SOAP 1.1 does not provide definitions for one-way and req/resp MEPs,
  so we need to define them in terminology that maps to SOAP 1.1 spec.
Refactor Section 6 into 2 parts: simple patterns using same SOAP MEP, and
  aggregate patterns using >1 SOAP MEP.
Note that RefToMessageId cannot be used to distinguish the
  simple/aggregate cases; it distinguishes an MSH Request message from
  an MSH Response message.
More discussion about the set of abstract MSH MEPs, and where the
  RefToMessageId is needed.  We believe that in the case of Pull,
  the Response Message need not refer to the Pull Signal, but only
  to the Request Message.
RefToMessageId is passed through to the application (or handled by a
  correlation layer between MSH and app), in the case of correlating
  request-response message pairs; or handled internally by the MSH,
  in the case of Fault references.

Back to Jacques' Reliability document:
2.2: An MSH logically contains an RMP, but is not itself an RMP.
2.3: The only restrictions placed on RM Agreement is on ReplyPattern,
  so mention only that.
2.4: Assumes reliability of RM Response; however, WS-R v1.1 left this
  out of scope.  We are anticipating this feature to be described in
  the near future.
  Pull signal is accomplished via RM-Submit (on business message receiver
  side) and RM-Deliver (on sender side).  Pull Signal is recommended to
  be sent reliably.
  It is not necessary for Pull signals to be delivered in order, since
  messages in the virtual MSH queue may not be in order anyway.
Discussion about what happens when the queue is empty.  How does RMP that
  receives a Pull signal know whether a response (from the queue)
  is expected, following a Deliver operation (that is, whether the
  synchronous connection should continue to be held open for an eventual
  response, or terminated because there will be no response)?
  * Still an open issue.
2.5: To the RMP, Synchronous Request/Response looks the same as the
  Pull MEP.  (The difference, at the MSH level, is that the latter begins
  with a Pull signal instead of a Request message.)

Reliability of an aggregate MEP is equivalent to reliability of its
  constituent simple MEPs (with some additional MSH-level coorelation
  via eb:RefToMessageId).

Remove processing sequence from 2.2, and insert a specific sequence for
each MEP.  May include security steps in this as well.



> 2. Review and completion of WS-Security inclusion

> 3. Completion of Payload services


> 4. Complete review of specification identify outstanding work
>    Examples
>    Bindings
>    Appendices

* Need to rename 5.4 "Modes of Operation" to something more accurate.

> 5. Requirements for future work and F2F

> 6. BPSS alignment & CPA version control / identification

--Pete
Pete Wenzel <pete@seebeyond.com>
Senior Architect, SeeBeyond
Standards & Product Strategy
+1-626-471-6311 (US-Pacific)