Need clear explanation of market-related data types

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

RE: Need clear explanation of market-related data types

grampajohn
Administrator
chris.flath wrote
We always said that privision of analysis tools is crucial for Power TAC to be successful. Using a standard market design and standard data types for the wholesale market allows direct application of typical statistics package from financial markets.

AFAIK this was also a reason behind some of the data fields in the order objects and the order book to match the Reuters financial standards.
I agree that access to standard tools is important, but the rest of us are not familiar with the Reuters financial standards, and you have not told us what they are. I don't doubt that the original design incorporated those standards, but I have no idea which fields were derived from the standard and which were not.

Let's also keep in mind a few other factors. First, financial analysis is just one kind of analysis folks will likely be interested in. It may be the most important kind of analysis, and it may not be. I don't know. Second, the primary purpose of the simulation database is to support the simulation, not to support analysis. What's important is not that the database directly support a range of analysis purposes, but rather that the data dumped at the end of a simulation can be easily transformed into a form that is well-adapted to a variety of analysis purposes. This is standard industry practice, that the database supporting business transactions must be transformed and indexed before it's really useful for analysis.

So my feeling is that as long as we can produce the data matching the Reuters standard by post-game transformation, we should not burden the simulation with keeping track of data that it does not need.

Does this make sense?

John
Reply | Threaded
Open this post in threaded view
|

RE: Need clear explanation of market-related data types

chris.flath
In reply to this post by grampajohn
To write up the wiki storyline for the wholesale market I would like to get a settlement in this issue:

We have discussed the following formats:

a) CDA
Brokers can continuously submit shouts to the orderbook which clears if possible after each shout submission
b) multi-round PDA / call market / periodically clearing, continuous trading:
brokers can submit shouts which get collected in the order book which is cleared in fixed intervals - to respond to new developments brokers can delete non-executed shouts
c) single-round PDA
brokers can submit shouts only once per auction and these get cleared subsequently

a) was implemented in the prototype but latency and compression hinder the application in the real competition
b) was implemented by Daniel (using the CDA base) on the spring architecture - it should be easily adapted to the current architecture
c) was not yet implemented - it is potentially easier to initially implement but may offer limited scope afterwards. It seems to be a special case of b)

I just fear that thorugh the indirectness of the mailing list we seem to be misunderstanding each other and potentially missing important aspects. So I hope we quickly find the common understanding - then Daniel and I will write the wiki story and the market gets finally implemented.

I personally thought that b) is a good way of meeting halfway but if there is serious arguments against it we should not do it.

grampajohn wrote
So my feeling is that as long as we can produce the data matching the Reuters standard by post-game transformation, we should not burden the simulation with keeping track of data that it does not need.
Completely agreed - we definitely can leave not required stuff out if they can just be added afterwards as long as the market format is comparable. The important requirement for financial analysis is the repeated interaction to make price evolution observable.
Reply | Threaded
Open this post in threaded view
|

RE: Need clear explanation of market-related data types

grampajohn
Administrator
chris.flath wrote
We have discussed the following formats:

a) CDA
Brokers can continuously submit shouts to the orderbook which clears if possible after each shout submission
b) multi-round PDA / call market / periodically clearing, continuous trading:
brokers can submit shouts which get collected in the order book which is cleared in fixed intervals - to respond to new developments brokers can delete non-executed shouts
c) single-round PDA
brokers can submit shouts only once per auction and these get cleared subsequently

a) was implemented in the prototype but latency and compression hinder the application in the real competition
b) was implemented by Daniel (using the CDA base) on the spring architecture - it should be easily adapted to the current architecture
c) was not yet implemented - it is potentially easier to initially implement but may offer limited scope afterwards. It seems to be a special case of b)

