FpML Issues Tracker
closed
Crash
Always
Architecture
Admin
andrew
Summary
The messaging quality of service requires definition. At the moment there is a lack of consensus and this is affecting the business process definition adversely.
1. Is the transmission and receipt of messages unordered or ordered? If ordered is it totally ordered, causally ordered, totally or causally ordered within a conversation? How do you order across Parties and across sytems? How do you prevent back-channels (telephone calls, faxes, etc.).
2. Which of Unicast, Multicast, and Broadcast are supported? NB This refers to the standard definitions of these and not IP implementations.
2.1. Unicast implies each message can have only one destination. For multiple sendTo and copyTo how would this be implemented? Would there be sequential sends rather than parallel?
2.2. Multicast implies each message may have more than one destination; that for one send there are potentially multiple recipients.
2.3. Broadcast implies that a message is sent to an address others subscribe to. Is Broadcast required for the Quotes and IOI processes? How are these implemented. Is a 'market' a group of destinations or a single destination itself?
3. All or none receivers. When a message is sent may it be received by some receivers but not others. Specifically is there a transaction on writing to all receivers or none?
Notes:
matthew
04/04/07 8:37 am
What is the SWIFT Network quality of service?
matthew
04/04/07 1:35 pm
Discussions between MDR, AJ, MG, MPD, FM
1. The SWIFTNet system is unordered. This has been a problem for SWIFT with Accord.
2. SWIFTNet offer multicast on the interface, not the implementation. You are not bound to unicast. Broadcast is not supported.
3. There is no transaction on all or none receivers.
andrew
05/30/07 10:01 am
Different qualities of service call for different messaging patterns. FpML processes are currently designed for a ‘fire and forget’ pattern using guaranteed (at least once) delivery. If we wish to consider others then the BPWG will need to adapt them.
Ordering is only as issue if messages relating to the same business object are send more often then they are delivered to, and processed by, the recipients.
Most of the processes we have designed to date are likely to be invoked very infrequently for each transaction so the majority of message flow will arrive in order with respect to each transaction.
Where a message is sent to multiple recipients the act of sending should appear atomic (e.g. all get the message or none get the message).
Broadcast implies that distribution to determined elsewhere, it might be through publish and subscribe, it might also be determined by an intermediary (such as an exchange).
matthew
05/30/07 11:08 am
“Different qualities of service call for different messaging patterns. FpML processes are currently designed for a ‘fire and forget’ pattern using guaranteed (at least once) delivery. If we wish to consider others then the BPWG will need to adapt them.” – this is agreed, but “fire and forget” is only one aspect of the quality of service. You also need to consider the other aspects. These are:
1. Is delivery time-bound?
2. Can an address be a broadcast address.
“Ordering is only as issue if messages relating to the same business object are send more often then they are delivered to, and processed by, the recipients.” – this is an incorrect (simplistic) definition of “causal order”. There may be non-messaged objects that determine what messages get produced.
“Most of the processes we have designed to date are likely to be invoked very infrequently for each transaction so the majority of message flow will arrive in order with respect to each transaction.” – this is just not reliable enough. A “majority” of correct messages isn’t enough, they need to all be correct.
“Where a message is sent to multiple recipients the act of sending should appear atomic (e.g. all get the message or none get the message).” – this is unimplementable. You can determine whether the message is sent, but not whether it arrives. Following this statement exactly would lead to you putting a transaction on all endpoints receiving. Do you mean instead to have a transaction on sending to all endpoints?
andrew
05/30/07 11:52 am
“”Ordering is only as issue if messages relating to the same business object are send more often then they are delivered to, and processed by, the recipients.” – this is an incorrect (simplistic) definition of “causal order”. There may be non-messaged objects that determine what messages get produced.”
Actually its more a temporal ordering – Casuality implies seeing the ’cause’ before the ‘effect’. To have a causal ordering problem a message would go to two or more reciepients who produce a new message as a result. This might be true of the novation process but is not true of any of the others.
“”Most of the processes we have designed to date are likely to be invoked very infrequently for each transaction so the majority of message flow will arrive in order with respect to each transaction.” – this is just not reliable enough. A “majority” of correct messages isn’t enough, they need to all be correct.”
Adding a protocol over the messaging to enforce total reliability and/or ordering on every message is complex and expensive (in terms of additonal messages/bandwidth/processing time) and not often needed. As long as you can detect when a problem has occured you can operate a simpler protocol and begin a recovery process on the rare occaisions it is actually needed.
matthew
06/07/07 1:18 pm
Agreed at AWG 2007-06-07 that Marc Gratacos will circulate the ISO20022-6 document for voting at the AWG this week. The proposal is to incorporate the ISO20022-6 contents into the architecture specification.
matthew
07/12/07 1:20 pm
Agreed at AWG 12th July 2007 that we agree:
1. To incorporate the ISO20022:6 Reliable Mode by value (incorproate equivalent text) into the FpML Architecture document.
2. Marc will make a proposal for the following week for us to review at the AWG.
mgratacos
07/26/07 10:48 am
See attached FpML Transport Characteristics. A first attempt to incorporate MTC into FpML.
matthew
07/26/07 1:38 pm
nought is spelt with an “o” not an “a”.
matthew
07/26/07 2:16 pm
You need to define:
1. The layers and their relation to OSI or TCP
2. Be clear that Message Transport is a role that can be played by either endpoint in a peer to peer setup, or by one or more third party systems
3. “Business rules” means the schema constraints defined in the validation rules. These are not generic business rules.
polis
08/16/07 2:35 pm
There was concern that the Transport Characteristics section could be considered to impose an implementation requirement.
The v2.doc spec says
“The definition of the FpML business processes assumes the use of reliable messaging …”.
The purpose of assuming reliable messaging is provided to make it easier to design standard business processes and messages. The control signals to provide reliable messageing are assigned to a service layer.
For example, a bulk load of reports in an fpml message format could be sent by ftp to another party. That is perfectly ok. If the parties wanted to ensure the bulk load was successful, they could simply make a phone call. This means that we don’t have to explictly design messages at the business level to cope with failed bulk report loads.
mgratacos
08/16/07 2:35 pm
We need to add a section for ‘Purpose’.
The purpose of the Message Transport Characteristics is to precisely define the set of transport characteristics’ assumptions that FpML is based on. If the transport characteristics were not defined, the business process definition would be ambiguous.
mgratacos
02/07/08 10:35 pm
A Transport Characteristics section has been added to the Business Process Architecture Section of the Specifications. This has been committed to the trunk.