expedition4.bokee.com    复制

服务模型是在对企业进行业务角色分析、业务流程分析、关键性能指标评价等一系列业务分析之后，抽取出来的可以为企业创造价值的不同层次的业务活动或功能，这些业务活动或功能可以作为一种可重用的资源——服务“存储”在企业服务仓库中。

服务模型有以下几种：

（1）、功能服务：可以单独提供具体业务功能的服务；

（2）、流程服务：用于编排到流程中的服务；

（3）、人工服务：人工实现的服务；

（4）、规则服务：用于表示业务规则的服务。

（5）、其他服务。

对服务模型的操作有三种：标识（identification）、描述(specification)、实现（implementation）。在这篇文档中，我们要涉及到对服务模型的标识（服务模型的分析）和描述（服务模型的设计）操作。

对服务模型的标识也称为“服务发现”，IBM 的SOMA（Service-Oriented Modeling and Architecture）的方法能够为服务发现提供强大的方法论支持。SOMA是IBM用于服务建模和架构设计的方法学，SOA IF是支持SOMA的工具，业务组件、一级业务流程和业务目标是服务建模的三种主要输入。下面我们来看一下SOMA是如何进行“服务发现”的：

第一步：从一级业务流程逐步分解为各个层次的服务候选者，如下图：

其中，产品销售流程是一级流程，而其下面所有的子节点都是由这个以及流程逐层分解出来的。第一步的工作必须基于之前对企业业务流程的分析之上。

第二步：通过关键性能指标（KPI）分析来验证已有服务候选者以及发现遗漏的服务候选者，如下图：

       这一步也可以叫做“目标服务建模（Goal Service Modeling）”。这一步的思想是这样的：从企业的业务目标出发，目标分解为子目标，子目标再分派给相关的服务来实现，这样，就形成了一颗“目标服务树”，处于叶子节点上的每个服务都能回溯到具体的业务目标。第一步的工作必须基于之前对企业关键性能指标的分析之上。

       第三步：通过对已有系统的分析发现遗漏的服务候选者，并为服务实现提供依据，如下图：

这一步也可以叫做“遗留资产分析”，它的主要思想是：通过建立已有系统所具有的功能模块目录列表，我们可以方便的发现那些在不同的系统中被重复实现的功能模块以及我们可以复用的功能模块，从而将这些模块包装成服务发布出来。遗留资产分析的来源一般是原有系统的分析和设计文档。遗留系统分析的结果是可以重用的服务列表。

服务的描述是对发现及标识出来的服务的名称、服务的提供者、服务的消费者，服务所依赖的其他服务、服务的接口（输入参数以及输出参数）等服务属性做一个全面的描述。描述格式大致如下表：

服务名称	服务消费者	服务提供者	依赖的其他服务	输入参数	输出参数	服务描述

1、Rose UML 建模工具的使用
2、WebSphere Dev 相关文档的研读
3、完善组件设计文档
4、扩展的需求、医疗器械行业的背景分析
5、系统架构文档的落实

太赞了，赛和黑队也很配合，才有6：0的传奇比分。

Oh，一切都是如此的smooth。

 

 

【推荐】北京高考零分作文之“北京就是圆环套圆环娱乐城”

曾经固执地认为，负责北京城市规划的人一定是一个搞行为艺术的。

我这么认定的理由之一是：他怎么会将偌大的北京城以“环”为单位来划分？

有人说了，北京是Ｎ朝古都，皇城在那儿一摆，二环路往那儿一搁，不按环儿往外辐射，那怎么划分？我想说的是，中国古都那么多，皇城也不是紫禁城独一座，再说哪个城市还没个新城老城的？怎么就北京这么干呢？大清朝亡国多少年了，难道还非要把这个紫禁城当作是全北京乃至全国的中心，让大家伙儿整天围着它绕圈儿吗？说到这里，不由得联想到《一个馒头引发的血案》里的“圆环套圆环娱乐城”，不晓得导演大人是不是借这片子在讽刺北京的城市规划，如果是，那倒是意外的共鸣了。

