关键字 |
| 中间件、同步DTP(分布式事务协议),CORBA,妈妈,RPC。 |
介绍 |
| 各种商业趋势导致越来越对分布式系统的需求。首先,公司之间的并购的数量继续增加。新合并的公司的不同部门提供统一的服务给他们的客户,这通常需要一个集成的IT系统。可用的时间交付这样的集成通常是如此短,建立一个新系统不是一个选择,因此现有的系统组件必须集成到一个分布式系统,作为一个集成的计算工具。其次,提供新的服务是可用的时间减少。这常常只能实现如果是现成的,然后购买组件集成到一个系统,而不是从零开始。组件被集成可能不兼容的要求他们的硬件和操作系统平台;他们必须被部署在不同的主机上,迫使系统分布式。最后,互联网提供了新的机会提供产品和服务大量的潜在客户。在这种背景下,这是很难估计的可伸缩性需求。 An e-commerce site that was designed to cope with a given number of transactions per day may suddenly find itself exposed to demand that is by orders of magnitude larger. The required scalability cannot usually be achieved by central-ized or client-server architectures but demands a distributed system. Distributed systems can integrate legacy components, thus preserving investment, they can decrease the time to market, they can be scalable and tolerant against failures. The caveat, however, is that the construction of a truly distributed systems is considerably more difficult than building a centralized or client/server system. This is because there are multiple points of failure in a distributed system, system components need to communicate with each other through a network, which complicates communication and opens the door for security attacks. Middleware has been devised in order to conceal these difficulties from application engineers as much as possible; As they solve a real problem and simplify distributed system construction, middleware products are rapidly being adopted in industry [6].In order to build distributed systems that meet the requirements, software engineers have to know what middleware is available, which one is best suited to the problems at hand, and how middleware can be used in the architecture, design and implementation of distributed systems. The principal contribution of this paper is an assessment of both, the state-of-the-practice that current middleware products offer and the state-of-the-art in middleware research. Software engineers increasingly use middleware to build distributed systems. Any research into distributed software engineering that ignores this trend will only have limited impact. We, therefore, analyze the influence that the increasing use of middleware should have on the software engineering research agenda. We argue that requirements engineering techniques are needed that focus on non-functional requirements, as these influence the selection and use of middleware. We identify that software architecture research should produce methods that guide engineers towards selecting the right middleware and employing it so that it meets a set of non functional requirements. We then highlight that the use of middleware is not transparent for system design and that design methods are needed that address this issue. This paper is further structured as follows. In Section 3,we discuss some of the difficulties involved in building distributed systems and delineate requirements for middleware. In Section 4, we use these requirements to attempt an assessment of the support that current middleware products provide for distributed system construction. We then present an overview of ongoing middleware research in Section 5 in order to provide a preview of what future middleware products might be capable of. In Section 6, we delineate a research agenda for distributed software engineering that builds on the capabilities of current and future middleware and conclude the paper in Section 7. |
相关工作 |
| 在这个特殊的区域我们确定软件体系结构的研究应该产生方法,系统地指导工程师对选择正确的中间件和使用它的方式满足一组非功能性需求。然后我们强调中间件的使用是不透明的系统设计和设计方法需要解决这个问题。两种趋势的讨论是很重要的中间件软件工程研究的影响。首先,中间件产品构思在分布式系统的建设提供直接的好处。他们因此迅速采用行业。其次,中间件供应商都有良好的记录将中间件研究成果转化为他们的产品。一个例子是ISO / ODP交易员,于1993年被定义,采用CORBA标准在1997年和去年成为可用的CORBA产品。因此一个好机会,一些先进的研究领域的灵活、可伸缩、实时和移动中间件将在3 - 5年成为实践的状态。除非软件工程研究分布式系统提供了原则,符号,兼容的方法和工具的功能,目前的中间件产品提供和中间件的研究将产生未来软件工程研究成果只能有限的工业意义。行业将采用已知的中间件提供的好处而忽略不兼容的软件工程方法和工具。中间件产品和研究,然而,只支持编程和很大程度上忽略所有其他活动需要在软件过程的分布式系统。 We, therefore, have a chance to achieve a symbiosis between software engineering and middleware. The aim of this section is to identify the software engineering research themes that will lead to the principles, notations, methods and tools that are needed to support all life cycle activities when building distributed systems using middleware. |
中间件的需求 |
| 在本节中,我们回顾在分布式系统建设所遇到的困难。在本节中,我们认为,它太昂贵和费时,如果应用程序设计者必须解决这些问题通过直接使用网络操作系统原语。相反,他们需要一个中间件,提供更高级的原语。这种分布式系统建设与中间件的方法绘制如图1所示。 |
| 因此中间件之间的分层网络操作系统和应用程序组件[13]。中间件促进沟通和协调的组件分布在几个网络主机。中间件的目的是为应用工程师提供高标准的原语简化分布式系统建设。使用中间件来构建分布式系统的概念与使用数据库管理系统在构建信息系统。它使应用程序工程师抽象底层的实现细节,如并发控制、事务管理和网络通信,使他们能够专注于应用程序需求。 |
网络通信 |
| 如图1所示,分布式系统的不同组件可能驻留在不同的主机上。为了使分布式系统出现作为一个集成的计算设备,组件必须相互沟通。这沟通只能通过使用网络协议,通常更优雅的ISO / OSI参考模型[25]。分布式系统通常建立在传输层的顶部,其中TCP或UDP是很好的例子。下面的层所提供的网络操作系统.Different传输协议的共同之处,他们可以在不同的主机之间传输消息。如果分布式系统之间的通信程序在这个层次的抽象,应用工程师需要实现会话和表示层。这是太贵,太errorprone太耗时。相反,应用程序工程师应该能够请求参数化服务可能不止一个远程组件,可能希望执行它们作为原子和孤立的事务,离开会话和表示层中间件的实现。请求一个服务组件的参数需要通过一个组件,它提供了一个服务通常是复杂的数据结构。表示层实现的中间件应该提供能够将这些复杂的数据结构的格式可以使用传输协议传输,即。一个字节序列。This transformation is referred to as marshalling and the reverse is called unmarshalling. |
协调 |
| 由于组件驻留在不同的主机上,分布式系统有多个控制点。组件在同一个主机上并发执行,从而导致需要同步,当组件相互通信。需要在会话层中实现这种同步的实现提供的中间件。同步可以以不同的方式实现。一个组件可以被阻塞在等待另一个组件完成的执行所请求的服务。这种形式的交流通常被称为同步。组件发出请求后,还可以继续执行其操作与服务提供和同步组件在晚些时候。这种同步可以由客户端组件(例如使用轮询),在这种情况下,相互作用通常被称为延迟同步。同步启动的服务器称为异步通信。因此,采用工程师需要一些基本的机制,支持多种形式交流组件之间的同步。有时超过两个组件参与服务请求。 These forms of communications are also referred to as group requests. This is often the case when more than one component is interested in events that occur in some other component. An example is a distributed stock ticker application where an event, such as a share price update, needs to be communicated to multiple distributed display components, to inform traders about the update. Although the basic mechanisms for this push-style communication are available in multi-cast networking protocols additional support is needed to achieve reliable delivery and marshalling of complex request parameters. |
| 协调问题略有不同,由于大量的分布式系统的组件。组件,即模块或库,一个集中的应用程序驻留在应用程序执行时虚拟内存。这是不适合分布式组件有以下原因: |
| ¯主机有时不得不被关闭和组件驻留在这些机器必须停止并重新启动主机恢复操作时; |
| ¯资源所需的所有组件在一个主机也许大于主机可以提供的资源;和 |
| ¯取决于应用程序的性质,组件可能长时间闲置,从而浪费资源,如果他们保存在虚拟内存。 |
| 由于这些原因,分布式系统需要使用一个概念叫做激活,允许组件执行进程启动(激活)和终止(停用)独立于应用程序执行。中间件管理持久性存储的组件的失活和恢复之前状态组件在激活状态。中间件也应该启用应用程序程序员确定激活策略,定义组件是激活和取消激活。考虑到组件上执行并发分布式主机,服务器组件可能请求的同时从不同的客户端组件。中间件应该支持不同的机制称为线程控制服务器组件如何应对这样的政策一致,请求。服务器组件可能是单线程的,队列的顺序请求和处理它们的到来。另外,组件也可能生成新线程和执行每个请求的线程。最后使用的组件可以使用一个混合线程策略与固定数量的线程池来执行请求,但是开始排队一旦没有自由线程池中。 |
可靠性 |
| 网络协议有不同程度的可靠性。协议在实践中使用并不一定保证每包,发送方传输实际上是由接收机接收,发送的顺序保存。因此,必须把分布式系统实现错误检测和校正机制在应对这些不可靠的地方。不幸的是,服务请求和服务结果的可靠传递不免费的。可靠性必须支付与降低性能。让工程师权衡可靠性和性能以灵活的方式,事实上需要不同程度的服务请求的可靠性。关于服务请求两个组件之间的通信,分布式系统的可靠性,提出文学是最好的努力,至多一次、在至少一次,仅一次[13]。尽最大努力服务请求不要给任何保证的执行请求。至多一次请求担保只执行一次。他们可能不执行,然后请求者是失败的通知。 At-least-once service requests are guaranteed to be executed, possibly more than once. The highest degree of reliability is provided by exactly-once requests, which are guaranteed to be executed once and only once. Additional reliabilities can be defined for group requests. In particular, the literature mentions k-reliability, time-outs, and totally-ordered requests. K-reliability denotes that at least K components receive the communication. Time-outs allow the specification of periods after which no delivery of the request should be attempted to any of the addressed components. Finally totally-ordered group communication denotes that a request never overtakes a request of a previous group communication. The above reliability discussion applies to individual requests. We can extend it and consider more than one request. Transactions [18] are important primitives that are used in reliable distributed systems. Transactions have ACID properties, which means they enable multiple request to be executed in an atomic, consistency-preserving, isolated and every completed transaction is consistent. It demands that a transaction is isolated from concurrent transaction and, finally that once the transaction is completed its effect cannot be undone. Every middleware that is used in critical applications needs to support distributed transactions.Reliability may also be increased by replicating components [4], i.e. components are available in multiple copies on different hosts. If one component is unavailable, for example because its host needs to be rebooted, a replica on a different host can take over and provide the requested service. Sometimes components have an internal state and then the middleware should support replication in such a way that these states are kept in sync. |
可伸缩性 |
| 可伸缩性表示能力,以适应未来负荷增长。在集中或客户机/服务器系统、可伸缩性是有限的服务器主机能承受的负荷。这可以克服分发负载跨多个主机。构建一个可扩展的分布式系统的挑战是支持组件配置主机的变化不改变系统的架构或任何组件的设计和代码。这只能通过尊重透明度的不同维度在ISO开放分布式处理(ODP)参考模型[24]系统的架构和设计。透明的访问,例如要求的组件访问另一个组件的服务是在相关的是本地的还是远程的。另一个例子是位置透明性,这要求组件不知道他们与组件的物理位置。详细讨论不同透明度的尺寸超出了本文的范围和读者被称为[13]。如果组件可以访问服务不知道物理位置并没有改变他们的方式请求,负载平衡机制可以迁移机器为了减少负载之间的组件在一个主机和另一个主机上增加。又应该是透明的,用户是否发生了迁移。 This is referred to as migration transparency. Replication can also be used for load balancing. Components whose services are in high demand may have to exist in multiple copies. Replication transparency means that it is transparent for the requesting components, whether they obtain a service from the master component itself or from a replica. The different transparency criteria that will lead to scalable systems are very difficult to achieve if distributed systems are built directly on network operating system primitives. To overcome these difficulties, we demand from middleware that they support access, location, migration and replication transparency. |
非均质性 |
| 分布式系统的组件可能会采购现成产品,可能包括遗留和新组件。由于他们通常相当异类。这种异质性有不同的维度:硬件和操作系统平台、编程语言和中间件本身。硬件平台为原子数据类型使用不同的编码,如数字和字符。大型机使用EBCDIC字符集,Unix服务器可以使用7位ASCII字符,而基于windows的个人电脑使用16位Unicode字符编码。字母数字数据发送的字符编码在不同类型的平台必须调整。例如,同样,大型机和RISC服务器使用大端对数字的表征,即最重要的字节编码整数,长或浮点数是最后一个。电脑,然而,使用一个低位优先的字节表示的意义减少。因此,每当一个号码发送从低位优先的主机高位优先主机,反之亦然,这个数字编码的字节顺序需要交换。这种异质性应该通过中间件来解决而不是应用工程师。 When integrating legacy components with newly-built components, it often occurs that different programming languages need to be used. These programming languages may follow different paradigms. While legacy components tend to be written in imperative languages, such as COBOL PL/I or C, newer components are often implemented using object-oriented programming languages. Even different object-oriented languages have considerable differences in their object model, type system, approach to inheritance and late binding. These differences need to be resolved by the middleware. As we shall see in the next section, there is not just one, but many approaches to middleware. The availability of different middleware solutions may present a selection problem, but sometimes there is no optimal single middleware, and multiple middleware systems have to be combined. This may be for a variety of reasons. Different middleware may be required due to availability of programming language bindings, particular forms of middleware may be more appropriate for particular hardware platforms (e.g. COM on Windows and CORBA on Mainframes). Finally, the different middleware systems will have different performance characteristics and depending on the deployment a different middleware may have to be used as a backbone than the middleware that is used for local components. Thus middleware will have to be interoperable with other implementations of the same middleware or even different types of middleware in order to facilitate distributed system construction. |
中间件解决方案 |
| 在本节中,我们审查目前的中间件产品的状态。我们确定在多大程度上满足上述需求,突出他们的缺点。因为它是不可能审查个人中间件产品在这篇文章中,我们首先提出一个分类,它允许我们从特定产品特性和抽象为比较不同的方法提供一个概念性的框架,四类,我们考虑是事务性的,面向消息的中间件程序和对象或组件。我们选择这种分类基于th原语,中间件产品提供分布式组件之间的交互,分布式事务、消息传递、远程过程调用远程对象请求。 |
事务处理中间件 |
| 事务处理中间件支持事务涉及分布式主机上运行的组件。事务来实现分布式事务。这一类产品包括IBM CICS [22], BEA的燕尾服[19],Transarc Encina。网络通信:事务中间件使应用程序工程师定义服务器组件提供的服务,实现这些服务器组件,然后编写客户机组件请求几个这些服务的一个事务。客户端和服务器组件可以驻留在不同的主机上,因此请求通过网络的方式是透明的,客户端和服务器组件。 |
| 协调:客户端组件可以使用同步或异步通信请求的服务。事务中间件支持各种活化政策,允许服务在需求被激活和停用时,已经闲置了一段时间。激活也可以在内存中。 |
| 可靠性:一个客户端组件可以集群多个服务请求到一个事务,即使服务器组件驻留在不同的机器上。为了实现这些事务、事务中间件必须假定参与服务器实现两阶段提交协议。如果使用数据库管理系统构建的服务器组件,可以委托实施两阶段提交这些数据库管理系统。这个实现可以移植,一个标准的定义。分布式事务处理(DTP)协议,已通过的开放组织,定义了一个可编程接口两阶段提交的xa协议[43]。DTP被广泛支持的关系和面向对象的数据库管理系统。这意味着分布式组件,使用任何一种数据库管理系统可以很容易地参与分布式事务。这使得它们容错,自动恢复到所有完成交易的结束。 |
| 可伸缩性:大多数事务监控器支持负载平衡、和复制的服务器组件。复制的服务器通常是基于复制功能,数据库管理系统提供的服务器组件的依赖。 |
| 异构性:事务中间件支持异构性,因为组件可以驻留在不同的硬件和操作系统平台。不同的数据库管理系统也可以参与交易,由于标准化DTP协议。解决数据异构性,然而,不支持事务中间件,中间件不提供原语来表达复杂的数据结构,可以作为服务请求参数,因此也不元帅。上面的讨论表明,事务中间件可以简化分布式系统的建设。然而,交易中间件有几个缺点。首先,它创建了一个不必要的开销,如果没有需要使用事务,与酸或事务语义是不合适的。这种情况下,例如,当客户端per-marshalling客户机使用的数据结构和参数,服务需要在许多产品需要手工完成。第三,尽管两阶段提交的API是标准化的,没有标准的方法来定义服务器组件提供的服务。这减少了可移植性不同事务监控器之间的分布式系统。 |
面向消息的中间件(MOM) |
| 面向消息的中间件(MOM)支持分布式系统组件间的通信通过促进消息交换。这一类产品包括IBM的MQSeries[16]和Sun的Java消息队列[20]。 |
| 网络通信:客户端组件使用妈妈发送消息到服务器组件在网络上。消息可以通知事件,或从服务器请求一个服务执行组件。这样一个消息的内容包括服务参数。服务器响应客户端请求与应答消息包含服务执行的结果。 |
| 协调:一个妈妈的力量是这个模式支持异步消息传递非常自然。客户端尽快继续处理中间件的消息。最终服务器将发送消息包括结果和客户端能够收集信息在适当的时候。这种实现解耦的客户机和服务器,导致更多的可伸缩的系统。的弱点,同时同步请求的实现是繁琐的手动同步需要实现客户端。另一个妈妈的力量是它支持组通信通过分配相同的消息到多个接收器以透明的方式。 |
| 可靠性:妈妈通过实现消息队列实现容错存储消息暂时在持久存储。发送方写消息到消息队列,如果接收方不可用由于失败,消息队列保留消息直到接收器再次可用。 |
| 可伸缩性:妈妈不支持访问透明度很好,因为客户端与远程组件,组件使用消息队列通信虽然是没有意义使用队列为当地沟通。这种缺乏透明度禁用迁移和复制队列需要由管理员和队列的使用是硬编码在客户端和服务器组件,导致僵化和不适应性架构。 |
| 异构性:妈妈不支持数据异构性非常好,当应用程序工程师必须编写代码,警察。与大多数的产品,有不同的编程语言绑定。在评估妈妈的优点和缺点,我们可以注意到这类实现分布式中间件尤其wellsuited事件通知和发布/ subscribe-based架构。消息队列的持久性意味着这个事件通知可以实现容错方面,这样组件接收事件后重新启动时失败。然而,面向消息的中间件也有一些缺点。它只支持可靠性至少一次。因此,同样的信息可以不止一次交付。此外,妈妈不支持事务属性,如原子的消息交付全部或没有一个接收器。只有有限的支持可伸缩性和异质性。 |
程序上的中间件 |
| 远程过程调用(Remote Procedure call, rpc)是由太阳Mi-crosystems在1980年代早期的开放网络计算(ONC)平台。太阳提供的远程过程调用的所有操作系统和提交rpc作为标准的X /开放的财团,它采用的分布式计算环境(DCE) [36]。rpc现在可用在大多数Unix实现和微软的Windows操作系统。 |
| 网络通信:RPC支持RPC程序服务器组件的定义。RPC程序出口大量的参数化过程和相关的参数类型。客户驻留在其他主机在网络上可以调用这些程序。程序性中间件实现这些过程调用的参数打包成消息发送到主机服务器组件的位置。服务器组件解组消息并执行程序和传输编组结果返回给客户端,如果需要的话。编组和解组实现在客户端和服务器存根,由编译器自动创建从一个RPC程序定义 |
| 协调:rpc是一个客户机和一个服务器之间的同步交互。异步和由程序直接不支持多播通信中间件。程序上的中间件提供了不同形式的激活服务器组件。激活策略定义远程过程程序总是可用的或是否已启动。关于需求的启动,RPC服务器由inetd守护进程一旦开始一个请求到来。inetd需要一个额外的配置表,提供了一个远程过程之间的映射项目名称和项目文件系统的位置。 |
| 可靠性:rpc与执行语义最多一次。的procedural middleware returns an exception if an RPC fails. Exactly-once semantics or transactions are not supported by RPC programs |
| 可伸缩性:rpc相当有限的可伸缩性。Unix和Windows RPC没有任何复制机制,可以用来规模RPC程序。因此复制必须解决的设计师基于rpc的系统,发布/ subscribe-based架构。消息队列的持久性意味着这个事件通知可以beachieved在容错方面,这样组件接收事件后重新启动时失败。然而,面向消息的中间件也有一些缺点。它只支持可靠性至少一次。因此,同样的信息可以不止一次交付。此外,妈妈不支持事务属性,如原子的消息交付全部或没有一个接收器。只有有限的支持可伸缩性和异质性。 |
程序上的中间件 |
| 远程过程调用(Remote Procedure call, rpc)是由太阳Mi-crosystems在1980年代早期的开放网络计算(ONC)平台。太阳提供的远程过程调用的所有操作系统和提交rpc作为标准的X /开放的财团,它采用的分布式计算环境(DCE) [36]。现在可以使用rpc在大多数Unix imple-mentations也在微软的Windows操作系统。 |
| 网络通信:RPC支持RPC程序服务器组件的定义。RPC程序出口大量的参数化过程和相关的参数类型。客户驻留在其他主机在网络上可以调用这些程序。程序性中间件实现这些过程调用的参数打包成消息发送到主机服务器组件的位置。服务器组件解组消息并执行程序和传输编组结果返回给客户端,如果需要的话。编组和解组实现在客户端和服务器存根,由编译器自动创建从一个RPC程序定义。 |
| 协调:rpc是一个客户机和一个服务器之间的同步交互。异步和由程序直接不支持多播通信中间件。程序上的中间件提供了不同形式的激活服务器组件。激活策略定义远程过程程序总是可用的或是否已启动。关于需求的启动,RPC服务器由inetd守护进程一旦开始一个请求到来。inetd需要一个额外的配置表,提供了一个远程过程之间的映射项目名称和项目文件系统的位置。 |
| 可靠性:rpc与执行语义最多一次。的procedural middleware returns an exception if an RPC fails. Exactly-once semantics or transactions are not supported by RPC programs. |
| 可伸缩性:rpc相当有限的可伸缩性。Unix和Windows RPC没有任何复制机制,可以用来规模RPC程序。因此复制必须解决的设计师基于rpc的系统,这意味着在实践中,基于rpc的系统只在有限范围内进行部署。 |
| 异构性:程序中间件可以使用不同的编程语言。此外,它可以在不同的硬件和操作系统平台。程序使用中间件标准定义标准化的数据表示作为传输请求和结果的表示形式。DCE,例如标准化网络数据表示(NDR)。编组RPC参数时,存根硬件具体的数据表示转化为标准形式和执行反向映射在解组。程序性中间件是弱于事务中间件和妈妈一样不容错和可伸缩的。此外,协调原语中可用程序中间件更受限制的,因为他们只吃晚饭——港口直接同步调用。程序性中间件改进事务中间件和妈妈关于接口定义,实现自动编组和数据编出服务参数和结果。程序性中间件的一个缺点是这个接口定义不是反射性。这意味着程序导出一个RPC程序不能返回另一个RPC程序。 Object and component middleware resolve this problem. |
对象和组件的中间件 |
| 对象中间件是由rpc演变而来的。对象中间件的发展反映类似的演进在面向对象的编程语言,编程语言(如c++从过程式编程语言如C .这里的想法是让面向对象的原则,如目标识别通过引用和继承,可用于分布式系统的发展。系统在这类中间件包括公共对象请求代理体系结构(CORBA) OMG(34岁,37),微软的组件对象的最新版本(COM)[5]和远程方法调用(RMI)以来,已可用功能Java1.1 [28]。最近的这一类产品包括中间件支持分布式组件,如企业Java bean [30]。不幸的是,我们可以只讨论和比较重要的一类中间件短暂和更多的细节请参考(8、13)。 |
| 网络通信:对象中间件支持分布式对象请求,这意味着客户端对象请求从服务器执行一个操作的对象可能驻留在另一个主机。客户端对象必须有一个对象引用服务器对象。编组操作参数和结果再次通过存根生成的接口定义。 |
| 协调:默认同步原语在对象中间件同步请求,阻止客户端对象,直到服务器对象返回响应。然而,支持其他的同步原语。CORBA 3.0,例如,既支持延迟同步和异步请求的对象。对象中间件支持不同的激活策略。这些包括服务器对象是否活跃的所有时间和启动ondemand。线程可用的政策,确定新的线程启动多个操作是否并发请求的客户,或他们是否排队和顺序执行。CORBA还支持组通信事件和通知服务。该服务可用于实现推样式架构。 |
| 可靠性:对象的默认可靠性atmost一次请求。对象中间件支持异常,客户抓住为了检测到一个故障发生在执行请求。CORBA消息或通知服务[33]可以用来实现只有一次可靠性。对象中间件还支持事务的概念。CORBA对象事务服务[32],可以从多个分布式对象用于集群请求事务。COM集成与微软的交易服务器[21],和Java事务服务[7]为RMI提供了相同的功能。 |
| 可伸缩性:对象中间件的支持构建可伸缩的应用程序仍然比较有限。一些CORBA实现支持负载平衡,例如通过使用使用名称服务器返回一个对象引用服务器加载最小的主机上,或者使用工厂至少加载主机上创建服务器对象,但支持复制仍相当有限。 |
| 异构性:对象中间件支持异构性在很多不同的方式。CORBA、COM都有多个编程语言绑定,这样客户机和服务器对象不需要用相同的编程语言。他们都有一个标准化的数据表示,他们使用跨平台解决异构性的数据。Java / RMI以一种不同的方法为异质性已经解决了客户端和服务器的Java虚拟机对象驻留。不同形式的对象中间件互操作。CORBA orb间协议定义了互联网(IIOP)标准[34],控制不同的CORBA实现交换请求数据。Java / RMI利用本协议和使用它作为一个传输协议对于远程方法调用,这意味着一个Java客户机可以执行远程方法调用CORBA服务器,反之亦然。CORBA还指定了一个微软的COM规范决定的。对象中间件提供了非常强大的组件模型。他们把大部分事务的能力,面向消息的中间件或程序。 However, the scalability of object middleware is still rather limited and this disables use of the distributed object paradigm on a large scale. |
中间件的 |
| 而中间件产品已经成功地应用于工业实践,他们仍然有几个缺点,防止其使用在许多应用领域。这些缺陷导致相对呆板的系统,不能很好地应对不断变化的要求;真的不扩展到局域网;他们是不可靠的,不适合在无线网络中使用。在本节中,我们审查的最先进的中间件的研究,解决了目前的弱点,将会影响下一代中间件产品。我们讨论交易、反射和应用层传输机制,支持更灵活的软件架构的建设。我们现在的复制技术,将导致更好的可伸缩性和faulttolerance。然后我们讨论研究中间件支持实时应用程序的最后地址移动和普适计算中间件的研究结果。 |
灵活的中间件 |
| 交易:大多数中间件产品使用命名为组件标识:妈妈使用指定消息队列、DCE目录服务,CORBA命名服务,COM使用名字和Java / RMI使用RMIRegistry将名称绑定到组件。客户端组件发出请求之前,它必须解决一个名称绑定为了获得服务器组件的引用。这意味着客户需要惟一地标识他们的服务器,尽管location-transparent的方式。在许多应用领域,它是不合理的假定客户端组件的组件可以识别他们可以获得一个服务。即使他们可以,这导致僵化的体系结构,客户端组件不能动态地适应更好的服务提供者成为可用。 |
| 交易已被认为是另一种命名,它提供了更多的灵活性。ISO / ODP标准定义了交易的主要特征[2]。的想法是类似于黄页电话簿。而不是使用名字,基于服务类型的组件的位置。的trader registers the type of service that a server component offers and the particular qualities of service (QoS) that it guarantees. Clients can then query the trader for server components that provide a particular service type and demand the QoS guarantees from them. The trader matches such a service query with the service offers that it knows about and returns a component reference to the client. From then on the client and the server communicate without involvement of the trader. The idea of trading has matured and is starting to be adopted in middleware products. The OMG has defined a Trading service [32] that adapts the ODP trader ideas to the distributed object paradigm and first implementations of this service are becoming available. Thus trading enables the dynamic connection of clients with server components based on the service characteristics rather than the server’s name. |
| 反射:另一种方法更灵活的组件执行环境是反射。反射是一个著名的范式编程语言[17]。程序使用便餐机制发现类型或类在运行时和定义方法调用。反映目前的中间件产品已经支持一些扩展。CORBA的界面库和动态调用in-terface启用客户端程序员发现目前已知的服务器组件的类型,然后从这些组件动态地创建请求调用操作。当前研究反射中间件[9]超越反射对象和组件模型。它旨在支持元对象协议[29]。这些协议是用来检查和中间件执行环境本身的适应。在[12]建议,例如,使用一个环境模型。检验环境的元模型支持查询中间件的行为事件,如消息到来,询问请求,编排和反编排、线程创建和调度请求。 Adaptation of the environment meta-model enables components to adjust the behaviour of the middleware to any of those events. |
| 应用层传输协议:当编组和解组主要是最好通过中间件实现,有应用,中间件创建一个不必要的开销。因此,反思的一个重要应用是编组。这是特别的情况下有一个特定于应用程序的数据表示,可以通过网络传输和异质性不需要通过中间件来解决。在[14]我们调查中间件和标记语言的结合使用,比如XML [14]。我们建议将XML文档作为粗略的字节字符串使用中间件。这种组合是出于这一事实XML支持数据结构之间的语义翻译和现有的标记语言定义的事实,如FpML[15]或FIXML可以利用[23]。另一方面,XML最初的HTTP协议使用显然是不适当的满足可靠性要求。可以预期,应用程序之间的互操作性和中间件的数据结构将适时出现,因为OMG已经开始采用过程的技术,将CORBA之间提供无缝的互操作性数据结构和XML结构化文档[35]。 |
可伸缩的中间件 |
| 尽管中间件是成功地在局域网中使用可伸缩的应用程序,目前的中间件标准和产品实施限制,防止其在全球分布的系统中使用。特别是,当前中间件平台不支持复制所需——萨里程度实现全球分销[31]。国家的艺术研究解决这个问题通过不透明的复制。 |
| 复制:Tanenbaum是解决这一问题的分布式对象中间件全球项目[42]。全球的目的是提供一个基于对象的中间件,扩展到十亿个用户。为了实现这一目标,全球广泛使用的复制。不像其他的复制机制,如伊希斯[4],全球不假设存在一个普遍适用的复制策略。它复制,而表明政策必须type具体,因此他们必须由服务器对象设计师。因此,全球假定每个类型的对象自己的策略,主动复制对象。 |
实时中间件 |
| 很好的总结了先进的实时中间件已经在欧盟资助的红葡萄酒生产卓越网络[1]。目前大多数中间件产品只有有限的使用在实时和嵌入式系统,因为所有请求有相同的优先级。而且目前的中间件产品的内存需求防止部署在嵌入式系统中。这些问题已经被各种研究小组解决。道[39]是一个实时CORBA原型开发,支持请求优先级和调度策略的定义。CORBA 3.0规范[41]基于这项研究和标准化实时和最小的中间件。 |
中间件为移动计算 |
| 目前的中间件产品承担高带宽网络连接的持续可用性。这些无法实现与身体移动主机由于各种原因。无线局域网协议,如WaveLAN,实现合理的带宽。然而,他们只有操作如果主机是触手可及的几百米的基站。网络中断发生如果移动主机在跨区域由不同的基站覆盖或如果他们进入“无线电阴影”。广域无线网络协议,如GSM细胞交接期间也有类似的问题。此外,他们的带宽是通过数量级较小;GSM最多达到9600波特。State-ofthe——艺术无线和广域协议,如GSRM和utm将改善这种情况。然而,他们将不会被用于另一个两年。 Several problems occur when current middleware products are used with these wireless network protocols. Firstly, they all treat unreachability of server or client components as exceptional situation and raise errors that client or server component programmers have to deal with. Secondly, the transport representation that is chosen for wired networks efficient. Middleware products are therefore optimized to simplify both, the translation between different heteroge- neous data representations, and the routing of messages to their intended receivers. Such optimizations do not need to choose size efficient encodings for the network protocol and are therefore inappropriate when packets are sent through a 9,600 baud wireless connection.Research into middleware for mobile computing aims to overcome these issues by providing coordination primitives, such as tuple spaces, that treat unreach- ability as normal rather than exceptional situations. Moreover, they use compressed transport representation to save bandwidth. A good overview into the state of the art for mobile middleware is given by [38] and we therefore avoid to delve into detail in this paper. |
中间件和软件工程研究 |
| 在本节中,我们分析中间件产品的可用性的后果及其进化由于中间件研究软件工程研究议程。我们认为在构建软件系统的非功能性需求的重要性与现有的和即将到来的中间件和识别需要需求工程技术,专注于非功能性需求。 |
需求工程 |
| 协调的挑战、可靠性、可伸缩性和异构分布式系统建设中,我们在第二节中讨论,工程师面临的非功能特性。软件工程师因此必须定义软件架构,满足这些非功能性需求。然而,非功能性需求和软件体系结构之间的关系是非常知之甚少。我们首先讨论的需求工程结束这种关系。现有的需求工程方法往往有很强的专注于功能性需求。尤其是面向对象和用例驱动的方法,雅各布森[27]和最近Rational[26]或多或lesscompletely忽略非功能性问题。目标的方法,如[10]似乎提供一个更好的基础,但需要增加专门解决非功能性问题。为非功能性目标是一个有用的输入middleware-oriented架构,这些目标需要量化。从不需要量化需求模型所需的响应时间、最大负荷和整体事务或数据量,预计将扩大的体系结构。因此需求工程研究需要设计方法和工具,可以用来引出和模型从定量的角度非功能性需求。 Once a particular middleware system has been chosen for a software architecture, it is extremely expensive to revert that choice and adopt a different middleware or a different architecture. The choice is influenced by the non-functional requirements. Unfortunately, requirements tend to be unstable and change over time. Non-functional requirements often change with the setting in which the system is embedded, for example when new hardware or operating system platforms are added as a result of a merger, or when scalability requirements increase as a result of having to build web-based interfaces that customers use directly. Requirements engineering methods, therefore, not only have to identify the current requirements, but also elicit and estimate the ranges in which they can evolve during the planned life time of the distributed system. |
软件架构 |
| 只有很少的中间件软件架构的影响,与[11]是一个明显的例外。事实上,我们相信,对软件体系结构描述语言的研究过分强调功能和不够规范的全局属性和非功能性需求是如何实现体系结构。这些需求不能归因于单个组件或连接器,因此不可以指定当前的体系结构描述语言。分布式软件工程研究需要识别符号,设计方法和工具支持。研究需要提供方法,帮助软件工程师系统地推导软件架构,满足一组非功能性需求,克服目前所做的猜测。这包括支持的中间件来确定合适的中间件或组合手头的问题。此外,软件工程研究需要定义架构设计流程,能够减轻风险的选择错误的中间件或架构。这些过程需要依靠定量模型的性能和可伸缩性的方法一个特定middleware-based架构实现和使用验证技术,如模型检查、验证模型确实满足要求。需要校准的模型使用收集的指标,观察中间件性能在实践中。许多体系结构描述语言支持的连接器通过显式建模组件[40]沟通。 A main contribution of [11] is the observation that connectors are most often implemented using middleware primitives. We would like to add the observation that each middleware only supports a very limited set of connectors. Specifying the behaviour of connectors explicitly in an ADL is therefore modelling overkill that is only needed if architects opt out of using middleware at all. For most applications, the specification of each connector is completely unnecessary. Instead, software architecture research should develop middleware-oriented ADLs that have built-in sup-port for all connectors provided by the middleware that practitioners actually use. |
设计 |
| 在[13],我们认为,使用中间件的设计不是,永远不会,完全透明的设计师。有很多因素,尽管ISO / ODP透明度的维度,需要设计师意识到参与的中间件组件之间的通信。这些因素是: |
| ¯网络延迟意味着两个分布式组件之间的通信是通过数量级低于本地通信。 |
| ¯有状态组件的组件激活和停止导致需要实现持久性的这些组件。 |
| ¯组件需要设计,以便应对并发交互发生在分布式环境中。 |
| ¯组件可以选择不同的同步原语特定中间件提供,需要正确利用它们。特别是,他们必须避免死锁或活性问题可能出现的由于使用这些同步原语。 |
| 软件工程社区需要开发middleware-oriented设计符号,方法和工具,考虑到上述担忧。讨论上面的最先进的中间件的研究中,我们强调了这一趋势给程序员如何中间件的行为产生更大的影响。全球复制策略,道的调度策略和反射能力影响中间件执行引擎必须使用的设计师。有效的,这意味着,程序员可以看到更多的中间件和分布和异构性变得不那么透明。如果这确实是必要的,和中间件研究社区提出充分的理由,程序员必须帮助更多的分布式组件的设计。因此适当原则、符号的设计方法和工具复制策略、调度策略和使用反射能力需要从软件工程研究。 |
总结 |
| 我们已经讨论了为什么分布式系统的建设是困难的,表示支持,软件工程师可以从目前的中间件产品来简化任务。我们已经回顾了当前状态的艺术在中间件的研究和使用这些知识获得软件工程研究议程,将生产原则,符号,方法和工具来支持所有活动在一个软件工程的生命周期过程。 |
数据乍一看 |
 |
| 图1 |
|
引用 |
- j·贝茨。艺术的状态在分布式和可靠的计算。技术报告、实验室通信工程,剑桥大学,http://www.newcastle.research.ec.org/cabernet/sota/report, 10月。1998年。Int。Conf.分布式开放加工、德国柏林,第4卷,页341 - 352。北荷兰,1993年。
- p·a·伯恩斯坦诉Hadzilacos和n·古德曼。数据库系统的并发控制和恢复。艾迪生韦斯利,14卷,pp - 140 - 146, 1987。
- k·p·伯曼猫。建立安全可靠的网络应用程序。pp-20-29曼宁出版、卷7日,1997年。
- d .的盒子。必要的COM。朗文出版社,Vol18, pp - 121 - 127, 1998。
- j·查尔斯。中间件前沿移。IEEE计算机1999年5月,页17日- 19日。
- 张。Java事务服务(JTS)。Sun Microsystems,圣安东尼奥路901号,位于加州帕罗奥图的CA 94303年,卷2,pp-23-25 Mar.1999。
- p .钟y黄,s . Yajnik d .梁j . Shin彭译葶。王,Y.-M。王。DCOM和CORBA:并排,一步一步,层随层。c++的报告,January1998 pp ~ 29。
- p . Cointe编辑器。元级别架构和反射:¾O国际会议,反映99年,圣,法国,卷1616在计算机科学的课堂讲稿.Springer,卷2,pp-12-21, 1999年。
- a .达a van Lamswerde, Fickas。Goaldirected要求收购。科学的计算机编程,20:3-50卷,pp - 67 - 68, 1993。
- e di日本日东和d Rosenblum。利用ADLs指定建筑风格由中间件基础设施14卷,pp - 112 - 116,
- f . Eliassen a .安徒生g·s·布莱尔,f·科斯塔·g·库尔森,V。t . Kristensen Goebel O·汉森,t . Plagemann h . O。Rafaelsen, k B。Saikoski, w。下一代中间件:需求、体系结构和原型。在学报ØIEEE研讨会分布式计算系统的未来趋势,60 - 65页。IEEE计算机协会出版社,1999年12月。
- w·艾默里奇。工程分布式对象。约翰•威利父子公司pp-57-58, 2000年4月。
- w·艾默里奇a·芬克尔斯坦•施瓦兹(george w . bush)。标记与中间件。在ØInt。车间在分布式的未来趋势系统,开普敦,南非,页261 - 266。IEEE计算机协会出版社,1999年。
- FpML。引入FpML: e-commerce.http新标准:/ / www.fpml.org, 1999。
- l·吉尔曼和r .以下。与IBM MQSeries分布式计算。威利,Vol23 pp-12-18, 1996年。
- 戈德堡。smalltalk - 80:语言和它的实现。艾迪生韦斯利,Vol19 pp-32-34, 1985年。
- j . n .灰色。Notes数据库的操作系统。在r .拜耳,r·格雷厄姆和g Seegm¨ul,编辑,操作系统:一个高级课程,体积的60课堂讲稿n计算机科学章3. f。,页393 - 481。施普林格,1978年。
- c . l .大厅。构建客户机/服务器应用程序使用礼服.Wiley, 1996年。
- m . Hapner r·布里奇和r·沙玛。Java消息服务规范。技术报告,Sun Microsystems, http://java.sun.com/products/jms, pp-28-30 11月。1999年。
- 希利尔。微软事务服务器编程。微软出版社,页11 - 64 - 69卷,1998年。
- e . s . Hudders。CICS:内部结构指南。5卷,pp - 72 - 84,威利,1994年。
- 无穷。无限网络贸易概述http://www.infinity.com/ntm/pdf/ntmOverview.pdf, 1999年。
- ISO 10746 - 1。开放分布式处理参考模型。技术报告,国际标准化组织,1998年。[24]
- ISO 7498 - 1。在formation processing systems – Open Systems Interconnection – Basic Reference Model: The Basic Model. Technical report,International Standards Organisation, 1994.
- m . v . Steen p小礼帽,a . s . Tanenbaum。全球:广域分布式系统。IEEE并发,70 - 78页,January-March1999
- 雅各布森,g . Booch和j . Rumbaugh。的统一软件开发过程。艾迪生韦斯利,1999年。
- 雅各布森,m . Christerson p·琼森,g .¨gaard。面向对象的软件工程:一个用例驱动的方法。AddisonWesley,页1992 - 91 - 96。
- JavaSoft。Java远程方法调用规范修订1.50 jdk 1.2版,1998年10月。
- g . Kiczales j . d。Rivi怎样,d . g . Bobrow。元对象协议的艺术.MIT出版社,1991年。
- r . Monson-Haefel。Enterprise javabean。O ' reilly英国,第22卷,pp-32-37, 1999年。
- 公元前纽曼。在分布式系统。在t之家系统。pp-11-23 IEEE计算机协会出版社,卷13日,1994年。
- 对象管理组织。CORBAservices:公共对象服务规范,修订版。马492老康涅狄格路径,弗雷明汉,01701年,美国1998年12月
- 对象管理组织。通知服务。马492老康涅狄格路径,弗雷明汉,01701年,美国1月。1998年。
- 对象管理组织。公共对象请求代理:架构和规范修订2.2。马492老康涅狄格路径,弗雷明汉,01701年,美国1998年2月。
- 对象管理组织。XML /值要求的建议。马492老康涅狄格路径,弗雷明汉,01701年,美国,1999年8月。
- 开放组织,编辑器。DCE 1.1:远程过程调用。Open Group, 4卷,pp-14-20, 1997年
- r . Orfali d Harkey和j·爱德华兹。即时CORBA。威利,13卷,pp-12-14, 1997年。
- G.-C。罗马,a·l·墨菲,g . p .山顶。软件工程的角度对流动性。在a·c·w·芬克尔斯坦,编辑,的未来
- 吉尔·d·施密特,c和d·莱文。评估实时CORBA动态调度策略。在½Ø国际真正IEEE -次研讨会。IEEE计算机协会出版社,1998年
- m·肖和d . Garlan。软件架构:观点一个新兴学科.Prentice大厅,1996。
- j·西格尔。组件和对象技术:一个预览的CORBA 3。IEEE计算机1999年5月,页114 - 116。
- X / Open Group。分布式事务处理:XA +规范,版本2。X /开公司,ISBN 1-85912-046-6,阅读,英国8卷,pp-12-16, 1994年。
|
菜单
