บทความนี้ถูกเขียนโดย  Jean-François James, Java EE Guardian .

ช่วง Summer ที่ผ่านมา Oracle ประกาศเจตนารมณ์จะ  open source Java EE (Enterprise Edition) ซึ่งได้รับการยืนยันที่  JavaOne 2017. บทความนี้จะชี้ให้เห็นถึงสถานะในปัจจุบันและเสนอมุมมองบางอย่างที่สำคัญ.

แรงกระตุ้น

ตามที่ David Delabassee, Oracle Java EE evangelist ผู้ที่มีส่วนในการตัดสินใจที่นำ Java EE ให้มีความคล่องตัว(agile) และความยืดหยุ่นง่ายต่อการใช้งาน(responsive) เพื่อมาทำให้เกิดการเปลี่ยนแปลงในด้านเทคโนโลยีและอุตสาหกรรมที่มีความต้องการในขณะนี้

ในความเป็นจริงนั้นขั้นตอนและระบบธรรมาภิบาลของ  JCP (Java Community Process) แม้ว่าการเปิดกว้างและความยืดหยุ่นนั้นทำดีและเป็นน่าชมเชยอยู่ แต่มันยังไม่ได้ถูกปรับให้เข้ากับการเปลี่ยนแปลงอย่างรวดเร็วของตลาด IT ในปัจจุบัน ตัวอย่างเช่นมีการเปลี่ยนแปลงมากมายเกิดขึ้นตั้งแต่ Java EE 7 (มิถุนายน 2013): พวกเราส่วนใหญ่มักละเลยในเรื่องต่างๆ เช่น เทคโนโลยี database แบบ NoSQL, การ containerization, สถาปัตยกรรมแบบ microservices รวมถึงการบริการแบบ serverless.

อย่างไรก็ตามในความคิดของผมค่อนข้างประหลาดใจกับการตัดสินใจครั้งนี้ เมื่อมองเปรียบเทียบกับ road map และการตั้งเป้าหมาย ตามที่ประกาศไว้ในOracle at JavaOne 2016:


Java EE roadmap as of JaveOne 2016

และในเวลาเดียวกัน Java EE8 นั้นกำลังจะประกาศให้ใช้งานได้อีกครั้งหลังจากไม่มีกิจกรรมมาเป็นเวลาหลายเดือน

แน่นอนว่าการตัดสินใจในครั้งนี้ชี้ให้เห็นว่า Oracle นั้นไม่ได้ให้ความสำคัญกับ Java EE อีกต่อไป และนั้นดูเหมือนจะเป็นการเสนอให้มีการใช้ open source ใหม่ในชื่อ Fn และมีการให้บริการแบบ Serverless คล้ายๆกับ  Amazon Lambda และ OpenWhisk ของ IBM (ซึ่งเปลี่ยนเป็นชื่อ  Apache project ในภายหลัง)

มีอะไรไหม่ใน Java EE8.

ในส่วนของข้อดีของ Oracle ที่พยายามที่จะส่งมอบ Java EE8 ได้อย่างตรงเวลา คือ ช่วงกันยายน 2017 ซึ่งไม่เพียงมีการพัฒนาและการ evolving specifications แต่ยังมีการย้าย Glassfish(the Java EE Reference Implementation) ไปยัง GitHub.

Java EE8 มีการปรับปรุงหลักๆดังนี้:

  • Java SE 8 alignment: API ของวันเวลา, CompletableFuture, repeatable annotations.
  • CDI 2.0: asynchronous events, เหตุการณ์ที่เกี่ยวกับการออกคำสั่ง, การปรับปรุงคุณสมบัติอื่นๆให้ดีขึ้น.  CDI ยืนยันว่าอยู่บนพื้นฐานของ platform ของ Java EE สำหรับการเปิดตัวในครั้งนี้
  • Servlet 4.0: HTTP/2 support (Server Push)
  • JAX-RS 2.1: Server-Sent Event, reactive extensions
  • JSON Processing 1.1 and JSON Binding 1.0
  • Security: การทำให้เข้าใจง่าย, การจัดการความลับ, modernization, OAuth2 and OpenID support

