I've attached my comments inline below. Ben
-----Original Message----- From: Avantika Agrawal [mailto:[email protected]] Sent: Wednesday, June 10, 2009 1:21 PM To: [email protected] Subject: some questions regarding the configuration service Hi everyone, I had a couple of issues regarding the implementation of Ben's configuration contract so let me know what you guys think: - I am developing the ConfigService as a console application for the sake of consistency with the BS and OPS. I guess we can change all of them to web services together. > I think the ConfigService should be hosted by TradeWeb as a .svc. I would > like to limit the amount of config needed for config. But, I'm fine as long > as there are plans to change it later. I am using the Order Processing Service as a guide for the structure of the ConfigService and as such the solution consists of a ConsoleHost, Contract, Implementation, ConfigurationService and existing projects of StockTraderDALSQLServer, StockTraderDALFactory and StockTraderIDAL > This seems fine - I have created an interface IConfig in StockTraderIDAL which accesses the configuration tables (ClientToBs, BsToOps, Service) in the database. - do you guys think this is the right way to go? > Can you attach the interface as a comment on STONEHENGE-66? - I have some questions about the contract IConfigService - right now I'm working on getting the main methods implemented (i.e. ClientConfigRequest, BSConfigRequest and OPSConfigRequest) However ClientConfigRequest takes a clientname as a parameter and returns an object of the type ClientConfigRequest which only has a string client as an attribute - is this the endpoint of the client? In this case does this method simply take the clientname and look it up In the service table and return the endpoint or that client? The reason for my confusion is that the PHP config_service has a ClientConfigRequest method which is meant to return the endpoint url of the business service that the client points to. > I personally think we should try to have a consistent contract. > Although, the PHP version has a lot unused operations. - Some of the other methods in the contract are also confusing in terms of what they're meant to return. Is it okay if I change the contract a little bit or is that something we are leaving fixed for the sake of consistency with the PHP? > I'd like to defer to some of the PHP Devs on this one? > Should the new .net contract be optimized for our new config system, (ie > disregarding PHP compatability)? > That may cause additional changes to the PHP contract, when it comes time for > update the config tab. > > In particular we may need to change method parameters, and return types, or > add change properties on the return objects. > Also for the case of methods that aren't being used. > > Either way we go it would be helpful to append your proposed service contract > to STONEHENGE-66? Thanks, Avantika
