今天，我阅读了《软件构架实践》16-19章，也就是全书的最后4章。
第16章主要介绍了Sun Microsystems的Java 2Enterprise Edition（J2EE）的架构规范，同时介绍了该规范的重要组成部分—Enterprise JavaBeans（EJB）。对以Java语言编写的分布式面向对象程序，以及各种Java组件可以如何进行通信和交互，J2EE提供了一个标准的描述。EJB描述了服务器端基于组件的编程模型。作为一个整体，J2EE还描述了各种企业范围的服务。最后，它描述了厂商需要如何为应用程序构建者提供基础结构服务，以使得在与标准一致的情况下，所得到的应用可以移植到所有的J2EE平台上。
J2EE/EJB的规范在不断地扩展，当前已有的服务包括：事务、安全性、命名、持久性和资源管理。这些服务能够使J2EE/EJB应用的程序员从低层的分布式细节中解脱出来，从而将精力放在业务逻辑的开发上。J2EE/EJB通过使用一种通用的可移植性的语言并拥有组件间精确地契约，获得了可移植性。它通过一些机制获得了性能和性能可扩充性，这些机制包括：将应用分布给多个处理器（横向扩充）、无状态会话bean和资源池。
第17章主要介绍了Luther构架。设计Luther的目的是提供一个通用的构架，以使Inmedius能够在此框架内为其客户的维护问题提供定制的解决方案。它基于J2EE构架，因此，这就成了一个通用的J2EE/EJB框架在下述环境下的应用：最终用户通过无线网连接，并且有一个具有有限输入/输出能力和有限计算能力的设备。
Luther是Inmedius构造用于支持客户支持系统的快速构建的解决方案。它基于J2EE。我们已经投入大量的精力来开发可重用的组件以及简化各部分功能添加的框架，而且其用户接口设计用于支持基于客户和基于浏览器的解决方案。
第18章主要介绍了用商业组件构建系统，对于用商业组件构建的系统，组件选择涉及一个发现过程，该过程确定兼容组件的“装配”，理解如何实现所期望的质量属性，并确定是否可以将它们集成到所构建的系统中。
可以维持系统中的质量属性，即使该系统主要是用其设计和交互机制不在设计师的掌握之下的商业组件的构建也是如此。然而，在这种类型的系统中实现质量属性的要求的实践与制定开发的代码有很大不同。需求过程需要更加灵活，允许在市场中可以获得的产品修改需求，从而提供一个更加的总体业务方案。需要确定基本需求，并在可行组件整体的评估中将其作为一个关键的限制引入。需要考虑多个偶然事件，因为基本需求的数量会增多，难度会加大，因此必须将定制开发考虑成一种fallback。
第19章介绍了软件构架的研究和实践会向什么方向发展？同别人相比，我们也不具有超凡的洞察力。但我们将对未来做出预测。除了将来抽象的程度会更高、用以构成系统组件的构件将更为复杂外，我们对构架的未来发展做如下两大预测：
首先，编程和软件工程的区别在于编程是满足某一个人、某一个版本的软件的需要，如果期望别人也来看看所开发的系统，就需要采用软件工程技术来满足这些人的需要。构架也正是如此。如果我们所关心的仅仅是得到某个正确的结果，采用微不足道的单一构架就足矣。当人的问题—使系统能够良好的运转、在成本限制内构建系统、实现期望的收益、使各小组能够协调地共同完成系统的开发、帮助维护人员顺利地进行维护、使得涉众理解该系统—暴露出来是，就得采用某个构架了。