I personally thought that b) is a good way of meeting halfway but if there is serious arguments against it we should not do it.
We are modeling a day-ahead market, and optionally a balancing (ancillary services) market. There are serious proposals to combine those markets, but so far they are separate in all jurisdictions we are aware of. None of those markets is a CDA market - the existing CDA markets are for options and futures contracts, farther in the future than one day. The EEX day-ahead market clears just once every 24 hours as far as I can tell, while the pool markets in North America, Scandinavia, and much of the rest of the world clear once/hour, more or less. That is because the format of the bids is too complex, and because of the need to incorporate transmission constraints. I strongly recommend that you get a copy of Shahidehpour, Yamin, and Li, Market Operations in Electric Power Systems, and develop a clear understanding of how these markets work.

These are all wholesale markets; they are the way power is moved from large-scale energy producers to distributors and retailers, and that's what we need to simulate. There are two basic models - exchange and pool. The exchange model is more complex and less coordinated, and would be much more complex to simulate because there are multiple more or less coordinated markets for the same commodities. Because of its simplicity, and because it's very widely used around the world, we are modeling an abstract pool market for now - there's a single market that generates all commitments to buy and sell power.

So I believe we should be modeling a pool market that clears once/hour for contracts extending from one hour in the future through 24 hours in the future. That way, brokers get 24 chances to observe and influence prices for each "block" of power they must import or export, and of course they are free to engage in arbitrage across those 24 market clearings once they have a notion of how prices will likely evolve. This is the single-round PDA model.

Most of these markets, including the EEX, have fairly complex bid formats, that allow specification of some sort of price-quantity function, and in the case of EEX, specification of multi-hour bundles. Those complexities, I believe, should be abstracted away for now, and replaced with multiple independent bids.

In the end, I believe our goal should be to provide a market model that is a reasonable abstraction of real-world markets, but abstracts away the physical constraints (congestion), unnecessarily complex bid formats, bilateral contracts, and options and futures contracts. Once we have experience with running a competition and building agents, we can decide which additional features, if any, will enhance the research value of Power TAC for our audience without introducing unnecessary complexity. Of course, individual research groups are free to build their own more complex market models if they wish, but to the extent that agents need to be redesigned to adapt to these markets, they would lose the ability to test against competition-proven agents from other research groups.

Does this help make the issue more clear to you?

John
Reply | Threaded
Open this post in threaded view
|

RE: Need clear explanation of market-related data types

chris.flath
grampajohn wrote
None of those markets is a CDA market - the existing CDA markets are for options and futures contracts, farther in the future than one day.
The EEX/Euronext EPEX Intraday Market allows continuous trading up to 75 minutes ahead of an hour.

grampajohn wrote
That way, brokers get 24 chances to observe and influence prices for each "block" of power they must import or export, and of course they are free to engage in arbitrage across those 24 market clearings once they have a notion of how prices will likely evolve.
So what do we want? Trade 23 different "versions" of each hour or trade one hour continuously / periodically for 24 hours? The latter seems to offer the advantage of having one price evolution which can be directly analyzed versus the 23 different auction prices. Moreover, by extending the pre-trading period we can easily blend in a futures market and analyze the effect of longer trading periods. Also we already have a rough implementation at hand.

grampajohn wrote
Most of these markets, including the EEX, have fairly complex bid formats, that allow specification of some sort of price-quantity function, and in the case of EEX, specification of multi-hour bundles. Those complexities, I believe, should be abstracted away for now, and replaced with multiple independent bids.
This is true for the day-ahead auction - here you specify a price-quantity function. In the EPEX intraday you continuously trade hourly power.
Reply | Threaded
Open this post in threaded view
|

RE: Need clear explanation of market-related data types