โดยรวมแล้ว Java EE8 เป็นมากกว่าการเริ่มต้นใหม่ที่มีการพัฒนาการอย่างแข็งแกร่ง โดยเฉพาะอย่างยิ่ง การระบุถึงส่วนประกอบของ cloud-native applications นั้นอยู่นอกเหนือขอบเขต อาทิเช่น distributed tracing, central configuration, health check, circuit breaker, load balancing.

มุมมอง Java EE ในตอนนี้?

โดยรวมแล้ว Java EE ยังคงเป็น platform ที่มีองค์กรหรือโครงการใหญ่ๆ ยังให้ความสำคัญเนื่องจาก:

  • รูปแบบการเขียนโปรแกรมมีความสมบูรณ์และมีความยืดหยุ่น
  • การใช้คำสั่งเดียวเพื่อควบคุมทั้งหมด โดยปกติแล้วไฟล์ Maven pom.xml จะมีจำนวนไม่เกิน 20 บรรทัด แม้ว่าจะเป็นโครงการที่ซับซ้อนก็ตาม
  • CDI ถูกพิสูจน์แล้วว่าทรงประสิทธิภาพและง่ายต่อการใช้งาน.
  • มีการผสมผสานที่ดี กับ IDE เป็นส่วนใหญ่

ในความคิดผม Java EE มีข้อจำกัดหลักอยู่ดังนี้

  • ไม่ได้มีความล้ำสมัย แม้ว่าจะมีความพอใจ แต่นักพัฒนาส่วนใหญ่ ไม่ได้เลือกเพื่อนำไปพัฒนา cloud-native applications เป็นตัวเลือกแรก
  • ยังขาดความเสถียรอันเนื่องจากส่วนประกอบที่แตกต่างกันในแต่ละรุ่น อาทิเช่น Servlet, CDI beans, EJB โดยเฉพาะอย่างยิ่งการแบ่งแยก CDI และ EJB ที่ไม่ชัดเจน สิ่งนี้อาจจะมีผลกับบทบาท CDI ในแง่ของ “first-class citizen” ในอนาคต.
  • มีความซับซ้อนในการทดสอบ แม้ว่าจะมีจุดเด่นดังที่จะเห็นใน Arquillian.
  • การเปลี่ยนแปลงนี้ยังไม่พร้อมทั้ง ข้อมูลจำเพาะและการนำไปใช้งาน

  • ใช้กับ Java SE ไม่ได้ คงจะต้องรอดู Java EE ที่ออกมาใหม่ ที่จะถูกรวมเข้ากันใน Java 9

การพัฒนาการของ Java EE Ecosystem.

การตัดสินใจของ Oracle มีผลอย่างมากกับ Java EE Ecosystem ซึ่งถือเป็นตัวละครใหม่ที่มีทั้งข้อดีและข้อเสีย.

เรามาพิจารณาในแต่ละฐานะกัน

Oracle.

Oracle เป็นเจ้าของ technology ของ Java (รวมถึง Java EE) และแบรนด์ โดยเฉพาะอย่างยิ่งยังคงรับผิดชอบในส่วนของ Java EE 8 maintenance.

ดังที่อธิบายไว้ข้างล่าง การที่ oracle เป็นเจ้าของเสียเองนั้น ได้พบปัญหาใหญ่ในการสร้างแบรนด์และเทคนิคของ platform ในอนาคต อันเนื่องจากไม่สามารถใช้ซ้ำได้ดังเหตุผลข้างล่าง

  • Java EE คือแบรนด์หรือตรา
  • แม้ว่าการใช้ชื่อ Java ในชื่อใหม่นั้นก็ยังเป็นปัญหา
  • มันไม่สามารถนำ javax package กลับมาใช้งานได้

The JCP.

ชื่ออย่างเป็นทางการคือ “the mechanism for developing standard technical specifications for Java technology”.

JCP โดยส่วนใหญ่นั้นถูกจัดการโดย Oracle ไม่ว่าจะเป็น Program Management Office , การเลือกตั้ง, การโหวต, การจัดการข้อกำหนดจำนวนมาก.

ในแง่ของการเป็นองค์กร JCP ยังคงเป็นองค์กรเปิดอยู่ ทุกคนสามารถสมัครเข้ามาเป็นสมาชิกได้ อาทิเช่น IBM และ Red Hat ซึ่งก็มีบทบาทมากเช่นกัน