相信每个曾经或正在那些二、三、四上面绕圈的人都会对这些“环儿”们深恶痛绝。那分明不是路，而是观音姐姐给孙悟空戴的箍儿，一圈一圈地把人们套在里面。而且套上容易，想摘掉可是比登天还难。君不见每天上下班高峰期，甚么内环外环主路辅路赌成了一窝蜂。这个环儿本身没什么毛病，要是每个人都以观光为目的，在环儿上开着车子兜风，那当然是大家Ｈａｐｐｙ。可惜不是，这南来北往的车流，大家伙都是要赶时间谋生的主儿，谁也不想把生命浪费在围着紫禁城绕圈儿上。所以，圈外的想挤进去（据说主路比辅路快），圈里的要杀出来（貌似过了某个出口就得上高架，一股脑开出去好几公里才能掉头），这一进一出的，车就堵上了。

说来说去，这些环儿们方便的只有那些纯以绕圈为目的的观光客，而真正爽了的，相信只有搞行为艺术的那位，君不见五、六、七、八环都已经铆足了劲准备往上套了吗？这可比街头那十块钱一玩的套圈儿来得过瘾，一套一个准儿，好几千万人，一下子就全套进去了。

还有就是在这些二三四五六七八环上盘踞着的立交桥们。

立交桥这东西显然是舶来品，我想老外相对中国人是比较务实的，发明这劳什子应该主要目的还是缓解交通压力。不过这些立交桥到了中国设计师手里，就首先变成了艺术品。那一座座桥架得是个顶个的高，修得是一个赛一个的漂亮，可惜，该堵的地方它还是会堵。相信把那些个立交桥全都拆了换成红绿灯，交通也未必会差得了多少，甚至司机们还不用因为盘桥盘昏了头而多走好几公里的冤枉路。当然，之前说的那些以绕环路跑圈为目的的“观光客”们可能就没这么爽了。

说到立交桥，当然不得不提那个世界建筑史上的极品——西直门立交桥。我至今仍记得第一次见到盛名之下的西直门桥时的感觉，那就是一个字——艺术，真ＴＭＤ艺术。直到现在我都查不清楚那座桥究竟有几层几个口几条道儿，只知道每次在桥下面打车，想沿着学院路往北走，就没有一次不用绕大圈的。更不用说从西外大街向二环南下的那个极品右转弯儿，用北京人的说法叫“走三个剪刀把”，你听听，连走法都这么艺术。别说外地人不知道怎么走，就算是那些整天水深火热地跑着的的哥们，怕是稍一打盹就得转了向。

我所熟悉的立交桥，除了西直门那座极品，就得属二环沿线的那些神奇的立交桥了。还是回到最初的说法，那些立交桥存在的主要目的，就是让想沿着二环路观光的人们跑得爽。当然了，只是跑得爽，设计的时候可从没考虑爽之前怎么进去和爽之后怎么出来。那些个立交桥的统一风格就是——二环路永远是直通的，在二环路的头顶上形成一个环岛，不管是东去西来南下北上，想跑路就得先跟着大家伙儿在环岛上慢悠悠地转着，转到了合适的角度，你再随着鳖爬一样的车队慢慢地磨出来。

也许北京的立交桥数量在世界上算不得最多，不过本人有理由相信，在艺术型立交桥（相对于实用型）数量所占比重上，北京绝对是世界首屈一指的。

行为艺术家的思维依旧围着紫禁城转着圈儿，在那些圈儿上也依旧会有一座接一座的艺术型立交桥拔地而起，再加上主路辅路依旧不经意地泼墨大写意。我有理由相信，三十，不，也许五十年后，我仍旧会说：“我曾经固执地认为，负责北京城市规划的人一定是一个搞行为艺术的。”

这是系统的问题还是我配置日值的时候出的问题？

大家要看日志的话，进入首页后再点一下日值的链接栏就能看见所有的日志了。

