在WebLogic环境中考虑SOA

最近我在为一个客户工作，他们有许多部署在WebLogic 8.1上的J2EE应用程序，需要我帮助他们把应用程序资产转化为SOA的服务资产。他们有严格的时限，所以不能对应用程序代码进行大的改动。在讨论中，他们不断提出关于Web服务的问题，我感觉人们通常将Web服务看作SOA的构件块。他们关注的是将应用程序组件转化为Web服务以及由此给整体环境和操作带来的影响。

许多人将Web服务看作SOA基础架构的构件块，这并不奇怪。我认为Web服务可以是SOA的构件块，但并不一定是必需的。下面我将介绍为什么以及如何可以将部署在WebLogic Server上的应用程序组件看作作为SOA一部分的服务。

应用程序可以被分解为实现业务功能的组件。每一个应用程序都有特定的业务、功能和操作需求。功能需求要迎合实现，在这方面我不准备花太多时间介绍，因为我们讨论的是已经成为企业一部分的、需要转化为SOA构件块的应用程序。此时我们需要关注的是，如何关联业务需求并为该应用程序提供一个轻松的操作环境。

许多业务需求都归结为对应用程序的服务水平协议(SLA)的满足，业务需求可能包括以下方面:

并发用户

响应时间

错误率

工作负载优先化(业务功能按照优先级进行分解)

应用程序采用率(就用户数目而言的应用程序扩展路线图)

可用性

操作需求与维护基础架构有关，可能包括以下方面:

应用程序监控

部署策略

维护(补丁、升级)

问题诊断

大多数情况下，WebLogic实例上部署了许多应用程序，难以将上述需求关联到该环境中。

隔离:给出上述场景之后，我们来看一种将这样的环境转化为SOA的一部分的方法。第一步是要隔离被认为是关键型的应用程序或组件。可以通过将这些应用程序部署到各自的WebLogic实例中，然后关联适当的存储器和WebLogic资源到该应用程序来实现隔离。然后这些服务器实例可以被集群化，这样就有助于进行故障转移，从而使环境具有高度可用性。不要忘记:业务期望值越高，基础架构的成本就越昂贵。如果需要隔离应用程序的特定组件，可以利用定制的执行队列(_execute Queue)或工作管理器(Work Manager)(9.0中的新特性)，为它们配置适当的线程数。创建执行队列可以为应用程序组件提供分离的请求通道，并防止请求缺乏关键型业务功能。在连接池级进行隔离可以确保数据库资源的可用性。

服务器特征:我们需要从吞吐量、负载之下的响应等方面来了解服务器特征。这是通过进行负载/压力测试，然后调优环境以获得WebLogic Server实例的最佳性能指标来完成的。这是一项重要的任务，因为它可以帮助规划以后的应用程序采用率，从而提供一个可伸缩的环境。