Java EE 8终于给出即将完成的迹象

Java EE 8终于给出即将完成的迹象。Oracle在近期的博客帖子中,更新了Java社区中Java EE 8的相关活动情况,其中给出了最新的发表时间表:

  • 公开评审(Public Review):2017年4月或5月间;
  • 提议最终草案(Proposed Final Draft):2017年六月;
  • 最终发布(Final Release):2017年七月。

2017年2月21日,Java EE规范牵头人(spec lead)Linda DeMichielJSR 366(即Java EE 8)的各位专家发了一封电子邮件,信中介绍了为最终完成Java EE 8的发布,作为规范牵头人是如何严格遵照时间表去完成JSR的。要点包括:

由于Oracle最近转让了实现“MVC 1.0”规范JSR 371)的牵头责任,因此在Java EE 8中将不包括该JSR。

IBM的Java EE架构师Kevin Sutter在给DeMichiel的一封电子邮件中,询问了Servlet 4.0需要ALPN这一问题将如何解决。ALPN(应用层协议协商,Application-Layer Protocol Negotiation)是一个TLS扩展,其中包括了“问候”消息交换中的协议协商,计划在Java SE 9中加入。DeMichiel是这样回答的:

我知道有人曾提出将该支持(或至少是所需的API)向后移植到Java SE 8中,只是我尚未看到任何书面内容。但是我们还是必须要去推动它,虽然当前的规范自提出后就被破坏了。

完成Java EE 8绝非易事。在过去的一年中,对于Oracle完成Java EE 8的承诺得到了广泛的关注。在2013年发布Java EE 7之后的一段时间内,Oracle对Java EE 8规划的表现出了十足的热情。当年的JavaOne大会主题就定为“给Java一个未来”。Oracle在2013年11月的博客帖子中是这样说的:

在发布Java EE 7和GlassFish Server Open Source Edition 4之后,我们开始规划Java EE 8路线图,并通过JavaOne Strategy的主题演讲进行了宣讲。总而言之,我们的兴趣主要集中在改进对HTML5的支持、云计算,以及调查对NoSQL的支持等方面。对于大家想在Java EE 8中看到的改进,社区和客户为我们提供了一些很棒的反馈。

简单的说,Oracle对Java EE的未来做出了承诺。Java EE 7已正式发布,有关Java EE 8的规划工作也已开始。

也正是在同一博客帖子中,Oracle宣布对Oracle GlassFish Server的商业支持做出了关键更改:

对于Oracle GlassFish Server,Oracle将不再进一步发布提供商业支持的主版本,即不再发布Java EE 7支持的Oracle GlassFish Server 4.x。

Oracle建议现有的Oracle GlassFish Server客户启动向Oracle WebLogic Server迁移的规划,这是一个技术和新许可的自然前向迁移路径。

Oracle将继续提供对GlassFish Server Open Source版的支持。

新的Java EE 8规范(JSR 366)于2014年9月构建,其中提出了最初的发布计划:

  • 组成专家组(Expert Group):2014年第三季度;
  • 早期草案(Early Draft):2015年第一季度;
  • 公开评审:2015年第三季度;
  • 提议最终草案:2015年第四季度;
  • 最终发布:2016年第三季度。

但是从那时起,Oracle的热情看上去有所减退。2015年6月,Oracle通过博客帖子更新了Java社区状态:

我们为自己的设置的目标是在JavaOne 2016旧金山大会前完成该项工作。虽然以JavaOne大会为平台发布重大事宜是我们所喜闻乐见的,但是在组建专家组中的各种延迟以及对我们规范牵头人在时间上的其它要求,已经导致发布日期稍向后延。我们会严格遵守对于Java EE平台工作透明度所做出的承诺。这里我们公开宣称,现在更改工作完成的目标时间期限为2017年上半年。

这一推迟直接导致前Oracle布道者Reza Rahman组建了一个称为“Java EE守护者”社区组织,目标是让一切恢复正轨。正如InfoQ在2016年6月所报道的:

随着去年Oracle对Java布道者进行裁员,以及更早前宣布将暂时停止继续为GlassFish Server发布大型版本更新并对相关支持进行限制,一群Java标准的支持者开始以“Java EE守护者”的身份自居,并通过一个章程宣告他们将努力拯救Java EE。

Java EE守护者是名副其实的Java权威人士,其成员包括“Java之父”James Gosling、前任技术传教士Reza Rahman,以及其他很多知名的Java技术人员。

几乎与此同时,另一个称为“MicroProfile”的新组织也成立了,其中集合了Red HatIBMTomitribePayara等企业,组织的章程是“借助Java EE技术创建独立于软件企业的微服务框架”,目标是在2016年12月发布一个最初的版本。

看上去,Java EE守护者和MicroProfile社区的各项工作已引起了Oracle的关注。正如2016年7月InfoWorld所报道的:

退一步说,Oracle意在使未来的Java提供云端支持。

有谣言称Java EE计划已被Oracle置于次要的位置,这引发了一场对Oracle管理组织Java EE不满的风暴,已有两个独立的组织考虑规划脱离Oracle推进Java EE。Oracle的高层对近期的批评声音给出了反馈,声称Oracle并非是想让Java萎缩,而是在考虑如何重启该平台以更好地适合企业的发展方向,尤其是在云端,

InfoQ在2016年8月曾做出报道

在最近的一次采访中,Oracle产品开发总裁Thomas Kurian宣布了Java EE 8的一系列改进。此举被认为是为了平息近期的批评(比如那些来自Java EE守护者的批评)和工作分歧(如MicroProfile)。目前的信息还很少,更多细节会在JavaOne 2016大会上公布。

Java开发社区越来越担心Java EE的未来发展。此前,在今年5月,JCP执行委员会曾考虑向Oracle发出正式申请,要求他们针对其Java EE承诺和计划作出公开答复。虽然在会议时记录了下来,但该申请未获批准。实际上,它变成了一份非正式的申请。之后大约一个月,Java EE守护者们提交了一份change.org请愿书,希望以此激励Oracle,让他们不要把Java EE搞砸了。截至目前,签名者已达3300人。

在2016年9月,Oracle给出了对JCP执行委员会(Executive Committee)的工作策略。InfoQ对此做出了报道

Anil Gaur是Oracle集团负责Java EE和WebLogic Server的副总裁。他受邀在上一次的JCP执行委员会会议上发表了演讲,透露了有关Java EE未来发展的一些信息。他所传达的信息和Oracle之前的说法一致:企业编程正在发生变化,Oracle希望适应这种变化。然而,执行委员会成员后续的提问突出了Oracle计划里的缺陷。