grampajohn
Administrator
chris.flath wrote
The EEX/Euronext EPEX Intraday Market allows continuous trading up to 75 minutes ahead of an hour.
Yes, but that is not the whole market. This is from pg 18 of Ockenfels et al. "Most electricity spot auctions operate in the form of a sealed bid auction. In sealed bid auctions there is only one round of bidding; this means that the participants in the auction do not get any feedback on other bidders’ bidding behaviour in the auction to which they could respond. In various countries, there is also continuous exchange trading before and after the day-ahead
auction, e.g. also on EEX." So the open-bid auction you refer to is part of a larger structure, and only captures a portion of the trade quantity. It is not the primary market. As far as I can tell, the EEX market is very complex and decentralized, and works differently in different places. Modeling it effectively seems fairly hopeless to me, and would be a major distraction from the key research issues we hope to address in Power TAC.
chris.flath wrote
So what do we want? Trade 23 different "versions" of each hour or trade one hour continuously / periodically for 24 hours? The latter seems to offer the advantage of having one price evolution which can be directly analyzed versus the 23 different auction prices. Moreover, by extending the pre-trading period we can easily blend in a futures market and analyze the effect of longer trading periods. Also we already have a rough implementation at hand.
I think there are two differences. One is the need to re-submit bids for the periodic auction format. I think that's simpler for the bidders anyway. We would be trading each hour repeatedly for 24 cycles. Of course the prices 22 and 23 hours ahead would inform the bidding 21 hours ahead for a particular 1-hour block. The other difference is in price formation - in a continuous auction, bids and asks are matched individually, whereas a periodic auction (and the pool markets for power in most countries, including the day-ahead auction market in EEX) clears at a single price. That is why I was asking earlier about broker feedback, whether the orderbook should include just uncleared bids, or all bids. However, if you don't clear at a single price, then the order in which bids and asks are considered can have a big influence on the outcome, specifically with regard to distribution of surplus and which bids and asks get matched.

John
Reply | Threaded
Open this post in threaded view
|

RE: Need clear explanation of market-related data types

Wolf
Administrator

In Power TAC we are particularly interested in the spot and day-ahead. The most day-ahead markets around the world are pool markets and they clear once per hour. EEX on the other hand only clears once in 24h, and it doesn’t deal with physical constraints. In contrast, in pool markets one trades through a central market considering physical constraints, therefore these markets need to clear once per hour. If the European grid will expand as planned, i.e. taking power from sun power in North Africa or Water/Wind power from Norway, etc. then they need to integrate these physical constraints and then the whole EEX trading scheme will change, and I think this will happen in future enhancements.

 

My experience from running/participating almost 10 years in TAC SCM and other competitions is that we have to maximize research value and subsequent motivation for all the teams around the world. Therefore, we carefully need to design an abstraction of the real world, since real world systems are by far too complex, since these have too many different factors influencing the final outcome. EEX, for instance, is a collection of four different markets, and much of the trading is done outside of the day-ahead market.

 

To ensure that we are making progress, and to enable different kind of markets I suggest the following. I challenge Chris and Daniel (since they work on this already, but of course, anybody else is invited too) to come up with a bid representation that makes sense for both markets. After we have done this, we can start with a simple call market, and then extend later to different market structures, but before we move on to more complex ones, we need to get a thorough understanding of the simple setup. This is extremely important, since we want by all means avoid losing important research audience around the world. Currently, the structure of the competition is more important than the pre-existing analysis tools. After we have a mutual bid representation, and an initial call market, we can go to more complex markets like EEX, but again, EEX is also not very transparent; in pool markets all transactions are visible, where in EEX the majority is traded outside the day-ahead market. Further, there are obviously similarities between financial and energy markets, but they are far from the same. It should be relatively easy to write an adapter after the fact to match up whatever structure you like.

 

Cheers,

 

Wolf

 

 

From: grampajohn [via Power TAC Developers] [mailto:[hidden email]]
Sent: Wednesday, March 23, 2011 07:45 PM
To: Wolf Ketter
Subject: RE: Need clear explanation of market-related data types

 

chris.flath wrote:

The EEX/Euronext EPEX Intraday Market allows continuous trading up to 75 minutes ahead of an hour.

