SHFileOperation
ShellExecute

#include <winsvc.h>
OpenSCManager
OpenService
QueryServiceStatus
StartService

COleDispatchDriver
  .m_bAutoRelease
ListView_SetExtendedListViewStyle(hWnd,LVS_EX_CHECKBOXES | LVS_EX_FULLROWSELECT);

EnumProcessModules

WM_DEVICECHANGE

SHGetSpecialFolderLocation
SHGetPathFromIDList

CAsyncMonikerFile 下载文件

PlgBlt

GetEnvironmentVariable
ExpandEnvironmentStrings

RegisterWindowsMessage

GetACP
The GetACP function retrieves the current ANSI code-page identifier for the system.

GetTextCharset 
GetTextCharsetInfo 
IsDBCSLeadByte 
IsDBCSLeadByteEx 
IsTextUnicode 
MultiByteToWideChar 
TranslateCharsetInfo 
WideCharToMultiByte

declare @x int
select @x = 1
while @x < 100000
begin
insert table1(id, idv)values(@x, @x)
select @x = @x + 1
end

_com_issue_error

Video for Windows  VFW

_TrackMouseEvent

MakeSureDirectoryPathExists
_taccess errno
GetFileAttributes

关于Script
IActiveScript

strtol 与 atol 的比较

http://www.openssl.org/  openssl 开源的数据加密 数字签名 等API

SQLBrowseConnect 带数据源选择对话框的连接
SQLDataSources      列出数据源名称描述.必须SQLSetEnvAttr 设置为odbc3.0版本(非常晕)

http://www.bruceeckel.com/ Bruce Eckel的主页。一堆好书

http://www.twinhelix.com/ 牛人的DHTML menu... 11k的.js文件。呃，jscript代码是很恶心的...so 实在佩服

const CString &  Value: OK
CString & const Value以及CString & volitate Value ==>过时用法

“无法解决 equal to 操作的排序规则冲突。”

一.错误分析：
　　这个错误是因为排序规则不一致造成的，我们做个测试，比如：
create table #t1(
name varchar(20) collate Albanian_CI_AI_WS,
value int)

create table #t2(
name varchar(20) collate Chinese_PRC_CI_AI_WS,
value int )

表建好后，执行连接查询：

select * from #t1 A inner join #t2 B on A.name=B.name

这样，错误就出现了：

服务器: 消息 446，级别 16，状态 9，行 1
无法解决 equal to 操作的排序规则冲突。
　　要排除这个错误，最简单方法是，表连接时指定它的排序规则，这样错误就
不再出现了。语句这样写：

select *
from #t1 A inner join #t2 B
on A.name=B.name collate Chinese_PRC_CI_AI_WS

二.排序规则简介：

什么叫排序规则呢？MS是这样描述的："在 Microsoft SQL Server 2000 中，
字符串的物理存储由排序规则控制。排序规则指定表示每个字符的位模式以及存
储和比较字符所使用的规则。"
　　在查询分析器内执行下面语句，可以得到SQL　SERVER支持的所有排序规则。

　　　　select * from ::fn_helpcollations()

排序规则名称由两部份构成，前半部份是指本排序规则所支持的字符集。
如：
　　Chinese_PRC_CS_AI_WS
前半部份：指UNICODE字符集，Chinese_PRC_指针对大陆简体字UNICODE的排序规则。
排序规则的后半部份即后缀 含义：
　　_BIN 二进制排序
　　_CI(CS) 是否区分大小写，CI不区分，CS区分
　　_AI(AS) 是否区分重音，AI不区分，AS区分　　　
　　_KI(KS) 是否区分假名类型,KI不区分，KS区分　
_WI(WS) 是否区分宽度 WI不区分，WS区分　

区分大小写:如果想让比较将大写字母和小写字母视为不等，请选择该选项。
区分重音:如果想让比较将重音和非重音字母视为不等，请选择该选项。如果选择该选项，
比较还将重音不同的字母视为不等。
区分假名:如果想让比较将片假名和平假名日语音节视为不等，请选择该选项。
区分宽度:如果想让比较将半角字符和全角字符视为不等，请选择该选项

三.排序规则的应用：
　　SQL SERVER提供了大量的WINDOWS和SQLSERVER专用的排序规则，但它的应用往往
被开发人员所忽略。其实它在实践中大有用处。

