<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>IT公司面试手册 &#187; SOA</title>
	<atom:link href="http://www.mianwww.com/html/category/it-interview/soa/feed" rel="self" type="application/rss+xml" />
	<link>http://www.mianwww.com</link>
	<description></description>
	<lastBuildDate>Wed, 08 Feb 2012 11:48:28 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>介绍一下webservice开发的几个基本概念</title>
		<link>http://www.mianwww.com/html/2012/02/13102.html</link>
		<comments>http://www.mianwww.com/html/2012/02/13102.html#comments</comments>
		<pubDate>Sun, 05 Feb 2012 13:12:57 +0000</pubDate>
		<dc:creator>jim.jin</dc:creator>
				<category><![CDATA[SOA]]></category>

		<guid isPermaLink="false">http://www.mianwww.com/?p=13102</guid>
		<description><![CDATA[web Service Web Service是使应用程序可以以与平台和编程语言无关的方式进行相互通信的一项技术。Web 服务是一个软件接口，它描述了一组可以在网络上通过标准化的 XML 消息传递访问的操作。它使用基于 XML 语言的协议来描述要执行的操作或者要与另一个 Web 服务交换的数据。一组以这种方式交互的 Web 服务在面向服务的体系结构（Service-Oriented Architecture，SOA）中定义了特殊的 Web 服务应用程序 SOAP SOAP（Simple Object Access Protocol ）简单对象访问协议是在分散或分布式的环境中交换信息并执行远程过程调用的轻量级协议，是一个基于XML的协议。使用SOAP，不用考虑任何特定的传输协议（最常用的还是HTTP协议），可以允许任何类型的对象或代码，在任何平台上，以任何一种语言相互通信。 SOAP包括四个部分：SOAP封装(envelop)，封装定义了一个描述消息中的内容是什么，是谁发送的，谁应当接受并处理它以及如何处理它们的框架；SOAP编码规则（encoding rules），用于表示应用程序需要使用的数据类型的实例；SOAP RPC表示(RPC representation)，表示远程过程调用和应答的协定；SOAP绑定（binding），使用底层协议交换信息。 应用中比较关注的是envelop，由一个或多个Header和一个Body组成。 SOAP在可互操作的基础 Web 服务协议栈中的位置： Axis Axis本质上就是一个SOAP引擎（Apache Axis is an implementation of the SOAP），提供创建服务器端、客户端和网关SOAP操作的基本框架。但Axis并不完全是一个SOAP引擎，它还包括： 是一个独立的SOAP服务器。 是一个嵌入Servlet引擎（例如Tomcat）的服务器。支持WSDL。 提供转化WSDL为Java类的工具。 提供例子程序。 提供TCP/IP数据包监视工具 AXIS的几种服务类型 AXIS有四种service styles，分别是：RPC, Document, Wrapped, 和Message。最常用的就是RPC和Message。 RPC：在AXIS中是一个默认选项。当你部署的时候使用下列两种方式： 或则 ，它遵循SOAP RPC和编码规则。每个RPC都包括一个表示名称的外部接点和一些表示参数的内部接点。AXIS会根据规则将一个XML（WSDL文件）文件转化成一个JAVA对象，并对对想赋上在文件中描述的值。也可以根据规则将一个JAVA对象转化成XML文件。 Document [...]]]></description>
		<wfw:commentRss>http://www.mianwww.com/html/2012/02/13102.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>RESTful的实现：RESTful Web 服务与 RPC 样式的 Web 服务</title>
		<link>http://www.mianwww.com/html/2012/02/13097.html</link>
		<comments>http://www.mianwww.com/html/2012/02/13097.html#comments</comments>
		<pubDate>Sun, 05 Feb 2012 13:09:47 +0000</pubDate>
		<dc:creator>jim.jin</dc:creator>
				<category><![CDATA[SOA]]></category>

		<guid isPermaLink="false">http://www.mianwww.com/?p=13097</guid>
		<description><![CDATA[了解了什么是REST，我们再看看RESTful的实现。最近，使用 RPC 样式架构构建的基于 SOAP 的 Web 服务成为实现 SOA 最常用的方法。RPC 样式的 Web 服务客户端将一个装满数据的信封（包括方法和参数信息）通过 HTTP 发送到服务器。服务器打开信封并使用传入参数执行指定的方法。方法的结果打包到一个信封并作为响应发回客户端。客户端收到响应并打开信封。每个对象都有自己独特的方法以及仅公开一个 URI 的 RPC 样式 Web 服务，URI 表示单个端点。它忽略 HTTP 的大部分特性且仅支持 POST 方法。 　　由于轻量级以及通过 HTTP 直接传输数据的特性，Web 服务的 RESTful 方法已经成为最常见的替代方法。可以使用各种语言（比如 Java 程序、Perl、Ruby、Python、PHP 和 Javascript[包括 Ajax]）实现客户端。RESTful Web 服务通常可以通过自动客户端或代表用户的应用程序访问。但是，这种服务的简便性让用户能够与之直接交互，使用它们的 Web 浏览器构建一个 GET URL 并读取返回的内容。 　　在 REST 样式的 Web 服务中，每个资源都有一个地址。资源本身都是方法调用的目标，方法列表对所有资源都是一样的。这些方法都是标准方法，包括 HTTP GET、POST、PUT、DELETE，还可能包括 HEADER 和 OPTIONS。 　　在 RPC [...]]]></description>
		<wfw:commentRss>http://www.mianwww.com/html/2012/02/13097.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>什么是REST？</title>
		<link>http://www.mianwww.com/html/2012/02/13095.html</link>
		<comments>http://www.mianwww.com/html/2012/02/13095.html#comments</comments>
		<pubDate>Sun, 05 Feb 2012 13:08:42 +0000</pubDate>
		<dc:creator>jim.jin</dc:creator>
				<category><![CDATA[SOA]]></category>

		<guid isPermaLink="false">http://www.mianwww.com/?p=13095</guid>
		<description><![CDATA[REST (REpresentation State Transfer) 描述了一个架构样式的网络系统，比如 web 应用程序。它首次出现在 2000 年 Roy Fielding 的博士论文中，他是 HTTP 规范的主要编写者之一。 REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。 Web 应用程序最重要的 REST 原则是，客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。此外，无状态请求可以由任何可用服务器回答，这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。 在服务器端，应用程序状态和功能可以分为各种资源。资源是一个有趣的概念实体，它向客户端公开。资源的例子有：应用程序对象、数据库记录、算法等等。每个资源都使用 URI (Universal Resource Identifier) 得到一个惟一的地址。所有资源都共享统一的界面，以便在客户端和服务器之间传输状态。使用的是标准的 HTTP 方法，比如 GET、PUT、POST 和 DELETE。Hypermedia 是应用程序状态的引擎，资源表示通过超链接互联。 另一个重要的 REST 原则是分层系统，这表示组件无法了解它与之交互的中间层以外的组件。通过将系统知识限制在单个层，可以限制整个系统的复杂性，促进了底层的独立性。 当 REST 架构的约束条件作为一个整体应用时，将生成一个可以扩展到大量客户端的应用程序。它还降低了客户端和服务器之间的交互延迟。统一界面简化了整个系统架构，改进了子系统之间交互的可见性。REST 简化了客户端和服务器的实现。]]></description>
		<wfw:commentRss>http://www.mianwww.com/html/2012/02/13095.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>SOA工程师面试题</title>
		<link>http://www.mianwww.com/html/2011/10/11532.html</link>
		<comments>http://www.mianwww.com/html/2011/10/11532.html#comments</comments>
		<pubDate>Sun, 30 Oct 2011 14:30:27 +0000</pubDate>
		<dc:creator>jim.jin</dc:creator>
				<category><![CDATA[SOA]]></category>

		<guid isPermaLink="false">http://www.mianwww.com/?p=11532</guid>
		<description><![CDATA[1. 请介绍一下什么是SOA? SOA是Service oriented architecture的简称，面向服务架构。定义SOA之前首先需要定义一下什么是Service即服务, 这些服务是自包含的，具有定义良好的接口，允许这些服务的用户——称为客户机或使用者——了解如何与其进行交互。 SOA是指为了解决在Internet环境下业务集成的需要,通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。SOA是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。 2. 请介绍一下SOA中的业务层（business layers）和管道层（plumbing layers）？ 在SOA中采用了两层架构，首先一层直接与业务相关叫业务层，因为它实现了业务功能。第二层则是技术层次交管道层，该层将管理计算机资源，例如：数据库、web服务器等等。 3. 服务Service和元件Components有什么区别？ 服务是一组为实现业务功能而组合起来的元件，元件是服务的实现方法，元件可以是Java,C#,C++等等，但是服务总是以通用协议如Web Service等格式暴露出来的。]]></description>
		<wfw:commentRss>http://www.mianwww.com/html/2011/10/11532.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>简单介绍消息队列（Message Queue）简介及其使用</title>
		<link>http://www.mianwww.com/html/2011/10/11145.html</link>
		<comments>http://www.mianwww.com/html/2011/10/11145.html#comments</comments>
		<pubDate>Wed, 19 Oct 2011 12:26:21 +0000</pubDate>
		<dc:creator>jim.jin</dc:creator>
				<category><![CDATA[SOA]]></category>

		<guid isPermaLink="false">http://www.mianwww.com/?p=11145</guid>
		<description><![CDATA[利用 MSMQ（Microsoft Message Queue），应用程序开发人员可以通过发送和接收消息方便地与应用程序进行快速可靠的通信。消息处理为您提供了有保障的消息传递和执行许多业务处理的可靠的防故障方法。 MSMQ与XML Web Services和.Net Remoting一样，是一种分布式开发技术。但是在使用XML Web Services或.Net Remoting组件时，Client端需要和Server端实时交换信息，Server需要保持联机。MSMQ则可以在Server离线的情况下工作，将Message临时保存在Client端的消息队列中，以后联机时再发送到Server端处理。 显然，MSMQ不适合于Client需要Server端及时响应的这种情况，MSMQ以异步的方式和Server端交互，不用担心等待Server端的长时间处理过程。 虽然XML Web Services和.Net Remoting都提供了[OneWay]属性来处理异步调用，用来解决Server端长方法调用长时间阻碍Client端。但是不能解决大量Client负载的问题，此时Server接受的请求快于处理请求。 一般情况下，[OneWay]属性不用于专门的消息服务中。 1. 基本术语和概念（Basic terms and concepts） “消息”是在两台计算机间传送的数据单位。消息可以非常简单，例如只包含文本字符串；也可以更复杂，可能包含嵌入对象。 消息被发送到队列中。“消息队列”是在消息的传输过程中保存消息的容器。消息队列管理器在将消息从它的源中继到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。 “消息队列”是 Microsoft 的消息处理技术，它在任何安装了 Microsoft Windows 的计算机组合中，为任何应用程序提供消息处理和消息队列功能，无论这些计算机是否在同一个网络上或者是否同时联机。 “消息队列网络”是能够相互间来回发送消息的任何一组计算机。网络中的不同计算机在确保消息顺利处理的过程中扮演不同的角色。它们中有些提供路由信息以确定如何发送消息，有些保存整个网络的重要信息，而有些只是发送和接收消息。 “消息队列”安装期间，管理员确定哪些服务器可以互相通信，并设置特定服务器的特殊角色。构成此“消息队列”网络的计算机称为“站点”，它们之间通过“站点链接”相互连接。每个站点链接都有一个关联的“开销”，它由管理员确定，指示了经过此站点链接传递消息的频率。 “消息队列”管理员还在网络中设置一台或多台作为“路由服务器”的计算机。路由服务器查看各站点链接的开销，确定经过多个站点传递消息的最快和最有效的方法，以此决定如何传递消息。 2. 队列类型（Queue Type） 有两种主要的队列类型：由您或网络中的其他用户创建的队列和系统队列。 用户创建的队列可能是以下任何一种队列： “公共队列”在整个“消息队列”网络中复制，并且有可能由网络连接的所有站点访问。 “专用队列”不在整个网络中发布。相反，它们仅在所驻留的本地计算机上可用。专用队列只能由知道队列的完整路径名或标签的应用程序访问。 “管理队列”包含确认在给定“消息队列”网络中发送的消息回执的消息。指定希望 MessageQueue 组件使用的管理队列（如果有的话）。 “响应队列”包含目标应用程序接收到消息时返回给发送应用程序的响应消息。指定希望 MessageQueue 组件使用的响应队列（如果有的话）。 系统生成的队列一般分为以下几类： “日记队列”可选地存储发送消息的副本和从队列中移除的消息副本。每个“消息队列”客户端上的单个日记队列存储从该计算机发送的消息副本。在服务器上为每个队列创建了一个单独的日记队列。此日记跟踪从该队列中移除的消息。 “死信队列”存储无法传递或已过期的消息的副本。如果过期或无法传递的消息是事务性消息，则被存储在一种特殊的死信队列中，称为“事务性死信队列”。死信存储在过期消息所在的计算机上。有关超时期限和过期消息的更多信息，请参见默认消息属性。 “报告队列”包含指示消息到达目标所经过的路由的消息，还可以包含测试消息。每台计算机上只能有一个报告队列。 “专用系统队列”是一系列存储系统执行消息处理操作所需的管理和通知消息的专用队列。 在应用程序中进行的大多数工作都涉及访问公共队列及其消息。但是，根据应用程序的日记记录、确认和其他特殊处理需要，在日常操作中很可能要使用几种不同的系统队列。 3. 同步和异步通信（Synchronous VS. [...]]]></description>
		<wfw:commentRss>http://www.mianwww.com/html/2011/10/11145.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>详细讲解Webservices技术</title>
		<link>http://www.mianwww.com/html/2011/10/11143.html</link>
		<comments>http://www.mianwww.com/html/2011/10/11143.html#comments</comments>
		<pubDate>Wed, 19 Oct 2011 12:25:52 +0000</pubDate>
		<dc:creator>jim.jin</dc:creator>
				<category><![CDATA[SOA]]></category>

		<guid isPermaLink="false">http://www.mianwww.com/?p=11143</guid>
		<description><![CDATA[Web Service是基于网络的、分布式的模块化组件，它执行特定的任务，遵守具体的技术规范，这些规范使得Web Service能与其他兼容的组件进行互操作[21]。它可以使用标准的互联网协议，像超文本传输协议HTTP和XML，将功能体现在互联网和企业内部网上。Web Service平台 是一套标准，它定义了应用程序如何在Web上实现互操作性。可以使用任何语言，在任何平台上写WebService。 Web Service平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互操作性，Web Service 平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。目前这些协议有： 1.XML和XSD 可扩展的标记语言XML是Web Service平台中表示数据的基本格式。除了易于建立和易于分析外，XML主要的优点在于它既与平台无关，又与 厂商无关。XML是由万维网协会(W3C)创建，W3C制定的XML SchemaXSD定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型 Web Service平台是用XSD来作为数据类型系统的。当你用某种语言如VB.NET或C#来构造一个Web Service时，为了符合Web Service标准， 所有你使用的数据类型都必须被转换为XSD类型。如想让它使用在不同平台和不同软件的不同组织间传递，还需要用某种东西将它包装起来。这 种东西就是一种协议，如 SOAP。 2.SOAP SOAP即简单对象访问协议(Simple Object Access Protocol)，它是用于交换XML编码信息的轻量级协议。它有三个主要方 面：XML-envelope为描述信息内容和如何处理内容定义了框架，将程序对象编码成为XML对象的规则，执行远程过程调用(RPC)的约定。SOAP 可以运行在任何其他传输协议上。例如，你可以使用 SMTP，即因特网电子邮件协议来传递SOAP消息，这可是很有诱惑力的。在传输层之间的 头是不同的，但XML有效负载保持相同。 Web Service 希望实现不同的系统之间能够用“软件-软件对话”的方式相互调用，打破了软件应用、网站和各种设备之间的格格不入的状态 ，实现“基于Web无缝集成”的目标。 3.WSDL Web Service描述语言WSDL就是用机器能阅读的方式提供的一个正式描述文档而基于XML的语言，用于描述Web Service及其函数、参数和 返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的。 4.UDDI UDDI 的目的是为电子商务建立标准；UDDI是一套基于Web的、分布式的、为Web Service提供的、信息注册中心的实现标准规范，同时也包含 一组使企业能将自身提供的Web Service注册，以使别的企业能够发现的访问协议的实现标准。 5.远程过程调用RPC与消息传递 Web Service本身其实是在实现应用程序间的通信。我们现在有两种应用程序通信的方法：RPC远程过程调用和消息传递。使用RPC的时候， 客户端的概念是调用服务器上的远程过程，通常方式为实例化一个远程对象并调用其方法和属性。RPC系统试图达到一种位置上的透明性：服务 器暴露出远程对象的接口，而客户端就好像在本地使用的这些对象的接口一样，这样就隐藏了底层的信息，客户端也就根本不需要知道对象是 在哪台机器上。 微软的.NET技术应该算是时下最好的Web Service 开发技术。.NET平台不仅延续了微软一贯的编程风格，而且还增加了许多支持Web 服务的 [...]]]></description>
		<wfw:commentRss>http://www.mianwww.com/html/2011/10/11143.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>请简单介绍微软工作流技术</title>
		<link>http://www.mianwww.com/html/2011/10/11139.html</link>
		<comments>http://www.mianwww.com/html/2011/10/11139.html#comments</comments>
		<pubDate>Wed, 19 Oct 2011 12:24:47 +0000</pubDate>
		<dc:creator>jim.jin</dc:creator>
				<category><![CDATA[SOA]]></category>

		<guid isPermaLink="false">http://www.mianwww.com/?p=11139</guid>
		<description><![CDATA[一、什么是工作流，工作流做什么用呢？ 一个工作流本质是一种方法-用来归档包含在完成一个单元的工作中的活动。典型地，在处理过程中，工作&#8221;流&#8221;流过一项或更多活动。这些活动可以通过机器或人工来实现，并且有可能象在一个互联网应用程序定义页面顺序一样得简单，也有可能象管理必须为任何数目的人都要看到、更改并同意的文件或产品一样得复杂。 二、WWF是什么呢？它的整体框架？ WWF说到底也是一个程序，只不过它是一个专门控制工作流的程序，它为开发工作流提供了框架、模型、以及工作流的工作引擎（即WorkflowRuntime），让开发人员快速的建立工作流。 1、Activities（活动） 工作流的组成部分，一个工作流由若干个activity组成，每个activity都包含特定的功能，去完成一件工作。 2、Serivices（服务） 当一个工作流实例运行时，可以伴随运行许多个Serivices，这些Services都是采用可插式调用的，即这些Serivices是为了满足不同的工作流的运行实例的需求，伴随实例而运行的。如：在一个工作流的运行实例中，我们可以同时加载与宿主程序通信的Service，监听和跟踪工作流实例运行的Service等等。 3、WWF与宿主程序的通信和关系。 宿主程序能够与工作流通讯交换数据通过通信Service服务，同时，宿主程序也可以与WWF中一些特殊的Activiy活动通过定义一些接口，采用事件传递参数的形式进行通信，交换数据。 4、WWF持久化（“钝化”） WWF工作流程序可以长时间的运行，而且当WWF运行时所在的计算机重新启动后，这些实例仍然可以正常准确的运行，是由WWF的“钝化”机制来实现的。在WWF内部包含了一个非常有用的Service服务，用来把这些运行的数据保存到SQlServer中。 5、WWF跟踪 WWF中在工作流运行的同时，能够监视工作流的操作，而其这些操作可记录在数据库中或文件里。 6、WWF序列化 WWF的activity活动是可以被序列化的，通过序列化可将自定义的Activity的自定义样式进行保存。 7、WWF动态更新 WWF工作流允许工作流在运行的状态中，动态的更新工作的状态，或动态的控制工作流的流向，更改预期的流程。 通过使用WWF，你可以创建基于处理器流的工作流并且把它们部署在任何类型的.NET应用程序中。此外，本文还讨论了ASP.NET开发者面对的一些特有的问题-这些问题可能通过使用工作流得到解决，如维持状态和页面导航等。 在2005年9月，微软在它的一年两次的专业开发者会议上公开了Windows Workflow Foundation(WWF，Windows工作流基础)。作为WinFX API的支柱之一，WWF提供给开发者一个普通框架-在其上开发过程驱动的和以工作流为中心的应用程序。 当前，有些组织力图把整个商业过程自动化；他们的标准答案就是集合一队开发者来开发相应的代码。尽管这种方式对于这些组织带来良好的作用，然而也有一些固有的问题。为了深入理解这一问题，你需要理解一个工作流的基本特征。 一个工作流本质是一种方法-用来归档包含在完成一个单元的工作中的活动。典型地，在处理过程中，工作&#8221;流&#8221;流过一项或更多活动。这些活动可以通过机器或人工来实现，并且有可能象在一个互联网应用程序定义页面顺序一样得简单，也有可能象管理必须为任何数目的人都要看到、更改并同意的文件或产品一样得复杂。 因为如此多的工作流必须考虑到人工参预，所以可能需要花费很长工期才能完成，时间可能为几小时到数月或更长。例如，参预在该过程中的人可能无法找到，不在本地或忙于另外的任务；因此，工作流必须在所有非活动期间能够把自身持续性存储。而且，通过编码独立实现的过程可能对非技术人员难于理解而对开发者却难于更改。这一点和其它一些因素正是例如WindowsWF等通用工作流框架的目标-其目的就在于使创建、改变和管理工作流更容易-这是通过向它们提供一个可视化接口或通过定义一组普通API来实现的。 你可以把WWF工作流放置在任何类型的.NET应用程序中-包括Windows表单程序，控制台应用程序，Windows服务和ASP.NET Web应用程序。每种类型都需要专门的考虑。尽管一些现有示例已经足够说明如何把工作流宿主到Windows表单程序和控制台应用程序中，但是本文将集中于讨论ASP.NET开发者的问题-他们希望把工作流集成到自己的应用程序中。 Windows WF和MVC模式 在开发一个ASP.NET应用程序时，你可能使用WWF的一个普通的方法是实现一种模型-视图-控制器(MVC)方法。实质上，MVC的目标是把描述层、应用程序逻辑和应用程序流逻辑分离开来。 搞清楚这个将十分有益于一个ASP.NET应用程序的开发，请考虑一个帮助桌面票工作流的场所。假定有一个商业用户通过填写一个ASP.NET Web表单并点击一个提交按钮来启动该工作流。接下来，服务器就会通知一个使用Windows表单应用程序和帮助桌面的雇员&#8211;&#8221;有新票可用了&#8221;。该帮助桌面雇员然后将在这一问题上工作，并在最后关闭该票。如果使用Windows WF来开发这个工作流情形，那么所有的处理逻辑和流程可以被包含在工作流本身，而该ASP.NET应用程序将完全不需要了解这一逻辑。 这种场所提供了一些稳固的证据-把描述与逻辑相分离是一件好事情。因为这个处理帮助桌面请求的过程是非常普通的，如果使用C#或VB.NET代码在若干不同的.NET应用程序中实现这一逻辑，那么你将会冒着重复编码的危险甚至更坏的情形&#8211;用完全不同的代码导致同样的商业处理过程的不同实现。但是如果你使用WWF来实现这一过程，那么需要这一过程的应用程序开发者将仅需在一处修改这些步骤-工作流本身-而不必担心这样会改变应用程序逻辑。代码复制和在哪里实现该过程可以通过Windows WF的使用来加以缓和。 当使用Windows WF在ASP.NET中实现MVC架构时，开发者应该尝试构建独立于应用程序的工作流-而该工作流仍然宿主于该应用程序中。这将有助于保持逻辑独立于描述并且保持在该Web应用程序中的工作步骤顺序和页面流之间的高度独立性。 一个WWF开发新手可能试图用一固定数目的活动以某种顺序去开发一个工作流，然后开发一组ASP.NET Web表单&#8211;这些表单以与之相同的顺序从一个表单流向另一个表单。很遗憾，尽管这看上去挺符合逻辑，但是实际上这是非常不具有生产效率的，因为你将会再次实现这个工作流逻辑。Web页面X不需要知道是否它需要转到页面Y或页面Z来正确地实现该工作流步骤。代之的是，该工作流(模型)应该告诉ASP.NET(控制器)下一步该干什么；然后ASP.NET应该决定要显示哪个页面。这样，每个页面几乎不需要了解整个过程；它仅需要知道怎样完成一个不同的活动并且让该工作流来关心页面是如何从一处流向另一处的。这种分离在开发者处理页面流时带来了一种极大的灵活性。例如，如果你决定改变该页面显示顺序，那么你可以从工作流中容易地实现这一点，而不需要改变该ASP.NET应用程序中的一行代码。]]></description>
		<wfw:commentRss>http://www.mianwww.com/html/2011/10/11139.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>请简单介绍SOA</title>
		<link>http://www.mianwww.com/html/2011/10/11137.html</link>
		<comments>http://www.mianwww.com/html/2011/10/11137.html#comments</comments>
		<pubDate>Wed, 19 Oct 2011 12:24:18 +0000</pubDate>
		<dc:creator>jim.jin</dc:creator>
				<category><![CDATA[SOA]]></category>

		<guid isPermaLink="false">http://www.mianwww.com/?p=11137</guid>
		<description><![CDATA[什么是服务？如前所述，在一个典型的业务环境里，服务意味着业务函数、业务事务和系统服务。业务函数可能是 getStockQuote、getCustomerAddress 或 checkCreditRating。业务事务可能是 commitInventory、sellCoveredOption 或 scheduleDelivery。系统服务可能是 logMessageIn、getTimeStamp 或 openFile。请注意各种类型服务之间的区别。从应用程序的角度来看，业务函数实际上是原子的非系统函数。业务事务很像是调用应用程序的简单函数，但是它们可能是作为自己的事务的上下文所包含的复合函数来实现的。它们可能包括多个底层函数，这些底层函数对调用者来说是透明的。系统函数是能够从诸如 Windows 或者 Linux 这样的特定平台中抽象出来的广义函数。应用程序框架可能提供像 openFile 这样的广义函数来有效地虚拟化数据源，从而可以在不考虑真实数据源的类型和位置的情况下使用这类函数。 Web 服务的出现产生了根本的改变，因为很多 Web 服务项目的成功显示这种技术事实上确实存在，借此您可以实现真正的面向服务的体系结构。它使您又往回走了一步，不仅分析您的应用程序的体系结构，而且还要分析您正设法解决的基本业务问题。从业务的角度来看，它不再是一个技术问题，而是要开发一种应用程序体系结构和框架，可以在其中定义业务问题，还可以以一致的可重复的方式来实现解决方案。 不过，首先必须理解 Web 服务并不等同于 面向服务的体系结构。Web 服务是包括 XML，SOAP，WSDL 和 UDDI 在内的技术的集合，它使您能够针对特定的消息传递和应用程序集成问题构建编程解决方案。随着时间的推移，您有理由相信这些技术将逐渐成熟并最终为更好、更有效、更健壮的技术所取代，但是，就目前的情况而言，它们可以发挥作用。至少，它们是 SOAs 能够最终实现这种观念的证明。那么，面向服务的体系结构实际上是由什么组成的呢？ SOA 只不过是一种体系结构。它不是任何诸如 Web 服务这样的特定技术的集合；而是超越它们的，在理想的情况下，是完全独立于它们的。在业务环境中，SOA 的纯粹的体系结构定义可能会是这样的“一种应用程序体系结构，在这种体系结构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，可以以定义好的顺序调用这些服务来形成业务流程”。请注意这里的表述： 所有功能都定义为服务。这仅仅包括业务功能、由底层功能组成的业务事务和系统服务功能。这将会产生粒度问题，后面我们将对此进行讨论。 所有的服务都是独立的。它们就像“黑匣子”一样运行：外部组件既不知道也不关心它们如何执行它们的功能，而仅仅关心它们是否返回期望的结果。 在其最一般的意义上来说，接口是可调用的；也就是说，在体系结构的层面上，它们究竟是本地的（在本系统内）还是远程的（在直接系统外）、是用什么互连 Scheme 或协议来调用或需要什么样的基础架构组件来连接，都是无关紧要的。服务可能是在相同的应用程序中，也可能是在公司内部网内完全不同的系统上的不对称多处理器的不同地址空间中，还有可能是在用于 B2B 配置的合作伙伴的系统上的应用程序中。 在所有这些表述中，接口是最关键的，同时也是调用应用程序关注的焦点。它定义了必需的参数和结果的类型；因而，它定义了服务的类型，而不是实现服务的技术。系统的责任是实现和管理服务的调用，而不是调用应用程序。这使得可以认识到两个关键的特征：其一，服务是真正独立的；其二，它们是可以管理的。管理包括许多功能，其中有： 安全性——请求的授权、加密和解密（在需要时）、确认等等 部署——出于性能、可用性冗余或其他方面的原因，允许服务在网络内重新部署（移动） 日志——用于审核、测量等等 动态重新路由——用于故障排除（fail over）或负载平衡 维护——管理服务的新版本]]></description>
		<wfw:commentRss>http://www.mianwww.com/html/2011/10/11137.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>对比OOP和SOA，它们的目的分别是什么？</title>
		<link>http://www.mianwww.com/html/2011/10/11118.html</link>
		<comments>http://www.mianwww.com/html/2011/10/11118.html#comments</comments>
		<pubDate>Wed, 19 Oct 2011 12:10:05 +0000</pubDate>
		<dc:creator>jim.jin</dc:creator>
				<category><![CDATA[SOA]]></category>

		<guid isPermaLink="false">http://www.mianwww.com/?p=11118</guid>
		<description><![CDATA[我想OOP和SOA应该没有对比性吧。OOP是一种编程模型，强调将复杂的逻辑分解出小的模块，特性是继承，封装和多态。而SOA是一个技术框架，技术框架和编程模型应该说不是一码事吧？SOA的思想是将业务逻辑封装成服务或者中间件提供给应用程序来调用，当然其组件化思想是继承和发扬了OOP的优点。]]></description>
		<wfw:commentRss>http://www.mianwww.com/html/2011/10/11118.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Siebel面试题</title>
		<link>http://www.mianwww.com/html/2011/10/10779.html</link>
		<comments>http://www.mianwww.com/html/2011/10/10779.html#comments</comments>
		<pubDate>Mon, 10 Oct 2011 12:55:46 +0000</pubDate>
		<dc:creator>jim.jin</dc:creator>
				<category><![CDATA[SOA]]></category>

		<guid isPermaLink="false">http://www.mianwww.com/?p=10779</guid>
		<description><![CDATA[Q:   What are the four architectural layers of the Siebel application? A:   Data Objects Layer, Business Objects Layer, Logical User Interface Layer, Physical User Interface Layer &#160; Q:   Name the top level objects in the Data Objects Layer A:   Table, Workflow Policy Column, Workflow Policy Object, EIM Interface Table &#160; Q:   Name the top level [...]]]></description>
		<wfw:commentRss>http://www.mianwww.com/html/2011/10/10779.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

