- From: Steve Ross-Talbot <steve@enigmatec.net>
- Date: Mon, 5 May 2003 17:59:51 +0100
- To: public-ws-chor@w3.org
- Message-Id: <FCDCB6F6-7F1A-11D7-9BEB-000393AD2AA6@enigmatec.net>
Background Financial Service, at least wholesale banking (investment banking), differs from most other web service domain in that it is much much more dynamic. Dynamic in this sense means that the act of deciding who to trade with depends on information that is dynamic. Prices tend to predominate in this domain but they may be seen as serving to guide as to what one might do. So for example if the price exceeds a certain threshold you might do one thing. If the rate of change exceeds a threshold you might do something else. Of course any trading situation that is price driven (commodity, energy, derivatives and so on) markets. So this problem will apply to Elf, BP, Shell, Total, and of course any US based energy markets as well as the futures markets attached to them and the commodity markets are the same. Description of how it is done today Today Joe Trader (JT) simply doesn't do it. Sophisticated Trader does. ST looks at all sorts of market indicators and decides what strategy to employ. That strategy might be to place trades with specific execution venues. An execution venue is some place (represented by a company i.e. TradeWeb, Instinet, MTS, EuroMTS etc etc) at which buyers and sellers meet up. because there are several venues for different types of financial instrument ST needs to keep in their head what the different contracts are for each venue. So one venue might allow immediate price change, another might say only for order above a certain value and another might simply restrict it to prices changes every 5 minutes (from the point of view of whoever places that price). Because only ST can have a hope of managing the situation the general case put financial service inititutions at risk. They might offer a US treasury bond at one price for 10 million units but over multiple venues. They want to sell 10 million. But the venues increase their risk to the number of venues times the units. Only ST, at best, can manage this. IT support is needed. Description of what would be desirable tomorrow What they would like to do is on a per trade basis indicate how the trade should be placed. So JT (let alone ST) might want to place a 10 million units deal across several venues based on some business rule that minimizes their exposure. On the other hand JT might want to indicate the price of a deal right now, with the intention of changing the price pretty soon while a bigger deal, that may change the price anyway is being pursued. Obviously JT (as well as ST) want to ask each venue what their contract allows in order to place the trade in the optimal way. What does this have to do with Choreography I thought I'd add this to make the relevance clear. The impact on choreography is that the very contract that a choreogaphy (the external observable behaviour ) represents may provide attributes that form part of a query or constraint that is part of a strategy employed by a JT or an ST to do their job. Without necessarily lifting a skirt on a venue, a venue could be a web service, a JT or an ST could be interacting with another web service. What they both want to do is examine the potential venues (web services) so as to correctly place their trade with those venue based on some behavioural attributes. This is late binding of web services based on choreography as well as impacting other possible aspects of web services such as UDDI etc etc. Closing note I'd be happy to add more to this if required to do so.
Attachments
- text/enriched attachment: stored
- text/ignore attachment: SecurityCheck.txt
Received on Monday, 5 May 2003 13:00:33 UTC