大规模的财政应用和面向服务的体系结构(weblogic)

　　 
财政机构在J2EE和基于组件的结构上已经有了很重的投资。WebLogic服务器是用来对客户和贸易伙伴展开革新财政服务的关键的电子商务平台。出现面向服务的结构范例是对J2EE（Java 2 platform Enterprise Edition）的很自然的扩展，并且WebLogic把它无缝集成起来。

组件和商业过程的重用

组件的重用是构造大规模的商务对商务（B2B）的财政服务的关键；本篇文章说明了用WebLogic平台实现这些服务的好处。电子商务提出的最基本的方法是核心的业务逻辑是定位以及被管理于应用服务器上。此外，现在业务逻辑可以从各种各样的介绍渠道获得。WebLogic是用于加强处理集中商务过程重用的一个强有力的平台。如果你给Excel电子数据表单提供商务过程，简单的做法是你不得不压缩它，将其当作SOAP（Simple Object Aclearcase/" target="_blank" >ccess Protocol 简单对象存储协议）服务， 然而WebLogic可以极大地简化这项任务。

应用拓扑学和商务模式

退回一步，我们注意到在金融领域中出现的一些电子商务模式是很有趣的。在其最简单的形式中，商务模式描述用户，商务和数据之间的相互作用。在这种理解下, 用模式驱动的方法构建围绕着WebLogic的电子商务结构是非常有趣的。J2EE的体系结构可以简单的被映射成不同的商务模式，类似用户－商务，或叫"自助"模式；用户－数据，或叫"信息集合"模式；和B2B，或叫"扩展企业"模式。

一旦你确认了你的财政服务所应用的电子商务的模式，下一个步就是把它绘制成应用拓扑结构，按顺序编成runtime拓扑结构。本篇文章将主要集中于财政服务的用户－商务模式，但是也将谈到类似Web服务的企业应用的扩展。

对于用户－商务模式，已经确认了两个应用拓扑结构。在第一种拓扑结构中，你的应用是不需要和遗留系统以及第三方应用交互的。这种类型发生在当你构建不需要WebLogic服务器连接遗留系统的纯J2EE应用体系时。在第二种拓扑结构中，你的应用系统是需要和遗留系统以及第三方应用进行交互。这在需要获得实时数据提供的财政服务，ticker plants ，和第三方业务管理系统中最普遍。
runtime拓扑学

一旦应用拓扑结构被确认，它肯定被编成runtime拓扑结构，并作为电子商务解决方案被最终部署。以下是为用户－商务模式提供的本质的财政服务的概况的一览表：

1． 有权使用实时财政消息和数据的供给
2． 在事件上的通知和改变，例如贸易或引用值
3． 财政手段的实时贸易
4． 业务量计算和报告

令人惊讶地，顾客已经开始期待这些服务在移动设备上有功能上相同的水平使他们可以使用Web浏览器。财政服务必须自始至终被设计成多渠道的。图1解释了当应用WebLogic构造大规模，多层次的财政应用时，我发现runtime拓扑结构非常有效。

节点

runtime拓扑结构由几个节点组成，他们被看成是特定的功能，如防火墙，Web服务器和目录服务像LDAP（Lightweight Directory Access Protocol）等。每个节点在围绕着WebLogic而构造的企业贸易系统中都很重要。

这些节点代表着外界连接不同的财政商务过程的角色。一个角色可以是私人的或者制度上的客户，另一个应用通过Web服务/SOAP沟通，经纪人公司用FIX协议在预定，承认贸易订单，甚至是可移动的委托人。一个或几个角色初始化大部分系统用例。
第一个防火墙节点根据一套规则从因特网和过滤通信量限制访问。例如，大部分的银行业务应用HTTPs（Hypertext Transfer Protocol超文本传输协议）密码化，使防火墙仅能确认某几个IP地址和端口号443。第二的防火墙节点限制从非军事区（DMZ）到内部网络的访问。介绍通道和其他节点，如FIX引擎的移动网关等定位于DMZ。

Web服务器节点（WebLogic在这个拓扑结构中）作为财政上的Web应用。在大部分的情况，这种应用在文件管理，电子报告和对财政的数据和消息的访问中。客户使用Web方法；然而，大部分的业务逻辑处理通过RMI/IIOP（Remote Method Invocation/ Internet Inter-ORB Protocol 在Internet对象请求代理协议上的远程方法调用）使EJB组件定位于第二道防火墙后面。

FIX引擎节点是一个非常专门的用来生产和消费把消息编码成FIX的消息引擎，是一个跨产业的开放式协议，特别的发展了实时性和股票处理的无缝的电子的交换。FIX能给你提供直通的处理，它减少了处理成本，实质上是消除了在贸易商和代理人之间的电话和传真的沟通。通常，一个FIX引擎必须满足和其他runtime节点相同的高效性准则；因此，大部分的引擎销售公司是将集群和容错功能集成在他们的产品中。