　　例1:让表NAME列的内容按拼音排序：

create table #t(id int,name varchar(20))
insert #t select 1,'中'
union all select 2,'国'
union all select 3,'人'
union all select 4,'阿'

select * from #t order by name collate Chinese_PRC_CS_AS_KS_WS
drop table #t
/*结果：
id name
----------- --------------------
4 阿
2 国
3 人
1 中
*/

　　例2：让表NAME列的内容按姓氏笔划排序：

create table #t(id int,name varchar(20))

insert #t select 1,'三'
union all select 2,'乙'
union all select 3,'二'
union all select 4,'一'
union all select 5,'十'
select * from #t order by name collate Chinese_PRC_Stroke_CS_AS_KS_WS
drop table #t
/*结果：
id name
----------- --------------------
4 一
2 乙
3 二
5 十
1 三
*/

四.在实践中排序规则应用的扩展
　　SQL SERVER汉字排序规则可以按拼音、笔划等排序，那么我们如何利用这种功能
来处理汉字的一些难题呢？我现在举个例子：

　　　　　　　　　　用排序规则的特性计算汉字笔划

　　要计算汉字笔划，我们得先做准备工作，我们知道，WINDOWS多国汉字，UNICODE目前
收录汉字共20902个。简体GBK码汉字UNICODE值从19968开始。
　　首先，我们先用SQLSERVER方法得到所有汉字，不用字典，我们简单利用SQL语句就
可以得到：

select top 20902 code=identity(int,19968,1) into #t from syscolumns a,syscolumns b

再用以下语句，我们就得到所有汉字，它是按UNICODE值排序的：

　　select code,nchar(code) as CNWord from #t

　　然后，我们用SELECT语句，让它按笔划排序。

select code,nchar(code) as CNWord
from #t
order by nchar(code) collate Chinese_PRC_Stroke_CS_AS_KS_WS,code

结果：
code CNWord
----------- ------
19968 一
20008 丨
20022 丶
20031 丿
20032 乀
20033 乁
20057 乙
20058 乚
20059 乛
20101 亅
19969 丁
..........

　 从上面的结果，我们可以清楚的看到，一笔的汉字，code是从19968到20101，从小到大排，但到
了二笔汉字的第一个字“丁”，CODE为19969，就不按顺序而重新开始了。有了这结果，我们就可以轻
松的用SQL语句得到每种笔划汉字归类的第一个或最后一个汉字。
下面用语句得到最后一个汉字：

create table #t1(id int identity,code int,cnword nvarchar(2))

insert #t1(code,cnword)
select code,nchar(code) as CNWord from #t
order by nchar(code) collate Chinese_PRC_Stroke_CS_AS_KS_WS,code

select A.cnword
from #t1 A
left join #t1 B on A.id=B.id-1 and A.code<B.code
where B.code is null
order by A.id

得到36个汉字，每个汉字都是每种笔划数按Chinese_PRC_Stroke_CS_AS_KS_WS排序规则排序后的
最后一个汉字：

亅阝马风龙齐龟齿鸩龀龛龂龆龈龊龍龠龎龐龑龡龢龝齹龣龥齈龞麷鸞麣龖龗齾齉龘

　　上面可以看出：“亅”是所有一笔汉字排序后的最后一个字，“阝”是所有二笔汉字排序后的最后
一个字......等等。
　　但同时也发现，从第33个汉字“龗(33笔)”后面的笔划有些乱，不正确。但没关系，比“龗”笔划
多的只有四个汉字，我们手工加上：齾35笔，齉36笔，靐39笔，龘64笔

建汉字笔划表（TAB_HZBH）：
create table tab_hzbh(id int identity,cnword nchar(1))
--先插入前33个汉字
insert tab_hzbh
select top 33 A.cnword
from #t1 A
left join #t1 B on A.id=B.id-1 and
-----------------

比如我可以根据RSA的方法找到一对公钥和私钥，然后告诉每个我的朋友或者商业伙伴这个公钥。这样我就可以发送用私钥签名的信息给他们，他们也可以用我的公钥加密信息后发送给我。(这就是数字签名了)

