Web (WCF) Service设计的 基本观念

 

文章来自： IT工程技术网 http://www.systhinker.com/html/33/n-11533.html

继续谈谈SOA Service Layer方面的设计考量。

前一篇网志文章中提到，通常有跨平台整合、或是需要透过网路提供远端存取的共用元件，通常才会考虑建立成为Web Service。除此之外，在设计Web Service的时候，也有些需要注意的基本概念。

Web Service虽然是透过服务介面(interface)与用户端程式系结，然而就跟一般应用程式一样，每个Web Service所提供的功能是独立的，而且与一般应用程式一样，采用层级的架构设计。 Web Service基本的层级架构如下图：

在设计时，必须尽可能的将Data Layer 与Business Layer分别封装在不同的元件中，并且各层级之间再透过抽象的介面结合。一般来说，后端的元件可以制作成Shared Component，再提供给内部的其他系统整合时使用。

而开发Service Layer时，必须要把Service Contract、Service Implementation、Data Contract等等，分别定义到不同的组件中。换句话说， 你并不应该使用Visual Studio 开发工具新增一个预设的Web Service或是WCF Service专案之后，就只用这一个专案完成所有Service Contract、Service Implementation、Data Contract 的开发；正确的做法应该是另外再建立不同的ClassLibrary专案来开发与维护不同用途的服务元件。这样的做法可以让你将来需要调整服务的内容时，可以拥有比较高的弹性；同时也可以比较容易进行单元测试，确保Web Service的稳定性。

同时，也必须要注意到，每个Web Service 同时也会是一个独立的应用程式，用户端程式必须要透过Service Layer所定义的介面(服务合约)，才可以使用其功能。而Web Service 之间若是需要整合的话，可以透过下面几种方式：

1. 若是后端资源(如：资料来源)方面的整合，可以透过Data Layer所提供的Shared Assembly：

而通常这种方式，因为跳过了Business Layer，所以仅能做比较逻辑较单纯的资料异动。

2. 若是要进行功能面的整合，则必须要透过ESB(Enterprise Service Bus)，或是再建立一个更上层的Web Service 来完成；而不是在Web Service 之间直接建立交互参照：

举例来说，假设Service A 是库存系统的服务，提供产品库存查询与异动的介面；而Service B 是订单管理系统的服务，提供新增订单与订单异动的介面。而若是需要整合客户系统提供即时下单功能时，就应该另外建立一个新的Service C，并且把处理订单的流程( Business Workflow)封装到新服务的功能当中。这样的架构会比你在Service A 和B之间建立交互参照来得有弹性，而且也较容易维护多变且复杂的商业流程。

 

文章来自： IT工程技术网 http://www.systhinker.com/html/33/n-11533.html