This project is read-only.

=========================================
= 5月3日进度
=========================================
1. 已经初步完成 IServiceHandle的逻辑部分。
2. 完成了HostService的逻辑部分。
3. 应用了绑定元素进行服务宿主
4. 对于HostChannel的开启和关闭仍然需要注意,这点需要再仔细的看下。
5. 另外,日志记录器貌似不是特别稳定,需要修改下。
6. 完成了对于开放操作以及开放服务Attribute的逻辑部分。
7. 对于二进制网络协议逻辑部分已经编写完成,已经支持安全验证(Certificate)。
8. 对于方法,参数的拆分(IBinaryArgContext)已经完成。


下一步要做的工作:
1. 定制CONNECT.技术的配置文件树
2. 初步建立ServiceHost类,并可以根据配置文件读取相应设置。
3. 初步扩展属性,支持并发。
4. 编写一个对于ServiceMessage的解析器。
5. 初步的把上层通道模式应用于TransportChannel层。

=========================================
= 5月10日进度
=========================================
1. 编写ServiceRequestDispatcher中,要根据服务发布类型的不同而选择不同的分发模式。



=========================================
= 5月19日进度
=========================================
1. 对于底层传输通道所使用的消息契约,全部使用智能对象类型(IntellectObject)进行替换。
2. 对于底层消息契约的支持,全部转移为使用内置的智能二进制消息框架(Intellect Message Framework)。
3. 封装了上层应用消息 :
(1). RequestServiceMessage : 用于向服务操作契约发起请求时使用,里面包含了发情请求的详细信息。
(2). ResponseServiceMessage : 用于服务操作契约回馈请求结果时使用,里面包含了回馈结果的详细信息。
(3). 上述2个消息均为智能对象。
4. 对于底层传输通道,当接收到请求时的分发处理,由原来的轮询回调,变更为现在的:并发回调。
5. 将IBinaryArgContext制定为一个智能对象。
6. 编写了分发器层,以及应对与不同需求的核心分发器。分发器的作用在于,将一个请求根据服务开放的基本规则,
通过不同的方式,分发到一个指定的服务实例上。目前预设的核心分发器为3个档次(单实例分发器,多线程分发器,多核并发分发器)。
7. 完成了传输通道(Transport Channel)与通道栈(Channel Stack)的对接工作。
8. 完成了通道栈(Channel Stack)与服务句柄包装器(Service Handle)的对接工作。


=========================================
= 5月21日进度
=========================================
1. 完成了整个服务契约操作请求的所有步骤。
2. 完成了契约操作返回值的衔接操作。
3. 创建了请求中心(RequestingCenter),用于将请求和ACK结果进行衔接。
4. 添加了请求观察者(RequestAckObserver),用于监视返回的结果。
5. 完成了接口级的优化操作,现在已经能够支持使用接口来声明服务契约操作了。

下一步要做的工作:
1. 初步实现服务实例调用时,可获取调用上下文操作(Get call context)。
2. 初步设计针对于客户端动态代理的封装。
3. 增加对于开放服务契约时,服务操作的参数检查。
4. 初步改造请求中心(RequestingCenter),使其为了今后的回调(Callback)接口,做出扩展能力。


=========================================
= 5月28日进度
=========================================
1. 支持了服务契约操作请求后的返回值。
2. 支持了内部服务契约外抛异常。
3. 建立了ClientBase<T>客户端基础类,内部封装了关于动态代理的基础层信息(事件关联,植入观察者...)。
4. 已经完全走通服务操作请求流程(包括最后返回值)。
5. 修改了一个BUG, 修改后的逻辑是:对于每次的请求都会使用一个新的会话编号(Session Code)。
6. 请求中心(RequestingCenter)增加了GetResponse<T>方法,用于Catch回馈对象,并初步支持了请求超时功能。
7. 实现了在服务契约操作中,可获取调用的上下文操作(Get Service Call Context)。
8. 完成了动态客户端的封装。


下一步要做的工作:
1. 初步设计基于客户端动态代理的缓存解决方案。
2. 增加对于开放服务契约时,服务操作的参数检查。
3. 初步改造请求中心(RequestingCenter),使其为了今后的回调(Callback)接口,做出扩展能力。
4. 改造智能配置文件读取器,并初步设计CONNECT.技术的的配置文件树。

