摘要：
- OBA是什么
- OBA客户端技术
- OBA服务端技术
正文：
OBA是Office Business Application的缩写，其致力于消除企业中的后端业务系统与企业员工之间的鸿沟。由于企业员工最常使用的软件是Microsoft Office，而OBA则使Office软件能够直接与企业后端系统之间进行互联互通，企业员工可以在不离开自己熟悉的界面的情况下，访问企业商业数据，参与业务流程，完成业务操作。这样不但极大的减少了企业员工为了访问复杂业务系统所耗费的时间，也降低了实施业务系统的成本与费用。
从概念上看，OBA确实为企业应用描述了一副美好的画卷。接下来让我们透过概念，梳理一下OBA的实质到底是啥。我们先来看下面这幅图：
图表 1
其实OBA的解决方案包括了客户端技术和服务端技术。由上图可以看出，客户端的平台就是Office，服务端还是基于Office SharePoint Server。OBA客户端与企业应用的整合有两种渠道，一种是通过直接调用企业应用WebService，还有一种是由SharePoint与企业应用整合后再由Office与SharePoint进行直连。第一种方法要求企业应用最好是基于SOA的架构，这样就可以很方便的实现Office与LOB的整合。后者利用了Office与SharePoint之间天然的联系，由SharePoint通过BDC等技术与LOB整合，这样就可以支持更多的旧系统，而且SharePoint提供了很好的安全、性能及可靠性，提供了一个很好的可扩展的平台来支撑OBA应用。
前面所说的连接方式有些抽象，让我们看看客户端要如何在界面里操作业务系统。OBA客户端技术主要有VSTO和Open XML。通过VSTO，我们可以为Office增加Ribbon（也就是下图左上角的按钮区域）和Task Pane（右下角的任务窗格）。这样我们就可以在Ribbon中触发业务操作，在任务窗格中收集输入，并触发后端应用。说到这，Open XML就该登场了。Open XML的内容三言两语也说不清，在这大伙只要明白Word、Excel、PowerPoint这三种文档格式都是通过Open XML来描述的，并使用了Zip格式进行压缩。这意味着什么呢，意味着只要能操作XML和Zip，就可以操作这三种格式的文档。以前我们可以通过VBA来操作Office文档，不过那些都是二进制的文档，而且微软是没有公开这些文档的格式。Open XML却是个公开的标准，所以这为我们访问Office提供了极大的便利。在这举个实际些的例子。银行的客户经理写贷款申请时，可以通过OBA来访问后端信贷相关的系统，获取客户相关信息后填入预定义的文档中，客户经理需要做的就是在文档里写上各种自己收集的信息和建议了。所有的工作都在自己熟悉的Word里完成，是不是挺方便的！
图表 2
大伙看到这，是不是觉得OBA的客户端技术还是很方便的，似乎可以不需要什么服务端的东东了。确实，不需要借助Office SharePoint Server，OBA客户端就可以很方便的连接后端的应用了。可是作为一个企业级的Office应用，统一的用户认证，权限控制，性能和可靠性，工作流、企业搜索都是必不可少的。从这个角度来看，SharePoint在OBA解决方案中的核心地位还是有其必然性的。对于SharePoint本身的功能，在这我不想过多提到。我想在未来构建OA系统时，有些问题是需要重点关注的：
- SharePoint中的数据大部分是用List来保存，每个List由各种Field组合而成。这种设计主要是为了可以通过配置就构造一套基于SharePoint的应用来，相当灵活。带来的问题是与List和Field相关的表会变得相当庞大。所以初期的规划就要考虑好数据库的物理部署，对数据库的优化最好是提前做好。
- SharePoint自带的工作流总的说来就是个鸡肋。确实，非开发人员可以很直观的配置出一个工作流来，可是这个流程与SharePoint的耦合度很高，如果你想要实现工作流的监控和事后的分析，基本上是不可能的。
- SharePoint作为企业应用的粘合剂，更多的是取数据，数据展现（如Excel Service, Reporting Service, Web Part）；要想实现数据的增删改，就没有那么方便了。可以通过InfoPath表单来做，只是InfoPath表单数据都是XML格式，所以你还需要自己把XML转化成对象持久化到数据库。
图表 3
OBA的推出就是为了解决现实企业中Office文档与企业应用之间的鸿沟，而且目前的平台和开发工具已经可以很好的支持这一类型应用的开发。作为开发人员的你，是否准备好面对2007 Microsoft Office 这一重要的应用程序平台？！