Web服务服务器节点提供基础结构去编制SOAP调用在主机正面第二道防火墙后面的会话EJB。用这种RPC(Remote Procedure Call 远程过程调用) 形式调用到达Web服务服务器的SOAP消息。服务器解析消息并用RMI/ IIOP调用会话EJB，这个EJB依次处理本地调用驻留在WebLogic上的会话beans和实体beans。举这个例子说明作为EJB组件封装起来的可重用的财政过程的好处，它可以由Web应用服务器和SOAP客户端支撑。作为Web服务，RPC 形式的调用对于提供定价或证券的优化分析很理想，它提供很多新的机会去共享内外过程。

移动网关节点在企业财政过程和移动平台如Symbian, Palm OS和Windows CE等之间提供连接。随着更强大的设备和更丰富的用户界面的出现，移动用户期望可以由桌面应用服务器提供相同水平的功能。WML (Wireless Markup Language 无线标记语言) 几乎不体现那种理解。 使用基于JMS (Java Message Services Java消息服务) 的可移动中间件是一个不错的方法。这种解决方案依赖三个组件：WebLogic作为给财政商务逻辑，数据同步和安全性的一个JMS供应者；一个移动的JMS网关；和一个非常小的驻留在移动设备上的JMS客户端程序。来自Softwired公司的iBus//mobile (www.softwired-inc.com) 为构建使用JMS的移动服务对WebLogic进行无缝集成。由于移动平台有诸如间歇性连接和中断通信连接等问题，提供队列设备和可靠的消息传送是JMS消息传送所必须的，是理想的候选者。

大量的财政过程定位在第二道防火墙后面的节点上。在这种情况下，WebLogic应用服务器是一个主要的储存库，储存那些由可重用的财政商务过程打包成的会话beans，实体beans，和消息驱动beans。最终目标，组件的重用是通过确认在所有大规模的财政应用中重复出现的基本服务并且将他们压缩作为EJB的组件而实现的。组件的重用实现起来有困难；然而，在现今快步调的市场经济下我们除了依赖于坚实的以及经过可靠测试的重要组建集群外，是别无选择的。

目录服务节点对于创建单一的注册基础结构不可缺少。单一的注册不仅消除了多用户的注册和口令的管理争论，而且在整体上大大的简化了管理任务。一个LDAP的目录不仅可以储存像电子邮件地址这样的一般信息，也可以存储强大的认证信息，用户证明。从应用发展观点看，集中的数据存储对于用户管理是非常重要的，因为同样的授权和认证业务逻辑在每一次的应用中不能复制。对于runtime拓扑结构有一些细微的不同，它需要在DMZ上加上一个只读的"从属"LDAP目录。写控制在第二道防火墙后面，复制习惯在同步控制和从属节点。这种解决方案有更好的缩放的优点。

引用服务器，或者叫"标记设备"节点是一个实时的行情数据分配系统就像Reuters Triarch。标记设备用TIBCO的通信技术，从TIBCO集合消息实时的调度JMS的引用消息到客户端应用节点。

客户端应用节点是GUI(Graphical User Interfaces 图形用户接口) 用来管理证券或输入交易订单。除了实时引用的处理之外，在GUIs后面的大量的业务逻辑实际上是作为EJB组件来执行的，它驻留在WebLogic上并由Web层重用。

这种交易处理节点是一个后台系统用来调整和清除交易的。财政商务过程从驻留在WebLogic 发送JMS交易消息道交易处理器，处理器确认交易之后把JMS消息返回给消息驱动bean。

