[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FpML-BP Updates choreography including RequestTradeMatch

One additional thought crossed my mind.
I know that most of you are new to this choreography stuff and it may seem a bit heavy given what you are used to. So I want to give you at least my take on why I think it makes good commercial sense and industry sense to use 
it in the work we are all doing on FpML.
Simply stated, today FpML is pretty good at providing a standardised messaging format for derivatives. This can be seen by its growing adoption. Given that the industry as a whole is under pressure to automate - since the Corrigan letter in 
Nov 2005 - anything we can do to enable STP would be good thing.
Message formats is the start of that process. We all know that the message exchanges are important too. We could continue with sequence diagrams and descriptive text to help developers to write the software needed to implement STP between parties but the risk is inexact software and lack of interoperability between parties. This will hold up the move to STP. By providing a clear, complete and unambiguous description of those message exchanges we can increase the success of developers writing the necessary software because the software can be tested against such 
a description to ensure that it is correct.
I understand fully that this is a a large task but I think it is a small hill rather than a large mountain to climb (I believe the current work shows this to be true) and even if we do not succeed fully I am sure that we will at least flush out problems - I always think it is better to know what problems we have than not know at all. 



Just a few thoughts....

Steve T

On 7 Jun 2007, at 08:33, Steve Ross-Talbot wrote:
Enclosed is a zip file for the choreography project for confirmations (as before) corrected with RequestTradeMatch.
Take a look at the html in the src/choreography/html folder and see what you think. 

Questions and issues to consider:

	1. Is this correct? If not what is wrong with it?

	2. Identity - xsi:type + tradeIdentifier + version
Is this correct? The choreography can support multiple and different identities as single or composite keys. What is important is to locate or bind these identities in the message to the ChannelType. You can see this in the choreography. We do need identities because without them one cannot monitor what is going on at all. With a choreography one has the possibility of monitoring against plan (the choreography description) which 
			is a stronger form of monitoring.
What about allocations? How do they relate to trades? How do we distinguish between them and the underlying trade? 

	3. +ve ack as opposed to none
There are none in this model. Should it be supported? Do we need two models on for +ve ack and one for no ack? 

	4. Confirmations for other business events
Only for new's and maybe amendments, what about increase/ decrease/novation etc? If we can agree to this process then what about doing the rest? How do we deal with things that might happen as opposed to things that have happened.
5. What artifacts from a choroegraphy suite are desirable for the standard (i.e. to be included)? 
			The model itself in various forms (BPMN, UML, WS-CDL, HTML)?
Scenarios that have been validated against the model (i.e. sequence diagrams)? Does the HTML textual version need to be changed - to add more or less - to be included directly in the 
			documentation?
These are some of my questions/issues at the moment. I am sure there will be others from Matthew and Brian in due course 
as well as from many others.

Cheers

Steve T

<Confirmations-FpML4.3.zip>





-------------------------------------------------------------------------------
To unsubscribe: Email majordomo@xxxxxxxx with a blank subject line
In the body include the line: unsubscribe bpwg youremail@address
To view archives: http://www.fpml.org/_wgmail/_bpwgmail/threads.html