WCF中的Stream操作

WCF支持对Stream对象的操作,尤其对于传递size过大的消息而言,如要考虑传递消息的效率,WCF推荐通过Stream进行操作。

然而,WCF对于Stream操作规定了一些限制,在我们编写相关程序时,需要特别注意:
1、绑定的限制
如果需要使用Stream操作,可以使用的绑定只能是BasicHttpBinding,NetTcpBinding以及NetNamedPipeBinding。此外,在使用Stream操作时,不能使用Reliable Messaging。如果考虑到消息安全,则此方式是不可取的。

2、对Stream对象的限制
要作为服务操作所传递的消息对象,这样的对象必须是可序列化的。遗憾的是,FileStream类的定义却是不支持序列化的,我们能够使用的Stream对象,包括Stream,MemoryStream等。使用Stream类对象是大多数Stream操作的首选。

一个有趣的现象是FileStream与Stream类型的转换。例如在服务契约的操作中,有如下的实现:

public  Stream TransferDocument(Document document)
{
     FileStream stream 
=   new  FileStream
                             (document.LocalPath, FileMode.Open, FileAccess.Read);
    
return  stream;
}


注意,操作TransferDocument()的返回类型为Stream,而方法的实现中,返回的对象则为FileStream类型。由于Stream类是FileStream类的父类,这样的实现没有问题。

然而,在客户端调用该操作时,却不能将操作的返回值赋给FileStream类型的对象,如下所示:

FileStream stream  =  m_service.TransferDocument(doc);


此时获得的Stream对象则为null。因而,我们只能这样调用操作:

Stream stream  =  m_service.TransferDocument(doc);


但是,还有一个奇怪的问题是WCF并不支持Stream对象Length属性的序列化,也就是说,在客户端我们不能使用服务操作返回的Stream对象的Length属性。诸如stream.Length的调用会抛出NotSupportedException异常。

3、TransferMode的限制

若要使用Stream操作,必须修改绑定的TransferMode属性。该属性的默认值为Buffered。我们应该根据操作中Stream对象的参数类型,以决定TransferMode的值分别为Streamed、StreamedRequest或者StreamedResponse。

4、MaxReceivedMessageSize的限制

MaxReceivedMessageSize属性的默认值为64kb,如果传递的Stream对象一旦超过了MaxReceivedMessageSize属性的设置值,则客户端在操作该对象时,就会出现CommunicationException异常。因此,我们应根据实际需要设置MaxReceivedMessageSize的值。MaxReceivedMessageSize属性的取值范围为1-9223372036854775807(Int32.MaxValue)。如果设置值不在该范围之内,则无法通过编译。编程方式设置为:

binding.MaxReceivedMessageSize = 120000 ;


配置文件的设置方式为:

< binding …… maxReceivedMessageSize = " 120000 " />



5、操作参数的限制

WCF对包含了Stream对象的操作参数进行严格的限制,它只允许这样的操作只能包含一个Stream对象,这里所谓的一个Stream对象,是包含return对象,out和ref对象在内的。也就是说如下的操作定义都是错误的:

void  Transfer(Stream s1, Stream s2);
void  Transfer(Stream s1,  out  Stream s2);
void  Transfer(Stream s1,  ref  Stream s2);
Stream Transfer(Stream stream);


如果定义了这样的操作,则会出现运行时错误。

此外,由于传输的Stream对象较大,可能会消耗过长的时间,因而建议增大绑定的SendTimeout属性值。例如设置为10分钟。编程方式设置为:

binding.SendTimeout  =  TimeSpan.FromMinutes( 10 );


配置文件的设置方式为:

< binding …… sendTimeout = " 00:10:00 " />


注意,对绑定的相关设置必须要求服务端与客户端的配置一致。最佳实践是均通过配置文件进行设置。例如在我的应用程序中是这样设置的:

< basicHttpBinding >
        
< binding name = " DocumentExplorerServiceBinding "
                 sendTimeout
= " 00:10:00 "
                 transferMode
= " Streamed "
                 messageEncoding
= " Text "
                 textEncoding
= " utf-8 "
                 maxReceivedMessageSize
= " 9223372036854775807 " >           
        
</ binding >
</ basicHttpBinding >

   

 
"java.io.IOException: Stream closed"是一个常见的错误消息,它表示在处理输入或输出时出现了问题。在Java,输入和输出是用于读取和写入数据的工具。 通常情况下,抛出这个异常的原因是由于输入或输出操作之前已被关闭。当我们使用Java的IO类进行输入或输出操作时,我们需要按照一定的顺序正确关闭,以避免出现此错误。 在遇到这个错误消息时,我们可以检查以下几个方面: 1. 检查是否正确地打开和关闭了输入或输出。在使用完之后,我们应该使用`close()`方法来关闭。 例如,在读取文件时,我们应该使用以下代码片段: ```java try { FileInputStream file = new FileInputStream("myfile.txt"); // 读取文件的代码逻辑 } catch (IOException e) { e.printStackTrace(); } finally { try { if (file != null) { file.close(); // 关闭 } } catch (IOException e) { e.printStackTrace(); } } ``` 2. 检查代码是否存在多个线程尝试共享同一个。当多个线程同时对同一个进行操作时,可能会导致其一个线程关闭了,而其他线程尝试读取或写入数据时抛出"Stream closed"异常。确保在多线程环境正确同步的访问。 3. 检查对象是否被重复使用。有时我们可能会在多个地方使用相同的对象进行读写操作。如果在一次操作之后关闭了,在后续操作再次使用该对象将导致"Stream closed"异常。确保每次操作都使用一个新的对象。 总之,当遇到"java.io.IOException: Stream closed"异常时,我们应该仔细检查的打开和关闭过程,确保在正确的时间关闭,并避免多个线程或重复使用对象造成的问题。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值