• 创建:2006-7-19
  • 文章:46
  • 评论:311
  • 访问:202449
  •  

电力行业最成熟的信息系统是SCADA,最关注的业务是调度安全,而众多的SCADA数据采集系统形成了行业特有的数据整合关注领域。

这个领域的数据整合效果体现在多个调度中心之间的数据通讯,以及各种高级应用和管理运营系统对电网数据的强烈需求。

有句话叫“一具体就深入”,我来具体讨论一下,把这些调度数据从业务上分为3类:

1 电网模型数据

2 电网量测数据

3 电网图形数据

很多人觉得数据集成都是相同的方法,但实际过程中不同的数据应当采用不同的方式来进行集成。

区别的原因在于不同数据的有不同的更新频率以及业务要求。

例如:电网模型数据实际更新频率较慢,常常是以每个月的更新方式来更新基础模型,但电网模型作为一种电力核心数据,在业务上对拓扑链接的整合、设备信息的整合有独特业务的要求。

而电网量测数据则是每一秒都在变化,对集成速度、历史数据的访问都有非常强的技术要求。

因此在两种数据整合上必然就将采用不同的技术方式。

基于IEC 61970标准的GID接口设计了不同的符合SOA的接口定义可以为不同的领域数据提供不同的方案。

在不同厂家的系统根据自己的业务需求,都实现IEC 61970 GID接口,实现标准接口之间的调用就可以实现即插即用的企业架构应用。而采用IEC 61970集成总线来形成数据整合和交换的核心就成了未来电力数据整合SOA架构必然选择。

编辑 | 阅读全文(446) | 回复(0),liaobin 发表于 2008-6-12 21:21

最近大雪纷飞,许多人回不了家,春节货物也不能运输,大家都非常的痛苦。

想想我们的政府如果有一个全局的视图,能够把现场天气、各种交通出行、地点能放到一起来,提供预警预报、并提供给出行的人、车进行辅助分析,是否可以走、是否可以绕行,该是多好的事情啊。

刚刚看到google提供了ditu.google.com/chunjie来集成了地图、天气以及基本的交通情况,但这不是实时的,信息量靠手工维护,非常不足,如果政府能够提供公共数据接口,应该可以为辅助解决交通问题起到非常大的作用。

企业常常是需要SOA来解决集成问题。这次的事件其实也体现了政府和公共服务行业更需要不同部门、不同地域、不同行业的信息集成。

SOA前途光明。

编辑 | 阅读全文(541) | 回复(1),liaobin 发表于 2008-1-31 23:45

2007-12-18 13:2 | 关于SOA的成熟度模型

最近参加了几个大厂商的发布会,各大厂商在年底都推了新的基于SOA理念的产品版本,许多厂商也提到了SOA能力成熟度模型的问题。

但很多的看法是直接借用了CMMI的模型,我觉得这其实对用户是误导,我们在这个问题上只能借用CMMI的方法,而不能照搬他的模型。

我们可以看看CMMI的作用是什么:

1通过PA过程域 可以量化我们改进的活动

2 通过不同等级可以量化我们能改进的层次

而CMMI是针对于软件业的,它的具体需要实施的活动和能力层次的划分并不适合于SOA,我以前就讨论过EAI的成熟度模型,对于一个企业的SOA成熟度模型来说,由于企业的实施SOA中的比较大的问题是SOA不是一个项目,而是一组项目,不是一个短期的活动,而是一个长期的活动,因此在这样的差异条件下,有一个良好的路线图可以使我们达到SOA的远期目标:即插即用的整合,是非常有必要的。

要做到长期坚持一件事情不容易,我比较赞同SOA治理这个概念,通过SOA组织来达到长期的活动指导。

而路线图(成熟度模型)可以使我们的SOA组织可以有明确的长期的奋斗方向。

 

编辑 | 阅读全文(564) | 回复(0),liaobin 发表于 2007-12-18 13:2

遇到几个朋友讨论ESB,有人说我们要上ESB,因为它可以减少企业内的接口开发,降低成本。

是这样的吗?

总线凭什么就减少了接口总量了?有人说,总线可以代理啊,把原来的点对点变成了,每个系统只对总线访问,所以减少了接口。

