摘录本的摘录内容
Marc Fiammante的新书“动态SOA和BPM：业务流程管理和SOA敏捷性的最佳实践” ，描述了如何基于数十年来在企业中获得的多年实践经验，构建灵活的SOA / BPM系统。 SOA实现。
Marc在他的书中带领读者完成几个主要的SOA / BPM实现步骤，包括：
- 简化用于动态BPM和SOA的企业体系结构，回答以下问题：
- “我的企业应该在哪里灵活？ 哪个企业目标需要应计的可变性？
- 推动变革的企业的业务优先顺序是什么？ 我可以期望发生什么变化？ 哪些条件将首先发展？
- 实现该可变性的收益/风险比是多少？ 有内部赞助商吗？”
- 实施动态企业信息，讨论企业信息变更对SOA实施的影响。
- “尽管应对信息更改在IT领域中像往常一样，但我们仍在努力限制信息更改的影响，特别是如果该信息由服务接口携带并在整个企业的业务流程中进行处理时。”
- 实施可变服务，讨论服务实施模式
- “实现服务可变性对于限制消费者和服务提供者链变化的影响至关重要。”
- 实施动态业务流程，讨论如何基于服务通过自动化的端到端企业流程来构建敏捷企业。
- “企业必须快速有效地应对不断变化的市场需求，法规和客户需求。 在竞争激烈的市场中，他们必须考虑新产品”
本书还包含有关IBM SOA / BPM工具的大量信息，可用于实现这些步骤。
IBM Press向Infoq读者提供了摘录中的摘录，其中介绍了确保过程可变性的技术。
InfoQ与Marc Fiammante进行了交谈，以更详细地了解本书背后的动机和想法：
Infoq：尽管有许多出版物对此进行了说明，但是在您的书中，您认为BPM和SOA两者密切相关，并且似乎暗示着应该将两者一起处理。 您是否考虑在没有BPM的情况下实施SOA，反之亦然？
即使可以孤立地开始SOA和BPM方法，但我还是要提出一个前提条件，说明SOA和BPM在一起会更好。
首先，我不认为SOA是Web服务上的客户机/服务器或面向对象（OO），而是两个业务方之间的业务合同方法。 这种方法使每个当事方的所有权都与他们想要在将其捆绑在一起的同时执行其合同的一部分的方式联系在一起。
当流程的设计没有这种所有权并且有执行的自由时，所有各方的实施都会在全球范围内公开。 结果是，多个参与方或企业所有者最终会控制具有不同生命周期的通用模型的各个部分。 一方提出的关于他们认为是私有的过程元素的每个更改请求，都需要与另一方进行大量协商，而合同方法会限制对接口的影响。 我经常用火车比喻：火车工程师在乎餐厅旅行车的菜单吗？ 相反，他只在乎火车是否跟随，并将对每节货车中发生的事情的控制权留给了具体的负责人。
通过将货车连接在一起，可以实现一个隐式或抽象过程，因为灵活的过程需要在不影响整个列车的情况下用另一辆货车替换货车的能力。
旅行车之间的连接被实现为灵活的业务合同，这些合同将被实现为灵活的服务。
返回到BPM和SOA，我们必须区分高级端到端模型，该模型必须为在代表服务的每个业务合同背后私下发生的事情留有灵活性。
另一个考虑因素是流程交付和测试的成本。 该成本与过程模型的圈复杂度成正比。 我的经验表明，在给定的流程模型中进行更改将导致大约一半人/天的测试工作量乘以循环复杂性，即使更改仅涉及流程的一小部分。 为了降低变更成本，必须对流程进行模块化。 但是仍然需要将过程模块或组件连接在一起。 此连接一定不能传播更改，然后自然的方法是将灵活的服务定义为链接。
Infoq：游击SOA的支持者认为，全球SOA全面改革是灾难的根源。 您是否认为“基于项目”的SOA实施是合理的第一步，还是您认为SOA的真正价值只能在企业级实现？
我将SOA视为实现灵活性的支持者，我向客户表示：“如果不需要，请不要使用它”。 考虑它的一种方法是：不会将伸缩缝放置在建筑物中的任何地方，而是将这些灵活的连接限制在人们希望关联方变化的地方。 合理的第一步甚至可以是一个由单个服务组成的非常小的第一项目。 我想到了两个确切的例子：第一个例子来自一家汽车制造商，该公司在第一年将一项“材料服务单”的ROI评估为几百万欧元，因为如果发生故障可能会节省保修成本，零件原点。 第二家公司是一家信使公司，其服务是为包裹创建带有国内或国际适当变体以及任何国家变体的包裹标签。
为了确定SOA有价值的地方，我们通常基于OSIMM成熟度模型进行评估，使用相同的模型，我们可以创建愿景和路线图来确定SOA的价值所在。 第二阶段将从小规模开始，以确立业务价值和可行性。 稳定将根据确定的业务价值来寻找SOA的其他机会。
Infoq：描述动态企业信息的方法时，建议对可能变化的信息部分使用“ xsd：any”和/或名称/值对。 这种方法假定一个自定义编组将会在有效载荷的至少部分来完成。 为整个文档实施自定义编组会更容易吗？ 您可以建议其他XML设计方法吗？
因为我们通常推荐用于互操作性的WS-I基本概要文件和标准J2EE JAX-WS（以前称为JAX-RPC），所以我们遵循这些标准的含义，包括JavaBean的编组和解组。 Sun的这篇文章明确指出xsd：any将作为javax.xml.soap.SOAPElement.处理javax.xml.soap.SOAPElement.
但是，我不建议使用xsd：any作为方法，但事实是，诸如OAGIS之类的行业标准都将xsd：any用于其所有可扩展性，并且客户也使用它。 我更喜欢TeleManagement论坛使用的Characteristic Value模式，它与XML等效。
关于使用“ xsd：any”以提供灵活性的问题，让我举一个我的大客户为例。 该客户将3个WSDL用于相同的服务：
1 /客户端WSDL； 2 / ESB和注册表使用xsd：any公开了WSDL，以实现更大的兼容性；以及 3 /提供程序端WSDL。
所有3个WSDL都可以承载兼容的XML有效负载。 这种方法减少了来自提供方的更改的影响，并使服务的早期版本与提供方的演进兼容。
Infoq：在W3CWeb服务活动声明之后，您写道Web服务提供了一种在各种软件和应用程序之间进行互操作的标准方法，这些软件应用程序可以在多种平台和/或框架上运行。 但是Web服务未指定实际的业务数据交换，因此实际上不提供对语义数据交换的支持。 您是否相信无需语义数据交换就可以实现互操作性和松散耦合？
我确实相信Web服务的真正价值来自于服务所载业务信息的协议。 然后可以使用诸如SAWSDL之类的标准来说明语义，或者可以将其隐含，因为在用于集成目的的通用且灵活的信息模型上存在行业协议：“数据共享”空间，由美国联邦数据参考模型命名。 。
因此，总而言之，如果遵循一种也可以解决业务有效负载的合同方法，则可以实现松散耦合，但是它不需要使用RDF或OWL进行正式的语义捕获。
Infoq：在您的书中，您写道：“从概念上讲，Web服务只是对目标资源的参数状态转换请求”。 这是否意味着您认为它们在语义上是等效的？ 您认为两者之间有什么区别？
我是在Restful Web Services的上下文中编写的，问题是：使用Restful Service，我是否总能找到一种方法来实现我可以使用更经典的Web Services进行的工作？ 我的立场是肯定的，我认为只要能够清楚地标识资源，就可以在Web服务操作，事件，动作和资源的状态转换之间总找到语义上的对等关系。
例如：transferMoney操作应表示为创建资源或MoneyTransfer资源，其内部状态从已提交到已完成。
将这种方法扩展到行业标准正在做的事情中，在大多数情况下，Web服务操作是一个动词和一个名词以及两个用于请求和响应的传输对象。 我将使用OAGIS 9.3，它在Web服务中使用了动词+名词的方法http://www.oagi.org以下列表包含OAGIS用于对其实体（名词）起作用的13个动词。 我在OAGIS动词旁边放置了适当的REST动词，如果需要，还放置了一个携带状态的附加资源对象：
确认（放置一个确认对象）； 取消（删除）； 变更（POST）； 确认（输入确认对象）； 获取（GET）; 负载（PUT）; 通知（放置一个通知对象）； 发布（PUT）； 流程（为相应实体输入订单）； 响应（放置一个响应对象）； 显示（GET）; 同步（将更新发布给数据的非所有者）； 和更新（POST到数据的所有者）。
作为参考，以下是OAGIS所使用的与各种对象相对应的名词：
ActualLedAllocateResource, AllocateResource, BOM, BudgetLedger, CarrierRoute, Catalog, ChartOfAccounts, ConfirmWIP, CostingActivity, Credit, CreditStatus, CreditTransfer, CreditTransferIST, CurrencyExchangeRate, CustomerPartyMaster, DebitTransfer, DebitTransferIST, DispatchList, EmployeeWorkSchedule, EmployeeWorkTime, EngineeringChangeOrder, EngineeringWorkDocument, Field, InspectDelivery, InventoryBalance, InventoryConsumption, InventoryCount, Invoice, InvoiceLedgerEntry, IssueInventory, ItemMaster, JournalEntry, Location, LocationService, MaintenanceOrder, MatchDocument, MergeWIP, MoveInventory, MoveWIP, OnlineOrder, OnlineSession, Operation, Opportunity, PartyMaster, Payable, PaymentStatus, PaymentStatusIST, Personnel, PickList, PlanningSchedule, PriceList, ProductAvailability, ProductionOrder, ProductionPerformance, ProductionSchedule, ProjectAccounting, ProjectMaster, PurchaseOrder, Quote, Receivable, ReceiveDelivery, ReceiveItem, RecoverWIP, RemittanceAdvice, RequireProduct, Requisition, RFQ, RiskControlLibrary, Routing, SalesLead, SalesOrder, SequenceSchedule, Shipment, ShipmentSchedule, ShipmentUnit, SplitWIP, SupplierPartyMaster, UOMGroup, WIPStatus.
Infoq：您认为，除了JavaScript客户端外，什么时候可以将JSON负载用于REST服务？
如本文所述，传输可以是任何协商的类型，无论是XML还是XHTML。 我之所以特别公开JSON，是因为它展示了一种有趣的可变性方法来携带其信息。 文章指出：“ 使用MIME类型和HTTP Accept标头是一种称为内容协商的机制，它使客户端可以选择适合自己的数据格式，并最大程度地减少服务与使用它的应用程序之间的数据耦合 。”
Infoq：根据您的书“ Commall，使用流程建模标准（例如XPDL或WSBPEL）对流程进行建模”。 您认为这些语言是建模语言还是执行语言？
尽管WS-BPEL是流程的执行语言，而XPDL更是流程的交换格式，但它们已被用作流程模型交换支持的工具，但是，它们都没有像BPMN那样定义视觉符号。 BMPN 2.0标准团队已经发现了这一差距，我强烈希望我们在不久的将来有了一些融合的符号，交换模型和执行模型。
Infoq：谈论服务路由和业务流程时，您正在讨论用于路由和基于策略的外部路由的业务规则。 还有使用服务注册表进行动态路由的地方吗？ 您可以比较这些路由方法吗？
使用WebSphere Fabric，我们确实将路由策略存储在注册表中，因此，有一个地方可以为注册表提供动态路由支持。 但是，我们需要区分路由决策发生的位置和策略的存储位置。 通常，来自注册表的端点和策略被缓存在执行路由的ESB中，而通常，缓存效率模式和路由评估是在总线上动态进行的，而不是在需要远程交互的注册表中。
高效的基于内容的路由首先导致上下文和内容到具有语义的约定结构的映射，这些语义通常可以通过类似于SBVR的人类可读语言（ http://www.omg.org/spec/SBVR/1.0/ ）访问。 进行此类内容或上下文分析的性能影响要求在本地进行处理，并在内存中解析策略或规则。
您可以在下面的实际策略示例中看到，业务人员可以理解用于路由的策略的粗体和斜体元素，但在幕后，它具有指向服务请求内容（ 产品， 三重播放 ）或上下文的显式链接（ 渠道 ， 网络 ）。
对于ActivateConnection 业务服务
什么时候
产品为三重播放 ， 渠道为网络 ， 精英身份为金和
角色是自助服务还是 客户是住宅
使用 激活光纤到家过程
Infoq：在您的书中，您提出了一个重要问题，即限制业务流程拥有的数据量。 您可以针对该主题给出更具体的建议吗？
早期的流程模型方法是将流程流与数据流区分开来。 Web服务和WS-BPEL的引入导致控制信息与其余有效负载的合并。 尽管从理论上讲，这种合并允许将任何信息用作流程决策，但我在业务流程分析中的经验表明，情况很少。 我的建议是在执行流程建模的同时执行业务信息建模。 然后，清楚地识别信息的控制元素，并创建仅显式公开这些元素的特定服务。
然后，确定与“信息即服务”域相关的服务（首先为其余有效负载（包括非控制部分）实施CRUD的服务）。 除了CRUD接口之外，其他操作还可以封装信息的其他分析，并将分析结果作为简单的决定公开。 结果可以被流程用来执行更智能的动作，而不必在流程中携带信息。 然后，在触发流程组件之前，调用者应使用“信息即服务”界面来保存大量信息，并仅使用最少的控制元素来触发流程。 如果过程需要与需要比控制信息更多信息的目标系统交互，则可以在过程外部使用总线中的中介来补充所需信息，然后再到达应用程序。
因此，如果对有效负载的分析发生变化，它将被封装在流程之外，并且不会影响其生命周期。
Infoq：在您的书中，您将机会性事件驱动方法与确定性服务方法之间的区别定义为：“如果事件消息的发布者期望此事件导致特定的行动，那么这就是严格的面向服务的体系结构（SOA）交互……如果消息的发布者不希望事件消息导致特定的动作，但是如果侦听者检查了该消息并应用了一些规则来确定他们是否必须对此做某事，那么我们是真的事件驱动架构（EDA）”。 另一方面，您所描述的EDA与本书前面所述的基于业务规则/策略的路由非常接近。 那么，SOA和EDA之间是否存在显着的体系结构差异？
事件确实可以触发服务，并且在这方面，SOA和EDA之间是连续的。
在SOA中，服务的请求者会直接触发服务的提供者，即使中间有一些规则解析来选择合适的提供者也是如此。 在事件驱动的体系结构中，事件的来源通常不是服务的请求者，而是会有“观察者”来监视事件，并且可以选择通过使用规则来成为服务的请求者。 在EDA中，观察者是服务请求者； 在SOA中，该事件是一个请求，不需要观察者。
这就是为什么我称其为机会主义，因为观察者决定他们是否处理事件并触发服务，而事件的最初来源不是服务请求者。 事件的初始来源不能期望进行特定的处理，因为它无法控制观察者链。
EDA通常公认的设计模式是“ 四人帮”（GOF）模式中的观察者模式，而SOA的通常设计模式则是“ 桥接模式” 。 当然，您可以连接设计模式以结合SOA和EDA。
Infoq：SOA的宗旨之一是假设服务是无状态的。 无状态对于不同的人意味着很多不同的事情。 当您在书中谈论状态和状态管理时，您指的是哪个状态？ 对话状态？ 执行状态？ 还有吗
我将其称为“适应状态”。 为了使应用程序以适当的粒度公开，您需要一个适应和粒度匹配的适应层，该层应尽可能接近目标应用程序。 无状态服务作为可重用服务公开，并且是这种适应的结果。 该服务不会暴露任何状态。
Infoq：在讨论服务生命周期管理时，您正在讨论WebSphere Service Registry Repository的用法，而不是Rational Asset Manager。 您是否认为注册表和存储库具有相同的目的？ 您看到这两种工具的用法了吗？
是的，我看到了这两种工具的用法，甚至将其与变更和配置管理“ Tivoli变更和配置管理数据库（CCMDB） ”相辅相成。
在开发中，一个软件项目包括正在寻址注册表和存储库域之外的域的资产。 这些可以是项目计划，文档和开发人员指南，图像和演示文稿，测试计划，用例和需求； 实际上，任何与项目有关的东西。 在Service Registry and Repository中，通常仅与设计时，代码时和运行时相关的元素相关。 在CCMDB中，您将找到有关软件组件的其他信息，例如中间件版本，硬件级别和配置。
摘录本的摘录内容
扫一扫
4759
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
