面向对象编程中的协调协议封装

理论计算机科学电子札记189（2007）87-103www.elsevier.com/locate/entcs面向对象的协调LidiaFuentes1 和PabloS a'n che z 2D pto o。LenguajesyCienciasdelaComputacio′nUniversidadeMa′lagaM'alaga，Spain摘要不同的软件模块（例如，组成系统的组件不是孤立的实体。事实上，它们需要根据一定的协调协议进行交互，以实现共同的目标。这种协调协议横切不同的软件模块，阻碍了它们的可重用性，独立性，维护和进化，但这些缺点可以通过将协调与计算分离并将协调封装在执行计算的组件之外来解决。面向对象的编程已经被证明是一种处理某些横切问题（如协调）的有趣技术。本文解释了如何协调协议可以实现计算模块外使用通用面向方面的编程语言。关键词：面向对象，协调，组件，协议，状态机。1引言系统分解成的软件模块并不是孤立的，它们需要按照一定的协调协议进行交互，以实现共同的目标。在传统的软件分解技术中，如面向对象[27]或基于协作的[35]技术，这样的协调协议不能适当地封装到单个模块中（例如，对象或组件）。因此，作为系统的一部分的每个软件模块必须执行与两个不同问题相关的两个任务：（1）计算，即，其功能的执行;以及(2)协调，即， 管理与其他实体的互动，协调协议。因此，协调问题似乎与软件模块的计算部分纠缠在一起，并分散在它们之间。协调的交叉性质以及将协调与计算分离所带来的好处已经得到协调委员会的承认1电子邮件地址：lff@lcc.uma.es2 电子邮件地址：pablo@lcc.uma.es1571-0661 © 2007 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi：10.1016/j.entcs.2007.05.04988L. 丰特斯山口Sánchez/Electronic Notes in Theoretical Computer Science 189（2007）87nity，并且为了克服这些缺点，已经提出了几种外生协调模型[4，25，28，8]。将计算与协调分离会带来更好的模块化系统。由于它们更好地模块化，它们的开发，维护和发展更容易[30]。每个单独的软件模块的可重用性也增加了，因为只有软件模块的计算部分被重用，并且没有额外施加协调协议[28，8]。因此，软件模块可以更容易地用作构建块来组成应用程序。此外，由于协调被更好地封装，它也可以在不同的应用程序中作为预构建的软件模块进行重用[28，8]。面向对象编程（AOP）[20]近年来已被证明是一种在横切的软件模块之外实现横切关注点（如协调）的合适技术。本文根据一个外生协调模型，解释了如何使用通用的面向方面编程语言来实现计算模块外部的协调我们将关注基于组件的系统，因为我们以前在这个范例中有过经验，并且很容易理解。此外，本文所揭示的思想可以很容易地推广到其他范例，例如面向代理的[26]。第二节介绍了拍卖系统的实例。第3节解释了为什么协调是一个跨领域的问题。第4节提供了一些关于面向对象的软件开发的背景知识。第5节解释了如何将协调作为一个方面来处理。第6节显示了使用JAsCo [34]作为一个方面的协调的具体实现第7节对我们的方法提出了一些建议。第八节对相关工作的评论。最后，第9节概述了结论和未来的工作。2激励的例子一个在线拍卖系统3被用来作为一个例子来说明整个本文提出的想法。在线拍卖系统允许订阅用户根据一定的拍卖协议对商品的买卖进行谈判。4要参加拍卖，用户必须首先加入。一旦注册，用户可以出价。根据所选择的拍卖协议，客户将能够进行多个出价或仅一个出价;出价可以是私人的或公共的;等等。图1显示了将拍卖系统分解为组件和接口的摘录。5在Szypersky的定义中，组件被认为 组件可以是 黑盒性质，因此我们可能无法访问它们的内部结构。接口是操作/服务签名的集合。的接口3 摘自http：//lgl.ep.ch/research/omtt/auction.html4现有的不同拍卖协议的描述可以在http://en.wikipedia.org/wiki/Auction上找到。5完整的说明可在http：//www.lcc.uma.es/casepablo/CaseStudies/AuctionSystem中找到。L. 丰特斯山口Sánchez/Electronic Notes in Theoretical Computer Science 189（2007）8789ICustomer+callForProposal（价格）+acceptProposal（id，price）国际原子+join（id）#decideWinner（winner，price）+proposal（customerId，bid）<<组件>>拍卖<<组件>>客户Fig. 1.拍卖系统分解为组件可以由组件提供或要求。提供的接口包含组件向其环境提供的操作/服务，而要求的接口包含组件从其环境要求的操作/服务。组件通过接线所需/提供的接口连接。在图1中，IaaS接口由Auction组件提供，Customer组件需要它。本文对拍卖系统特别感兴趣，因为不同的系统可以简单地通过改变拍卖（协调）协议来构建，该协议管理客户和卖方组件之间的消息交换，保持这些组件的计算部分。3计算与协调3.1协调协议正如已经评论过的，软件模块不是孤立的实体。它们按照一种称为协调协议的模式相互通信，协调协议管理它们的通信和交互。协调协议的目的是提供一种将一定数量的可能异构的模块集成在一起的方法，通过以这样一种方式与每个模块进行接口，使得集合形成单个应用程序[29]。协调协议可以用不同的形式表示。我们选择了状态机[17]，因为它们可以很容易地用UML表示，并且我们打算在未来的工作中将本文中提出的思想集成到模型驱动开发[38]过程中。设计协调协议的状态机由软件架构师在架构设计时创建，由应用程序需求驱动状态机处理两个或多个组件之间的交互，并负责实现这些组件之间的协调协议每个状态代表组件之间协调协议的不同状态。转换中的事件表示组件之间通过其提供的/所需的接口交换的消息的截取。事件消费的原始UML语义被稍微修改了。在我们的例子中，一个事件被转换消费意味着与该事件相关联的操作被执行，然后消息被分派到目标。 不触发任何转换的事件不会被交付 到它们的目标对象（在这种情况下，可能会引发异常）。与每个事件关联的操作实现协调任务。该状态机可以90L. 丰特斯山口Sánchez/Electronic Notes in Theoretical Computer Science 189（2007）87Auction.proposeBid（id，拍卖.join（id）[isFirstBid（id）]Auction.proposeBid（id，/{buyers=}Init进入/做/退出//{buyers=buyersU{id}}/placedBids = placedBidsUid/{buyers=}/{buyers=buyersU{id}}/{buyers.callForProposal（bid）}CollectBids拍卖？joinat（joinTimeInitCollectBidsat（joinTiming{price= Auction.getStartingPrice（）;buyers.callForProposal（price）}directBuy（id）at（biddingTime）{price= Auction.getStartingPrice（）;buyers.callForProposal（price）}directBuy（id）at（biddingTime）/Auction. decide Winner（winner，price）关闭拍卖buyers=buyers-winner; buyers.rejectProposal（）;winner.acceptProposal（winner，price）}/Auction. decide Winner（winner，price）关闭拍卖buyers.acceptProposal（winner，price）}图二. 状态机：Private One Bid（左）Public English Style（右）Auctions被认为是一个外部协调器的设计，在组件的提供/需要的接口之间透明地引入（图1中的灰色背景）。在我们的模型中，组件只封装计算，不允许执行与协调相关的任务或活动。为了执行计算，组件可以显式地调用它们所需接口的服务. 它们在所需接口连接到的组件上调用这些服务例如，根据图1，客户组件可以请求服务（例如，join）从Auction组件调用包含在IAERONIC接口中的。组件调用服务时不知道连接器、协调器或放置在它们之间的任何关注拍卖系统示例，有几个协调协议可用（例如，私人英式风格，私人一个出价，私人维克瑞等）。图2（左）显示了一个私有的一次出价拍卖的协调协议，用UML状态机表示。 在这种情况下，当拍卖开始时， 初始化为空集，系统转换为初始化状态。在这种状态下，只能向拍卖组件发送加入消息。任何其他消息发送都被简单地跳过（否则，可能会引发异常）。当加入拍卖的指定时间（joinTime）到期时，将向所有注册买家广播callForProposal消息，系统将进入CollectBids状态。在这种状态下，只允许向Auction组件发送proposeBid消息。此外，每个客户只能发送一条消息，因为在私人一次出价拍卖协议中不可能进行多次出价。当指定的投标时间（biddingTime）到期时，拍卖结束;计算获胜者和最终价格，并向获胜者发送接受消息。由于拍卖是私人的，拒绝消息被发送给所有非赢家买家，没有关于赢家或最终价格的任何信息此外，Auction组件还提供了一个特殊的服务directBuy：每个物品的卖家指定一个金额，该金额是拍卖物品价格的上限。如果客户希望以该金额购买物品，则可以在CollectBids阶段调用此服务，而无需进行更多的出价。在这种情况下，拍卖将结束，拍卖的获胜者将是服务的调用者。因此，状态之间的转换可能由于时间消耗或组件执行的动作而发生。L. 丰特斯山口Sánchez/Electronic Notes in Theoretical Computer Science 189（2007）87913.2将计算和协调合并到组件中的缺陷本节使用拍卖系统的例子说明了一些问题，这些问题是由于组成系统的组件内部的计算和协调的纠缠造成的。正如已经评论的，存在多个拍卖协议，因此，拍卖系统的拍卖协议可以根据新的商业规则而改变是可行的。 例如，当前的私有一个出价拍卖协议我们的拍卖系统可以被一个公共的英式协议所取代在这在这种情况下，必须在协调协议中进行下面评论和图2（右）所示的两项更改(i) 客户现在可以对同一个项目进行多次出价，因此，保护isFirstBid （ id ）从proposeBid转换中删除。此外，由于拍卖现在是公开的，每次有新的出价，所有登记的买家都必须被告知这样的出价。因此，callForProposal（bid）消息被广播到所有这些节点，从而避免了做出更高出价的可能性(ii) 当拍卖结束时，因为它是公开的，所有买家必须被告知获胜者的身份和最终的拍卖价格。 因此，不是像以前那样向非获胜客户发送rejectProposal（），而是向所有客户发送acceptProposal（winnerId，finalPrice）如果协调不是封装在Auction和Customer组件之外，而是硬编码在它们内部，那么上面描述的更改将意味着：(i) 为遵循一个出价私有协议的拍卖系统设计的拍卖和客户组件不能像在使用公共英式协议的拍卖系统中那样被重用。(ii) 由于协调代码可能分散在组件方法中，因此更改将影响组件内的多个位置。此外，定位与协调相关的代码将不是一项简单的任务，因为该代码将与计算代码纠缠在一起。(iii) 由于协调协议没有封装在组件之外，因此不能将其作为构建块重用，以组成使用相同协议但不同交互组件的拍卖系统应用程序总之，可以说，协调横切组件，因此，如果协调与组件内部的计算纠缠在一起，系统维护和进化就会受到阻碍，这也会阻碍软件模块在单个级别上的可重用性和类似的论点可以在[4，25，28，8]中找到。面向对象的编程[20]旨在以透明的方式在横切的组件之外实现横切关注点，例如协调。本文研究了面向对象编程如何帮助透明地实现外生协调器，如图2的状态机92L. 丰特斯山口Sánchez/Electronic Notes in Theoretical Computer Science 189（2007）874面向对象的软件开发（AOSD）面向对象的软件开发[11]旨在解决诸如面向对象（OO）[27]或基于一致性的[35]之类的跨平台软件分解技术的缺点，这些技术涉及横切关注点的封装和组合，例如安全性，监控或持久性。面向方面（AO）改进了关注点的分离，提供了将每个横切关注点适当地封装到一个称为方面的模块中的机制，然后指定这个方面必须如何与它横切的软件模块组合。面向代理可以与当前现有的软件开发范式相结合，如面向对象[19]，基于组件[32]或面向代理[2]。面向方面的原则和面向方面的术语（以粗体显示）如下所述：(i) 软件基础模块（例如，对象或组件）不包含与横切关注点相关的任何引用或代码（例如，持久性）。(ii) 横切关注点被封装在特殊的模块中，称为方面。方面包含特殊的方法，称为通知，它公开了它们的功能.(iii) 每个软件模块都允许在特定点注入横切关注点，这些特定点称为其执行流程的连接点（例如，在他们执行一个方法之后）。当面向方面应用于基于组件的系统时，连接点仅涉及组件公共接口所公开的行为，例如组件创建/销毁、消息传入/传出、事件抛出等。(iv) 特殊的组合规则，称为切入点，指定必须注入横切关注点的软件模块的特定连接点（例如，在执行了所有的foo（）方法之后。此外，切入点可以指定在运行时必须满足的约束，以便在连接点上执行方面（例如，系统处于特定状态）。(v) 最后，面向方面的编译器或平台负责组成整个系统，确保方面建议在切入点选择的连接点上执行。这个组合过程称为织入，可以在编译时（称为静态织入）或加载时执行或者甚至是运行时（称为动态织入）。 在后一种情况下，编织者可以允许我们在运行时添加和删除方面此外，编织过程可能需要修改软件模块的源代码或二进制形式，以便将方面注入其中（称为侵入式编织），或者非侵入性编织（non-invasive weaving）。我们想指出的是，在任何情况下，没有必要查看或修改编织应用的结果。如果应用需要更新，则将对基本模块、切入点和/或方面执行相应的改变。然后，系统将被重新编译（或重新编织）。那么，L. 丰特斯山口Sánchez/Electronic Notes in Theoretical Computer Science 189（2007）8793横切关注点在实现级别上永远不会分散或纠缠。在侵入式织入的情况下，横切关注点在编译后将与基本模块混合在一起，因此在部署和运行时失去了关注点的分离。因此，方面不能独立于其基本模块进行部署在非侵入式编织的情况下，方面被编译成单个模块，可以独立于不同应用程序中的基本模块进行部署，甚至可以作为预构建组件放置在方面存储库在这种情况下，选定的连接点的拦截和方面建议的执行因此，即使在运行时也保持关注点的分离。另外，面向方面的平台可以允许我们动态地添加和删除方面，这使得这种织入适合于动态体系结构，如开放系统。当应用于基于组件的系统时，织入被用来是非侵入性的，以保持软件组件的黑盒属性，并且为了能够将方面重用为组合模块或预构建的组合。nents。5面向对象的协调第3节讨论了协调协议的跨领域性质。由于协调是一个横切关注点，本文提出的想法是使用面向方面充分封装到一个或多个方面的计算组件之外的协调的实现，在一个透明的方式。在设计时，可以使用某种外生协调器模型（如图1的状态机）在其协调的组件之外设计协调协议。然后，在实现时，可以使用面向方面来实现这个协调器。下面描述了使用面向方面编程来实现设计协调协议的状态机的步骤。包含在表示协调协议的设计的状态机中的具有源状态1和目标状态2的每个转换目标消息[保护]/动作如下实现：(i) 所有协调代码，对应于触发转换时必须执行的操作，都封装在一个方面通知中。此代码包括：(a) 与State 1的exit（UML 2.0中的exit/(b) 实现操作行为的代码。(c) 用于将消息调度到目标的代码。(d) 与State 2中的入口相关联的代码（UML 2.0中的入口/(e) 将系统状态从State1更改为State2的代码。(f) 与停留在State 2（UML 2.0中的do/(ii) 然后，构造一个切入点来指定当且仅当：94L. 丰特斯山口Sánchez/Electronic Notes in Theoretical Computer Science 189（2007）87(a) 系统处于状态1。(b) 警卫很满意。(c) 消息被发送到目标。切入点是一种模式，它选择应用程序执行流程的几个连接点这种模式通常由以下部分组成：（1）表示应用程序执行流程中某个事件的表达式（例如，消息的接收）;以及（2）为了执行与切入点相关联的建议而必须满足的某些约束（例如，某些属性具有特定值）。每个面向方面的语言对这些约束的表达能力有很大的不同，所以不可能提供关于如何将步骤（ii）.c和（ii）.d转换为切入点的一般规则。有时候，它们可以放在切入点本身中，有时候这些约束必须在通知代码的开头进行检查。尽管UML标准建议的选择是OCL [39]，但这些守卫可以用不同的语言表示。然后，考虑自动模型驱动转换，需要一个从OCL到我们的面向方面编程语言的生成器来生成这些保护的实现。6在实现所有转换之后，将向协调方面添加一个过滤器建议。它根据状态机语义过滤所有没有触发任何转换的消息。这意味着，例如，一个客户发送给一个拍卖的加入消息在Init状态下永远不会到达目标。 可选地，协调方面可以提出一个异常，以便通知发送方有关此特殊情况。我们想指出的是，将协调作为一个方面来处理的一个重要好处是，组件可以直接相互通信，不知道协调协议，并且不需要保持对外部协调器实体的引用，例如对Mediator模式的引用[13]，从而实现高度的透明度。下一节展示了拍卖系统示例的实现摘录，该示例遵循这些思想并使用面向方面的语言JAsCo（Java Aspect Components）[34]。6协调作为使用JAsCoJAsCo（Java Aspect Components）[34]是Java的一个面向方面的扩展，主要引入了两个新概念：方面bean和连接器7。Aspectbean封装横切关注点，独立于特定的组件类型。Aspect bean可以被认为是一种特殊的组件，它封装了横切关注点.它们可以独立于基本组件进行编译和部署连接器在特定应用程序中部署一个或多个方面bean。6 从 OCL 到 Java 的 代 码 生 成 器 可 以 在 http://www.klasse.nl/octopus/index.html 和 http://dresden-ocl.sourceforge.net/introduction.html7JAsCo中连接器的含义与架构描述语言中的连接器的含义不同。JAsCo中的连接器用于将方面通知与基本组件的实际连接点绑定在一起，而不是连接组件L. 丰特斯山口Sánchez/Electronic Notes in Theoretical Computer Science 189（2007）8795JAsCo的一个重要优点是它使用了非侵入式织入（non-invasive weaving），不需要修改组件的内部结构就可以将方面应用于组件。因此，它可以应用于遗留类（包括Plain Old Java Objects（POJO））或第三方Java组件，而无需在aspect bean是一个常见的Java类，它也包含一个或多个hook。钩子封装了一段横切代码（即，面向方面术语中的建议）。吊钩（图3，第05-13行）由三个主要模块组成：钩子构造器（图3，第06-07行）它声明了一个抽象切入点，即连接点的抽象模式（例如，方法调用，方法执行）钩子横切。此模式由连接器当该方面被部署在特定应用8内时。isApply子句（图3，第08-09行）它是一个在运行时计算并返回布尔值的函数，为了在钩子横切的连接点上执行钩子主体，该值必须为true钩子主体（图3，第10-12行）它包含横切代码。它还声明何时执行与连接点相关的操作，即，前后左右。使用上一节中介绍的通用方案，由状态机定义的协调协议被转换为JAsCo，如下所示：(i) 创建一个方面bean来封装与协调协议相关的所有代码(ii) 对于每个过渡，都会创建一个挂钩。(iii) 这个钩子在发送消息时执行。这意味着所有的构造函数都有HookName（method（..args）作为它们的签名，并且它们将call（方法）作为它们的主体，call（方法）是用于拦截消息发送的JAsCo抽象切入点。(iv) 转换的保护被转移到isApply子句，该子句检查保护是否在运行时得到满足。此外，isApply子句还必须检查协议是否处于转换的源状态否则，无法触发转换。(v) 所有的动作都是在发射过渡时进行的，都是在钩体中进行的。(vi) 最后，添加了一个Filter钩子，以实现filter方面来忽略所有不触发任何转换的消息（另一种选择是引发异常）。图3显示了私有一次出价拍卖协议的JAsCo实现的摘录。所有与协调相关的代码都封装在PrivateOneBid方面bean中（第00-29行）。为了简洁起见，在图3中，仅出现了ProposeBid钩子（第15-29行），其实现了Auc.8这种机制（抽象模式加上连接器的后期实例化）增加了方面的可重用性[34]96L. 丰特斯山口Sánchez/Electronic Notes in Theoretical Computer Science 189（2007）8700 public class PrivateOneBid {15 hook ProposeBid {0116ProposeBid（方法（.. public String（）{02矢量连接点> transFired17return（method）;} //构造函数03int state= INIT;18public void run（）{04Vector CustomerId> placedBids;19return（this.state== COLLECT_BIDS）&&0520（placeBids.contains（Customerargs[0]））;}06挂钩筛选器{2107过滤器（方法（.. publicString（）{22public void run（） {08return（）;}23return（）;09public void run（）{24println（println）;10快回来！return（）;}25return return（）;11public void run（）{26state= COLLECT_BIDS;12返回null;27return（）;13}28return return value;14}// around +Filter29}}// around + ProposeBid30 静态连接器PrivateOneBidConnector {31PrivateOneBid.InitJoin hk_1=新privateOneBid.InitAuctionJoin（* Auction.join（*））;32PrivateOneBid.ProposeBid hk_2 = new PrivateOneBid.ProposeBid（* Auction.proposeBid（*））; 33.34PrivateOneBid.Filterhk_3 = new PrivateOneBid.Filter（**.*（*））;}图三. JAsCo中实现的一个私有一标拍卖协议摘录proposeBid（id，amount）[isFirstBid（id）]/{placeBids+=id}transition;以及Filter钩子（第05-13行）。ProposeBid钩子通过它的构造函数指定它将在发送（通用）消息时执行（第16-17行）。“......”我的意思是。args“表示截获的消息的参数，并且在运行时可以作为钩子作用域中的Object数组访问。如果系统处于COLLECT BIDS状态，则isApply子句（第18-20行）返回true，即，转换的源状态（第19行）和转换保护得到满足（第20行）。如果这两个条件在运行时都不成立，钩子主体将不会被执行。如果它们成立，钩子主体（第22-29行）将围绕（第22行）执行，即替换消息的发送。这意味着我们可以在这样的消息发送之前和之后执行操作，甚至忽略它。钩子主体开始将当前连接点添加到transFired向量。这个向量包含当前拦截的触发转换的连接点，过滤器将对其进行分析，以决定是否必须过滤消息。 为了避免误解，我们想澄清一下，从同一个发送者发送到同一个接收者的相同消息，具有相同的参数，但在两个不同的执行中被视为不同的连接点。接下来，执行实现与转换相关联的操作的代码（第24行）。 然后，执行对proceed（）特殊指令的调用（第25行）。该指令将控制传递给被拦截的连接点，这意味着消息将继续其朝向目标组件的路径。这个发送仍然可能被其他尚未评估的钩子拦截。在此之后，proceed（）指令返回截取的消息执行的返回值。随后，钩子将协议状态更改为转换的状态目标（第26行），删除transFired向量的当前连接点（第27行）并完成（第28行）。与并发相关的问题，即，由几个钩子同时访问状态变量的问题，都由JAsCo编译器解决，所以程序员不需要处理这些问题。最后，为了在特定应用程序中部署协调方面bean，L. 丰特斯山口Sánchez/Electronic Notes in Theoretical Computer Science 189（2007）8797连接器（第30-34行）必须构建。它用每个钩子必须拦截的方法签名的通配符可用于表示签名模式。例如，ProposeBid钩子被实例化以拦截proposeBid消息的所有发送（第32行）。proposeBid消息可以有任意数量和类型的参数（**），并且它必须将Auction组件作为目标。钩子的执行顺序由每个钩子在连接器中实例化的顺序决定。Filter钩子必须在JAsCo连接器的末尾实例化，以确保它是最后执行的。由于JAsCo实现了非侵入式编织，因此结果在语义上等同于将实现特定拍卖协议的新Coordinator组件连接到Auction和Customer组件的接口。面向方面编程的一个有趣特性是Customer和Auction组件不知道这个协调器实体。7讨论在本文的介绍中，声称面向方面允许开发人员实现更好的系统模块化，从而使系统的开发，维护和进化更容易。对这一主张的深入验证超出了本文的范围，但感兴趣的读者可以在Videira和Bajracharya [37]和Garcia等人[14]中找到关于这些问题的定量研究，其中作者研究了Aid-Orientation如何为我们的系统增加价值，从而改善模块化。然而，另一方面，它可能会增加复杂性和额外的问题，如新的依赖关系或方面交互。关于可重用性，没有现有的定量研究来证明我们的主张，但我们可以提供定性的情况下，使用拍卖系统的例子，以评估它们。首先，关于拍卖协议的变化，使用面向方面，特别是JAsCo，只会影响协调方方面bean，因此相同的拍卖和客户组件可以用于构建具有不同拍卖协议的拍卖系统。因此，相同的基本组件可以被重用以构建具有不同协调模式的系统。在JAsCo的情况下，它实现了一个非侵入式的动态编织，这甚至可以在运行时完成。如果我们想改变一个正在运行的系统的拍卖协议，可以在运行时拔掉实现它的协调器方面bean，并插入实现新拍卖协议的新协调器方面bean。因此，这种动态的面向方面语言确实适合于动态演化，比如开放系统。其次，假设我们需要构造一个具有不同计算需求的拍卖系统，但它遵循相同的拍卖协议。例如，让我们假设出价可以以不同的货币提出，因此Cus- tomer和Auction组件必须是多币种的。这种变化只会影响这些组件的计算部分，而不会影响协调方面bean98L. 丰特斯山口Sánchez/Electronic Notes in Theoretical Computer Science 189（2007）87执行拍卖协议。由于协调器方面bean的实现独立于Auction和Customer组件的特定实现，因此它可以按原样重用。然而，方面bean协调的可重用性有一些限制。尽管组件不知道它们是如何被协调的，但它们必须通过接口提供允许它们被协调的方法。例如，在Auction System中，Customer组件必须提供一个callFor- Proposal方法，以允许接收初始拍卖价格。协调协议中的更改可能需要组件接口中的新方法。因此，组件和/或方面bean协调器的可重用性也将取决于其接口支持更改的能力。在拍卖系统的情况下，可以预先知道现有拍卖协议的完整集合。因此，这种变化是可以预见的。在其他情况下，这样的完整集合可能是未知的，因此，不能预期改变，并且因此，一些改变可能不被充分支持。在理想的情况下，组件的接口不应该强加任何协议。如果一个组件强加了一个与协调协议不匹配的协议，那么它就需要进行调整[40]。如何实现适配器使用一个spect-orienationatio已在[6，12]中得到了验证。FuntesandSanchez[12]说明了如何使用面向方面的编程来实现适配器，以解决签名、协议和服务质量不匹配的问题。因此，面向方面的一个额外好处是可以使用相同的语言支持来实现协调器和适配器。该方法的另一个限制是协调器方面只能对组件的可观察行为做出反应。因此，如果协调协议的状态需要根据组件执行的不可观察动作的结果来推进，则这种方法将不起作用。解决方案是强制基本组件在每次由于外部不可观察的操作而导致状态更改时发送事件。这些事件将由协调器方面接收，协调器方面将执行所需的动作来协调组件。另一种解决方案是使用灰盒组件，其中组件可以通过其接口公开其私有方法甚至状态。这些方法不能被组件客户端调用，当然，组件状态只能被读取，但是协调器方面可以观察它们，例如，在执行这些方法之前，周围或之后执行方面。这种解决方案类似于协调角色[28]。随着协调模式复杂性的增加，协调方面bean的大小也会增加，从而有可能成为一段无法管理的代码。最近的面向方面的语言，如JAsCo或EAOP9，能够将方面应用于方面。这个特性可以用来定义协调器的协调器，允许通过组成简单的协调模式来创建复杂的协调器，例如Reo [4]或外源连接器[25]。9http://www.emn.fr/x-info/eaop/L. 丰特斯山口Sánchez/Electronic Notes in Theoretical Computer Science 189（2007）87998相关工作本节描述了以前的工作，其中协调已经从组件计算中分离出来，并封装在一个特殊的模块中。包括传统的和面向方面的方法8.1传统技术将协调与计算分离的想法在文献中并不新鲜。近年来，设计模式、内生协调模型和外生协调模型的出现都试图实现这一目标。我们概述了其中的每一个8.1.1设计模式一些设计模式[13]专注于解决协调问题。例如，Mediator模式试图解耦组件，从而减少互连的数量。Wrapper和Role模式用于扩展或限制软件模块的功能。然而，设计模式也有一些缺点：(1)它们是抽象的解决方案，通常难以实例化;（2）协调问题的解决可能需要组合几种设计模式（例如， 中介器加包装器），复杂性相应增加;(3)其中一些需要修改应用它们的软件模块的源代码，即，（4）使用面向对象技术实现设计模式可能导致横切代码，因此使用面向方面技术可以更好地实现设计模式[16，14];（5）设计模式通常需要组件知道外部协调器实体的存在，如中介器，并保持对它们的引用。这些缺点在面向方面的协调中不存在。 在Truyen的博士论文[ 36 ]中，可以找到关于面向方面相对于传统面向对象技术（包括设计模式）8.1.2内生协调模式内生模型和语言，如Linda [15]，提供了必须纳入计算的协调这些协调模型集中在解耦消息的发送者和接收者，但是实体仍然负责使用通信原语、本地化通信信道等。它们还必须实现协调协议。如果该方案发生变化，组件将变得过时。内生语言的协调原语横切应用程序组件，并讨论了其在易维护性、演化性和可重用性方面的缺点。这种缺点在面向方面的协调中不存在。8.1.3外生协调模型本文提出的方法与外生协调模型非常相似，如流形[5]，Reo [4]，协调角色[28]或外生连接器[25]，其中协调器实体对组件的外部行为做出反应，100L. 丰特斯山口Sánchez/Electronic Notes in Theoretical Computer Science 189（2007）87行动本身。事实上，我们已经提出了面向外生协调器的编程作为实现外生协调器的合适技术，与Capizzi等人[7]达成一致。然而，外生协调模型相对于面向方面的一个缺点是，基本组件通常需要与协调器实体进行间接交互，例如，发送事件，或者满足某些约束，例如，外生连接器[25]禁止组件调用其他组件。通过使用ANORT-Orientation，协调器实体被透明地引入到基本组件中。此外，- ten的外生模型需要某种特殊的语言支持，这是专门用于管理协调的[5，4，28]。通过使用AASP-Orientation，可以将外部协调器透明地引入此外，面向方面的语言支持也可以用于实现适配器[6，12]和/或分离其他横切关注点，例如持久性[33]或调度[23]等[24]。然而，在目前，不应将ANOW-Orientation视为可以轻易分离任何横切关注点的圣杯，因为仍有一些挑战需要解决[22，21]。8.2具有协调支持的第一次尝试的成本控制在[18，9，8]中是一个很好的选择。Herna′ndez et al [18]引入了协调的概念，并提出了一些与其实现相关的问题，其中大部分在本文中得到了解决（除了无法从组件外部观察到的协调状态更改）。 Cuesta等人[9]展示了如何通过面向方面的ADL在架构级别将协调指定为方面。然而，它们没有涉及如何将协调作为一个方面来实施。Corchuelo等人[8]提出了一种面向方面的语言CAL，用于实现多方交互协议。然而，这种语言是专门用于协调的，它不能用来分离其他横切关注点。[10]和[1]介绍了关于协调的一个方面的广泛研究。然而，这项工作是基于两个特定的面向对象的组件平台：CAM/DAOP [32，31]和MALACA [3]。两者都使用特定的语言来指定横切关注点。本文说明了如何协调可以从计算中分离使用基本的面向方面的功能，在所有面向方面的语言或平台，没有任何特殊的语言支持协调。因此，不需要CAM/DAOP、MALACA或CAL中的特殊协调功能。目前，有很多面向方面的语言可供使用，它们针对不同的开发需求和领域（实时系统，Web服务，组件系统，应用服务器）。因此，使用相同的语言支持，面向方面，外源协调器可以实现为一个方面在不同的应用领域与不同的需求和约束。最后，Capizzi等人[7]提出了一个类似于这项工作的想法。他们通过放置横切代码，L. 丰特斯山口Sánchez/Electronic Notes in Theoretical Computer Science 189（2007）87101内部的模型。此外，本文还说明了如何弥合设计和实现之间的差距，为实现通过状态机指定的协调协议提供明确的规则