时间：2006-02-15
作者：Suchin Rengan
浏览次数： 648
本文关键字：SOA, WebLogic, Web Service, Web服务 文章工具
推荐给朋友
打印文章
最近我在为一个客户工作，他们有许多部署在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实例的最佳性能指标来完成的。这是一项重要的任务，因为它可以帮助规划以后的应用程序采用率，从而提供一个可伸缩的环境。
灾难恢复规划：关键型应用程序应该有适当的灾难恢复规划。我信任hot-hot型而不是hot-standby（热备份）型的冗余环境。如果备份不能运行该怎么办？如果出现故障，有多少服务器实例才足以维持峰值负载？关于这方面的详细信息也必须在文档中注明。所有这些可以确保在出现故障时能够有一个运行良好的环境，而保护业务是底线。
统一管理：我曾经在一些机构中看到他们用一个操作小组来管理多个WebLogic域。这样的环境是难于维护和管理的。考虑需要进行更新的场景。还有监控——这是一项日常操作任务——必须查看多个WebLogic Server控制台以收集信息。我的建议是，在可能的地方对类似的应用程序创建多个集群而不是多个域。集群提供对应用程序的固有隔离级别，这会产生较少的域以及更易于管理的环境。
操作是面向流程的：对环境的操作很大程度上是面向流程的，且需要进行详细的记录。错误模式和正确的解决方案的记录都是一个动态过程。环境进行升级和打补丁的停机时间必须符合高可用性的业务需求。必须为维护设置适当的过程。还要定义逐步升级的过程，并写入文档。作为部署过程的一部分，还应该采用域模板，以便产生跨不同环境的一致域。
提供透明性：一个管理良好的环境需要有针对关键性业务破坏的报警机制。在问题诊断时，服务器日志中的信息必须有一定的透明度。应用程序必须记录有助于问题诊断的关键信息。在问题诊断时，可以使用诸如来自Splunk之类的工具来聚合来自服务器环境中不同日志的信息。此外，预期和实际的关键性技术指标也应该被收集并关联起来。例如，在容量规划期间，可以基于业务需求预测特定数目的并发用户，而这个数字可能与生产环境中实际得到的数字不同。这类技术指标应该定期报告，以方便以后的环境调优。
结束语
在本文中，我介绍了一种经过大大简化的方法，用于将驻留在WebLogic上的应用程序转化为SOA中的资产。此外，我没有谈到的其他领域（比如数据库、外部系统）也需要进行分析和研究。上述概念也可以应用于这些系统。这些特性都带有相关的成本，因此必须分析实现它们的投资回报(ROI)。最后您将得到一个可以满足业务和功能需求的环境，就可以很好地实现SOA了。本文并未涵盖所有的SOA要素，但是它提出了一个用于满足复杂的WebLogic环境中的某些SOA需求的解决方案。
参考资料实现执行线程
原文出处 Thinking SOA in a WebLogic Environmenthttp://dev2dev.bea.com/blog/srengan/archive/2005/12/post.html
作者简介
Suchin Rengan 是BEA公司专业服务机构的一名资深顾问。他于2004年12月加入BEA，在此之前，他在惠普公司担任J2EE应用方面的解决方案架构师。他还担任Chase和GSK公司的顾问。Suchin积极参与dev2dev的活动策划。他领导着CodeShare中的几个开源项目，其中一个旨在凝聚社区的力量来开发面向WebLogic和AquaLogic平台的Eclipse插件。
_xyz
时间：2006-02-15
作者：Suchin Rengan
浏览次数： 648
本文关键字：SOA, WebLogic, Web Service, Web服务 文章工具
推荐给朋友
打印文章
最近我在为一个客户工作，他们有许多部署在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实例的最佳性能指标来完成的。这是一项重要的任务，因为它可以帮助规划以后的应用程序采用率，从而提供一个可伸缩的环境。
灾难恢复规划：关键型应用程序应该有适当的灾难恢复规划。我信任hot-hot型而不是hot-standby（热备份）型的冗余环境。如果备份不能运行该怎么办？如果出现故障，有多少服务器实例才足以维持峰值负载？关于这方面的详细信息也必须在文档中注明。所有这些可以确保在出现故障时能够有一个运行良好的环境，而保护业务是底线。
统一管理：我曾经在一些机构中看到他们用一个操作小组来管理多个WebLogic域。这样的环境是难于维护和管理的。考虑需要进行更新的场景。还有监控——这是一项日常操作任务——必须查看多个WebLogic Server控制台以收集信息。我的建议是，在可能的地方对类似的应用程序创建多个集群而不是多个域。集群提供对应用程序的固有隔离级别，这会产生较少的域以及更易于管理的环境。
操作是面向流程的：对环境的操作很大程度上是面向流程的，且需要进行详细的记录。错误模式和正确的解决方案的记录都是一个动态过程。环境进行升级和打补丁的停机时间必须符合高可用性的业务需求。必须为维护设置适当的过程。还要定义逐步升级的过程，并写入文档。作为部署过程的一部分，还应该采用域模板，以便产生跨不同环境的一致域。
提供透明性：一个管理良好的环境需要有针对关键性业务破坏的报警机制。在问题诊断时，服务器日志中的信息必须有一定的透明度。应用程序必须记录有助于问题诊断的关键信息。在问题诊断时，可以使用诸如来自Splunk之类的工具来聚合来自服务器环境中不同日志的信息。此外，预期和实际的关键性技术指标也应该被收集并关联起来。例如，在容量规划期间，可以基于业务需求预测特定数目的并发用户，而这个数字可能与生产环境中实际得到的数字不同。这类技术指标应该定期报告，以方便以后的环境调优。
结束语
在本文中，我介绍了一种经过大大简化的方法，用于将驻留在WebLogic上的应用程序转化为SOA中的资产。此外，我没有谈到的其他领域（比如数据库、外部系统）也需要进行分析和研究。上述概念也可以应用于这些系统。这些特性都带有相关的成本，因此必须分析实现它们的投资回报(ROI)。最后您将得到一个可以满足业务和功能需求的环境，就可以很好地实现SOA了。本文并未涵盖所有的SOA要素，但是它提出了一个用于满足复杂的WebLogic环境中的某些SOA需求的解决方案。
参考资料实现执行线程
原文出处 Thinking SOA in a WebLogic Environmenthttp://dev2dev.bea.com/blog/srengan/archive/2005/12/post.html
作者简介
Suchin Rengan 是BEA公司专业服务机构的一名资深顾问。他于2004年12月加入BEA，在此之前，他在惠普公司担任J2EE应用方面的解决方案架构师。他还担任Chase和GSK公司的顾问。Suchin积极参与dev2dev的活动策划。他领导着CodeShare中的几个开源项目，其中一个旨在凝聚社区的力量来开发面向WebLogic和AquaLogic平台的Eclipse插件。
_xyz