zhaobin

增强信息技术;感悟商业管理;探索商业与技术融合;丰富自我修养;享受时尚生活;记录心路历程;使Blog作为自我改变之记录与监督的平台。
posts - 15, comments - 35, trackbacks - 0, articles - 0
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

最新评论

re: 网络OSGi资料精华收藏 dishmily 2008-04-20 07:44  
谢谢了,不错。
最近关于osgi的帖子好像少了,只有bluedavy活跃了
告谢大家,已中标。
签个单子,用做项目的方式去做标准。本身就比较可笑。
想清楚什么情况下做项目,什么情况下做产品,什么情况下做标准...
这个本身还是需要想一想的。
想清楚了,再问自己,这么做行吗?
想清楚了,再做不晚。

不是业界的老大们在一起碰撞,协商;而是凭借权利去做什么事情;这是国内软件发展到今天,还是一盘散沙的一个重要原因。这个局面的形成和政务信息化建设中那些及其强势的客户也很有关系。他们的思路不转变,统一的电子政务也很难作成。靠政治强权去统一技术路也不好走。
所以,我觉的做这件工作基本没什么价值。
不是停留在理论上面,就是做出来也没人用。
这件事情做成需要技术厂商和客户共同协商。甚至需要政治改革的成功做保证。
re: 关于《电子政务流程服务规范》 zhanggongyi 2008-01-04 18:09  
@wangshu
赞同《电子政务流程服务规范》必须重点考虑“电子政务”。
@zhaobin
目前“电子政务”有两个特征是比较显著的:
1、“群雄割据”,这是电子政务用户、供应商共同营造和面临的现实局面。没有哪个供应商轻言愿意遵守另一供应商的规范,通常下级政府也对上级政府的出台的规范置若罔闻。
2、“用户主导”,电子政务用户是各级党政机关,很强势。供应商大多情况下是按需修改完善。导致电子政务应用管理软件,多是项目模式,绝少产品模式。
面对此景,楼主提出 “简单实用”,正好可以发挥供应商身份的实践经验。关键是必须找好实用的着力点,达到规范可用的目的。
一个可参考的着力点是:利用《电子政务流程服务规范》作指导,一个政府用户购买一家供应商的流程服务后,即可应用于需要流程服务的其他业务系统。其他厂商所承建的业务系统所需流程服务由此提供。对于该用户而言,他的流程服务是规范的、单一,易于管理、应用,同时降低业务系统建设成本。
如果基于这种着力点的简单实用主义规范,我觉得《电子政务流程服务规范》所需重点描述的是流程服务表层:
1、 电子政务流程需要提供哪些服务?
2、 电子政务业务如何应用这些服务?
也许这就是服务的本质,我不管服务内部怎么实现,我就想知道应该有哪些服务,如何规范的应用这些服务。
@李文章
赞同“更多的关注与二次接口调用和整合相关的描述”
@ 银狐999
如何描述确实是个重点,没有简单明白的表达,规范就缺乏生命力。
@ronghao
“对业务加以诠释(也算是一种标准,但不是API),例如什么是会签、传阅等等,它们用以处理哪些业务场景等等”,对流程服务内部的业务描述确实也是一个有益方向。赞同。
zb,我对服务规范的理解是如何说明能把复杂的问题简单化,各家都有自己的一些扩展标准,不变的是政务需求本身,既然是业务领域的规范,应该首先尊重业务领域,其次是技术实现
@赵斌
"也就是说,不要求界定内部的实现,只要能通过服务的形式,提供这些功能就好了。"很赞同,特定于电子政务,我认为一开始可以对业务加以诠释(也算是一种标准,但不是API),例如什么是会签、传阅等等,它们用以处理哪些业务场景等等。这样再提到工作流产品的时候,是否支持会签等就直接成为一个衡量的标准。而至于如何实现,实际上是非常灵活的。
@李文章
总体赞同,尤其是非常赞同这一句:“而对于"WFMC"的五个接口说实话个人意见其抽象度更甚于XPDL亦或BPEL”,我就是希望能在更高层面、更抽象的描述流程服务,这样具有更广的容纳性,至于采用何种流程描述语言或运行机制,都可以。
而对于流程标准个人意见:是否应该更多的关注与二次接口调用和整合相关的描述。——赞同!
@银狐999
我从比较简单的角度来考虑这个问题:流程描述我倾向于在XPDL上面做扩展,图形的表示方式侧重于BPMN,但为什么在流程服务规范上没有规定或限定这方面的内容?
因为这2方面比较容易引起争议,而且很难说谁更正确。
标准刚刚开始起步,应该获得更多人的支持,而不是争议。
所以,我跳过了这2个问题,只是去定义“服务”的规范。
也就是说,只要能提供这些“服务”(或者说API功能)的就符合流程服务规范。
也就是说,不要求界定内部的实现,只要能通过服务的形式,提供这些功能就好了。
你提的第三个问题,倒可以考虑,在国外流程服务规范上,增加电子政务的特色,将业务所需的API增加上。
你提的问题1、2可以在今后进一步的规范上增加。
@Wangshu
赞同在《流程服务规范》中,针对电子政务的业务需求,增加功能性的API,也就是电子政务的流程的服务。
但不赞同增加功能项的描述和界定,不同的产品千差万别,最后只能形成一个无所不能的大杂烩,功能总是越多越好。至于在招投标过程的详细规则,也只描述服务层面的内容,只界定作为一个流程服务的产品,应该提供哪些流程服务,不应该涉及其他。
re: 关于《电子政务流程服务规范》 李文章 2008-01-02 10:01  
这确实是一个很头疼的问题,但是否需要明确一下什么人(厂商)来去执行标准?让参与建设的工作流厂商!很不好办!从现在的情况来看应该很少会有厂商为了符合你的标准而去改变自有的“标准”体系。哪就剩下集成商了,但对于一个非“工作流圈内”的实体,去谈BPEL还是XPDL或者自定义标准都难免有点曲高和寡!而对于"WFMC"的五个接口说实话个人意见其抽象度更甚于XPDL亦或BPEL;更是一个面向“圈内人士”的描述,不是在谈怎么去用工作流而是怎么去实现一个“工作流引擎”。
而对于流程标准个人意见:是否应该更多的关注与二次接口调用和整合相关的描述。
hi, 老赵,对你所提的《电子政务流程服务规范》,说一点个人的意见。