Java EE เป็นส่วนที่มีองค์ประกอบและข้อมูลจำเพาะอยู่มาก ไม่ว่าจะเป็น Servlet, EJB, CDI, JAX-RS จน Java EE8 ถูกเปิดให้ใช้งาน ก็อยู่ในการกำกับของ JCP อย่างเต็มที่

แต่ละสเปคได้รับการจัดการในรูปแบบของ Java Specification Request (เช่น: JSR 366 สำหรับ Java EE 8, JSR 369 สำหรับ Servlet 4.0, JSR 365 สำหรับ CDI 2.0, JSR 370 สำหรับ CDI 2.1) ทั้งนี้ ได้อยู่ภายใต้ ความรับผิดชอบของ Expert Group ตาม well-defined lifecycle ดังรูป

Expert Group มีหน้าที่รับผิดชอบเพื่อให้ได้ผลลัพธ์ 3 ประการ

  1. Documentation ที่จะอธิบายถึงข้อมูลเฉพาะ
  1. Reference Implementation เพื่อให้แสดงถึงความสามารถของข้อมูลเฉพาะ
  1. Test Compatibility Kit ให้ตรวจสอบคำสั่งให้กับการใช้งานต่างๆ

นี่คืองานที่ใหญ่มาก!

กระบวนการนี้อาจจะดูเก่ามากๆ โดยที่มันเริ่มจากการข้อมูลเฉพาะถูกส่งจากปลายด้านหนึ่งและจะมีคุณสมบัติเฉพาะของข้อมูลถูกจัดเก็บโดย application servers ในเวลาเดียวกัน.

การลงทะเบียนเพื่อให้เป็น Associate Member ของ JCP นั้น ผมยอมรับว่าประทับใจในคุณภาพของข้อผูกพันและธรรมาภิบาลของผู้ที่เกียวข้อง แม้ว่าไม่รวดเร็วแต่การเปลี่ยนแปลงใหม่นี้จัดเป็นมาตรฐานการจัดความสำคัญหรือไม่?

สิ่งสำคัญที่ทำให้บังเกิดผลสำเร็จสำหรับ EE4J คือความสามารถที่จะทำให้มีความแข็งแรงในขณะเดียวกันก็มีธรรมาภิบาลที่ยืดหยุ่น

Java EE Guardians.

Java EE Guardians “เป็นกลุ่มคนอิสระทั่วไปที่มีความมุ่งมั่นที่จะขับเคลื่อน Java EE platform ให้ไปข้างหน้าผ่านการสนับสนุนและการมีส่วนร่วมของกลุ่มผู้พัฒนา”

ซึ่งถูกก่อตั้งเมื่อปี 2015(ไม่ทราบวันที่ก่อตั้งที่แน่ชัด) โดย Reza Rahman เพื่อที่จะกระตุ้นให้มีการใช้งานอีกครั้ง Java EE8 ขึ้นจากเดิมซึ่งมีคนใช้งานน้อยมากในขณะนั้น

ในปัจจุบันนั้นมีการโดยมุ่งเน้นการนำตรา Java EE และ javax package กลับมาใช้งานเพื่อให้มีการใช้งานอย่างต่อเนื่อง ซึ่งนี้เป็นเป้าประสงค์ที่ถูกระบุไว้ในเอกสารซึ่งเผยแพร่ในเมื่อตอนต้นมกราคม 2561 ที่ผ่านมา

Microprofile.io

Microprofile ถูกนิยามความหมายว่า “เป็น platform พื้นฐานที่มาจากการปรับแต่ง Enterprise Java เพื่อใช้ในสถาปัตยกรรมแบบ microservices และ ช่วยให้ MicroProfile สามารถทำงานพร้อมๆกันได้อย่างง่ายและสะดวกมากยิ่งขึ้น“

Microprofile ถูกสร้างขึ้นในช่วง summer ปี 2016 และกลายมาเป็น Eclipse project(-link-) ในปัจจุบัน มันถูกสนับสนุนโดย TomiTribe,Red Hat, IBM, และ Payara. แม้ว่าจะไม่ได้ริเริ่มมาจาก Oracle ก็เข้าร่วมเมื่อเดือนพฤศจิกายนปี 2017 เป็นต้นมา.