Yes, but that is not the whole market. This is from pg 18 of Ockenfels et al. "Most electricity spot auctions operate in the form of a sealed bid auction. In sealed bid auctions there is only one round of bidding; this means that the participants in the auction do not get any feedback on other bidders’ bidding behaviour in the auction to which they could respond. In various countries, there is also continuous exchange trading before and after the day-ahead
auction, e.g. also on EEX." So the open-bid auction you refer to is part of a larger structure, and only captures a portion of the trade quantity. It is not the primary market. As far as I can tell, the EEX market is very complex and decentralized, and works differently in different places. Modeling it effectively seems fairly hopeless to me, and would be a major distraction from the key research issues we hope to address in Power TAC.

chris.flath wrote:

So what do we want? Trade 23 different "versions" of each hour or trade one hour continuously / periodically for 24 hours? The latter seems to offer the advantage of having one price evolution which can be directly analyzed versus the 23 different auction prices. Moreover, by extending the pre-trading period we can easily blend in a futures market and analyze the effect of longer trading periods. Also we already have a rough implementation at hand.

I think there are two differences. One is the need to re-submit bids for the periodic auction format. I think that's simpler for the bidders anyway. We would be trading each hour repeatedly for 24 cycles. Of course the prices 22 and 23 hours ahead would inform the bidding 21 hours ahead for a particular 1-hour block. The other difference is in price formation - in a continuous auction, bids and asks are matched individually, whereas a periodic auction (and the pool markets for power in most countries, including the day-ahead auction market in EEX) clears at a single price. That is why I was asking earlier about broker feedback, whether the orderbook should include just uncleared bids, or all bids. However, if you don't clear at a single price, then the order in which bids and asks are considered can have a big influence on the outcome, specifically with regard to distribution of surplus and which bids and asks get matched.

John


To start a new topic under Power TAC Developers, email [hidden email]
To unsubscribe from Power TAC Developers, click here.

Reply | Threaded
Open this post in threaded view
|

RE: Need clear explanation of market-related data types

grampajohn
Administrator
Wolf wrote
To ensure that we are making progress, and to enable different kind of markets I suggest the following. I challenge Chris and Daniel (since they work on this already, but of course, anybody else is invited too) to come up with a bid representation that makes sense for both markets. After we have done this, we can start with a simple call market, and then extend later to different market structures, but before we move on to more complex ones, we need to get a thorough understanding of the simple setup.
I think this makes sense - essentially, use a representation for bids, asks, and orderbooks that will support a more complex market structure (which might also include constraints or preferences on energy source and carbon content, or some sort of price-quantity function), but implement a simple call market, with no carryover of bids between periods, for now. From a software design standpoint, this would ideally be done in a way that does not burden brokers and other components with complex representation and processing unless they need it.

Cheers -

John
 
Reply | Threaded
Open this post in threaded view
|

RE: Need clear explanation of market-related data types

Daniel Schnurr
The current shout (=order) representation allows for limit and market orders per timeslot. Therefore it enables the brokers in an easy way to express their valuation. They can express price-quantity functions by issuing several limit orders per timeslot. But they don't have to.

The Green property could be enabled later through the product class. That's why I prefer to maintain it. It does also allow for futher extentions such as options.

Transparency is enabled through the information that is issued by the market. Two objects in our market were designed to fulfill this functionality:
- Pre-Trade Transparency: Orderbook - The top 10 bids and asks (with respective quantities) are issued to the brokers in the time horizon before the matching
- Post-Trade Transparency: TransactionLog - provides information about executed trade prices and volumes.

The call auction algorithm was already implemented in the last version of the pda plugin.

I think all the stated requirements in this thread can be handled adequately by the presented design of domain objects in the earlier market version. I will sit down with Chris to write down the wiki scenario in a hopefully clarifying way so we can discuss it further on this basis.
Reply | Threaded
Open this post in threaded view
|