但是我怎么告诉我的朋友或者商业伙伴我的公钥？用internet告诉他们？别忘了上网就像裸奔，别人也可以找到另一对公钥私钥，以你的身份通过Internae把公钥发送给你的朋友(你认为没有这个可能？因为电子邮箱是需要身份认证的？你的密码不可能泄露，电脑上一定没有木马，黑客伪装不了你的电子邮件，更窃听不了你发送的数据包,竞争对手不会窃取你的商业秘密,没有人试图知道你的银行帐号，FBI更不知道你发表了什么言论。恩，那数字证书确实没什么用)。那么一个个打电话告诉他们，或者发送一堆挂号信？这样看起来不大现实。

所以有了数字证书。数字证书就是数字认证机构(CA)颁发给我的签名，由数字认证机构来证明这个证书的有效性。假如有了某个机构的数字证书，我就可以向所有人发送用这个数字证书签名过的信息。信息的接收者只要验证这个认证机构的签名就可以了。

但这样还是不现实，谁会拿着我的电子邮件跑去找厦门数字认证中心或者北京数字认证中心呢？所以这些机构的数字证书上也有更上层的签名，那就是根证书。打开IE-工具-Internet选项-内容-证书.你就可以看到一堆的受信任的根证书和中级证书机构颁发的证书.根证书给中级机构的证书签名,中级机构的证书给我的证书签名.所以只要根证书是可信的.我的证书就是可信的.

通俗一点就是说比如安南公布了自己的签名，声称他是可信的。然后布什去找安南，让安南在他的签名上签名，这样布什的签名就是可信的，然后布什在我的签名上签名。这样我的签名上就有布什的签名，而布什的签名上有安南的签名，这样如果你认识安南的签名，你就知道我的签名大概不是假的。大概就是这样了。

但是也许某一天布什会认为我有搞恐怖的嫌疑，决定把我的签名扔进黑名单。这时如果你收到了一份我签名的文件，说布什有裸奔的习惯，你怎么知道我是否还是可信的呢？布什想了个办法，把他黑名单公布在白宫的墙上，并在他的签名上写下白宫地址。这样你收到我的签名后，因为我的签名里面有布什的签名，布什的签名里面有白宫地址，你就可以去白宫看看我是否上了黑名单榜。

听起来这个方式很好。。可惜找布什在我的签名上签名是要钱的，直接找安南签名要的钱更多。人吃人的社会啊。所以据说有另外一种签名的方式。但目前偶还不清楚。

试验CryptoAPI的失败： 微软提供的Microsoft Cryptographic Service Providers里的The Microsoft Base Cryptographic Provider和The Microsoft Enhanced Cryptographic Provider不支持导入导出密钥对。唯一的收获。寂寥，郁郁，挫败。

目前电子签名签名的实现方式有：
基于PKI(Public Key Infrastructino)的公钥密码技术的数字签名；
以生物特征统计学为基础的识别标识；
手印、声音印记或视网膜扫描的识别；
一个让收件人能识别发件人身份的密码代号、密码或个人识别码PIN；
基于量子力学的计算机...
数字签名的目的和功能:
认证、数据保密性、数据完整性和不可否认性.

数字签名的实现方式:

