保存两篇旧文章

openis 系统的历史、目标与方案的选择

1.0版
2004-01-16
庄表伟

一、历史
  1、PHP版本，最初的试验
    在2000年6月左右，我开始使用PHP为公司开发门户网站，当时有一个最初的设想，
  来源于各种各样的“栏目”，在一个门户网站中，存在各种各样的栏目，每一个栏目都
  有不少的文章，栏目还包括子栏目，子栏目下也可以   包括不少的文章。以往的设计
  都是为不同的栏目设计不同的表，定下不同的字段，为了这些不同的表和字段写不同
  的程序。于是我就考虑，能不能只用两个表来表示这所有的信息，栏目表、内容表。
  无论哪个栏目的内容，都放在一个表里，这些内容的不同的字段，我通过一个包含了
  各种冗余字段的内容表，来存放不同的内容。这样的设计当然是不符合数据库设计与
  经典的软件开发的思路的。当时也遭到了一些反对。但是这样的好处就是，我可以写
  一个统一的访问栏目与内容的函数层，整个网站的开发，不再需要考虑数据库结构的
  设计，也不再需要写不同的数据库访问程序，项目的焦点，就直接集中于表现层，开
  发的进度大大加快。至于系统的效率，当时确实没有考虑。

  2、Java版本，命名为iMIS
    在具体的应用中，我发现，不但栏目需要加子栏目，内容也可能需要加子内容。比
  如BBS中，栏目就是板块，帖子就是内容，但是每一个帖子也可以有多个跟帖。不但栏
  目是树状的，内容也应该是树状的。另外就是相关性，某一篇新闻的相关新闻，也需
  要有所记录。
    于是在新的开发项目中，我将栏目与内容统一命名为节点(Node)。   每个节点都可
  以跟子节点。节点与节点的区别就是节点类型的不同。不但内容发布的信息是节点，
  用户群组与   用户也是节点，产品类别是节点，具体的产品也是节点。只要能够想到
  的信息，都是某种节点。节点与节点的   关系也有很多种，比如厂商节点与产品节点
  存在“生产”关系，新闻节点与新闻节点存在“相关”关系，用户节点   与内容/栏目节点
  存在“权限”关系等等。
    这个系统被命名为iMIS，也就是集成管理信息系统的意思。这其中含义包括四个方
  面“数据集成”，“应用集成”，“管理集成”，“界面集成”。但是这个系统并没有完成他
  的命名所预定的目标，就已经完成了当时需要开发的项目的目标:)在公司来说，就不
  再支持后续的开发了。

  3、openis，一个全新的开始
    一个全新的系统，不与某个具体的项目挂钩－－虽然与具体的项目挂钩能够得到公
  司的支持。2004-01-10开始。

二、目标
  1、提高开发速度
    最重要的目标就是提高开发速度，终极的目标是系统对于用户来说是“立等可取”的。
  开发的过程变成修改的过程，而对于系统的修改成为常态。使得软件工程师与客户之间
  能够直接交流，不再经过咨询人员的“低效率翻译”，也不用“UML”之类的高科技使用户
  望而生畏，而是提供一种双方都能直接理解的需求定义的方式。
  2、降低学习成本
    无论是软件公司，还是使用软件的政府与企业，都不需要更多的学习，而是能够通过
  一些简单的讲解，就能理解和应用。
  3、规范开发流程
    通过使用openis，在软件公司实现规范的，合理的，科学的开发流程，在清晰定义的
  结构中，每个人都能明白自己的任务和目标。
  4、提供整体方案
    一方面在openis能够覆盖的范围内（Web上的管理信息系统），各种项目都能在一个
  整体方案中得到实现。
    另一方面，通过openis，能够整合现有的各种应用，进而对于用户显示出一个整体。
  5、不断提高系统的性能
    性能不是最重要的选择，但是必须在openis的开发过程中，不断提高。

三、方案的选择
  1、同时支持java与.NET
    java程序员与.NET程序员，都需要一套快速开发平台。
  2、java而不是j2ee
    j2ee华而不实。
  3、ASP.NET而不是ASP
    ASP对于扩展性的支持，远不如ASP.NET，另外C#与java的类似性，也是选择.NET的
  原因。
  4、jsp+taglib≈C#+ASP.NET
    ASP.NET的服务器控件是一种非常好的Web开发方式，jsp+taglib，能够基本实现类
  似ASP.NET的服务器控件。
  5、数据库作为主要存储方式
    有很多人试图开发自己的存储方式与算法，但是这不划算，而且不太可能超过数据库
  的性能。
  6、提供一套完整的对象模型
    这套模型目前要能够支持信息发布，内容管理，工作流，事务处理，以及版本控制。
  而且在java与.NET中，应该用法一致。