初步预想的配置文件树结构(Version 1):
-------------------------------------------------------------------------
<kjframework.servicemodel>
<services>
<service name="" contract="">
<endpoint binding="" address=""/>
</service>
</services>
<client>
<endpoint address="" contract="" binding="" name=""/>
</client>
<bindings>
<pipeBinding bufferSize=""/>
<netTcpBinding />
<basicHttpBinding />
</bindings>
</kjframework.servicemodel>

=========================================
= 6月18日进度
=========================================
1. 扩展了OperationAttribute,使其增加了IsOneWay属性,通过将一个契约操作标记该属性,使得此操作将不会关心服务器的回传信息,节省服务器开销,
同时也节省了客户端注册观察者的成本。
2. 正式启用了RequestServiceMessage的NeedAck属性,此属性用来通知契约拥有方是否需要回传关于执行操作的结果状态。(此属性与上述的IsOneWay
属性相呼应)。
3. 增加了开放服务契约时的检查,专门用于检查当一个契约操作标注了IsOneWay属性,但是却有合法返回值的时候。(不允许这种情况的出现)
4. 编写了另外2种开放服务契约的模式(Singleton单一实例模式,以及Concurrent并发模式)。
5. 优化了2处代码,减少了对象装箱所带来的开销。
6. 修改了唯一标示生成器(KeyGenerator)的一处BUG。

=========================================
= 6月22日进度
=========================================
1. 加入了IMessageChunkOutputPin, 这是一个消息PIN的概念,通过这个数据端,使得服务器与客户端之间的消息在超过固定大小后将会自动分包发送。
2. 加入了SubServiceMessage消息 (支持分包)
3. 加入了SubServiceMessageHeader消息头 (支持分包)

下一步要做的:
-------------------------------------------------------------------------
1. 编写封包片缓存容器,用来保存封包片,以及支持最基础的拼接封包片操作。


=========================================
= 6月23日进度
=========================================
1. 同时支持了2种消息数据端(Input Pin, OutPut Pin)。
2. 加入了分包包裹和封包片的概念(ISubMessagePackageCache, ISubMessagePartCache)。
3. 支持对于超出额定长度的消息自动分包,自动拼包。
4. 支持分包消息超时处理。
5. 更新了最底层传输通道的传输策略,使其支持服务编号(Service Key)


=========================================
= 6月24日进度
=========================================
1. 优化了服务器端异常的情况,使得,客户端只要能够引用服务端契约,就可以支持在客户端抛出服务器端指定的异常(ThirdParty Exception Supported)。
2. 高度优化了服务器请求返回值(IServiceReturnValue)的字节大小,经过测试,如果服务器端请求出现异常,返回的请求返回值(IServiceReturnValue)
最大不超过2.5K。


下一步要做的:
-------------------------------------------------------------------------
1. 尝试开启服务消息协议(Service Message)的压缩标记位(IsZip)。
2. 尝试开启服务消息协议(Service Message)的加密标记位(IsEncrypt)。





=========================================
= 7月21日进度
=========================================
1. 编写了基于TCP协议的,绑定对象,绑定元素,URI对象。
2. 更新ChannelHelper类中的方法,使其支持TCP Channel。

下一步要做的:
-------------------------------------------------------------------------
1. 能够读取TCP数据,并解析成为一个消息体。
2. 调试TCP方式通讯,使其正式成为KJFramework.ServiceModel中的一种通讯方式。




=========================================
= 7月23日进度
=========================================
1. KJFramework.ServiceModel正式支持了TCP通讯方式。






=========================================
= 7月27日进度
=========================================
1. 支持传递“智能对象”类型的参数。
2. 修改了返回值不能为null,的BUG。
3. 二进制参数 (Binary Arg)支持了对于智能对象类型的转换。




=========================================
= 7月30日进度
=========================================
1. 优化了请求中心(Request Center),使用信号量同步取代了原有的轮训判断。
减少了判断中对于字典(Dictionary.ContainsKey的锁定,加快了搜索速度。)
[注]:对于多客户端请求,偶尔返回失败的问题,暂时使用lock来解决。



