??xml version="1.0" encoding="utf-8" standalone="yes"?>
ȝQ?a href="http://www.shnenglu.com/mzty/archive/2007/08/13/29922.html">
http://www.shnenglu.com/mzty/archive/2007/08/13/29922.html C++高
http://www.shnenglu.com/mzty/archive/2007/03/02/19109.html C++基础
http://www.shnenglu.com/mzty/archive/2007/04/16/22064.html C#界面QC++核心(j)法
http://www.shnenglu.com/mzty/archive/2007/03/04/19163.html 设计模式
http://www.shnenglu.com/mzty/archive/2007/03/29/20893.html 64bitQFW3.0随笔分类
http://www.shnenglu.com/mzty/archive/2007/03/29/20892.html windows脚本技?/p>
http://www.shnenglu.com/mzty/archive/2007/03/04/19167.html C#基础
可以跨进E、跨机器甚至于跨q_的通信Q只要支持标准的Web ServiceQ例如J2EE应用服务器(如WebSphereQW(xu)ebLogicQ。应用程序可以运行在Windows操作pȝ下,也可以运行在其他的操作系l,如Sun SolarisQHP UnixQLinux{等?/p>
3、安全与可信?br>WS-SecurityQW(xu)S-Trust和W(xu)S-SecureConversation均被d到SOAP消息中,以用于用戯证,数据完整性验证,数据隐私{多U安全因素?br>在SOAP的header中增加了(jin)WS-ReliableMessaging允许可信赖的端对端通信。而徏立在WS-Coordination和W(xu)S-AtomicTransaction之上的基于SOAP格式交换的信息,则支持两阶段的事务提交(two-phase commit transactionsQ?br> 上述的多UWS-Policy在WCF中都l与?jin)支持。对于Messaging而言QSOAP是Web Service的基本协议,它包含了(jin)消息_(d)headerQ和消息?body)。在消息头中Q定义了(jin)WS-Addressing用于定位SOAP消息的地址信息Q同时还包含?jin)MTOMQ消息传输优化机ӞMessage Transmission Optimization MechanismQ?/p>
4、兼Ҏ(gu)?br> WCF充分的考虑C(jin)与旧有系l的兼容性。安装WCFq不?x)?jing)响原有的技术如ASMX?Net Remoting。即使对于WCF和ASMX而言Q虽然两者都使用?jin)SOAPQ但ZWCF开发的应用E序Q仍然可以直接与ASMXq行交互?/p>
?WebService的运行机?
首先客户端从服务器的到WebService的WSDLQ同时在客户端声UC个代理类(Proxy Class)Q?q个代理c负责与WebService服务器进行Request 和ResponseQ?当一个数据(XML格式的)(j)被封装成SOAP格式的数据流发送到服务器端的时候,׃(x)生成一个进E对象ƈ且把接收到这个Request的SOAP包进行解析,然后对事物进行处理,处理l束以后再对q个计算l果q行SOAP包装Q然后把q个包作Z个Response发送给客户端的代理c?Proxy Class)Q同样地Q这个代理类也对q个SOAP包进行解析处理,l而进行后l操作?/p>
?.net Remoting
是在DCOM{基上发展v来的一U技术,它的主要目的是实现跨q_、跨语言、穿透企业防火墙Q这也是他的基本特点Q与WebService有所不同的是Q它支持HTTP以及(qing)TCP信道Q而且它不仅能传输XML格式的SOAP包,也可以传输传l意义上的二q制,q得它变得效率更高也更加灵zR而且它不依赖于IISQ用户可以自己开?Development)q|?Dispose)自己喜欢的宿L务器Q所以从q些斚w上来讲WebService其实上是.netemoting的一U特例?/p>
区别Q?/p>
1、Remoting可以灉|的定义其所Z的协议,比如httpQtcp{,如果定义为HTTPQ则与Web Service相同Q但是webservice是无状态的Q用remoting一般都喜欢定义为TCPQ这hWeb ServiceEؓ(f)高效一些,而且是有状态的?/p>
2、Remoting不是标准Q而W(xu)eb Service是标准?/p>
3、Remoting一般需要通过一个WinForm或是Windows服务q行启动Q也可以使用iis部vQ而W(xu)eb Service则必dIISq行启动?/p>
4、在VS.net开发环境中Q专门对Web Service的调用进行了(jin)装Q用h比Remoting方便?/p>
5 net remoting只能应用于MS ?net framework之下Q需要客L(fng)必须安装f(xi)rameworkQ但是WebService是^台独立的Q跨语言Q只要能支持XML的语a都可以)(j) 以及(qing)IK企业防火墙?/p>
来自MSDNQ?a >http://www.microsoft.com/china/MSDN/library/enterprisedevelopment/builddistapp/ASP.NETWebServicesor.NETRemoting-HowtoChoose.mspx?mfr=true
分布式应用程序设计:(x)ASP.NET Web 服务?.NET Remoting
ASP.NET Web 服务偏向?XML Schema cdpȝQ提供具有广泛用范围的跨^台支持的单编E模型?NET Remoting 偏向于运行时cdpȝQ提供较为复杂而且使用范围得多的~程模型。这U本质上的差别是军_使用哪种技术的主要因素。但是,q要考虑很多其他设计因素Q包括传输协议、主E、安全性、性能、状态管理以?qing)对事务的支持等?/p>
传输协议和主E?/p>
管 SOAP 规范q不要求?HTTP 作ؓ(f)传输协议Q但是客L(fng)只能通过 HTTP 讉K使用 ASP.NET Web 服务实现?Web 服务Q因为它?ASP.NET 支持的唯一一U传输协议。服务是通过 IIS 调用的,q在 ASP.NET 的辅助进E?aspnet_wp.exe 中执行?/p>
.NET Remoting 使?zhn)能够在Q何类型的应用E序Q包?Windows H体、托的 Windows 服务、控制台应用E序?ASP.NET 辅助q程Q中灉|地托远E对象。正如前面所qͼ.NET Remoting 提供两个传输信道——TCP ?HTTP。这两个信道都能使用套接字提供Q意发送和接收q程之间的通信?/p>
它还能将 HTTP 信道?IIS ?ASP.NET 辅助q程集成。这一点很重要Q原因有以下几点。首先,它是当客L(fng)h到达时自动启?.NET Remoting 端点的唯一Ҏ(gu)?NET Remoting 线不包括启动远E服务器所需?DCOM cd的服务控制管理器 (SCM)。如果从Lq程中提供远E对象,则需要确保那些进E正在运行。还必须保它们是线E安全的Q例如,U程 A 不能在线E?B 开始关闭进E之后激zd象。如果从 ASP.NET 提供q程对象Q则可以利用 Aspnet_wp.exe 辅助q程Q这h可自动启动又hU程安全的优ѝ第二,?IIS 集成是确保跨q程 .NET Remoting 调用的唯一途径Q如下一节所q?/p>
ASP.NET Web 服务?.NET Remoting 基础l构都是可扩展的。?zhn)可以qo(h)入站和出站消息,从多斚w控制cd送和元数据的生成。?.NET RemotingQ还能实现?zhn)自己的格式化E序和信道?
安全?/p>
׃ ASP.NET Web 服务依赖?HTTPQ因此它们与标准?Internet 安全性基l构盔R成。ASP.NET 利用 IIS 的安全性功能,为标?HTTP 验证Ҏ(gu)Q包括基本、简要、数字证书,甚至 Microsoft? .NET PassportQ提供了(jin)强有力的支持。(q可以?Windows 集成验证Q但只能用于信Q域中的客L(fng)。)(j)使用可用?HTTP 验证Ҏ(gu)的一个优势在于,无需?Web 服务中更改代码,IIS 是在 ASP.NET Web 服务被调用之前执行验证的。ASP.NET q支持基?.NET Passport 的验证和其他自定义的验证Ҏ(gu)。ASP.NET 支持Z目标 URL 的访问控Ӟq过?.NET 代码讉K安全?(CAS) 基础l构的集成支持访问控制。SSL 可用于确保通信的安全?/p>
管q些标准传输技术对于确?Web 服务相当有效Q但它们只能做到q种E度。在涉及(qing)C同信d中多?Web 服务的复杂情况下Q还得徏立自定义的特D解x案。Microsoft 和其他公司正致力于创Z套安全性规范,该规范将Z SOAP 消息的可扩展性提供消息别的安全性功能。这些规范之一?XML Web 服务安全性语aQWS-SecurityQ,它ؓ(f)消息U别的凭据传输、消息完整性和消息保密定义?jin)框架?/p>
正如上一节所qͼ一般情况下Q?NET Remoting 线不能保跨进E调用的安全。?ASP.NET 托管?IIS 中的 .NET Remoting 端点可以利用 ASP.NET Web 服务可用的所有安全性功能,包括对?SSL 保有线通信的安全性的支持。如果?zhn)正在使用托管在进E中?TCP 信道?HTTP 信道Q而不?aspnet_wp.exeQ,则必自己执行n份验证、授权和保密机制?
另一个要x的安全性问题是Q在不必更改默认安全性策略的情况下,从不完全信Q的环境中执行代码的能力。ASP.NET Web 服务客户端代理可以在q些环境中工作,?.NET Remoting 代理则不能。要从不完全信Q的环境中使用 .NET Remoting 代理Q需要特D的序列化权限。默认情况下Q该权限不会(x)授予?Intranet ?Internet 上下载的代码。如果要在不完全信Q的环境中使用 .NET Remoting 客户端,则需要更改从那些区域中加载的代码的默认安全性策略。当(zhn)从q行于沙(如下载的 Windows H体应用E序Q中的客L(fng)q接到系l时QASP.NET Web 服务是较单的选择Q因Z需要更改安全性策略?/p>
状态管?/p>
默认情况下,ASP.NET Web 服务模型采用无状态的服务l构Q它q不是本能地与来自同一个用L(fng)多个调用相关。另外,客户端每ơ调?ASP.NET Web 服务Ӟ都创Z个新的对象以服务于该h。方法调用完成后Q该对象卌破坏。要l护h之间的状态,可以使用 ASP.NET 面使用的相同技术(例如QSession ?Application 属性包Q,也可以自己实现自定义的解x案?
.NET Remoting 支持许多状态管理选项Qƈ且可能与来自同一个用L(fng)多个调用相关或不相关Q这取决于?zhn)选择的对象生命周期架构。SingleCall 对象是无状态的Q如用于调用 ASP.NET Web 服务的对象)(j)QSingleton 对象׃n所有客L(fng)的状态,客户端激zȝ对象在每个客L(fng)的基上保持状态(带有其生的所有相关的可升U性和可靠性问题)(j)?/p>
性能
从原始性能斚w来讲Q?TCP 信道和二q制格式化程序时Q?NET Remoting 线能够提供最快的通信。在我们q行的比?ASP.NET Web 服务?.NET Remoting 的相Ҏ(gu)能的几乎所有的试中,ASP.NET Web 服务在性能上都出?jin)?HTTP ?TCP 信道?SOAP 格式化程序的 .NET Remoting 端点。更有意思的是,使用二进制格式化E序?HTTP 信道?ASP.NET ?.NET Remoting 端点在性能上非常相q。(更多信息Q请参见 Performance Comparison:NET Remoting vs. ASP.NET Web Services。)(j)
企业服务
ASP.NET Web 服务或通过 .NET Remoting 提供的对象可以用本C务根据单个数据库协调工作。如果需要根据多个资源协调工作,可以使用 .NET 企业服务Q又U?COM+Q公布的事务Q由 COM+ 线理?DTC 分布式事务)(j)。但要注意的是,ASP.NET Web 服务?.NET Remoting 线都不能传播公布的事务Q因此两U端炚w不可能通过跨进E的调用l承公布的事务?/p>
q不一定是件坏事。一般来Ԍ公布的事务比本地事务代h(hun)要高Q而要跨进E传播公布的事务Q则代h(hun)?x)更高。如果确实需要这一功能Q简单的解决Ҏ(gu)是在 .NET 企业服务的服务器应用E序中部|一个从 System.EnterpriseServices.ServicedComponent z的类Q更多信息,请参?COM+ Integration:How .NET Enterprise Services Can Help You Build Distributed ApplicationsQ。对该类对象的跨q程调用?DCOM q行处理Q以保正确传播事务环境。较隄解决Ҏ(gu)是用底层的 APIQ手动传播分布的事务?/p>
值得注意的是Q传l的分布式事务模型一般不适用于松散耦合?Web 服务。基于补偿事务的模型Q即Q撤消其他事务所提交工作的事务)(j)更有意义Q因为其隔离U束条gq不是很严格。在包括 Microsoft ?Web 服务供应商中有一U普遍的说法Q即 Web 服务I间需要的事务模型灵z,该空间中q行的工作越多。等到定义出 Web 服务事务的标准方法时Q?zhn)可以根据情况用本地或公布的事务实现自q补偿架构?jin)?/p>
结
虽然 .NET Remoting 基础l构?ASP.NET Web 服务都可以进行跨q程通信Q但每种设计适用于不同的用户。ASP.NET Web 服务提供?jin)简单的~程模型Qƈhq泛的用范围?NET Remoting 提供?jin)较为复杂的~程模型Q而且使用范围H得多。请务必?jin)解q两U技术的工作原理Qƈ选择适合(zhn)应用程序的技术。在L一U情况下Q都要?IIS ?ASP.NET 理q程生命周期Qƈ提供一般的安全性?/p>
一 .NET Framework代码的移?/p>
使用.NET Framework的各U语a~写的代码,通过各种语言对应的编译器Q最后都生成为IL中间语言代码Q而这样中间语a?/p>
与CPU的架构无关的Q当IL中间语言在各UCPU上面的执行时才生成Native的CPU直接执行的指令。IL代码是在CLR通用语言q行时中?/p>
行的Q所以我们也U?NET Framework~写的代码ؓ(f)Managed托管代码。正是由?NET Framework的这U运行机Ӟ使得?NET
Framework~写的代码,几乎不用改写代码可以移植到64位系l上?/p>
1) 大部分存在的托管应用无需重新~译Q便可以直接?2位和64位上工作?br>2) ?2位系l上的pe文g格式在新?4位中E有改变Q表CZpe+?br>3) Framework 1.0Q?.1的代码作?2位在64位的WOW64上运行,Framework 2.0的代码在64位上作ؓ(f)64位直接运行?br>4) 如果是只有托代码,则可以编译ؓ(f)Any cpu (q有x86Qx64Qipf),可以在x86Qx64Qipf上运行?/p>
?托管代码与Native代码的互调用的移?/p>
1)32位和64位的代码不能在同一q程中执?Q由于可以用的内存大小不同Q所使用的页文g大小不同?br> 2)如果?2位和64位的互调用,则统一都移植ؓ(f)64位?br> 3)也可以通过q程外互操作实现32位和64位的互调用?br> 4)几种互操作实现技术:(x)COM依赖QWin32依赖Q用代理进E技术(dllhost.exeQ?/p>
?32位在64位上的执?/p>
像我们的32位系l上可以执行16位的E序一P?4位的pȝ上也提供?jin)向后兼?2位程序。在64位的pȝ上用WOW64?/p>
供对32位的支持Q但是不再支?6位程序的q行。大部分32位应用程序能够运行在WoW64中,h在原生Windows 32位上几乎相同?/p>
Ҏ(gu)?br> 1)WoW64如何工作:WoW64?2位应用程序截取系l调? 转变?4位模? ?2位数据结构{换ؓ(f)64位对齐结?发出原生64位系
l调??4位系l调用写回Q何输出数?q回?2位模式?br> 2) 囄WOW64的调用和执行q程Q?br>
上图用过E,下面是执行过E:(x)
最后大家好q!有兴的可以l箋学习(fn)sql?4位移植,在微软的webcast|站?/p>
Term | Description |
---|---|
DWORD32 | 32-bit unsigned integer |
DWORD64 | 64-bit unsigned integer |
INT32 | 32-bit signed integer |
INT64 | 64-bit signed integer |
LONG32 | 32-bit signed integer |
LONG64 | 64-bit signed integer |
UINT32 | Unsigned INT32 |
UINT64 | Unsigned INT64 |
ULONG32 | Unsigned LONG32 |
ULONG64 | Unsigned LONG64 |
Term | Description |
---|---|
DWORD_PTR | Unsigned long type for pointer precision. |
HALF_PTR | Half the size of a pointer. Use within a structure that contains a pointer and two small fields. |
INT_PTR | Signed integer type for pointer precision. |
LONG_PTR | Signed long type for pointer precision. |
SIZE_T | The maximum number of bytes to which a pointer can refer. Use for a count that must span the full range of a pointer. |
SSIZE_T | Signed SIZE_T. |
UHALF_PTR | Unsigned HALF_PTR. |
UINT_PTR | Unsigned INT_PTR. |
ULONG_PTR | Unsigned LONG_PTR. |
Term | Description |
---|---|
POINTER_32 | A 32-bit pointer. On 32-bit Windows, this is a native pointer. On 64-bit Windows, this is a truncated 64-bit pointer. |
POINTER_64 | A 64-bit pointer. On 64-bit Windows, this is a native pointer. On 32-bit Windows, this is a sign-extended 32-bit pointer.
Note that it is not safe to assume the state of the high pointer bit. |