1. N-层应用组件化设计原则
        三层客户/服务器设计包含三个逻辑的和物理的应用代码组织。它们是：
•        表示层(和相关的表达业务层)
•        组件层(也称为应用层或业务层)
•        数据层
        应用逻辑经过这些层次的分离使应用得实现松耦合的概念，松耦合使得应用逻辑被分割为 tuxedo服务，这些服务可以根据系统当前或未来的分布需求，如用户数、容量和数据分布的需求进行部署。

1.1 表示层
        客户机上的表示层包括两个子层：
•        表示层
•        表示业务逻辑层
表示层提供应用的用户交互接口，即主要是图形化用户界面，这一层不应该包含任何业务规则或数据访问。
        表示业务逻辑层，用于为表示层提供一个业务逻辑抽象。表示业务逻辑层只包含需要通过访问组件层完成的业务逻辑，或完成本地业务决策逻辑。
        表示层与表示业务逻辑层的划分能够提供：
•        表示层与表示业务逻辑层划分清晰
•        为表示层提供业务抽象
•        在表示业务逻辑层实现面向对象的运行方式，而不影响图形用户界面的程序逻辑和开发环境。
•        在所以的GUI逻辑实现中可访问可重用的业务逻辑。
•        能够适应GUI开发工具，开发语言和操作系统。
注意：不要把交易控制置于表示业务逻辑层，把它们组织在组件层。

1.2 组件(或应用)层
1.2.1 组件框架原则        
        应用层从面向对象的观点来看通常是指组件层。组件层只包含业务逻辑，在这一层中不应该包含任何GUI或数据库访问方法(SQL，存储过程)。数据访问通过数据层服务访问实现。组件层包括所有的应用业务规则，而不依赖于数据层和表示层。
        组件体现在 tuxedo应用系统中就是服务。组件根据请求者的请求运行，并可请求必要的数据层消息服务。组件可以调用其它组件，并自动成为全局交易的一个组成部分。
        各层之间的通讯由TUXEDO消息传输机制来实现。采用XA接口，所有与其它组件或数据层的通讯均自动包含在全局交易中。
        在组件层进行交易语义控制。不要在表示层或数据层实现交易语义控制。

1.2 组件(或应用)层
1.2.1 组件框架原则        
        应用层从面向对象的观点来看通常是指组件层。组件层只包含业务逻辑，在这一层中不应该包含任何GUI或数据库访问方法(SQL，存储过程)。数据访问通过数据层服务访问实现。组件层包括所有的应用业务规则，而不依赖于数据层和表示层。
        组件体现在TUXEDO应用系统中就是服务。组件根据请求者的请求运行，并可请求必要的数据层消息服务。组件可以调用其它组件，并自动成为全局交易的一个组成部分。
        各层之间的通讯由TUXEDO消息传输机制来实现。采用XA接口，所有与其它组件或数据层的通讯均自动包含在全局交易中。
        在组件层进行交易语义控制。不要在表示层或数据层实现交易语义控制。
1.2.2应用服务设计原则：
•        信息隐藏原则：定义服务以及从客户到服务的数据流尽可能独立于服务的实现。服务程序中不要嵌入客户机有关数据采集技术等信息。反之，客户机也不应该意识到服务器程序的实现细节，如数据库结构以及记录格式。
•        分层服务原则：尽可能每个服务只完成一项任务，而不是多项任务。不要在一个服务函数中包含过多或过少的功能。努力定义一组简单服务来实现业务的基本功能，通过这组服务的组合，可以实现复杂的应用服务功能。
•        业务对象原则：围绕业务对象设计并使用服务功能。以一组相关的对象或公共对象将服务组织成为服务进程。

1.3 数据层
        数据层包括所有访问数据库或信息库的所有逻辑。这层包一包括数据存取方法，如SQL、存储过程、ISAM文件存取以及与数据存取相关的业务逻辑。
        组件层与数据层服务的划分为TUXEDO应用管理员在应用系统部署阶段提供了极大的灵活性。而在开发阶段对数据层服务、组件层服务和GUI业务层的重用，必须给予足够的重视。

1.4 N-层组件部署原则
        应用部署的灵活性对应用管理员非常重要。在高度松耦合的N层组件化系统结构下，可以依据系统生产环境，如用户数、交易容量、数据的分布以及外部系统经互联网对应用的访问或企业其它应用的访问等要求，灵活改变应用的结构。