openis 系统的特性

1.0版
2004-01-16
庄表伟

一、统一信息访问
  在openis中，信息分为两大类，一类称为“节点”，另一类称为“关系”。具体的节点
与关系的说明，将在概念模型中描述。这里的“节点”可以是任何类型的信息，例如数
据库中的一条记录，一个本地文件，一个FTP能够访问的文件，一个HTTP能够访问的文
件，一个Web Service的返回结果等等。
  访问这样的信息，有统一的路径，类似URI，规则如下：

协议[.子协议]://[用户名]:[密码]@地址[:端口]/路径/节点名或表达式[.节点类型][#操作][?[参数1][&参数2]]

  例如：
  file://local/c:/temp/info.xml
    这样就能访问一个本地的XML文件
  db.mysql://192.168.1.31:3306/mysql/user/id=1.user
    这样就能访问192.168.1.31下的mysql数据库，其中的mysql库user表，id=1
    的记录，这个记录取出来之后，作为user类的对象
  core://192.168.1.31/info/news/nnodeid=1.news
    这样就能访问192.168.1.31下的核心数据库中/info/news/路径下的nnodeid=1
    的记录，这个记录取出来之后，作为news类的对象
  core://192.168.1.31/ntreeid=1&nnodeid=1.news
    对于核心数据库，可以只用treeid与nodeid定位一个节点，取出之后，作为news
    对象
  http://192.168.1.31/news/index.php
  ftp://tiger:123@192.168.1.31/temp/temp.xml
    这不用解释了吧
   
  db.mysql://192.168.1.31:3306/mysql/user/id=1.user#modify?username=jack
    将user表中的id=1的用户名改为jack

  下面详细解释一下。
   
  1、协议.子协议
    访问任何信息都需要通过协议，http,ftp是我们常见的协议，file协议是用于访问
  本地文件或者某一台局域网服务器上的共享文件。db代表了数据库访问协议，访问不同
  数据库的jdbc作为子协议。core代表核心数据库，可以采用更加快捷的方式访问。
    目前打算支持的协议有:
    core
    db.*
    file
    http
    ftp
    https
    socket
    smtp
    ldap

  2、用户名与密码
    访问大多数的信息，都需要用户认证，或者以匿名的方式访问。

  3、地址与端口(略)

  4、路径
    路径的概念来自文件系统，所有树状结构的信息，都可以通过路径访问。而对于关系
  型数据库，则需要作出约定，用“库名/表名”表示。

  5、节点名或表达式
    对于文件系统，文件名即可以定位一个节点，而对于关系型数据，则需要表达式，约
  定为只包含关键字段的表达式。否则可能查出多条记录。另外，一个文件的扩展文件名
  并不是节点类型。

  6、节点类型
    系统提供一个基础对象Node，其他类型的节点继承Node对象，可以命名为NewsNode。
  当不指定节点的类型时，就认为这是一个缺省的Node对象。

  7、操作
    不同的节点类型支持不同的操作，其中Node对象中有一个缺省的show操作，如果操作
  省略，就代表调用show操作。
 
  8、参数
    与不同的操作有关，可变

二、节点
  统一访问标识的是一个特定的节点，不同的节点可以有各种不同的属性，任何类型的节
点，都可以转化为核心数据库中的一条记录，如果一个项目不需要集成外部的数据和文件，
则单纯的核心数据库就可以满足大多数开发需求。每一个信息节点，包含以下信息：
  －－－－－－－－基本字段
  ID号
  路径
  父节点ID
  名称
  标题
  创建者ID
  创建时间
  最后修改者ID
  最后修改时间
  子节点最后ID
  类别
  状态
  －－－－－－－扩展字段
  n个varchar字段
  n个int字段
  n个datetime字段
  n个float字段
  －－－－－－－内容字段
  一个CLOB
  一个BLOB
  －－－－－－－打包字段
  一个CLOB

  我们对于一个节点，通常有这样几个方面的查询需求，一个是对基本字段的查询，一个
是对于不同的节点可能产生的含义不同的查询，还有就是通过一个节点与其他节点的关系，
查询其他节点。从其他应用集成进来的信息，除了需要查询的字段我们放入扩展字段之外，
其他的就打包入一个CLOB字段中。

