服务管理和模型驱动的服务开发

实现在异质环境中的服务接口需要大量代码，这些代码中的大多数经常结构相同，只能根据不同的参数、一场和其他配置数据来区分，这是应用代码生成器，或者说（MDSD，模型驱动软件（服务）开发）。
为服务生成的代码包括：
l 为服务实现细节提供框架的代码。它的目的是为服务供应者提供一个API，如此一来，服务实现的所有公共方面都得以解决。服务实现者能集中在特定的业务功能上行。这样的代码称为”框架“，因为被生成的代码是能够用特定的实现代码进行手工扩展的框架。
l 提供对服务的调用功能的代码。它的Udine是为服务消费者提供一个API，如此一来，从业务角度来看，调用服务就容易了。它应该覆盖调用一个服务的所哟技术细节。（WCF的Client端，VS有工具生成）
l 使你能在基础设施内部处理服务的代码，比如业务活动监测的代码
l 提供测试框架的代码。例如，代码可能提供了非常简单和直观的方法---仅仅使用描述性配置文件---来指定不同的测试用例
l 文档（严格的来说，不是代码）
l 在构造和部署期间，对生成的制品进行脚本处理
可以使用Rational Roes设计服务，或者使用Web Service工具创建最初的WSDL文件。这两者都可以被转换到一个中间格式上，这个格式可以指定特定平台代码生成器的基础。
模型与模型驱动工具
表达一个模型的方法非常不同。用来规定一个模型的具体表示方法称为“建模语言”或“领域特定语言”（DSL）。后一个术语表明，针对模型所采用的表示法是领域特定的，所以，对模型的描述能集中在关键信息上。一个DSL应该精确、简练、可读和完整。DSL可以用图形表示法或文字表示法。
DSL会影响你对工具的选择，例如，WSDL是使用特定大纲的XML，但是使用工具能使你通过一个可视化的界面而非难度和难维护的DSL表示法。这些工具应该：启速度快、恰当的人机界面、模型必须被版本化、模型支持团队开发。
元模型
模型的结构称为元模型。各自的元模型都会不同，但是，在开始时，将XML表示法用于整个模型，从中生成相应的代码，这就够了。然后，可以将其他阐明模型的方法转换到XML表示法上。这样的好处是，它把阐明服务的方法从转换模型和代码生成的方法中解耦了出来。如果后来引入了不同种类的服务实现，则只需要提供一个方法把这些规范转换到你的恶模型表示法上。
实践中的MDSD
1.打标签：在大型团队中，需要配置管理支持，才能处理统一模型和生横制品的不同版本。
2.调试
3.手工修改生成代码：有时需要手工修改生成的代码，结果就是文件既包含生成代码，也包含手工创建的代码。
a) 使用不同文件：将生成的代码和手工代码，物理上完全隔离。比如，前者可以是一个不可改变的基类，然后派生类为手工类
b) 生成一次：生成以后就全部是手工修改
c) 合并生成的与手工代码
4.代码生成粒度：太细，有太多文件也不好。正确的找到粒度，需要对代码有良好的组织。
工具
现在几乎所有建模语言都是用基于XML的格式，所以一个工具可能是XSTL。
一个XSTL处理器将一个或多个XML文件转换成一个多个结果文件，其格式可能是XML，也可能是其他文本形式。这些文件提供了结果代码的模板，模板中点缀着可用于输入记号进行循环的控制结构，以及可以用源文件继承的特定数据进行填充的占位符。
XSTL也有很多缺点，可以考虑使用其他一些工具，比如openArchitectureWare的工具。
服务管理
通常，在介绍Web Services的时候都会引入3个角色：服务供应者，服务消费者，以及服务中间人。当供应者提供一个服务时，他就把服务注册到一个人所共知的地方（即服务中间人），当消费者需要一个服务时，消费者就可以使用中间人来找到该服务的供应者。
早在2000年，当Web Serices开始起步时，一个被称为“通用描述，发现和集成业务注册中心”（UDDI/UBR）的中间人出现了，宣布要称为Web Service的世界黄页。但是，最终这个概念失败了：失败的一个重要原因可能是早期的Web Services规模都比较小，而建立一个中央中间人并不是非常重要，它并非实现SOA的第一步，在早期还不需要一个中间人。
但是，当SOA慢慢成长时，这个话题慢慢变得重要了。当它到达一定规模时，会出现对帮助消费者找到合适服务的中间人的需求。而且，Web Services调用内生是点到点的调用，所以，引入一个中间人的松耦合还是很有意义的。（当然也可是使用ESB里提到的代理或拦截器）
业务库和注册中心
业务库是从业务的角度来管理服务及其制品，也就是说，他们管理的是接口、契约、SLA、依赖关系等等，其目的是帮助识别、设计和开发服务。从业务的观点来看，一个业务库应该包含有关服务的接口和行为的所有信息，他们独立于技术细节，切换基础设施（ESB）时，不必改变业务库。
注册中心从技术的角度来管理服务。他们管理服务，但是不管理契约的所有细节，它们管理的是在运行时使用服务需要的所有技术细节（即部署信息），可以被用来将服务调用路由到提供相应服务的各个系统。如果必要的话，一个注册中心可以是基础设施的一部分。
业务库和注册中心可以是同一个实体，此时会产生使业务库依赖于基础设施的危险，这意味着改变基础设施不会像业务库独立于基础设施时那样容易。
如果他们是不同实体，那么注册中心需要有一个对业务库的引用，这也许是个好主意。
另外，一开始建立SOA的时，并不需要业务库和注册中心，当业务库和注册中心变得有用或有必要时，再将其引入时一种不错的做法。在早期，可以定义一个“元模型”，甚至从最开始就对这个元模型使用一个XML表示法。他就可以被认为是最初的服务业务库。他可以被逐步扩展。
总结
l 模型驱动的服务开发（MDSD）是生成所有必须的服务代码的完美的方法
l 源模型应该满足源代码所有常见的要求
l 建模工具应该满足源代码编辑器所有常见的要求
l 应该独立于特定基础设施来定义自己的元模型，并且，通过使用相应的XML表示法，将服务规范和生成特定于基础设施的代码和其他制品的过程解耦
l 提供所有必需的生成器还不够，建立合适的过程。
l XSTL是生成代码的方法之一，但是，并不一定是最好的。特别是处理复杂模型。复杂转换和许多文件时，XSTL的局限就很明显。