(一)公钥加密算法如何加密:
比如我要发送一个绝密的信息M给你,我当然不会直接把M写在信里面寄给你,我会提前告诉你解密的方法,然后使用算法P处理M得到P(M),我发送P(M)给你.因为你知道解密的方法P',你使用P'来处理P(M)得到了M.只要P和P'不让别人知道,我们的通讯就是保密的.
如果从P'能够得到P,那你就能知道P,然后伪装我发送消息给其他人.
但是据说有一个公钥加密算法,加密和解密的算法是一样的,而且是公开的,我告诉你我的公钥k1,我自己保密的是私钥k0,我发送给你的信息是M' = P(k0,M),你收到M'后可以通过运算P(k1,M')得到M,但是通过k1是无法计算出k0的,通过K0也无法计算出k1.(我也不知道是否真的这么神奇,现在网络上到处都是RSA被破解之类的,看得菜鸟我心惊胆颤,俺刚要好好学习呢,别人早已经把它颠覆了).

这样你只有解密的份,没有伪装我身份的可能.
同样你也可以用k1来加密发消息给我,我用k0可以将它解密.
但是这种公钥加密算法是把消息本身当成一个大数来进行幂运算,所以比如我想把1000个字节的字符串当成一个大数来加密,应该是非常困难而且非常慢的.(偶想高手应该会算,但那不是俺关心的)
所以有了散列.

(二)关于散列:
最常用的散列机制有 SHA1,MD5,RIPEMD-160等.SHA1即“安全散列算法”。SHA1 可以处理 2**64字节以内的任何消息，并生成一个 20 字节的结果。
按照菜鸟我看来这不是"散列",这是"聚列"啊.把一个2^(64*8)的数映射到一个2(20*8)的数,同志们,这不是聚列是什么?但其实我们一般用的字符串,不会把0~2^(64*8)的数全用光,只用了其中一小部分.所以这个散列似乎是相对安全的.这种问题就留给长了几个脑袋的人来解决吧.

关键是散列算法比公钥加密算法要快很多.

这样,我找到了一对公钥和私钥(k0和k1),我公布了我的散列算法H,发表了一篇长5万个字奇菜无比的论文,内容为M,对M进行散列,很快得到H(M),然后用私钥加密得到S = P(k0,H(M)),把S附在M后面并发表.
你看到后为了证实这篇其烂无比的文章是我写的,可以判断 P(k1,S) 是否等于H(M).如果相等,你就可以确定这其烂无比的文章确实是我写的.
或者确定那个狗屁不通的审批确实是某大人批准的.

(三)除了使用公钥加密算法来实现数字签名,还可以用HMAC来实现:

HMAC即散列后的消息验证代码”(Hashed Messsage Authentication Code)
微软MSDN上这么说:
将共享密钥混合在摘要中，即创建 H(S+M)。您收到消息后，可以使用自己的 S 副本来创建 H'(S+M)。
在使用 HMAC 时，完整性保护的有效性取决于攻击者计算出 S 的能力。因此，S 应该不容易被猜出，并应该经常更改 S。符合以上要求的最好方法之一是使用 Kerberos。在 Kerberos 中，中央机构将在两个实体希望通信时分配包含临时会话密钥的“票”。此会话密钥将用作共享密钥。在要将签名发送给您时，我将得到一张票，以和你通信。我打开票中的属于我的那一部分来获得 S，然后将消息、消息的 HMAC 和票中您的那一部分发送给您。您打开票（使用原来通过 Kerberos 注册的密钥），获取 S 以及有关我身份的信息。您现在可以获得消息 M，生成自己的 H'(S+M)，并查看它们是否匹配。如果匹配，表明您原封不动地收到了我的消息，并且 Kerberos 将通知您我是谁。

Kerberos是古希腊神话里的地域门口的一条三头狗.也是MIT麻省理工大学发明的一种协议.要使用这个协议需要配置一个分发服务器,似乎比较麻烦...

什么是工作流:
工作流管理委员会(WfMC)把工作流定义为：工作流是一类能够完全或部分自动执行的业务过程。根据一系列规则，文档、信息、任务能够在不同的执行者之间传递、执行。完成正个过程所需要的参数有：
过程中每一单独步骤的定义，每一步骤由谁负责，每个活动需要的应用程序。定义一个工作流就是说明了处理过程是什么：由哪些活动、任务组成即流的结构。如何做：活动间的执行条件、规则，所交互的信息即控制流与信息流的定义，谁来做：人还是应用程序即角色定义，做得怎么样：对工作流的执行状态实施监控。(工作流管理与事务服务设计方案)

WfMC提出了一种工作流的参考模型(Workflow Reference Model)：目的就是把工作流分成5个模块,并定义这5个模块之间的接口的规范.这么做的意义是啥呢?应该不归我菜鸟来解释了.

模型包含5个模块：
1.过程定义(Process Definition)
2.特定的工作流系统(Workflow Enactment Service),其中包含一个或多个工作流引擎(Workflow Engine(s)),提供工作流API和交换(Workflow API and Interchange)
3.工作流客户端程序(Workflow Client Application)
4.激发的程序(Invoked Applications)
5.其它工作流系统(Other Workflow Enactment Service)
6.管理和监控工具(Aministration & Monitoring Tools)
其中包含5个接口(Interface)
1.工程定义工具接口(Process Definition Tools Interface)
工作流系统(Workflow Enactment Service)<=>过程定义(Process Definition)
2.客户端程序接口(Workflow Client Application Interface)
工作流系统(Workflow Enactment Service)<=>工作流客户端程序(Workflow Client Application)
3.激发程序接口(Invoked Application Interface)
工作流系统(Workflow Enactment Service)<=>激发的程序(Invoked Applications)
4.工作流系统间协同接口(Workflow Interoperability Interface)
工作流系统(Workflow Enactment Service)<=>其它工作流系统(Other Workflow Enactment Service)
5.管理和监控接口(Administration & Monitoring Tools Interface)
工作流系统(Workflow Enactment Service)<=>管理和监控工具(Aministration & Monitoring Tools)

XPDL：
5.流程定义交换概述(Overview of Process Definition Interchange)
流程定义的作用：
1。产生和控制流程实例的模版
2。仿真和预测
3。监控和分析
4。文档，可视化和知识库管理(?)
可能会包含子流程的定义
一个初始的流程定义最少要包含初始化和执行所需要的对象(objects)和属性(attributes)。流程实例将继承(inherit)这些对象和属性。
WfMC术语表中包含活动(activities), 流向(transitions), 工作流相关数据(workflow relevant data)和参与者(participants)等。
 
5.1流程定义交换的方法(Approaches to Process Definition Interchange)
这里使用XML作为交换的机制。XPDL提供一种交换标准，使用导入导出(import/export)的方法使得任意在内部用不同方式表示流程的系统得以互相交换流程(?)。
有很多不同的方法可以用来在不同系统间交换流程。在这些方法中都必须把流程表示成一致的格式。

6.元模型(Meta-Model)
元模型用以描述一个流程定义的最上层实体(the top-level entities)，实体的关系和属性(这些属性有的只是用以仿真或监控的目的，而不是为了运行(enactment))；它包含了把多个流程组织成流程模型(process models)和多个流程和流程模型间的公共定义数据(common definition data)。
 
6.1实体(Entities)

6.1.1工作流定义(Workflow Process Definition)
提供上下文环境(contextual information)，提供管理信息（如创建日期，作者等）或者用于执行(process execution)的信息（如初始值，执行优先级，期限，需要通知的人，仿真信息(simulation information)等）

6.1.2环节（Workflow Process Activity）
一个流程定义中包含多个环节，环节是流程中逻辑上独立的单元。环节代表使用多种资源处理的工作（参与者的任务）或/和应用程序（应用软件的职能）。其它信息包含是否自动开始/结束，当和其它环节发生资源冲突的时候的优先级。对流程相关数据(workflow relevant data items)的使用也必须指明。一个环节的范围是某个特定的流程。
一个环节可能是一个子流程(subflow)。这种情况下它包含了一个特定流程的执行，这个流程可能在同一个工作流服务器（workflow service）中运行，也可能在其它工作流服务器上运行（通过流程协同接口(process interoperability interface)）。子流程包含它自己的环节，内部流向，资源和应用程序分配(application assignments)，尽管这些可能是从同一个公共资源而来。输入参数和输出参数使得流程相关信息得以被在调用和被调用流程间交换（如果必要可以是返回参数）。
一个环节可能是一个块环节(block activity)。块环节包含一个环节组(activity set,)，或一堆环节和流向，一个环节组中的环节和流向共用内流程(containing process)的名字空间。
最后，一个空环节（dummy activity）不执行任何操作（因此没有相关资源和相关applications），仅用来在入流向(incoming transitions)和/或出流向(outgoing transitions)间进行流转(routing).

6.1.3流向信息.(Transition Information)
环节之间由流程控制条件相关联(流转条件(transition information).)).每个流向包含三个基本属性,源环节,目的环节和流向条件.从一个环节到另一个环节的流向可能是有条件的,也可能是不需要条件的.一个流程里面的多个流向可能产生串行的(sequential)或并行的(parallel)环节.分叉(split)或者合并(join)的相关信息在对应的环节之中,split as a form of “post activity” processing in the from-activity, join as a form of “pre-activity” processing in the to- activity.This approach allows the workflow control processing associated with process instance thread splitting and synchronization to be managed as part of the associated activity, and retains transitions as simple route assignment functions.{开始昏了}一个流向属于包含它和它的相关环节的流程.
其它更复杂的流向,不能用简单的函数来表达的,使用空环节来实现.结合使用基本的流向和空环节,任何复杂的流转结构都可以被实现.因为业内已经有好几种流向控制的途径,在XPDL中也有相应的几类,在本文稍后描述.

