规则二：区分Service的不同类型：Business和Data Access
在商业逻辑层中的Service可以进一步细分成负责完成商业逻辑的Business Service和负责数据访问的Data Access Service两种类型。
规则三：同一个Server内的Service都访问相同的资源
规则四：Request/Response类型的Service要和会话Service分开在不同的Server中
在Tuxedo中，一个Server要么支持Request/Response类型的Service，要么支持会话方式的Service，具体是在配置文件中*SERVER一节中CONV=Y或者N来决定。会话方式和Request/Response方式是两种互斥的通讯方式。Request / Response 方式效率比较高，是使用最频繁的通讯类型。Tpcall/tpacall/tpforward都是Request/Response类型的API。会话方式适合大量的数据传输，但是它的代价是效率的下降。所以这两种类型的Service要分开放在不同的Server里面。
规则五：执行时间相似的Service放在同一个Server里面
在一个典型的Tuxedo应用环境中，可能有成百上千的Service，这些Service的执行时间显然是不同的。对于单线程的Server来说，虽然它可能有多个Service，但是这些 Service的执行是串行的。如果某个Server拥有两个Service，A和B。A的执行时间是100ms，B的执行时间是1000ms，也就是说执行一次B的时间可以执行十次A。那么当B在执行的时候，可能会有十个A在队列里面等待。这种情况会急剧降低该Server处理Service的吞吐率。因为，很自然的一个原则是把执行时间相似的Service放在同一个Server里面。
规则六：具有相同执行频度的Service放在同一个Server里面
在一个典型的Tuxedo应用系统中，并不是所有的Service的执行频率都是相同的。可能一些Service被频繁的执行，而另外一些Service只是偶尔才被执行几次。
规则七：Service的命名要科学
在一个大型的Tuxedo系统中，Service的数目可能达到上千个。
规则八：避免死锁的情况发生
在Tuxedo中的死锁情况有两种，第一种是一个Server中的Service A去调用同在一个Server中的Service B。这种死锁发生的原因是，对于单线程的Server来说，它其中的Service是串行执行的。Service A去调用Service B的时候，Service A还没有执行完，它等待Service B的返回结果。 但是Service B不能执行，因为该Server还处于执行Service A的状态。最终导致Service A超时而出错。

原载于：联动北方
全文：http://bbs.landingbj.com/t-0-248696-1.html