自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+

纸上得来终觉浅,绝知此事要躬行

不会写代码的架构师绝对不是好架构师

  • 博客(16)
  • 收藏
  • 关注

原创 java中处理xml数据性能不能大幅提高的根本原因 - 继续追寻高性能xml解析方法

<br />这里讨论的处理xml数据,指包含复杂业务规则处理的场景,基于流的解析方法不在被讨论范围,下面只针对dom模型和xpath进行讨论。<br /> <br />主要原因有:xml是一种基于string或称文本数据描述方法,描述的是一种逻辑数据结构,不是计算机可以拿来直接进行处理的模型,必须经过解析处理,转换成计算机可以解析的模型(内存结构)。这个解析过程中包含的主要步骤有(考虑目前主流的dom解析器):读入xml string(分派xml原始大小的内存)扫描该xml string,构建dom,这个过

2010-09-29 14:16:00 1756

原创 透过现象看本质 - 壮志未酬的BPEL

<br />头不痛了,继续扯扯IT那点事。<br /> <br />先明确一下本文主旨,本人并不喜欢BPEL,仅从个人观点分析下BPEL因何而来,BPEL的局限,以及本人喜好的业务流程设计方法,希望能引起关心业务流程设计的人的进一步思考,别整天帮着老外吹他们的SOA解决方案来骗自己同胞的钱!<br /> <br /> <br />先理解一下工作流是个啥东东:<br /> <br /> <br />要说bpel,撇不开工作流,而工作流的出现,源于业务流程建模需要,业务流程建模的目标,是分离业务流程的表述与其技

2010-09-27 18:30:00 1022

原创 这几天跑哪儿去了?

偏头痛了好几天,今天终于没事了。我家多多还有2个月就要出世了,想想不出小家伙什么模样,:)!希望是个可爱的乖孩子,但千万别太老实,:)发觉自己真是有点老了,身体各个部分些小毛病越来越多,关节、颈椎、手腕、脑袋,等等等等,一个个的纷纷前来拜访,看来搞IT的,不管身体条件多好也得注意了,尤其是现在还年轻的弟弟妹妹,侄子侄女们,更要好好注意锻炼,出来混的迟早要还的,何况在我们这样一个社会福利远不健全的社会,你没能力生存就差不多只有死路一条了,所以付出时要长远考虑,千万不能以破坏“环境”为代价!名字真难起,想好的几

2010-09-27 16:13:00 483

原创 推荐给架构师一篇好文章

<br />在架构满天飞的世界,如何理清楚架构的定位,如何选择及抽象可重用参考架构等都是非常重要的需要思考的问题。<br /> <br />推荐给架构师们一片文章,希望能对大家在架构设计及选择过程中,有一个比较清楚的高层理解。<br /> <br />http://www.via-nova-architectura.org/magazine/magazine/enterprise-reference-architecture.html<br /> <br /> 

2010-09-22 12:15:00 440

原创 XQuery 作为xml数据转换引擎的软肋

当前很多的xml数据转换框架运行在XQuery引擎上,尤其是主流的SOA厂商产品,如oracle ESB等。先不提performance问题,就功能范围来讲,XQuery确实提供了丰富的数据转换函数,并允许提供自定义转换函数,能够支持非常复杂的xml结构的转换(当然,这种复杂度实际上应当在进行数据模型架构设计时由架构师尽量避免)。但个人认为,XQuery是一种中立的与编程语言无关的纯粹的面向xml的查询&转换语言,其应用场景定位于纯粹的xml语境中,其语言的操作范围仅限于XQuery运行时定义在XQuery

2010-09-21 17:23:00 793

原创 大概的了解了下javacc

jxpath中的xpath parser是使用了javacc来构建,生成了一个xpath语法分析器。jxpath对所有解析过的xpath,为了提高效率,避免重复解析,将结果放到了一个hashmap里。对于javacc,看起来貌似很神秘,其实倒也不复杂,关键是要具备一些编译原理的知识。搜了很多javacc文章,只有一篇文章感觉很好,感兴趣的大家可以参考:http://www.javaeye.com/topic/359454

2010-09-21 11:12:00 746

原创 Ehcache的BigMemory

<br />Ehcache增加了个新的功能,bigmemory,可以用来缓存更多的对象于jvm Heap之外的内存,可达350G,不受jvm GC控制。看来老外是真能琢磨,真敢想。<br /> <br />大概看了下文档,应用的时候通常还是需要配合inmemory来使用,例如设置inmemory缓存(heap中分配,受GC控制)为1G,超出部分使用big memory。<br /> <br />使用方法见:http://ehcache.org/documentation/offheap_store.html

2010-09-21 10:32:00 5442

原创 谈谈为什么ORMapping不适合企业应用的构建,以及未来企业应用系统构建需要什么要素

说明:本人文字功底欠佳,有问题欢迎继续深入探讨,本文允许转载,但请注明出处,谢谢本人向来不喜欢ORmapping技术,并且在所管理的项目中,极少使用ORMapping技术或框架,iBatis算是一半特例吧,因为iBatis不算是个完全的ORmapping框架,至少本人管理的项目中,ibatis从来都只算是数据库快速开发的一个工具罢了,有人可能钻牛角尖,说我根本不懂ORmapping,因为根本我就是在用ORmapping嘛,这里我不就此问题进行争论,何况ibatis也在逐步退出本人的可用技术列表。先说几点OR