=========================================
= 8月12日进度
=========================================
1. 解决了处理MessageChunkInputPin时,内存泄露的问题。
2. 更新了TcpTransportChannel,PipeTransportChannel内部断开逻辑。



=========================================
= 9月8日进度
=========================================
1. 池化了ResponseServiceMessage
2. 池化了ServiceReturnValue
3. 修改了调用方法异常时每次NEW异常的情况

###############################################
# 注意:
# 检查内存泄露,以及线程使用的问题。
###############################################



=========================================
= 9月11日进度
=========================================
1. 池化了RequestCenterWaitObject
2. 池化了RequestMessageTaskBoxObject
3. 增加了任务箱子(Task Box)的概念.
4. 增加一个请求任务箱子,用来保存瞬间产生的大量请求消息,并由可配置的指定数量线程进行分发处理。
5. 去除了多线程同步的一个BUG,优化了多客户端的性能问题。
6. 优化了RequestMethodObject添加和查找参数时的LINQ,改用BinaryArgContext.Id来进行索引。

下一步优化策略:
------------------------------------------
1. 优化服务调用上下文。



=========================================
= 9月14日进度
=========================================
1. 池化了服务调用上下文
2. 将分发器的每次内存分配,改为了静态调用,减少内存碎片
3. 尝试引入了缓冲区,而缓冲区设置的粒度是为每一个传输通道配备一个缓冲区
4. 将池化的参数以及缓冲区大小的设置从HARD CODE移到了配置文件中,并建立了新的配置节



下一步优化策略:
------------------------------------------
1. 尝试解决对于字节数组的COPY性能问题
2. 尝试解决针对于字节数组的内存碎片问题。
3. 梳理整个调用流程中,多线程方法,以及可能会引起多客户端堵塞的地方


=========================================
= 9月16日进度
=========================================
1. 更新了RequestServiceMessage中Header的协议,增加了LogicalRequestAddress字段,
增加该字段后,直接的支持了同端口多分支服务的请求操作。
2. 增加了ServiceCenter, 用于记录开放不同契约时的服务句柄,为了今后的消息路由派发做基础支持。



=========================================
= 9月20日进度
=========================================
1. 更新了服务发布方内部执行方法时使用MethodInfo的问题,这样的执行会带来效率上的问题, 经过更新后
已经修改为使用MSIL动态执行,并加上相关的Cache操作。
2. 优化了Core Dispatcher在处理请求时,重新创建参数数组的问题,这个操作是重复的,因为在反序列化
请求消息的时候,已经将请求的参数集合设置为一个数组。 经过改动后,只需要使用原来的数组即可。
3. 更改了客户端发送请求时的方式,由原来的并行发送,改为线程同步发送。

###############################################
# 注意:
# 检查多客户端请求时的多线程问题。
###############################################


=========================================
= 9月21日进度
=========================================
1. 更改了返回值的序列化方式,从原来的.NET序列化变更为智能对象,并且存储格式改为:IBinartArgContext


###############################################
# 注意:
# 优化客户端返回值速度问题
###############################################


=========================================
= 9月25日进度
=========================================
1. 优化了请求中心(Requesting Center)的同步等待流程,减少了初始化对象并等待CPU间隔时间片运行的成本。
2. 优化了请求中心(Requesting Center)的判断流程,删除了一些不必要的判断。



=========================================
= 9月27日进度
=========================================
1. 将任务箱子所使用的线程数量改为可配置。




=========================================
= 9月28日进度
=========================================
1. 更新了服务侧查找对应契约方法的逻辑,铲除了一个污点算法,修改后的逻辑是使用MethodToken来代替使用
String.Format生成的Method唯一标识,这样做的好处是,减少了每次生成唯一标识的问题,减少了字典锁,
因为他的读是服务启动后的,而写部分只是服务初始化才做的,所以完全可以认为是读写分开,并且线程安全的。
对于此次修改,客户端侧来讲,缩减了方法请求对象的总体字节大小,相对意义上优化了传输速度。
2. 更新了动态生成客户端代理的部分代码,修改了外抛Method Token的逻辑,当指定契约操作公开了Method Token
时,则使用公开的,否则就自己生成。
3. 在OperationAttribute中,新增了属性:MethodToken, 此新增的属性是为了今后远程发布服务契约而特地预备的,
当本地引用契约程序集时,是不需要设置此属性的,只有当未来通过远程获取服务契约副本时,才会标记该属性。
--------------------------------------------------------------------------
【重点】找到了一个污点:
1. 在生成唯一Session时,目前使用的是16位的MD5值,但是这个成本非常大,是个大大的污点,消耗性能和浪费时间
目前正在寻找到可代替的方案,比如使用INT类型方法来代替字符串的那种16位MD5。



