Innovate the future

有些书上也称“代表”或“委托”
C#中取消了指针的概念。对指针恋恋不舍的程序员可以有两种解决方法：声明“非安全”（unsafe）代码段然后在其中使用指针或者使用C#的一个引用类型——“代理”（delegate）。“代理”相当与C中的函数指针原型，区别是C#是类型安全的。

“代理”（delegate）（代表、委托）“代理”是类型安全的并且完全面向对象的。
（1）在C#中，所有的代理都是从System.Delegate类派生的（delegate是System.Delegate的别名）。
（2）代理隐含具有sealed属性，即不能用来派生新的类型。
（3）代理最大的作用就是为类的事件绑定事件处理程序。
（4）在通过代理调用函数前，必须先检查代理是否为空（null），若非空，才能调用函数。
（5）在代理实例中可以封装静态的方法也可以封装实例方法。
（6）在创建代理实例时，需要传递将要映射的方法或其他代理实例以指明代理将要封装的函数原型（.NET中称为方法签名：signature）。注意如果映射的是静态方法，传递的参数应该是类名.方法名，如果映射的是实例方法，传递的参数应该是实例名.方法名。
（7）只有当两个代理实例所映射的方法以及该方法所属的对象都相同时，才认为它们是想等的（从函数地址考虑）。
（8）多个代理实例可以形成一个代理链，System.Delegate中定义了用来维护代理链的静态方法Combion，Remove，分别向代理链中添加代理实例和删除代理实例。
（9）代理的定义必须放在任何类的外面，如delegate int MyDelegate()；而在类的方法中调用MyDelegate d = new MyDelegate(MyClass.MyMethod)；来实例化自定义代理的实例。
（10）代理三步曲：
 a．生成自定义代理类：delegate int MyDelegate();
 b．然后实例化代理类：MyDelegate d = new MyDelegate(MyClass.MyMethod);
 c．最后通过实例对象调用方法：int ret = d();

简单对象访问协议（SOAP）是W3C组织的一个Note, 它描述了一种在分散的或分布式的环境中如何交换信息的轻量级协议。SOAP是一个基于XML的协议，它包括三个部分：SOAP封装(Envelop)，封装定义了一个描述消息中的内容是什么，是谁发送的，谁应当接受并处理它以及如何处理它们的框架；SOAP编码规则（Encoding Rules），用于表示应用程序需要使用的数据类型的实例；SOAP RPC表示(RPC Representation)，表示远程过程调用和应答的协定；SOAP可以和多种传输协议绑定（Binding），使用底层协议交换信息。在这个文档中，目前只定义了SOAP如何和HTTP以及HTTP扩展进行绑定的框架。

SOAP是个通信协议， SOAP在HTTP协议的基础上，把编写成XML的REQUEST参数, 放在HTTP BODY上提交个WEB SERVICE服务器(SERVLET，ASP什么的) 处理完成后，结果也写成XML作为RESPONSE送回用户端， 为了使用户端和WEB SERVICE可以相互对应，可以使用WSDL作为这种通信方式的描述文件，利用WSDL工具可以自动生成WS和用户端的框架文件，SOAP具备把复杂对象序列化捆绑到XML里去的能力。

SOAP的前身是RPC, 就是远程呼叫处理的协议，这个协议安全性不是很好，多数防火墙都会阻挡RPC的通信包，而SOAP则使用HTTP协议作为基本的协议，使用端口80使得SOAP可以透过防火墙，完成RPC的功能。

SOAP协议和HTTP协议一样，都是底层的通信协议，只是请求包的格式不同而已，SOAP包是XML格式的，现在我们编写WEB SERVICE不需要深入理解SOAP也没关系。如果SERVICE和CLIENT在同样的环境下使用SOAP，由于一般情况下都有自动生成SOAP程序框架的工具，因此不知道细节也没关系. 可是, 如果CLIENT和SERVICE的环境不同，比如说JAVA的Client和.NET的SERVICE进行通信，或者是VB CLIENT和TOMCAT下的JAVA SERVICE通信，还是要知道一点细节为好. 特别是, WSDL或者UDDI都不是标准，如果不让用就只好手工配制SOAP MESSAGE啦。

    目前主要有三种网络负载平衡转发技术，分别是网络地址转换、直接路由和IP隧道技术，采用不同的方法将客户端发送的包转发到目的服务器上，并确保目的服务器的返回包可以顺利到达客户端。通过ArcGIS Server的体系结构，可以发现对基于ArcGIS Server的企业级应用进行负载平衡的测试应用，需要从Web服务器、ArcGIS Server（SOM＋SOC）、ArcSDE（主要从Oracle的角度出发）这几个层次考虑和分析。
      1、Web服务器的负载主要考虑通过对Web服务器的网络载荷进行监听，配置多余的服务器环境。在正常运行的时候，通过负载平衡软件对用户的请求进行分配，保持网络载荷的平衡；在有服务器发生故障时，只向正常工作的服务器发送信息。同时每个服务器需要一个完整的数据备份。
      2、ArcGIS Server的负载平衡由一个镜像的AGS的SOM配置提供。
      3、ArcSDE的负载策略集中于数据库的负载策略。对于ArcSDE For Oracle来说，解决Oracle的负载平衡和集群技术比较关键。
      集群系统通过连接一台或多台电脑，使它们对客户端好像一台机器。数据存放在一个共享的磁盘中。使用集群的主要目的就是提供系统的容错功能（其中一台当机不影响使用，但应用程序的内存不被传递），通过可以添加或减少接点进行水平伸缩。集群主要是从系统的容错能力以及可扩展性角度描述了系统的设计策略。同时系统良好的可扩展性也会增加系统处理网络载荷的能力。
