MHonArc v2.5.0b2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Dec 7 Meeting Minutes
See attachment.
--Pete
Pete Wenzel <pete@seebeyond.com>
Senior Architect, SeeBeyond
Standards & Product Strategy
+1-626-471-6311 (US-Pacific)
1. Role call
5/8 voting members present. [Ian joins later, making 6/8. Sasha and
Matt are unable to attend.]
2. Pull proposal follow up - Jeff
We have seen a few follow-up emails on this list about this topic.
Jeff: Haven't gotten much further since last call. Iwasa is unable to
attend meeting; perhaps Jacques could get further information from him
about the intent or requirements behind the proposal. If the
WS-Enumeration spec that Doug brought up would be helpful, we should
investigate that route.
We would define a "Pull Request" MSH signal. The response would be
a message. In order for it to be reliable, we also need a "Pull Ack"
signal, due to shortcomings of WS-Reliability.
Doug: The 1-to-1 approach may not be the best way to go. There is no
indication that the last item in the queue has been retrieved. Don't
see a need for Pull Ack, if we're not bundling return messages together.
WS-Reliability supports bundling of Acks. Microsoft, Sun and others
published WS-Enumeration.
http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-enumeration.pdf
[Correction: Sun did not author this, but rather a profile that includes
usage of WS-Enumeration, among other specs.] It is still proprietary
with respect to the OASIS IPR Policy, but we may request that the
authors submit it. It is used to retrieve a given number of messages
from a queue. Response contains the messages, and an indication of what
is left in the queue.
Jacques: There is no requirement for pulling multiple messages. One at a
time fulfills Iwasa's requirements. The response is synchronous, so there
is a reliability issue. Need to be able to resend the pulled message.
Doug: The model suggested is flawed. We are implementing a
WS-Reliability one-way exchange, from the recipient of the pull request
to the originator.
Jeff/Jacques: Believe that for some reason, an RM Request is not allowed
in a synchronous (pull) response.
Doug explains further....
Pete: In other words, the Pull Request contains no RM headers. The Pull
Response contains a payload and RM Request header. RM Response (Ack)
will follow as a callback on a new connection. (Agreement)
Doug: Pull Request is idempotent, so it need not be reliable (it may be
repeated without ill effect).
Pete: The business message will remain in the queue until it has been
Acked at the RM level.
Jacques: A requirement is that if the consumer of the request sends a
response that is not received, the consumer should be notified of the
failure.
Doug: We're complicating the protocol in order to use an off-the-shelf
WS-R module. That may be a misguided effort.
Jacques: Still not sure that WS-R supports what we're trying to do.
Pete: If the "transmit" operation is abstract, then in the "normal"
case, the message is sent from client to server. In the "pull" case,
it is placed in a queue. Believe the WS-R abstract model would support
this, but the current HTTP binding would need to be extended.
Doug: Agrees.
Jacques: Would like to make Pull Request a reliable message. We need
notification of failure.
3. WS-Security integration results - Jeff
Pete sent an email referencing the latest WSS SwA Profile.
4. How do we - proceed - divison of work?
Sorry, I have lost track of our decisions here.
5. SOAP 1.1 decision communication, reasons, publication.
Did we postpone this one or finish dealing with it?
6. Future meeting schedule, especially Dale's offer to host in Scottsdale.
Jeff would prefer to meet for more than 2 days.
Avoid golf tournament Jan 31 - Feb 6.
Proposed F2F date is all day Jan 26, 27, and half day 28th.
7. A.O.B.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]