=========================================
= 10月13日进度
=========================================
1. 更新了生成会话码(Session Code)的技术细节,从原来的16位MD5会话码变为现在的数字类型, 直接的导致了性能的提升
并且将原有大粒度的锁lock, 变为了更加原子性的锁。
2. 修正了存在于PIPE通讯方式传输通道中的分包BUG,修正后能够通过正确的serviceId来判断消息类型了。
3. 将消息数据段最大长度的限制,从Hard Code的形式改为使用配置节进行配置。
4. 修改了对于TransportChannel中Send方法的设计,采用base + InnerSend的方式,在父类TransportChannel中的Send
函数将会自动判断是否需要分包的需求,然后才会调用具体传输通道中的InnerSend方法。


==========================================
= 10月18日进度
==========================================
1. 已经初步实现了契约操作的异步模型(Async Method Model),但是此模型现在还是要依靠重置契约,并且标记属性才能完成。
2. 为请求中心提供了添加/移除回调函数的操作,用于支持客户端的异步操作行为。
3. 目前基于客户端操作的异步回调,是使用的前置添加行为,也就是说要想实现一个异步方法,需要如下准备工作:
(1). 重置契约(添加属性标签等等)
(2). 为异步操作添加回调函数
(3). 执行操作请求



==========================================
= 10月26日进度
==========================================
1. 已经实现了为每一次的异步调用产生独立的回调函数,并且能够初步保证上下文是同步的,也就是说不会出现在A线程调用的构造函数却
触发了其他调用的回调函数。
2. 经过认证,决定采用的新的异步契约操作模型(New Async Contract Operation Model, ACOM),虽然内部实现的很复杂,但是暴露给
外部的接口却很少,能够做到在高层次面上深度隐藏对于异步的底层实现,而不会使用户在一大堆的异步API面前发愁,当然,如果要将
一个同步执行的方法改为异步执行,是需要重写契约的(将Operation Attribute的IsAsync设置为:true)。
3. 为IAsyncMethodDelegator专门设置了超时器,默认的触发时间间隔为:1分钟,也就是说每隔1分钟,都将会自动移除那些已经过期的
回调函数。 当一个回调被移除之前,会先触发该回调函数,方法签名如下:
public delegate void AsyncMethodCallback(bool isComplated, params Object[] parameters);
(1). isComplated参数用来当做是否完成的标示,如果isComplated = true, 则parameters为返回的结果, 如果isComplated = false
则parameters返回的是一个失败的原因。


下一步需要做的事情:
---------------------------------------
1. 尝试设计基于批处理请求的底层通信协议,用来初步的支持契约操作的批量操作。
2. 优化客户端的逻辑,使其能够提供更快的速度。
3. 优化服务端的Response逻辑



==========================================
= 12月29日进度
==========================================
1. 优化了客户端传递一个数组时的字节序列化方式
2. 优化了服务器端接受一个数组参数时的字节序列化方式
3. 优化了网络层获取传输通道时的方法
4. 增加了服务契约描述(IContractDescription)
5. 增加了服务契约方法描述(IDescriptionMethod)
6. 增加了服务契约方法参数描述(IDescriptionArgument)
7. 增加了服务契约详细信息接口(IContractInfomation)
8. 为服务契约Attribute分别加入了如下几个属性:Name, Description, Version
9. 增加了IMetadataExchange接口,用于支持IServiceHandle服务句柄的服务契约发布功能。
10. 增加了服务契约描述包装器(IContractDescriptionWrapper), 用于发布服务契约元数据时的不同数据类型(比如XML, WDSL)。