首先WfMC的《工作流参考模型》,是值得参考和引用的。毕竟从结构上来说,所有的流程系统都会围绕这套“参考结构”来实现。但是,这并不能保证你的《流程服务规范》真正能够落实到实处。—— 我很同意你所说的“规范不考虑实现”,但是“规范需要解决如何描述的问题”。

(1)你如何解决“流程描述语言”问题?是扩展XPDL,还是扩展BPEL,异或者是自主定义一套?
(2)如何标准化流程定义的图元?是扩展BPMN,还是定义一套国内客户更为容易接受的图元?
(3)如何在流程描述中体现国内的流程特色?回退,取回,跳转,会签,加签,剪签等等。虽然这个更偏重于业务化功能特色,但是,如何提供更统一或者更基础的的描述规范,将这些语义“规范”,将行为“规范”。

如果这三个问题不解决,所提的《流程服务规范》,最终,或许依然只能是一句空谈。
我对工作流的具体技术了解较少,但对电子政务及其业务有比较深的体会。如果说这个流程服务规范与其他的相关工作流规范有什么不同,我觉得最大的不同点在于“电子政务”这四个字。因此,规范描述的应该是一些通用的东西。从政府业务上看,那些东西是通用的了?“公文流转”、“行政审批”。是否可以从业务层面规范一些典型的应用功能,做为电子政务的工作流所必需具备的功能项。从而可以指导不同的政府用户在立项、招标的过程中对工作流的技术规格能够提出全面、准确、具有前瞻性的详细规格要求。
范玉顺怎么了,"可饭否?"
收集了有关范玉顺的工作流文章,大家看看: http://www.agilestep.cn/theory/document/FanYuShun.html
re: 网络OSGi资料精华收藏 jidongxu 2007-11-27 13:46  
整理的很好,谢谢楼主
lz
辛苦啦!
太nb了
re: 网络OSGi资料精华收藏 BlueDavy 2007-11-06 14:32  
:),整理的不错,好东西呀...
re: 网络OSGi资料精华收藏 隔叶黄莺 2007-11-06 14:01  
收藏了,谢谢
re: 网络OSGi资料精华收藏 Reg 2007-11-06 12:04  
顶,整理的不错哈。学习ing。。。
对您的印象非常深刻,对什么问题都有自己成熟的思考,相比而言,自己要学得非常多。
re: 浪潮Loushang平台参观有感 赵斌 2007-08-21 13:01  
@朱金晨
谢谢提醒,回头了解一下。
re: 浪潮Loushang平台参观有感 朱金晨 2007-08-21 11:47  
其实在浪潮,除了楼上还有一个平台GSP,楼主有空可以了解一下,从设计的思想上比楼上更新,但从整体的面上来说,没有楼上铺的那么广。
re: 支持BPEL的开源工作流 cnodin 2007-04-08 01:15  
楼主啊,你发链接上来也检查一下啊。有的项目已经closed了
re: 浪潮Loushang平台参观有感 sun 2007-03-02 10:13  
Loushang肯定是值得学习的,至少他在新一轮的技术领域已经走出了第一步,坚持下去,1-2年后loushang一定会变得更强壮。如果一步也不走,仅仅是“参观”,在未来市场中,公司的产品一定会处于劣势。
新产品的开发要投入巨大的人力财力,经营者和技术研究者的思路通常是有冲突的。新产品的开发在2种情况下最容易实现,财力雄厚的大公司;刚刚起步的小公司。中不溜的公司一不小心就容易成为下一轮技术浪潮中的淘汰者。这也就是应了IT界中一般软件企业5年一个轮回的宿命。怎样才能摆脱这种宿命的结局?如果你已经是一个技术管理者,引导公司技术从中等规模走向发展,在研发和项目中找到平衡点,合理组织不同知识结构的技术团队,这些都是和“MDA”一样重要的议题。
不是来泼冷水或者砸场子。
MDA依然是看起来不错,但如果在企业中真照那套做大家都玩完的。
倒是JetBrain的MPS和MS的DSL更贴近实践些!
我是没有看过浪潮的那套,不过我一直怀疑其只是简单的代码生成而已!
freeMind可以画
@sea

