为期四天的Licensed ZapThink Architect课程中，最具挑战性的就是解释文档格式服务和与其具有显著差异的远程过程调用样式(RPC)相互作用这一部分。乍一看，服务形式(尤其是网络服务)的差异源于技术细节，但实际上这种差异强调了服务独立性和创建改变的基本结构原则。

　　此外创建改变是整个LZA课程的核心主题，因为商业灵活性是服务架构的主要商业推动因素。商业灵活性意味着为了寻求竞争优势而创建杠杆作用改变。因此，理解文档形式及其与服务独立性和创建改变的关系的真正内涵和理解文档形式在SOA中如何有着异曲同工之处。

　　文档形式和创建改变

　　为了ZapFlash的目的，我们将完成一个特殊例子。在该项实例中，设计者必须设计一个创建雇员服务即在公司的人力资源数据库建立一个基本的雇员记录。为了阐释创建这项服务寻求改变的需要，我们将描绘三个使用实例。第一个实例说明现在的要求。第二个说明从今往后三个月的要求，第三个说明接下来六个月的要求。我们先看前两个例子：

　　实例一（现在的要求），我们要求创建雇员服务建立一个雇员记录，该服务建立一个带有标识符的空雇员记录并返回一个产品序列号。通过与一个独立服务通话，我们将信息填入该雇员记录
　
　　实例二（三个月的实例）我们将一份写有我们对雇员感兴趣的信息文档发给创建雇员服务，服务把该信息填入一个新的雇员记录并为该雇员返回一个独特的产品序列号

　　此外，上面的每一个使用实例都符合单独产品线的服务(LOBs)需求，所以创建雇员服务必须继续满足每个LOB的需求，但要记住这项服务属于疏耦合，改变其能力必须不能毁坏这项服务现有的用户。

　　让我们从实例一开始，利用RPC形式方法来实行该项服务，，例如我们决定用我们四个指定的操作：建立雇员（），读取雇员（），升级雇员（）删除雇员()。换句话说，我们事实上不是建立一个创建雇员服务，而是在执行一项雇员信息服务。并且调用该项服务的建立雇员（）操作，这项操作不需要任何参数，并返回一个唯一产品序列号。该方法目前一直行之有效。-这R PC的方式方法为实例编号1提供了理想的功能，另外也提供了其他操作。

　　可是当我们试图把实例编号2混合进来时，问题就出现了。为了支持该项服务的新参数，我们必须重制服务合同，因此，我们必须同时将用户升级，否则，用户会向服务发送无效请求。此外，如果我们要改变用户发给服务的信息，我们就要改变合同和用户。

　　如果要维护耦合服务，我们就要按照文档形式实行实例一。在这种情况下，我们终究建立了一个创建雇员服务，并接受XML文档格式的输入。至于文档包含什么内容，并不重要。接受该文档就足够建立一个雇员记录，文档的标题也许包含其它机密内容，但是正文不应含有参数和信息。

　　现在该实行实例2，我们简单的将新近要求的功能加入服务，来接受正文带有信息的输入资料。如果请求带有用户信息，我们就能升级用户记录。如果信息丢失，我们就简单地实行用例1.另外如果我们改变接受超时的用户信息，服务能够继续支持新加功能，而不影响任何用户或者要求修改合同。换句话说，对于松散耦合来说，建立文档形式服务尤为重要。

　　服务独立性的微妙之处

　　但文档形式，并不能解决全部问题。对于大多数机构来说，人们的需求总在发展变化，所以在实例2初见成效三个月之后，这些机构还需要实例3：

　　实例三（六个月的实例）——我们像从前一样向创建雇员服务发送一个文档。，只有现在我们可以看出，该雇员是全职还是兼职。既然如此。我们通过几个步骤将这些雇员按全职员工津贴进行设置。我们不为兼职员工设置津贴。另外，按照津贴设置员工的商业规则对我们旧版人力资源应用程序是必不可少的，并且旧版app也会处理建立雇员记录。因此，所有我们要做的即添加实例3要求的功能，就是在旧版人力资源应用程序上添加界面，对吧？但并不那么简单。

　　为了支持论点，我们用简单的包装方法来实行创建雇员服务。此外，让我们假设另一个服务——转换零星业务为日夜业务服务，这项服务要求现有的兼职雇员暂停他们的兼职。然后在创建雇员服务登记带有津贴的新雇员的同时，执行旧版应用逻辑程序。

　　效果不错，但是难就难在这了：我们说，该项业务要求创建雇员服务中的新雇员津贴登记部分发生变化。现在我们在服务层面和深层应用层面出现了问题。因为在服务层面，应用程序功能的改变意味着这种改变可能影响其它服务，该事实人们无法看到。我们希望避免这些服务的相对独立性。

　　问题就出在，我们把复杂的应用功能简单化了。如果我们把津贴登记过程提取成一项原子服务构成的组合，而不是原子服务本身，我们。当业务要求变化时，我们还必须升级该过程功能。但在这种情况下，变化发生在组合服务层面。因此，我们足以看见我们精心设计的SOA提供的统治架构所产生的变化所产生的作用。我们不再需要改变任何现有的服务合同。

　　但是，如果业务还要求由此产生的原子服务功能发生变化。只要那些原子服务经由文档形式相互作用，设计师就能用简单的方式处理该变化。在这种情形下，改变原子服务的功能不会影响整个组合的用户，因为文档形式稀疏耦合能够保证疏耦合的宽度，因此需要具有服务独立性的文档形式服务和精心设计的统治架构。

　　采用ZapThink

　　设计合适的服务远远超出了ZapFlash涉及的领域---参看ZapThink最近关于服务设计定向的讨论和我们先前对适当颗粒性设计RPC vs文档形式相互作用以及原子性和颗粒性之间的关系。但是之前的讨论主要是关于颗粒性问题。服务独立性问题主要是旧版服务实现的应用功能问题，而不是界面颗粒性问题。
.

　　更不是设计恰当的原子性和相互作用形式。但是ZapFlash包含的核心信息是怎样建立服务寻求变化。也不同于其它通过建立改变而使SOA 有别于其它设计方法的设计原则。。从而形成了该结构商业灵活性观点的核心部分该结构具有真正的SOA结构特色。建立改变最大的难处，当然，就是我们无法预测明天的要求。在统治架构环境里建立文档形式并为旧版服务指定适当的原子性是解决这一基本局限性重要技术。