เวอร์ชั่นแรกๆที่ถูกปล่อยออกมาให้ได้ใช้งานอย่างจริง ที่ JavaOne 2016 ซึ่งเป็นพื้นฐานของ JAX-RS 2.0, CDI 1.2, และ JSON-P 1.0.

ตั้งแต่นั้นมา ผู้พัฒนาได้ถูกใช้งานในหลายๆโครงการพร้อมกัน อาทิเช่น

  • microprofile-config
  • microprofile-fault-tolerance
  • microprofile-health
  • microprofile-metrics
  • microprofile-open-api
  • microprofile-jwt-auth

ความปรารถนาตั้งแต่แรกเริ่มของ Microprofile.io นั้นมุ่งเน้นด้านนวตกรรมที่รวดเร็วให้กับ JCP ที่ทำงานอยู่บนพื้นฐานอยู่แล้ว มาถึงวันนี้ถือได้ว่า “พิสูจน์แนวคิด” สำหรับ EE4J ในการใช้ในกลุ่มผู้พัฒนา ทั่วไป องค์กร และรัฐบาล

อนาคตของ Microprofile.io จะเป็นอย่างไร? จะรวมกับ EE4J หรือจะยังคงอยู่ด้วย Microprofile หรือไม่

EE4J.

ตามที่ได้นิยามไว้ว่า “Eclipse Enterprise สำหรับ Java (EE4J) เป็น open source ที่ถูกสร้างขึ้นมาเพื่อการสร้างมาตรฐานให้กับ APIs , การทำให้ APIs ความสมบูรณ์ และ technology compatibility kits สำหรับ Java runtime นั้นๆที่มีเปิดใช้งานการพัฒนาการ การปรับปรุงและการบริหารทั้งฝั่ง server และฝั่ง cloud(cloud-native applications). EE4J ขึ้นกับ platform Java™ ตามมาตรฐานของ Enterprise Edition (Java EE) และใช้ Java EE8 เป็นพื้นฐานในการสร้างมาตรฐานใหม่

ต้องเน้นว่า EE4J เป็นชื่อโครงการไม่ใช่ชื่อแบรนด์ มีการสำรวจในเดือน พ.ย. 2017 เพื่อเลือกชื่อแบรนด์ จากข้อจำกัดที่กล่าวถึงข้างต้นนั้นยังไม่มีความเห็นเป็นเอกฉันท์ที่ชัดเจน ดูเหมือนว่ากลุ่มผู้พัฒนาส่วนใหญ่ (79%) จะสนับสนุน Java EE ให้ยังคงอยู่

คณะกรรมการบริหารโครงการซึ่งสร้างขึ้นจากผู้คนที่รู้จักกันดีในระบบนิเวศ Java EE ได้ถูกจัดตั้งขึ้นในเดือนพ.ย. 2017 สิ่งสำคัญอันดับแรกคือการเปลี่ยนแปลง การระดมกลุ่มผู้พัฒนาใหม่และการเปิดตัว version แรกที่ใช้บน Java EE8.

สำหรับตอนนี้ มี 2 projects ที่กำลังจะออกในส่วนของ EE4J.

  1. Yasson ที่พัฒนาโดยอ้างอิง JSON-B,
  1. EclipseLink ที่พัฒนาโดยอ้างอิง JPA.

หากต้องการทราบสถานะของ EE4J และอนาคตข้างหน้าจะเป็นอย่างไร กรุณาดูที่ FAQ.

ผลกระทบที่เกิดขึ้นของบริษัทผู้พัฒนา Java EE?

บริษัทผู้พัฒนา Java EE (ซึ่งได้แก่ Red Hat, IBM, Tomitribe และ payara) นั้นมีความตื่นตัวกับสิ่งที่เกิดขึ้นใหม่นี้ในเรื่องอะไรบ้าง:

  • พวกเขาจะมีพลังและอิทธิพลมากขึ้นต่อภายใน JCP
  • พวกเขาจะได้สิทธิ์ในการเข้าถึง Test Compatibility Kits ฟรี ซึ่งก่อนหน้านี้เป็นของ Oracle.
  • พวกเข้าสามารถที่จะส่ง “application servers” ในการพัฒนาโปรแกรมแบบ iterative โดยไม่ต้องอาศัย Java EE ที่เรียกว่า “tunnel effect”.

อนาคตของ Application Servers.

