所有数据层都通过webservice的可行性

    系统是新建设的 我们是负责网站方面的 客户希望我们把我们的数据库表放到公共数据库 然后由总集成 提供我们webservice的数据接口 也就是说我们的整个数据访问层都是建立在别人的webservice上（数据操作包括增删改查）  这样的解决方案 在安全性 性能 和 对我们项目以后的扩展性 可实行性是否高 如果要驳倒那么理由是是什么  希望各位大牛给予建议
   
     数据层采用webservice统一调用的缺点：
性能：
数据层接口是系统开发最频繁的调用层，webservie的接口调用是一种开销很大的操作， 即使内网的调用也要在0.4s左右的响应速度，如果接口数据的交互量大那么效率更加低下，如果在数据层提供webservice接口的话那么，那么会对网站的整体性能产生很大的影响。
   
安全性：
数据层webservice层所提供的数据访问是没有判逻辑性和识别性的，它无法判别具体的接口可供哪些子系统调用，而且子系统具备对数据库进行恶意攻击的能力，此时集成需对所有的子功能的服务进行安全测试（其中可能很多的服务都是相同功能，测试也就会重复劳动）

扩展性：
游客对web网站进行一次访问时，可能会对webservice的数据层产生2-3次的请求应答，也就是说基于现有的数据层webservice层架构，webservice服务器所受到的压力会是web应用服务器压力的2-3倍，那么如果今后网站访问量剧增，web服务器如果要做3台机器的集群（还不包括手机wap等子功能），则webservice服务器将需要做6台机器的集群才能应付。

维护性：
现有的webservice接口是一些简单的数据接口，只不过封装了一些单表简单的增删改查，基于现有的架构各个子系统需要自己调用webservice的数据接口来编写自身的服务接口，不同的子系统可能会有相同功能的服务service接口，也就是说在整个大系统的环境下相同功能的服务接口可能会有多个版本，服务商对数据表的理解深浅可能会造成他们自身服务接口的优良参差不齐，最终可能导致数据输出出错或不一致。
如果在现有的数据库结构产生变化（比如一张表分离成2张表），那么对于现有的结构，对外提供的数据层将会改变，那么所有的子功能都将修改自己service服务层，这样将牵一发而动全身，是很不符合设计原则的。（在后期的维护中也存在这样的情况，可能一个改变需要所有的子系统都要修改）

 对外统一开放接口基于服务层service的优势
Soa ：是面向服务service的架构
集成应该是基于服务的整合，对外统一的接口定义应该是基于服务层（业务层）


    不管是用户，企业，各种机关部门，子系统开发商（统称使用者），集成平台对他们开放的其实都应该是一套统一的不重复的服务接口规范，服务接口就是一个可以在使用者不考虑数据库结构的情况下得到的一个功能，也就是服务（这个服务甚至可以根本和数据库没有交互：比如计算器服务，当然这样的服务子系统自己也可以提供，但是如果它自己提供，则我们对它的正确性和服务今后的维护和升级不做保障），服务对使用者来说可能是注册，可能是查询信息，可能是删除信息，可能是买一样东西，对使用者来说他所要知道的就是他使用一个服务完成一件确切的事情，服务接口对外是统一的，但是使用者的不同身份权限会限制到它到底能使用多少服务。
    服务分为公共服务（对所有使用者提供，可通过公网的webservice调用：天气预报等），内部服务（提供子开发商进行子功能的开发，例如我们的网站，手机网站都可以挑选集成平台提供的服务来进行2次开发整合，同时集成平台对我们所使用的服务进行性能，安全，升级等进行多方面的保障）
    性能：将对webservice的调用次数降低到最低，将对webservice服务器的压力降低到了最小，大大减少了服务器的压力
    安全：对不同使用者开放的服务是可限制的，并且是可控的（可以开关使用者的使用权限，可以在集成平台进行服务级别的日志记录）
可维护性：当内部数据或业务逻辑发生改变时，不需要改变接口，只需要改变服务的具体实现，子系统根本不需要做任何修改就能达到同步和统一，系统出问题也缩短了错误寻找时间和测试时间（只要捕捉到服务层日志就可以轻松锁定发生错误的子开发商）。