RE: Need clear explanation of market-related data types

grampajohn
Administrator
Daniel -

This sounds good. TransactionLog has not been eliminated, just the name changed to MarketTransaction. I think it's OK for now to keep the Product class, but allow it to be null if we are not using it. I'm guessing it will never be used in its original form.

I also suggest that when we implement markets that allow changes to outstanding Shouts, we use a fairly simple representation like we are using for Tariff updates. Remember, groovy dispatches on argument type at runtime, unlike Java. See TariffMarketService for an example.

Eventually we may want to build Shouts very much like Tariffs are built - a basic framework with attachments, as Rates are for Tariffs. That would make it easy to represent step-function bids as in most pool markets, bundle bids like EEX, or different prices for different "qualities" of energy.

Cheers -

John
Reply | Threaded
Open this post in threaded view
|

RE: Need clear explanation of market-related data types

Daniel Schnurr
Okay that sounds good.

But I think the MarketTransaction as I understand it at the moment has a slightly different layout than the TransactionLog.

Since the MarketTransaction is associated with one broker it represents the effects of a trade for one party that is involved in this trade (=single broker)?! Therefore I saw the main purpose in reporting market transactions for a single broker to the accounting service.

The TransactionLog was intented to express the overall quantity traded in a clearing plus the price. (The seller/buyer property would be used just in case of a cda where a trade is executed always between two parties). Therefore the main purpose was to publish trade information to the public.

So how do we publish trade information to the public in the new model? Is my understanding of MarketTransaction wrong? Or do we need the TransactionLog object back (leaving out the quote properties since they are redundant to the orderbook)?
Reply | Threaded
Open this post in threaded view
|

RE: Need clear explanation of market-related data types

grampajohn
Administrator
Daniel Schnurr wrote
Since the MarketTransaction is associated with one broker it represents the effects of a trade for one party that is involved in this trade (=single broker). Therefore I saw the main purpose in reporting market transactions for a single broker to the accounting service.
That's correct.
Daniel Schnurr wrote
The TransactionLog was intented to express the overall quantity traded in a clearing plus the price. (The seller/buyer property would be used just in case of a cda where a trade is executed always between two parties). Therefore the main purpose was to publish trade information to the public.

So how do we publish trade information to the public in the new model? Is my understanding of MarketTransaction wrong? Or do we need the TransactionLog object back (leaving out the quote properties since they are redundant to the orderbook)?
I don't understand why we or the brokers would be interested in the individual-trade information. What decision process would a broker use that would be affected knowing the identity of the other side of a trade? Clearly, the TransactionLog is only relevant to a CDA where bids and asks are matched individually, and even then it's hard to see how it would be relevant in our simulation. What information does a TransactionLog contain that we need and do not already have in a MarketTransaction, which is exactly the information needed to update individual broker accounts?

In the interest of agility, I would say we don't need it now, so let's wait until we do and then decide on the best way to acquire and use such information.

Does this help?

John
Reply | Threaded
Open this post in threaded view
|

RE: Need clear explanation of market-related data types

chris.flath
Daniel Schnurr wrote
The TransactionLog was intented to express the overall quantity traded in a clearing plus the price. (The seller/buyer property would be used just in case of a cda where a trade is executed always between two parties). Therefore the main purpose was to publish trade information to the public.
grampajohn wrote
I don't understand why we or the brokers would be interested in the individual-trade information. What decision process would a broker use that would be affected knowing the identity of the other side of a trade?
I understood Daniel's idea of TransactionLog as a public information on traded volume and the last clearing price of a time slot. And this seems to be very relevant to all brokers - even those who did not participate in trading. Also the aggregate trade volume may be important information.
Reply | Threaded
Open this post in threaded view
|

RE: Need clear explanation of market-related data types