“Java EE ใหม่” จะยังคงเป็นข้อกำหนดที่ครอบคลุมหรือเป็นชุดข้อกำหนดที่อิสระและสอดคล้องกับข้อกำหนดหรือไม่?

คำถามต่อมาคือ Application Servers ยังคงอาศัย “monolithic platforms” หรือจะเปลี่ยนไปใช้ platform ที่แยกออกไปเลยหรือ แบบใช้แบบควบคู่กัน?

ถ้าเป็นผมแล้วจะเลือกตัวเลือกที่สอง ตามที่ Red Hat Wildfly Swarm ได้กล่าวไว้.

ผลกระทบกับกับกลุ่มนักพัฒนา.

มันอาจจะเป็นโอกาสที่ดีสำหรับกลุ่มนักพัฒนา ที่มี platform ที่มีความล่องตัวและตอบสนองได้ดีขึ้น ซึ่งจะทำให้เกิดการเปลี่ยนแปลงใหม่ๆขึ้นอีก.

สำหรับบุคคลที่สนับสนุน EE4J นั้นจะต้องพิจารณาถึง ผลกระทบและความชัดเจนให้ดี.

ผลกระทบสำหรับผู้ใช้งาน.

ในสถานการณ์ปัจจุบันนั้นยากที่จะมองเห็นมุมมองจากผู้ใช้งานได้อย่างชัดเจน จุดแข็งของ Java EE ที่เคยเป็นมาตรฐานของ JCP อย่างเป็นทางการ แน่นอนว่ามาตราฐานนี้เคยเป็นสิ่งสำคัญอย่างมากสำหรับโครงการในระยะยาว

มันเป็นที่ชัดเจนว่า Java EE ในรูปแบบก่อนหน้านี้สิ้นสุดลงแล้ว มันจะนำพาความสบายใจหรือไม่ นั้นคือสิ่งที่เราต้องรอดู.

บัลลังก์ที่ครอบครองมานานนั้นสิ้นสุดลงแล้ว!

สิ่งใดจะเป็นมาตราฐานสำหรับ “Java EE ใหม่” แล้ว EE4J จะปฏิบัติตามกฎของที่ปราศจากการสนันสนุนของ JCP อย่างไร?

มันขึ้นอยู่กับว่ามันจะเริ่มเร็วแค่ไหนและให้ผลลัพธ์ที่เป็นรูปธรรม ในความเห็นอย่างน้อยจะมีปัจจัยที่มีอิทธิพลดังนี้

  1. เวลา อย่างที่ทราบกัน แม้ว่า Java EE8 นั้นมีค่าแต่นั้นไม่ได้ถูกยกให้มีความล้ำสมัย ช่องว่างนี้จะต้องถูกแก้ไขให้เร็วที่สุดเท่าที่จะเป็นได้ เพื่อให้กลับเข้าสู่ตลาดการแข่งขัน มันจะกลายเป็นเรื่องยากถ้า EE4J ใช้เวลาหลายเดือน “เพียงแค่” ส่งมอบ Java EE8 ที่เป็นที่ยอมรับ.
  2. การทำงานร่วมกันกับ Microprofile.io นั้นได้เริ่มหลังจากที่มีการเดินหน้าทำ cloud-native applications ซึ่งนั้นดึงดูดให้ EE4J มีพลังขึ้นมา!
  3. กลุ่มผู้พัฒนา จะสร้างความแข็งแรงและความว่องไวให้กับกลุ่มคนพัฒนา EE4J ได้อย่างไร ใครจะเป็นตัวละครถัดไปที่ได้รับความสนใจในนี้
  4. ก็เรื่องเวลาอีกนั้นแหละ บริษัทผู้พัฒนาและ Open Source projects สามารถที่จะส่งมอบ EE4J ที่เป็นที่ยอมรับ ได้อย่างตรงเวลา หนึ่งในปัญหาที่ทำให้ Java EE นั้นล่าช้ามากเกิดขึ้นระหว่าง version ล่าสุดที่กำหนดไว้และ versionที่ใช้อยู่ใน application servers.

ในตอนนี้ผมชอบในข้อดีของมัน งั้นมาดูกันว่าจะเกิดอะไรขึ้นในปีถัดไปที่จะถึงนี้!

เรามาคอยติดตามผ่าน EE4J user mailing list และ EE4J PMC mailing list กัน.