协议转换组件
这里谈到的协议转换指的是对于请求和返回的协议，TOP可以做适配，来满足服务调用者和服务发布者之间在服务协议失配的情况下还是能够正常通信。当前支持JSON,XML,Atom,二进制协议之间的转换，当然转换描述文档将会配置在TOP。同时返回的数据内容，也可以通过协议转换，返回给客户端常规的xml或者json类型的数据。
服务流程化组件
服务流程化指的是将离散的服务通过流程描述文档能够虚拟的串联成为一个新的服务，这样更加适合调用者使用，同时将服务的一些内部逻辑隐藏起来。这很类似于SOA中的服务编排，同时也可以参看Yahoo的Pipe，那就是一种典型的服务串联，同时还提供了方便的界面直接交由用户通过手动拖拉的方式来使用服务串联。
服务流程化最大的特点就是将不同类型的服务能够根据业务场景的需求组合成简单的流程性服务，极大降低了服务开发者由于对服务流程不熟悉而犯错的几率，同时也为服务开发者提高了开发效率。
计费组件
当前计费模型主要是按流量收费和插件分成两种模式，因此计费组件还比较简单，当前就是基于日志做分析，未来会考虑在流量上的各种特殊模式（打包，优惠等等）。
容器组件（TBML）
产生原因：
· 数据隐私性
· 开发便利性
· 业务升级透明化
· 监控全局化
· 开发标准化
作用：
· 数据操作可控，保护终端用户隐私（结合cookie和标签，控制ISV业务数据操作尺度，提高数据安全性）
· 提供标准业务流程标签，简化开发者对于业务流程理解过程。
· 标签化接口方式，完成数据获取和页面渲染，后台业务升级对ISV透明化。
· 标签获取客户端信息，将监控扩展到整个业务请求过程。制定行业化标签库，形成统一开发标准。
TBML首先需要根据业务需求及场景定义出对应的标签库，也就是制定Taobao的标签标准，最简单的获取用户信息标签，到最复杂的业务操作流程标签都会成为标签库中的一部分。同时在服务端需要有解释引擎来翻译标签，解释引擎一方面需要去了解标签内容和含义，同时需要请求后台多个API，串联成为流程化的服务，从应用的输入，得到最后的输出，当然期间也需要处理异常的情况。最后还需要关注的就是安全控制，在交验标签传递来的数据时，需要对数据作完整性及合法性的交验，防止通过标签数据的特殊性攻击后台服务接口。
TBQL组件
TBQL其实是一种服务调用的方式，也是通过一种程序员和开发者习惯的方式，将对资源的REST请求转换成一种类似QL的请求，对于面向资源性的架构体系来说是十分有利的。同时对于API来说，使用者会更加自然的去采用连接和过滤得方式得到需要的数据。
QL解释引擎负责对于TBQL的翻译工作，数据存储的MetaData保存在数据库中，可以指导QL解释引擎翻译。需要支持不同数据来源的连接和过滤，在获得结果以后需要做格式转换返回给服务调用者（通常就是xml）。与容器一样，需要着重考虑安全性问题，对于传统的SQL注入就是典型攻击QL系统的案例，需要谨慎处理解析中对于字符的翻译工作。在流程中出现异常，需要制定策略来判断是否直接返回错误还是支持部分容错。
TOPID组件
TOPID组件有点类似于Facebook的Connect，需要在淘宝和淘宝的合作开发者之间建立起双向的用户互通的标准和流程，同时也为服务互通打好基础，毕竟业务的互动需要基于可以互通的用户体系。
总结
以上仅仅只是简单的罗列了一下TOP技术体系架构中的一些组件化的内容，同时在这些组件的背后有着更多的基础性项目的支持，例如统一配置中心对于系统动态扩容的支持，分布式缓存对于监控告警的支持，分布式文件系统对于海量小文件保存和获取的支持等等。同时以上每一个模块都有各自特殊的定制和优化，例如路由模块就需要有Lazy的服务参数解析模式来提高处理性能，安全体系中需要有动态密钥机制来保证高安全性等等。
TOP从萌芽走向成熟，不论从技术架构还是商业规划都处于不断摸索和改进的过程，当前的技术体系仅仅是现阶段的一个需求缩影，未来在市场不断成熟，开发者不断介入和反馈的情况下，TOP会走得更快更远，TOP的“兵器谱”会更加丰富，更加出彩。
