B2B（business-to-business）应用框架
Simplified Application Framework，简称作SAF
SAF由两组框架组件组成：第一组是通用的跨领域组件，第二组是特定领域组件。
(是不是系统组件和领域组件？)
第一组包含了诸如类工厂（class factory）服务、缓存（caching）服务、事件通知（event notification）服务等通用组件。
第二组，B2B应用的本质是在商业伙伴之间交换和处理商业文档。
客户化B2B应用
SAF B2B 领域组件[文档层、工作流]
SAF跨领域组件[类工厂、事件通知、授权、事务、缓存、Windows服务、身份验证、配置、消息队列、加密]
.NET框架
3.2.1 类工厂服务（ClassFactory Service）
服务允许开发者在开发应用时，不必在代码中指定具体业务类就可获得业务对象。
使用的两项主要.NET技术是，.NET反射技术和.NET remoting技术，该框架组件的设计还采用了抽象工厂模式和单件模式。
3.2.2 缓存服务（Caching Service）
应用开发期间，开发者经常希望通过消除过多的对象创建来提高应用的性能——他们经常是把已存在的业务对象保存起来，过后再去重新获取它们，以访问其属性和方法。
两个主要功能（feature）：第一，它特别采用了XML技术，使被缓存的对象具有层次化结构，这使得开发者管理缓存对象更加容易。第二，它内置了钩子方法，这使得开发者能够在不改变框架代码的情况下，改变缓存行为和算法以适应特定业务需求。
使用的主要.NET技术是XML和XPath。
3.2.3 配置服务（Configuration Service）
标准的配置信息存取机制
.NET的配置文件和配置设计
3.2.4 事件通知服务（EventNotification Service）
应用某一部分（通常是独立的进程或远程系统）激发的事件，可能是其他部分行为的基础。
两种.NET技术：委托和.NET remoting技术。
两个主要目的。第一，它为开发者提供一种跨进程发送和接收事件的标准手段。第二，当事件通知涉及到多个应用时，它省去了集成的工作。
架构基于观察者模式和中介者模式，
3.2.5 “Windows服务”服务（WindowService Service）
如果你的应用系统要求有多个Windows服务，就会导致开发和发布的额外工作量。SAF.WindowService通过创建统一的Windows服务机制来解决上述问题：开发者只需简单修改配置文件，就可以增加另外的后台进程（background process）。
使用的主要.NET技术是.NET Windows服务、反射和线程。
模板方法设计模式用来创建扩展点，开发者可以在扩展点处插入他们自己的关于如何运行服务的业务逻辑。
3.2.6 消息队列服务（MessageQueue Service）
在应用开发中，消息队列是最被低估的技术之一。它对客户和服务器应用的解耦能力，使你能够开发出具有高度可伸缩性（scalable）和容错能力（fault tolerant）的异步（asynchronous）应用。消息队列在应用集成的开发中也很常用，以支持异构环境中的应用之间发送和接收数据。
使用System.Messaging命名空间来访问MSMQ，使用.NET的interop功能来访问MQSeries的COM动态链接库。
使用桥接设计模式来解耦用户接口和不同队列实现技术之间的依赖关系。
(什么是解耦？消息队列的作用？)
3.2.7 授权服务（Authorization Service）
授权是一个过程，根据调用者的标识或所属用户组（group）来判断调用者是否有权访问置于保护之下的特定资源。
使用SAF.Authorization，开发者只需简单地在方法（method）上增加特性（attribute），就能够在方法上进行安全检查——例如角色级检查或用户级检查等。
(很新奇的实现方式！)
使用的技术包括：.NET声明性安全、.NET特性以及.NET反射。SAF.
Authorization服务还允许开发者通过策略设计模式，来改变安全权限检查方法。
3.2.8 身份验证服务（Authentication Service）
一个应用经常包含很多子系统，每个子系统都有它自己的识别具体调用者的方法。
当一个调用请求要涉及到多个子系统时，这就产生了问题。
SAF.Authentication服务通过为整个应用提供单点登录（single-sign-on）功能，解决了上述问题。
SAF.Authentication通过像.NET安全Web服务（security Web service）这样的技术，来实现单点登录功能。
3.2.9 加密服务（Cryptography Service）
不管是密码还是需在网络上传输的数据，应用开发者经常需要将某些敏感数据加密。
SAF.Cryptography使用了.NET加密、Web服务增强（Web Service Enhancement，WSE）以及.NET remoting等技术。
3.2.10 事务服务（Transaction Service）
SAF.Transaction使支持跨多个方法调用的事务变得简单。
SAF.Transaction使用.NET中的COM+实现。
文档处理层的一些例子包括：文档解密、文档结构转换、文档日志记载以及往文档中写入特定应用数据等。
工作流处理的主要任务是：识别参与的应用，把它们连接起来使特定业务文档的处理自动化。
3.3.1 文档层服务（DocumentLayer Service）
SAF.DocumentLayer服务为开发者提供一种易用的方法，来创建单独的文档处理层。一方面，各处理层之间相互解耦；另一方面，它们共同协作，来处理输入文档和输出文档。
通过配置文件，来定义特定文档如何通过每一处理层被处理。
SAF.DocumentLayer的核心是装饰设计模式，它使你能够以“逐层”的方式对一个对象进行服务性处理。
3.3.2 工作流服务（Workflow Service）
当一个业务文档通过B2B应用时，许多业务组件都参与对该文档的处理。你必须管理这些业务组件的协调问题，以保证文档能够以正确的顺序处理。
SAF.Workflow借助访问者设计模式，来隔离工作流的业务逻辑和协调逻辑，并使用户易于向工作流中引入新的协调逻辑和业务组件。
向读者展示，可以在应用框架中开发不同服务；
它作为一个框架实现的案例，来说明开发框架时可以使用的各种.NET技术和设计模式。
SAF省略了很多通常对于实际生产环境所必需的、有关异常处理（exception handling）、线程安全和各种验证的代码。
Simplified Application Framework，简称作SAF
SAF由两组框架组件组成：第一组是通用的跨领域组件，第二组是特定领域组件。
(是不是系统组件和领域组件？)
第一组包含了诸如类工厂（class factory）服务、缓存（caching）服务、事件通知（event notification）服务等通用组件。
第二组，B2B应用的本质是在商业伙伴之间交换和处理商业文档。
客户化B2B应用
SAF B2B 领域组件[文档层、工作流]
SAF跨领域组件[类工厂、事件通知、授权、事务、缓存、Windows服务、身份验证、配置、消息队列、加密]
.NET框架
3.2.1 类工厂服务（ClassFactory Service）
服务允许开发者在开发应用时，不必在代码中指定具体业务类就可获得业务对象。
使用的两项主要.NET技术是，.NET反射技术和.NET remoting技术，该框架组件的设计还采用了抽象工厂模式和单件模式。
3.2.2 缓存服务（Caching Service）
应用开发期间，开发者经常希望通过消除过多的对象创建来提高应用的性能——他们经常是把已存在的业务对象保存起来，过后再去重新获取它们，以访问其属性和方法。
两个主要功能（feature）：第一，它特别采用了XML技术，使被缓存的对象具有层次化结构，这使得开发者管理缓存对象更加容易。第二，它内置了钩子方法，这使得开发者能够在不改变框架代码的情况下，改变缓存行为和算法以适应特定业务需求。
使用的主要.NET技术是XML和XPath。
3.2.3 配置服务（Configuration Service）
标准的配置信息存取机制
.NET的配置文件和配置设计
3.2.4 事件通知服务（EventNotification Service）
应用某一部分（通常是独立的进程或远程系统）激发的事件，可能是其他部分行为的基础。
两种.NET技术：委托和.NET remoting技术。
两个主要目的。第一，它为开发者提供一种跨进程发送和接收事件的标准手段。第二，当事件通知涉及到多个应用时，它省去了集成的工作。
架构基于观察者模式和中介者模式，
3.2.5 “Windows服务”服务（WindowService Service）
如果你的应用系统要求有多个Windows服务，就会导致开发和发布的额外工作量。SAF.WindowService通过创建统一的Windows服务机制来解决上述问题：开发者只需简单修改配置文件，就可以增加另外的后台进程（background process）。
使用的主要.NET技术是.NET Windows服务、反射和线程。
模板方法设计模式用来创建扩展点，开发者可以在扩展点处插入他们自己的关于如何运行服务的业务逻辑。
3.2.6 消息队列服务（MessageQueue Service）
在应用开发中，消息队列是最被低估的技术之一。它对客户和服务器应用的解耦能力，使你能够开发出具有高度可伸缩性（scalable）和容错能力（fault tolerant）的异步（asynchronous）应用。消息队列在应用集成的开发中也很常用，以支持异构环境中的应用之间发送和接收数据。
使用System.Messaging命名空间来访问MSMQ，使用.NET的interop功能来访问MQSeries的COM动态链接库。
使用桥接设计模式来解耦用户接口和不同队列实现技术之间的依赖关系。
(什么是解耦？消息队列的作用？)
3.2.7 授权服务（Authorization Service）
授权是一个过程，根据调用者的标识或所属用户组（group）来判断调用者是否有权访问置于保护之下的特定资源。
使用SAF.Authorization，开发者只需简单地在方法（method）上增加特性（attribute），就能够在方法上进行安全检查——例如角色级检查或用户级检查等。
(很新奇的实现方式！)
使用的技术包括：.NET声明性安全、.NET特性以及.NET反射。SAF.
Authorization服务还允许开发者通过策略设计模式，来改变安全权限检查方法。
3.2.8 身份验证服务（Authentication Service）
一个应用经常包含很多子系统，每个子系统都有它自己的识别具体调用者的方法。
当一个调用请求要涉及到多个子系统时，这就产生了问题。
SAF.Authentication服务通过为整个应用提供单点登录（single-sign-on）功能，解决了上述问题。
SAF.Authentication通过像.NET安全Web服务（security Web service）这样的技术，来实现单点登录功能。
3.2.9 加密服务（Cryptography Service）
不管是密码还是需在网络上传输的数据，应用开发者经常需要将某些敏感数据加密。
SAF.Cryptography使用了.NET加密、Web服务增强（Web Service Enhancement，WSE）以及.NET remoting等技术。
3.2.10 事务服务（Transaction Service）
SAF.Transaction使支持跨多个方法调用的事务变得简单。
SAF.Transaction使用.NET中的COM+实现。
文档处理层的一些例子包括：文档解密、文档结构转换、文档日志记载以及往文档中写入特定应用数据等。
工作流处理的主要任务是：识别参与的应用，把它们连接起来使特定业务文档的处理自动化。
3.3.1 文档层服务（DocumentLayer Service）
SAF.DocumentLayer服务为开发者提供一种易用的方法，来创建单独的文档处理层。一方面，各处理层之间相互解耦；另一方面，它们共同协作，来处理输入文档和输出文档。
通过配置文件，来定义特定文档如何通过每一处理层被处理。
SAF.DocumentLayer的核心是装饰设计模式，它使你能够以“逐层”的方式对一个对象进行服务性处理。
3.3.2 工作流服务（Workflow Service）
当一个业务文档通过B2B应用时，许多业务组件都参与对该文档的处理。你必须管理这些业务组件的协调问题，以保证文档能够以正确的顺序处理。
SAF.Workflow借助访问者设计模式，来隔离工作流的业务逻辑和协调逻辑，并使用户易于向工作流中引入新的协调逻辑和业务组件。
向读者展示，可以在应用框架中开发不同服务；
它作为一个框架实现的案例，来说明开发框架时可以使用的各种.NET技术和设计模式。
SAF省略了很多通常对于实际生产环境所必需的、有关异常处理（exception handling）、线程安全和各种验证的代码。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
