关于我们的队名：AOS

Our team name AOS stands for Architecture-On-Services. 

这是一个很有意思的名字： SOA 是“面向服务的架构”，而 AOS 的意思是“基于服务进行架构设计”；SOA 提倡一种新的基于服务的架构方式，而 AOS 是说“我们要在服务的基础上进行架构设计”； SOA 强调的是我们要以一种新的观点（基于服务的观点）看待软件系统的设计问题，而 AOS 强调我们进行软件系统设计的基本单位是服务（On-Services）。

其实，不论是 SOA 还是 AOS，强调的都是两个概念： Services 和 Architecture。 与 SOA/AOS 相对的是早期的一些开发模型，如OO模型。Object-Oriented 中的 “Object” 和 Services-Oriented 中的“Services” 有很大的区别，如交互方式、依赖关系、可配置性等等。 这些区别导致了生成的系统在可扩展性、可配置性，以及当业务需求发生变化时的适应能力上有着很大的差别。 虽然在 OO 模型中可以通过一些巧妙的设计模式（Pattern）来获取适应需求变化的能力，但这些模式（或者说“开发经验”）实际上只能在一定程度上，一定范围内对实际存在的这些“因需求变化而导致的问题”进行处理或控制。  比如我们可以在一个企业软件中应用设计模式来使这个系统获取一定程度的可扩展性，使得当有新的需求（如新的业务流程）出现时，我们仅需付出少量的额外劳动力。但我们却很难找到一种所谓的模式，来解决“对多个系统进行整合”的需求。当然，这里我们假设这些独立的系统并不是“同质”（相同的架构技术，如J2EE/.NET）的。 但是，SOA 的基于“服务”的架构模型却可以解决此类整合需求。 SOA 的解决之道在于，将系统对外提供的功能包装成“服务”，而这里的“服务”实际上对系统功能更高层次的抽象和描述。这样，即使是两个毫不相干的系统，它们只要各自遵守调用这些服务一些基本约定，就可以在不必了解“对方的服务是如何实现”的前提下，相互进行服务调用。

以上的这些内容只是由我们的队名（AOS）引发出来的对SOA的一些思考，其中不免有很多不准确或不恰当的观点，还希望大家多多指教。 我相信，随着这次比赛的逐步推进，随着我们团队讨论的逐步深入，随着我们的对“凤凰公司”整合需求的逐步细化，我们对 SOA 会有更加深入的理解。