当前位置: 首页 > 图文教程 > 网络编程 > ASP.NET > Java与.NET间进行Web Service交互的选择

ASP.NET
Script:WINDOWS Script 枚举运行中进程
使用Flex结合Webservice完成域名查询
VSTS Team System 总算装好了。
用于部署数据库的 数据库初始化工具 xzSQLDeploy Tools V1.0 (for SQLServer) f...
一个将阿拉伯数字转换成中文大写的最简单算法
SCRIPT:使用Windows Script 关闭和打开指定程序
Script:使用WINDOWS脚本访问WEB SERVICES
asp.net连接Access数据库
VB中IIS Application发布可能出现的问题
VB打包后的安装问题
Nhibernate的数据分页技术(续)
使用API函数复制文件,可显示进度。
VB打包技巧
VB.NET实现DirectSound9 (9) 实现示波器
VB.NET 实现DirectSound9 (10) 均衡器
[水晶报表部署系列之一]轻松搞定水晶报表9.2打包
DataGrid 中双向排序的一种办法
利用System.EventHandler来实现两个窗体间的事件调用
多线程应用程序中调用窗体的一点心得
Smart Client之旅一:用B/S方式运行Exe应用程序

ASP.NET 中的 Java与.NET间进行Web Service交互的选择


出处:互联网   整理: 软晨网(RuanChen.com)   发布: 2009-08-14   浏览: 115 ::
收藏到网摘: n/a

谈到.NET和Java之间的Web服务交互性时,通常的选择只有SOAP over HTTP,而根据.NET 3.0的相关规范,这仅有的一个选择也将会受到更多限制,.NET中提供的BasicHTTP将是唯一能直接与Java Web Servcies进行交互的方式。

最近,有两个新的选择出现了——WebSphere MQ(WMQ)和ActiveMQ传送器,它们可以用于创建Java和.NET之间的交互式Web Services。而且.NET的可靠消息系统已经得到了扩展,因此对于MSMQ来说,WMQ和Active MQ都可以作为.NET Web Services的可靠传递者。

WMQ解决方案基于IBM AlphaWorks中IBM WMQ for Windows Communication Foundation的定制通道(Custom Channel),它的最新版本已于3月14日发布。这一产品允许将WMQ作为定制通道用于Windows Communication Foundation(WCF)框架(已随.NET Framework 3提供)中,它与微软的内建通道工作方式相同。

消息都是经过格式化的,以满足WMQ v6.0的SOAP over JMS实现,让应用程序即可以和运行于WCF之上的服务进行通信,也能和运行在WebSphere SOAP over JMS服务基础之上的服务进行通信,包括WebSphere应用服务器和CICS。

目前的实现是以概念验证为主,是为了帮助更好地理解对这一领域产品的需求(也就是说它并不适合在产品环境中使用),如何产品化这一实现的计划还没有最终确定。

定制通道的构建是通过Windows Communication Foundation的可扩展框架提供的,这一可扩展框架允许集成和使用那些与微软提供的内建传送器类似的传送器。服务型应用只要通过配置就可以使用新的定制通道,只要客户端应用程序是通过像微软的Service Metadata utility Tool(Svcutil.exe)这样的标准工具生成的,它们就可以正常运行。服务的元数据描述可以被正在运行的服务直接发布(可以通过一个附加的HTTP端点来暴露)或者使用WSDL(Web Service Description Language)。

目前的实现版本支持核心的消息功能,它有如下限制:

对于一个服务实例,只有一个客户端可以使用双向通道的模式;

双向通道是对WebSphere MQ v6所提供的SOAP/JMS实现的一种扩展,它只能用于WCF服务与其客户端之间的通信;

仅支持核心的消息功能(如不支持像事务化和安全等高级特性)

运行在现存WMQ v6的SOAP/JMS环境中的SOAP/JMS服务仅能进行单向操作;

运行在CICS或WebSphere应用服务器的SOAP/JMS环境内的SOAP/JMS服务,不允许在一个单一合约中混合使用单向操作和请求/回复操作,而必须为每个通道形态分别创建独立的合约。

Active MQ解决方案基于Axis提供的JMS(由Java编写而成)和“插件式协议”特性(由.NET编写而成),因此,它并不是以真正的.NET定制通道方式包装的,这就需要更多的定制编程。

这两种解决方案都没有彻底的产品化,但它们却提供了一个很好实验基础,以选择合适的Web Services交互式传送器。