大约六个周之前,在Oracle产品开发总裁Thomas Kurian就有关Java EE的话题接受了采访之后,我们很明显可以知道,Oracle正在制定一个可以将Java EE带回正轨的方案。就是在这种背景下,8月9日,Gaur在最近的JCP EC会议上口头介绍了Oracle的Java EE策略。Gaur在演讲中表示,Oracle知道企业编程正在发生什么变化,采用分布式架构的应用程序越来越多。为此,Gaur重点介绍了若干有望添加到Java EE 8的技术,以便为开发人员带来实实在在的好处。他提供了一个技术列表,听上去和Kurian在采访中所给出的列表非常相似:HTTP/2、配置、状态管理、最终一致性、多租户、O-Auth和OpenID连接。不过,在提问环节,IBM运行时技术项目负责人Steve Wallin对于在短时间内实现这样一项革命性的变革提出了质疑。同时,他申明,IBM已经通过自己的努力在当前的Java EE平台上实现了快速云部署(可能是指Bluemix)。

不过,或许他没提供的信息才是最有趣的。在口头介绍结束后,执行委员会成员进行了提问,以期更好地了解Oracle的计划,其中有一个问题是,新版本什么时候可用。Gaur承认,Java EE 8的交付日期会“变化”,但没有提供更多的细节。不过,有迹象表明,部分新功能可能会基于Java SE 9,那意味着需要延期很长的时间。

JavaOne 2016大会披露出为添加对微服务和云端应用的支持,Java EE 8的发布将进一步推迟到2017年底。计划中还包括将于一年后发布Java EE 9。

也是在JavaOne 2016大会期间,据《Register》报道

为适合开发和部署中的盛行做法,目前有10个Java EE 8的项目正经历“主要改进”。这一修订工作将会影响到Bean Validation、CDI、JAX-RS、JSF、JSON-P和Servlet。

Oracle并未给出Java EE 8最近一次推迟的原因,但是很多人揪住了Oracle在今年的开发过程中擅离职守这一把柄。工程师和规范牵头人并未提供与Java社区其他成员的交流,他们的代码提交数也显著的下降。Oracle被迫站出来发布一个声明,坚称它依然会负起Java的责任。

Java EE 8将支持以下特性:分布式数据流、HTTP/2、键值对,使用OAuth和OpenID Connect系统管理密钥的一种标准方法、支持Docker在任一单个容器中打包一个以上物件(Artifact)、统一的事件模型、服务中事务和多租用管理的一致性。

为简化编码,将在Java EE 9中引入Java SE 8的Lambda。在Java EE 8中没有实现的特性也将会滚动到Java EE 9中。

Oracle正就社区成员想要在Java EE 9中看到的特性征求意见。

Oracle继续鼓励开发人员对JSR工作做出贡献,为此他们发布了第二次“采纳JSR”(Adopt-a-JSR)网络广播

Gartner

Gartner在2016年11月发布的一份报告中,预测了Java EE将会消亡。在报告的摘要中指出:

数字信息业务要求应用平台提供新的特性和能力。由于Java EE以及类似于ASP.NET这样的三层框架却没有赶上这趟车,应用负责人必须构建策略迁移到支持云端原生应用的候选平台。

该报告引发了一场争议,一些著名的Java技术领袖也参与其中,包括Reza RahmanKito MannJosh JuneauRyan Cuprak等人。

Java EE软件企业

一些在企业自身的开发中使用了核心Java EE规范的软件厂商,例如Red HatPivotal等,被迫对Java EE 8的延期寻求变通方案。正如InfoQ在2016年7月所报道,在Servlet 4.0 API中将不会包括发布Spring 5。当Pivotal的Spring Data项目负责人Oliver Gierke接受JAXenter采访时,他是这样解释的:

对我们而言,Java EE 8中最重要的部分在于Servlet 4.0 API及其对HTTP 2.0的支持。某种程度上,可以预见的是在我们最终正式发布Spring 5之前,一切都尚无定论,我们目前正在与最主要的Servlet容器实现者(Tomcat、Jetty、Undertow)密切合作,以确保我们能在第一时间使用由他们所提供的原生API,实现对HTTP 2.0的支持。

Red Hat的JBoss EAP平台架构师Jason Greene在2016年10月接受了InfoQ的采访。当被问及Java EE 8和Java 9的推迟是否会应用影响到WildFlyWildFly SwarmJBoss EAP的进一步开发时,他解释说:

WildFly和JBoss EAP已经远远超越了EE标准,并在进行继续完善。当某一规范的开发出现延误后,我们会将精力专注于其他感兴趣的领域。话虽如此,我们依然希望整个标准能够跟上业界发展步伐,因此我们很乐意与MicroProfile开发领域的其他重量级选手进行合作。

相关资源

查看英文原文: Light at the End of the Long Tunnel for Java EE 8

该文章由WP-AutoPost插件自动采集发布

原文地址:http://www.infoq.com/cn/news/2017/04/long-road-for-java-ee-8?utm_source=news_about_java&utm_medium=link&utm_campaign=java

聊聊 Tomcat 的单机多实例

Tomcat 从何而来?

先说 Tomcat 这一单词解释,如果你不是一个开发者,当然它在美国口语中并非是褒义词;如果你是开发者,那你一定听过 Web 应用服务器、Sun 公司和 Tomcat 。如你所知道那样,牛逼的公司总是推动这个世界的发展,并建立一个又一个标准,当然,在软件界 Sun 公司绝对算牛逼中的其一。
在贵的离谱的商用服务器充斥着市场的时候,Sun 公司推出了第一个 Java servlet container(Servlet 容器) 名字叫:Java Web Server(JWS),物美价廉,这简直是业界的一股清流,但市场并没有像他们想象的那么喜欢 JWS,一家商业公司如果产品卖不出去,那真是令人极其伤感的,但对于 Sun 公司来说这不重要,因为他们是 Java servlet 这个最初的标准的制定者,应该没有什么比这个更令人兴奋的了。随着标准的推出,直接推动了当时许多自由的、免费的 Java servlet container 的出现,像 Jetty 、JServ 等这些容器,好像所有人都喜欢免费,当然同时期还有一些商用的如 WebLogic 、JRun 这些容器存在。到这里好像还并没有出现 Tomcat ,别着急,Sun 公司其实比你更着急,因为 JSP 还没有出现。
可能由于 Sun 公司在 Servlet 容器市场的低迷表现,他们转头又愤而推出了迷你型 servlet coutainer 并支持 Web 的工具包,他们称之为 JavaServer Pages(JSP),这个工具包(JSDK)任何人都可以下载,接着随着 Sun 接着制定了新版的 JSP 规范,JSDK 也升级到了 2.1 版本后,注意,这时候大神出现了。在 Sun 公司上班的 James Duncan Davidson 没有使用任何原来代码的情况下写出了一个全新的 servlet contaniner ,从此取代了 JSDK 2.1 版本,因次这也是为什么 Tomcat 的版本是从 3.0 开始的而不是 1.0 。
当然,接下来的加入 Apache 基金会和开源也算是 Sun 公司为软件界的贡献,这其中肯定有商业上的考虑,但你何必在意呢。

Tomcat 的基本组成

了解一个事物的本质是现在就用它。不废话,直接先说一下 Tomcat 的安装和使用,之前写过 Tomcat 在 CentOS 、Windows 和配合 Nginx 在做负载均衡这三篇文章,用到的可以简单看下:

安装好之后,进入安装目录看一眼结构:

Tomcat 目录

简单介绍一下各个文件夹及文件:

  • bin:主要存放脚本文件,例如比较常用的windows和linux系统中启动和关闭脚本
  • conf:主要存放配置文件,其中最重要的两个配置文件是server.xml和web.xml
  • lib:主要存放tomcat运行所依赖的包
  • LICENSE:版权许可证,软件版权信息及使用范围等信息
  • logs:主要存放运行时产生的日志文件,例如catalina.out(曾经掉过一个大坑)、catalina.{date}.log等
  • NOTICE:通知信息,一些软件的所属信息和地址什么的
  • RELEASE-NOTES:发布说明,包含一些版本升级功能点
  • RUNNING.txt:运行说明,必需的运行环境等信息
  • temp:存放tomcat运行时产生的临时文件,例如开启了hibernate缓存的应用程序,会在该目录下生成一些文件
  • webapps:部署web应用程序的默认目录,也就是 war 包所在默认目录
  • work:主要存放由JSP文件生成的servlet(java文件以及最终编译生成的class文件)

上面是一个安装后的 Tomcat 的全部组成部分,如果你要启动,进入bin目录执行startup.sh就可以了,接着就可以在浏览器输入http://localhost:8080/访问了。那么问题来了:当你有了三个、五个以及十个应用服务需要同时部署到同一台服务器上时,你的 Tomcat 服务正确启动方式是什么?是把上面文件全部复制出 N 多个目录么?还是有其他处理方式呢?

Tomcat 常见的几种部署场景

通常,我们在同一台服务器上对 Tomcat 部署需求可以分为以下几种:单实例单应用,单实例多应用,多实例单应用,多实例多应用。实例的概念可以理解为上面说的一个 Tomcat 目录。

  • 单实例单应用:比较常用的一种方式,只需要把你打好的 war 包丢在 webapps目录下,执行启动 Tomcat 的脚本就行了。
  • 单实例多应用:有两个不同的 Web 项目 war 包,还是只需要丢在webapps目录下,执行启动 Tomcat 的脚本,访问不同项目加上不同的虚拟目录。这种方式要慎用在生产环境,因为重启或挂掉 Tomcat 后会影响另外一个应用的访问。
  • 多实例单应用:多个 Tomcat 部署同一个项目,端口号不同,可以利用 Nginx 这么做负载均衡,当然意义不大。
  • 多实例多应用:多个 Tomcat 部署多个不同的项目。这种模式在服务器资源有限,或者对服务器要求并不是很高的情况下,可以实现多个不同项目部署在同一台服务器上的需求,来实现资源使用的最大化。-

这次其实要说的就是这种方式,但多个 Tomcat 就是简单的复制出一个新的 Tomcat 目录后改一下端口么?这样做也太 Low 了点吧?哈哈,其实并不是低端没技术含量的问题,当你同一台服务器部署了多个不同基于 Tomcat 的 Web 服务时,会迎来下面几个极其现实的问题。

  • 当你需要对数十台 Tomcat 版本进行升级的时候,你需要怎么做?
  • 当你需要针对每一个不同的 Web 服务分配不用的内存时,你需要怎么做?
  • 当你需要启动多台服务器时,你需要怎么做?

当然,好像上面的都不是很重要,注意,划重点,多实例部署最大作用就是最大化利用服务器资源。

说干就干,现在就开始干?

别着急别着急,先看一下官方文档怎么建议的。他们说可不建议你复制一个又一份的全部 Tomcat 目录进行多实例的部署,说安照下图可以实现更优雅的 Tomcat 单机多实例部署:

部署结构

上图中的 CATALINA_HOME 指Tomcat安装路径,CATALINA_BASE 指实例所在位置。
CATALINA_HOME 路径下只需要包含 binlib 目录,而 CATALINA_BASE 只存放 conf、webapps、logs 等这些文件,这样部署的好处在于升级方便,配置及安装文件间互不影响,在不影响 Tomcat 实例的前提下,替换掉 CATALINA_HOME 中的安装文件。

流程清楚了,接下来才是真正的撸起袖子加油干了。

快来实践一下吧

你看到了这里肯定已经安装了 Tomcat 了,我现在演示用的是最新的 8.5.11 版本。

1.复制出两个 Tomcat 实例
在 Tomcat 安装路径的同一级目录下,新建两个tomcat-1、tomcat-2文件夹,先把安装路径下的 conf、webapps、temp、logs、work 这五个文件移动到tomcat-1实例中:
mv conf

命令:

mkdir tomcat-1 tomcat-2
cd apache-tomcat-8.5.11
mv conf/ webapps/ temp/ logs/ work/ -t ../tomcat-1

接着把tomcat-1下的这几个文件再复制到tomcat-2中,直接命令:

