将Web服务用于电子交易的单点登录 来源: 时间:2002-08-26 16:54 作者:AMTeam.org 将Web服务用于电子交易的单点登录
Web 应用用户在使用 Web
站点时期望着无缝的集成和互操作性。然而驱动该站点的后端系统是各个服务器软件包的聚合物。本个案研究展示了怎样用 Web
服务将“电子客户关系管理”(electronic Customer Relationship
Management,eCRM)应用集成到现有电子交易市场应用,从而为用户提供单点登录的体验。 本个案研究展示了怎样用 Web 服务为用户提供无缝且 轻松的单点登录的体验。您将看到开发小组怎样用 Web 服务无缝地将 eCRM 应用集成到现有电子交易市场应用中。我展示了详细的示例,这些示例源自 Switchouse 将 Inclusion 协作消息传递软件集成到其 Web 站点所积累的经验。这篇文章还提出了几个在集成工程过程中所碰到的问题,我希望您能够避免。 减少在线消费者市场的开支 开办这个电子交易 Web 站点不久之后,Switchouse 管理层决定添加在线客户关系管理(eCRM)服务以减少为用户提供服务的开销。Switchouse 使用其 Web 站点的电子社区部分来提供成员对成员(member-to-member)的支持系统。 对于其公共和私有讨论组、电子邮件公告以及通知,Switchouse 选择将它们的对 Inclusion 的 eCRM 软件需求外包给系统集成商,加州洛斯拉图斯的 Inclusion 公司。Inclusion 软件以基于标记的脚本语言为特征,使其脚本生成的页面的观感和 Switchouse 的电子交易站点页面的观感一致。 图 1. Switchouse.com 主页提供了登录表单。
集成系统主要关心的是带给用户良好的体验。经验表明,Switchouse 用户几乎不能容忍缓慢的响应时间,因此登录系统需要实时地进行工作。除此之外,Switchouse 还有这样一些要求: 在一次会话过程中,只要求用户输入一次标识和密码。 设计小组要关注两个问题。第一,系统将怎样立即响应 Inclusion 生成的页面上的登录表单?第二,在将来某个时候,当有更大量的数据需要传递时,系统将怎样进行伸缩? 两部分解决方案 图 2. GateKeeper 系统的同步部分。
清单 1:HTML 登录表单 <FORM action="http://www.switchouse.com/keymaster.html" METHOD="POST"> <INPUT type="text" size="10" maxlength="32" name="login_username"> <INPUT type="password" size="10" maxlength="32" name="login_password" <input type="hidden" name="return" value="/switchouse/summary.html"> <input type="hidden" name="submitKey" value="Log In"> </FORM> 电子交易应用服务器上的 KeyMaster servlet 验证用户帐户,并且以指向 eCRM 服务器上的 GateKeeper servlet 的重定向命令响应表单请求。这个重定向命令看起来像这样: http://eCRMsite.inclusion.net/sq=%0A%12%38%31...%8B%9C&return=/switchouse/summary.html sq 参数包含用户数据。在基于 SOAP 的 Web 服务环境中,解密后的用户数据看起来像这样: <gatekeeper> <name>Frank</name> <password>83jdiej</password> <action>sign-in</action> </gatekeeper> GateKeeper servlet 解密用户数据,将用户登录到 eCRM 应用中,并且将用户的浏览器重定向到返回页面。虽然在这次事务中有重定向的页面,但是用户只看到带有登录表单的原始页面以及用户登录后的返回页面。这样,用户会感到很愉快。 异步协议 新用户的注册通常包括姓名、地址、电话号码、组关系以及作为新成员的权限。如果 URL 编码的(URL-encoded)用户数据多到长于 2000 个字节,同步方法将不保证仍能工作 — 许多浏览器会截断很长的 URL。GateKeeper 使用同步 Web 服务来接收最基本的用户信息,使用异步 Web 服务来接收附加的用户信息。 新用户将注册信息 — 姓名、地址等输入到 HTML 表单。该表单提交到电子交易服务器,从而将新用户数据插入到电子交易系统数据库。此次提交返回一个重定向命令,它包含了一个 GateKeeper XML 文档。 <gatekeeper> <name>Frank</name> <password>83jdiej</password> <action>new-user</action> </gatekeeper> GateKeeper servlet 解密这个 XML 文档,将新用户添加到 eCRM 服务器数据库,登录该用户,并将用户重定向到返回页面。所有过程在用户看来都是实时的。 GateKeeper 还将一个条目添加到异步请求队列中。该条目指示 GateKeeper 联系电子交易服务器的 KeyMaster servlet,从而检索用户的扩展的信息,包括公司、职称、电话号码、部门名称、经理姓名以及电子邮件地址。 <keymaster> <name>Frank</name> <password>83jdiej</password> <action>send-extended-info</action> </keymaster> KeyMaster 以扩展的用户信息向 GateKeeper 发出 Web 服务请求。 <gatekeeper> <name>Frank</name> <password>83jdiej</password> <action>update-user-info</action> <company>PushToTest.com</company> <title>Developer</title> <phone>408 374 7426</phone> <department>7</department> <manager>Fred Gibbons</manager> <email>fcohen@pushtotest.com</email> </gatekeeper> 交换新用户的数据、更新现有用户、删除用户以及报告错误都由同一系统完成。例如,响应的 XML 文档可能是一条错误消息。 <gatekeeper> <action>error</action> <error>400></error> <error_description>KeyMaster received an XML document that will not decode</error_description> <timestamp>38274883</timestamp> </gatekeeper> 使用这些同步和异步 Web 服务,系统实现了单点登录的目的。新用户即时访问了电子交易站点。该异步系统所测出的延迟通常少于五秒。用户感到很愉快。 只有开发者才应吸取的经验 单向的防火墙 为了与这个启动进度表相吻合,厂商选择 Inclusion 的托管的“应用服务提供商”(Application Service Provider,ASP)服务来开始,然后再将 Inclusion 软件合并到其数据中心。KeyMaster 和 LDAP 目录驻留在厂商网络内部,Inclusion 软件驻留在外部的网络。遗憾的是,虽然厂商的网络允许出站的 HTTP 请求通过,但是网络却阻塞入站的 HTTP 请求。 图 3. 单向的防火墙
单点登录系统具有双向的特性,却不能穿越防火墙。起先,我想到要求厂商的 IT 部门开放一条到内部 KeyMaster 服务器的特殊的没有保护的连接。但当我站在他们的立场,考虑一下我是否会为了一些特殊的情况而开放自己的网络时,我否定了这种想法。 解决方案是改变呼叫处理流程,使得只有 KeyMaster 来发起事务。当新用户注册以及用户登录时,运行于厂商网络的 KeyMaster 将联系 GateKeeper。 先计划集成 可靠的安全 当前的 SOAP 2.2 规范没有定义安全和认证协议。但是,很多工程师期望最终的 SOAP 规范将 SSL 定义为安全地发出 Web 服务请求的一种手段。OpenSSL.org 是 SSL 技术很好的资料来源,并且是免费的。 今天是 DTD 模式,明天将是 XML 模式 下一代单点登录系统将使用“SOAP 和 XML 模式”来定义请求和响应调用的参数。Java 实现将使用 JDOM 来创建和处理 XML 文档。JDOM 是简单的 API,它运行在 SAX 和 DOM 解析器之上,提供更类似于 JAVA 的、对 XML 数据进行处理的方法。 我是 KeyMaster。不,我是
KeyMaster。 首先这提出了一个潜在的问题:作为一家想要将另一家公司的服务集成到自己系统的电子交易公司,当其它公司提供了它们自己的服务器对服务器的通信系统时会发生什么呢?谁是 GateKeeper,谁是 KeyMaster?通过使所有的系统既是客户又是服务器,Web 服务解决了这个难题。入站请求与出站响应一样通过相同的协议被传送。 结束语
|
关键词:
|
相关文章 |