Hi Ben, Thanks for the feedback. I will make the changes to the patch and probably upload an updated version today.
With regards to the approach, here's what I had in mind. I was thinking of delivering the ConfigService in two phases, with the first phase offering very basic functionality and a basic UI. This case doesn't deal with the case of multiple clients, multiple DBs, addition and deletion of endpoints, etc. For this phase, I definitely agree with you that only three operations would probably be required for this ticket (I was going for the 1st approach you mentioned). I implemented the others thinking that we'd probably need them for the UI - setBSToOPS, setClientToOPS would probably be used when the user selects the services from the front-end. GetServiceLocations, getClientToBSConnections, getBSToOPSConnections - these could also be useful when populating drop-down lists for the UI. But like you said, this may be jumping the gun for this ticket. I think that the second phase will give us the opportunity to discuss what additional features we want this config service to offer - this will probably include the case of multiple clients, multiple DBs, and possible changes to the structure of the DB. For these issues, we will probably need to use the other operations setActiveDB, getDBConfig. Also, in this phase we may want to consider the idea of having the UI take care of addition of new endpoints and new services. The reason I thought of tabling these issues to Phase II is that I think we should get a configService up and running before we deal with additional complexity. These are just my thoughts on this service so let me know what you think. I am also in the process of documenting a specification for this service, which may clarify some ideas mentioned here. Thanks, Avantika -----Original Message----- From: Ben Dewey [mailto:[email protected]] Sent: Friday, June 12, 2009 2:20 PM To: '[email protected]' Subject: RE: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service Avantika, Great start, Here is a list of some comments. - The Config Configuration Settings should really only include DB connString/user/password - Same for the ConfigConsole App.config - don't include your .sou files in the patches (they fail anyways) - The IDAL, DALFac, DALSql Config.cs and IConfig.cs files were added to the csproj files, but not included in the patch. - Can you describe the use cases for the operations you've setup? I think there still some unnecessary operations in yours. I can think of two different approaches both have only 3 operations. 1. (how PHP does it) Get your own config before any operation, this includes your database info and your next parties endpoint info (getconfig would return db info+bs address) - in this scenario all we need is GetClientConfig, GetBsConfig, GetOpsConfig // ClientConfigResponse GetClientConfig(ClientConfigRequest client) // BsConfigResponse GetBsConfig(BsConfigRequest client) // OpsConfigResponse GetOpsConfig(OpsConfigRequest client) 2. Get the active endpoints or database depending on what you need - in this scenario you'd have GetActiveDb, GetBsForClient, GetOpsForBs // DbConfigResponse GetActiveDb() // EndpointConfigResponse GetBsForClient(string client) // EndpointConfigResponse GetOpsForBs(string bs) To me it comes down to the return type objects, in scenario 1, we need custom inputs/outputs for everything. In scenario 2 we could use common strings, DbConfig, and EndpointConfig objects. Now, this is really the basic level and we need to try to think forward a bit to what we might have with the full new UI. For this ticket I would stick to something along these lines. I'd like to hear your thoughts and any other Use Cases you are planning for. -Ben -----Original Message----- From: Avantika Agrawal (JIRA) [mailto:[email protected]] Sent: Friday, June 12, 2009 3:29 PM To: [email protected] Subject: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service [ https://issues.apache.org/jira/browse/STONEHENGE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avantika Agrawal updated STONEHENGE-66: --------------------------------------- Attachment: Stonehenge-66.patch Here's what I have so far. You will find a new folder called Config_Service which hs the same structure as the OrderProcessor_Service - it should have a ConfigServiceSolution Also, there are some addtions made to the common folder - an IConfig interface and its implementation. I am sticking with the format of the php. Ben, you may find that I changed your contract very slightly, but this is in line with the php format so I don't think it should be an issue. I have left comments in areas which still need work. Moreover, I have not implemented setActiveDB, getDBConfig, and other methos relating to DB configuration yet - I think we should come to those later, once we have this service up and running. This service builds successfully but it is not running. I am getting a few errors. Will update this when those are fixed, but for now, you guys can take a look at what I've done so far and send me any feedback you may have. > Create a .NET Config Service > ---------------------------- > > Key: STONEHENGE-66 > URL: https://issues.apache.org/jira/browse/STONEHENGE-66 > Project: Stonehenge > Issue Type: New Feature > Reporter: Avantika Agrawal > Priority: Minor > Attachments: Stonehenge-66.patch > > > Implement Ben's ConfigContract to create a configuration service attached to > the .NET Client -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
