新传旗下数字化行销部门,正在客户数据、传播技术和营销创新领域进行持续投入,为不同行业包括信息技术、制造业、金融服务、房地产、旅游、消费品、医疗和教育等领域的客户提供整合数据库营销、网络活动营销、在线互动营销、整合渠道营销服务,长期帮助国际客户和国内企业赢得全国市场。 打造一流的在线行销OnlineMarketing团队,期待有远见的您加入。
您的每一份付出与努力都会得到回报! 更多…
尊敬的 Google 企业应用套件管理员,您好: 我们收到了您取消试用 ushop18.com 的 Google 企业应用专业版的申请。您的域已降到免费的标准版,您很快就会收到 Google Checkout 取消确认。由于您是在 30 天免费试用期内降级,而我们尚未向您的信用卡收取费用,因此您不会在您的信用卡明细单上看到退款。 您很快就会发现您的电子邮件帐户存储配额下降到标准版限制。您也不能再访问其他所有专业版功能(包括 Google 视频、99.9% 正常运行时间保证、集成 API 和关键问题的增强技术支持)。 我们很感谢您提供有关专业版的反馈。要回答几个简单的提问,请点击此处:< https://survey.googleratings.com/wix/p1291893.aspx 如果您想随时了解 Google 企业应用套件发生的更改,则可以在您的收件箱中获取更新,只需在以下网址进行订阅即可:< http://feedburner.google.com/fb/a/mailverify?uri=GoogleAppsUpdates 如果您决定不使用 Google 企业应用套件作为您的电子邮件解决方案,Google 还是可以帮助您保护您的公司免遭垃圾邮件和病毒的威胁,并且可以满足您的常规需求。点击此处了解更多:< http://www.google.com/a/security/ 如果您有任何问题,可以访问我们的帮助中心,网址为:。请勿回复此电子邮件,我们不会对此邮件的回复进行监管。 谨致 Google 企业应用套件团队
keso推荐一篇文章,引用“作为政府的网络服务”,很棒的一个分析。
这一段是将平台控制方类比为政府。
> A lot of people have begun using the term ecosystem to describe these big > platforms. That captures their decentralized, emergent character, but > ecosystems do not have a central point of control. Apple decided to > eliminate third party analytics between one release and the next. That > doesn’t happen in an ecosystem. The right analogy is a government.
下面这一段则让我联想到注明的“上者由之…最下者与之争”的中国古哲:
> If you accept the analogy of web services as governments, the example of > Craigslist offers a couple of insights. First, it’s possible to be > fabulously profitable as a restrained government, but perhaps at the expense > of top line revenue (or the government’s share of total GDP). And second, > that no web service is an island. Web services will compete with each other > for the time and attention of their users and for investment from the > private sector (applications developers), but they will do this in the > context of their host government’s who are also competing for tax revenues > and private sector investment.
目前为止主文下有86条评论/回复,也值得一读。
出处: http://www.unionsquareventures.com/2010/06/web-services-as-governments.php *布拉德 伯纳姆 **2010年6月10日* * * * *
分析师点评:
手机支付标准迟早会进行统一,尤其在近距支付方面,这对于市场的健康发展和社会资源的节省都具有较重要意义,区别只是以什么样的方式或者会以多长的时间进行博弈而已,单纯从技术成熟性和社会资源角度而言,中移动的2.4G确实没有太多优势,对整个产业发展也比较不利,因此手机支付标准向银联标准倾向的可能性极大,只是考虑到移动前期的投入和发展的TD产业,预计还会在时间和方式上做一些相对平衡的处理。
背景新闻:
近日关于中国移动暂停RF-SIM 推广的消息持续升温。有分析人士认为,此举将会给负责该业务芯片设计、封装、程序开发的国民技术、东信和平、恒宝股份等企业带来较大损失。
今日,国民技术率先发布说明公告,称截至昨日公司未收到过中国移动以任何形式发布的关于叫停RF-SIM”的通知、发言或公告。但若确定中国移动不采用 RFID-SIM作为移动支付业务解决方案,势必将对公司的营业收入和净利润产生一定影响。
RF-SIM研发仍在进行
国民技术去年7月24日与中国移动签订了RFID-SIM卡模块的合作框架协议,有效期2年。2009年,国民技术在移动支付芯片及解决方案上实现营业收入5165.84万元,占全年营业收入的11.09%。在今日公告中,国民技术称并未收到过中国移动以任何形式发布的关于叫停RF-SIM的通知、发言或公告,当前仍在持续支持和配合中国移动在 RFID-SIM 方向的技术、标准的研究和开发。
此前有分析指出,2010年全年的RF-SIM卡采购量将会有400万片,涉及约4亿元的市场。此外,由于RF-SIM方式需要更换POS终端,今年的RF-POS机的采购也将达到10余万台,又涉及数亿元的市场。现在看来可能都成了空中楼阁。
国民技术主要涉及芯片设计与制造,RFID-SIM移动支付芯片及解决方案既是该公司当前的产品线之一,也是它募集资金的投资项目。若中国移动确定不采用RFID-SIM作为移动支付业务解决方案,势必将对国民技术的营业收入和净利润产生一定影响。目前,国民技术正在评估相关事项的可能风险。
除国民技术外,中国移动主导的RF-SIM产业链所涉及的A股上市公司还有负责芯片封装的长电科技,负责SIM卡程序开发、卡基封装的东信和平和恒宝股份等公司。
叫停是迫于技术及成本问题
有消息称,中国移动已经在4月份暂时叫停了2009年主推的手机支付业务方式RF-SIM。取而代之的目前是中国银联主导的13.56MHz的NFC手机支付方式。目前,中国移动仅在部分试点城市继续RF-SIM方案。
此前有分析人士表示,中国移动和中国银联各执一种标准,两家的优势都很明显,前者拥有全球最大的移动手机用户群,后者的13.56MHz(即NFC)技术已经广泛应用于交通、金融、社保、加油等非接触卡片领域,因此两大巨头都希望在手机支付产业夺取主导地位。
但部分专家认为,由中国移动首家提出的2.4G标准(即RF-SIM)存在一些问题。一方面,其成熟度不高、标准不公开、安全性欠缺在内部被多次探讨;另一方面,目前银行、金融等机构布点的POS机等终端大都基于13.56MHz(即NFC)技术,和RF-SIM卡无法实现兼容,因此中国移动要推广其技术必须重新铺设终端。而RF-SIM卡以及相应POS机的采购费用高达数亿元。据了解,目前中国移动已采购了超过100万张RF-SIM卡,总值接近1亿元。高昂的成本是中国移动叫停RF-SIM的一个重要原因。
不过,有接近中国移动的人士表示,此举并不意味着彻底否定RF-SIM,只是短期内在该标准上不会有太大动作,”至少前期研发投入不至于’打水漂’。”(陈雅琼)
对话人生首页
http://www.wealink.com/weeklyredirect/index/?do=http%3A%2F%2Fwww.wealink.com%2Fdialog%2Findex%2F%3Fstatf%3Dtalklife_2010-06-07 第25期(2010-06-07) 若邻网Wealink.com
2003年出任掌上灵通公司CEO 2006年担任北极光创投的投资合伙人 2008年10月,创立领航资本投资公司 2009年3月,创立泰山天使投资公司
*若邻档案:* http://raymondyang_126com.wealink.com
*网站:* http://www.taishan-invest.com/
*杨镭:*这个机会非常偶然,那是1995年,美国波士顿技术公司驻亚太区的副总裁找到我,希望我成立销售短信技术和语音信箱技术的STI公司,于是我从硅谷回到北京,短信技术就这样来到了中国。当时波士顿技术公司在中国的市场占有率是零,刚开始整整8个月时间一分钱收入也没有,那时候我也会怀疑自己做的这件事情到底对不对,你所做的这件事情会不会被别人接受,你这个产品会不会被市场接受。但是强大的销售能力能创造奇迹,我有这样的自信,我从没去过公司在美国的总部,仅有的,只是当初公司给的两张产品介绍。三年不到的时间就一跃成为中国市场占有率第一,占有市场份额的70%,我当时重点把语音信箱卖给中国移动。“领先三步是先烈,领先一步是先进。”当时是“领先一步”,但是我是一个喜欢冒险的人,看准一个好的机会就会凭着直觉跳进去干。
若邻:1999年,您的中国语音信箱和短信公司成功以后,你却急流勇退地回到硅谷开始了自己人生中的又一次创业,网络情报公司做得非常成功,我们很好奇,后来的掌上灵通是怎么吸引您“重出江湖”的呢?
*杨镭:*我一直深信中国的手机用户市场的发展以及短信息在无线增值领域里的机会,这会是一个大事业。我喜欢“创业”的感觉,因为很享受创业过程中的每一步,哪怕这个过程是很艰难、很痛、很折磨人的,但这是一种有血有肉的生活方式,充满激情和战斗力。我同时很喜欢在一个大的市场,大的机会面前去轰轰烈烈地做一些事。我当时就朦胧地感觉到这样一个大的机会,当然后来验证我的直觉是对的。
若邻:到灵通您做的第一件事是什么? *杨镭:*灵通当时条件特别艰苦,办公室是由仓库改装的,连窗户都没有,一楼是一家餐馆,所以经常有很大的老鼠沿着管道爬到办公室里来,有几次一只很大的老鼠从员工头顶的管道上失足掉下落到正在工作的员工桌子上,吓得女孩子们哇哇大叫。当时办公地方也有限,只有一间会议室被隔成两段,一间是小会议室,另一间是前任CEO办公室。我进去第一件事就是要求不设CEO办公室而是和大家在一起拼个桌子坐在外面。。
若邻:这样的管理方式跟您在国外的事业经历有关吗? *杨镭:*是的,硅谷的经历给我这样的体会。当时灵通员工人也很少,几十个人。我要给大家树立一种信念,在公司困难的时候我进来,我要给大家一种感觉,是和大家同舟共济。另一方面我不让大家叫我‘杨总’,而叫‘Raymond’’,我不叫杨总,别的高管也就不好叫老总了,这样公司的文化更亲切了,我希望员工以公司为家,快乐工作,每天醒来都觉得很开心,上班见到自己的同事很高兴,这是一家热情、活力、充满激情的团队。
若邻:作为企业家出身的投资人,您有怎样的感受呢? *杨镭:*回想做企业的那些日子,公司的CEO、创始人特别像一个将军或元帅,在战斗中有流血牺牲的时候、有被敌人包围的时候、有冲出重围的时候……让我有强烈的英雄感。而纯投资人更像诸葛亮那样的谋士。我刚做VC时还有些不习惯,但越深入了解,越感受到投资领域既需要有将军气质和风范,又要有谋士眼光和韬略的投资人。 看一些企业的时候,我会用谋士的眼光去分析,某些时候也会把自己设身处地想象成企业的CEO,帮助企业去解决一些实战的问题,具体决策的执行。这是因为我不仅有经营企业的经验,同时我激情的火从未熄灭。 另外一个层面,创业者也非常愿意跟我沟通,他们很多人都说,跟我交流的体验是在跟别的投资人那感受不到的,我看问题的角度和提出的问题很尖锐,这些是普通的资本财务层面不会去问到的问题,但在工作运行中‘很细节’却是非常关键的问题。我非常愿意跟创业者交流一些体会。
若邻:您曾被评为“中国十大杰出CEO”、“世界尊敬的企业领袖”、 “首届华商领袖品牌人”等等,在您眼中,优秀的CEO需要有哪些素质呢? *杨镭:*这段时间我正好在总结,我的手机里记着几个要点,跟你分享一下。 首先是“激情”。“激情”是对一个行业的热爱,对一项事业的追求,有强烈的源动力,阻挡不了,有不撞南墙不回头的精神。他要实现一个梦想,而不是简单的去实现单纯“成功”和物质上的追求。创业的人需要把自己的目标设定得比较高,我也曾经少年轻狂,但成功的人都有高的追求和目标。人有两种,一种是为梦想而工作的,一种是为金钱而工作。作为一个企业的带头人,如果你是一个追梦者,那么走近你的和你欣赏的人也一定是追求梦想的人。当一群追求梦想的人一起打拼,一定比单纯追求短期利益的人更能获得成功。我认为这是CEO的首要素质。 我的同行包括竞争对手公司的人,都很尊敬我,他们说虽然杨镭不是公司的原始创始人,但是确实是把公司当作自己的来做。不管是企业家还是创业家,当用这种精神对待企业的时候,才是真正的创业家,我最欢的一个词就是Entrepreneur(创业者)。这个词原意就是“把自己看作是事情的主人”。当一个领导者、员工把企业当作是自己的,那么他的热量、精神和才华就会施展得淋漓尽致。 第二点就是“人”。作为一名CEO,需要吸纳人才。灵通的成功某一方面是因为把行业内优秀的人才吸引了过来。有句话说得很好——“一流人招一流人,二流人招三流人。”CEO就应该有这样的胸怀,招到甚至比自己更优秀的人。我想起在硅谷创业的时候,我的投资人问我:“你觉得CEO应该有什么样的素质?’我回答了很多点。但他听了后告诉我说,其实就两件事:‘带来好人,带来钱。’很精辟。如果一个企业有好的人才,成功的概率和把握度就很高,而且优秀的人才能让CEO的工作非常顺利,管理的过程不但不累,还很愉快。很多青年的企业家面临这样的问题可能会问:我现在还是小公司,也付不起很高的工资,我怎么带来人才?那就看你愿意不愿意把你的股份拿出来给优秀的人才。让别人分享你的梦想,也是需要胸怀。员工也会观察企业领导每一个细微的行为,身体力行非常重要。我在灵通有个原则,所有办公室,会议室的窗户、门都是透明的,我要塑造的就是一种文化:没有秘密,很透明、很公开、很平等。领导力是员工在内心对你的尊敬,分享公司成功的梦想。有人说我是福将,做任何事成功概率比较大,但成功都不是偶然的,我相信就算不是做掌上灵通,做掌上蓝通、掌上天通都可以做上市。 第三点就是有“胸怀”。没有完美的个人,只有完美的团队。CEO必须是一个圆圈里的圆心,不能有自己的偏私,不能有所谓“自己人”,公平公正很重要。当然你心里要非常了解你的员工。 创业家出身的CEO,都比较有个人的个性,有点非常重要,就是要学会当一个(Listener)即能听取别人的意见的人,不能自大自狂。“听很多人的意见,和少数人商量,一个人做主。”中国有的大企业的领导人在海外做上亿的兼并大项目,往往就他和身边几个人一商量就拍板决定了,我是绝对并不会那么干的。特别是资本上的大的动作,我一定跟很多人商量,我问问题的时候会问一个中性的问题,不会让对方猜出来我是怎么想,我要听的是真话,而不是对方去猜度着你的思维,说他认为你想听的话。接下来我会跟公司的高层商量,到最后在脑子里形成一道选择题,答案还是要自己去打勾。不能优柔寡断,不怕犯错误。有的小公司之所以成功,就是因为它能快速地去尝试很多条道路,发现失败,又能快速地去修改。当它尝试了第五步,可能就发现海阔天空的机会,就成功了。 当然还有其它很重要的素质,一名CEO能够面对自己的错误,有与人沟通的能力,能打造一个互补型的团队等等。创业家都是比较自信的人,但也要充分知道自己弱点,能否清醒地认知自己,让团队成员发挥自己的专长。同时还有紧迫感等等,少花钱多办事。
若邻:有什么有趣的管理理论跟大家分享的? *杨镭:*我有一个“学士、硕士、博士理论”,这三种学位对应公司三种职位:经理、总监、VP。学士生是由老师出题,同时老师帮他分析和解决问题;硕士生是由老师出题,但由他去分析并解决问题;博士是给自己出题,自己分析解决。映射到公司里如如果你是副总级别,你就应该有能力去发现问题并且解决问题,不能把问答题丢给CEO,就算提问题也一定要是选择题。如是总监级的上级给了你任务,不给你解决方案你要有能力自己去解决。
若邻:您是一个超级沟通的高手? *杨镭:*哈哈,是的。虽然我并不是一个特别爱讲话的人,也特别不愿意在大众面前讲话。公司规模小的时候,我会亲力亲为去沟通,公司规模大了,不能每个都亲自去沟通,在重大会议和年会上会发言,但还不是‘麦霸’,更多目的是把沟通的平台搭建起来,步兵点将,用自己的精神去制造影响力。在清华读书的时候,我是团支书,经常组织活动,例如一年一度的中秋节,我们会在圆明园开篝火晚会,组织大家唱歌跳舞,我自己特别不擅长唱和跳,但站在后边看着大家尽兴,活动成功,我会感到很满足。
若邻:CEO找人才有两方面,一方面发现人才,一方面是把人才吸引过来,那伯乐是怎样炼成的呢? *杨镭:*这个跟经历有关,阅人无数后自然会一种慧眼。但是再好的人才,哪怕面试两个小时就做出完全正确的决策也是很难的。一方面是凭自己的直觉,另一方面我的感受是通过行业里朋友推荐的人才比猎头找来的要稳妥得多。朋友推荐的人首先就已经有一定的了解,口碑可信度高。第二点,当发现招错了人,特别是核心职位的人,也不要马上就放弃他,要尽快在第一时间帮他适应环境,解决问题,真诚坦率地跟他交流。但还不行的话也不要踌躇,立刻换人。
若邻:什么样的项目让您感到兴奋? *杨镭:*它在一个很大的市场里,或者说潜在的大市场,做了一件别人没做到的事,它富有创新,而且市场马上有这样的需求。“me too”(拷贝)的项目我就不喜欢,比方分众传媒做得好,模式被复制到车库、理发店、洗手间、高尔夫球场……这类的拷贝模式我没兴趣。可能会挣钱,但就不是我期待的伟大的公司。
若邻:曾经浓烈的“天使情结”,现在还有吗? *杨镭:*当然啦!泰山天使是我的情结,我的使命。我要感受创业,我用另外一种方式在完成我对创业的那种激情。天使投资就像收藏古玩的爱好一样,是我业余时间最喜欢从事的事情。我跟古董、瓷器投资商陶醉于收藏一样痴迷于天使创投。我爱好去看各种早期的、有潜质、有创意的小公司和项目,我能看到很多让我兴奋的事。
若邻:请问您对若邻网的看法? *杨镭:*我觉得很好,我用linkedin,很期待中国有linkedin这样的网站,人群定位很清楚,是非常有前途的。
如果你想认识*raymond*,请点这里,查看他的若邻档案。
前言
在目前的虚拟技术市场上,VMware是掌握了绝对的市场份额。但微软公司即将正式发布的Windows Server2008中也整合了Hyper-V虚拟技术,看来软件的巨头微软公司已经将其触手伸向了这个越来越热的虚拟技术市场,毫无疑问,Hyper-V借助低廉的价格以及Windows的迅速普及,将VMware的垄断地位会有一定的打击。
有意或无意,在Microsoft Windows Server2008发布时间很接近的时候,VMware也发布了新的VMWare Infrastructure 3.5,Infrastructure 3.5包涵了全套的服务器ESX虚拟平台和管理套件。无论如何,巨头之间的技术和市场的直接竞争,对用户来说,尤其是对信息化预算投入不多的中小企业,还是好处更多一些。
测试目的:
在单一基于VMWare ESX的虚拟服务器上进行ERP压力测试,不断加大并发用户数来体现系统性能极限,另外在保持高性能压力的状态下,通过长时间运行疲劳测试以考察虚拟系统的稳定性。
测试方法:
建立虚拟服务器作为测试的服务端,采用PS-ERP最常用的物流功能6模块作为测试脚本,在客户端利用Loadrunner虚拟用户并发并记录系统资源占用、响应时间、通过事务数等参数。
测试用数据库系统为MS SQL Server 2005,数据大小为5G。5G数据库大约是一个中等规模企业使用浪潮PS-ERP的数据大小。
测试环境:
| 硬件组成 | 客户机 | 星盈G129-Q,Intel Xeon 5335*2,4*146G SAS 15K转/ RAID5/ 16G内存 |
| 服务器 | VMWare虚拟服务器 | |
| 网络 | 1000M交换机 | |
| 软件组成 | OS:
VMWare Infrastructure 3.5 Microsoft Windows Server 2003 Enterprise Edition ON VMWare ESX |
|
| Microsoft SQL Server 2005 with SP2 | ||
| 浪潮通软ERP-PS9.1 | ||
| Loadrunner8.1 | ||
| 测试脚本 | 浪潮ERP物流6功能模块 | |
评测工程师评点:
上次我们在Windows Server 2008整合的Hyper-V虚拟服务器上进行了ERP压力测试,这次我们利用VMWare ESX虚拟服务器,继续在同一套硬件平台上进行了同样的测试项目,以此来对比两种不同的虚拟技术不同的性能表现。
VMWare的虚拟服务器目前占据了大部分的市场不是没有原因的,其技术也有着自己的独特之处。在测试中VMWare的虚拟服务器表现稳定,即使是运行大压力的重要业务的应用程序也没有出现宕机,这和很多人认为的虚拟机只能跑非核心应用的观念有很大的出入,虚拟服务器同样胜任物理服务器所能做的大部分任务。
一、测试简介:
建立虚拟服务器作为测试的服务端,采用浪潮ERP最常用的6种功能模块对象作为测试脚本,在客户端利用Loadrunner虚拟用户并发并记录系统资源占用、响应时间、通过事务数等参数。
性能测试方面,对虚拟服务器进行ERP压力测试,通过不断加大并发用户数来测试系统性能极限;稳定性方面,在保持高性能压力的状态下,进行12-20小时左右的长时间疲劳测试来考察虚拟虚拟系统的稳定性。
硬件方面的物理服务器是配置较高的星盈G129-Q企业级服务器,星盈G129-Q是高集成度的IU机架式服务器,使用两路Intel Xeon 5345 CPU,16G内存,存储系统为4块15,000转的SAS 146G硬盘组成的硬件RAID5。该服务器先前在Windows Server2008中的Hyper-V进行过同样测试项目。我们给ESX的虚拟服务器划分同样的系统资源(4CPU以及8G的物理内存),以此来对比基于同样硬件平台使用不同虚拟技术的虚拟服务器的差异(Hyper-V测试结果见《全球首发!Windows Server 2008虚拟机ERP压力测试 》)。
二、性能测试:
性能测试的项目中我们为VMWare ESX 选取了和Hyper-V同样的测试并发数,分别是50、100、200、240并发的响应时间来进行对比。
图 1
图1、2两套虚拟系统性能比较(点击放大)
上图左边是本次的VMWare的测试结果,右边是Windows Server 2008的Hyper-V测试结果。为了方便各位对两种虚拟技术有更直观的比较,我们将它们都放到一起。简单的对比,除了库存入库单记帐模块在VMWare平台上响应时间比较领先之外,其他的5个功能模块都不同程度的落后于Hyper-V的虚拟平台。
不同的功能模块在不同的虚拟服务器系统中应该有着不同的表现,但VMWare和Hyper-V其实都是属于同一种虚拟架构的虚拟技术,都是裸金属架构,即都是虚拟服务器上的系统直接驱动底层硬件,而我们测试的都是在同一套硬件之上,安装的操作系统以及所使用的系统资源都是一样的,理论上这两种虚拟机上的性能表现应该是一样的,原来我们曾经在同一个物理服务器上进行过同样压力的性能测试项目,前后的测试成绩相差都不会超过10%。对于虚拟服务器,我们原来猜想也是如此,但现实往往在想象之外。
虽然现在对具体的原因还很难分析清楚,不过根据虚拟技术的原理,可以做出一个基本判断:不论是Hyper-V还是VMWare,虚拟层的主要作用就是给客户操作系统(微软称为访客操作系统)提供模拟的单独硬件环境,另外更重要的作用就是调度核心资源例如CPU、内存以及IO。实际上在之前的Hyper-V,还有这次VMWare测试中我们都发现,分配给虚拟机的虚拟CPU和物理CPU没有映射关系(当然VMware提供这个选项),测试中不论我们分配给虚拟机1个还是4个CPU,虚拟机的性能上限都变化不大。这就意味着在CPU资源调度这个关键功能而言,虚拟层都将所有的物理CPU当成一个资源池,根据虚拟机实时的资源申请进行分配。在我们这个场景的测试中,因为只有一个虚拟机,因此基本上物理CPU资源池仅仅保留虚拟层进程必要的CPU时间片,其他资源都可以按需要分配给虚拟机。
很明显,虚拟层进程的时间占用和对资源申请的调度效率就很大程度决定了虚拟机的表现。虽然VMware描述的技术是虚拟机直接在物理CPU上运行,但是对CPU资源的调度就像操作系统对处理器的调度一样,仍然是虚拟层的核心任务,而Hyper-V与VMWare在调度效率上显然有所侧重,这也没什么奇怪的地方。
实际上,VMware已经证明能够很好的支持异构操作系统,例如同时支持微软和Linux,而目前Hyper-V对Linux的支持还需要完善。目前我们还没有办法测试在完全异构环境下的资源调度效率,从这个意义上说,Hyper-V在Windows平台的优胜还不是两种方案的全部。
这其实是由于Hyper-V和VMWare ESX Server两种虚拟技术所使用的底层编译语言是不一样的,在硬件层和虚拟服务器客户机系统之间的虚拟平台,它实现的是客户机操作系统对硬件的驱动,但各自使用的方式及编译语言是不一样的。这好比BENZ和BMW,虽然都是汽车,都表现出相似的运动方式。但说到核心技术,诸如发动机、底盘、驱动方式、制动方式都有着自己的标准,所以差别并不少。
在深入研究过测试的数据后我们大致的发现VMWare响应时间比较慢的原因。对于VMWare ESX Server上的虚拟系统资源,有3种会比较影响性能的参数,1是对虚拟系统的资源保留值,即每个系统保留的CPU个数、内存大小,磁盘大小等等。2、是各个系统在物理硬件资源池中所占的资源权重,比如说多个系统都对物理资源申请调用时,哪得系统会得到优先使用权的设置。3、是虚拟系统资源的限制值(Limit),这个数值是指虚拟系统不能占用超过物理资源的百份比例。这三个设置其实是互相影响的,在物理服务机上安装的虚拟系统不多的情况下,如果没有对虚拟系统设置限制值,那么保留值的设置并没有太大的意义,因为只要物理资源有空闲的时候,虚拟系统提出申请,那么这些系统资源,尤其是CPU的计算能力,都是被虚拟系统所调用。
图3 IOmeter测试结果
在压力测试之余,我还特意的对两种虚拟平台上磁盘文件系统的性能做了IOmeter的性能测试。从上图可以看出,Hyper-V下的虚拟磁盘性能曲线平稳一些,而VMWare ESX 的磁盘对压力的表现更直观。就性能而言,在队列深度的不断增加,虚拟磁盘的读写速度差别不是很大,两种磁盘的性能都很接近,但在压力增加的时候,VMWare ESX 的下降趋势比较明显,这多少解释了为什么VMWare ESX 的ERP高并发时响应时间变得更慢的原因。
| 读写速度(MBps) | 队列深度 | |
| 物理服务器磁盘 | 29.172204 | 64 |
| VMWare ESX Server | 9.73768 | 16 |
| Hyper-V | 9.502278 | 32 |
表1 IOmeter磁盘峰值速度
从上表可以看出,虚拟文件系统与物理文件系统的差别巨大,性能仅仅是物理系统的30%!这就是为什么重要的解决方案例如高可用和容灾一定要在单独的阵列上运行。原因之一就在于虚拟文件系统实际上需要虚拟层的翻译。例如Hyper-v其实是在Windows 2008文件系统上创建一个扩展名为VHD文件来模拟虚拟机文件系统,所有对虚拟文件系统的操作实际上是对这个Windows2008文件的操作来实现。VMware给虚拟机一个单独的分区,但是根据测试来看,其虚拟机仍然不是直接操作物理磁盘系统。这样虚拟文件系统相当于所有的操作都要通过虚拟层的翻译,效率自然高不到哪里去。
在我们进行的虚拟机Windows 2008和Windows 2003文件传送效率对比测试中,虚拟文件就造成更惊人的差别:Windows2008的文件传输效率居然是Windows2003的9倍!主要的原因也出在这个虚拟机文件系统上。
因此对实际生产的系统而言,不论采用Hyper-v还是VMware方案,我们都强烈建议将虚拟机安装在单独的SAN存储上,而不要和虚拟层共同安装在服务器直连存储上!
三、稳定性测试
对于VMWare ESX虚拟系统的稳定性,我们同样的进行了100并发中等压力下的12小时长时间的压力测试来验证VMWare ESX系统的稳定性能。同样的,测试项目顺利的完成,没有出现宕机死锁的现象。在测试中VMWare的虚拟服务器表现稳定,这和很多人认为的虚拟机只能跑象备份、邮件等非核心低压力应用的观念有很大的出入,虚拟服务器同样胜任物理服务器所能做的大部分任务。
图4 长时间的测试结果
因为测试项目运行的时间很长,同样的ERP业务动作会被重复的执行很多次,而由于数据的冗余,执行的事务的时间会越来越长,最小和最大的响应时间之间会出现很大的偏差,所以在稳定性测试中,平均响应时间有更多的参考价值。值得一提的是,在稳定性测试中,VMWare每个模块的平均响应时间又都领先于之前的Hyper-V的同样测试的结果(见图)。难道VMWare对数据冗余有更好的优化技术?这个问题我们会继续咨询相关的技术人员,随后给大家一个合理的答案。
四、资源使用率
在进行压力的测试的同时,我们会不断的记录虚拟系统的资源占用情况,这也是从去年在物理服务器上测试时遗留下来的习惯。系统资源的占用情况会直观的表现系统的压力程度,不过在虚拟平台上,这就和我们的使用习惯相去甚远了。
图5 VMWare不同并发压力下的资源使用率
正如上文提到的虚拟资源的3个很重要的参数。没有添加限制值的时候,CPU资源的会自动进行动态的调配。持续长时间占用的100%CPU计算时间在物理服务器上是很少见到的,而在虚拟机上,不同的压力下,CPU也一直维持为接近100%的水平,这个现象在之前的Hyper-V上的虚拟服务器上已经出现过了,所以在这样高系统占用的情况下,只要虚拟服务器的计算申请没有达到或者超过物理服务器的资源水平,仍然没有宕机也不算奇怪。
这样的设置其实是体现了虚拟技术的最大特点,就是以不同应用来划分系统资源,将闲置的系统资源分配给合适的应用,同时保证每一个应用都最大程度的利用系统资源的,使物理服务器的硬件价值得到最大化的体现。
四、结论
图6 VMWare Infrastructure架构
VMWare ESX是VMWare Infrastructure的主要组成部分,ESX运行在物理服务器上的一个虚拟层,它将要调配的处理器、内存、存储器和网络资源抽象到多台虚拟机中。这大大的改变了以往一台物理服务器负责一个或多个主要应用的旧有习惯,提高了系统资源的利用率的同时,也很大的节约了服务器的摆放空间和能耗。现在的数据中心机房服务器托管都是按U计算费用,同时国家也出台了关于高能计算的单位能源损耗标准,无疑,虚拟技术的出现和普及有其必然性。
从本次在虚拟平台上的测试,如果单以物理性能来的衡量,测试的成绩虽然没有给我们带来太多的惊喜,但我们至少在虚拟平台上进行了高压力的应用项目测试。单个虚拟服务器的测试成绩不算很出色,不过我们并只划分了部分的硬件资源,如果全部利用起来就可以构造多个的虚拟服务器以应付不同的应用,在象VMWare的企业级的虚拟服务器平台上,依靠单台的物理服务器,架构出一个中小型企业的全部应用平台也不是不可能的。在虚拟技术这个大舞台上,微软还是VMWare,我们看看谁能笑到最后吧?
之前有网友评点过微软Server2008的测试,说目前虚拟系统的最大用途是用于测试。诚然,虚拟系统中有很多诸如快照这样的可回溯的功能,对一些破坏性的测试有很大的帮助。但经过我们的自己的测试,这样来定义虚拟服务器,确实是有点大材小用。由于时间的关系,VMWare ESX的一些其他的应用象是高可用方案(HA),VMotion管理等功能的测试会陆续进行,测试结果也会分批次的与网友见面。
【相关文章】
| 【内容导航】 | ||||
|
项目管理速成手册
2010-5-10 蒋彪 于南京
1.前言
项目,如果不好好的管理的话,就会变得混乱下去。曾经的计划到处是破绽,成果物乱七八糟,项目成员心情都无比沮丧,到了不可收拾的地步。
一个陷入混乱的项目,最需要的就是出重手,快速摆平所有的问题。正所谓“乱使用重典”。当然,这不是那么件简单的事情。本篇文章,就是想说明,在项目的各个阶段,如何摆平项目秩序。
本文不光简单的描述一些项目管理的手法,并且还解说了许多项目管理的工具,和一些技巧性的提案。
2.项 目经 理石先生的困惑
项目经理石先生和我这样抱怨到:
| 部长问我项目什么时候做完?但是我心里也没有数。项目组所有的兄弟都在努力加班。
但是我去问他们什么时候能做完,他们都告诉我两三天之后。可是到了两三天之后,再去问他们,他们又说还要再两三天之后。 项目的周期越拖越长,客户越来越不满,下属也越来越不满,领导也越来越不满。 我真的不知道该怎么办了。 |
原来如此,石先生在项目管理上感到如此的困惑。有一种深深的被嘲弄的感觉。
要解决石先生的问题,我们首先应该考虑的是项目的进度管理。
3.进 度管理的目的
进度管理就如在地图上画出路线上一样。
你想从地图上的A点到达B点,有很多种路线可以走,那条路线是最近的,那条路线是最少困难的,凭空想象是不行的。你需要的是,在地图上标出自己要走的路线。而这个路线就是项目的进度计划。
实际的项目进度管理要包括以下两点:
1. 项目全体现在完成了多少?(达成率)
2. 如果这样进行下去,项目会延期吗,会提前完成吗?(完了预测)
4.进 度管理的两 大原则
4.1 进度管理的周期
进度管理是不可能一蹴而就的,任何一个进度管理,都需要按照以下周期,不断进度,不断改进,才能真实的反映项目的真实进度。
・ 根据项目成员的能力和项目的任务制定项目计划
・ 根据项目计划作业,报告作业结果,分析计划的可行性
・ 如果项目计划延迟了,则考虑改变项目计划的对策
比如,我们可以假设以下的项目进行的方法。
| 在每周一的早上,根据上周作业的实际情况,确定本周的进度预定。
在每周的周五17点,用email的方式通告本周的作业结果。 PM根据这些资料,在每周一的晨会上决定进步调整。 在有很大的作业延迟的那天,向部长以上级别汇报。 在月末将进度整理之后报告给客户。 |
以上,可以说就是一个典型的计划・报告・分析・对应的循环。
在以上的循环中,进度率的计算如下:
| Σ(作业的进度率×作业的预定工数)/ 计划的总工数 |
其中总工数的计算是有必要的,做成WBS(Work Breakdown Structure)的项目计划也是有必要的。
另一方面,完了预测的计算如下:
| 项目需要的天数 = 预测日期内完成的作业天数(实绩) / 预测日期内的作业天数 × 总天数 |
因为到目前为止,项目需要的天数已经清楚了,所以我们可以得到以下公式:
| 进度完了差异 = 项目需要的天数 — 预定总天数 |
如果计算出来的值是负的话就说明比预定提早做完了。如果是正的话,就说明比预定推迟完成了。
为了更形象的说明这个问题,请看以下这个图表:
当然,以上计算的前提是所有作业的内容都是一致的,单纯的,但是实际情况下,这样简单的平均值计算出来的数据不准确的可能性也是很高的。
按照以上这样的标准,反复进行,最后就能找到项目计划中的不准确的地方和找到解决之道,提高项目计划的准确性。
4.2 进度管理的基准
在进度管理的过程中,如果精度太低就没有意义了。比方说定义到天的精度明显比定义到星期的进度要好。
根据单纯的项目成员的报告数据来确定项目进度的精度是很复杂的。因为报告者个人的水平是不一致的,报告的时候也会出现故意多报或者少报的情况。
作为一种补充方法,可以采用完成度的报告方法来确定进度,比如:
・ 如果完成了代码编写,完成度就是50%
・ 如果完成了内部评审,完成度就是70%
・ 如果全部完成了,完成度就是100%
5.计 划! 计 划! 计 划!
很多年前,我和IBM合作的时候,经常听他们的PM说一句话,“计划!计划!计划!”
那么到底如何制定一个完美的计划呢,一般来说,我们可以用WBS来对项目结构进行分割,常见的分割方法如下:
5.1 依据项目产物分割
| 大项目 | 中项目 | 小项目 |
| 需求分析阶段 | 用例图 | 客户管理 |
| 商品管理 | ||
| 模块设计文档 | 客户管理 | |
| 商品管理 | ||
| 详细设计阶段 | 详细设计文档 | 客户管理 |
| 商品管理 |
5.2 依据模块分割
| 大项目 | 中项目 | 小项目 |
| 销售系统 | 客户管理 | 用例图 |
| 模块设计 | ||
| 详细设计文档 | ||
| 商品管理 | 用例图 | |
| 模块设计 | ||
| 详细设计文档 |
#具体的关于项目规模估算,可以参见以下文章
| 文章名:《手把手教你估算软件项目》
文章链接:http://blog.csdn.net/nanjingjiangbiao/archive/2010/03/04/5346859.aspx |
6.使用管理工具管理项 目
如果不是很复杂的项目,我们一般可以使用Excel就可以制定项目计划。但是如果很巨大的项目,中间的变更又很多,或者要多人同时操作,那么就需要专门的项目管理工具了。
下面给大家推荐一个免费的项目管理工具:
| 工具名:GanttProject |
该工具可以做一些简单的项目任务分配,进度率的自动计算和分析,但是负责的工作就不一定能完成了,必要的时候还是花钱的工具比较好。
7.总结
根据以上的说明,PM石先生终于了解到了自己应该如何管理一个项目。
但是是不是有了项目的计划,一个项目就能成功的完成呢?
当然不是,以下各种各样的问题,都会不断的困惑着项目经理
・ 项目成员的激励
・ 项目的配置管理
・ 项目质量的把握
・ 项目管理负荷的扩大化
・ 如何放权给下属
・ 如何摆平外界对项目组的干扰
~~~~~~~~~~~
一个项目经理,不是那么简单就能作好的。
-以上-
Web Service技术内幕
–Web Service的详细教程和协议分析
2010/2/25 蒋彪 于南京
1. Web Service的介绍
1.1 Web Service到底是什么?
研究一下当前的应用程序开发,你会发现一个绝对的倾向:人们开始偏爱基于浏览器的瘦客户应用程序。这当然不是因为瘦客户能够提供更好的用户界面,而是因为它能够避免花在桌面应用程序发布上的高成本。发布桌面应用程序成本很高,一半是因为应用程序安装和配置的问题,另一半是因为客户和服务器之间通信的问题。
传统的Windows富客户应用程序使用DCOM来与服务器进行通信和调用远程对象。配置好DCOM使其在一个大型的网络中正常工作将是一个极富挑战性的工作,同时也是许多IT工程师的噩梦。事实上,许多IT工程师宁愿忍受浏览器所带来的功能限制,也不愿在局域网上去运行一个DCOM。在我看来,结果就是一个发布容易,但开发难度大而且用户界面极其受限的应用程序。极端的说,就是你花了更多的资金和时间,却开发出从用户看来功能更弱的应用程序。不信你问问你的会计师对新的基于浏览器的会计软件有什么想法:绝大多数商用程序用户希望使用更加友好的Windows用户界面。
关于客户端与服务器的通信问题,一个完美的解决方法是使用HTTP协议来通信。这是因为任何运行Web浏览器的机器都在使用HTTP协议。同时,当前许多防火墙也配置为只允许HTTP连接。
许多商用程序还面临另一个问题,那就是与其他程序的互操作性。如果所有的应用程序都是使用COM或.NET语言写的,并且都运行在Windows平台上,那就天下太平了。然而,事实上大多数商业数据仍然在大型主机上以非关系文件(VSAM)的形式存放,并由COBOL语言编写的大型机程序访问。而且,目前还有很多商用程序继续在使用C++、Java、Visual Basic和其他各种各样的语言编写。现在,除了最简单的程序之外,所有的应用程序都需要与运行在其他异构平台上的应用程序集成并进行数据交换。这样的任务通常都是由特殊的方法,如文件传输和分析,消息队列,还有仅适用于某些情况的的API,如IBM的”高级程序到程序交流(APPC)”等来完成的。在以前,没有一个应用程序通信标准,是独立于平台、组建模型和编程语言的。只有通过Web Service,客户端和服务器才能够自由的用HTTP进行通信,不论两个程序的平台和编程语言是什么。
什么是Web Service
对这个问题,我们至少有两种答案。从表面上看,Web Service 就是一个应用程序,它向外界暴露出一个能够通过Web进行调用的API。这就是说,你能够用编程的方法通过Web来调用这个应用程序。我们把调用这个Web Service 的应用程序叫做客户。例如,你想创建一个Web Service ,它的作用是返回当前的天气情况。那么你可已建立一个ASP页面,它接受邮政编码作为查询字符串,然后返回一个由逗号隔开的字符串,包含了当前的气温和天气。要调用这个ASP页面,客户端需要发送下面的这个HTTP GET请求:
http://host.company.com/weather.asp?zipcode=20171
返回的数据就应该是这样:
这个ASP页面就应该可以算作是Web Service 了。因为它基于HTTP GET请求,暴露出了一个可以通过Web调用的API。当然,Web Service 还有更多的东西。
下面是对Web Service 更精确的解释: Web Services是建立可互操作的分布式应用程序的新平台。作为一个Windows程序员,你可能已经用COM或DCOM建立过基于组件的分布式应用程序。COM是一个非常好的组件技术,但是我们也很容易举出COM并不能满足要求的情况。
Web Service平台是一套标准,它定义了应用程序如何在Web上实现互操作性。你可以用任何你喜欢的语言,在任何你喜欢的平台上写Web Service ,只要我们可以通过Web Service标准对这些服务进行查询和访问。
新平台
Web Service平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互操作性,Web Service平台必须提供一套标准的类型系统,用于沟通不同平台、编程语言和组件模型中的不同类型系统。在传统的分布式系统中,基于界面(interface)的平台提供了一些方法来描述界面、方法和参数(译注:如COM和COBAR中的IDL语言)。同样的,Web Service平台也必须提供一种标准来描述Web Service,让客户可以得到足够的信息来调用这个Web Service。最后,我们还必须有一种方法来对这个Web Service进行远程调用。这种方法实际是一种远程过程调用协议(RPC)。为了达到互操作性,这种RPC协议还必须与平台和编程语言无关。下面几个小节就简要介绍了组成Web Service平台的这三个技术。
XML和XSD
可扩展的标记语言(XML)是Web Service平台中表示数据的基本格式。除了易于建立和易于分析外,XML主要的优点在于它既是平台无关的,又是厂商无关的。无关性是比技术优越性更重要的:软件厂商是不会选择一个由竞争对手所发明的技术的。
XML解决了数据表示的问题,但它没有定义一套标准的数据类型,更没有说怎么去扩展这套数据类型。例如,整形数到底代表什么?16位,32位,还是64位?这些细节对实现互操作性都是很重要的。W3C制定的XML Schema(XSD)就是专门解决这个问题的一套标准。它定义了一套标准的数据类型,并给出了一种语言来扩展这套数据类型。Web Service平台就是用XSD来作为其数据类型系统的。当你用某种语言(如VB.NET或C#)来构造一个Web Service时,为了符合Web Service标准,所有你使用的数据类型都必须被转换为XSD类型。你用的工具可能已经自动帮你完成了这个转换,但你很可能会根据你的需要修改一下转换过程。在第二章中,我们将深入XSD,学习怎样转换自定义的数据类型(例如类)到XSD的类型。
SOAP
Web Service建好以后,你或者其他人就会去调用它。简单对象访问协议(SOAP)提供了标准的RPC方法来调用Web Service。实际上,SOAP在这里有点用词不当:它意味着下面的Web Service是以对象的方式表示的,但事实并不一定如此:你完全可以把你的Web Service写成一系列的C函数,并仍然使用SOAP进行调用。SOAP规范定义了SOAP消息的格式,以及怎样通过HTTP协议来使用SOAP。SOAP也是基于XML和XSD的,XML是SOAP的数据编码方式。第三章我们会讨论SOAP,并结识SOAP消息的各种元素。
WSDL
你会怎样向别人介绍你的Web Service有什么功能,以及每个函数调用时的参数呢?你可能会自己写一套文档,你甚至可能会口头上告诉需要使用你的Web Service的人。这些非正式的方法至少都有一个严重的问题:当程序员坐到电脑前,想要使用你的Web Service的时候,他们的工具(如Visual Studio)无法给他们提供任何帮助,因为这些工具根本就不了解你的Web
service。解决方法是:用机器能阅读的方式提供一个正式的描述文档。Web Service描述语言(WSDL)就是这样一个基于XML的语言,用于描述Web Service及其函数、参数和返回值。因为是基于XML的,所以WSDL既是机器可阅读的,又是人可阅读的,这将是一个很大的好处。一些最新的开发工具既能根据你的Web Service生成WSDL文档,又能导入WSDL文档,生成调用相应Web Service的代码。
一句话总结:Web Service就是高级版的DCOM和CORBA
1.2 Web Service的体系结构图
通过上图,我们能看出来,WebService的运行机制有点类似于CORBA。
1.通过WSDL描述WebService
2.通过SOAP在互联网环境内传递数据
3.通过JAXB实现Java和XML之间的互相转换。
| 具体的Web Service的体系结构可以参照以下文件:
====================================================== 《深入浅出JAX-WS 2.0》 http://blog.csdn.net/nanjingjiangbiao/archive/2010/02/11/5306034.aspx 《SOA技术研究之 图解JAX-WS技术》 http://blog.csdn.net/nanjingjiangbiao/archive/2010/02/10/5305049.aspx 《手把手教你在Interstage上部署WebService》 http://blog.csdn.net/nanjingjiangbiao/archive/2010/02/22/5317356.aspx ====================================================== . |
1.3 一个简单的WebService运行实例
WebService代码:
| package stock.server;
@javax.jws.WebService public class StockQuoteProvider { public StockQuoteProvider () { } public float getLastTradePrice (String tickerSymbol) { return “abc”.equals(tickerSymbol)? 1234.0f : 0.0f; } } |
客户端代码:
| import java.lang.annotation.Annotation;
import stock.server.*; import javax.xml.ws.Service; public class StockQuoteClient { public static void main(String[] args) throws Exception { StockQuoteProviderService service = new StockQuoteProviderService(); StockQuoteProvider port = service.getStockQuoteProviderPort(); System.out.println(port.getLastTradePrice(args[0])); } } |
2. Web Service技术研究的环境准备
2.1 安装运行环境
推荐安装GlassFish服务器,具体安装方法可以参见以下文章:
| 《手把手教你 怎么 安装 GlassFish》
http://blog.csdn.net/nanjingjiangbiao/archive/2010/01/28/5264913.aspx |
2.2 下载WebService API(JAX-WS)的源代码
具体的下载URL参见以下地址:
| https://jax-ws-sources.dev.java.net/source/browse/jax-ws-sources/ |
2.3 部署服务器端
1.把1.3中的服务器端部署到GlassFish中
2.用wsimport命令生成stub中间程序
3.把1.3中的客户端代码和stub代码,以及2.2下载的WebService源代码部署到Eclipse工程中,就可以DEBUG了。
具体的可以参照以下文章:
| 《SOA技术研究之 图解JAX-WS技术》
http://blog.csdn.net/nanjingjiangbiao/archive/2010/02/10/5305049.aspx |
3. Web Service的技术内幕
3.1 客户端是如何和WSDL建立关系的?
1. 首先,我们看到客户端程序中有以下这样一行
| StockQuoteProviderService service = new
StockQuoteProviderService(); |
2. 这行代码,会调用到
| public StockQuoteProviderService() {
super(STOCKQUOTEPROVIDERSERVICE_WSDL_LOCATION, new QName(“http://server.stock/”, ”StockQuoteProviderService”)); } |
3. 这行代码,会调用到com.sun.xml.ws.spi.ProviderImpl的
| @Override
public ServiceDelegate createServiceDelegate( URL wsdlDocumentLocation, QName serviceName, Class serviceClass) { return new WSServiceDelegate(wsdlDocumentLocation, serviceName, serviceClass); } |
4. 这行代码,会调用到com.sun.xml.ws.clientWSServiceDelegate的
| /**
* @param serviceClass * Either {@link Service}.class or other generated service-derived classes. */ public WSServiceDelegate(@Nullable Source wsdl, @NotNull QName serviceName, @NotNull final Class<? extends Service> serviceClass) { ~省略~ } |
5. 而其中最关键的就是以下这段,解析阅读WSDL的代码,这段代码主要是用XMLStream来构建WSDL代码,不足为奇。
| WSDLServiceImpl service=null;
if (wsdl != null) { try { URL url = wsdl.getSystemId()==null ? null : new URL(wsdl.getSystemId()); WSDLModelImpl model = parseWSDL(url, wsdl); service = model.getService(this.serviceName); if (service == null) throw new WebServiceException( ClientMessages.INVALID_SERVICE_NAME(this.serviceName, buildNameList(model.getServices().keySet()))); // fill in statically known ports for (WSDLPortImpl port : service.getPorts()) ports.put(port.getName(), new PortInfo(this, port)); } catch (MalformedURLException e) { throw new WebServiceException(ClientMessages.INVALID_WSDL_URL(wsdl.getSystemId()), e); } } this.wsdlService = service; |
3.2 客户端是如何和SEI建立关系的?
1. 首先,我们看到客户端程序中有以下这样一行
| StockQuoteProvider port = service.getStockQuoteProviderPort(); |
2. 这行代码,会调用到com.sun.xml.ws.clientWSServiceDelegate的
| private <T> T getPort(WSEndpointReference wsepr, QName portName, Class<T> portInterface,
WebServiceFeature… features) { SEIPortInfo spi = addSEI(portName, portInterface, features); return createEndpointIFBaseProxy(wsepr,portName,portInterface,features, spi); } |
3. 这行代码,会调用到com.sun.xml.ws.clientWSServiceDelegate的
| /**
* Creates a new pipeline for the given port name. */ private Tube createPipeline(PortInfo portInfo, WSBinding binding) { //Check all required WSDL extensions are understood checkAllWSDLExtensionsUnderstood(portInfo,binding); SEIModel seiModel = null; if(portInfo instanceof SEIPortInfo) { seiModel = ((SEIPortInfo)portInfo).model; } BindingID bindingId = portInfo.bindingId; TubelineAssembler assembler = TubelineAssemblerFactory.create( Thread.currentThread().getContextClassLoader(), bindingId); if (assembler == null) throw new WebServiceException(“Unable to process bindingID=” + bindingId); // TODO: i18n return assembler.createClient( new ClientTubeAssemblerContext( portInfo.targetEndpoint, portInfo.portModel, this, binding, container,((BindingImpl)binding).createCodec(),seiModel)); } |
在这段代码中,使用了TUBE技术,把客户端和服务器之间建立了关系。
4. 这行代码,会调用到com.sun.xml.ws.util.pipe.StandaloneTubeAssembler的
| @NotNull
public Tube createClient(ClientTubeAssemblerContext context) { Tube head = context.createTransportTube(); head = context.createSecurityTube(head); if (dump) { // for debugging inject a dump pipe. this is left in the production code, // as it would be very handy for a trouble-shooting at the production site. head = context.createDumpTube(“client”, System.out, head); } head = context.createWsaTube(head); head = context.createClientMUTube(head); head = context.createValidationTube(head); return context.createHandlerTube(head); } |
在以上代码中,开始和SOAP绑定,准备发送请求和调用函数等等。
3.3 客户端是如何发送请求的?
1. 首先,我们看到客户端程序中有以下这样一行
| port.getLastTradePrice(args[0]) |
2. 这行代码,会调用到com.sun.xml.ws.client.sei.SEIStub的
| public Object invoke(Object proxy, Method method, Object[] args)throws Throwable {
MethodHandler handler = methodHandlers.get(method); if (handler != null) { return handler.invoke(proxy, args); } else { // we handle the other method invocations by ourselves try { return method.invoke(this, args); } catch (IllegalAccessException e) { // impossible throw new AssertionError(e); } catch (IllegalArgumentException e) { throw new AssertionError(e); } catch (InvocationTargetException e) { throw e.getCause(); } } } |
3. 这行代码,会调用到com.sun.xml.ws.client.stub的(中间省去了2层不重要的代码)
| /**
* Passes a message to a pipe for processing. * <p> * Unlike {@link Tube} instances, * this method is thread-safe and can be invoked from * multiple threads concurrently. * * @param packet The message to be sent to the server * @param requestContext The {@link RequestContext} when this invocation is originally scheduled. * This must be the same object as {@link #requestContext} for synchronous * invocations, but for asynchronous invocations, it needs to be a snapshot * captured at the point of invocation, to correctly satisfy the spec requirement. * @param receiver Receives the {@link ResponseContext}. Since the spec requires * that the asynchronous invocations must not update response context, * depending on the mode of invocationthey have to go to different places. * So we take a setter that abstracts that away. */ protected final Packet process(Packet packet, RequestContext requestContext, ResponseContextReceiver receiver) { configureRequestPacket(packet, requestContext); Pool<Tube> pool = tubes; if (pool == null) throw new WebServiceException(“close method has already been invoked”); // TODO: i18n Fiber fiber = engine.createFiber(); // then send it away! Tube tube = pool.take(); try { return fiber.runSync(tube, packet); } finally { // this allows us to capture the packet even when the call failed with an exception. // when the call fails with an exception it’s no longer a ‘reply’ but it may provide some information // about what went wrong. // note that Packet can still be updated after // ResponseContext is created. Packet reply = (fiber.getPacket() == null) ? packet : fiber.getPacket(); receiver.setResponseContext(new ResponseContext(reply)); pool.recycle(tube); } } |
4. 这行代码,会调用到com.sun.xml.ws.api.pipe. __doRun的(中间省去了3层不重要的代码)
这段代码开始发送打成数据包的http请求
| /**
* To be invoked from {@link #doRun(Tube)}. * * @see #doRun(Tube) */ private Tube __doRun(Tube next) { final Fiber old = CURRENT_FIBER.get(); CURRENT_FIBER.set(this); // if true, lots of debug messages to show what’s being executed final boolean traceEnabled = LOGGER.isLoggable(Level.FINER); try { while(!isBlocking() && !needsToReenter) { try { NextAction na; Tube last; if(throwable!=null) { if(contsSize==0) { // nothing else to execute. we are done. return null; } last = popCont(); if(traceEnabled) LOGGER.finer(getName()+’ ‘+last+”.processException(“+throwable+’)'); na = last.processException(throwable); } else { if(next!=null) { if(traceEnabled) LOGGER.finer(getName()+’ ‘+next+”.processRequest(“+packet+’)'); na = next.processRequest(packet); last = next; } else { if(contsSize==0) { // nothing else to execute. we are done. return null; } last = popCont(); if(traceEnabled) LOGGER.finer(getName()+’ ‘+last+”.processResponse(“+packet+’)'); na = last.processResponse(packet); } } ~省略~ |
5. 这行代码,会调用到com.sun.xml.ws.encoding. StreamSOAPCodec的(中间省去了无数层不重要的代码)的
| public ContentType encode(Packet packet, OutputStream out) {
if (packet.getMessage() != null) { XMLStreamWriter writer = XMLStreamWriterFactory.create(out); try { packet.getMessage().writeTo(writer); writer.flush(); } catch (XMLStreamException e) { throw new WebServiceException(e); } XMLStreamWriterFactory.recycle(writer); } return getContentType(packet.soapAction); } |
大家可以看到,他发出请求了。
3.4 服务器端是如何接受请求的?
1. 首先,服务器端有一个名叫JAXWSServlet的Servlet常驻服务器,监听请求。所以,请求会首先被转发给com.sun.enterprise.webservice.JAXWSServlet的
| protected void doPost(HttpServletRequest request,
HttpServletResponse response) throws ServletException ,IOException{ /** * This requirement came from the jbi team. If the WebServiceEndpoint * is a jbi endpoint which is private throw an error whenever a get * or a post request is made */ Endpoint endpt = wsEngine_.getEndpoint(request.getServletPath()); ~省略~ |
2.最后,代码会调转到以下com.sun.xml.ws.transport.http.HttpAdapter的
| final class HttpToolkit extends Adapter.Toolkit {
public void handle(WSHTTPConnection con) throws IOException { boolean invoke = false; try { Packet packet = new Packet(); try { packet = decodePacket(con, codec); invoke = true; } catch(ExceptionHasMessage e) { LOGGER.log(Level.SEVERE, ”JAXWS2015: An ExceptionHasMessage occurred. “ + e.getMessage(), e); packet.setMessage(e.getFaultMessage()); } catch(UnsupportedMediaException e) { LOGGER.log(Level.SEVERE, ”JAXWS2016: An UnsupportedMediaException occurred. “ + e.getMessage(), e); con.setStatus(WSHTTPConnection.UNSUPPORTED_MEDIA); } catch(Exception e) { LOGGER.log(Level.SEVERE, ”JAXWS2017: A ServerRtException occurred. “ + e.getMessage(), e); con.setStatus(HttpURLConnection.HTTP_INTERNAL_ERROR); } if (invoke) { try { packet = head.process(packet, con.getWebServiceContextDelegate(), packet.transportBackChannel); } catch(Exception e) { LOGGER.log(Level.SEVERE, ”JAXWS2018: An Exception occurred. “ + e.getMessage(), e); if (!con.isClosed()) { writeInternalServerError(con); } return; } } encodePacket(packet, con, codec); } finally { if (!con.isClosed()) { con.close(); } } } } |
以上代码分为三块大的处理,分别是
packet = decodePacket(con, codec);
packet = head.process(packet, con.getWebServiceContextDelegate(),
packet.transportBackChannel);
encodePacket(packet, con, codec);
用来解析数据包,调用服务,发送回复数据包。这里就不详细介绍了。
4. 总结
希望能够通过这样的文章,更清晰的,直白的把WebService的详细技术内幕公布给大家,为开源软件运动作一份自己的贡献。
##以上##
手把手教你估算软件项目成本
2010-3-4 蒋彪 于南京
[背景]
软件项目一般来说可以分成两种:
A. 客户定制系统
B. 研发产品化系统
目前,国内绝大多数的都是在做A类型的客户定制系统,从接客户的单,到做客户的需求,拿到客户的合同,做开发,做实施,做后期维护之类的工作。
另外一种B类的,做产品研发的工作,国内涉及的人不多,而且它的项目估算里面涉及的问题很多,这里就不展开谈了。
做一个正常的软件项目,作为经营者和管理者,都想清楚地知道,这个软件项目有多大,要花掉多少成本,我能拿到的利润有多少,所以能不能准确地估算出软件项目的规模就显得很重要的。
下面我们来剖析一个小小的软件项目的规模估算。
[项目的需求文档]
假设现在,我们接到了一个项目,项目的名称是×××会员综合管理平台,决定采取传统的B/S架构来设计,我们首先要干的事情就是具体的分析这个项目的需求文档,只有在熟悉需求的情况下才能知道整体的规模。
| 具体的需求文档参见: |
[项目规模的概算]
我们大家都知道,正常的软件开发模式,比如瀑布开发模式的话,会分成
A. 需求分析
B. 基本设计
C. 详细设计
D. Codeing
E. UT
F. CT
G. RT
H. 后期维护
这么多阶段和步骤。但是根据,我所了解到的,国内除了少部分对日的大型公司会严格按照这种流程来做事情之外,绝大多数的国内公司还是随着自己的性子来。其中不乏,东软,联创之类的著名企业。所以我在制定项目概算的时候,还是按照国内的开发步骤来做:
| 大项目 | 中项目 | 小项目 | 人日 | ||
| 系统设计 | 数据库设计(大概10张表左右) | —— | 6 | ||
| 系统结构设计 | —— | 6 | |||
| 画面demo | —— | 10 | |||
| 系统开发框架搭建 | —— | 3 | |||
| 开发作业 | 会员管理子模块 | 会员开卡画面 | 1.5 | ||
| 会员开卡确认画面 | 0.5 | ||||
| 会员信息检索画面 | 1 | ||||
| 会员信息修改画面 | 1 | ||||
| 会员休息修改确认画面 | 0.5 | ||||
| 批量生成卡号 | 1 | ||||
| 会员积分输入和修改 | 2 | ||||
| 会员卡延期画面 | 2 | ||||
| 会员卡挂失画面 | 2 | ||||
| 商品管理子模块 | 商品录入画面 | 1 | |||
| 商品录入确认画面 | 0.5 | ||||
| 商品检索画面 | 1 | ||||
| 商品信息维护画面 | 1 | ||||
| 库存管理 | 库存检索画面 | 1 | |||
| 库存新建画面 | 1 | ||||
| 库存修改画面 | 1 | ||||
| 库存信息确认画面 | 0.5 | ||||
| ~省略~ | |||||
| 测试作业 | 测试数据和计划的准备 | —— | 3 | ||
| 分模块测试 | 分画面测试 | ~省略~ | |||
| 后期维护 | 系统上线安装 | 硬件安装,布线 | 1 | ||
| 环境安装,项目部署 | 1 | ||||
| 简单的客户培训 | 3 | ||||
| 维护 | 日常数据的维护 | 4 | |||
| BUG的修正 | 5 | ||||
| 总计 | 大约7人月以上 | ||||
[结论]
软件公司在算钱的时候有几种方法:
A. 国内的比如联创之类,用项目分段方法收钱,做到哪一个阶段,或者完成了一个模板的上线就算前
B. 外包公司一般采用一个人月多少钱来收钱,比如对日外包一般是1万~2万一个人月。
对于老板而言,他要计算出项目的成本,也要这样算,比如以下:
| (总人月:7人月) | 项目成本 | 对客户收费 |
| 总价 | 7万(市价:1万/人月) | >=8万 |
# 为什么项目成本里面,一个人月会有1万呢
因为如果我们假设项目的成员构成如下:
| 职位 | 月工资 |
| PM | 60,00 |
| SE | 45,00 |
| PG(5人) | 25,00×6 |
| 公司日常运营费用(包括文职人员,会计,场地租金,旅游福利,公司上层的工资,电脑设备,和客户打交道的关系费—–) | 500,00 |
于是我们就能得到:
| 月开销合计 | 75,500 |
| 平均一个人月 | 10,786 |
# 为什么项目最后的售价一定会大于8万呢
在今天的IT市场上,一般来说作客户定制系统的公司,利润率只有10%~20%,厉害一点的比如联创,日恒一般也就15%。
特别是现在每年5%的通货膨胀率,如果一个企业不拿到10%以上的利润,那这个公司一定会完蛋。
所以,7万×(最起码的利润率)10%>=8万。
证明完毕
—–以上——
以下软件管理相关文章,欢迎大家访问
========================================================
《对日外包项目 管理十日谈》
http://blog.csdn.net/nanjingjiangbiao/archive/2010/01/31/5274307.aspx
http://blog.csdn.net/nanjingjiangbiao/archive/2010/03/10/5364523.aspx
========================================================
【附件—系统的需求文档】
系统需求:
| 模块名 | 处理机能 | 机能详细 |
| 会员管理子模块 | 会员卡类型管理:分为储值型返现型、计次型、普通型。 | 储值型返现型属于预付费型会员卡,例如充100实到帐120。
计次型属于预付费型会员卡,例如500块/20次。 普通型分为两种:一种属于预付费型会员卡,在开卡之际需要充入一定的现金;还有一种仅是用于代表用户拥有某个商户的会员身份,仅用于积分或打折使用。 每种卡类型都有相对应的积分与消费折扣率。 |
| 会员卡管理:包括会员开卡、会员信息维护、批量生成卡号等功能。 | 会员开卡:会员首次办理会员卡时需录入会员的信息并生成相应的卡信息与会员信息对应。
会员信息维护:会员信息的查询,会员卡、会员身份信息的修改。 批量生成卡号:可以事先生成一批卡号,当用户需办理卡时,直接录入即可。无论是单独生成还是批量生成卡号,都需屏蔽不吉利的号码。 |
|
| 充值管理:有储值的会员卡在金额消费完毕后,需进行续费,若未续费,则会员卡暂不可用。 | 储值型返现型、计次型为开卡前一次性充值。使用完毕即结束,再次充值时,所充金额按卡类型的限止进行充值。
普通消费型:可充入金额不等,具体金额由商家自行确定。 |
|
| 会员积分 | 会员积分是一个可以灵活配置的功能。例如开卡送多少积分,不同类型的会员卡在消费时增加多少积分,在兑换礼品时减少多少积分等等。 | |
| 会员卡延期 | 无论是哪种类型的会员卡,在建卡之初都会设置相应的结束时间,在结束时间到来时,若尚有余额未使用,用户可以申请延期,延期具体时间由商家自行决定。 | |
| 会员卡挂失:用户在无意中丢失卡片后可以向办理卡片时的商户申请挂失。 | 挂失:用户凭办理时输入的密码与证件进行挂失。
取挂:用户若找到了丢失的卡片,可以取消挂失。 补卡:用户在挂失一段时间后,可以申请补卡。补卡时用户的会员卡号有可能会变,但会员卡编号是唯一的,不可变的。 |
|
| 商品管理子模块 | 商品类别管理:商家为自己的商品创建相应的类别。商品的类别分为真实商品与虚拟商品两种。 | 真实商品是现实中存在的商品,例如:香烟、酒、饮料等。
虚拟商品为空间或时间上的概念。 |
| 真实商品管理: | 商品信息录入:各商家自行录入商品信息。
商品信息维护:包括商品信息的查询、修改、删除等功能。 |
|
| 虚拟商品管理: | 商品管理:例如某个球场。3小时/100元。某种服务,100元/1次。 | |
| 库存管理 | 库房管理 | 创建、维护、查询、删除本商家的库房信息。 |
| 供应商管理 | 创建、维护供应商信息。供应商名称,电话,具体联系人,销售产品等。 | |
| 入库管理 | 新进商品的入库操作。商品的名称,数量,对应的供应商,存储的库房,保持期,最低库存告警点等。 | |
| 出库管理 | 商品销售过程中,系统会对商品的数量进行自动的减少。 | |
| 库存告警 | 当某种商品库存量低于设定的水平时,给予明确的告警。 | |
| 消费管理子模块 | 预订管理 | 用户以电话的形式联系商家,并预订下到达的时间和所消费的服务。商家通过系统创建预订单,预订单中包含用户的联系信息或会员卡号、计划消费的服务、使用的场地等信息。 |
| 消费单生成 | 用户来到商家消费后,若是事先有预定则此时转化为相应的消费单,若是当场消费,则现场生成消费单。消费单中保存了用户在商户的一切消费行为,当最终进行费用结算时,若用户是会员则可将消费单与会员卡对接。 | |
| 添加真实商品 | 为已正式生成的消费单添加商品,包括商品的数量,单价,消费时间等。 | |
| 增加虚拟商品 | 为已正式生成的消费单添加虚拟的商品,虚拟的商品不同于真实商品,未必以数量为单位,可能是以时间或次数为单位。系统会详细记录会员消费的起始时间或次数,到会员结帐时自动根据记录计算出结果。 | |
| 费用结算管理 | 系统会根据各商户所生成的消费单上的内容进行结算。这包括真实商品的数量与单价的乘积,虚拟商品所用时间或次数的计算结果,或者是二者之和。在计算出结果后,若用户持有会员卡,系统会根据会员卡的类型、商品的类型等进行打折、积分。 | |
| 联合结帐 | 在上面结帐管理的基础上,可以将不同的消费单关联,并设置其中一张消费单为主结算单进行费用结算。 | |
| 商家自助管理子模块 | 商家信息管理 | 对商家自身信息的管理、维护。商家充值功能。 |
| 员工管理 | 新建、维护员工。包括员工登陆系统的帐号,初始密码,有效期等。 | |
| 员工销售情况统计 | 查看每个店内员工的商品或服务销售情况,可以借此衡量员工的业绩。 | |
| 员工操作日志 | 查看每个店内员工的操作行为记录。 | |
| 交班管理 | 员工与员工之间交班时的一种操作,主要是对上一班员工的各类数据的一个总结,新一班员工数据的重新开始录入。 | |
| 提醒管理 | 分为两种提醒,一种是程序控制的提醒,在某些点上加入,到达限定条件即提醒(待议);一种是可配置的提醒,如,某年某月某日要做些什么。 | |
| 短信群发申请 | 商家编辑短信的内容提交至管理员处统一发送。 | |
| 邮件群发管理 | 可以从数据库中随机掏出指定人数用户向其发送邮件。 | |
| 公告管理 | 针对店内员工的公告信息 | |
| 计量单位管理 | 每个商家可以添加属于自己的计量单位,例如:个,次。这种仅限于页面展示,与价格换算无关联。 | |
| 密码修改 | 对登陆系统密码的修改 | |
| 统计报表 | 待定 | |
| 系统管理 | 角色权限管理 | 平台中有众多商家,他们所包含的员工都有相应的角色,不同的角色所看见的功能不一样,角色由管理员统一创建。 |
| 商家管理 | 所有商家皆由此添加,在有效期到来之前,商家均可正常登陆系统进行操作。 | |
| 地市信息管理 | 系统初始数据,一般不做变更,主要包含江苏省13个地市的信息。 | |
| 提醒管理 | 分为两种提醒,一种是程序控制的提醒,在某些点上加入,到达限定条件即提醒(待议);一种是可配置的提醒,如,某年某月某日要做些什么。 | |
| 短信群发管理 | 可以从数据库中随机取出指定人数用户向其发送短信。审批后,因按短信的条数扣除从商家的帐户上扣除一定的金额,若金额不够则不能审批。 | |
| 邮件群发管理 | 可以从数据库中随机掏出指定人数用户向其发送邮件 | |
| 公告管理 | 向所有的商家发布公告信息 | |
| 密码修改 | 对登陆系统密码的修改 | |
| 统计报表 | 待定 |




