JBoss AS 5有哪些新功能？－采访JBoss CTO Sacha
程序员文章站
2022-05-15 11:34:13
...
DZone近期对Red Hat中间件CTO Sacha Labourey进行了一次关于即将发布的JBoss Application Server (AS) 5的采访。在这次采访中，Sacha讨论了新的微容器(Microcontainer )架构和即将发布的中间件服务更新，比如JBoss Messaging，JBoss Cache，事务监控引擎和JBoss DNA。他谈到了通过消息实现的JBoss ESB(企业服务总线)和Web service平台，以及Bill Burke的新的RESTEasy项目和重点指出了即将发布的Web Beans规格一些重要属性。最后，他说明了他对Glassfish和Spring应用平台的观点，展望了应用服务器市场的革新和在未来10年中市场的领导趋势。
下面是详细内容：
问：我们现在正在采访Red Hat中间件CTO Sacha Labourey，你能介绍一下自己，以及你近期在Red Hat的工作吗？
Sacha：大家好，欢迎来到瑞士。我非常高兴接受这次采访。我是JBoss的CTO。自从JBoss成为Red Hat的一个部分，我就和Craig Muzilla一同领导JBoss。我们正在Neuchatel，这是我出生的地方。我们很久以前就以这里为基地开始向欧洲推广JBoss。
问：首先问一个整个JBoss社区都想问的问题，什么时候我们才能看到正式的JBoss AS 5发布？
Sacha：很快。也许会在几周内发布，也许在几个月内。我们正在为多个candidates版本努力，我们很快就能GA了。我知道已经经过长久的等待，但是我相信这种等待是值得的。
问：现在重新架构一个应用服务器并不是一个简单的工作，尤其是象JBoss这样复杂的服务器。这次新的发布，准备了几乎三年，很多人都想问，准备这么久时间有没有非技术方面的原因？
Sacha：这是一个好问题。直觉上人们习惯于认为是由于J2EE spec问题，我们在实现J2EE spec方面花了多少时间？事实上，如果你仔细查看EJB3容器，我认为JBoss是第一个向市场提供EJB3实现的公司，所以在实现J2EE spec方面我们没有问题，企业服务很早就准备好了。我们主要在应用服务器的基础架构上花费了很多时间，几乎我们所有的工程师都在为建设一个新的微容器和把一些核心服务迁移到新一代现实中而努力。
比如消息服务架构，事务架构，以及微容器，也许我提到太多次微容器，但是这是新的产品中最大的一部分。而且，显然，我们扩展了JBoss代码数量，我们的需要管理更多复杂的逻辑，我们也不得不简化创建应用服务的方式，以及解模不同的组件来提供能大的灵活性。
我们的应用服务使用了非常独一无二的开发环境，使得我们的开发速度变慢了一些，但是这种方式让我们的应用服务器更加强大。
问：对于重新架构的主要技术挑战在哪里？
Sacha：开发环境和日益增加的复杂性是难点之一。我们主要的精力花在重新设计新的微容器。JBoss是最先在宏核心(microkernel)基础上提供应用服务的公司之一，微容器在很多方面是领先的，比如类加载，metadata，AOP(面向方面编程)，依赖注入，依赖跟踪等等。把所有的方面都做好是困难的。
问：你能整体介绍一下在JBoss AS 5中新的核心中间件服务吗？
Sacha：好的。首先我们把原来的服务进行了翻新。比如消息实现方式完全是新的，我们使用了一个JBoss MQ的工具，我们将迁移到JBoss Messaging。
JBoss Messaging非常棒，它具有执行效率非常高。你能在JBoss网站看到一些测试数据。如果你需要，我们提供了一些本地层集成，内部完全转换为java动作实现。
它是完全群集方式的。我们可以采用负载平衡方式或者失败重定向方式(failover)。我们有一个不同的方式来群集，基于JBoss缓存技术，也是我们在过去5年中同时使用JGroups来做应用服务群集。所有的东西都是基于这个通用层。
JBoss Messaging是一个真正的强大的消息服务，我不认为有任何开源的消息应用软件能够比得上它的强大功能和执行效率。
我们也加入了一个新的事务监控引擎作为应用服务器的一部分。如果你记得，2005年，我们同时从Arjuna和HP处收购了Arjuna 事务服务组件。
现在我们集成了这些组件作为应用服务器的一部分，这个事务引擎非常坚固，这是一个发展了超过20年的事务管理工具。它是第一个JTA和JTS事务管理商业实现，所以在事务管理方面，我们拥有强大的专业能力。我们事务引擎非常快，提供JTA和JTS行为，尤其对于银行系统来说，有了重大的改变。
在Web Services方面我们也做了很多修改。我们现实了全新的Web services架构，兼容EE 5.并且我们提供一个抽象层，你能灵活的嵌入不同的后台架构。
你也许需要Sun应用，Apache应用，将它们以插件形式嵌入后台，对于应用服务器没有任何影响。我们希望提供给用户*选择应用的权利。
修改的部分还有很多。
微容器同样带来配置应用服务器的不同方式。以前JBoss很简单用修改文件方式配置，但是如果你需要即时修改，并且不希望重启，这种方式要复杂的多。我们拥有两个完全一样的metadata应用服务器管理，你可以称之为profile服务，完全是插件形式，这个profile服务可以是一组文件，也能是数据库，或者JCR存储。通过统一的方式在一个节点或者JBoss群集中存储metadata，因此能快速提供JBoss实例。这个方式，与之相关的我们称为JBoss DNA，目标是创建一个完整的注册和存储机制，不光提供给应用服务器，也能提供给整个SOA平台支持。
问：AS 5有更多的支持RESTful 应用吗？
Sacha：当然。Bill Burke正在做一个叫RESTEasy项目，几周内就会发布详细spec，我们希望尽早实现这些spec。我们的目标是让开发者开发更简单，提升执行效率，RESTEasy项目会成为JBoss 5的一部分。
问：为什么我需要考虑使用JBoss ESB，而不是简单的在Web Service架构中使用JBoss Messaging？
Sacha：这是一个好问题。事实上，在过去的三年中，这两者的边界开始模糊。但是如果你需要灵活的微容器，比如 JMX微容器，OSGi 微容器，基于POJO的微容器，你需要JBoss ESB。对于企业服务来说，需要安全服务，事务服务，远程管理，消息服务等，这不是用简单的消息服务可以搞定的。
问：如果我不需要核心的服务，不需要群集和事务管理，那么一个单独的服务器容器比如Tomcat能胜任吗？
Sacha：我们提供对Tomcat单独支持。我们也有一些客户只是使用Tomcat作为服务器容器，效果不错。但是，我不建议这样做。当客户提出问题，我的典型回答是：“为什么不使用JBoss App Server呢？”JBoss App Server能提供最*的服务。
JBoss是Tomcat项目的最大捐助者，对我们而言，这是一个很重要的项目，并且Tomcat的代码整合进入了JBoss应用服务器。
问：在之前对JBoss架构是David Ward的采访中，他形容JBoss微容器为：一个IOC容器。现在和之前和热部署服务模型有什么不同？
Sacha：首先，之前的模型是良好的基于JMX，JMX是一个很好的spec，定义了一些我们今天必需的概念，但是它没有走的足够远。我认为它是第一个对于宏核心(microkernel)的优秀实现。但是如果你面对近年发展的需求，光JMX不够了，有些人需要OSGi，有些人需要JMX，有些人希望纯粹的依赖POJO。我们希望提供满足这些需求的解决方案。
在微容器中，你能够只有POJO，你也能映射个性化定制POJO类似于OSGi容器或者JMX。例如，一个Spring部署文件能够映射到JBoss POJO概念类加载器和metadata中。我们能够映射所有市场所需要的概念，并且在微容器中让他们运行。
标准非常重要，但是经常改变，所以，我们需要一个架构来定制和建设一个足够灵活的解决方案来满足不同的标准。这就是我们现在正在做的。
更多的，就如我之前所说的，我们在宏核心的顶端为应用和服务提供的恢复和重载metadata方案，就是为了获得足够的灵活性。
问：我们看到模块化服务架构正在更多被应用。OSGi被很多人认为是组件模型的实施选择，对于JBoss AS 5来说如何看待呢？
Sacha：首先，非常高兴看到整个市场这个方面的趋势。为什么是OSGi？为什么不是OSGi呢？我喜欢OSGi有一些基本的理由。它是标准的，我们喜欢开放标准。但是它对我们是否足够呢？答案是否定的。我们提供给用户的是一个超越OSGi的实现。
问：JSR 299或者Web Beans API将标准化JBoss所支持的模型，它混合了EJB3,JPA和JSF来提供一个广泛web应用架构。JSR将包括三个Java EE6 web 属性选项中的两个。Sacha，你认为Web Beans将如何改变应用最基本创建方式？
Sacha：我认为，Web Beans未来最重要的就是减少对使用JPS和JSF,JPA开发的方式的改变。EE对于市场规格来说已经足够长了。只要最基本的规格，每天大家都在用的企业概念就够了。但是你看一下他们集合EE spec的方式，比如J2EE 1.3或者1.4，只是一个小spec。我认为我们应该在集成spec方面做的更好。
对于EE开发来说，改进spec的底线应该是我们获得更高的生产力，更低的学习曲线。
问：你能展望一下应用服务器市场的未来吗？在未来5年到10年内，什么是成长最快的领域？比如提供企业应用托管服务？
Sacha：我认为事实上我们应该查看两个补充方面，一个方面，我们将看到企业运行runtime时的特殊需求。你也许需要集成应用或者系统，你也许需要开发一个新的应用等等，不管你需要什么，你能够通过菜单方式的进行选择组合，这是在灵活性方面。但是灵活性意味这更加复杂，这是我们希望避免的。我们要提供简单而强大的系统，这是中间件和操作系统厂商的发展方向。基于这种立场，JBoss强依赖操作系统，JBoss在windows，AIX，solaris,HP-UX等操作系统上运行。另外一个方面就是在开发上要简单。
操作系统市场存在超过40年，但还远说不上成熟，对于中间件市场更是如此，未来5－10年，JBoss会努力作出开创性的成绩。
问：对于应用服务器现在有三个选择：Glassfish，Spring和JBoss，如果站在中立的角度来说，你希望给挑选者什么样的建议呢？
Sacha：简单，结论就是选择JBoss (笑)。
首先Glassfish，我不得不说最近几年Sun的工作很不错。如果查看Sun整个应用服务器的发展历史，他们发布太多的版本，有太多的bug。Glassfish本身也是一个不太成熟的软件。
其次SpringSource，先说一说Spring框架，这是一个轻量级的解决方案。Spring框架非常成功，很多公司使用，并且也获得了不错的口碑。我看到Spring运行在JBoss上，Spring运行在WebSphere上，Spring运行在Weblogic上等等。我们很高兴看到Spring在JBoss上运行。但是对于Spring 应用服务器来说，首先他们进入这个领域太晚了，在6年前，这个市场有20到25家不同的厂商，现在只剩下4到5家。所以，事实上SpringSource决定如此晚进入这个领域是个大挑战。
我认为对于用户来说，应用服务器性能的强大是最重要的，对吗？提供一个好的框架是一回事，提供一个强大而强壮的企业级应用又是另外一件事情，后者需要多年艰苦的努力，不是短期能达到的。
问：Sacha，最后向大家说几句吧。
Sacha：欢迎大家来访问JBoss.org社区，欢迎加入我们。
下面是详细内容：
问：我们现在正在采访Red Hat中间件CTO Sacha Labourey，你能介绍一下自己，以及你近期在Red Hat的工作吗？
Sacha：大家好，欢迎来到瑞士。我非常高兴接受这次采访。我是JBoss的CTO。自从JBoss成为Red Hat的一个部分，我就和Craig Muzilla一同领导JBoss。我们正在Neuchatel，这是我出生的地方。我们很久以前就以这里为基地开始向欧洲推广JBoss。
问：首先问一个整个JBoss社区都想问的问题，什么时候我们才能看到正式的JBoss AS 5发布？
Sacha：很快。也许会在几周内发布，也许在几个月内。我们正在为多个candidates版本努力，我们很快就能GA了。我知道已经经过长久的等待，但是我相信这种等待是值得的。
问：现在重新架构一个应用服务器并不是一个简单的工作，尤其是象JBoss这样复杂的服务器。这次新的发布，准备了几乎三年，很多人都想问，准备这么久时间有没有非技术方面的原因？
Sacha：这是一个好问题。直觉上人们习惯于认为是由于J2EE spec问题，我们在实现J2EE spec方面花了多少时间？事实上，如果你仔细查看EJB3容器，我认为JBoss是第一个向市场提供EJB3实现的公司，所以在实现J2EE spec方面我们没有问题，企业服务很早就准备好了。我们主要在应用服务器的基础架构上花费了很多时间，几乎我们所有的工程师都在为建设一个新的微容器和把一些核心服务迁移到新一代现实中而努力。
比如消息服务架构，事务架构，以及微容器，也许我提到太多次微容器，但是这是新的产品中最大的一部分。而且，显然，我们扩展了JBoss代码数量，我们的需要管理更多复杂的逻辑，我们也不得不简化创建应用服务的方式，以及解模不同的组件来提供能大的灵活性。
我们的应用服务使用了非常独一无二的开发环境，使得我们的开发速度变慢了一些，但是这种方式让我们的应用服务器更加强大。
问：对于重新架构的主要技术挑战在哪里？
Sacha：开发环境和日益增加的复杂性是难点之一。我们主要的精力花在重新设计新的微容器。JBoss是最先在宏核心(microkernel)基础上提供应用服务的公司之一，微容器在很多方面是领先的，比如类加载，metadata，AOP(面向方面编程)，依赖注入，依赖跟踪等等。把所有的方面都做好是困难的。
问：你能整体介绍一下在JBoss AS 5中新的核心中间件服务吗？
Sacha：好的。首先我们把原来的服务进行了翻新。比如消息实现方式完全是新的，我们使用了一个JBoss MQ的工具，我们将迁移到JBoss Messaging。
JBoss Messaging非常棒，它具有执行效率非常高。你能在JBoss网站看到一些测试数据。如果你需要，我们提供了一些本地层集成，内部完全转换为java动作实现。
它是完全群集方式的。我们可以采用负载平衡方式或者失败重定向方式(failover)。我们有一个不同的方式来群集，基于JBoss缓存技术，也是我们在过去5年中同时使用JGroups来做应用服务群集。所有的东西都是基于这个通用层。
JBoss Messaging是一个真正的强大的消息服务，我不认为有任何开源的消息应用软件能够比得上它的强大功能和执行效率。
我们也加入了一个新的事务监控引擎作为应用服务器的一部分。如果你记得，2005年，我们同时从Arjuna和HP处收购了Arjuna 事务服务组件。
现在我们集成了这些组件作为应用服务器的一部分，这个事务引擎非常坚固，这是一个发展了超过20年的事务管理工具。它是第一个JTA和JTS事务管理商业实现，所以在事务管理方面，我们拥有强大的专业能力。我们事务引擎非常快，提供JTA和JTS行为，尤其对于银行系统来说，有了重大的改变。
在Web Services方面我们也做了很多修改。我们现实了全新的Web services架构，兼容EE 5.并且我们提供一个抽象层，你能灵活的嵌入不同的后台架构。
你也许需要Sun应用，Apache应用，将它们以插件形式嵌入后台，对于应用服务器没有任何影响。我们希望提供给用户*选择应用的权利。
修改的部分还有很多。
微容器同样带来配置应用服务器的不同方式。以前JBoss很简单用修改文件方式配置，但是如果你需要即时修改，并且不希望重启，这种方式要复杂的多。我们拥有两个完全一样的metadata应用服务器管理，你可以称之为profile服务，完全是插件形式，这个profile服务可以是一组文件，也能是数据库，或者JCR存储。通过统一的方式在一个节点或者JBoss群集中存储metadata，因此能快速提供JBoss实例。这个方式，与之相关的我们称为JBoss DNA，目标是创建一个完整的注册和存储机制，不光提供给应用服务器，也能提供给整个SOA平台支持。
问：AS 5有更多的支持RESTful 应用吗？
Sacha：当然。Bill Burke正在做一个叫RESTEasy项目，几周内就会发布详细spec，我们希望尽早实现这些spec。我们的目标是让开发者开发更简单，提升执行效率，RESTEasy项目会成为JBoss 5的一部分。
问：为什么我需要考虑使用JBoss ESB，而不是简单的在Web Service架构中使用JBoss Messaging？
Sacha：这是一个好问题。事实上，在过去的三年中，这两者的边界开始模糊。但是如果你需要灵活的微容器，比如 JMX微容器，OSGi 微容器，基于POJO的微容器，你需要JBoss ESB。对于企业服务来说，需要安全服务，事务服务，远程管理，消息服务等，这不是用简单的消息服务可以搞定的。
问：如果我不需要核心的服务，不需要群集和事务管理，那么一个单独的服务器容器比如Tomcat能胜任吗？
Sacha：我们提供对Tomcat单独支持。我们也有一些客户只是使用Tomcat作为服务器容器，效果不错。但是，我不建议这样做。当客户提出问题，我的典型回答是：“为什么不使用JBoss App Server呢？”JBoss App Server能提供最*的服务。
JBoss是Tomcat项目的最大捐助者，对我们而言，这是一个很重要的项目，并且Tomcat的代码整合进入了JBoss应用服务器。
问：在之前对JBoss架构是David Ward的采访中，他形容JBoss微容器为：一个IOC容器。现在和之前和热部署服务模型有什么不同？
Sacha：首先，之前的模型是良好的基于JMX，JMX是一个很好的spec，定义了一些我们今天必需的概念，但是它没有走的足够远。我认为它是第一个对于宏核心(microkernel)的优秀实现。但是如果你面对近年发展的需求，光JMX不够了，有些人需要OSGi，有些人需要JMX，有些人希望纯粹的依赖POJO。我们希望提供满足这些需求的解决方案。
在微容器中，你能够只有POJO，你也能映射个性化定制POJO类似于OSGi容器或者JMX。例如，一个Spring部署文件能够映射到JBoss POJO概念类加载器和metadata中。我们能够映射所有市场所需要的概念，并且在微容器中让他们运行。
标准非常重要，但是经常改变，所以，我们需要一个架构来定制和建设一个足够灵活的解决方案来满足不同的标准。这就是我们现在正在做的。
更多的，就如我之前所说的，我们在宏核心的顶端为应用和服务提供的恢复和重载metadata方案，就是为了获得足够的灵活性。
问：我们看到模块化服务架构正在更多被应用。OSGi被很多人认为是组件模型的实施选择，对于JBoss AS 5来说如何看待呢？
Sacha：首先，非常高兴看到整个市场这个方面的趋势。为什么是OSGi？为什么不是OSGi呢？我喜欢OSGi有一些基本的理由。它是标准的，我们喜欢开放标准。但是它对我们是否足够呢？答案是否定的。我们提供给用户的是一个超越OSGi的实现。
问：JSR 299或者Web Beans API将标准化JBoss所支持的模型，它混合了EJB3,JPA和JSF来提供一个广泛web应用架构。JSR将包括三个Java EE6 web 属性选项中的两个。Sacha，你认为Web Beans将如何改变应用最基本创建方式？
Sacha：我认为，Web Beans未来最重要的就是减少对使用JPS和JSF,JPA开发的方式的改变。EE对于市场规格来说已经足够长了。只要最基本的规格，每天大家都在用的企业概念就够了。但是你看一下他们集合EE spec的方式，比如J2EE 1.3或者1.4，只是一个小spec。我认为我们应该在集成spec方面做的更好。
对于EE开发来说，改进spec的底线应该是我们获得更高的生产力，更低的学习曲线。
问：你能展望一下应用服务器市场的未来吗？在未来5年到10年内，什么是成长最快的领域？比如提供企业应用托管服务？
Sacha：我认为事实上我们应该查看两个补充方面，一个方面，我们将看到企业运行runtime时的特殊需求。你也许需要集成应用或者系统，你也许需要开发一个新的应用等等，不管你需要什么，你能够通过菜单方式的进行选择组合，这是在灵活性方面。但是灵活性意味这更加复杂，这是我们希望避免的。我们要提供简单而强大的系统，这是中间件和操作系统厂商的发展方向。基于这种立场，JBoss强依赖操作系统，JBoss在windows，AIX，solaris,HP-UX等操作系统上运行。另外一个方面就是在开发上要简单。
操作系统市场存在超过40年，但还远说不上成熟，对于中间件市场更是如此，未来5－10年，JBoss会努力作出开创性的成绩。
问：对于应用服务器现在有三个选择：Glassfish，Spring和JBoss，如果站在中立的角度来说，你希望给挑选者什么样的建议呢？
Sacha：简单，结论就是选择JBoss (笑)。
首先Glassfish，我不得不说最近几年Sun的工作很不错。如果查看Sun整个应用服务器的发展历史，他们发布太多的版本，有太多的bug。Glassfish本身也是一个不太成熟的软件。
其次SpringSource，先说一说Spring框架，这是一个轻量级的解决方案。Spring框架非常成功，很多公司使用，并且也获得了不错的口碑。我看到Spring运行在JBoss上，Spring运行在WebSphere上，Spring运行在Weblogic上等等。我们很高兴看到Spring在JBoss上运行。但是对于Spring 应用服务器来说，首先他们进入这个领域太晚了，在6年前，这个市场有20到25家不同的厂商，现在只剩下4到5家。所以，事实上SpringSource决定如此晚进入这个领域是个大挑战。
我认为对于用户来说，应用服务器性能的强大是最重要的，对吗？提供一个好的框架是一回事，提供一个强大而强壮的企业级应用又是另外一件事情，后者需要多年艰苦的努力，不是短期能达到的。
问：Sacha，最后向大家说几句吧。
Sacha：欢迎大家来访问JBoss.org社区，欢迎加入我们。
上一篇： Java 8 之 流（Stream）
下一篇： Python读取yaml文件多层菜单