您一定知道SOA是什么（这只是我根据您目前在访问该网站所做的假设），但您知道什么是ABOS吗？简而言之，ABOS是指一堆服务（A Bunch Of Services）——一堆互相重叠而互不兼容的服务，拿来就实施，缺少更加开阔的想法，而仅为满足某一个项目的需要。换句话说，当您将Web服务技术应用于筒仓项目时，ABOS就产生了。

　　那么，是什么导致SOA变成ABOS的呢？当您暗中破坏贵公司的SOA举措时，请记住下面的5个SOA反常规做法（或称之为ABOS“最差劲做法”，如果您愿意的话）： 

　　1. 只考虑自己，而不考虑别人：导致ABOS服务产生的最好方法之一，就是闭上眼睛不管他人，然后就开始编码。不关心其他的项目，不考虑如果多花一点时间再支持一个参数或是一项操作，就可以让别人使用您的服务的现实。毕竟，您要赶在最后期限前完成工作，而如果停止手头的工作去帮助别人则意味着给自己带来更多的麻烦。那么那些建筑师呢？他们也因为业务架构和路线问题而一直在打扰您。那么，如果您不理会他们到足够久，他们自然会知趣的离开。  

　　2. 只是“搞定了！”（台词盗用，在这里向《王牌特派员》致歉）：这些声音都是设计审查、代码审查、测试计划审查，等等等等发出的噪声。而且众所周知，WSDL是完全的自文档化，任何人都无法读取这种“谨小慎微”的文档，所以您当然也不想费工夫去试着编写文档——那将是多么浪费时间的一件事情。  

　　3. 向后兼容性是留给那些胆小的：如果别人想用您的Web服务，他们就要自己承担风险。如果您改变操作需要重新部署时，那么问题不在于您，毕竟最初不是您请他们来使用您的服务的。如果您需要改变它，那就完全是您自己的事情，与外人无关（参照最差劲做法1）。 

　　4. 不向任何人透露您的服务，因为他们实际上可能会试图使用您的服务：这个最差劲的做法是最差劲做法3的一个必然结果——如果您对您的服务秘而不宣，那么就会避免许多将会出现的麻烦。服务共享、“即部署即能从任何地方调用”、以及其他的事情……那些家伙从来不用担心要讨好您的老板——这全是为了使您的项目看起来好看。如果其他项目看起来有点差，这是因为他们不得不自己编写服务，而如果他们了解您的服务的话，这本可以避免，那么一切就完美了——所以，我们在优先次序上调高了一或两个等级！

　　5. 最后一点，但并不是最不重要的一点，使用及忘记：，有一个项目确实成功找到、掌握并/或使用了您的服务中的一个（经过与最差劲做法4、2、1的斗争，他们最终实现了这一点），当然我们不希望这是事实，对吧？但终究不久他们就会发现您部署了新的代码拾取（再次参照最差劲做法3）。因为一堆程序停止运行，调页程序随之停止，在周日凌晨2点听到这一消息将是多么兴奋。您现在又多了一个交战胜利的故事，又可以在下周与人聊天中娓娓道来（但鉴于您公司的运行方式，将会出现大量的竞争）。

　　从较为严肃的角度，希望你能了解我粗劣的幽默（Steve Martin不用担心我会与他竞争，这是肯定的！）。那些重视SOA的公司应该通过设计时存储库/注册表，考虑和规划架构的指导及管理，以及服务的跨版本兼容性和传递/溯源性。仅仅技术堆栈正确还不足够——围绕公司的构建实现企业级SOA的问题越大（在许多方面就越难），实现企业级SOA的目的在于实现IT内的跨项目联盟，以及购买IT的公司与使IT工作的公司之间的业务/IT联盟。

　　关于作者

　　Brent Carlson是LogicLibrary公司的技术副总裁和创始人之一。他曾在IBM公司工作17年，并且因领导了IBM几个关键举措而广为人知。最近，他被任命为WebSphere Business Components项目的第一设计师，为基于EJB的组件开发产品提供整体的技术方向支持。