C and D are kisssing.
A and B are watching.
A moment later……

B: I see love and peace. And you?
A: I see on demand business in demand people.
B: Are you kidding?
A: No, I am serious.
B: You are so romantic.
A: Yes , I am .
B: ＄◎×7％￥

Then, the IBM logo emerges.

　　SOA目前在业界已经受到了足够的关注和追捧，但是一个企业要想成功实施SOA，必须使企业的高层（CIO、CEO等）真正认识到SOA与以前的信息系统是不同的概念，认识到SOA是业务驱动的，实施SOA不仅仅是单纯的技术问题，而且是一个如何更好地满足企业经营管理需要的问题，特别需要关注业务流程和企业架构的设计。

       在设计和实施企业的SOA时，需要通过CEO、CIO等了解企业战略，需要业务人员和IT人员充分的讨论明确业务的模型，只有这样才能保证实施的SOA能够充分支持业务的需要。如果企业的高层没有充分重视SOA的实施，没有积极的参与到SOA的设计中，没有有效的促进业务人员和IT人员的充分沟通，而只是像以往一样购买了一套系统和解决方案后就期望它能给企业带来很大效益，那SOA的实施是很难给企业带来好处的。因此，为了保证SOA能够实施成功，必须使CXO们真正重视它。

    在和企业签订实施SOA的合同前，SOA提供商应该确认该企业的管理者对实施SOA下了决心并愿意积极的参与和推进业务模型建立、流程设计等工作。这些工作既可以从一个全新的系统的总体设计阶段以高起点的方式着手，也可以在一个已有系统的改进升级中逐步过渡。其中最关键的就是负责总体设计的系统架构师对企业内业务操作和经营管理两方面需求的理解，特别是潜在需求的深入挖掘、深刻理解和合理抽象。换句话说这不仅仅是单纯的技术问题，而是一个如何更好地满足企业经营管理需要的问题。

　　SOA管控是保证企业的IT系统能充分支持企业业务的关键。服务（services）具有分布式特性，它们可能是由企业内外的不同组织维护的，不同组织的服务之间甚至可能要进行功能合成，这些都给SOA管控带来了很大的挑战。

SOA管控指的是在SOA环境下对IT系统的管控。之所以这么说，是因为SOA并不是一项需要管控的IT资产，事实上，它是一种企业架构。实施了SOA的企业应该以面向服务的视角来看待它的IT资产。SOA管控应该以面向服务的观点解决以下三个问题：

1. 为了保证IT系统有效的使用和管理，使之支持业务战略，应该做出什么样的决策？

2. 这些决策应该由谁来做出？

3. 这些决策是怎样做出的？它又是怎样被监控和确保实施的？

在Tilak Mitra的论文《A case for SOA governance》中，作者认为SOA管控应该自顶向下分为四个层次，依次为：

u       董事会层。该层制定企业的业务战略和目标，对企业的哪部分业务流程应该被改进或是哪些新的应用应该增加做出关键的决策。

u       领导层。这一层接受董事会层的企业业务战略和目标，并在SOA管控中直接向董事会层汇报。领导层由CoE（center of excellence）以及每个业务域（business domain， 代表一组具有相同的业务环境的业务服务）的业务经理和IT经理构成。他们创建企业架构和SOA规则，决定创建什么应用架构，确保IT系统能满足业务需要。

u       机会管理层（Opportunity management level）。该层是由许多initiative team组成的，每个initiative team都关注一个或几个相关的业务需求，对迎合业务需求的明确定义的业务应用负责。initiative team都有业务组的组长和IT组的组长。业务组组长负责收集并规范化业务需求，对应的IT组组长负责创建符合领导层制定的SOA规则的应用架构。

　　u       项目管理层。该层的每个项目组负责一个典型应用的设计和开发的全生命周期，包括解决方案定义、规划、宏观设计、微观设计、构建、测试和发布。