grampajohn
Administrator
chris.flath wrote
I understood Daniel's idea of TransactionLog as a public information on traded volume and the last clearing price of a time slot. And this seems to be very relevant to all brokers - even those who did not participate in trading. Also the aggregate trade volume may be important information.
OK, now I see the point. But I thought we decided to put that information in the orderbook. I know that in a standard CDA the orderbook is just the uncleared quotes, but if we add the cleared price(s) and volume then it aggregates all the information that would otherwise be in a potentially large number of individual TransactionLog instances. The difference could be significant in terms of overhead, but it also means that the orderbook could not be flat any longer.

I have always thought that the denormalized orderbook design was weak; perhaps this is the time to make the orderbook simply a composite of cleared trades and uncleared quotes. I would not call any of them "TransactionLog" because that name never clearly communicated its purpose - that's probably why I did not understand it and got rid of it.

So perhaps we need a type that can represent a price, a volume, and a cleared flag, a collection of which would be the Orderbook. What would we call that? MarketOrder? Is there need for identities of traders in this case?

Thanks for raising and clarifying this issue.

John
Reply | Threaded
Open this post in threaded view
|

RE: Need clear explanation of market-related data types

Daniel Schnurr
I have two very strong concerns about merging the orderbook and the reporting of trades:

a) In terms of semantics and practical use: the orderbook is explicitly understood as a collection of unmatched bids and asks. If an order is matched, it is thrown out of the orderbook. I talked to the finance people here at the chair in Karlsruhe about this issue and they underlined this as the common undertanding.

b) Ease of implementation: at the moment I don't see major advantages of a more complex element that merges orderbook and trade reporting functionality? But it would require a redesign of a domain class and the according service code.
On the other hand we already have an implementation that fulfills the basic requirements by separating the two functionalities: reporting of unmatched bids and reporting of public trade information.

Therefore my proposition would be to (re-)introduce a renamed version of the TransactionLog object that leaves out the quote information (because this is really redundant to the orderbook) and that only serves the purpose of reporting public trade information (price and volume). Since the code is already available I think this is the quickest way to implement the first version as long as there is no significant downside of this approach?! We could name it ClearingLog, TradeLog?

Thoughts?

Daniel
Reply | Threaded
Open this post in threaded view
|

RE: Need clear explanation of market-related data types

grampajohn
Administrator
Daniel Schnurr wrote
a) In terms of semantics and practical use: the orderbook is explicitly understood as a collection of unmatched bids and asks. If an order is matched, it is thrown out of the orderbook. I talked to the finance people here at the chair in Karlsruhe about this issue and they underlined this as the common undertanding.
I am aware of that. I was indeed overloading the term.
Daniel Schnurr wrote
b) Ease of implementation: at the moment I don't see major advantages of a more complex element that merges orderbook and trade reporting functionality? But it would require a redesign of a domain class and the according service code.
On the other hand we already have an implementation that fulfills the basic requirements by separating the two functionalities: reporting of unmatched bids and reporting of public trade information.
Yes, and if there are 20 trades executed in a timeslot, in a simulation with 10 brokers, the original design would produce 200 individual messages per timeslot just to update public trade information. So what I want to see is consolidation.
Daniel Schnurr wrote
Therefore my proposition would be to (re-)introduce a renamed version of the TransactionLog object that leaves out the quote information (because this is really redundant to the orderbook) and that only serves the purpose of reporting public trade information (price and volume). Since the code is already available I think this is the quickest way to implement the first version as long as there is no significant downside of this approach?! We could name it ClearingLog, TradeLog?
I would consolidate all cleared trades for power in a given timeslot, that occur within a single timeslot, into a single message. As you say, each individual trade is represented by just two numbers.

I don't much like the term "Log" for this, because it has a different meaning for most people, specifically a record over time. That's not what these are. I would choose a name like ClearedTrades.

Does this help?

John
Reply | Threaded
Open this post in threaded view
|

RE: Need clear explanation of market-related data types

