社会网络 是具有特定的共同特征的个人组成的团队的关系模型。个人还可能属于多个社会网络。例如，Joe Soap 属于得克萨斯大学毕业生的社会网络、奥斯汀山地自行车爱好者组成的社会网络、专门在 Whole Foods 购物的个人组成的社会网络，如此等等。Joe Soap 属于各种社会网络。

　　关于特定社会网络特征的知识是一个非常有价值的工具，可供应用程序开发人员用于仔细研究社会网络的需要和要求，并恰当地定制应用程序。例如，您可以添加有用的功能，而删除无用的功能。这就使得应用程序更加适合于其特定的目标社区。此外，您还可以通过寻求反馈并在应用程序的多个修订版本中包含这些反馈来与这些社区紧密合作。此方法与设计针对更广泛受众的软件相对，受众广泛的软件要求添加各种功能，而这些功能有可能会使用，也有可能不使用。

　　Clay Shirky 所撰写的文章给出了几个非常有说服力的示例，说明了纽约大学的学生如何针对特定的目标受众设计有用且受欢迎的应用程序。他还指出这些应该程序在定位为针对更多受众的情况下，在价值和受欢迎程度方面降低的情况。因此，总的说来，环境应用程序 是针对特定环境需求创建的应用程序，是在与特定社会网络协作的情况下设计和开发的。

　　要注意的另一个有意义的因素是，由于市场变化很快，大量的业务协作时间都短于 12 个月。由于平均应用程序集成工作需要三到六个月，因此没有太多的时间获得投资回报（Return On Investment，ROI）。行业需要能快速构建而且成本合理（考虑到整个协作时间）的解决方案，以解决直接而具体、但同时也认为可以解决（随着市场的发展）的业务问题。由于环境需求经常导致应用程序仅在短暂时间内使用，因此环境应用程序还有另一个特征，即最终结果可以为非正式且足够好 就可以，因为并不需要具有产品级别质量的功能和特征。

　　如何创建环境软件？

　　如果 SOA 可以发展和进行改进，以让用户更为方便地释放信息和提高可访问性，则可以建立一个 Mashup 生态系统，以便用户能够快速地创建环境软件。虽然这很有意思，这些实际上是非常难于实现的目标。以下部分将对此方法进行更为详细的说明。

　　SOA 发展

　　IT 行业正在大刀阔斧地将 IT 基础设施分解为模块、可重用服务。虽然这已经在其他领域体现了其价值，但仍然需要开发人员具有相关的技能才能使用这些服务集成和构建应用程序。由于 IT 存在的目的是为了满足业务的需求，因此 SOA 的下一个发展就是将这些服务送到用户（非开发人员）手中，以便他们构建解决方案，从而克服前面描述的关于 ROI 的问题。

　　而且，要实现环境应用程序的需求，需要让开发的成本大幅度降低，同时还能提高其应急能力。您需要新的方式访问和利用 SOA 中当前的服务，让最终用户或业务用户能够快速地将这些服务集成到一起。此方法将允许他们快速地创建满足其环境需求的应用程序。

　　为了使此类模型生效，服务需要具有对应的可视元素。每个服务的“脸”（即可视表示形式）可以提供对该服务的属性和功能的访问，并能反映服务之间的关系（连接）。实现了这一点后，可以创建服务类别来包括服务的可视表示形式和可以从选择面板上拖放并在画布上使用的内容。如果能够以可视的方式提供对服务属性的访问，则可以不用编程就能完成连接阶段的工作。在业务用户已经熟悉了新服务的功能和内容的情况下，就能通过这样非常快地创建应用程序。

　　如果业务用户是使用服务的用户，则可以提供关于服务所提供的信息的粒度的有用反馈。在这之前，服务中提供的信息粒度经常由性能和保持旧的遗留接口的现状等因素决定。如果业务用户能够使用这些服务构建应用程序，则可以根据其在应用程序中的实际使用 情况来提供关于信息粒度的宝贵反馈信息。

　　图 1 显示了如何将 SOA 作为环境应用程序的基础架构使用的框架。

　　图 1. SOA 上的可视表示形式
 
　　一个比 Shiry 的论文中提供的示例更为广泛的社会网络，即现代业务最终用户或超级用户组成的社会网络。这种由个人组成的特殊网络的特点是，这些人对 Web、系统中所使用的特定技术以及基本编程技能（如创建 Microsoft® PowerPoint® 自动化和 Microsoft Excel® 宏的能力）都有很好的理解。这些用户与其受众有较为密切的关系（通常是一个小得多的社会网络），能够使用此知识来避免将时间浪费在明确不需要的功能上。为了向这些用户提供所需的能力，需要使用这些技能来利用用户关于内容源（企业内和网络上）、工具、产品和服务的知识，以便构建可为其业务部分起到推动作用的环境应用程序。可以通过采用 Mashup 生态系统实现此目标，如图 2 中所示。

　　图 2. 支持用户构建环境应用程序的目标
 
　　Mashup 生态系统

　　图 3 中的关系图显示了 Mashup 生态系统垂直堆栈。每个元素都基于其下方的元素构建，最终得到的就是能够创建的 Mashup。Mashup 位于生态系统顶部，但只有在生态系统的其他元素均已就位的情况下才能获得。

　　图 3. 垂直 Mashup 生态系统堆栈
 
　　Mashup