在计算机世界中，我们也许可以很容易地获得来自互联网中的各种信息（比如HTML页面，XML数据）等，然而，对于这些信息的真正含义的理解却不是计算机能够轻松解决的问题。比如说对于词汇“订单审核”，也许如果没有上下文的话，我们是很难判断它具体指的是“审核订单中客户信息的完备性”还是“审核订单中的产品的库存数量是否足够满足订单的需求”。

语义理解对于SOA的服务的重要性也是如此。虽然说现有的WSDL文件可以清晰地描述服务的各种输入输出消息，服务的端口类型等，但是仅仅只有这些还是远远不够的。因为SOA承诺能够很好地实现业务和IT的结合，所以要求计算机对服务的理解不能与服务所表达的实际业务用意脱离。

目前，服务语义的理解也是SOA面临的挑战之一。具体的解决办法可能还要依赖语义网（Semantic Web）技术的发展和进步。

问题的提出：

SOA是一个复杂而庞大的项目，任何组织实施SOA，必须创建一个基本的架构模型，用它来管理商业流程的各个阶段，然后应用这些复用性很强的模块来实施各个项目。这个建立企业架构的过程包括确认所有的商业流程，它们之间的交互关系，针对各种业务和服务的特殊应用和功能，以及商业流程中的数据流向。同时还要设定技术和方法的标准，选择实施的工具，建立一些基础性（面向系统）的服务，这一过程需要几年的时间，并花费大量的财力、人力才能达到它最终的目标。

然而当企业一个重要的商业项目需要立刻实施，或者当一个企业的财力人力都非常有限的时候，企业的架构是很难快速转移到SOA的架构上来的，这种情况对于SOA来说是一个重要而严峻的挑战。

SOA项目的设计者和实施者也许会说，部署SOA的秘诀在于分阶段实施SOA，而不是立刻完全实现SOA。因为部署SOA不是一蹴而就的事情，很多商业战略随着时间的推移可能会发生改变。创建企业架构并且分阶段部署，可以在一个时间段内集中在一个应用领域，或者根据商业的急迫程度来选择项目优先实施SOA。

但是当设计和开发出一个企业架构时，你很难考虑到所有的事情。这就需要SOA的实施者有准确的洞察力，去预测将来的服务架构和特定的商业流程可能的变化。然而谁都不可能准确的预知将来的事情，因此SOA对于一些商业流程相对成熟的行业和领域，比如银行、航运还是很有效的，但是对于一些新兴的产业作用并不明显。

解决问题的思路：

针对不同的企业规模、资金、人力和实施期限的情况，开发出多版本的SOA解决方案或者架构模式。针对于企业规模较小，资金、人力有限，或者需要短期内迅速实现的业务，可以设计一种小型SOA解决方案，包含SOA最基本的模块儿和快速实现业务的流程；针对大型企业，资金、人力资源充足，实施时间充裕的情况下，可以采用大型SOA解决方案，包含完整的SOA基础模块、分阶段实施的规划等等。比如目前Java软件的三个主要的版本，J2SE用于开发小型应用，J2ME用于开发中等规模的应用，J2EE用于开发企业级的大规模应用，这三个版本有效的满足了个人或企业使用Java开发各种不同需求的软件的要求，有效的节约了开发者的费用，提高了开发效率。

针对不同需求的SOA解决方案之间的可伸缩性是必须解决的一个问题。比如一个企业，开始规模较小，需要短期上马一个新的业务，可以采用小型的SOA解决方案。实施SOA之后，新业务发展迅猛，用户数量激增，带来了巨大的利润，企业也迅速壮大。这样的情况下，原有的SOA解决方案已经很难满足快速发展的业务需求，这个时候，是否能够在原有的小型SOA解决方案的基础上，扩展成大型SOA的解决方案就成了一个重要的问题。相反的情况，当企业发展受阻，盈利下降，规模缩小的时候，可能很难维持原有的SOA的架构模式，这时，能否演变到小型SOA架构模式也是企业关注的问题所在。