We've discussed this numerous times in the past and I have to agree with Kent that, although ideal, it's very unlikely that we'll have a single customBinding configuration that will work with all cases.
This is why the SERVICE names from the DB maps directly to a App.config setting [1] that in turn binds to a client endpoint[2]. Please note, although present, the address property of the client endpoint is not actually used and is replaced by the address of the SERVICE from the DB. That being said, there are improvements that can be made. First, I'm not sure what value the .NET wsHttp endpoint adds. It's currently only being used by .NET and IMHO, only adds unnecessary confusion. Second, the basic and all non-.NET OPSSEC clients are using the same configs; this could be consolidated to something like [3]. -Ben Dewey [1] <add key="DOTNET_OPS" value="OpsClient_DotNet_BasicHttpBinding" /> <add key="DOTNET_OPSSEC" value="OpsClient_DotNet_WsHttpBinding_MSec" /> <add key="PHP_OPS" value="OpsClient_PHP_BasicHttpBinding" /> <add key="PHP_OPSSEC" value="OpsClient_PHP_WsHttpBinding_MSec" /> <add key="JAVA_OPS" value="OpsClient_WSAS_BasicHttpBinding" /> <add key="JAVA_OPSSEC" value="OpsClient_WSAS_WsHttpBinding_MSec" /> [2] <endpoint address="http://localhost:8000/tradeorderprocessor/msec"; contract="Trade.OrderProcessorContract.IOrderProcessor" binding="wsHttpBinding" bindingConfiguration="OpsClient_WsHttpBinding_MSec" behaviorConfiguration="OpsClient_DotNet_CertificateBehavior" name="OpsClient_DotNet_WsHttpBinding_MSec"> <identity> <dns value="OPS.Com"/> </identity> </endpoint> [3] <add key="DOTNET_OPS" value="OpsClient_BasicHttpBinding" /> <add key="DOTNET_OPSSEC" value="OpsClient_DotNet_WsHttpBinding_MSec" /> <add key="PHP_OPS" value="OpsClient_BasicHttpBinding" /> <add key="PHP_OPSSEC" value="OpsClient_CustomBinding_MSec" /> <add key="JAVA_OPS" value="OpsClient_BasicHttpBinding" /> <add key="JAVA_OPSSEC" value="OpsClient_CustomBinding_MSec" /> -----Original Message----- From: Kent Brown [mailto:[email protected]] Sent: Friday, October 16, 2009 10:29 AM To: [email protected] Subject: RE: .Net new passive STS impl. I agree that's the way it "should" work if interop was perfect. My only concern is whether we will hit situations where special bindings are needed on one side or the other to get things to work. I think that would be a big change in the way the config service works and the way the .NET app uses it. Maybe Ben or others can weigh in on the implications before we change it. Kent -----Original Message----- From: Pablo Cibraro [mailto:[email protected]] Sent: Friday, October 16, 2009 4:57 AM To: [email protected] Subject: RE: .Net new passive STS impl. Yes, I totally agree that it should work that way. I'll be working on this today. Thanks Pablo. -----Original Message----- From: Chintana Wilamuna [mailto:[email protected]] Sent: Friday, October 16, 2009 6:50 AM To: [email protected] Subject: Re: .Net new passive STS impl. On Wed, Oct 14, 2009 at 9:49 PM, Pablo Cibraro <[email protected]> wrote: > Ok, I will take a look. I had some problems to build the WSAS implementation > the last time I tried some weeks ago, so I never tested our .NET > implementation with other implementations. Keeping the setup as DOTNET_CLIENT -> DOTNET_BS and by changing the DOTNET_BS endpoint in the database to point it to the WSAS_BS and changing the endpoint value in web.config sends the request to the WSAS_BS. So, it seems to be trader client in .Net is checking whether the business service is .Net, WSAS etc... and then invoking it. I think it's best if we can remove this tight coupling. Ideal scenario would be you get the endpoint from the database, you know that's where the business service resides and just call that service. Thoughts? Bye, -Chintana -- http://engwar.com/
