FpML Issues Tracker
closed
Minor
Always
Architecture
Admin
andrew
Summary
Add a messageAccepted message. messageAccepted is the opposite of messageRejected. For each business message the response is either messageRejected or messageAccepted. A response must be given so that the completion of this exchange is observable.
Today when a businessMessage is sent the response can either a messageRejected or nothing. The problem with sending nothing is that the businessMessage sender cannot tell when the process has completed. The sender does not know whether the message was accepted, yet to be considered, or is waiting to receive a rejection. The sender is in effect left hanging and the messaging session never completes.
Notes:
matthew
04/04/07 1:23 pm
A timeout at one end would also be observable.
andrew
05/30/07 9:37 am
The message specification 3.1.2 states:
“Throughout this document we have assumed that message exchanges will be carried by an asynchronous passing of messages over a highly assured transport, such is provided by a messaging queuing system. This form of transport is commonly used today in the finance industry (e.g. AMQP, Apache QPid, FIX engines, MQSeries, MSMQ, RabbitMQ, SwiftNet Interact ‘Store and Forward’, etc.).
One important consequence of this decision is that error cases related to non-delivery do not have to be considered (e.g. once accepted a guaranteed messaging queuing system WILL ALWAYS deliver a message) although the ‘freshness’ of the message may need to be considered (e.g. has the message been stuck in a queue waiting to be delivered for a long period of time). Similarly message queuing system can normally eliminate duplicate messages so these are not considered either.”
All the processes to date have been design with a ‘fire and forget’ style of messaging. If we wanted to adapt FpML business processes to less guaranteed styles of messaging then we would have to redesign them to provide more response messages to provide the direct acknowledgement that you think is missing.
Just adding a messageAccepted does not solve the problem.
matthew
05/30/07 11:13 am
Andrew – you are missing the problem. The problem is not whether the message was accepted or not, but how to know when the business process is complete. There needs to be some sort of message to differentiate between the end of the business process and the message rejected. If the MessageAccepted was renamed MessageNotRejected or TransactionCompleted then it would serve the same effect. How else do you propose to know the business transaction is completed? What is your solution?
andrew
05/30/07 11:32 am
To my knowledge there only the messages for the confirmation and matching process exhibit non-observability (e.g. submitting/modifying a new trade does not generate an immediate response). All other requests should generate either a reponse, an error condition (e.g. TradeNotFound) or a message rejected (e.g. bad XML content).
The business processes for increase/termination/amendment are not fully documented in the specification (e.g. no sequence diagrams) which is a mistake and should be corrected. Any message choreography you have for them may be different from what was intended.
matthew
06/07/07 1:22 pm
Agreed at AWG 2007-06-07 that Marc Gratacos will propose a change to the Architecture Specification that incorporates the principle that all business process definitions must have an observable completion. The BPWG will make specific changes to comply.
mgratacos
06/28/07 10:04 am
Agreed that we should incorporate the principle that all business process definitions must have an observable completion.
However, I am not sure it fits in the Architecture Spec. Should we include it in the Spec in the Business Process Architecture Section instead of the Architecture Spec?
mgratacos
07/05/07 1:33 pm
A flag to indicate that the sender wants to receive a response may blur the distinction between business and transport messages.
All request business messages should have a business response. Business processes need to be cleaned up before introducing a generic message accepted.
Message accepted sits in the middleware space. Some participants expressed that if the content of a message accepted is not business content, it shouldn’t be defined in the business message layer.
mgratacos
07/13/07 8:48 am
The following bullet point has been added to section 3.1.2 Design Assumptions of the Specifications:
* All business process definitions must have an observable completion. The set of messages defining a business process needs to be complete. In addition, timeouts must be defined if necessary.