SOA可以为网格应用提供一种基于标准的资源描述方式，使之能支持更广泛的平台和环境，扩展网格应用的使用范围；而网格可以为基于SOA的应用提供一种虚拟化的基础设施服务，提供资源虚拟化、服务水平管理、计费管理等功能。
近年来，SOA和网格成为了IT技术发展的热点，许多企业都在研究和评估SOA和网格技术。有些喜欢先进技术的用户已经开始试用将非关键业务系统部署在基于SOA的网格服务上，率先地享受了SOA的灵活优势。
作者简介：朱明先生在IT业已有25年的深厚经验，继最初5年在惠普公司之后，1986年进入IBM位于达拉斯的开放系统中心担任顾问工程师，随后的20年一直在IBM不同的部门为各行业的客户服务。
企业的两大传统局限
在互联网时代，企业的传统应用具有两大局限性。其一为无法有效利用现代互联网技术，其二为无法编写互联网应用。这两大局限使得互联网的优势无法被传统应用充分利用。
SOA的体系架构正是为了突破这两大局限而产生的。SOA将应用程序的不同功能单元封装，能够在互联网上运行与被呼叫的独立功能模块。这种“互联网上”的模块被称之为“互联网服务（Web Service）”或“网格服务(Grid Service)”。
当这些“服务”被基于业务流程而被连成“流程”时，我们仍将它叫作“网格服务”。服务间通过基于标准的接口和协议连接。这种服务间的接口能够独立于实现服务的硬件平台、操作系统和编程语言，因此可以采用统一和通用的方式进行信息交换。
由于这是一种松耦合的集成方式，所以可以保证应用的最大灵活性，以满足在不断变化的环境中客户应用的需求，实现一种随需应变（On Demand）的业务模式。
面向服务的体系架构并不是一个新鲜事物，面向对象（Object-Oriented）的概念早在二十多年前就诞生了，分布式对象技术也在近十余年来得到了广泛的发展，如CORBA，EJB等。
SOA的主要不同点是采用了网格服务标准来描述应用接口，由于网格服务都是基于开放标准的，在其定义中就保证了体系结构和平台的无关性，因此基于SOA的应用程序可以部署到各种平台上，可以极大地简化基于SOA应用程序的部署和分布。
此外，除了服务描述以外，在SOA中还需要定义整个应用程序如何在服务之间执行其工作流，将业务的商业流程与具体实现的技术流程联系起来。
“虚拟化”分布的IT资源
网格计算是分布式网络发展的下一代产物，它可以让我们分享分散的计算系统资源。有了网格计算技术，用户可以将服务器、存储系统和网络联合在一起，组成一个大的系统，从而为用户提供功能强大的多系统资源来处理特定的任务，解决一些以前由于工作量太大而在一台计算机上很难处理的问题。
简而言之，网格是一种将分布的IT资源“虚拟化”的技术。
由于网格要利用很多技术组件，并需要在构成网格的多个功能域之间进行交互，因此标准就在网格的持续扩展中扮演了一个至关重要的角色。它们可以规范不同组件之间的交互操作，让供应商集中精力在自己的应用实现中提供更高的价值。
如果没有网格解决方案框架中的标准，用户就不可能利用一种模块化和协调的方法来为自己的网格环境持续增加能力。
目前，网格正在向网格服务架构发展，首先是Globus采用开放网格标准基础设施（OGSI），然后是新发布的Globus工具包Globus Toolkit 4.0（GT4）对网格服务资源框架Web Services Resource Framework（WSRF）的支持，可以看到网格标准和网格服务正在走向统一（如图1）。
SOA可以为网格应用提供一种基于标准的资源描述方式，使之能支持更广泛的平台和环境，扩展网格应用的使用范围；而网格可以为基于SOA的应用提供一种虚拟化的基础设施服务（Infrastructure Services），提供资源虚拟化、服务水平管理、计费管理等功能。
用户可以方便地添加IT资源来扩展应用的处理能力和提高服务质量，由此简化SOA的部署，降低系统运作和管理成本。通过企业服务总线（ESB），两者可以有机结合，为企业提供一个随需应变的运作环境（On Demand Operating Environment）（如图2）。
基于SOA的网格程序和传统的网格应用相比，可以分解为一系列独立的互联网服务功能组件，并且可以在不同平台上运行，提供了更大的灵活性；同时，依赖于网格服务的描述和发布机制，可以实现网格资源的自动发现和配送，能大大提高网格的自治性。
但真正将网格应用移植到SOA平台上，有两点问题需要考虑：
1.应用程序能否划分成更小的、互相独立的功能模块
在系统设计时，应该尽量避免采用不可分的单块程序架构，而是采用一种“搭积木”的思路来考虑问题。
2.功能模块是否能独立运行
在模块运行时，应尽量避免对物理资源的长期占有。当需要使用共享的资源时（如数据库连接），应尽量采用Web服务的方式来进行所需的操作，并在操作完成后迅速释放资源。
对于企业来说，将整个基础架构迁移到SOA，这一过程应该是一个进化，而不是一个改革。用户需要和选定的技术合作伙伴一起，制定一个良好的分步实施方案，避免可能的风险，并在每个步骤都获得良好的投资回报。
以下几点是这一迁移过程能否成功的关键因素：
◆ 技能：用户自身技术人员或合作伙伴对网格服务和SOA的掌握程度，对于应用架构向SOA的平滑过渡至关重要；
◆ 应用：现有应用是否需要作大幅度的修改，对应用程序的执行效率会不会有影响等。一般会先选择一些合适的应用作为试点；
◆ 业务：在迁移过程中可能涉及对业务模式和业务流程的优化，因此对业务流程的熟悉程度和相关行业的实施经验和IT同样重要。
◆ 基础设施：现有的基础设施能否被重用？基础设施能否提供足够的灵活性来支持未来的扩展？基础设施是不是具有部署SOA所需的虚拟化能力？
将网格应用移植到SOA平台上，能够提高资源的利用效率，简化资源的管理，进一步地推动企业范围内的协作。可以预见到，网格技术将在企业架构的SOA发展之路中起重要作用。这种技术终将使企业的应用在未来能充分的发挥互联网的优势。
应用实例
我们以一个实际的客户应用案例，来说明SOA向网络服务迁移的这一过程，该用户是美国的激光干涉仪引力波探测实验室（Laser Interferometer Gravitational Wave Observatory，LIGO）。这是一个由美国国家科学基金委员会支持的项目，目标是观测和验证由爱因斯坦提出的引力波理论。
目前这一项目覆盖了十个不同地点和数以百计的科学家，需要处理150TB规模的数据，而且这些数据还以每天1TB的速度在增加。
客户以前在每个地点都采用了专用的网格产品和架构，用户只能在本地提交作业。由于数据和存储能力是分散在不同地点的，用户需要手工地将数据在不同地点间进行移动。这样不仅使用不便，不利于科学家之间的合作，而且也造成了IT资源的利用效率不高（如图3）。
随着Globus 4.0的发布及其对距联网服务标准的支持，用户希望将他们的基础设施迁移到SOA的架构上去。因此，他们在现有的环境基础上添加了新的网格服务中间件，并且采用面向服务的方式对现有的业务流程进行了封装，具体说明参看图4。
通过上面的例子可以看到，用户并不需要对现有的IT基础设施作太大的改变。通过将现有的网格平台封装为网格服务，并添加新的工作流管理和数据管理组件，用户可以实现统一的面向服务的网格架构（或SOA网格），而现有的网格资源也为这一SOA的架构提供了必要的基础设施。这一架构也同样适用于许多分布的企业中。
1 首先定义了通用的数据服务和工作流管理服务，用户通过元数据（Metadata）来定义和提交作业。
2 工作流管理服务通过查询元数据判断作业对数据的需求。
3 元数据将用户数据需求映射为逻辑文件名 。
4 通过网格服务中间件提供的RLS（位置复制服务）将逻辑文件名映射为分布在不同地点的物理文件名。
5 通过网格服务中间件提供的RFT（可靠的文件传输服务），将需要移动的数据传递到作业执行地点。
6 工作流管理服务将数据文件和计算作业结合在一起。
7 工作流管理服务将整合的作业提交到工作流执行服务。
8 通过网格服务中间件提供的GRAM（网格资源分配和管理）组件将作业提交到已有的网格平台上。
9 执行作业。