图10使用一个服务契约显示了 OrderProcessor 服务提供者的需求，该服务契约提供了一张由业务分析师创建的业务过程的角色中心视图。一个协作使用被添加到 OrderProcessor 服务提供者中，指出它所完成的服务契约。

    图 10: 实现服务契约
     

    图10中被称作契约的的协作使用，是图11中所显示的 Purchase Order Process 服务协作的一个实例。这指定了 OrderProcessor 服务提供者完成 Purchase Order Process 业务需求。角色绑定指示出服务提供者的哪一个部分在服务契约中扮演哪一个角色。例如，货品计价端口扮演货品计价角色，购买端口扮演 orderProcessor 角色。

    这些角色绑定和下一小节中所描述的服务信道连接器并不相关。服务信道连接器被用来连接子系统中的消费者请求和提供者服务。角色绑定指定了该部分在服务契约中扮演什么角色。角色绑定既可以是严格的也可以使松散的。严格的契约完成意味着各个部分必须同它们所绑定到的角色类型一致。松散的契约完成意味着各个部分将会根据架构师的要求扮演那些角色，但是模型验证并不验证角色和部分功能。也就是说，或许因为业务服务契约不完全，或者只有业务需求的概略信息。

    图 11: Service Requirements 契约     

    显示 SOA 解决方案如何完成业务需求要花费额外的工作来指定契约和角色绑定，但是它提供了一个管理变化的有利条件。模型查询可能被用来决定哪一个服务提供者完成什么业务需求。需求中的任何改变将可能导致服务协作中的其中一个角色的变化。建模器于是能够直接定位到扮演那些角色的部分，决定代表那些可能需要改变的角色的服务规范如何处理需求中的变化。模型验证也能够被用来决定某些角色是否被改变，以及在 SOA 解决方案中扮演该角色的各个部分不再有能力执行角色的所有责任。这较之用例实现的不具备支持语义或者松散语义的老套依赖要强大得多。正是这种类型的形式，可验证的 SOA 解决方案和业务需求之间的连接器（确保解决方案是业务相关的，满足需求，并且是敏捷的解决方案），才能够便于适应改变。