思维导图在国外还是比较火的,我使用的时间也不长,刚刚一年。
相应的软件有免费的,也有收费的,当然,网上也能找到破解的。
推荐一个网址:http://www.mind99.com/
首先感谢作者这篇文章,写的不错哦,其次想问下,作者画思维导图用的是啥工具,是免费的还是收费的?
re: 浪潮Loushang平台参观有感 Ivan Chen(西滨) 2007-03-02 09:09  
补上昨天的评论:
远程试用Loushang的时候,速度慢得要死,至于是网速慢还是系统慢,不好说。浪潮的人回访的时候,让寄张光盘过来看看,至今也还没有收到,所以到目前为止还没有什么体验。
re: 浪潮Loushang平台参观有感 BeanSoft 2007-03-01 09:36  
呵呵, 我们仍需努力, 继续追赶世界一流厂商. 在这之前, 必须达到一流厂商刚起步时候的水平才行.
re: 浪潮Loushang平台参观有感 CowNew开源团队 2007-03-01 09:16  
和金蝶的EAS BOS比简直是小巫见大巫,在EAS BOS面前Loushang简直就是小朋友,呵呵。我已经从金蝶出来了,Loushang我也仔细研究过,我只想说Loushang不过如此。
re: 浪潮Loushang平台参观有感 坏男孩 2007-03-01 08:43  
楼上是浪潮的顶尖技术