三、关系
  任何节点之间都可以存在关系，整个系统允许数目不限的关系种类。每一种关系只存在于
两个节点之间，多于两个节点的关系，总可以转化为多个两个节点之间的关系。
  例如：相关新闻，管理权限，项目与工作，BBS里的一篇文章在精华区中的位置等等

  关系分为对等关系与不对等关系。相关新闻这样的关系就是对等的，而管理权限，意味着
某个用户对某个节点有管理权限，关系的左边是用户类节点，右边是普通节点，就不能交换。

  可以通过操作取得某个节点的某一类相关节点。

四、操作与工作流
  每一个节点都可以允许多种操作，但是在不同的状态下，这个节点所允许的操作是不同的。
我们可以用两个表来表示：
  操作状态表：表示经过某个操作后，这个节点可能将处于的状态。
＋－－－＋－－－＋－－－＋－－－＋
｜　　　｜状态１｜状态２｜状态３｜
＋－－－＋－－－＋－－－＋－－－＋
｜操作１｜　＊　｜　　　｜　　　｜
＋－－－＋－－－＋－－－＋－－－＋
｜操作２｜　　　｜　＊　｜　＊　｜
＋－－－＋－－－＋－－－＋－－－＋
｜操作３｜　　　｜　　　｜　＊　｜
＋－－－＋－－－＋－－－＋－－－＋
  状态操作表：表示在某个状态下，这个节点允许的操作。
＋－－－＋－－－＋－－－＋－－－＋
｜　　　｜操作１｜操作２｜操作３｜
＋－－－＋－－－＋－－－＋－－－＋
｜状态１｜　　　｜　＊　｜　　　｜
＋－－－＋－－－＋－－－＋－－－＋
｜状态２｜　＊　｜　　　｜　＊　｜
＋－－－＋－－－＋－－－＋－－－＋
｜状态３｜　　　｜　　　｜　＊　｜
＋－－－＋－－－＋－－－＋－－－＋
  通过这样两个表格，我们就可以完全清楚的定义一个节点的所有操作的相互依赖关系。如果
我们进一步定义，在某一特定的时刻，某个特定的用户能够对这个节点有什么样的操作权限。
则一个工作流的定义也就已经完成了。
  在简单的情况下，我们可以假设一篇新闻，有是否被推荐两个状态，当一篇新闻被推荐时，
将无法被修改，而只能对其进行撤回操作，在未被推荐时，才能进行修改和删除操作。图表如
下：
  操作状态表：
＋－－＋－－＋－－－＋
｜　　｜推荐｜未推荐｜
＋－－＋－－＋－－－＋
｜推荐｜　＊｜　　　｜
＋－－＋－－＋－－－＋
｜撤回｜　　｜　＊　｜
＋－－＋－－＋－－－＋
｜修改｜　　｜　＊　｜
＋－－＋－－＋－－－＋
｜删除｜　　｜　＊　｜
＋－－＋－－＋－－－＋
  状态操作表：
＋－－－＋－－＋－－＋－－＋－－＋
｜　　　｜推荐｜撤回｜修改｜删除｜
＋－－－＋－－＋－－＋－－＋－－＋
｜推荐　｜　　｜　＊｜　　｜　　｜
＋－－－＋－－＋－－＋－－＋－－＋
｜未推荐｜　＊｜　　｜　＊｜　＊｜
＋－－－＋－－＋－－＋－－＋－－＋
  而对于更加复杂的状态流转情况，这样的表格同样可以胜任。在操作状态表中，一个操作可
能到达的状态有多个，这就需要在具体的节点中通过程序来实现了。

五、历史、版本与事务控制
  对于一个节点进行各种操作之后，可能改变这个节点的状态，这个节点的上一个状态如果需
要，可以存入另一个历史记录库中，历史记录表与核心表完全相同，但是增加一个字段，既原
本那个节点的ID号。
  添加与删除的操作，则彻底改变了一个节点的存在，因此需要一个系统级的历史记录表。
  如果在历史记录表中，也体现出树状的结构，就可以记录一个节点的不同版本，成为一个版
本树。
  当我们进行事务操作时，只要一次事务中的每一个操作都在历史表中记录了上一次的节点状
态，则这次事务就是可回滚的。无论这个事务跨越了多少个不同的表、文件、甚至服务器。

六、运行时服务器
  1、统一节点访问接口
  2、节点缓存与关系缓存
  3、事务支持
  4、日志服务
  5、分布式访问支持
  6、权限控制

七、TagLib

八、系统配置