　　Mashup 是一种环境应用程序，由进行了连接以创建集成体验的两个或更多独立组件组成。这方面的一个例子是 zillow.com，此网站将给定位置的房地产的地方税收信息（组件 A）与相同位置的地图（组件 B）集成，以便查看地图上特定区域内的所有房地产估算税值（新集成体验）。最初的环境应用程序主要是 shell 和 Perl 脚本，供开发人员用于在出现环境需求时以低成本方式快速地处理这些需求。不过，这些技术需要开发人员技能，不能满足利用业务用户技能的需求。不过，既然有办法发展 SOA 和让服务拥有外观，就为采用 Mashup 生态系统打好了基础，以便支持用户以可视的方式采用 Mashup 的形式开发环境应用程序。Mashup 只是环境应用程序的一种形式，就像 SOAP Web 服务只是一种实现 SOA 的方式一样。由于 Mashup 目前在 Web 上的广泛应用，因此这个方法是目前最流行的创建环境应用程序的方法。

　　Mashup marker

　　mashup maker 是用于运行和创建 Mashup 的组装环境。用户可通过其将公开提供的信息和服务与公司的内部私有信息和服务组合在一起，从而高效地以可视方式组装 Mashup。然后用户可以采用可视的方式操作和集成该内容，这些内容可以为静态内容（如网页）或动态内容（如 SOAP 或代表性状态传输（Representational State Transfer，REST）服务或 RSS Feed）。QEDWiki 是 IBM Mashup Starter Kit内包含的一个 Mashup marker。

　　Mashup maker 允许快速地以可视方式组装 Mashup，因为其中提供了小部件 集合，小部件是提供对一个或多个服务或内容的访问（通常为粗粒度）的软件组件（在本文中，内容 与信息 等效）。小部件的设计趋向于关注使用和自定义，以确保具有非常好的灵活性，因为 Web 2.0 的基本原则之一就是不能对内容以后的使用方式进行预计。小部件可以为可视的（呈现可视内容，如图标）或非可视的（提供某种形式的功能或对服务的访问）。通过 Mashup maker，可以将小部件从选择面板拖动到画布上，而小部件属性可以采用可视方式进行访问，并用于将各个小部件之间的输入和输出联系起来，从而最终创建 Mashup。

　　为了有足够的小部件来实现 Mashup 的组装，需要有可用性较广的数据服务接口来让小部件表示。数据服务接口 是一个通用术语，用于描述服务提供者提供的对其内容（希望在 Mashup 中使用或提供的信息）的访问的技术方法——通常通过 Feed、REST、SOAP/Web 服务描述语言（Web Services Description Language，WSDL）、Asynchronous JavaScript + XML (Ajax) 或 XML 远程过程调用（XML Remote Procedure Calls，XML-RPC）。Mashup Hub 是一个 Feed 管理服务器，提供很多强大的方式来向 Mashup 提供内容访问。Mashup Hub 包含在 IBM Mashup Starter Kit 中。

　　在 Mashup 生态系统中构建环境应用程序

　　Mashup 生态系统就位后，可以使用组装、连接与共享 (assemble, wire, and share) 模型来通过 Mashup marker 构建环境应用程序。下面让我们详细讨论一下每个操作：

　　组装：企业可以创建 Mashup maker 可访问的小部件目录。此目录包括所有内部创建的小部件和可能在给定业务领域使用的外部提供的小部件。这样用户就能够在构建 Mashup 的过程中快速查找和使用所需的服务和内容了。
　　连接：组装人员使用服务目录中可用的服务并通过 Mashup maker 将其连接在一起，从而以可视化方式快速地构建 Mashup。例如，表单小部件可以放在页面上，以便用户输入数据。输入的这个数据可以连接到提供 Web 服务调用的小部件的输入，而此 Web 服务响应的输出可以连接到呈现可视显示的小部件。
　　共享：组装人员随后共享 Mashup，将其公开提供，以供知识员工（knowledge worker）使用，从而就可以采用社区机制了。

　　此过程中有三个不同的角色：

　　Mashup 支持人员：Mashup 支持人员编写小部件并将其添加到目录。他们与组装人员沟通，以对其需求进行预计并主动或根据反馈添加恰当的服务。通常由 IT 部门的个人或具有编写软件所需的足够技术技能的人员担任此角色。
　　Mashup 组装人员：通常为不是非编程人员的业务部门用户或主题专家。Mashup 组装人员通过将 Mashup 支持人员创建的 Mashup 可使用的内容连接在一起构建 Mashup。
　　知识员工：这是将应用程序用于其预期用途的社区，还将在应用程序上应用社区机制（如评分和评论），以提供反馈，以便在下个迭代改进应用程序。

　　各个角色在模型各个阶段的责任如下图中所示。

　　图 4. 组装、连接与共享模型
 
　　是什么让 Mashup 生态系统如此有效？

　　首先，由于行业在关键技术标准化（如 SOAP、REST 和 Ajax）方面有长足进步，我们看到了 SOA 采用的大幅度增加（网络上和企业内）。这就让相应的技术达到了临界量，使得通过一个 URL 就可以得到的基于 Web 的可重用 API 和 Mashup 大幅度增加。由于这样，希望使用这个模型开发应用程序的人员可以使用的内容、数据和服务的数量以前所未有的速度猛增。时机已经成熟。

　　其次，这是极为易于使用的编程模型。其进入壁垒非常低，因为业务用户和高级用户中的大部分人都已经熟悉基于 Internet 的应用程序（和 PHP 之类的简单脚本语言），能够进行编写 Excel 宏之类的任务。

　　最后，今天在 Internet 上已经广泛流行的协作机制对使用此模型进行快速应用程序开发起到了促进作用。

　　结束语

　　在本文中，我们了解到，由于业务协作的短时性本质，使用现有应用程序开发流程和方法会导致较低的 ROI。而且，我们还了解到，通过在 Mashup 生态系统内利用业务用户和高级用户的领域特定的与技术相关的技能，可以让用户以可视的方式快速地组装环境应用程序，从而提供更好的 ROI。本系列的下一篇文章将讨论 IBM Mashup Starter Kit 以及可以如何使用它来构建 Mashup。