6.1.4流程参与者声明(Workflow Participant Declaration)
流程参与者声明描述在流程定义中各个环节的参与者(performer).The particular resources, which can be assigned to perform a specific activity, are specified as an attribute of the
activity, participant assignment, which links the activity to the set of resources (within the workflow participant
declaration) which may be allocated to it.{环节参与者是环节的一个属性...昏了}.流程参与者不一定是单独的个人,也可以是一组有相应资格或责任的人,或者机器的自动操作.元模型包含了一些简单的资源类型,这些类型可能在流程参与者声明中被定义.

6.1.5资源库(Resource Repository)(?)
资源库说明参与者可能是人员,程序,或者机器.在更复杂的情况下,参与者声明可能是一个资源库,它可能是参与人员的一个组织机构模型(Organizational Model).这份文档并没有定义或要求一个资源库.

6.1.6工作流应用程序声明(Workflow Application Declaration)
工作流应用程序声明描述了被工作流服务器调用的,用以支持各个环节的处理的IT应用程序或接口,这些程序和接口被定义为环节的一个属性.这些应用程序可能是行业工具,特定部门或企业的服务,或在工作流管理系统框架下的本地应用程序.工作流应用程序声明反映了工作流引擎和{应用程序或接口}的接口,包含需要传递的参数.

