在.NET里实现SOA的基础

在.NET里实现SOA的基础

由于需要做个关于SOA的讲座，本人所知有限，此文内容大多来自翻译的内容。
先放部分内容在这里，也给大家做个参考，有不对的地方，也给指点指点。

SOA的目标就是快速响应企业的业务变化需求，以实现实时企业的目的。
我们知道，一个好的架构强调责任的分离。例如，表示层维护显示组件，商业逻辑层维护商业逻辑组件，数据访问层维护数据访问组件。分层提供了很好的容错，维护和扩展。SOA不是全新的事物，只是巧妙的分离、暴露了组件的责任。
SOA来自于面向对象，但增加了一个虚拟的服务层。面向服务不是背离面向对象，而是一种改良。服务构架满足了业务逻辑的需求。使用面向对象的方法在幕后处理响应需求。

在一个面向服务的设计中，Services应该被设计为粗粒度访问，而且仿照业务过程与之一致。
对象应该是细粒度访问，相当与实际的业务实体。这些对象提供详细的业务逻辑。当创建这些对象时，对
象特征就很完善了。这同样也是很好的方法，用于整理编排学术知识。每个业务对象负责自己行为和业务规则实现，例如更新表，发送Email，或者在队列中替换消息。
Services使用业务对象给客户提供了完整的Service接口。Service负责编排调用业务对象，管理响应和处理。Service方法可以调用和管理多种业务对象。
Service方法的设计应该与业务过程一致。Class方法的设计应该与具体的对象级别的操作一致。

回忆在经典多层分布式架构中，在层次之间传送数据，一次传送1000bytes要好于把1byte传1000次。我们将优化函数、设计无状态的组件，把ADO记录集转换成XML，给分布式程序提供一个轻量级的负载。
通常，我们对SOAP和WebService只注意一般的用途。然而，我们可以更进一步。我们可以把WebService看作一个Service，不仅仅是数据泵，XML看作是个可以自我描述的包，不仅仅是个负载。

Web函数应当设计成：为一个完整的业务流程执行一系列完整的Service，简单的说，目标如下：
· 在业务级别提供粗粒度的Web函数
· Web Service要提供商业对象所需要的函数
· Service返回到客户的完整结果，就像一个有很多Table的Dataset

层与层之间的数据传送
数据在整个架构中各层次传递，可以使用Datset，序列化对象，XML等做载体。
这需要考量具体的项目情况。
Dataset是.NET提供的序列化对象，直接可以给其他.NET程序使用。如果你的应用程序将和其他平台应用交互，比如J2EE应用方案，DataSet可能就不太适合，J2EE无法很好识别这个对象。
序列化对象也是个的选择。要记住的是，整个对象并没有做封装处理。对象的公共属性和数据成员被序列化和包装，但客户端调用时，无法完全重构这个对象和访问它的私有数据成员和方法。
XML当然也是一种选择。XML格式数据交换用于在分布式架构中传递数据，已经是可靠和成熟的技术了。

分布式事务
Web method也支持事务。可以用DTC来管理这些事务。在.NET里可以引用System.EnterpriseServices namespace，使用 ContextUtil 类的SetAbort()和SetComplete()函数。这些函数提供了对事务的控制。
Webmethod需要加上TransactionOption修饰符，像这样：
[WebMethod(TransactionOption=TransactionOption.RequiresNew)]
事务控制只在一个web method里起作用，不能跨越Web method。

Exception Handling 错误处理
错误处理也要很好的考虑。客户程序必须捕获三种不同的错误。
首先是SoapException。在客户端，SoapException应当被当作中间层错误捕获。这对抛出中间层（应用逻辑）错误很有好处。所以，任何中间层错误应被作为SoapException抛出。
我们可以把错误做成我们需要的专用的业务逻辑错误。例如，我门给出一个有意义的SoapException信息，“数据库访问失败”，这样客户端可以很好处理他。
第二个错误是WebExceptions。当网络中断的时候，这个错误很有帮助。
最后，客户端需要捕获客户端的错误。这些错误被客户程序抛出，例如：文件找不到。。

转载于:https://www.cnblogs.com/duibudui/archive/2004/08/22/35695.html