最后，Reuters Investor 节点 (http://rfs.reuter.com/investor) 用XML(extensible Markup Language 扩展标记语言) 格式为驻留在WebLogic上的财政组件提供财政数据和消息。Reuters Investor服务和引用服务器的不同在于，Reuters Investor服务是用来构建财政上的入口由灵活的Reuters数据提供，而引用服务器的目标是为贸易提供实时的财政数据流。
在不同的节点使用分组，例如FIX引擎，移动网关和WebLogic服务器等，提高了可靠性和实用性。横向的缩放通过分组获得。通过给服务器机器增加CPU和内存等资源达到了纵向的缩放。在这种拓扑结构，WebLogic在DMZ中被用作Web服务器并作为应用服务器在内部的网络中应用。

面向服务的体系结构

在DMZ中应用WebLogic是很有意义的，尤其是用由WebLogic7.0 提供了附加功能的和像WebLogic WorkShop 一样的工具。因为WebLogic同时扮演着集群Web服务器和Web服务节点的角色所以runtime拓扑结构也被简化了。然而，还有更好的理由使用WebLogic服务器来构建面向服务的体系结构。如果你用过WebLogic Workshop，也许你已经看到了构建和发布Web服务是多么的简单。这不是个秘密；我们都知道企业计算的下一步是面向服务的体系结构。真正的问题是如何尽可能无痛苦的达到这个目标。很多人相信使用像WebLogic WorkShop 一样的工具，面向服务的体系结构在设计企业软件上会体现出基础上的转变，比起基础上的转变，它更是使企业软件扩展和适应的问题。毕竟，你还必须开发J2EE组件，并且，你还必须应用J2EE模式，不同的就是你必须考虑服务的面向。

在大多数情况下，商务过程复杂并且需要若干异步步骤。甚至是最简单的财政过程，像一个贸易订单，可能从事跨越若干天的复杂的工作流并且需要很多角色的干预。如同在图2中被描述的那样，当你可视化软件结构并把它作为中心过程规程开发的时候，真正基础上的转变就发生了。最有趣的是构建过程模型和在Web服务上发布他们的能力。

对WebLogic Workshop进行测试

为了将WebLogic Workshop作为中心过程软件开发工具进行评估，我"重新开发"了我帮助建造的应用。
银行A想出售基金给银行B，银行B希望依次通过提供适当的证券出售这些基金给他的客户。过程包括了几个复杂的步骤和商业规则。另外，银行A 的IT基础结构和银行B的完全不同。

我们设计了通过发送和接收每天的批量文件交换信息相关的笨拙的模式。然后业务逻辑曾为了使贸易和订单得到确认办理了文件。这个过程需要了很多手工操作的干预，在最后我有了"我能做得更好"的感觉。

使用 Web 服务解决问题是非常好的,但是直到最近它仍然被当作实验性的技术被考虑。 用WebLogic Workshop，这不太现时。给我留下深刻的印象是我可以很快的设计原型和把应用作为一组Web服务来重新设计并且逐渐地使整个工作流程可视化。我将结果展示给一个有一些软件工程知识的商业专家看，由于WebLogic Workshop的可视化界面，他能够提供反馈，并且我们能交互式的修改和调整商业模型。

角色的分离

runtime拓扑结构的目标不仅是提供一个安全的，可调整的，和可靠的环境, 而且可以促进在开发者之间的角色上的分离。 在图1中runtime拓扑结构提供了驻留在WebLogic上的业务逻辑组件和表示逻辑组件的清晰的分离。有 EJB 和 WebLogic 程序设计丰富知识的开发人员构建可重用的商业组件。开发者工作在Web服务和表示通道然后将它们集成在表示层。

一个重要的问题是从中间层的方法调用和数据传递的性能考虑。 J2EE 设计模式是避免这些缺陷的最好的信息来源。 我推荐佛洛依德的书, EJB的设计模式, 作为模式的来源和用EJBs构建分布式系统的最好的实践。

简单用例

最后，让我们看典型的用例的情况。考虑一个用户在访问金融机构的站点。Single Sign-on过程自动认证该用户。今后，他或她根据该组可以访问资源。个性化信息如报告，财政数据和消息通过WebLogic的Portal和portlet提供。

证券portlet给用户一个即时的关于他或她的目前的资产的总的情况以及最新的增益/损失情况。建议portlet显示依照用户情形的当前的建议。由于交易的portlet，用户回顾这个建议并且在一定限制条件下输入交易订单。用户终止连接，并且订单被委派到业务层EJBs。

同时，一个交易通知JMS消息被送到由用户监听的证券管理器。当证券管理器连接到应用服务器，他或她确认交易订单，并且另外的一个 JMS 消息从客户端的GUI应用程序发送到交易处理器。在一些处理之后，交易处理器返回一个JMS确认消息给另一个由FIX引擎确认，并且发送它到另一个JMS消息。然后FIX引擎将交易订单作为FIX消息打包并将它发送给代理。经过一些处理，代理返回一个确认信息，这个确认信息被编译成JMS消息，并返回到业务层。一个通知被发送到他或她的移动电话。

结论

过去的一年中，财政机构在J2EE体系结构上已经有了很重的投资，以使其适应并对Internet、贸易伙伴和客户开放其内部的IT基础设施。WebLogic服务器已经成为大规模的财政应用的基本组件和基本服务，例如在线贸易或证券管理。面向服务的体系结构对于构建高度分离的服务为中心的和商业过程为中心的解决方案是合理的下一步骤。不过，现在对于J2EE的投资应该被用杠杆作用操纵，并且面向服务的体系结构应当被当作J2EE基于组件模型的发展而不应是变革。像WebLogic服务器和WebLogic Workshop等工具，不仅仅保留你的现在的投资也使向面向服务的体系结构转变变得容易。

原文转自：http://www.ltesting.net