6.1.7工作流相关数据(Workflow Relevant Data)
工作流相关数据定义了在流程执行过程中创建和使用的数据.这些数据在工作流中被环节或者应用程序使用,并可能被用于传递持久的信息或者环节间的中间结果或/和用于判断流向流转或者分配参与者的的中间数据.工作流相关数据是特殊的类型(Workflow relevant data is of particular type.),XPDL定义了各种基本的和复杂的数据类型,(包含日期Date,字符串string,等).环节,被调用的应用程序(invoked applications)和/或流向条件会用到工作流相关数据.

6.1.8系统和环境数据(System and Environmental Data)
系统和环境数据由流程管理系统和本地系统环境管理,但会被工作流环节或工作流管理系统用于计算条件表达式,如同工作流相关数据一样.

6.1.9数据类型和表达式(Data Types and Expressions)
元模型(和相关的XPDL)假设有一些标准数据类型(string,reference,integer,float,date/time等),这些数据类型被用于工作流相关数据,系统和环境数据或参与者数据(participant data).用于条件判断的表达式将由这些数据类型组成.数据类型可以用XML schema或者引用外部资源中定义的类型来扩展.
 
 6.2流程和流程包(Processes and Packages)
从以上内容可知,流程模型包含的很多实体(entities)的范围超出了单个流程定义的范围.可能多个流程定义会引用到相同的流程参与者,工作流应用程序和工作流相关数据.元模型采取了使用公共流程定义库(common process definition repository)来包含这些实体和工作流定义.在这个库本身的范围内,为了提高传送流程定义数据的效率,引入了流程包的概念,流程包包含了一组工作数据实体(common data entities)和许多不同的流程定义,避免了在不同的流程定义中重复定义这些工作数据实体.
流程包包含了流程定义实体的许多公共属性如(作者,版本,状态等),包内的每个流程定义自动继承了所有这些公共属性,除非它们在流程定义中分别被重新指定.
 
在包中的一些实体的定义是全局的,能够被包中的所有流程定义(以及相关的环节和流向)引用,这些实体是:
-流程参与者声明
-工作流应用程序声明
-工作流相关数据
可以在流程包或者流程包包含的对象中使用被引用的外部流程包的最上层实体(The package reference allows the use within the package or its contained objects of references to top-level entities in the referenced external package:).{哈,没昏},这些最上层实体包括:
-子流程的流程ID
-流程参与者声明
-工作流应用程序声明
 
同一个库地址空间(repository address space)中的不同流程包的名称和标识的管理规定由提供商自己定义.{相同库,但不同包的名字空间的划分方法由工作流的开发者自己设计,好像是这意思}.推荐的查找方法是:
-流程id:先在同一个model中寻找(包含任何在不同服务器上运行的流程定义的引用),然后在任何被引用的外部model中查找
-流程参与者声明/工作流应用程序声明 :先在同一个model中查找,再在任何被引用的外部model中查找.
{这里model指的范围可能是流程包,有点像java import一个名字空间进来,怎么找一个类型一样}
 
