在软件开发过程中，经常会有如下情况发生：

1. 界面开发人员要开发界面，但是要使用的服务还没有开发好，这个时候，要么只能开发一半，要么就只能等服务开发好之后再继续进行开发，无论是哪一种情况，都会导致影响开发进度。
2. 与第三方对接的时候，由于各种原因，无法在本地构建第三方测试环境，只能到客户现场进行开发和测试，这会导致出差成本增加，开发人员满意度下降等情况的发生。
3. 做一个Demo系统，如果是全部做静态页面，与客户沟通讲解的时候，总是讲起来不够真实，如果全部采用真实实现，会导致Demo系统构建成本太高。

Tiny框架为了避免上述问题，增加了ServiceMock工程，顾名思义就是Mock一个服务，它的访问接口和真实的完全一致，但是内部的实现却是虚假的，这样就可以比较好的解决上面的问题：

1. 对于并行开发来说，只要先花一点时间简单做个MockService，界面开发人员就可以完全按照真实的方式进行开发、测试了，绝大多数的情况都可以满足展现和控制层的开发要求。
2. 对于与第三方对接的情况，只要先做好与对应的第三方所有接口的MockService，就可以完全在本地进行开发与测试，最后只要到现场做集成测试即可。
3. 做出来的系统完全可以做得更真实，比如：做个HelloWorld服务，比如在输入框中输入的是”abc“，展现出的效果是”Hello，abc“的效果比”Hello，World“的效果好得多，同时又不用花太多的工作量。

下面就用一个具体的例子来进行说明：

编写下面的Xml文件：

它的意思是：mock的ServiceId是helloworld

有一个入参，是字符类型，名字叫：name，有一个出参，也是字符类型，名字是result

在后面定义了出差是result的结果，它实际是一段模板，这段模板采用了TinyTemplate模板引擎来解释执行，上面的意思是用输入的参数name的值来替换${name}这个占位符，所以这个服务就可以直接执行，并且会根据输入name的值的不同，而返回对应的值，比如：参数name的值是abc，那么返回的值就是hello，abc!

实际上，它也可以做复杂一点的场景：

上面的这个MockService实现是可以真正完成加法运算的服务。

实际上，我们Mock出来的Service是真正的Service，它可以通过Json,Xml,WebService,等各种方式进行访问，实际上，对于调用者来说，它就是真正的Service，之所以我们Mock出来的Service可以骗过所有的使用者，是因为我们做了一个专门的服务加载器，把所有的MockService相关的信息读出来，并在服务框架进行注册，真正调用的时候，用调用MockServiceManager来进行真正的执行，执行过程就是读取这段模板并执行出结果之后，把结果返回。

后续，我们做对应的工具来编写这个Xml，那样做起来就更方便了。