下一步需要做的事情:
---------------------------------------
1. 尝试在网络层开启一个HTTP入口,用于呈现当前服务器所开放的服务契约,从而能够发布服务契约元数据。
2. 尝试设计在服务器端开放一个性能监控入口(HTTP Protocol).
3. 优化服务端的Response逻辑



==========================================
= 12月31日进度
==========================================
1. 增加了元数据交换网络节点(IMetadataExchangeNode)接口
1. 实现了基于HTTP协议的元数据交换网络节点(HttpMetadataExchangeNode)
3. 增加了元数据交换页面动作(IMetadataPageAction)接口
4. 实现了服务契约Root页面动作(HttpMetadataContractRootPageAction)
5. 实现了服务契约操作页面动作(HttpMetadataContractOperationPageAction)
6. 在ServiceCenter中开了一个HTTP入口,用于开启元数据公布节点(HTTP协议)。
7. 修改了IDescriptionMethod中部分处理的BUG.
8. 在DLL中内嵌了一个Contract Root的发布页面。





==========================================
= 2011年1月3日进度
==========================================
1. 增加了服务契约预览页面动作(HttpMetadataContractPreviewPageAction),用于生成契约预览
2. 开启服务时,为服务契约开放了/Preview/节点的页面
3. 增加了Operation描述页面(OperationPage.htm), 用于描绘契约操作
4. 修改了契约链接, 使用Method Token进行标示



==========================================
= 2011年1月20日进度
==========================================
1. 增加了服务契约生成页面动作(HttpMetadataContractGeneratePageAction), 用于生成服务契约中所拥有的所有数据格式
2. 在元数据交换节点中(MetadataExchangeNode), 加入了判断是否为.NET FRAMEWORK内置类型的静态方法
3. 增加了一个新的HTTP方式交换元数据地址(/Metadata/)




==========================================
= 2011年1月23日进度
==========================================
1. 增加了返回值可以是枚举类型(Enum Type)的功能实现





==========================================
= 2011年3月3日进度
==========================================
1. 增加了程序集缓存(Assembly Cache).
增加这个缓存的原因是为了当动态加载程序集时(Dynamic load library),无法通过Type.GetType()来获取到指定内容的类型事例,
所以现在的所发是,加入一个程序集缓存,如果Type.GetType()返回为null时,则默认搜索当前程序域的所有程序集,并找到合适的做缓存。




==========================================
= 2011年3月4日进度
==========================================
1. 修改了核心分发器中,无法Giveback返回值对象的BUG。
2. 修证了核心分发器中Giveback的逻辑。





==========================================
= 2011年4月16日进度
==========================================
1. 使TCP传输通道支持了分包传输的逻辑
2. 更新了传输通道(TransportChannel),提取了一个处理分包逻辑的方法
3. 修正了命名管道中,接受数据BUFFER长度的问题,统一改成了按照配置节中的数据来读取
4. 更新了RequestServiceMessageParser,用于正确的找到Protocol Id的位置
5. 更新了ResponseServiceMessageParser,用于正确的找到Protocol Id的位置




==========================================
= 2011年4月20日进度
==========================================
1. 创建了基于TCP协议的原始数据流传输通道(RawTcpTransportChannel)





==========================================
= 2011年5月8日进度
==========================================
1. 更新了BinaryArgContext查找目标参数类型的算法
2. 更新了ServiceMethod,增加了GetPrarmeterType方法



==========================================
= 2011年5月13日进度
==========================================
1. 更新了BinaryArgContext查找返回值类型的算法
2. 由于算法的优化,去除了BinaryArgContext每次都要设置参数全名的字符串



==========================================
= 2011年5月30日进度
==========================================
1. 为CONNECT.技术内部增加了性能计数器的Owner
2. 改写了ServiceHandle的构造函数, 会初始化性能计数器
3. 为CONNECT.内部增加了回调次数和执行成功次数、执行失败次数的性能计数器