其实这个问题画个图就很容易看出来,即便是把原来的点对点换成总线也没有减少一个接口,原来在系统中开发的接口仍然要开发。

那ESB减少了什么工作量呢?从总线的图上可以很容易看到,它可以减少一个系统访问多个系统资源时的麻烦。

那接口怎么才能减少呢?其实接口的数量取决于业务模块划分,业务模块之间的功能要求,以及作为接口的服务粒度大小以及接口的灵活程度。

编辑 | 阅读全文(810) | 回复(1),liaobin 发表于 2007-11-21 9:31

2007-10-18 15:47 | [原创]SOA 不等于 EAI

如何看待SOA和EAI的关系,SOA是解决EAI的方法吗?

我的观点是:确实SOA可以解决EAI的问题,但SOA是设计一个合理企业IT架构,更多的是从合理的架构设计来使得企业IT环境变得更有序、更有灵活性并且更有可扩展性,而EAI本身从原有历史来说是被动的解决信息孤岛问题,而不是主动的防护。

简单的说就是一个是主动的方法,一个是被动的方法。

编辑 | 阅读全文(1448) | 回复(2),liaobin 发表于 2007-10-18 15:47

先看看什么是语义web,网上很多,我摘录一些:

Berners-Lee 于2000-12-18 在XML2000 的会议上正式提出了语义Web。
语义Web 的目标是使得Web 上的信息具有计算机可以理解的语义,满足智能软件代理(Agent) 对WWW 上异构和分布信息的有效访问和搜索。
Berners-Lee 为未来的Web 发展提出了基于语义的体系结构-语义Web 体系结构。该体系中从底层到高层分别为 :UNICODE 和URI、XML 、RDF、Ontology、Logic 、Proof 、Trust 。


XML
XML 作为一种资源描述语言,由于其良好的可扩展性和灵活性,适合于表示各种信息,因而被广泛接受,已被认为是未来Web 上数据交换的标准。XML 不仅提供对资源内容的表示,同时也提供资源所具有的结构信息。但是,从方便信息搜索的角度看来,仅有XML 是不够的。

RDF
是W3C 推荐的用于描述和处理元数据的一个草案,能为Web 上的应用程序之间交互提供机器能理解(处理) 的信息。它独立于任何语言,适用于任何领域,是处理元数据的基础。
问题
XML 和RDF 在处理语义上存在两个问题:
(1) 同一概念有多种词汇表示;
(2) 同一个词有多种含义(概念) 。