cp tomcat-1/* tomcat-2

2.新建 Tomcat 启动、停止脚本
依然是在 Tomcat 安装路径的同一级目录下,新建两个tomcat-shell文件夹,用于存放启动和停止脚本,同时赋予文件全部权限。
tomcat-shell

命令:

cd tomcat-shell/
vim start_tomcat.sh
vim stop_tomcat.sh
chmod 777 start_tomcat.sh stop_tomcat.sh

tomcat-start.sh:
tomcat-start.sh

#!/bin/bash

export CATALINA_HOME=/software/apache-tomcat-8.5.11
export CATALINA_BASE=${1%/}

echo $CATALINA_BASE

TOMCAT_ID=`ps aux |grep "java"|grep "Dcatalina.base=$CATALINA_BASE "|grep -v "grep"|awk '{ print $2}'`


if [ -n "$TOMCAT_ID" ] ; then
echo "tomcat(${TOMCAT_ITOMCAT_ID}) still running now , please shutdown it firest";
    exit 2;
fi

TOMCAT_START_LOG=`$CATALINA_HOME/bin/startup.sh`


if [ "$?" = "0" ]; then
    echo "$0 ${1%/} start succeed"
else
    echo "$0 ${1%/} start failed"
    echo $TOMCAT_START_LOG
fi

tomcat-stop.sh:
tomcat-stop.sh

#!/bin/bash

export CATALINA_HOME=/software/apache-tomcat-8.5.11
export CATALINA_BASE=${1%/}

echo $CATALINA_BASE

TOMCAT_ID=`ps aux |grep "java"|grep "[D]catalina.base=$CATALINA_BASE "|awk '{ print $2}'`

if [ -n "$TOMCAT_ID" ] ; then
TOMCAT_STOP_LOG=`$CATALINA_HOME/bin/shutdown.sh`
else
    echo "Tomcat instance not found : ${1%/}"
    exit

fi


if [ "$?" = "0" ]; then
    echo "$0 ${1%/} stop succeed"
else
    echo "$0 ${1%/} stop failed"
    echo $TOMCAT_STOP_LOG
fi

这两个就是简单的脚本,其中传入了要启动的 Tomcat 实例所在的路径,当然,你也可以写一个重启的脚本,其实就是先停止再启动,还可以加入不同的 JVM 参数配置等等操作。
到这里,其实全部基础工作已经做好了。接下来我们看一眼整个多实例的目录结构:

ls-all

3.配置 server.xml 端口
你知道的,同一个服务器部署不同 Tomcat 要设置不同的端口,不然会报端口冲突,所以我们只需要修改conf/server.xml中的其中前三个端口就行了。但它有四个分别是:

  • Server Port:该端口用于监听关闭tomcat的shutdown命令,默认为8005
  • Connector Port:该端口用于监听HTTP的请求,默认为8080
  • AJP Port:该端口用于监听AJP( Apache JServ Protocol )协议上的请求,通常用于整合Apache Server等其他HTTP服务器,默认为8009
  • Redirect Port:重定向端口,出现在Connector配置中,如果该Connector仅支持非SSL的普通http请求,那么该端口会把 https 的请求转发到这个Redirect Port指定的端口,默认为8443;

我这里把 tomcat-2 实例的 Connector Port 改为了 8081 ,并分别在 tomcat-1、tomcat-2webapps/ROOT 目录下放入了一个页面文件,内容如下:

<html>
<title>Tomcat-1</title>
<body>
    Hello Mafly! from Tomcat-1.
</body>
</html>

4.启动
直接通过执行我们刚写的脚本,传入某一个 Tomcat 实例路径即可来启动对应的 Tomcat。
start-tomcat

命令:

/software/tomcat-shell/start_tomcat.sh /software/tomcat-1
/software/tomcat-shell/start_tomcat.sh /software/tomcat-2

去浏览器看一眼:
Hello Mafly

哈哈,可以了。接下来,停止或者重启什么的都一样,你可以根据需要来在单个服务器上创建更多的 Tomcat 实例,一切都看你喜欢。

总结一下

这两天简单翻了一下 《Tomcat 权威指南》这本书,对于我们日常使用的 Tomcat 有了更详细的了解,当然我在这里并没有详细写配置、部署管理工具、安全管理和集群什么的,我还了解不够透彻,只是简单把 Tomcat 单机多实例比较优雅的部署方式玩了一下,希望对你有用。

昨天晚上看 Linux 和 Git 的发起者 Linus 这位大神的传记,真是令人感到上帝的不公平,怎么能设计出这样的天才人类,但更令人兴奋的是,我们目前绝大多数人都被设计成了几乎无差别,还远远轮不到拼智商的地步。

开源Linkerd项目庆祝一周年纪念日

Buoyant是一家云服务公司,宣布Linkerd(发音为“linker-DEE”)的一周年纪念日,这是一个基于微服务的原生云应用程序的开源“服务网格”项目。诚如公告所述:

在20世纪90年代,TCP/IP协议之类网络通信的转变,使得全行业从主机转移到客户机/服务器结构,Linkerd作为下一代云应用的基础网络层,受到越来越多的采用,使得企业能够在不牺牲可靠性的情况下将其计算架构从单片应用转移到了微服务。

Linkerd通过自动化负载均衡服务发现和运行时恢复能力为微服务提供可靠性。

Linkerd于2016年2月发布0.1.0版本,由前Twitter工程师William Morgan,现任Buoyant首席执行官和 Oliver Gould(Buoyant现任首席技术官)创建。Linkerd建立在 Finagle之上 ,是“一个与协议无关的、用于JVM的异步RPC系统,这使它可以简单地在Java、Scala或者任何JVM托管语言中构建强大的客户端和服务器”,部署在Twitter的生产环境中。

下图演示了Linkerd如何被部署成应用程序实例的服务网格:

开源Linkerd项目庆祝一周年纪念日

Buoyant最近发布了Linkerd的0.9.0版本。此为新版本特点:

InfoQ独家专访Bouyant的创始人兼首席执行官William Morgan,并谈及了这个里程碑。

InfoQ:你在Buoyant目前的职责是什么?或者说,你每天都在做什么?

William Morgan:我是首席执行官,这意味着在一家工程繁忙的公司,比如Buoyant,我需要花费大部分时间在公司,而这只是为了跟上工程师的进程。他们的工作是做出优秀的产品,而我的工作是在他们身边,为他们建立一个良好的公司,可以用来支持他们,并且将他们所创造出的东西的价值转化为外部世界所能够欣赏到的。

InfoQ:你能告诉读者更多关于贵公司的信息吗?

Morgan:我们为原生云环境构建开源操作可靠性软件。我们的使命是使各地的公司能够构建安全且有弹性的任务关键型应用程序。我们是一家重型工程公司,与推特、谷歌、微软和雅虎等公司积累了许多集体经验,工程师团队(特别是SREs 和DevOps的工作人员)需要可靠、安全地运维他们的应用程序,我们要利用这些集体经验使他们可以做到这一点。我们过去也是一直都保持电话在线的,即使因为一些愚蠢的原因,也必须要在凌晨3点醒来,所以我们的目标是尽量减少这种情况。在此,也向我们随叫随到的工程师们表示感谢。

InfoQ: Linkerd是什么,为什么微服务和云本地应用程序在通信层需要新的“服务网格”?

Morgan: Linkerd是一个“服务网格”,它是专用于处理时间敏感的服务到服务的通信基础设施层。与传统网格物料相反,服务网格进行请求级别操作。所以我们不谈论数据包或者是字节,我们考虑的是请求导致响应的结果。服务Foo将与服务Bar交流,并且等待它做出响应,当它做到时,Foo将会处理结果,然后将自己的结果中继给它的调用者。如果Bar不及时回应,那么Foo也不得不做出一些反馈。

当然这种请求-响应模式自从网络编程开始便一直存在,但正在改变的是,对于微服务,使用原生云应用程序,每次对应用程序进行调用,这种通信将在应用程序内发生了几十或者几百次。因此,如果有成千上百个的服务,而且每个服务运行数百个实例,并且每秒有数百个请求,那么你最终会遇到一个非常复杂的请求流通过应用程序。而且这个实例可能正在死亡,或者正变得越来越超负荷,又或者被重新安排了所有的时间….总之它变得十分复杂。

服务网格的目标是解耦这个模型的操作复杂性,将其移动到应用程序之外,使应用程序保持纯净。因此程序代码只需要说:“嘿,我是服务Foo,我需要发送请求到服务Bar。”而操作的东西,比如重试、超时、截止日期、负载均衡和服务发现,他们不仅极其难以找到合适的,但关键是找到了合适的之后,应用程序也不会停留太长时间,当然,如果他们不正确,应单独处理。它们是在单独的一层,在那里,他们可以独立于应用程序运行进行管理。

Linkerd以它目前的形式,是一个用户空间代理,因为这是人们最容易使用的。这就像注入了类固醇的HAProxy。但是根本上服务网格概念远远超过了代理模型。

InfoQ:你能告诉我们读者一些关于你在推特上使用Finagle的经验,以及Linkerd是如何构建在Finagle上的(在推特上,经常被称为帮助杀死“Fail Whale”的关键技术之一)?

Morgan: Finagle是Twitter如何击败Fail Whale的一个重要部分(我会说“击败”而不是“杀死”,因为我喜欢想象鲸鱼自由地游来游去,不去骚扰别人,而不是到处贪婪地吞噬)。 Twitter决定将“巨石”分成许多不同的服务。我们当时没有“微服务”这个词,但这真的是我们正在做的。而且Finagle启动十分简单,它将成为我们用来调用从一个服务到另一个服务的库。几乎Twitter上的每一个服务端都使用Finagle客户端与另一个服务端进行通信,并且使用Finagle服务端接受请求。所以Finagle被放置在每个请求的两端。

事实证明,Twitter在早期存在的正常运行时间和可靠性的大量问题都是由服务间彼此交互的方式所造成的。所以Finagle是我们可以解决所有问题的地方。随着时间的推移,Finagle获得了负载均衡、服务发现、重试逻辑、断路、路由和命名抽象等一系列好东西。从Finagle的角度看来,它几乎就像是Twitter是一堆Finagle控制着的连接,但在它们之间有一些凌乱的应用程序代码。

而且很多运维经验已经在Finagle中实现了。Twitter会以新颖的方式走下去,在Finagle中实现对根本问题的容错,并如此往复下去。所以随着时间的变化,Finagle变得非常成熟,能够处理各种奇怪的边缘情形。因为这是分布式系统的模式,它们是由1%的正常操作和99%的奇怪边缘情形组成的。

InfoQ: 在你的Linkerd的最早时期中,你提出过一些目标,要向世人展示Finagle的能量。那么Linkerd将如何扩展Finagle,使这些抽象的服务沟通更容易为主流企业所利用?

Morgan:这最大的区别就是,Linkerd将Finagle包装成一个独立的代理,你只需要运行它,而不必了解其如何实现的细节。它不关心你的服务使用什么语言或服务器框架。Finagle是一个库,所以如果你在用JVM,你实际上就只能使用它了。但Linkerd却可以在任何地方使用。

另一个区别是Linkerd给你的仅仅只是一个运维模型。而Finagle具有两个模型:一个编程模型和一个运维模型。并且编程模型是非常优雅,具有表现力的,它是RCP调用的函数式编程,它让你写出漂亮的代码、神奇的代码、最好的代码。但我们把这些都扔掉了,我们只是给你运维的东西。事实上,我们努力地工作是为了让你使用Linkerd时不必深入了解Finagle,而不是口头表达“嘿,它的基础可是有够可靠、强大,比如 Twitter、 Soundcloud和Pinterest 和一些其他公司。”

InfoQ:Linkerd之于微软服务器,已经比作了使TCP能够转向客户端-服务端的方式。你觉得这么比合理吗?

Morgan:这个比较当然合理。好比我在一件连帽衫里看见自己是Vint Cerf。哦,当然这只是一个理想化的比较。但是机会是存在的。首先,它是一个抽象层。TCP允许网络编程人员说:“嘿,从这里到那里发送这些字节,不需要考虑数据包的丢失或重复,也不需要考虑关于路由、关于流控制、关于多个应用可能共享相同IP地址的事实”。类似地,Linkerd允许应用程序员说:“嘿,将这个请求从这里发送到那里,不必担心超时、期限传播、服务发现和跨多个端点的平衡的问题以及重试或者断路的状况。”

更广泛地说,有一个巨大的,全行业范围内的变化正发生在应用程序的架构上。这就是整个“原生云”转型。公司正在将Docker 、Kubernetes 和微服务转移到云本地堆栈上,但他们真的没有选择的余地。这只是一个时间的问题;他们预计运营的规模将会越来越大,但是这些虚拟化硬件真的缺乏可靠性语义;他们真的都需要在产品上同时快速迭代。这些情况都会促进原生云的建立。

而这种巨大的转变,在这样一个基本的层次上,类似于从主型机转移到客户端-服务端的行为,使得整个行业围绕TCP/IP构建。围绕网络硬件的整个行业是从20世纪80年代的转变开始被创建的,比如Cisco这样的公司。类似的事情现在正在发生,将堆栈向上移一点。所以这就是我们的秘密计划:成为微服务中的Cisco。

InfoQ: Linkerd在什么案例中很重要?

Morgan: 任何系统都需要多个服务,并且性能和可靠性都是至关重要的,其SLA正在运行的系统是Linkerd的一个候选者。Linkerd最早的很多采用者都是付款处理器和银行,比如MonzoZooz,他们正在云计算平台上构建基础设施,并且真正关注可靠性问题。停机的每一秒时间都是金钱损失。事务已经通过系统准确地附加上了金钱。这就是Linkerd真正擅长的用例。

InfoQ:能和我们说说关于Linkerd路线图的情况吗。自从它第一次被推出之后,在过去一年之间增加了什么,并且你将如何扩展其功能?

Morgan:是的,性能和资源消耗一直是我们正在努力解决的事情。我们希望Linkerd更小、更快、更轻。我们有一些及其酷炫的秘密,而且我们也正在努力将其实现,我真的很兴奋,因为我们很快就能将之公之于众了。 我们也还需要在工作中支持更多的协议,并支持原始TCP。当然,为了更紧密地与我们原生云的兄弟连接,特别是与Kubernetes的集成,现在很容易就可以将Linkerd嵌入到Kubernetes中,但是将来会有一些东西使它完成得更容易。

最后,我们认为,诸如gRPC 和HTTP/2之类的多路复合协议将是未来大规模分布式系统的明显选择。Linkerd已经对这些协议提供了巨大的支持,我们也将继续投入。

资源 

有关Linkerd的更多信息,请访问以下资源:

查看英文原文:Open Source Linkerd Project Celebrates First Anniversary in Quest to Become TCP/IP of Microservices

该文章由WP-AutoPost插件自动采集发布

原文地址:http://www.infoq.com/cn/news/2017/04/linkerd-celebrates-one-year?utm_source=news_about_java&utm_medium=link&utm_campaign=java

从Java 9反向移植对象反序列化过滤器

JEP 290让开发人员可以在反序列化对象时对传入数据进行过滤。该提案最初是针对Java 9提出的,但现在已经反向移植到Java 6、7、8。该特性提供了一种机制,可以在处理对象输入流时过滤传入数据,并且可以帮助预防反序列化漏洞。前不久,这种漏洞曾影响了Apache Commons及其他库。

反序列化不可信任数据是开放Web应用安全项目(OWASP)和CERT Oracle Coding Standard for Java(尤其是规则SER12-JSER13-J)等所列出的一个众所周知的风险。软件开发人员应该总是检查通过ObjectInputStream传入的数据是否有效,不过,借助JDK中现有的工具,这有时候并不容易实现。JEP 290改变了这种情况,它提供了一种方法过滤传入数据,而且不需要扩展ObjectInputStream。这是通过多种机制实现的,取决于相关开发人员的需要。

一般来说,开发人员可以通过编辑系统属性jdk.serialFilter或者conf/security/java.properties中的安全属性jdk.serialFilter配置默认的ObjectInputFilter。这些属性可以接受一种或多种模式,用于查找类(使用类似Ant文件模式的语法),或者设置对反序列化对象属性的限制:


// 拒绝反序列化任何属于untrustedmodule的类,
// 以及任何元素数超过500的数组
jdk.serialFilter=!untrustedmodule/.**;maxarray=500 

// 包com.myorg.trusted的白名单类,
// 但不一定是来自子包
jdk.serialFilter=com.myorg.trusted.* 

如果需要更大的灵活性,那么开发人员可以指定自己的动作和检查,实现自己的ObjectInputFilter,然后使用setObjectInputFilter应用到已有的ObjectInputStreamObjectInputFilter可以使用ObjectInputFilter.FilterInfo提供的信息确定当前正在反序列化的对象是可以接受还是需要拒绝,或者该过滤器并没有提供足够的决策信息;在后一种情况下,自定义的过滤器可以将状态置为“不确定”,并委托另一个用户定义的过滤器或者默认的系统过滤器进行决策。

最后,如果开发人员希望在所有的反序列化过程中都使用自己的机制,就可以使用ObjectInputFilter.Config.setSerialFilter将一个用户定义的过滤器指定为系统默认的过滤器。

如本文开头所言,开发人员不需要等到Java 9才开始应用序列化过滤器;Java 8 update 121、Java 7 update 131、Java 6 update 141均提供了JEP 290。

查看英文原文Object Deserialisation Filters Backported from Java 9

该文章由WP-AutoPost插件自动采集发布

原文地址:http://www.infoq.com/cn/news/2017/03/deserialise-filter-backport?utm_source=news_about_java&utm_medium=link&utm_campaign=java

Java将弃用finalize()方法?

最近,OpenJDK邮件组core-libs-dev里出现了一封邮件,建议弃用Object类的finalize()方法。

弃用Object类的方法将会是一件非常不寻常的事情。Java从 1.0开始就有了finalize()方法,不过这个方法一直被认为是一个糟糕的设计,也是Java平台的一个遗留的大“毒瘤”。

垃圾回收器会特别对待覆盖了finalize()方法的对象。一般情况下,在垃圾回收期间,一个无法触及的对象会立即被销毁。不过,覆盖了finalize()方法的对象会被移动到一个队列里,一个独立的线程遍历这个队列,调用每一个对象的finalize()方法。在finalize()方法调用结束之后,这些对象才成为真正的垃圾,等待下一轮垃圾回收。

Java的这种机制与C++里的RAll模式类似,创建对象的时候分配资源(比如文件句柄),在销毁对象时自动释放资源。

不过,析构并不能安全地实现资源的自动管理,因为垃圾回收器并没有运行时间上的保证。也就是说,并不存在任何一种机制可以把资源的释放与对象的生命周期完全绑定在一起,如果处理不好还会耗尽资源。

析构的使用已经偏离了它的设计初衷。

多年来,Oracle(以及之前的Sun)建议开发者避免在一般的应用里使用析构。弃用析构意味着向彻底移除迈出了第一步,不过现在能做的也就是在使用析构时给出编译警告。

现在并没有任何有关彻底移除析构机制的时间表,部分原因是因为Java平台上仍然存在一些使用析构的场景,这些场景与资源使用的管理并没有联系。已经有人在考虑如何对这些场景进行迁移,以便移除对析构机制的依赖。

如果Java 9不会弃用析构(看起来不太可能),那么最早有可能会在Java 10里弃用。不过,最终是不是会在Java 10里弃用,或者在更晚的版本里,目前尚无定论。

查看英文原文:Java finalization to be deprecated?

该文章由WP-AutoPost插件自动采集发布

原文地址:http://www.infoq.com/cn/news/2017/03/Java-Finalize-Deprecated?utm_source=news_about_java&utm_medium=link&utm_campaign=java

互联网公司之外,银联等大型企业是如何玩转软件研发的?


张建锋,永源中间件共同创始人,原红帽公司 JBoss 应用服务器核心开发组成员。毕业于北京邮电大学和清华大学,曾供职于金山软件,IONA 科技公司和红帽软件。

对于 JavaEE 的各项规范比较熟悉;开源技术爱好者,喜欢接触各类开源项目,学习优秀之处并加以借鉴,认为阅读好的源码就和阅读一本好书一样让人感到愉悦;在分布式计算,企业应用设计,移动行业应用,DevOps 等技术领域有丰富的实战经验和自己的见解;愿意思考软件背后蕴涵的管理思想,认为软件技术是一种高效管理的实现方式,有志于将管理学和软件开发进行结合。

很多年前就开始关注 InfoQ 网站,后来又机缘巧合做过 QCon 讲师,结识了 QCon 主编臧秀涛。2016 年年底,跟秀涛约聊后发现,现在 IT 技术大会虽多,但大多是互联网公司之间的技术切磋,少有企业之间的技术交流。诚然,互联网服务也是软件的一种,但我认为,“传统”的可交付软件也是必不可少的,尤其在中国的国情下。云计算是好的方向没错,然而套装软件依然会拥有不可小觑的市场。放眼全球,IBM、微软、甲骨文依然牢牢占据 IT 巨头第一梯队的位置。

对于技术人员来说,QCon 是一个非常好的学习和交流的平台,其官网首页的 Logo 下写着“全球软件开发大会”。既然是“软件开发大会”自然应该增加一些“传统软件”相关的话题。深思熟虑之后,我建议在 QCon 北京 2017 设立一个"企业软件互联网应用实践"专题,秀涛欣然同意并邀请我做专题出品人。

我认为,软件开发大会应该有来自纯软件厂商、IT 服务商、行业应用软件公司,以及应用 IT 走在前沿的企事业单位的声音。经过 3 个月的努力,我请到了来自不同领域组织(企事业单位)的 6 位讲师,围绕自身企业应用的实践,分享技术和实际经验中的闪光点。这些组织都在各自的领域有很高知名度。

话题 1.《企业级供应链系统服务化之路》吴众欣 新聚思架构部经理

新聚思是全球领先的供应链解决方案提供商,我们更熟悉的可能是其兄弟公司联强国际。作为 IT 供应链行业的大型公司,业务系统的复杂性可想而知。数据库的表结构、业务系统的架构复杂性,不断演变的系统和逐步加入的需求特性。这套驱动大型供应链业务系统的技术经验,值得每一位大型行业软件架构师和开发者关注

吴众欣老师是领域专家,有著作和译作若干本,并精于书法、绘画、国学等,是难得的“技术全才”。

互联网公司之外,银联等大型企业是如何玩转软件研发的?

SYNNEX SUPPLY CHAIN SERVICE SYSTEM,有超过 16 年的系统服务历史,它一直支持着 SYNNEX 公司业务量的攀升。供应链系统纷繁复杂,包括仓库管理系统(WMS),运输管理系统(TMS),应收(AR)、应付(AP)、信用管理(CR)等系统应用。

如今,SYNNEX 已由使用快速开发工具,转向两层 Java,继而走向 BS 
系统,目前正在服务化道路上快速推进。本话题将分享 SYNNEX 讨论、选择、思辨、跟进及革新的心路历程。

话题 2.《特大型央企流程管理平台应用实践》 董爱强 中电普华研发事业部主任

中电普华是知名的行业企业信息化建设软件提供商,产品和服务齐全,地域覆盖面广,面对的客户需求众多,流程管理平台在行业应用中起到关键的作用。企业应用中,ESB、BPM、CEP 和规则引擎是主要的技术产品,而 BPM 流程管理平台是重中之重

我国特大型央企的信息化建设,毫不夸张的说,涉及到国计民生,重要而关键,有成千上万的技术人员进行研发保障。作为研发事业部负责人,董爱强老师非常重视在 QCon 的交流机会,他将分享平台技术和运营经验,值得每个垂直行业业务系统的技术人员参考借鉴

互联网公司之外,银联等大型企业是如何玩转软件研发的?

在国内特大型央企的 IT 建设中,各领域的业务系统在不同的历史时期使用了多种流程管理软件,它们所遵循的流程规范及使用的技术标准均存在巨大差异,导致端到端的流程难以打通,且项目级的流程应用使流程资源难以集中管理、实施运维成本高、资源利用不合理。如何在复杂的 IT 环境中实现统一流程标准、统一流程服务、统一流程运维,是一件极具挑战性的事。

过去 10 年,企业级 BPM 作为 SOA 体系下的关键组件,经历了一个加速建设的过程。本话题将带大家从过去 10 年 BPM 平台的建设实践中,了解流程领域的技术发展与架构变迁,了解大型企业如何基于统一流程平台实现多应用的统一支撑、降低管理与运维成本、提升对业务创新与管理优化的支撑能力,以及对未来架构演进方向的一些思考。

话题 3.《中国银联的开源应用之路》 周亚国 中国银联技术开发中心资深工程师

隆重的给大家介绍下中国银联的周亚国老师,他是我认识的少数比我还勤奋的国企技术人员之一,在应用服务器中间件、分布式架构设计 OpenStack/SDN 等方面都具有丰富的一线技术经验。可以说,对于 JBoss 应用服务器的熟悉和理解程度,在国内周老师应该是紧随红帽 JBoss 团队成员排在前几位的。他们团队维护着一个丰富的经验库,用于应对中国银联开源应用中遇到的种种技术问题。

中国银联作为国字头金融企业,原有系统也几乎都是商业公司产品,然而技术团队通过自身的学习和实践,掌握了开源产品的关键技术细节,并走查了每个用到的开源组件的代码,从实践中不断归纳总结,进行修正改进,研发出了符合自己需求的应用服务器产品。我个人认为,这是国内企业中,运用国际优秀开源软件的典型成功案例。相信每个接纳以及打算学习开源技术,并受益于成本节约的企业技术人员,都能从周老师的分享中得到启发

互联网公司之外,银联等大型企业是如何玩转软件研发的?

随着开源软件在金融行业的应用越来越多,中国银联作为一家银行卡组织,积极探索开源软件的应用,正在经历使用开源软件替换商业软件的过程,例如,银联基于 JBoss 开源应用服务器定制开发,形成符合公司自身需要的发行版。本话题着重以 JEE 应用服务器定制开发及分布式服务框架为例,讲述银联的开源应用之路。

  • 中国银联开源应用的背景及实践
  • 如何定制化应用服务器及参与开源社区
  • 应用服务器定制开发点
  • 定制化应用服务器在使用过程中遇到的问题及解决方案
  • 应用迁移的历程

话题 4.《互联网思维下的 MOOC 课程实践》 马昱春 清华大学计算机系副教授

清华大学是国内顶尖的高校,也是每位理工科学生梦想的最高学府。如今, MOOC 使全球高校和专家的课程实现了在线化,让开发者们的学习需求得到了满足

马昱春老师是 MOOC 的实践者,具有丰富的经验。她教授的《组合数学》课程被评为 MOOC 精品课,组合数学是对编程最有帮助的一门数学课程,软件工程师必学,虽然冠以数学的字样,确是和软件开发密不可分。

互联网公司之外,银联等大型企业是如何玩转软件研发的?

随着 MOOC 的汹涌来袭,在线教育开始逐渐走向各个领域。在互联网思维的影响下,专业领域知识的传播不再禁锢在高校的围墙之内,而是开放给不同的学习者。作为大规模的网络开放课程,MOOC 不是简单地将课堂搬到网上。想要在互联网的思维下成功开发和运营一门在线课程,不仅要求授课者对知识有极高的把握度,更需要面向多样化的受众群体进行灵活的设计。

本话题将基于 MOOC 平台的课程建设和运营实践,讲述信息类在线课程的特点和发展之路。

话题 5.《企业应用互联网化的架构演进之路》 曾祥进 金蝶天燕中间件企业事业部负责人

金蝶中间件是国内中间件领域的领导者,我本人进入中间件这个领域,也受到了金蝶中间件原技术负责人袁红岗先生的影响。

中间件是基础软件,但因为和应用架构设计紧密结合,更多的融入到软件设计之中,作为独立软件反而不容易有巨大的市场红利。但毫无疑问,中间件是真正具有技术含量的基础软件,前面列举的 IBM、甲骨文、微软都是中间件大型厂商(微软中间件融入在.NET框架中),阿里中间件团队也是首屈一指的国内技术团队。

当前中间件已经从 JavaEE 范畴不断外延到各个技术领域,包括云计算 PaaS 等。曾祥进老师有深度的技术积累和丰富经验,他所分享的国内众多企业应用的架构演进内容,相信值得每位企业应用架构师和开发者关注

互联网公司之外,银联等大型企业是如何玩转软件研发的?

在云计算、大数据、社交化、移动化的共同驱动下,企业应用从传统的单体架构三层结构沿着互联网公司走过的路,向现代化的新型应用架构演进。由于企业业务本身的复杂性要大于互联网公司的业务,包袱也更重,因此企业应用架构的转型所面临的困难、挑战也更多。

  • 传统企业应用如何应对更高的并发及更高的用户体验要求?
  • 具有内部复杂逻辑关系的应用如何向微服务架构转型?
  • 碎片化后的应用之间如何通信并进行业务协同?
  • 原有的 SOA 基础设施该如何去升级?
  • 具有强一致性要求的业务模块在新的架构体系里如何设计?

话题 6.《基于 kubernetes 的企业级容器云》 周彩钦 联想 PaaS 团队资深工程师

联想是国内 IT 企业“老大哥”,也是国际化 IT 企业。内部的信息系统繁多,用户来自各个部门,数据量庞大,运维面对巨大的复杂性。

基于容器的企业 PaaS 平台,可以管理和高效运维来自各个部门或者合作伙伴开发的各类企业业务系统。容器云和 Kubernetes 当前都是比较新的技术,周彩钦老师所在团队,经过 1 年多深入的技术研究和研发打磨,构建了一套符合企业使用的 PaaS 平台。相信很多企业现在也在寻找或者调研开发一套类似的系统,那么周老师的一线技术经验分享不容错过

互联网公司之外,银联等大型企业是如何玩转软件研发的?

互联网时代,市场发展变化越来越快,传统企业应用的开发模式也变得多样化以适应业务的变化。持续集成、持续交付成为一个常态,自动化工具和 IT 自助化服务已经形成一股潮流。

联想是一个国际化企业,内部的业务和需求都呈井喷式发展,开发团队对于 IT 基础架构的快速交付和自动化需求变得更加强烈,另外,在应用的多样性和扩展性方面有更高的期望。基于此场景,其 PaaS 团队结合现在比较流行的 Docker 和 Kubernetes 技术打造了自有的企业级容器云,实现了服务的快速部署和交付,加速促进了业务的发展。

本话题将分享联想 PaaS 平台的基本架构,系统演变过程和平台开发运维过程中的一些实战经验及教训。

话题 7.《无需部署的前端中间件技术——企业移动化新思路》 马铎 云适配技术研究院院长

受限于过去网络速度和终端设备的落后,碎片化时间始终无法被高效利用。随着科技发展和社会节奏的加快,企业对于时间利用率的追求也变得越来越高,这也促进了移动技术的蓬勃发展。对于企业尤其是大中型企业而言,IT 技术中僵化、庞大的系统无法快速演变,老化的核心系统,如 ERP 系统,需要升级成为围绕服务进行规划的系统

马铎老师在多技术领域有深入研究和丰富实践,曾负责研发了国内最早基于业务模式实现可视化设计的企业级应用快速开发平台,主导了诸多大型企业的移动信息化项目,他将分享自己 10 多年的实践经验。

互联网公司之外,银联等大型企业是如何玩转软件研发的?

投入使用多年且变化极小的企业遗留系统,都迫切需要一种灵活的企业架构来重构 IT,使其变为一种可延展、可重复利用的资源。

重建遗留系统是一件超级繁琐的事情,但只有灵活的服务替代了僵化的系统,企业才有真正的未来。本次演讲将帮助企业顺利拥抱移动互联网时代。

  • 企业移动化的困境和开发痛点,以及 10 年信息化建设经验
  • 传统中间件如何解决移动化,它的局限性是什么
  • 前端中间件如何无须部署服务器、无须 API 实现企业应用系统移动化
  • 分享面向企业的 IT 重构新思路——用 HTML5 技术进行移动化扩展
  • 企业移动化实际项目中面临的挑战及解决之道

在我看来,企业软件和互联网软件之间有个重要的差异,就是企业软件需要更高的成熟度和稳定性。企业软件可能没有那么酷,可能还是用着几年前不是那么新潮的技术,机器数目和用户访问量也没有互联网那么大,但业务复杂度却非常高,无论是数据库表数目、代码行数,还是参与开发人员数量,都超过大多数互联网应用。同样的,面对客户多变的需求、巨大的业务数据量、更加苛刻的运营要求(商业环境下,1 分钱也不能出错,对事务特性要求很高),企业软件也需要不断优化改进,来满足快速增长的业务需求。

我相信,中国最大的软件开发者群体,还是分布在广大的软件公司、集成服务商、 IT 应用企业中。其中,程序员、测试、文档、项目管理人员都在努力工作,通过编写软件系统来支撑起我国的信息化建设。“企业软件互联网应用实践”专题的目标就是,让更多的技术人员都能在 QCon全球软件开发大会【北京站】2017上学到所在领域优秀企业的技术经验,都能够和专家在自己熟悉的技术方面进行交流。也希望“企业软件互联网应用实践”能成为 QCon 大会的常设专题。

该文章由WP-AutoPost插件自动采集发布

原文地址:http://www.infoq.com/cn/news/2017/03/enterprise-software-experience?utm_source=news_about_java&utm_medium=link&utm_campaign=java

Vaadin发布Polyglot框架第8版

第7版发布4年后,Vaadin近日发布了第8版Polyglot框架,该框架可用于通过UI组件构建Web应用,此版本在包含下列21项改进

  • 类型安全(Typesafe)Java API:
    • 有关Vaadin的改进:
      • 组件
      • 验证器
      • Grid
      • 异常消息
    • 新增的ItemCaptionGenerator
    • 类型安全Lambda表达式
  • Default的改进:
    • Null值
    • 有序布局(Ordered layout)
  • 性能改进:
    • 降低内存中数据集的开销
    • 降低大规模数据集的CPU需求
  • 面向未来趋势的改进:
    • 取消了对老版本Java和Servlet规范的支持
    • 取消了对遗留浏览器的支持

范例 – 第7和第8版的差异

下列Grid包含的类型安全Lambda表达式演示了相对与第7版,第8版Vaadin所实现的简化:

第7版:

Grid grid = new Grid();
grid.setContainerDataSource(
    new BeanItemContainer(persons));
grid.removeAllColumns();
grid.addColumn("firstName");
grid.getColumn("firstName")
    .setHeaderCaption("First Name");
grid.addColumn("lastName");

第8版:

Grid grid = new Grid();
grid.setItems(persons);
grid.addColumn(Person::getFirstName)
    .setCaption("First Name");
grid.addColumn(Person::getLastName)
    .setCaption("Last Name");

请注意第8版的容器中取消了数据包装(Wrapping)。Vaadin的Container接口也已从API中移除。

Vaadin还更新了第8版中使用Vaadin创建CRUD UI的范例(位于Spring Guides中)。

上手

下列命令使用Maven发起了一个应用程序构建:

mvn -B archetype:generate -DarchetypeGroupId=com.vaadin
-DarchetypeArtifactId=vaadin-archetype-application -DarchetypeVersion=8.0.4
-DgroupId=org.test -DartifactId=vaadin-app -Dversion=1.0-SNAPSHOT
&& cd vaadin-app && mvn package jetty:run

该命令可创建一个简单的单模块范例应用(通过-DarchetypeArtifactId指定),创建了一个子文件夹(通过-DartifactID指定),将目录更改至该子目录,启动了一个Jetty实例,并运行应用程序产生如下结果:

Vaadin发布Polyglot框架第8版

若要创建更复杂的多模块范例应用,可直接替换-DarchetypeArtifactId中的vaadin-archtype-application-example值。

在Vaadin 8的发布说明中,Vaadin产品营销经理Matti Tahvonen介绍了他们的后续短期目标:

虽然Vaadin 8.0.0包含了很多不错的改进,但这些只是后续进一步完善的基础。通过取消对老版本JDK和已停止维护的Internet Explorer版本的支持,我们将能更快速地为大家提供更多新功能。在计划于四月发布的下一个小版本中,我们将提供大家期待已久的层次结构,以及Grid组件的拖拽和组件支持。

当然我们同时也会继续通过新版修复各种Bug,因此如果你遇到“.0 bugs”问题,请通过GitHub反馈给我们。

相关资源

阅读英文原文Vaadin Releases Version 8 of Their Polyglot Framework

该文章由WP-AutoPost插件自动采集发布

原文地址:http://www.infoq.com/cn/news/2017/03/vaadin-releases-version-8?utm_source=news_about_java&utm_medium=link&utm_campaign=java