==========================================
= 2011年6月21日进度
==========================================
1. 更新了开放HTTP元数据节点的逻辑,已经抛弃了抱死80端口的逻辑,改为了动态获取空闲端口。
搜索范围:tcp port(65300~65535)
2. 修改了开放HTTP元数据节点时,服务契约名字很长的问题,当一个需要开放的服务标记了ServiceMetadataExchangeAttribute
标签时,我们就会按照ServiceMetadataExchangeAttribute的属性进行开放显示。 当然,这个标签目前还只有一个属性: ContractName,
我相信, 日后就会多起来的。
3. 貌似同一进程多应用程序域的情况,创建性能计数器貌似会产生冲突。 所以特此为ServiceHost和ServiceHandle创建了NeedPerformanceCounter
属性,用于手动开放对于性能计数器的支持
4. 将元数据开放操作(Metadata exchange operation)改为了lazy模式, 当有契约需要开放时,再决定本地的host端口,否则不占用任何资源
5. 修改了不检测性能计数器为null的BUG



==========================================
= 2011年6月22日进度
==========================================
1. 重写了动态客户端代理(Dynamic client proxy)的底层MSIL部分,重写后,直接减少了装箱和拆箱的成本,提高了客户端代理的性能
2. 改写了ClientBase对于接收到底层收集信息的逻辑,单独定义了一个EventArgs(ClientLowProxyRequestEventArgs)




==========================================
= 2011年08月08日进度
==========================================
1. 添加了对于缓存模型框架(KJFramework.Cache)的引用
2. 添加了对于通信信道模型框架(KJFramework.Net.Channel)的引用
3. 重写了元数据交换节点(HttpMetadataExchangeNode), 内部使用了最新的HttpHostTransportChannel.
4. 更新元数据页面动作接口(IMetadataPageAction)的设计, 统一了执行后的结果总出口



==========================================
= 2011年08月09日进度
==========================================
1. 使用缓存模型框架(KJFramework.Cache)替换了CONNECT.技术内部的所有缓存池
2. 重构了3个CoreDispatcher内部的代码,重构后它们拥有统一的出口,更简洁了
3. 将内部3个CoreDispatcher继承自CoreDispatcher父类,而且归根了。
4. 精简了Client Proxy和Service Handle内部的代码
5. 使用ICacheContainer代替了Client中的请求超时计算代码




==========================================
= 2011年08月10日进度
==========================================
1. 使用通信信道模型框架(KJFramework.Net.Channel)替换了现有内部的所有通道
2. 编写了一个针对于CONNECT框架的协议栈
3. 清除了内部的冗余代码
4. 重新编写了内部网络层的代码,使用IMessageTransportChannel进行了替换工作
5. 重构了CONNECT.框架内部的所有涉及的通讯信息
6. 重新编写了消息的解析代码
7. 使用同一的消息父类Message, 来作为所有通讯信令的根


【注意】
----------------------------------------------------------------------------------------------------------------------------------
貌似在第一轮测试的情况下,总是会出现SocketAsyncEventArgs不够用的情况,默认框架内部已经
缓存了50000个,难道还不够用? 我不相信不够用,所以我觉得一定是框架内部哪里漏掉了归还SocketAsyncEventArgs,
等明天吧,我好仔仔细细的找找看,到底是哪里漏掉了



==========================================
= 2011年08月11日进度
==========================================
1. 移除了客户端对于证书的支持.




==========================================
= 2011年08月12日进度
==========================================
1. 为CONNECT.框架编写了封包片管理器(继承自信道模型).
2. 已经为分包消息传输的对接工作,做好了基础支持.
3. 清除了ChannelStack内部的无用代码,更轻量了.
4. 清除了请求中心(RequestCenter)内部无用的观察者模式
5. 成功的实现了数据自动分包/拼接的数据发送模式(支持分包发送)
6. 为CONNECT.技术创建了单元测试项目
7. 为大数据传输编写了单元测试
8. 为普通的SOA方法调用编写了单元测试



==========================================
= 2011年08月29日进度
==========================================
1. 应用了新版本的消息框架(KJFramework.Messages)
2. 精简了BinaryArgContext内部的字段
3. 更新了BinaryArgContext内部字段的类型,缩短了序列化时的字节数组大小
4. 移除了一些无用的代码





==========================================
= 2011年09月19日进度
==========================================
1. 重构了ServiceModelProtocolStack.Parse(byte[] data)方法,重构后,
该方法减少了大量的字节数组COPY工作





==========================================
= 2011年09月30日进度
==========================================
1. 重构了性能计数器