2010-09-20 18:36:00 2407

原创 继续找寻高效xml处理引擎

早上又花了一点时间搜索了一下java平台下轻量的dom解析器,发现了2个东东:Nux和xmlzen,大概拜读了一小下:共同特点:都是在寻找一条高效xml解析之路,觉得目前流行的xml库都过于重量了,不太绿色,太大的不必要消耗。Nux:xquery based,不喜欢xquery晦涩的语法,另外,由于基于saxon,估计也不是我所找寻的高效解析器。xmlzen:更像是一个xml构造库,没看出来xpath的支持程度。http://code.google.com/p/xmlzen/wiki/Motivation总

2010-09-20 10:39:00 593

原创 杂谈:“专业”Consultant小零碎工具系列

<br />仅抛砖引玉!一个大大的笔记本(纸的啊!):记录灵感,展开想象,一对一沟通多色笔:时刻随身携带各种颜色的笔各一支(至少得有黑,兰,红的吧),更容易给人留下深刻印象。用途,使用不同颜色的标记,更容易理清思路。24x7 online系列:买个移动的XXX服务。手机查看outlook邮件那是必须地。人脉资料:谁能干啥,能干成啥,有啥癖好,是不是喜欢美女啥的,必须了如指掌常备菜谱:中国各大菜系得能说出个头头道道,吃饭的时候让人家不仅吃得好,更要知道吃得到底哪儿好了八卦新闻杂志PPT演示器<br />不花时

2010-09-16 16:54:00 352

原创 Memcached应用最佳实践

真是越来越感叹,人这种动物真是聪明,而且越来越聪明,但不管怎样,聪明来源于实践,来源于奋斗在一线的同仁们对问题的思考,来源于需求。常见的应用Memcached的solution,通常是会设置多台大内存的Memcached服务器来运行Memcached服务端,但这些服务端之间不可相互通信,也就是说谁都不知道谁的存在,各自独立作战。客户端,也就是web应用,把cache放在哪里,从哪里取cache,自己都要知道,通常是通过consistant hashing算法,根据key值对memcached 服务器实例进行

2010-09-15 12:44:00 563

原创 version control system 的后起之秀

<br />试用了一下TortoiseHg (Mercurial的图形化客户端),感觉还不错,不过试验了一下两个repository的sync操作,还没整明白是怎么回事,待有时间研究一下。<br /> <br />总体感觉TortoiseHg软件还需做的更精美一些,比起TortoiseSVN,还有一些差距,不过相信今后DVCS一定会大大超越传统VCS的应用。TortoiseHg一定会越做越好。<br /> <br />anyway,DVCS对异地并行作战的团队,还是相当有好处的,尤其适用于集成商在总部维护自

2010-09-15 01:32:00 626

原创 对主流SOA解决方案中BPM+ESB产品的一点看法

<br />本人对soa架构中BPM功能+ESB功能还是持有肯定看法的,面向业务的流程管理及service的管理定作为完整的soa方案不可或缺。<br /> <br />这里仅对主流soa产品厂商的导向保留个人看法:目前主流软件提供商均提供bpm产品和esb产品,两者通常为两个独立的产品,需要结合使用,而且包括多数咨询机构在内的集成商在完整的soa解决方案中也会同时选择两种产品。<br /> <br />个人认为,在xml解析及处理效率没有革命性的提升前提下,应用soa解决方案于高容量的核心(关键)业务,性

2010-09-14 20:39:00 1678

原创 很想重新强调一点关于soa的理解

今天看到一个soa的片子,关于其中为了说明soa的business value,引用的一幅图片,个人看过太多的这类片子,觉得这种比较方法都没说到根上,很容易让读者云里雾里,似懂非懂,然后拿去用来满载唾沫星子的又去忽悠别人。这个比较方法,没写过程序的人肯定容易看明白了,没准会发现新大陆般大呼小叫,SOA正是我想要的,对这种也不能说是SB的人,我不想多说。我这里只想提醒一下写过程序的人,别太过死钻牛角尖,花费时间去仔细对比这个所谓的nb service到底和十年前C程序中的function(service)有啥

2010-09-14 16:58:00 777

原创 关于JMS系统设计的几点建议

<br />回答一个老外同事关于JMS系统设计的几点建议,抄录如下,下图为其应用场景,消息流量1000条每秒<br /> <br /> <br /> <br />1.       Separate jms queues bese on function ( or systems) and volume requirement and message size, especially on volume requirement and size if you have concern on this.<br

2010-09-13 19:43:00 1041

原创 关于高性能xml解析问题的再思考

如今xml应用已经遍布天下,您是否还在您的应用中使用传统的SAX或DOM技术呢?回答yes是没有关系的,但问题是您有没有想过进一步提升xml的处理速度,减少内存使用率,使您的应用处理模型变得更为简化呢?周末花了点时间来思考这个问题,但似乎还没有找到更好的答案,:(,如果哪位高人有好的建议,欢迎交流!一点背景:本人近些年一直奋斗在电信行业BSS应用集成的一线,致力于简单、高性能、灵活的EAI架构的研究,在应用xml过程中,为提供统一的、简化的、可配置化的xml访问方法,基本只使用dom+xpath,在实现数据

2010-09-13 10:02:00 1098

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除