Cool. Actually in the dotnet version all the endpoints are in the *.exe.config and we only change the active one by editing the file... You will find a stub for "WSO2" endpoints. Since there is already a config service I believe dotnet side should adapt to what is there rather than rebuild. However I think the client side of the config service should be by machines that do not have PHP. I am not sure this is the current case. I may be wrong. I need to try it from one of the dotnet machines after I get the WSF/PHP machine all clean and happy.
The complicating configuration in the dotnet version is the "inprocess" mode. In this mode the Web app runs the BSL and ops in the WebApp Process. This complicates the code but the original author (Greg) felt strongly that I should leave it in. However these are dotnet only scenarios. Taking it out is a lot of work that does not need to be done. We need to know it is there. Actual minimum work would be to add the dotnet endpoints to the config service DB for the PHP machines and hard code the endpoint in the *.exe.config files. Of course this is not optimum. A single control point is highly desirable. Thanks! drew -----Original Message----- From: Selvaratnam Uthaiyashankar [mailto:[email protected]] Sent: Wednesday, March 18, 2009 9:31 PM To: [email protected] Subject: Re: php config service. Hi Drew, comments inline... On Thu, Mar 19, 2009 at 9:49 AM, Drew Baird (Volt) <[email protected]>wrote: > Well it looks like this config system is compatible if I build the hooks > into dotnet. It looks simple enough. > I might have to modify the dotnet .configs and get a mechanism to refresh > them. doable. Let me think on it. Right now we change the endpoint in the > *.exe.config or the web.config and restart the app. > > Correct me if I am wrong but the table is a simple "key and endpoint". The > php page serves up a list of possible endpoints. User beware :) But I like > clean and simple. Let me explain. There are 3 tables, "Services", "ClientToBS" and "BSToOPS". "Services" table keeps a key and end point address. "ClientToBS" keeps "Client key" and which "BS Key" connected to that client. BSToOPS gives the connection from BS to OPS. This can change at the runtime. So for every request clietns and BS send a request (including their keys) to the config service and config service responds with the endpoint to which client / BS should connect. (Note, this is not a perfect soultion, but allowed us to dynamically change the endpoints when doing demos :) ). Keys we are having are PHP_CLIENT, RUBY_CLIENT, PHP_BS, JAVA_BS, JAVA_OPS, etc. . There will be a single configuration service and all other clients + services will have endpoint for the config service. > > > Right now I have a 5 machine scenarios cooking in the lab. I guess each > system could have a config or each web server could have a config. However a > remote machine must 'know' where the service is. > > I saw the thread Chintana started. WE can continue it here or circle back > and pick up the old thread?. I think we can continue here. Regards, Shankar > > > Thanks for responding! > Drew > > > -----Original Message----- > From: Selvaratnam Uthaiyashankar [mailto:[email protected]] > Sent: Wednesday, March 18, 2009 9:01 PM > To: [email protected] > Subject: Re: php config service. > > Hi Drew, > > On Wed, Mar 18, 2009 at 9:56 PM, Drew Baird (Volt) > <[email protected]>wrote: > > > It appears the PHP config service uses the DB. I am using the dotnet > > StockTrader DB I already have working. I guess I need to 'seed' the > tables > > for the PHP config service to get the PHP StockTrader working? Can > someone > > please confirmed this although it seems obvious... > > > Yes, that is correct. > > > > > > > > > This might be an interoperability issue with dotnet Stock Trader since > the > > version contributed does not use the config DB. > > > Yes, we have to find a common mechanism to configure the services. We had a > discussion to do it [1], but unfortunately haven't decided how to proceed. > It is a good oppertunity to find a common mechanism. > > Regards, > Shankar > > [1] > > http://www.mail-archive.com/[email protected]/msg00081.html > > > > > > > > Thanks! > > Drew > > > > > > > -- > S.Uthaiyashankar > Software Architect > WSO2 Inc. > http://wso2.com/ - "The Open Source SOA Company" > -- S.Uthaiyashankar Software Architect WSO2 Inc. http://wso2.com/ - "The Open Source SOA Company"