************************************************************************
* KJFramework.ServiceModel 解决方案升级策略 *
************************************************************************
*1. 为客户端代理器添加统一的错误处理接口
*2. 深度优化Client -> Server请求的协议
*3. 为Client Proxy进行分层创建,深度扩展为了支持以后的协议公有制
*4. 更多的稳定性
*5. 更快的速度
*6. 高度的容错性




==========================================
= 2011年10月08日进度
==========================================
1. 初步完成了新的分层设计
#Basic layer: KJFramework.ServiceModel
#Core layer: KJFramework.ServiceModel.Core
#Bussiness layer(default): KJFramework.ServiceModel.Bussiness.Default
2. 初步完成了客户端动态接口的拆分,如果需要灵活使用,只需使用IContractDefaultAction即可
3. 初步完成了客户端代理器的设计(IClientProxy), 移除了原来的ClientBase以及Client-ProtocolStack的实现
4. 移除了RequestingCenter, 使用IRequestManager来代替





==========================================
= 2011年10月09日进度
==========================================
1. 修改了异步调用,回调函数的原型。 由原来丑陋的方法签名改为使用IAsyncCallResult接口代替
2. 清理了相关的无用配置项




下一步要做的大改动
---------------------------------------------------
1. 完全重写对于客户端的异步调用模型(APM)
对于客户端的测试,可以先虚拟一个接口
2. 完成对于远程代码发布/生成的功能,这可能需要分几步去做
#元数据的定位(引用关系,等等)
#元数据可描述性设计(xml)
#元数据的下载
#元数据与实体类的生成
<--split line-->
#实体类与解决方案资源树的关联
#引用文件与解决方案资源树的关联





==========================================
= 2011年10月12日进度
==========================================
1. 添加了元数据类型生成器接口(IMetadataTypeGenerator)
2. 加入了新的页面动作(HttpMetadataArgumentDescriptionAction)
#HttpMetadataArgumentDescriptionAction 此页面动作负责提供某个参数的元数据描述(XML)
3. 修改了Operation页面动作的行为,在构造函数的时候,检测当前方法是否存在需要构造元数据描述的参数类型
如果有的话,则进行参数的元数据生成以及相关页面的注册.

--------------------------------------------------
下一步动作:

1. 研究CodeDOM来完成初步的源代码生成
2. 开始设计新的契约调用异步模型(New APM)




==========================================
= 2011年10月14日进度
==========================================
1. 初步完成了动态客户端底层MSIL的修改,去除了AsyncMethodName字段
2. 删除了原本丑陋而且很重量级的老APM原型,而代替它的仅仅是一个ICacheContainer :)
3. 编写了ISourceFileGenerator接口,用于协议对象的生成
4. 修改了IRequestCallResult的构造函数,使其只有在GetResult<T>()方法的时候才反序列化结果数据
5. 去除了一些陈旧的设计,和方法实现
6. 更新了ArgumentHelper中陈旧的处理方式,去除了一处处理数组类型时的多余字节数组COPY







==========================================
= 2011年10月18日进度
==========================================
1. 合并了项目KJFramework.ServiceModel.Bussiness.VSPlugin
2. 为CONNECT.契约的元数据发布增加了HttpContractOperationArgumentPageAction
3. 重构了客户端动态代理底端的MSIL部分,修改为,如果方法是异步的,则默认返回值为void,就不需要调用 RequestCenter.GetResult了
4. 为VSPlugin创建了元数据解析器接口(IMetadataParser)
5. 为VSPlugin创建了远程服务代理模型(IRemotingService)
6. 为ContractPreviewPageAction中的每一个操作都添加了返回值描述信息(return type)



下一步要做的事情
---------------------------------------------------------------------
1. 尝试为一个IsCustome = true的参数获取其内部定义(Argument define.)
2. 尝试进行初步的契约接口生成操作




==========================================
= 2011年10月19日进度
==========================================
1. 完成了代码生成器与解决方案资源树的整合
2. 初步完成了代码生成器的界面工作
3. 初步修正了部分元数据生成不正确的情况
4. 完成了对于自定义参数类型定义的关联下载功能
5. 支持了对于契约操作返回值类型的自定义元数据公开

Last edited Oct 20, 2011 at 6:43 AM by g0194776, version 2

Comments

No comments yet.