J2EE应用的运行重构-外文翻译.doc

J2EE应用的运行重构亚斯明卡 玛特威斯卡-梅耶，萨沙 奥里格斯，威廉哈塞尔伯林计算机科学系，软件工程组，奥尔登堡大学，26121奥尔登堡，德国matevska-meyerinformatik.uni-oldenburg.de,olligesinformatik.uni-oldenburg.de,hasselbringinformatik.uni-oldenburg.de摘 要：改变运行系统的运行时重构，不仅在安全和关键任务系统方面起着提供高可用性的一个重要角色，而且对商业网络应用提供专业服务。据此，主要的关切点是维持在由重构时导致的在重新配置和最大限度地减少其停机期间运行系统的一致性。本文的重点是平台独立的，基于作为能够使基于组件系统运行重构的执行系统部署新的J2EE API 模块的子系统。我们的“控制运行时重新部署”包括以结构调整为允许补充的延伸热部署和动态刷新。关键词：基于组件的软件工程，部署，动态/自主重构/修改1 简介该软件系统的要求就必须永久改变其演变。业务流程在设计意在系统的在设计，变异的管理办法设计意在设计包括部署后的系统适应变化的系统。作为运行系统的必需的变化，运行时重构起着提供软件系统的高可用性具有重要作用。主要的关切点是维持在由重构时导致的在重新配置和最大限度地减少其停机期间运行系统的一致性。因此，决定了系统的某些部分将在重构停止和继续运行的技术是需要的，因此，该系统可继续进行重构1执行的部分。为了确定受影响的作为一个最小集合部分的组件，我们需要一个系统的描述，它提供了其运行时基本上是关于使用的组件的实例依赖关系2行为的一个信息。此外，我们必须能够重新组合在系统其运行期间。我们有关所谓重新部署的运行时重构的方法提供了一个控制运行时的热部署和动态刷新概念延伸3。此外，我们也考虑1运行系统的结构上相一致的变化。本文组织如下：首先，我们简要地介绍了我们的做法以使基于组件的系统在运行时重构（第3节），其次，我们提出一个系统架构（图2-1）。在2.1节我们提出了我们对J2EE部署的API 4的执行情况。最后，在第三节阐述我们进一步的工作的结论。2运行时启用基于组件的系统的重构我们关注作为一个运行着的系统必须的变化的基于组件系统的重构。我们通过重构的结果：（1）功能，（2）非功能性，（3）结构方面来区分三种不同的重构。所有类型的重组可以发生在不同的粒度级别（即，可满足整个系统或单个子组件）。功能重构包括对单个组件的功能变化，以及一个特定的子系统，甚至整个系统。非功能重构与质量有关的服务（QOS）的系统，可以影响单个组件（子系统）或架构。同时考虑结构重构，改变单一组件接口和不断变化的组件之间（一个系统的体系结构更改的依赖）。我们看到正在运行的系统会在一个个特定的时间间隔内接收重构请求直到重组完成。在已经部署和运行系统，我们用实体组成部分的依赖关系确定的时间限制，那种关系是由特定的结构依赖关系和特定的信息或派生组件协议约束实例使用的依赖关系。知道了所有可能受影响的组件的当前状态，以及他们未来的行为，我们可以排除过去的依存关系和未来的。这使我们能够建立一个最小的运行时依赖关系图匹配的特殊请求重构1。组件 组件描述活跃组件符合组件描述原子组件描述原子活跃组件容器组件实例服务组件连接器组件图2-1.C3元模型我们的元模型如图2-1，提出了一种综合描述该系统的静态结构和运行时的看法，从而使重组后的系统行为和其一致性检查和组成层次分解。对于这容器组件的重要延伸到建立该系统的部署和运行性能模型。一个容器提供了活动的组件运行环境。为了描述这种系统运行行为，我们使用自动影响服务。对于确定的重构的时间点，我们提出了一个重组的消息序列图，所谓生存序列图，因为他们可以表达生机和时间终结。最后，需要申请到已经部署和运行机制的变化通常会触发一个系统配置的变化，意味着重构后，系统会重建和重新部署，以取得一致。这里一个要解决主要的问题是组件运行管理中的依赖关系。我们的控制下运行时重新部署的概念提出了一种对热署和动态刷新概念延伸3。另外相对于前面提到的，我们允许运行系统的结构变化和只允许一个应用程序或单个组件在运行时既简单交换其他概念的管理一致性问题。2.1 J2EE部署API的实现软件的热重新部署在J2EE（Java 2企业版的软件组件）平台由J2EE产品供应商作为一个为组件开发者不断在运行环境中执行测试的可选功能而实施。因此，热重新部署和实际操作，可能是无效的现有用户会话。松动会话状态不是很关键在而调试和测试组件，对开发商没有问题。在生产系统，揭露他们的服务真正的用户，部署是一个时间和错误敏感的过程。而方案的正确性，只有部分被部署过程的影响，在处理部署问题时，时间是一个重要因素。在大多数情况下，维持生产系统的停机时间被认为是一个大问题，因为其他的业务流程依赖着系统可用性。部署API规范作为新的J2EE 1.4 5需要更进一步重新部署的概念，以对用户是透明从而允许它在生产系统中使用。在一个运行的系统没有使无效的会话情况下执行配置变化的可能会明显减少停机的时间。重构确认或忽略重构请求重构分析仪依赖管理 一致性管理器 重构组件用户重构/回滚报告更新参数重构许可/回滚请求图2-2 重构管理但是，没有任何J2EE应用服务器包括一个API规范的工作部署落实。我们的项目“部署的J2EE API实现”4开发了一个JBoss应用服务器API实现的技术基础。我们现在的工作在规格说明中标注是可选的，就是实施重新部署的功能。这种API执行的结果将会完整的集成到一个完整的系统使能在产品系统建立配置、部署、重构J2EE应用程序。我们将我们的系统取名为PIRMA（平台独立重构经理）,它是激活重构的请求。它包括以下四个一流水平：重构分析仪，依赖管理，一致性管理器和重构组件。我们的部署在J2EE API实现覆盖了重构基本功能，并为一致性管理提供了一个接口。2.1.1 执行部署的基本原则我们的项目利用了JBoss的拦截器堆栈技术的潜力，以支持重新部署。在JBoss服务器中每个J2EE组件被部署在一个容器管理的组成部分。该容器配置了一系列处理配置系统级的EJB组件拦截对象，它们分别是：事务划分，持久性，认证，授权、远程通信以及实例池选择链。其他的拦截器链的责任是调用这些路由，日志，并作为特别关心的问题是管理容器拦截关机操作。清洁关机拦截的责任是等待组件容器配置的完成，并拒绝再调用。我们计划使用类似的机制，支持透明的重新部署行动。新推出的拦截器可以让任何开创了新的交易完成但新的同步调用等待一些障碍的杰出调用。在容器中调用完成后该组件将被新版本组件取代。不同的是清洁关机拦截无视该行动的事务属性被调用，新的拦截器拦截了被配置为启动新的交易业务。因此，保证交易完成，没有配置变化而进行的交易运行。不用说，有这样的调动可以在配置更改一些限制。部署API规范指出，必须继续运行一个J2EE模块同样要成功地调动配置。但是，此限制可能会在一定程度上削弱。它应该是可能的支持结构的变化，以模块部分符合一定的要求。该组件的类型决定的标准组件来满足，因此组件着扮演是否是安全的结构性改变或不区分关键作用。会话bean类型EJB组件是由创建它们的客户端定义扩展。 EJB规范定义了两种这样的组件类型。一个有状态会话bean实例包含必须在方法和交易的保留的会话状态。会话bean容器有时需要转变beans的性能原因二级存储状态。这种转移称为钝化。作者把beans复活操作称为激活。为了支持这项工作，由会话Bean类型实现的该接口包含容器调用告知其钝化或激活一个组成部分的回调方法。它的实例有责任保证从一个使返回钝化方法的领域实现Java序列化存储。由于序列化的序列化类型的结构，有状态会话bean的依赖是不可靠的结构变化。无状态会话Bean组件类型不包含方法调用之间的对话状态。因此这种类型的bean实例是可互换的。由于在切换组件的版本时没有需要保存的状态信息，就不会有重新部署问题。另一方面，作为会话bean的客户端扩展，其结构是纳入自己的客户，因此一个无状态会话bean只能被由（不变）远程客户端引用的bean部署。这始终是本地EJB组件处理的情况（见第6.5章的EJB规范）。一个实体bean类型EJB组件是信息实体的面向对象的观点，就像一个人或一个账户，存储在数据库或现有企业应用程序。由于一个实体bean是一个位于其他地方的数据视图，它不包含任何状态。根据容器的配置也可能被缓存在应用服务器中，但在任何情形，这是保证该实体在当前交易完成提交后的修改写入到数据存储系统。在实体bean组件处理部署是发生的真正的问题是，当其结构的变化，在相关的持久性存储数据结构的时候也需要改变的。虽然这肯定是可能的，但这样的操作可能是一个长期运行而对用户透明系统在调动时不可接受的任务。一种可能的解决方案是备用数据存储与第一个数据库存储。备用数据存储，然后可用于持久性的实体的新版本。该数据存储交换机通过为实体的新版本配置完成新的资源管理器。如果EJB组件是由（不变）远程客户端引用，这又是不可能改变的EJB组件结构。消息驱动bean类型的组件有没有客户端可见的身份。一个消息驱动bean中没有会话状态的特定客户，但他们当然可能包含说明的客户端邮件处理有效的实例变量。然而，EJB规范指出，一个消息驱动Bean的所有实例，相当于一个消息因而可能会被发送到任何实例。作为一个消息驱动Bean是一个异步消息接收器，重新部署行动可能会暂时禁用邮件路由和交换相关的bean的定义。上述意见现在可以概括：是否有一个EJB组件是安全的结构性变化（即界面改性的区别），是否能够归结到（不变）远程客户持有，是否是含有引用会话状态。要检测一个组件是安全的配置改变（甚至取消），再一次拦截是可取的，这次截获的组成部分主接口是用来创建（EJBHome），查找和删除处理（存根）到EJB对象。2.1.2 相关研究JBoss的开源项目本身就以研究部署API实现开始。作为一个新的项目，目前的资源是不完整和不包括任何调动的支持。无论如何，该项目是更新非常频繁，一定会产生一些有趣的发展。另一个开源项目叫Ishmael，该工程研究Jonas J2EE服务器OBJ 04的执行情况。虽然该项目是在ObjectWeb的注册网站追溯到2002年10月，但仍然认为是alpha版本，不支持当前的服务器版本。看来这个项目的发展几乎停止。无论如何，在我们项目的J2EE部署API实现4追溯到2003年夏天段，有些设计决定是受Ishmael的源代码的影响。3 小结一个实现了在运行时允许在组件之间的依赖关系基于组件的系统重构的方法被提出了。我们使用一个元模型，描述了系统提供的运行时行为，也是我们高水平架构的重构管理器。图2-2，作为一个J2EE技术实现平台是就业。目前，我们的工作是为J2EE系统执行J2EE应用的运行时重构。这份文件的特殊重点介绍我们在实施一个使部署和重新部署的基于J2EE部署API的J2EE模块的子系统，。预测未来的工作包括在重构为一个特定的时间请求重构的最佳点的模拟方法的考虑。4 参考文献1 MATEVSKA - j的迈耶，哈塞尔伯林W.和REUSSNER“开发加快基于构件的运行时重构系统协议信息。”，在法律程序上的车间面向构件编程WCOP 2003年，德国达姆施塔特2003年7月。达姆施塔特技术大学。2 MATEVSKA - j的迈耶，哈塞尔伯林W.和REUSSNER，“软件体系结构描述支持部门的部署和系统运行时重构”，在法律程序上的车间面向构件编程WCOP 2004年，奥斯陆，挪威， 2004年6月。奥斯陆大学。3 IBM公司，/software/webservers/appserv/doc/v40，WebSphere应用服务器文档，2003年6月。4 OLLIGES南，部署的J2EE API实现，学生项目，奥尔登堡大学，德国，计算科学系，软件工程组，2004年1月。5 Sun微系统，/j2ee/，Java 2平台企业版规范，版本1.4，2003。 Runtime Reconfiguration of J2EE ApplicationsJasminka Matevska-Meyer, Sascha Olliges, Wilhelm HasselbringDepartment of Computing Science, Software Engineering Group, University of Oldenburg, 26121 Oldenburg, Germany matevska-meyerinformatik.uni-oldenburg.de,olligesinformatik.uni-oldenburg.de,hasselbringinformatik.uni-oldenburg.deABSTRACT: Runtime reconfiguration considered as “applying required changes to a running system” plays an important role for providing high availability not only of safety- and mission-critical systems, but also for commercial web-applications offering professional services. Hereby, the main concerns are maintaining the consistency of the running system during reconfiguration and minimizing its down-time caused by the reconfiguration. This paper focuses on the platform independent subsystem that realises deployment and redeployment of J2EE modules based on the new J2EE Deployment API as a part of the implementation of our proposed system architecture enabling runtime reconfiguration of component-based systems. Our “controlled runtime redeployment” comprises an extension of hot deployment and dynamic reloading, complemented by allowing for structural changes.KEY-WORDS: component-based software engineering, deployment, dynamic/autonomic reconfiguration/adaptation1 IntroductionThe permanent change of requirements on software systems necessitates their evolution. Reengineering approaches aim at a reasonable re-design of the system and variability management approaches concentrate on designing systems which include variation points for post-deployment system adaptation. Runtime reconfiguration as applying required changes to a running system plays an important role for providing high availability of software systems. Main issues are maintaining the consistency of the system during runtime reconfiguration and minimising its down-time caused by the reconfiguration. Due to that, techniques are required which determine the parts of the system to be halted during reconfiguration, and accordingly, the parts of the system which can continue execution during reconfiguration MAT 03:2. In order to identify those parts as a minimal set of affected components, we need a system description, which provides an information of its runtime behaviour basically concerning uses dependencies among instances of components MAT 03:3. Furthermore, we have to be able to re-compose the system during its runtime.Our approach to runtime reconfiguration concerning the deployment called controlled runtime redeployment presents an extension of the concepts of hot deployment and dynamic reloading IBM 03. Additionally, we consider consistent structural changes of the running system MAT 03:2. This paper is organised as follows. First, we briefly present our approach to enabling reconfiguration of component-based systems at runtime (Section 3); next, we propose a system architecture (Figure 1). In Section 2.1 we present our implementation of the J2EE Deployment API OLL 04. Finally, we conclude and indicate further work in Section 3.2 Enabling Reconfiguration of Component-Based Systems at RuntimeWe aim at reconfiguration of component-based systems at runtime as applying required changes to a running system. We distinguish between three different types of reconfiguration according to their reconfiguration effort: (1) functional, (2) nonfunctional, and (3) structural. All types of reconfiguration can occur on different levels of granularity (i.e., can address the entire system or a single sub-component). Functional reconfigurations include changes to the functionality of a single component as well as of a particular subsystem, even of the entire system. Nonfunctional reconfigurations are concerned with the quality of service (QoS) of the system and can affect single components (sub-systems) or the architecture. Structural reconfigurations consider both, changing the interface of a single component and changing dependencies among components (architectural changes of a system).We observe a running system at a particular time interval from receiving a reconfiguration request until reconfiguration completion. In an already deployed and running system we determine time-constrained use dependencies among instances of components, which are constrained by specified structural dependencies and specified or derived component protocol information. Knowing the current state of all possibly affected components, and their future behaviour, we can exclude past dependencies and late future ones. This allows us to build a minimal runtime dependency graph matching the particular reconfiguration request MAT 03:2.Figure 1. C3-Meta ModelOur meta-model in Figure 1, described in MAT 03:3 presents a Composite GAM 95 structural static and runtime view of the system, thus enabling hierarchical decomposition of the system behaviour and its consistency check and composition after reconfiguration.For this paper container components are the essential extension to establish modelling of deployment and runtime properties of the system. A container provides the runtime environment for the live components OMG 03, SUN 03 To describe the runtime behaviour of the system we use service effect automata (as specified in REU 03). For determining the reconfiguration point in time we propose a special extension of message sequence charts called live sequence charts DAM 01 because they can express liveliness and timing constraints.Finally, applying required changes to an already deployed and running system usually triggers changes in a system configuration and implies its reconstruction and redeployment to obtain a consistent system after reconfiguration. A major problem to be solved here is managing runtime dependencies among the components. Our concept of controlled runtime redeployment presents an extension of the concepts of hot deployment and dynamical reloading IBM 03. We additionally allow structural changes of the running system MAT 03:2 and manage consistency problems in contrast to both other concepts mentioned before, which only allow a simple swap of an application or a single component at runtime.2.1 Implementation of the J2EE Deployment APIHot redeployment of software components in the J2EE (Java 2 Enterprise Edition) platform is implemented by the J2EE product providers as an optional feature for component developers who continuously need to execute tests in a running environment. As a consequence, hot redeployment was and actually is an operation that potentially invalidates existing user sessions. This is no problem for developers, as loosing the session state is not critical while debugging and testing components. In productive systems, that expose their services to real users, deployment is a time- and error-sensitive process. While program correctness is only partially affected by the deployment process, time is an important factor when dealing with component deployment. In most cases, maintenance downtime of productive systems is considered a big problem because other business processes depend on the systems availability.The Deployment API specification SEA 03 introduced as a part of the new J2EE 1.4 specification SUN 03 takes the concept of redeployment one step further by specifying redeployment to be transparent to users thus allowing it to be used in productive systems. The possibility to perform configuration changes in a running system without invalidating running sessions will significantly reduce its downtime.Figure 2. Reconfiguration ManagerHowever, no J2EE application server includes a working implementation of the Deployment API specification yet. Our project “J2EE Deployment API Implementation” OLL 04 developed the technical basis for an API implementation for the JBoss Application Server. We now work on implementing the redeployment functionality which is marked optional in the specification. The resulting API implementation will then be integrated into a complete system enabling configuration, reconfiguration, deployment and redeployment of J2EE applications in production systems.We name our system PIRMA (Platform Independent Reconfiguration Manager). It is activated on reconfiguration requests. It consists of the following four top-level components MAT 03: Reconfiguration Analyser, Dependency Manager, Consistency Manager and Reconfigurator. Our implementation of the J2EE Deployment API covers the fundamental functionality of the reconfigurator and provides an interface to the consistency manager.2.1.1 Basic concepts of the Redeployment ImplementationOur project exploits the potentials of the JBoss interceptor stack technology STA 02 to support redeployment. In JBoss server each J2EE component is deployed inside a manageable container component. That container is configured with a chain of interceptor objects that handle the configurable system-level aspects of an EJB component which are: transaction demarcation, persistence, authentication, authorization and remote communication as well as instance pooling and optionally clustering. Other responsibilities of interceptors in these chains are invocation routing, logging and as a matter of particular interest an interceptor that manages container shutdown operations. The Clean Shutdown Interceptors responsibility is to wait for the completion of running invocations on the component container it is configured for and to deny further invocations. We plan to use a similar mechanism to support transparent redeployment operations. A newly introduced interceptor will let any outstanding invocation that started a new transaction complete while new invocations wait on some synchronization barrier. After invocation completion the component hosted in the container will be replaced with a new version. Unlike the Clean Shutdown Interceptor which ignores the transaction attribute of the operation to be invoked, the new interceptor has to intercept operations that are configured to start new transactions. Thus transactions are guaranteed to complete and no configuration change is performed while a transaction is running. Needless to say that there are some restrictions on the configuration changes allowed in such redeployments. The Deployment API specification states that the runtime configuration must remain the same for a J2EE module to be successfully redeployed. However, this restriction may be weakened to some extent. It should be possible to support structural changes to module parts that conform to certain requirements. The component type determines the criteria the component has to satisfy and therefore plays a key role in the distinction of whether the component is safe to structural change or not. Session bean type EJB components are by definition extensions of the client that created them. The EJB specification SUN 03:2 defines two types of such components. A stateful session bean instance contains conversational state that must be retained across methods and transactions. The session bean container sometimes needs to transfer the state of the hosted beans to secondary storage for performance reasons. This transfer is called passivation. The operation of bringing beans back to life is called activation. To support this, the interface implemented by the session bean types contains call-back methods that the container invokes to inform a component about its passivation or activation. Its the instances responsibility to ensure, that upon return from a call to the passivate method its fields are ready to be stored via Java serialization. As serialization depends on the serialized types structure, a stateful session bean is not safe to structural change. The stateless session bean component type contains no conversational state between method invocations. Therefore bean instances of this type are interchangeable. As there is no need to preserve state information when switching versions of the component this would be no problem to redeployment. On the other hand, as session beans are client extensions, their structure is incorporated into the client itself and therefore a stateless session bean may only be redeployed if it is not referenced by (unchanged) remote clients. This is always the case when dealing with local EJB components (see chapter 6.5 of the EJB specification SUN 03:2).An entity bean type EJB component is an object-oriented view of information entities, like a person or an account for example, that are stored in a database or an existing enterprise application. As an entity bean is a view on data located elsewhere, it contains no state