M-A-T Tory's Blog

关于BPEL好像不是你那么理解的，我建议你看看这篇文章
http://www-128.ibm.com/developerworks/cn/webservices/ws-bpel/part1/

这几天可能有些乱，前几天定的计划是学习。主要学关于UML，和一些与业务相关的知识，以及WebService。但考试好像把这一计划弄乱了，今天Merlin把业务扩展的已经差不多了，就像我说的一样，在这上面用不了很多时间。接下来的任务就应该是业务建模了吧，。但这方面的知识我们懂得不是很多，我们最后要的文档是专业的，不能随便写一个就算了。总之，我觉得现在还不是写文档的时候，时间很紧，这是事实。但我们决不能急，很多事情光着急时没有用的。静下心了，还是好好的学习。如果你觉得时间紧，那就抓紧时间。定计划时一定要想明白你现在能干什么，计划定得再好，完不成就是扯！

这个时候的考试让人觉得很不爽，明天该看WebService了

今天去了学校的收发室，地址写的应该没什么问题。估计是五一耽误le ，这几天的计划已经定了，努力吧！

尽自己所能吧

架构是一个系统的核心，系统的好坏完全有架构决定。也许现在的架构还不能称得上真正的架构，随着学习的深入，它可能被更改。由于搜索引擎的存在，很多东西不方便写在这里，呵呵。

这两天的研究WebSphere，400多页的英文的让人一看脑袋就大。但仔细多起来发现也没什么，文章中基本上都是很简单的句型，不像英语考试中有那么多的复合的长句。虽然开始的时候有不少单词不认识，但在金山词霸的帮助下可以很轻松的理解。那些单词出现的频率很高，到了后来基本上就记住了。良好的英文阅读能力在将来的工作中是必需的，现在就应该加强锻炼。关于这两天的一些心得贴在我的Blog 上，有些乱，大家可去看看，等我对WebSphere 有了更全面的认识后我会好好总结一下，与大家分享。

我昨天的总结已经发在我的Blog 上了，大家可以过去看看。这里把一个个人认为很有用的一点东西贴在这：

SOA 的一个架构模板

SOA 的一个抽象观点将它描述为与业务过程结合在一起的合成服务的部分分层架构。 图 3 呈现了这种类型的架构。

服务和组建之间的关系是，企业级的组件（大粒度的企业或者业务线组件）实现该服务并且负责提供它们的功能和维持它们的服务质量。通过组合这些公开的服务到合成的应用程序，就可以支持业务过程流。综合的架构通过使用 Enterprise Service Bus（ESB）支持这些服务、组件和流程的路由、中介和转化。为了服务质量和非功能性的需求，必须监视和管理已经部署的服务。


图 3：SOA 层

对于每一层，你都必须做设计和架构决定。因此，为了帮助用文件说明你的 SOA，你可能应该创建文档，由每个层相应的部分所组成。

这里是为你的 SOA 架构文档设计的模板：

范围 <此架构适用于企业的哪个领域>
操作系统层
打包的应用程序
自定义应用程序
架构决策
企业组件层
企业组件支持的功能范围
<这个企业组件支持业务领域、目标和过程>
关于控制的决策
<作为这个客户端组织内部企业组件来选择某物的标准>
架构决策
服务层
服务分类表
架构决策
业务过程和合成层
业务过程可以表现为舞蹈编排（choreographies）
架构决策
<哪一个过程需要编排在舞蹈编排里面以及哪一个镶嵌在应用程序里面？>
访问或者表现层
<证明这层中 Web 服务和 SOA 的含意；即便要。例如，在用户接口级别上调用 Web 服务的 portlet 的使用，以及在此层机能上的含意。>
集成层
<包含 ESB 因素>
<我们如何确保使用服务的客户端系统级的一致性（SLA）和服务质量（QoS）？>
安全问题和决策
性能问题和决策
技术和标准的局限性以及决策
服务的监控和管理
描述和决策
现在，让我们更加仔细的描述一下每一层以及每一层之间的合成。


层 1：操作系统层。本层包含现有的自定义构建的应用程序，也叫做 遗留系统，包含现有的 CRM 和 ERP 打包应用程序，以及 较旧的基于对象的系统实现，还有业务智能应用程序。SOA 的复合层架构可以利用现有的系统并且用基于服务的集成技术来集成它们。

层 2：企业组件层。本层由那些负责实现功能和保持公开服务 QoS 的企业组件组成。这些特殊的组件是企业和业务单元级支持的企业资产的受管理和控制的集合。 同企业范围资产一样，他们通过架构最佳实践应用程序来负责确保 SLAs 的一致。大多数情况下，本层使用基于容器的技术，比如实现组件、负载均衡、高可用性和工作量管理的应用服务器。

