传统的MVC对于单个应用来说非常成熟，这是实践中证明的。对于大多数独立的应用和系统来说MVC很胜任。
----传统技术和架构的合理性。
然而，当企业中的应用规模不断扩大，从几个到几十个甚至上百个的时候，靠若干MVC架构的不断叠加能够构造出一个适合企业级的架构么？所以才出现了Portal这样的新技术来迎接这样的挑战，但是Portal的关注点更靠近与展现端，在底端通讯方面不能给出更好的答案。所谓架构是要一套整体解决方案，这样的架构所要解决的问题简而言之就是两个特点：数目或规模大、异构应用交互。
----这是WebService的由来。
WSDL 在增强应用之间的可连接性以及互操作性方面迈出了一大步。然而，WSDL只关注了服务接口，它并不提供描述一个服务所依赖的其它服务，以及这个服务所需要使用的配置策略和服务之间的依赖关系。
单独通过WSDL 很难实现服务之间的组合调用。
SCA比WSDL走的更远的方面是定义了一个服务组件模型以及一个服务组装模型。
服务模型提供了比WSDL更多的功能，它允许服务开发者不单定义服务的接口而且还可以定义 这个服务和其他服务的依赖关系，以及这些交互（事务，安全，以及可靠 传输）之间的策略还有服务所可能提供的配置功能。
----这是SCA的由来。
过去我们所采用的技术中，不管是.NET也好，J2EE也好，它们都有基于自身平台下的规范，比如在J2EE环境下，我们就会通过JDBC、Entity Bean这样的方式访问数据库或者其它数据源;而在.NET下同样有类似ADO这样的方式来访问各种不同的数据源。
这里面的问题在于，平台透露了太多的技术细节，程序员需要了解很多相关的内容，比如他需要创建一个JDBC或ODBC的数据源，再利用这些规范所提供出来的编程接口来想办法得到数据源中的数据，为达成这个目标，程序员还需要去做对象-关系映射，以实现对象到关系数据库或者与之相反的数据转换。
目前有一些技术可以用来解决这些问题，比如前段时间在Java社群中一直都非常流行的Hibernate等，诸如此类的方法和工具很多，他们都是用来协助程序员处理上述工作的。
但无论如何，你都无法逃避地要看到很多这些方法中非常底层的技术细节，而且，程序员需要学习所有这些不同的技术，了解它们适应于什么情况，处理各种情况下的不同技术细节。
事实上，程序员需要抽象层次更高的东西，比如业务数据对象(Business Object)以及它内部各种细粒度数据对象之间的关联，这是可以用一致、通用的方式来表示和操作的。有了抽象层次更高的模型，程序员就可以通用的方式来定义和访问业务数据，从而以统一的方式来描述和访问不同的数据源，降低对程序员技能的要求，提高生产率，更容易在不同的应用环境交换。
这样，不管是Java或者C++语言描述下，程序员都不必去了解平台上的技术细节，用一个XML Schema描述这样的通用、简单的的业务数据模型，然后在运行将对象持久化到你的关系数据库、XML或者其它数据源中。
----这是SDO的由来。
SOA提供了一种很好的改变现有业务流程模式的途径，成功实施SOA项目的关键在于分析重点、减低风险，给出企业真正需要的功能模块。本质上讲，SOA并不是一种新技术，它仅仅是一种系统设计/规划模式，甚至可以说，只是一种现有业务流程重组转换模式。
更直接地说，有一种需求变得越来越明显：业务需要集成系统，并允许消费者利用基于标准的方法访问服务。
----SOA本义
简单的讲，SOA就是将现有的一些功能模块打包成独立的程序包，命名为“服务”模块。对于这些服务模块，需要对其接口进行良好定义，使得其他的应用系统可以使用“拿来主义”，方便的使用这些服务模块。通过创建服务模块库，将所建立的模块集中到模块库中，这样，利用库中的服务模块，可以方便的构建出所需要的应用系统，
面向服务的体系结构本质上来说是一种具有特殊性质的体系结构，它由具有互操作性和位置透明的组件集成构建并互连而成。
基于SOA的企业系统架构通常都是在现有系统架构投资的基础上发展起来的，我们并不需要彻底重新开发全部的子系统; SOA可以通过利用当前系统已有的资源(开发人员、软件语言、硬件平台、数据库和应用程序)来重复利用系统中现有的系统和资源。
---- SOA和现实及技术的关系
软件企业的产品开发和营销必须两眼紧盯着市场需求，产品开发要和市场人员紧密结合，找到关键客户普遍而又重要的共性问题。产品源于市场，服务于市场，研究技术是为了更好地解决客户的问题。
技术是手段，附以方法论，形成BEST PRATICE，驱使的目标或目的才是关键
目前国内大肆渲染的soa(sca,sdo)等，无非是手段，真正能派上用场的场合确实有，但是是大多鼓吹或爱好者所罕遇的。
研究技术是为了更好的解决客户的问题，这便是技术的目的！
-----技术的目的