工作流相关数据的命名在同一个流程包中必须是唯一的,在同一个包中,{在这份文档的当前版本},流程间参数的传递惯例是值传递(copy semantics).流程设计者(管理员)必须在流程定义/流程模型中确保名称和数据类型在调用子流程时的一致(和任何其它远程流程协调工作时的一致).

 6.3流程元模型(Process Meta-Model)
流程元模型定义了用于流程定义交换的一组基础的实体(entities)和属性(attributes)。对于每个流程定义，以下实体必须在流程范围内定义或从流程包中继承，或从其它包中引用：
-环节(Workflow Process Activity)
-流向(Transition Information)
-流程参与者(Workflow Participant Specification)
-工作流应用程序声明(Workflow Application Declaration)
-流程相关数据(Workflow Relevant Data)
这些实体的属性描述了流程的机制，它们将在本文后面被描述。

6.4流程包元模型(Package Meta-Model)
在一个模型定义(model definition.)中，多个流程定义是互相关联的。流程包包含了流程定义和相关的实体，而这些实体能被所有包内的流程使用(所有这些实体只要被定义一次)。流程包元模型包含了以下的实体：
-流程定义(Workflow Process Definition)
-流程参与者(Workflow Participant Specification)
-工作流应用程序声明(Workflow Application Declaration)
-流程相关数据(Workflow Relevant Data)
>

流程包的原模型指出了用于流程模型的交换和保存的实体和属性。它定义了各种不同的继承规则，来关联单独的流程定义和{流程参与者，工作流应用程序声明和工作流相关数据的定义}，这些定义(流程参与者...的定义)可能在单个流程定义中，也可能在流程包中。
流程包定义允许指定一些公共的流程定义属性，这些属性自动被应用于流程包中的每个流程定义。这些属性也可被但个流程所忽略.(如果这些属性在流程定义层被重新定义，那本地的属性值将覆盖全局的)
 
6.4.1流程库(Process Repository)
流程定义导入/导出接口被用于操作工作流管理系统的流程库。实现的方法是从这些流程库中导入导出包含XPDL的文件。这个接口在单独的流程和流程包两个等级上导入导出流程定义数据。
流程库和流程控制功能之间的接口由各个供应商(工作流实现者)自行决定，与本标准无关。但推荐把静态的流程库(for persistent, ongoing storage of process definition data)和动态的流程库(for managing changes to the process execution of extant process instances)区分开来(比如用版本控制)。
WfMC标准不包含流程定义库的具体内部实现结构。流程包的使用只是为了在导入导出过程中重用数据。在简单的流程库结构下(Where a simple process repository structure is used)。对流程定义层上的操作，被导入的流程库的共享信息会被复制到各个单独的流程定义中(并在导出过程中被类似地重新打包)。
 
6.4.1.1重新定义和范围(Redefinition and Scope)
因为有重新定义属性和元模型实体和对外部流程包的引用的可能，所以范围和层次的规则(principles of scope and hierarchy)被引入到了XPDL(和流程库)结构中。
(i)流程相关数据
流程相关数据的范围被直接相关的元模型实体定义并且不能被嵌套。它的标识符的可见性同样由该实体定义。{不知道有没搞错..费解}
(ii)属性
属性和外部属性的范围被直接相关的元模型实体定义并且可以被嵌套，例如可以在下一层被重新定义。例子：名字属性在各个实体定义中被重新定义。外部属性的标识符在特定实体和子实体可见，除非在子实体中重新定义了该标识符。
(iii)流程参与者和应用程序
流程参与者和应用程序的范围和可见性与外部属性相同。所有被(流程参与者和应用程序)使用的流程相关数据和外部属性的范围必须和使用者的范围一样，至少在同一个流程包内。
For a referenced external package entity that needs itself reference to entities and their identifiers defined in its external package clause the mechanism is started with the root in that package. That guarantees that no conflict takes place if the invoking process has an entity with the same id, which the definer of the referenced package cannot be aware of.
外部流程包的使用给流程设计者和管理者以很大的自由。一是可以在分开的模型中分别定义组织机构(参与者实体)和流程定义。另一个是可以添加一个新的流程定义共享原来的流程定义所用的模型而不需要重新提交整个环境信息。
 
