SOA驱动企业Mashups方案
说实话，SOA就是一个管道工程。当然，是一项耀眼而高效的管理工程。而那些一般业务人员（比如销售经理、销售主管、财务主管或客户服务代表）却不会去关心这些东西。实际上，如果你仔细而全面地考虑一下，他们可能并不希望有什么变化：这些无法看到、悄悄发生着的变化。这些业务人员可能更喜欢这项管道工程里的大理石地板、精致的镶木门窗和漂亮的黄铜设备。换句话说，他们喜欢的是管道工程的外表。
SOA的ROI也是很难甚至无法定义和衡量的。虽然专家们对一些问题（比如SOA的ROI的重要性、如何计算SOA的ROI等）已经产生了分歧，但他们好像都同意一点：企业对SOA的支持完全取决于SOA对总体业务的描述——更多的成长机会、利益、以及诸如此类让人向往的好东西。这也是企业Mashups可以极大地提高SOA的ROI的领域。
企业Mashups把SOA从广泛意义的IT拖到了终端用户的桌面上。这不仅是高度可视化的，并且是用户驱动的，它能够给IT一种新的方式提高晦涩的SOA的投资回报率，让用户与SOA产生利益关系，使IT可以更专心地解决最前端的业务需求。但是IT与业务一直以来就没有很多共同协作的经验（特别是像这种动态领域），因此SOA驱动的Mashups的第一课很简单：为与SOA驱动的Mashups相关的业务与IT部门之间的环境变化做好准备。Mashups并不是意味着IT工作的结束，但它确实排斥一种很不相同的职位。
Mashups改变SOA的实质
除了人力因素，SOA与混合应该之间还有许多非常实际的互相促进的关系，能够帮助你设计更好的SOA方案。这些关系都暗示着不同的SOA架构信息与经验。其中最重要的包括：
1. 虚拟化：Mashups有助于从那些还没有被“SOA化”的资源中创建规范化的“虚拟”服务。众所周知SOA是一项可能需要多年才能完成的任务。直到完美的SOA正式完成之前，迅速、标准的服务都可以帮助用户更早地起步。
2. 适当的规模：混合服务可以让用户“适当地”调整服务的粒度。现在IT不用再去猜、研究、或分析一个服务提供的数据是否“过于专业、过于广泛、过时或者不着边际”了。
3. 协作：混合服务让用户可以分享他们组合的服务，让他们成为服务创建网络的一部分。这等于给IT多了个帮手。
4. 可视化：Mashups让用户可以把SOA形象化为图像、图表、表格和对应图。这样就不必等待动作缓慢的企业门户为用户定制可视化的服务，每个用户都可以按喜欢的方式自己动手。
5. 微观组合：Mashups让用户能够添加企业外的数据。现在的SOA主要还是面向内部的。但是用户经常需要在他们的工作中加入外部数据。Mashups可以使用户在使用数据服务时无视数据服务的实际位置。
在Mashups中利用SOA的安全性
SOA与Mashups之间的互相促进只是个开始。Mashups还必须能够在有着大型、复杂的安全与治理的企业环境下生存。根据我们前面的企业Mashups定义和相互关系模式，我们可以总结出以下重要的安全与治理要求：
* 桥接：要真正地利用持续增多的SOA服务，你肯定希望有一个简单易用的能够实现SOA注册/信息库与企业Mashups之间的SOA服务信息流通的方式。千万不要说你没有SOA注册/信息库。
* 传输验证信息：你的企业Mashups必须具有能够管理用户验证的特性，能将验证书传送到正确的验证系统以及所有混合的服务。因此，在你的企业Mashups方案中必须让Mashups创建者指明所希望的验证格式。并且所有这些操作都必须在混合内部或外部服务时以统一、无缝的方式进行。
* 渐进式的标准化和部署：企业混合必须以源服务要求的方式传送验证信息。而且这种安全/验证的传输机制必须嵌入到系统架构中，因为这里的标准很薄弱。在四种服务类型中，只有JDBC/ODBC的数据库和WSDL（WS-SecurityPolicy）有一定的“标准”验证格式，虽然使用范围还不是很广泛。因此你的企业Mashups必须有足够的灵活性来传输用户验证信息而不管服务提供商需要什么格式。当然，或许你可以为新的标准或者用户格式预留位置。
* 调节信息联合组合应用是可移植的，你必须让你的组合应用能够用于Web 1.0门户（比如BEA和Oracle Portal）、Web 2.0界面（比如Netvibes和Pageflakes）、或者下一代的iPhone。不管在什么环境下，每个组合应用构件必须拥有可移植的安全性与治理性。
满足这些安全性和治理性需求的工作不能通过事后的增补工作来完成。你必须主动去完成并且持之以恒。但是请记住：创新与安全性/治理并不是互相排斥的。实际上，你的SOA（及Mashups）安全性越高，用户就越能自由地利用这种强大的技术。
