If WCF Service side and Client side config is different?!

本文详细探讨了Windows Communication Foundation (WCF)服务中客户端和服务端配置文件的一致性问题。文章通过实例说明如何正确配置基本HTTP绑定,并强调了在特定场景下如何调整超时设置以确保数据传输顺畅。

from stackoverflow 

http://stackoverflow.com/questions/4879310/when-setting-up-a-wcf-client-and-server-how-synchronized-does-the-config-files

最近配置wcf服务,一直有个疑问,一直我们配置wcf服务端跟client端总是一致的,但是如果我们配置的不一样呢?在stackoverflow找到以下答案。其实这个没有说一定那边起作用,比如client的sendtimeout对应的是service端的receivetimeout,而且在client端有些配置是没有用的。这个还得细细琢磨。我擦。。。

In order to address your request in your last comment to my previous answer, I tried to come up with my approach to how I would create (and modify) server- and client-side config's for any given service. This is based on both theory I read (books, blogs), things I've learned in Juval Lowy's WCF Master Class, and quite a bit of practical experience with several large service implementation projects - this isn't available in one single place, on the web or in a book.... so here it goes:

I would start basically from scratch. Think about your service first:

  • what address does your service live at?
  • what binding(s) do you want to support?

Simplest scenario: single service, single endpoint, basicHttpBinding, all defaults

Service config:

<system.serviceModel>
   <services>
      <service name="YourNamespace.YourServiceClass"> <endpoint name="Default" address="http://YourServer/SomeVirtualDirectory/YourService.svc" binding="basicHttpBinding" contract="YourNamespace.IYourServiceContract" /> </service> </services> </system.serviceModel>

Corresponding client config:

<system.serviceModel>
   <client name="Default"> <endpoint name="Default" address="http://YourServer/SomeVirtualDirectory/YourService.svc" binding="basicHttpBinding" contract="YourClientProxyNamespace.IYourServiceContract" /> </client> </system.serviceModel>

Then only ever change something if you really must! And most of all: NEVER EVER let Visual Studio (Add Service Reference) or svcutil.exe screw up your config! Protect it like the apple of your eye!

Then: if e.g. your data transfer takes more time than the default timeout of 1 minute allows, change that one single setting on both the service side and the client side. Do this by defining a custom binding configuration and referencing that from your endpoints - but change only that - not more!Leave everything else as is, with default values. Don't ever change anything unless you absolutely must (and know what you're doing, and why you're doing it).

Mind you: the sendTimeout on the client (time allowed until the whole message has been sent) will correspond to the receiveTimeout on the server - the time allowed for the whole message to come in (see this excellent blog post and this MSDN forum thread for more information)

Service config:

 <system.serviceModel>
    <bindings> <basicHttpBinding> <binding name="ExtendedTimeout" receiveTimeout="00:05:00" /> </basicHttpBinding> </bindings> <services> <service name="YourNamespace.YourServiceClass"> <endpoint name="Default" address="http://YourServer/SomeVirtualDirectory/YourService.svc" binding="basicHttpBinding" bindingConfiguration="ExtendedTimeout" contract="YourNamespace.IYourServiceContract" /> </service> </services> </system.serviceModel>

Corresponding client config:

<system.serviceModel>
   <bindings>
      <basicHttpBinding> <binding name="ExtendedTimeout" sendTimeout="00:05:00" /> </basicHttpBinding> </bindings> <client name="Default"> <endpoint name="Default" address="http://YourServer/SomeVirtualDirectory/YourService.svc" binding="basicHttpBinding" bindingConfiguration="ExtendedTimeout" contract="YourClientProxyNamespace.IYourServiceContract" /> </client> </system.serviceModel>

As you need other changes, like multiple endpoints on the service side, or local settings like bypassProxyOnLocal - adapt your config, do it carefully, step by step, manually, and consider your config an extremely essential part of your whole service - take care of it, put it in version control etc.

转载于:https://www.cnblogs.com/kklldog/p/5036627.html

代码转载自:https://pan.quark.cn/s/7f503284aed9 Hibernate的核心组件总数达到五个,具体包括:Session、SessionFactory、Transaction、Query以及Configuration。 这五个核心组件在各类开发项目中都具有普遍的应用性。 借助这些组件,不仅可以高效地进行持久化对象的读取与存储,还能够实现事务管理功能。 接下来将通过图形化的方式,逐一阐述这五个核心组件的具体细节。 依据所提供的文件内容,可以总结出以下几个关键知识点:### 1. SSH框架详细架构图尽管标题提及“SSH框架详细架构图”,但在描述部分并未直接呈现关于SSH的详细内容,而是转向介绍了Hibernate的核心接口。 然而,在此我们可以简要概述SSH框架(涵盖Spring、Struts、Hibernate)的核心理念及其在Java开发中的具体作用。 #### Spring框架- **定义**:Spring框架是一个开源架构,其设计目标在于简化企业级应用的开发流程。 - **特点**: - **分层结构**:该框架允许开发者根据实际需求选择性地采纳部分组件,而非强制使用全部功能。 - **可复用性**:Spring框架支持创建可在不同开发环境中重复利用的业务逻辑和数据访问组件。 - **核心构成**: - **核心容器**:该部分包含了Spring框架的基础功能,其核心在于`BeanFactory`,该组件通过工厂模式运作,并借助控制反转(IoC)理念,将配置和依赖管理与具体的应用代码进行有效分离。 - **Spring上下文**:提供一个配置文件,其中整合了诸如JNDI、EJB、邮件服务、国际化支持等企业级服务。 - **Spring AO...
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值