6.5实体预览(Elements Overview)
下表展示了XPDL中定义的主要元素(elements)
-第一栏包含所有主要元素的属性。所有主要元素包含的属性有：id，name可能有Description和Extended Attributes。
-第二栏是特殊的属性
-The third group consists of elements that may contain references to other elements.
-Documentation and Icon elements ：被工作流引擎使用的描述信息
-第五栏包含了仿真和优化的信息
以后可能会添加别的元素和预定义属性

6.5.1供应商或用户扩展(Vendor or User specific Extensions)
尽管元模型和XPDL包含了大部分流程定义交换过程中需要的结构。但在特定环境下流程定义可能需要包含更多的信息(供应商或用户的特定信息)。供应商或用户应尽量使用标准的实体和属性。以下将描述扩展信息的标准方法，但这要求流程引擎提供相应的运行时支持。
 
6.5.1.1Extended Attributes
最主要的方法是使用Extended Attributes。Extended Attributes由供应商或用户在必要情况下自行定义，用以表达额外的信息。额外属性的运行时支持分别在两个系统中实现，而且双方要在对额外属性的导入导出上达成一致。
 
6.5.1.2. Extended parameter mapping
关于子流程的参数传递，由供应商自行决定，和WfMC无关

最后:faint...人家已经xpdl2.0了
 
好像n多概念不一样了。2005-10-3的版本，然道我就这么倒霉？
2.0的流程包(Package)里面添加了pools,message flows,associations & artifacts的概念。
 
泳道(Swimlanes)?
池(Pool){环节，流向(Sequence Flow (transitions))} Pool之间通过信息流(Message Flow)联系。白箱黑箱。background pool即默认的pool
 
通道(Lane)，进一步分割pool,属性被其中的环节继承
 
巨faint，人家已经有翻译好的。。1.0版本的，除了几个特殊名称的翻译不习惯外，读起来挺流畅的。
但不能理解的还是不能理解，好像翻译的人也没融会贯通。
就当学英语好了..郁闷。以后失业了可以试试粗浅的翻译。
 
工作流现在咋就这么流行呢？ http://www.cnitblog.com/Files/Raistlin/wfmc-zh.rar

看了10分钟英文的题目，大概理解如下:有个m * n的字符串数组grid，和一个长度为g的字符串path，匹配方式是从grid中任何一个位置开始，从上下左右和对角方向(共八个方向)进行匹配，要求计算匹配的次数。如果匹配次数大于1000000000，返回-1。
类名字为WordPath，方法为int countPaths(vector <string> grid, string find);(俺语言选了C++)
 
看完题目，只剩下不到50分钟了，赶快写吧。直接开了个vc，创建类，写函数(不习惯竞技场的界面的)...正要调试的时候vc出问题了，说俺文件丢失。@#$！懒得去找丢失的文件。直接用竞赛场的界面来调试吧。我用vc编译是没问题的，在竞技场上编译就出问题了。因为vc工程的头文件和cpp文件是分开的，而竞技场里面是合并的。copy过来的时候出了问题..声明了虚构函数却没实现...
好不容易调试通过了，运行出问题了，错误结果是：segmentation fault。但我不知道这个segmentation fault是什么鸟。编码的时间从剩余的十几分钟一直到10分钟，到1分钟....烦了，干脆关掉。
 
郁闷，出去逛了一圈回来，重新建个vc的工程自己调试。运行没什么问题啊...返回的结果似乎也是正确的(俺只测试了一个例子)。奇怪为什么同样的代码在上面运行就出错呢？
 
只能怪自己是菜鸟了。安慰的说法是俺不是编程机器...
 
总结一下俺失败的经验:
1.C++的类要习惯把头文件和cpp文件写在一快。
2.完全不要考虑参数是否会出错，不要浪费时间做错误处理。
3.完全用C的代码来写C++的类。C++的特性不要使用，比如static成员，在构造函数里面初始化等。
4.比赛前研究一下调试的环境，好像标准输入输出是可以用的，但我没试过...
 
做好上面4点，完成题目的可能性会比较大了。