收到消息?

在网上下订单时,网站在交易过程中被锁定并不罕见——这都是网络体验的一部分,客户知道要打电话给客户服务代表,看看订单是否通过。但是把人为因素从等式中去掉,比如在Web服务事务中。谁百分之百确定他们的信息是通过的,没有重复的,而且顺序正确?毕竟,您依靠两个应用程序相互通信来完成订单,使用的是XML、HTTP和SOAP等标准。

“HTTP是一种很好的轻量级机制,可以发送HTML或几乎任何类型的格式。犹他州米德维尔伯顿集团的分析师安妮·托马斯·马内斯说:“问题是,这一信息不能保证能够传达出去。”它提供了92%到96%的可靠性,但是如果您需要99.9%的可靠性,或者如果消息没有到达那里,至少需要通知,HTTP不会为您这样做。”

尽管分析师认为可靠性并不是阻碍Web服务采用的唯一问题,但它无疑给在这样一个平台上构建任何关键任务的想法蒙上了一层不确定性的阴影。

一些用户,如俄克拉何马州塔尔萨市Dollar Thrifty Automotive Group Inc.互联网研发总监彼得·奥斯本(Peter Osbourne)说,他们在TCP/IP和HTTP方面做得很好。”我们广泛使用网络服务(用于基于网络的汽车预订),但没有遇到消息可靠性问题,”他说。Dollar有检测消息瓶颈的机制,但Osbourne说公司没有丢失任何消息。

ZapThink LLC的分析师Ron Schmeltzer说,在需要更高可靠性的公司,这是一个“用砍刀在丛林中砍杀”的问题。这些用户将可靠性构建到应用程序的业务逻辑中,或者使用成熟的消息传递平台,如IBM的MQSeries。

一次是不够的

ShopNBC的首席技术官兼IT开发副总裁史蒂夫·克雷格(Steve Craig)表示,ShopNBC是一家对Web服务可靠性进行了大量思考的公司,该公司向5600万户家庭广播。

ShopNBC依靠网络服务通过网络完成客户订单,并从其参与的商户处接收实时价格更新。因为这是一项关键任务,Craig和他的团队构建了一个三层系统,支持三种类型的Web服务消息传递:实时、近实时和周期性。每一层加强其他层以创建消息冗余,以防第一条消息无法通过。

克雷格解释说:“如果一个实时事务被触发而被错过,那么下游就会有另一个工作来满足这一需求。”。例如,一个商家系统向ShopNBC的网络服务系统发送一条消息,要求对正在电视上播放的产品降价10%。如果没有收到实时消息,发送到另一台服务器的另一条消息最终会降低价格——可能不是在产品播放时,而是在下一次数据库同步时。

另一个例子是客户通过网络订购产品。Web服务器尝试与后端服务器实时提交订单,但如果服务器没有响应,订单将发送到单独的服务器,以便稍后进行同步。

构建,不添加

正如ShopNBC所证明的,必须从一开始就考虑可靠性。”旧金山Black Pearl Inc.工程副总裁唐里夫斯(Don Reeves)说:“在事后,你永远不会给某个东西增加可靠性——这不是你可以简单地在应用程序上添加的东西。”。

Black Pearl的B4平台使用Web服务从不同来源收集数据,以提供实时客户概要和数据分析。例如,它向金融服务代理发送高优先级潜在客户的每日列表,以及可能引起特定客户兴趣的产品的实时警报。该系统需要从各种来源收集数据,如遗留客户数据库、营销活动系统和股票价格的实时数据源。

Reeves估计,组成B4的代码中有一半是针对功能的,另一半是针对错误检查的。”每当你连接到一个数据源,你必须假设它会失败,并有一个计划的反应,“他说。

另一种方法是使用可靠的传输协议,例如消息队列(MQ)服务,而不是使用HTTP来传输简单对象访问协议(SOAP)消息。主要的MQ服务是IBM的webspheremq,它充当一个中介,通过在本地存储消息直到接收到传递确认,来保证传递。

“您可以通过SMTP、FTP或MQ系统发送。Web服务完全独立于底层协议,”Manes说。问题是,MQ系统是专有的——IBM的WebSphere MQ不与Sonic Software Corp.的MQ系统进行通信。如果您只是在内部使用Web服务,那么问题就不那么严重了,但即便如此,这也是一个昂贵的提议。根据Manes的说法,MQ部署可以达到七位数。

使用标题

Schmeltzer说,为了摆脱对专有协议的依赖,公司必须将规范编码到他们的SOAP头中——例如,如果在300毫秒内没有收到回执,则让系统尝试重新发送消息。

如今,Schmeltzer指出,个别公司需要自己编写这种代码,这可能非常困难。然而,这种编码最终将被构建到诸如WS-Reliability和WS-ReliableMessaging之类的标准中。

华盛顿州Kirkland的Summit Strategies Inc.副总裁德怀特·戴维斯(Dwight Davis)说:“在这个行业的混乱中,缺乏可靠的消息传递规范是阻碍人们实现Web服务的主要原因。”他说:“在众多因素中,有很多包袱在起作用,包括技术的相对新颖性,以及关注日常危机而不是长期架构变化的必要性。同样,在关键任务Web服务应用程序进入主流之前,可靠的消息传递必须变得不那么复杂和昂贵。

布兰德尔是密歇根州大急流城的一名自由撰稿人。请与她联系玛丽·布兰德尔@康卡斯特.net.

丹斯克银行A/S构建面向服务体系结构的开创性工作已经非常先进,它从其大型机和应用服务器上公开了1000多个服务。但这家总部位于哥本哈根的银行发现自己陷入了令人沮丧的困境。

“我们找不到它们,”该公司首席架构师克劳斯·托普说。

这个问题威胁到了面向服务架构(SOA)的一个主要好处——重用。因此,Danske着手修改其服务概念,完善其存储库,并建立一个治理过程来实施最佳实践。

结果是140个服务的集合更易于管理。

深入研究几位SOA先驱可以发现,Danske银行采取的步骤是公司重用代码、以更快的速度和效率构建应用程序并最终节省资金的关键。

但这并不容易,实施顺序也很重要。例如,sunmicrosystems公司(sunmicrosystems)建立了一个注册表,并成立了一个架构审查委员会。但是IT部门现在正回过头来仔细检查Sun的80到100个Web服务。

Sun的IT主管Karen Casella建议,一家开始走SOA之路的公司应该首先查看其业务需求,并确定需要哪些Web服务。”她说:“我们学的很辛苦。”在我们完全了解我们需要做什么之前,我们已经建立了一些基础设施。”

服务

公司需要弄清楚哪些业务流程可以转化为服务,仔细设计和定义服务,并将其与组件区分开来。