1) 集群系统基本需求：
     ArcSDE8.1以上的版本；推荐使用直接连接的方式；需要SDE的License；Oracle 10g或者Oracle 9i企业版
2) 在MSCS（Microsoft Cluster Services）上安装ArcSDE
     MSCS已经包含在Windows 2000高级服务器版以及Windows 2003企业版中。Cluster Services包含和管理所有作为容错服务器的主机。Cluster Server可以在备份节点上自动重启Oracle数据库和应用。
先安装DBMS和其他所需组件；在第一个节点上安装ArcSDE，安装在共享的磁盘阵列上；切换到第二个节点；使用第一个节点创建的ArcSDE目录创建ArcSDE服务
3) RAC（Oracle Real Application Cluster）
    可以利用相互连接的主机上的计算能力；所有的实例都可以并发的处理事务，数据库放在共享磁盘上；可以实现对应用程序，如ArcSDE的水平扩展。

ERDAS发布的三维景观

1．ArcGIS Engine和ArcGIS Server的交叉点，是否可以利用ArcGIS Engine直接开发成COM组件，然后由ArcGIS Server调用，或者先通过Web Services的方式调用，再通过ArcGIS Server调用Web Services

可以利用Engine开发COM组件的方式，然后由ArcGIS Server直接调用，或者通过类的方式来集成，（但是Engine提供的组件的实现和逻辑应该分开，即Engine开发组件不能带有界面，而只能通过Engine来实现封装特定功能的组件，因为IE和开发COM组件的界面无法融合），同时，Engine提供的组件必须提供符合Server要求的统一接口。

如果部署在一台服务器上，也可以通过Web Services的方式进行集成。  

2．开发Web应用程序，是否可以只采用ArcGIS Server，而不需要ArcGIS Engine。如果使用Engine的话，优势主要体现在哪些方面？
开发Web应用程序，可以只采用ArcGIS Server，可以不需要ArcGIS Engine。因为Server和Engine底层的API是相同的。而采用何种架构模式取决于用户需求和具体的应用。两者实现的方式有一定的差别。  

3．ArcGIS Server和ArcIMS的关系。
ArcGIS Server是否可以取代ArcIMS，如果不能的话，它们的侧重点各是什么？ArcGIS Server是否可以用于地图数据发布？ ArcGIS Server可以代替ArcIMS，但是必须有高效的服务器，同时实现很好的负载平衡。ArcIMS适合高性能的地图数据发布，它提供的功能比较简单（只具备Viewer的操作），但是速度明显优于ArcGIS Server。而ArcGIS Server可以实现所有Engine可以实现的功能，包括一些高级的GIS功能，比如空间分析等 

4．ArcGIS Server部署方案
采用ArcGIS Server开发，部署时推荐使用Windows 2003 Server，有利于负载平衡。也可以采用2000 Pro/XP，但是最好采用Server平台  

5．Server Objects
A server object is a coarse-grained ArcObjects component that runs in a process on the SOC machine. ArcGIS Server comes with two out-of-the-box server objects:
  .esriCarto.MapServer
  .esriLocation.GeocodeServer 

6．池式和状态
Pooled server objects are expected to be used in a stateless manner. As a developer, you are responsible for making sure that the state of the server object, or its associated objects, has not changed when you return the object to the pool (by releasing its context via ReleaseServerContext).Each time a user or application session makes a request to create a pooled server object, it’s indeterminate which running instance it will get out of the pool; therefore, all instances must have the same state or applications will experience inconsistent behavior.

Non-pooled server objects can be used in a stateful manner. Since nonpooled server objects and their contexts are destroyed when you release them, you need to hold onto them for as long as the state is important to you. When you call ReleaseServerContext, or you allow the server context to go out of scope, the server object and its context are destroyed, purging any state changes you made.

7．状态管理
有状态（状态发生改变的时候）——非池式的服务器对象（或者池式的服务器对象，但在释放返回服务器上下文的时候能恢复的原来起始的状态，这种情况比较少）
无状态（状态不改变）——池式的服务器对象（也可以使用非池式的服务器对象，但不能发生状态的改变，这种情况比较少）

 
8．状态改变
调用服务器对象状态的方法：
      从地图的服务器对象中增加/删除图层 
      改变服务器对象中图层的Renderer

调用环境状态的方法：可以作用于池式/非池式的服务器对象，但是在池式的服务器对象中，应用程序在执行操作前不应该依赖处于特殊状态的环境；如果应用程序依赖于环境的状态时，在执行操作前要求设置所需要的环境状态
 

9．SCALABILITY的关键在于GIS Server的状态性，保持应用程序Scalability的标准
使用无状态的GIS Server
池式的服务器对象
减少应用程序控制服务器对象的时间。及时地释放服务器对象，不能仅仅依赖于.NET自带的垃圾回收系统

1.     ArcGIS Server开发模式与我们平时开发模式的区别和联系，理解什么是ArcGIS Server，Web编程（服务端和客户端如何交互）等关键概念

2.     理解ArcGIS Server体系结构，