[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FpML-BP Updates choreography including RequestTradeMatch
"Identity
- xsi:type + tradeIdentifier + version Is this correct?" - You
do not say what it is the identity of you are looking for. Yesterday in
the teleconference you said at different times the identity of the message,
the conversation, and the request confirmation. These are three different
types, so have three different identities. Which is it you want the identity
of?
Not knowing which of the three you want, I can give
you the answer to all of them. According to the FpML Specification you
can use the following:
- Conversation Identifier is /FpML/header/conversationId
- Message Identifier is /FpML/header/messageId
- Request Confirmation has no identifier
IMHO there should be an identifier for
the Confirmation Request. It should be added. It should be added for every
event.
Most vendor implementations of FpML
I have seen of confirmations get this wrong by making incorrect assumptions
such as:
- Each business message gets messaged
once, whereas in reality I can send the same message multiple times. (multiple
sends of one message)
- Each message is delivered once every
time it is sent, whereas in reality delivery service is "at least
once" and therefore a message can be delivered multiple times (highly
assured delivery)
- Each business event gets put in one
messages, whereas in reality I can put a RequestConfirmation in multiple
messages. (multiple messages per event)
- Each trade has only one Confirmation
Request per counterside. In reality I can alledge it many times.
- Each trade has Confirmation Requested
from only one counterside. In reality I can alledge against more than one
counterside.
How does your choreography definition
preclude or cope with these four typical incorrect assumptions?
Matthew Rawlings
+44 7917 596 827
Steve Ross-Talbot <steve@xxxxxxxxxxx>
Sent by: bpwg@xxxxxxxx
07/06/2007 08:33
|
Please respond to
bpwg@xxxxxxxx |
|
|
To
| bpwg@xxxxxxxx
|
|
cc
|
|
|
Subject
| FpML-BP Updates choreography including
RequestTradeMatch |
|
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
[attachment "Confirmations-FpML4.3.zip" deleted by Matthew D
Rawlings/JPMCHASE]
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to UK legal entities.