层 3：服务层。业务选择来支持和公开的服务处在这一层。它们可以被 发现或者直接静态绑定，接下来被调用，或者可能的话，编排到合成服务中。这个服务公开层同样提供了获取企业范围组件，业务单元特定组件，以及有些情况下，特定项目组建的机制，并且以服务描述的形式具体化了他们的接口子集。因此，企业组件使用它们接口提供的功能在运行时提供服务实现。在这一层的接口公开为一个服务描述，在这层中他们被公开以提供使用。他们可以独立存在或者作为合成服务。

层 4：业务过程合成或编排层。第三层中公开的服务的合成和编排在这一层中被定义。通过配合、编排，服务被绑定成一个流程，并且从而作为单独的应用程序而共同作用。这些应用程序支持特殊的用例和业务过程。这里，可视的流程合成工具，比如 IBM® WebSphere® Business Integration Modeler 或者 Websphere Application Developer Integration Edition，都可以用来设计应用程序流程。

层 5：访问或表现层。尽管这一层经常超出了围绕 SOA 讨论的范围，但是它却变得越来越有意义。在这里我描述它因为标准越来越集中，比如用于 Remote Portlets Version 2.0 的 Web 服务和其他技术，这些技术追求在应用程序接口或者表现层来利用 Web 服务。你可以把它作为将来的层用来满足将来的解决方案的需求。注意到以下这两点是非常重要的：SOA 将用户接口从组件中分离出来；最终你需要提供从访问路线到服务或者合成服务的端到端解决方案。

层 6：集成（ESB）。这一层使服务可以集成，通过引入一系列可靠的性能的集合，比如智能路由，协议中介和其他转化机制，经常被描述为 ESB（参阅 参考资料）。Web Services Description Language（WSDL）制定了绑定，其包含提供服务的地址。另一方面，ESB 为集成提供了位置独立机制。

层 7：QoS。这一层提供了监视，管理和维持诸如安全，性能和可用性等 QoS 的能力。这是一个通过 sense-and-respond 机制和监测 SOA 应用程序健康的工具来进行的后台处理过程，包括 WS-Management 和其他相关协议的所有的重要的标准实现以及为 SOA 实现服务质量的标准。

这篇文章主要讲了如何将 Web 服务组件组合成跨多重 SOA 的中间件应用程序，以及如何使用下面四种不同的方法来开发它们：

1.自顶向下
2.自底向上
3.旁路
4.嵌入式

在开放的体系结构中开发 SOA 中间件应用程序依赖于（举例）您想要使用哪种关系型或 WebSphere® 包。

还在读《在企业级 SOA 中使用 Web 服务》7篇系列文章，各篇的心得都写在该篇文章下的评论上了。毕竟这不是我的Blog，不能像April 这样写随笔。写我blog 上有不方便交流，评论是个不错的选择。我的Blog 上有我 认为比较有用的文章的摘抄，欢迎大家f阅读。

SOA整合中心、可复用的体系结构 、模块化的 SOA 库、库用例，使这篇文章提到的几个重要的概念。感觉SOA 整合中心应该是今后研究的重点，模块化的SOA 库应该是一个设计的一个标准。将这两个概念列下

SOA 整合中心是 Web 服务与非 Web 服务的合并的 SOA 与后端企业系统的集成。它使得 Web 服务及非 Web 服务能够与运行在不同平台上的服务器、主机和微机上的企业系统交互。

然而，SOA 整合中心不同于面向服务的整合（service-oriented integration，SOI）。SOI 将 Web 服务与运行在不同平台上的主机系统相整合。它使得 Web 服务能够通过网关与主机交互。您需要 ASP.Net 或其它技术获取网关来执行普通的 Web 服务。


模块化的 SOA 库

您可以开发模块化的和优化的 SOA 库，这些 SOA 被分成了不同类别的层次。每个类别可以通过层次最低级别的 Web 服务被进一步划分成 SOA 的子组。

您可以将库用作到 Web 服务应用程序的动态链接。当应用程序需要访问模块化的 SOA 时，它将自己链接到库中。当它不再需要检索到的 SOA 时，将从库中释放自己，当提高速度及性能时节省磁盘空间。

调用框架

要构建 SOAP 请求，需要使用 Web 服务描述语言 (Web Services Description Language，WSDL)，这是一种描述如何访问 Web 服务以及将执行什么操作的语言。您可以指定服务的类型，而不用自定义 Web 服务的代码，也不用重新编译以前的应用程序。

为确保 WSDL 文件能在各种软件架构中工作，您可以利用 IBM Web Services Invocation Framework (WSIF)，它让您可以将 WSDL 作为不同软件标准来描述。这表明您可以通过描述语言周围的 API 以独立于协议和位置的方式访问 WSDL。还意味着您可以通过 WSDL 将 Web 服务结合复合成应用程序，在 WSDL 中您可以在各种条件和异常情况下切换协议和位置。

