W3C负责XML、SOAP及WSDL；OASIS负责UDDI。
Web服务有三种手段：远程过程调用（RPC），面向服务架构（SOA）以及表述性状态转移（REST）。
说的不好听一点：搞技术的人员很多的都是处于IT食物链的底层。
每每说到这里，我就想起之前很多搞技术朋友在转型之前对我说的：哥们，搞技术就是死路一条，并且死路的很快！又想起之前和我认识的搞销售的朋友对我说的：我们公司的IT部门的搞技术的人很贱，给他们一点钱，他们就可以在哪里拼死拼活，而且加班，训斥他们，他们不敢反抗！
“身体是革命的本钱”，这句话真不是瞎说的。如果你自己不把自己看重，没有人看重你；如果你自己不把自己看人，别人更加不把你当人；如果你自己都不珍惜自己，死神就开始向你招手了！
有人说：把技术搞的非常非常牛X，那就工资高了！说的不好听一点：有几个公司要技术很牛X的？技术牛X不等于高工资！技术再牛X，人都没了，有什么用？钱这个东西，真的急不来！
活在当下，钱固然重要，但是想想曾经自己没有钱的日子，过的也很开心。那时候，穷的真没有钱吃饭，每天就和老婆吃挂面，每天的开销一共5元不到，如果有点青菜吃，那就是高兴的不得了的事情，如果有肉吃，那就是天降横财了…
活在当前，不要认为身边的一切都是无所谓，真正的到了那一天，什么都迟了。有个朋友说的好：我们真的不敢保证，白天出门上班，晚上就可以一定平安回来！
一件事情的成败大致可以用四个维度去考量：
排除第二点能力之外，其余三点可以大致概括为：勇为天下先的意识（创新）和创新得以生长的泥土（意愿和环境）。这几者彼此影响，不可分割。
一提创新，很多人可能会想到其瓶颈是没有想法，进而认为差距的主要原因是意识问题。但这很可能是错的，就我自身的观感，程序员这个群体里，现实的情形应该是想法很多，但受种种制约，实践下来的不多。
一般对于一个职业的Coder来说主要薪水主要有三个部分。月薪水，项目奖金和一些年终奖福利这里。部分高端的职位有年底分红和奖金。当然还有一些有单子赚外快。这个范围大概在月薪2K-32K之内。当然据说在这个之上的也有不过我没见过。对于只是工作得来的薪资来说这个算是中上。有人不信，我有个亲戚在中央工作的一些公务员也就这个水平。技术人员一般薪资稳定，所以就缺少一些激情文化。在这个CPI，房价一路狂奔的年代，这点也能买房子，不过还清差不多要脱一层皮，再加上户口社保以及养老医疗等诸多的问题，大家都很浮躁。
其实觉得浮躁也没什么，主要就是浮躁的心态有了大量不成型的开发，同时就是很多人为了接单就导致了几百块钱做一个站。还有大量的半成品单。
在两年前自己是一个技术类的开发主管。团队很小，下面有很多人在上班的时候都做单，那时候我也一直都让他们去自己接做外单。作为一个年轻的开发人员没有足够的项目开发的时候就去接单吧。接了许许多多项目和单之后你的开发思维基础代码能力都会越来越成熟。并且也会有足够的现金来让你有着开发的动力，这样绝对是个好事情。而超过了二十六岁就要避免这样的行为。需要更多的是专注。专注到一点，专注到行业的解决方案以及整体代码和更细致并且卓有成效的产品解决方案。
然后就是投资了。没太多的现金的时候要学会代码的投资。玩玩股票，慢慢的培育一件自己的核心产品，开个网店做点国外的外包，交点朋友，找老婆，打游戏，做产品，社交，旅游都行。做点自己喜欢做的有前途的事情。别老是闷着。没意思。闷成了呆鸟又没钱就更找不到女友了。
年轻的人就干年轻的事情，干点有前途的事情，等老了就去耐心的工作。别把工作当成生活的全部，说实在的赚钱也不差那点。上班准时到下班就闪，有个良好的工作状态早晚都会赚到钱的。你现在用一年加班的钱或许在你四十岁的时候一个月就赚到了。前者你浪费了一年，后者节省了十一个月。学能点，虽然这种能有时候知道自己是阿Q。不过还要Q点。活着就那点意义。一切开心就好。
我们的大脑透过五官接收到外在的事件，然后，我们的大脑会自动的对这些所接收的数据（事件）进行处理。在这个处理的过程中会自动的进行删减、扭曲和一般化。
比如有一个女孩子谈了三次恋爱，三次都被男孩子甩了。于是，她得出了一个结论：天下的男人没有一个是好东西。那么，这里就是在一般化了。也就是把具体的事情放大至含盖所有事情。
一些父母在孩子考试几次不及格后，就认为自己的孩子是不适合于学习某学科或者是笨的、或者说是不如别的孩子的感觉。这都是在一般化。我们的信念就是一般化的最好的例子。
一般化的好处是令到我们提高我们的学习效率。
比如我第一次吃桔子知道要剥了皮才能吃，以后看到和桔子差不多样子的水果就知道要剥了皮才能吃。这样，我就不用每次都要去学习这个东东是需要剥皮吃还是直接吃。但另一方面，因为我们把具体的事情过度的概括化了，有时就会期望将来的情况也会像原来的总结那样。比如：守株待免。同时我们在某一件事时，总结出了正确的一般化判断，却忽略了凡事总有例外，因此减少了可能性。比如南方的金桔就是不用剥了皮就可以吃的。
上面说了人与人的能力差不了多少，那么为什么同样没有基础的两个人学习新的知识会有学的好与学的不好之分呢？这里我想说的是----总结！
宏观上说，总结就是把整个知识的体系变成自己的。举个例子：别人的代码很难看懂，但是自己的代码就很容易看懂。原因很简单，自己写出来的东西自己当然熟悉，实现过程以及函数的调用自己再熟悉不过了。但是如果是别人写的就要好好费费心思看上一看了。学知识也是如此，把别人的知识架构弄清楚，或者把别人的知识放到自己的知识架构中，于是自己对这方面的知识就会很熟悉，这就是我们所说的学知识“学会了”。
微观上说，总结就是我们通常说的“说白了……”以及“换句话说……”后面省略号所指的内容。相信大家都有这么一个感触：当你学高数或者数学分析的时候，如果去扣定理那么必定头大。但是如果是别人把定理用大白话给你讲一遍你便会觉得豁然开朗。微观上（比如某个定理，某个技术）的总结就是把那些看起来晦涩难懂的描述语言，转变成自己的话，让自己更好的理解与运用。
总结，一言以蔽之：把别人的知识另存为自己的就叫总结。
要在工作上奋发图强，身体健康固然重要，但是真正能改变你的状态的关键是心理而不是生理上的问题。真正地投入到你的工作中，你需要的是一种态度、一种渴望、一种意志。
在工作和生活中每天都有干不完的事，唯一能够做的就是分清轻重缓急。要理解急事不等于重要的事情。每天除了办又急又重要的事情外，一定要注意不要成为急事的奴隶。
天才就其本质而论只不过是对事业、对工作过程的热爱而已。
怎么解释上面这句话呢？用实例，比如一个建筑工程师和一个软件工程师：
这个特点，让从业者的知识积累变得用处不太大。
第二个特点，可以这么理解：
以前看过一个传奇程序员的故事：
他做软件开发已经几十年，积累的代码/类库都整理好放在一个随身带的硬盘里，要开发什么软件或项目的时候，就直接从硬盘里快出调出程序类库进行组装。据说一个几十人的团队需要个把月才能完成的项目，他一个人一天就能组装出来。他调侃说，要是哪天硬盘丢了，他可能就要改行了。
所以，不考虑转行的情况下，技术复杂度，其实是软件工程师最好的朋友，掌握那些有一定门槛的，变化不太剧烈的技术，或者有前瞻性的技术，是打持久战的不二法门。
当然，复杂度阻挡了一大批从业者进入，形成门槛，如果顶不住复杂度，怎么办？还有另一个方向，就是接地气。避开技术的激烈变化这一劣势，上传统业务这一稳定的贼船，其实就是使用技术，比如在某个行业里深挖，象业务人员一样熟悉这行业的业务，那技术只是使用。另一个就是做技术的最前端，变化最激烈的这一部分。
这怎么说？因为最前端，比如用户端，变化最激烈，所以总有活干，用户界面，界面设计，产品设计，软件测试，这些最前端的东西，变化相当迅速，但对技术的要求不高，用户最看得见效果，所以总有钱赚。
由此可见，软件工程师的技术道路，应该走两极，要么走门槛极高，变化不大的底层级，要么走和用户业务最接近，变化最大的最前端级，其职业道路都比较长远。
简而言之，要么像那个传奇程序员一样学会积累自己的代码与类库，或着走向底层研发/用户界面这两端。中间级高不成低不就的研发，是最缺乏可持续发展的模式，也是那个层次的人，总是在嚷嚷“三十多岁挨踢”之类的话。
2.告知领导职责
进一步拉近员工的同时，让员工明白，出现问题，需要帮助的时候，可以找到领导，而不是自己一个人承担，或者隐瞒，等待问题自己过去。领导就是处理这些事情的，那么出现事情的时候，自然可以找到领导。
3.告诉容错底线
告知员工，自己容错的底线不是你犯了错误，而是犯了错误无所谓的态度。另外告诉员工，自己对待问题的态度是和员工站在一起，解决问题，分析问题，总结问题。而不是追究责任，进行惩罚。
6.员工角度考虑问题
问：我感觉自己和同事交流时，总表达不清自己的观点，我怎样提升自己的口才？
答：这个和口才没多大关系，深刻理解了问题的本质，表达自然会流畅。
问：我最近看什么都没耐心，看东西也总是似懂非懂，是不是我太浮躁了？
答：人的心态，都会经历一个过程：宁静、浮躁再到宁静静，你现在处于浮躁期很正常。你上学时，一学期啥都不做，只学10本书，自然心很静。现在，要看的东西很多，你驾驭不了，自然会无所适从。坚持几年，各知识点都梳理差不多，学习方法也成熟了，你自然会静下来。
问：我现在学什么都容易忘记，很有挫败感，究竟怎么了？
答：打个比方，你将200颗五颜六色的玻璃珠丢到桶里，你要随便找出某一颗，是不是很难？如果按颜色穿成20串呢？如果再用一根横线，将20串再串起来呢？是不是再找起来很容易。
学习有个过程，从点到线到网，你现在处于点的积累阶段。积累一定程度，要串起来就很快，那时，你会有顿悟和触类旁通的感觉。耐心等待吧。
问：我想成为技术大牛，但我感觉业务很重要，以后还想搞管理，我该怎么做？
问：我现在做外包项目，没啥技术含量，学不到东西，咋办？
问：IT技术变化太快，半年不学习就更不上时代了，好累啊。
答：当你学习EJB/RMI、CORBA、DCOM、SOAP/REST、DWR/JsonRPC时，你有没有发现，它们都根源于古老的RPC，对WindowsRPC漏洞不陌生吧？把RPC原理彻底搞懂，这些技术就学起来很快。
问：我看很多框架动辄上10万行代码，我看一点，实在看不懂就放弃了，你当时是怎么看的？
答：不要先钻进代码堆，而是了解设计。比如，struts核心是Command模式，JBPM思想是GraphOrientedProgramming，两个框架的内核都不到2000行，几个核心类搞懂了，其它类都是顺藤摸瓜。
提示：了解设计，先研究包结构，如继承关系。
一.项目型：将所有的能兵强将集结在一起，财务部、业务部、IT管理部等的精英们脱离原有的岗位。形成一个正式的部门，并由项目经理领导。这样的优势是项目经理的权利很强、资源充足，所有的项目经理都希望有这样的团队。但是就公司而言，单独团队对公司整体资源的浪费，是显而易见的；对被抽调的个人而言，脱离了原有的岗位。待项目结束之后，精英们将无家可归。（我就亲眼见过无家可归的人，某很有负罪感）
三.矩阵型：可能是最微妙的组织关系了，分为弱矩阵，平衡矩阵，强矩阵。那么这个强、弱、平衡关系是如何界定的呢。就是项目经理与职能经理的权利的强弱关系决定；
弱矩阵（WeakMatrix）、平衡矩阵（BalancedMatrix）、强矩阵（StrongMatrix）是矩阵型组织的三类细分，它们的区别主要是职能经理与项目经理之间的权力大小。职能经理与项目经理之间的权力基本相等时是平衡矩阵，两个极端分别是弱矩阵和强矩阵。
冲突与学习有什么关系？冲突很大程度上是用来检验学习成果，也能过用来提升学习能力。打算开始健身？跑了没几步就气喘吁吁，这是你想健身的意愿与实际体力产生了冲突，说明你体力不足；好不容易迈出步伐到了客户现场却为一些基础的东西争论不休，这是你的实际能力与意愿能力产生了冲突。一门心思埋头写代码，面对同事在架构上的问询争得面红耳赤，则要么是自己没有想清楚，要么是自己说不清楚。