接上文
许多资料和专家都在强调，系统开发应当抽象与封装变化，这样才能做到业务无关性，但只是这一个系统的业务无关性，不是全局的，这是一种向内塌陷的抽象，也是目前软件工程只用于形不具其神的表现。即使软件设计时考虑到接口的存在，也只是为了完成某一业务流程或目的，设计的接口，这些接口是没有抽象，是具有强业务相关性的！这不是敏捷、应用集群的特性。
2.实施了局部信息化应用
企业只有实施了信息化，有了一个个相当独立的信息系统－“信息岛”，才有可能出现所谓的“孤岛”。
3.现有系统之间出现了不能满足的信息沟通需求
“信息岛”之间出现了不能满足的信息共享或信息沟通需求，是信息孤岛的又一个必要条件。如果“信息岛”之间没有任何信息沟通的渠道，虽然在客观上已经形成孤立的“岛屿”，但是，这些孤岛之间如果没有信息沟通的需求，也不算是信息孤岛。
4.系统本身缺乏满足新的信息共享需求的能力
现有系统之间出现了新的信息共享需求，又无法通过调整系统配置建立相互之间的沟通、满足新的要求时，信息孤岛就出现了。
怎样解决这个问题，同时具有比较高的投资收益呢？
再讲这个问题前，需要先了解一下SOA以及搭建在这种架构方式上的“系统场”的概念。
多重复用的场组件
面向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。
对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。
所谓“系统场”即是搭建在SOA思想上的一种企业系统模型，多个系统的业务逻辑层抽象为WebService，组成一个全局“场”，每个系统间可以通过这个场获得需要的业务模型。结合上面举过的采购、生产例子，每套系统之间已经没有具体的边界，而是通过一个集成后的业务容器来完成各自的任务，这就是“场”的作用与工作方式。
怎样实现与交互“场”中的逻辑呢？
Web Services是一种新型的面向服务的体系结构，相对传统的技术。该计算模型通过提供动态的服务接口来实施一个动态的继承，实现了发布服务的应用程序和使用服务的应用程序之间的松散耦合。同时Web Services允许将应用程序划分为一些小的逻辑组件，使业务集成在小粒度的基础上变得更加容易。
Web Services是由URL标识的软件应用程序，其接口和绑定可以通过XML构件进行定义、描述和发现，Web服务支持通过基于Internet的协议及使用基于XML的消息与其他软件应用程序直接交互。其主要特点体现在：
1）协议的通用性。
2）完全的平台、语言独立性。
3）软件重用。
另外，Web Services以技术栈的形式规范了Web Services体系中的各类关键技术，包括服务的描述、发布、发现以及消息的传输等。
Web Services体系使用SOAP协议在实现应用与服务之间的通信，用WSDL文件对服务进行标准的描述。SOAP和WSDL都是基于XML的，这保证了XML的跨平台操作。同时，SOAP一般使用标准的HTTP协议，可以透明地穿透防火墙。
1）Web Services促进了互操作性。
2）Web Services促使即时集成。
3）Web Services通过封装减少了复杂程度。
3.3 Web Services与应用集成
应用集成解决方案可以呈现许多种形式并以多种级别出现。而适应应用集成中间件解决方案的3个主要类型有：数据集成、业务流程集成、函数或方法集成。Web Services能彻底地改变传统的应用集成中点对点的集成处理方式。使用Web Services，通过松散的应用集成，可以仅仅实现应用集成的一个子集，即能取得实效。与之相反，应用集成要实现一个全盘的方案，来紧密的集成和联系支持业务的所有的系统和应用。Web Services，以一种松散的服务捆绑集合形式，能够快速、低代价地开发、发布、发现和动态绑定应用。
以WFMC的工作流管理系统参考模型为基础，结合具体的Web服务技术，一种面向Web Services的工作流模型应包括服务门户、服务驱动引擎、服务注册中心、消息总线、信息资源库、Web Services组件、过程定义工具、以及服务流程管理工具等组成部分。
综上，利用WebService技术，结合业务模块粒度评估与划分组成的企业系统“场”能够解决信息孤岛，并很好的实现了业务流的共享。
本文转自Aicken(李鸣)博客园博客，原文链接：http://www.cnblogs.com/isline/archive/2009/12/15/1624947.html，如需转载请自行联系原作者