为构建 WSIF，无论您打算使用什么提供商，您都需要满足最低需求，该选项包括如下：

JAXP XML 解析器
Java API 的 WSDL
Apache SOAP
Apache Axis。

WSDL.....

服务是什么，在一个典型的业务环境里，服务意味着业务函数、业务事务和系统服务
从应用程序的角度来看，业务函数实际上是原子的非系统函数。业务事务很像是调用应用程序的简单函数，但是它们可能是作为自己的事务的上下文所包含的复合函数来实现的

人为的规定服务之间的区别，仅仅是为了引入粒度这个概念。 -----但本文没有给出粒度的确切概念。但根据下文粒度可能是区别函数级别的概念。

接下来的体系结构的集成部分介绍了几个应当考虑的问题。
包括1应用程序集成。2终端用户界面集成。3 应用程序连接 4 流集成 5 信息集成

疑问：
本文还介绍了框架，但不明白

要点总结：

首先必须理解 Web 服务并不等同于 面向服务的体系结构。

SOA 只不过是一种体系结构。它不是任何诸如 Web 服务这样的特定技术的集合

1。所有功能都定义为服务。这仅仅包括业务功能、由底层功能组成的业务事务和系统服务功能。这将会产生粒度问题，后面我们将对此进行讨论。
2。所有的服务都是独立的。它们就像“黑匣子”一样运行：外部组件既不知道也不关心它们如何执行它们的功能，而仅仅关心它们是否返回期望的结果。
3。在其最一般的意义上来说，接口是可调用的；也就是说，在体系结构的层面上，它们究竟是本地的（在本系统内）还是远程的（在直接系统外）、是用什么互连 Scheme 或协议来调用或需要什么样的基础架构组件来连接，都是无关紧要的。服务可能是在相同的应用程序中，也可能是在公司内部网内完全不同的系统上的不对称多处理器的不同地址空间中，还有可能是在用于 B2B 配置的合作伙伴的系统上的应用程序中。

补充一个：
CORBA

=Common Object Request Broker Architecture，是一组用来定义“分布式对象系统”的标准，由OMG(Object Menagement Group)作为发起和标准制定单位。CORBA的目的是定义一套协议，符合这个协议的对象可以互相交互，不论它们是用什么样的语言写的，不论它们运行于什么样的机器和操作系统。

今天马上就要过去了，总结一些今天的成果。
人才管理系统遇到了一个很让人不可思议的错误，改了一下午也没弄明白什么原因。心里很是不爽，被这么一个错误挡住，浪费了那么多时间。
晚上，似乎浪费了更多时间。公司里的考试，本来就没有必要了，更不用说讲考卷了。不过公司付钱给我们，也就这么算了。哈哈
快要回去了，剩下的时间就是自己的了。该好好看看SOA 了，50篇文章呢。

通过SOA ，您可以扩大或缩小编制的范围和性质，通过复用代码来改变复合应用程序的业务流程逻辑。基于个人提出的功能，SOA 中的 Web 服务可被复用并结合到高级服务的复合应用程序中来创建新的业务服务，反之，该业务服务可被复用并结合到另一个 SOA 的业务服务的高级复合应用程序中。
在短时间内一些 Web 服务连同其它的 Web 服务（包括长期运行的基于一套复合业务规则的应用程序）一起完成了业务流程，在整合这样的 Web 服务的过程中您可能会发现问题。Web 服务非常适合于短时间运行的应用程序，而不适合于处理繁重事务的环境，因为在这样的环境下需要很长时间才能完成业务流程。
通过SOA，可以将一系列的Web 服务的业务逻辑结合成一个或更多的复合应应用程序，并使Web 服务能够达到最佳性能，并且不会发生SOAP 超载问题。

以上是我今天看完这篇文章后对SOA 的认识，请大家指正。

这几天忙坏了，四天内弄一个人才管理系统果然不是一件闹着玩的事。但值得庆幸的是今天终于看到曙光了，昨天弄明白了那个问题后进度有了明显加快。今晚能完成全部的编码了，明天再处理一些细节就可交差了。
世界上只有一种不可能，那就是不可能有不可能。我们这四天差不多验证了这句话。
哈哈哈哈。
明天就可以钻心研究SOA了。非常感谢ApriL，它为我们准备这么资料，省得我们自己去找了。Great Job! ! ! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! ! ! ! ! !

我叫谭修光，也就是Tory 。
在此之前，从来没听过SOA，对于我们来说这是一个全新的概念。 但是我们不会因此感到畏惧，探索新的知识是我的最爱，也是我们团队的特点。探索的道路并不是那么平坦，但我们坚信： 只要有付出，就会有回报。