Avantika I'm taking a look now, I got the PHP config service to accept the message by changing the contract to
[OperationContract(Action="GetClientConfig", Name="ClientConfigRequest")] ClientConfigResponse GetClientConfig(string Client); Notice that now, I'm passing a String for Client not a ClientConfigRequest object and suppling the name of ClientConfigRequest. >From what I can tell, this is because .NET Sends/receives messages as <action><object><paramater1 /><paramater2 /><paramaterN /></object></action> And PHP sends/receives messages without the action <object><paramater1 /><paramater2 /><paramaterN /></object> This new contract works because there is only one parameter, on the return type there are multiple parameters and I don't have an out-of-the-box solution. I'm working on an alternative, I'll keep you posted. -Ben Dewey -----Original Message----- From: Avantika Agrawal [mailto:[email protected]] Sent: Monday, July 20, 2009 4:41 PM To: [email protected] Subject: RE: Config Service interoperability I am still getting a FaultException - Operation Not Found. Perhaps it is not recognizing the BSConfigRequest? -----Original Message----- From: Ben Dewey [mailto:[email protected]] Sent: Thursday, July 16, 2009 6:24 PM To: [email protected] Subject: RE: Config Service interoperability Short answer is all calls to/from the config service will be called in code using the GetBSConfig, which (also in all cases) will send/recieve a SOAP message with an Action header of getBSConfig. Long answer is if the .NET Code was accessing the PHP code through code generated by the wsdl the it would use the lowercase getBSConfig. Since the .NET code is creating a proxy manually based on the IConfigService interface, which is attributed with the Action="getBSConfig" override, all calls to the IConfigService GetBSConfig will be routed to a SOAP Message with an action link of getBSConfig. Hope that makes sense, -Ben Dewey ________________________________________ From: Avantika Agrawal [[email protected]] Sent: Thursday, July 16, 2009 4:41 PM To: [email protected] Subject: RE: Config Service interoperability But will this allow us to call the methods from the PHP Config Service interface named getBSConfig using GetBSConfig? Maybe I am misunderstanding you, but I don't think we can call their getBSConfig method without changing our code (even the contract). As far as I can see, we would have to make our method calls "getBSConfig"?? Let me know - I am in no way an expert on contracts and other WCF stuff. -----Original Message----- From: Ben Dewey [mailto:[email protected]] Sent: Tuesday, July 14, 2009 2:38 PM To: '[email protected]' Subject: RE: Config Service interoperability > Ben, if I add the action = getBSConfig - this means that any program calling > this needs to use getBSConfig rather than GetBSConfig? Even those within > .NET?? ASFAIK, the .NET calls will use proxies generated from the interface which will use the GetBSConfig (i.e. no .NET code changes). In all cases the actual web service call will contain an action attribute of getBSConfig. -Ben -----Original Message----- From: Avantika Agrawal [mailto:[email protected]] Sent: Tuesday, July 14, 2009 2:28 PM To: [email protected] Subject: RE: Config Service interoperability I actually had RUBY and SPRING in the database and then removed them because they weren't being used. I can easily modify the script to insert them. Apart from the naming inconsistencies, there is an additional attribute for BSConfigResponse and OPSConfigResponse in the DataContract of the .NET - BSName and OPSName. Is this something that the PHP folks wish to use? I added that while I was cleaning up the Utility.cs class and I think it is a useful attribute. Ben, if I add the action = getBSConfig - this means that any program calling this needs to use getBSConfig rather than GetBSConfig? Even those within .NET?? -----Original Message----- From: Ben Dewey [mailto:[email protected]] Sent: Tuesday, July 14, 2009 6:10 AM To: [email protected] Subject: RE: Config Service interoperability ASFAIK, the RUBY_BS and OPS were created by WSO2 that's why they're supported by PHP/WSAS. Unfortunately Ruby is still in contrib and hasn't had the traction to make it into the trunk. That being said, I don't think that the RUBY (or SPRING for that matter) should be in the trunk. Additionally, any Ruby developers out there who want to evaluate the validity of the Ruby implementation in contrib, please do. Also anyone on the list who knows any Ruby developers who may be interested please encourage them to join the list and speak up. -Ben Dewey ________________________________________ From: Ming Jin [[email protected]] Sent: Tuesday, July 14, 2009 5:23 AM To: [email protected] Subject: Re: Config Service interoperability Thanks, Ben, that would be great. There is one more thing, it's about the available options for client/bs/ops in config_service. Now .NET and PHP support different options. For example, .NET supports JAVA_CLIENT/DOTNET_CLIENT/PHP_CLIENT, while php supports JAVA_CLIENT/DOTNET_CLIENT/PHP_CLIENT/RUBY_CLIENT. In addition, same things happen in the options of BS and OPS. Can we make them consistent in that aspect? On Tue, Jul 14, 2009 at 11:16 AM, Ben Dewey <[email protected]> wrote: > Avantika, > > Let's get these discrepancies addressed and change the contract names > so the Metro team can model their config contract after the .NET contract. > > You should be able to change the method name to match PHP by adding > the action parameter to the OperationContract like this. > > [OperationContract] > BSConfigResponse GetBSConfig(BSConfigRequest bs); > > To > > [OperationContract(Action="getBSConfig")] > BSConfigResponse GetBSConfig(BSConfigRequest bs); > > > -Ben Dewey > > -----Original Message----- > From: Avantika Agrawal [mailto:[email protected]] > Sent: Monday, July 13, 2009 3:29 PM > To: [email protected] > Subject: RE: Config Service interoperability > > I just tested this and it managed to make a connection to the > configuration service but was unable to process the GetBSConfig > method. I think that's because our contract specifies this as > GetBSConfig and theirs is getBSConfig. This can be changed pretty > easily. But the contracts are a little different so all the > inconsistencies should be ironed out. Is this something you're interested in? > > ________________________________________ > From: Ben Dewey [[email protected]] > Sent: Monday, July 13, 2009 10:45 AM > To: '[email protected]' > Subject: RE: Config Service interoperability > > You should be able to just update the config service endpoint > configuration address to use > > http://localhost:8080/php_stocktrader/config_service/config_svc.php > > > > -----Original Message----- > From: Avantika Agrawal [mailto:[email protected]] > Sent: Monday, July 13, 2009 1:35 PM > To: [email protected] > Subject: RE: Config Service interoperability > > I have not actually tried this. I am interested in testing that but > I'm not sure how to go about it? > > -----Original Message----- > From: Ben Dewey [mailto:[email protected]] > Sent: Friday, July 10, 2009 8:51 AM > To: '[email protected]' > Subject: Config Service interoperability > > Avantika, > > Although this wasn't the goal, have you by any chance tested > interoperability between the .NET and PHP config services? Does that work? > > -Ben Dewey > -- Ming Jin Consultant Thoughtworks, Inc Mobile: +86 135-2125-6300 Email: [email protected] MSN: [email protected] Blog: http://blogjava.net/mingj