Daniel Schnurr
grampajohn wrote
Yes, and if there are 20 trades executed in a timeslot, in a simulation with 10 brokers, the original design would produce 200 individual messages per timeslot just to update public trade information. So what I want to see is consolidation.
This is true for the cda market. In a periodic clearing we would have the number of tradeable timeslots (*#products) per clearing (that is once a timeslot).

grampajohn wrote
I would consolidate all cleared trades for power in a given timeslot, that occur within a single timeslot, into a single message. As you say, each individual trade is represented by just two numbers.

I don't much like the term "Log" for this, because it has a different meaning for most people, specifically a record over time. That's not what these are. I would choose a name like ClearedTrades.
So what about a "ClearedTradeList" that is returned after each clearing and that is a collection of "ClearedTrade" objects that consist of properties: timeslot, product, executionPrice, executionVolume ?
Reply | Threaded
Open this post in threaded view
|

RE: Need clear explanation of market-related data types

grampajohn
Administrator
Daniel Schnurr wrote
So what about a "ClearedTradeList" that is returned after each clearing and that is a collection of "ClearedTrade" objects that consist of properties: timeslot, product, executionPrice, executionVolume ?
I like this. Let's do it.

John
Reply | Threaded
Open this post in threaded view
|

RE: Need clear explanation of market-related data types

Daniel Schnurr
Great! I implemented the ClearedTrade domain class and requested a pull to the common-plugin.

To go further into the details:
How do we process these public information (clearedTradeList & Orderbook) in the server after the market has generated them? Does the auctioneer plugin call a specific method (e.g. BrokerProxy?) or does it simply save these objects into the database and another entity is responsible for reading and sending?

Concerning the clearedTrade instances: should the ClearedTradeList be an own domain class (properties timeslot (stating the time of clearing), list/set<ClearedTrade>) or will we use the list just for passing around the ClearedTrade instances in an aggreagted form but save them only per instance?

Thank's for your help
Reply | Threaded
Open this post in threaded view
|

RE: Need clear explanation of market-related data types

grampajohn
Administrator
Daniel Schnurr wrote
Great! I implemented the ClearedTrade domain class and requested a pull to the common-plugin.
Looks good. I have processed the pull request.
Daniel Schnurr wrote
To go further into the details:
How do we process these public information (clearedTradeList & Orderbook) in the server after the market has generated them? Does the auctioneer plugin call a specific method (e.g. BrokerProxy?) or does it simply save these objects into the database and another entity is responsible for reading and sending?
I think the right way to do this is to call brokerProxyService.broadcastMessage(msg).
Daniel Schnurr wrote
Concerning the clearedTrade instances: should the ClearedTradeList be an own domain class (properties timeslot (stating the time of clearing), list/set<ClearedTrade>) or will we use the list just for passing around the ClearedTrade instances in an aggreagted form but save them only per instance?
I think it's hardly worth making a domain object for holding a list of other domain objects, but certainly the list can be passed to the brokerProxyService for broadcast as a single message.

The next question is whether these object even belong in the database, or whether they are simply a way to publicize market information to brokers. The reason is that all the information in these objects is presumably already contained in the database in the form of MarketTransaction instances. We cannot broadcast those to brokers, but we can certainly query for them in a game database. Does this make sense?

Thanks.

John
Reply | Threaded
Open this post in threaded view
|

RE: Need clear explanation of market-related data types

grampajohn
Administrator
In reply to this post by Daniel Schnurr
One more question, now that I'm working on the serialization problem:

Are we going to update OrderBook to be a collection of price-quantity-bid/ask instances, or are we going to leave that horrible denormalized monstrosity in place? There's a lot of code required to build and use it correctly that could go away. Does anyone have an objection to a ticket asking for that to be fixed?

In the meantime, I won't try to serialize the current OrderBook definition - I can hardly stand to look at it. If we are going to stick with it, someone else will have to make it serializable.

Thanks.

John
12