SOA业务价值重用和透明.docVIP

SOA业务价值重用和透明 　　作为Zapthink的《JustifyingFunding your soa project》白皮书的第二部分，此章重点讲述了SOA重用和透明的业务价值。可能我们对这两个概念早已耳熟能详，但是SOA到底是如何做到这些的呢，我想恐怕很少有人能够说的清楚。那就希望本篇能够带领读者深入地洞悉这其中的内涵。 　　 　　拓展现有应用的价值本质上就是资产重用的一种形式。对大多数企业来说，重用是实施SOA的主要动机。SOA也允许通过增加IT资产的重用来消除冗余，这种方式本质上是一种资产回报（ROA:Return On Asset）而并非简单的投资回报（ROI:Return On Investment）。而这种冗余通常是这样产生的:公司为了不同的目标，每次都花费巨资来建造不同的项目，而这些项目的基础却都完全相同。 　　例如，大多数公司在几十年前就建立了第一个客户数据库，但是今天，在实施CRM、ERP、企业门户和基于Web的系统时仍然需要再建造。只有当我们能够从服务中获取真正的重用性时，才能结束这些多余的、不必要的花费。而SOA能够帮助我们做到这些，使得企业能够建造一次服务，而多次使用。 　　 　　降低冗余度 　　 　　通过共享服务来消除冗余或许是SOA重用效益的最明显体现，重用长期以来一直是软件开发界追求的目标，但它的实现却远比人们想象的要困难。或许重用性的真正问题在于超越那些特殊的业务需求，对IT资产进行重新定义。如果定义不够清晰、准确，甚至不断变化，试想开发者如何能够开发出可供重用的资产呢？因此，如果对一个可供重用的资产不能进行具体的、可供操作的定义，重用根本不可能实现，而如果一定要开发者实现这种重用性的话，我想恐怕连他们自己也不知道什么时候能够完成。 　　在许多方面，重用不仅仅是资产建造者的问题，它也是资产利用者的问题。一个开发者可以为一项资产编出上千个版本，从而满足每一种可能的情况，但是到最后往往发现只有为数不多的几个能够被应用，甚至没有一个可以使用。因为尽管种类繁多，但是他们都无法满足一个特殊的或者特定的需求。所以，关键是让使用者去考虑重用性的问题，而不仅仅是开发者。 　　面向服务的新的魔咒就是广泛适用性的观念，不再是共享代码，服务使用者最终会共享服务。我们不会通过多次的拷贝和粘贴服务来为不同的目标提供不同的服务，同样我们也不会采取相同的方式来使用一项服务。通过在服务协议中涉及各种不同方面，而不是在底层代码中来这样做，我们可以建造一个共享的服务，它具备广泛的适用性可以应用到众多不同的流程和使用者中。而要实现这样的重用，需要仔细地对资产进行分类，还要在服务实现时对相关性进行分析。 　　如果一项服务负责提供客户数据，例如，12个不同客户需要此项服务能够用不同的方式来展示后台的数据，我们就会陷入重用的难题中，我们是该建造12项不同的服务和12项服务协议呢，还是利用一个具有可变性的协议来应对这些完全不同的需求。第一种情况违背了重用的目标，但是第二种情况下，一个单独的、过度复杂的协议又不够敏捷。那么一个单独的服务配合12个不同的协议则可以考虑，它既方便管理，又保持了敏捷。在这种方法下，我们只需管理12份协议，而不是12项服务，这就大大简化了管理工作。因此广泛的适用性取决于服务协议的管理。 　　如果人们不能够找到相应的服务或者不能理解如何使用这些服务，建立具有广泛适用性的服务仍然不能保证重用的实现。要想达到广泛的适用性，服务还必须可消费。可消费意味着人们可以实实在在地重用服务。因此对于可以使用的服务一定要有一个注册中心，这样用户就知道如何在这个中心中找到需要的服务了。可消费还需要对服务有足够多的信息，以便人们知道哪项服务是他们需要的，并且知道如何去使用他们。 　　SOA为重用提供一个实用的途径。但是，只有当事物是可伸缩的，并且易于发现和使用时，人们才会去重用，这是人类的天性。所以在建造服务时，更多地考虑广泛的适用性和可消费性，将会使重用变得更加简单。 　　 　　提升客户价值 　　 　　减少系统的冗余并不是重用的唯一用途，事实上，很多企业一直在努力重用良好的客户体验。可重用的、面向客户的服务结合客户喜爱的服务都有利于改善客户体验，并且有利于提升重要客户的价值。 　　例如，一家零售银行能够向客户提供存款、信用卡支付、财务管理等业务，同时这个大型银行的操作是在相互隔离的部门中进行的。典型的客户体验就是向银行的呼叫中心打电话，去咨询账户信息。但是在这样一个应用竖井中，客户如果希望通过信用卡号码来查询相应余额时，呼叫中心恐怕不能及时地回答，因为请求系统和处理系统是在不同的竖井中的。 　　其他大型的企业也会遇到类似的问题，因为他们最良好的客户信息被存在多个竖井当中。所以当服务于这些高端客