解决方法
为了解决上述两个问题,很自然地需要引入Ontology。
Ontology 通过对概念的严格定义和概念与概念之间的关系来确定概念精确含义,表示共同认可的、可共享的知识。
对于Ontology来说,Author ,Creator 和Writer 是同一个概念,而Doctor 在大学和医院分别表示的是两个概念。因此在语义Web 中,Ontology 具有非常重要的地位,是解决语义层次上Web 信息共享和交换的基础。
Ontology的一些描述语言
Ontology 的具体表示需要用描述语言来实现。目前有多种基于一阶逻辑的Ontology 描述语言,如Ontolingua 、Loom 等。对于Web 上的应用程序而言,需要一个通用的标准语言来表示Ontology ,以避免在各种描述语言之间的转换。
由于XML 已被认为是Web 上数据交换的标准语言,因此,一些研究人员开发了基于XML 语法的描述语言。这些语言包括[:SHOE、OML 、XOL 、Riboweb、RDFS 和OIL

在企业环境中,也大量存在语法和语义描述的问题,我们可以容易通过本体技术来解决企业内部的数据描述问题。

OWL是现在W3C的本体描述标准,可以较好的解决本体描述问题。

编辑 | 阅读全文(1415) | 回复(0),liaobin 发表于 2007-10-18 15:21
关键字:电力

SOA厂商常常说有了SOA之后企业就可以集成的很好了,是否真的如此呢?

至少我是不相信的。

确实,SOA是我们进了一大步,使得整个企业环境有了一个统一的集成技术标准。

两个系统都号称是SOA的,例如一个是财务系统、一个是EAM系统你觉得他们就可以简单快速集成吗?还是困难,难在那里呢?

难在两个系统间的数据语义和数据格式不统一,难在不同企业业务流程有变化。这就引入了需要语义的集成标准、数据传输格式的标准和业务功能模块的标准。

在电力领域的CIM模型就是语义的标准,它描述了电力系统的对象模型,使得电力系统的对象模型可以在尊从这个标准的所有系统间容易识别。

并且通过IEC 61968标准定义了基于WEB服务的业务接口标准,这就使得业务功能可以即插即用了。

但业务领域的定义远不如技术领域的定义和标准化来的快,达到USB这样的即插即用还只能是在企业小范围业务定义内可以达到。

 

编辑 | 阅读全文(1772) | 回复(2),liaobin 发表于 2007-10-18 15:7
关键字:应用软件

OSGi这段时间越来越流行,自从Eclipse采用了OSGi的插件式结构,OSGi就成熟起来了。

OSGi Alliance是一个由升阳IBM爱立信等于1999年3月成立的开放的标准化组织,最初名为Connected Alliance。该组织及其标准原本主要目的在于使服务提供商通过住宅网关,为各种家庭智能设备提供各种服务。目前该平台逐渐成为一个为室内、交通工具、移动电话和其他环境下的所有类型的网络设备的应用程序和服务进行传递和远程管理的开放式服务平台。

OSGi框架实现了一个优雅、完整和动态的组件模型。2003年Eclipse选择OSGi作为其插件的底层运行时架构。Equinox project对该理念进行了实验,2004年6月在Eclipse3 r3中发布。

OSGi分为三个层次,服务层、服务调用层、服务实现层。

 使用OSGi可以搭建一个动态的JAVA系统,一个系统能够动态化就意味着:
★ 添加新功能时不需要重启系统;
★ 修改已存在的功能时不需要重启系统;
★ 删除一些不需要的功能时不需要重启系统;
★ 修改系统中的配置时可以不需要重启系统即刻生效;
★ 系统的业务行为可动态的改变。
OSGi实现了在单一系统中服务积木化,比普元宣传了多年的EOS来的实用化多了。

SOA的概念中比较核心的问题是面向服务的发布、查找、调用(绑定)概念和OSGi里面的概念非常类似,而OSGi还包含了组件的全生命周期管理,这个是SOA中需要而没有涉及的。

通常SOA是面向A2A(应用到应用)的,SOA的粒度更大,更加企业级,或者企业和企业之间来实现,通过UDDI来发布和查询服务,通过ESB的路由编辑来绑定服务和路由,还不能很好的自动发现和绑定。

新技术的常常可以带来行业的业务分工,如果所有的应用和应用内部都可以按照一种规格化的方式模块化,这些模块就可以被独立的开发和交易,产生行业的细分和专业细分。

软件行业在行业内的业务分离脚步越来越快,和模块细分的时代越来越近了。

 

编辑 | 阅读全文(1610) | 回复(2),liaobin 发表于 2007-10-17 23:1
关键字:廖斌

这是我总结的4大原因:

  

解决的方案可以针对这四大原因来寻找。

编辑 | 阅读全文(1014) | 回复(4),liaobin 发表于 2007-5-25 0:13
关键字:廖斌

信息集成其实就是依赖一系列的标准使不同业务系统之间可以互联。

这里且不去评论集成异构系统之间的技术标准,单说业务语义方面的标准:

OASIS电子政务技术委员会,http://www.oasis-open.org/committees/egov
OASIS法律XML技术委员会,http://www.legalxml.org
OASIS税务XML技术委员会,http://www.oasis-open.org/committees/tax/
世界专利组织的XML专利文件格式标准,http://www.wipo.int/pct-safe/epct/xml_world_standard.htm
会议论文XML,http://www.gca.org/
投资与金融研究信息XML,http://www.rixml.org/
人力资源XML联盟,http://www.hr-xml.org
商业报表XML,http://www.xbrl.org
Health Level 7,http://www.hl7.org/
SWIFT金融机构交流协会,http://www.swift.com
OASIS通用商务语言技术委员会,http://www.oasis-open.org/committees/ubl/
中文办公软件文件格式XML标准研究,http://www.ec.org.cn/2004-05/09/content_1458956.htm
基于XML的电子公文格式规范,http://www.egs.org.cn/upload/WG1.pdf


电力企业常用信息集成标准

以下简单介绍一些上述标准:

IEC 61968

61968是电力行业的信息集成标准,是IEC 组织提供的标准。
从标准的业务范围上来看,61968包含了配电管理的中的工作管理、资产管理等全面的内容。
从标准采用的技术方案来看,61968采用了基于UML语言的CIM模型来描述业务元数据,采用了XSD的方法来描述业务之间交换表单,并同OAG合作采借鉴了动词的封装方式表述业务之间的逻辑关系。
61968不涉及技术描述,可以同现有SOA做较好的融合。

HR-XML主要目标和应用范围

HR-XML联盟是一个独立的非盈利机构,其宗旨是发展和促进有关XML细分部分的一系列方法,从而实现电子商务和与人力资源有关的数据交换自动化。与人力资源相关的电子商务,或任何公司间人力资源数据的交换,都要求各参与方之间就数据交换的方式方法达成协议。
HR-XML联盟的任务是帮助节省雇主和提供商之间在个案基础上就数据交换机制进行谈判并达成协议时所花费的费用,并减少相应的风险。联盟将通过开发和出版以可延展升级语言(“XML”)为基础的开放式数据交换标准,提供任何公司同其它公司进行数据交换的方法,而不需建立、设计和实施许多不同的交换机制。


金融 XML 语言

金融服务行业建立了多种标准 XML 格式以满足自身专门的需要。多数标准工作都致力于语义定义良好的文档格式——无论它们如何通信。该行业被分成一些互相交叉的专门领域,形成一个混乱的网 络,针对不同的领域已经出现了几种 XML 格式。例如: Interactive Financial Exchange (IFX)和 Open Financial Exchange (OFX)这样的标准,它们处理的对象是消费者和其他形式的小额银行业务。
该行业中自动化贸易的最早尝试是基于 EDI 的,最近的 Financial Information eXchange (FIX)(当前是 4.4 版)是作为产权交易数据的标准通信协议出现的。FIX 关注的是交易的前端事务方面,与交易的协商与执行有关。FIX 出现在 XML 之前,有 10 年了,最初它的有效载荷以二进制形式传输,但在最近的版本中使用 XML 开发了 FIX Markup Language (FIXML)为 FIX 协议表示业务消息。最初,XML 消息因为太大而受到指责,但新的模式设计规则已经使消息大小更加合适了。不幸的是,现行使用的 FIX 至少有 5 种不同的风格,而且类似的领域还可以发现其他的规范如 SWIFT(参见 后述)。于是,各个方面包括维护 FIX 的联盟 FIX Protocol Limited,都同意在 ISO 15022XML Working Group (TC68/SC4/WG 10) 的旗帜下实现真正的标准化,后者属于 ISO 银行业、证券业及相关金融服务委员会。
Society for Worldwide Interbank Financial Telecommunication(世界银行同业金融电信协会, SWIFT) 拥 有一个通信协议作为 FIX 的补充,该协议主要针对后台交易事务操作,比如交易执行后所进行的结算。和 FIX 一样,SWIFT 也并非一开始就采用 XML 数据格式,但是在加入 ISO 15022 XML Working Group 后,SWIFT 已经采用 XML 作为主要的表示格式,并把它的历史悠久的数据模型转化成了 XML 模式形式。

OFX

OFX(Open Financial Exchange)也是XML的一种标记集,用于描述会计事务所与客户之间的业务往来。使用OFX,客户与会计事务所之间可以直接交换财务数据 ,包括电子银行和支付协议等说明文件。
多年以前,交互式金融交易平台(IFX)从 OFX 银行组织派生出来,OFX 银行组织的目的是为个人理财市场的客户提供解决方案和标准。IFX的形成增强了商业银行、自动柜员机、银行之间、以及商业支付线的工作能力。几年来, IFX 规范取得了巨大成功并被广泛采用, 最显著的表现是其被大多数ATM厂商和OEM所应用。客户和经销商以不同方式选择采用IFX 规格。但最关键的是,他们可以在银行机构内外使用被行业认可的数据标准和信息模式来传输数据。
几年以前,当Web services开始掌控技术界时,显然数据标准成为了在基于SOAP 和 XML信息基础构造之上传输商业信息的关键。最近几年,这些数据标准正努力迎合新出现的体系架构。这种体系架构目前被称之为服务定位。在这种努力下,目前 已经形成更颗粒化的,以信息为基础的商业信息构架。此框架有更多的组成数据元素,并有公共安全框架支持。
对于这研究方向,IFX也不例外。 在IFX 商业信息规范现在和过去的版本中,都经历了DTD和早期的XSD时代,他们从从DTD模式继承了相同整体结构。目前,为了与服务定位达成一致,IFX 的发展致力于捕捉信息的粒度。
一年以前, IFX 努力开始与其他的标准组织合作,在交叉领域中定义" 交易内核 " 。核心的数据信息被压缩成跨行业共同认可的格式,这种格式支持金融机构之间的货币交易。此内核是一个可扩充的基础信息, 但是其本身又包含必要的处理指令和汇款信息用以在两个机构之间处理交易和支付。这个交易内核的真正价值在于协同互用性和行业接受度,这点对于任何类型交易 都非常重要。这个跨行业的成果被称为 IST Harmonization,全球的银行组织都可以采用它,就如同SWIFT、 RosettaNet 和 IFX 标准一样。

IFX 标准也包括许多帮助银行进行内部交易处理商业银行信息。比如:将资金在两个账户之间转帐。POC证明了上述商业信息是如何推动了被称之为No Fail Bill Pay的新的交易模式。在这个模式里消费者可以通过设置参数允许银行系统查看其他帐户资金,并且做出适度调整弥补帐户支付来避免透支和NSF的责令。

SWIFT

SWIFT又称:“环球同业银行金融电讯协会”,是国际银行同业间的国际合作组织,成立于一九七三年,目前全球大多数国家大多数银行已使用SWIFT系 统。SWIFT的使用,使银行的结算提供了安全、可靠、快捷、标准化、自动化的通讯业务,从而大大提高了银行的结算速度。
SWIFT用户包括三种类型,分别为:会员(股东)、子会员以及普通用户。会员享受所有SWIFT服务,普通用户只拥有与其业务相关的服务,主要来自于证 券行业,如证券中介、投资管理公司、基金管理公司等。 SWIFT的核心应用称为FIN,一种基于存储和转发机制的报文服务。从全球范围来看,90%以 上的报文流量来自于支付与证券交易,欧洲的流量超过66%。2002年,SWIFT报文承载量达8亿,日均7百万条,金额超过6万亿欧元。 SWIFT提 供了各种类型支付系统的连接能力,包括CLS:Continuous Linked Settlement,连续联结结算;Netting:净额系统,如EURO1、STEP1;证券交易系统:如Euronext;CSDs:证券集中保 管,如英国与爱尔兰的CREST;CCPs:如中央登记结算公司;ICSDs:国际证券集中保管,如Euroclear、Clear- stream;RTGS:实时全额结算系统。


编辑 | 阅读全文(2266) | 回复(0),liaobin 发表于 2007-3-20 13:35

前面讲过信息化的三个阶段,如何量化描述这些阶段呢?

信息化的三个成熟度阶段:

1 信息辅助业务

   实现业务电算化,解决电子流转问题,解决基础大量数据记录问题。

2 信息支撑业务

   主要业务运行在关键系统上,例如ERP、CRM等系统

   主要的业务过程已经标准化了,数据已经进行过梳理

3 信息引领业务

   可以根据日常数据进行业务分析,数据挖掘、建立企业KPI,进行持续改进。

   建立了企业信息架构(数据、业务、过程、系统),实现企业级EAI,系统能够快速应对业务变化。

   系统的建立按照行业工业标准,企业间上下游信息可以互动,信息直达客户

编辑 | 阅读全文(4443) | 回复(2),liaobin 发表于 2007-2-7 23:1
关键字:廖斌
很多人说EAI缺乏应用场景,SOA是在炒概念,其实是一个东西没有到用的时候就难以看到他的价值。
国外信息化比国内更成熟,eai就发展的更充分一些,国内信息化基础系统刚刚建立,EAI市场刚刚开始预热。

企业信息化通常是从部门开始的,先做电算化,其实就是把手工的东西变成计算机自动作,这时部门的基础工作很多都可以完成了。
这时,就开始产生企业级信息化的需求了,企业信息化的需求通常是流程化的、跨部门的,BPM这么热其实说明了企业整体概念加强了,原来部门级垂直的信息系统就不能满足要求了,因此出现了EAI,SOA等解决方案。

信息规划常常难以规划到这个程度,并且信息规划在实际操作中也并没有被企业真正很好的贯彻了。

因此,EAI其实也是常常是“先污染,后治理”的过程。
编辑 | 阅读全文(3572) | 回复(1),liaobin 发表于 2007-2-7 22:37
关键字:廖斌
SOA的实现需要技术和业务标准的共同努力,在技术上,MQ、WEB服务等标准已经相对成熟了,ESB技术也开始成熟或者说可用了。
但SOA不仅仅是个技术,而且同业务标准化息息相关,很多企业寄希望于自己把这块做好,或做业务规划、或做数据规划,但在业务上,期望通过单个企业来把业务标准化,或者重用,不太现实,需要依赖行业标准的力量,把所有相关企业的力量结合起来。
这才能够弥补SOA在业务标准和数据标准上的鸿沟。

在电力行业领域已经开始有自己的数据集成标准了,我们可以利用这些标准来在实际项目中获取益处,例如:
* 变电站内部:IEC 61850
* 控制中心之间:IEC 61970
* 配网管理:IEC 61968, Multispeak
* 人力资源:HR-XML
* 财务: OFX,SWIFT
* ERP:OAGIS

只有解决了业务模块化、标准化,才能体现SOA的灵活益处。
编辑 | 阅读全文(4035) | 回复(4),liaobin 发表于 2007-2-3 20:40

2006-12-27 10:8 | 企业架构(EA)规划

关键字:廖斌

企业架构规划类似于城市规划,为企业提供整体的系统架构规划,从规划过程来说可以通过做好重点领域的规划来达到抓大放小、整体建设的目标。

企业架构(Enterprise Architecture,EA) 分析可以链接业务战略、IT战略和IT实现之间的鸿沟。EA将过程、标准、接口和公共服务的部署和实现联系企业,最终支持业务目标的实现。

采用EA的方法将为企业带来“战略”到“实现”的链接,链接的主要方法是:

* 分析企业战略和业务战略
* 分析当前企业业务架构和技术架构
* 对比分析获得技术架构支撑实现业务目标的实现差距
* 提出现有系统提出建设要求
* 对未来项目提出符合架构设计的管理要求

信息系统可以通过结构化的描述,使得规划的成果未来能够有效理解、应用,并且扩充,采用ARIS的描述方法可以有效的进行结构化描述。

编辑 | 阅读全文(3275) | 回复(1),liaobin 发表于 2006-12-27 10:8

2006-11-19 13:45 | 信息化标准漫谈[2]

关键字:廖斌
这回聊聊业务驱动的信息化标准方法。
这3年基本在研究iec 61970/61968标准,相关的标准也看看,但不深入。不过标准制定的方法都是类似的。

1 确定业务场景
2 分析业务过程
3 抽取业务交互点数据
4 建立数据模型
5 增加到标准模型中

不同的标准有一些差异,但总的来说从具体业务出发来规范标准的方法是一致的。
业务场景(或用例)这个方法用的非常普遍,这带来几个好处:

1 标准是逐步覆盖业务的过程的(穷举方式)
2 每个用例可以成为典型案例,容易推广
3 同业务实际结合紧密

不同的地方在于:
1 确定业务场景的方法是否完整的采用用例的方式,或是有些变通
2 建模的方法不一定采用了UML方法,也可以有E-R方式或别的方式
3 交换的数据模型标准不一定采用了同样的技术,例如MQ,WEB服务
4 封装的格式有差异,XSD的设计有不同的考虑。

业务驱动的方式是一个长期业务建模的方法,同时也可以容易将任务分解掉,不停的增加和容纳新的业务信息。
给标准带来更好的开放性。
在标准制定的过程中,采用行业标准也是一个趋势,不再使用以往的一些私有方法,例如EDI,现在也在向XSD的方式转。
编辑 | 阅读全文(2600) | 回复(0),liaobin 发表于 2006-11-19 13:45
(共 24 条) 上一页 1 2

仅列出标题