中文字幕第一起页_久久久91亚洲视频_在线观看国产精品va_亚洲日本香蕉视频

進入2016年時間還不是很長，讓我們回顧下去年年底的一個預言。去年12月，來自C2B2的Steve Millidge預測，2016年將會成為Java EE微服務年。在一定程度上，這是基于Steve在JavaOne上的演講，他在演講中詳細地討論了這個主題。此外，Steve還是Payara的聯(lián)合創(chuàng)始人，Payara的目標用戶也是對微服務感興趣的Java EE開發(fā)人員。Steve還認為，SOA和微服務之間的差別很小，這種觀點我們以前聽說并且報道過。他在視頻中指出：

“微服務與SOA沒什么不同。它還是關于SOA”。

當然，現(xiàn)在還存在爭論，因為他的背景和當前的工作重心，Steve可能會發(fā)現(xiàn)自己很難保持客觀的態(tài)度。不過，早在2014年，微服務還處于起步階段，Adam Bien就描述了理想的Java EE微服務：

[...]理想的Java EE微服務是一個單[實體控制邊界]組件，在一個WAR包中，部署在單臺服務器/域中。在這種情況下，開發(fā)人員可以單獨地發(fā)布和重新部署單個組件（又稱微服務）。WAR包之間不可能直接調用方法，因此，WAR包將不得不使用比如JAX-RS來彼此通信。

我們在去年年底就微服務、DevOps和Java EE相關內容采訪了Markus Eisele，他詳細論述了自己為什么認為Java EE將會在微服務生態(tài)圈的發(fā)展中扮演重要的角色。還有一些其他使用Java EE編寫微服務的方法，包括TomEE和WildFly。KumuluzEE是JavaOne 2015 Duke選擇獎的其中一個獲獎者，該框架是一個Java EE微服務框架。該框架的聯(lián)合創(chuàng)建者Matjaz Juric解釋說：

KumuluzEE是第一個使用標準Java API的微服務框架。微服務架構的重點是將應用程序開發(fā)成服務并將這些服務單獨部署；沒有一個框架提供自動化部署和配置，是不可能使用Java EE實現(xiàn)真正的微服務架構的。

讓我們看一些人們如何看待微服務和Java EE的其他例子，這會非常有趣，因為有些人嚴格來講并不屬于傳統(tǒng)的Java EE領域。例如，早在2014年，Alex Soto就論述了為什么Java EE和RxJava是一個很棒的方案。不過，并不是每個人都認可使用Java EE能使開發(fā)人員采用微服務。正如Rick Hightower所說的那樣：

如果你將一個WAR文件部署到一個Java EE容器，那么你很可能不是在做微服務開發(fā)。如果你在一個容器或EAR文件中包含超過一個WAR文件，那么你肯定不是在做微服務開發(fā)。如果你將服務部署為AMI或Docker容器，而且你的微服務有一個main方法，那么你可能是在編寫微服務。

而且，Rick也不認為微服務與SOA相同：

事實上，它們在許多方面是完全相反的。例如，SOA往往采用WSDL，后者是一種非常嚴格的、強類型的服務端點定義方式。WSDL和XML模式中所有的未知量都來自XML。

當然，我們已經多次討論過，SOA和Web Service常常沒有關系。不過，Rick及其他一些人確信，Java EE太過臃腫或者說笨拙，以其為基礎構建微服務并不合適。Jeppe Cramon認為，Java EE之所以是一個糟糕的基礎還有更為根本的原因：

如果我們將兩路（同步）通信與小/微服務結合使用，并根據比如“1個類=1個服務”的原則，那么我們實際上回到了使用Corba、J2EE和分布式對象的20世紀90年代。遺憾的是，新生代的開發(fā)人員沒有使用分布式對象的經驗，因此也就沒有認識到這個主意多么糟糕，他們正試圖重復歷史，只是這次使用了新技術，比如用HTTP取代了RMI或IIOP。

如果微服務和SOA密切相關，那么可能會有一種觀點，就是微服務可以像SOA那樣采用一種技術無關的方式。你認為呢？2016年會成為Java EE微服務年嗎？如果有的話，Java EE會在微服務中扮演什么角色？

上篇文章：網頁制作與網站建設從入門到精通
下篇文章：java ee是什么