J2EE คืออะไร

J2EE คืออะไร

ก่อนที่จะทราบถึงความหมายของ J2EE มาทำความเข้าใจกับคำว่า Middleware กันก่อน Middleware คือ ซอฟต์แวร์ประเภทหนึ่งที่ทำหน้าที่เป็นตัวกลาง เป็นตัวประสานและบริการ Service ต่างๆ ให้กับ Application เช่น การทำ Load Balancing , Transaction, Resource Pooling และ Message Oriented Service เป็นต้น ซึ่งในระบบงานขนาดใหญ่ (Enterprise Application) จำเป็นต้องใช้งาน Service เหล่านี้เป็นอย่างมาก ซึ่งในอดีต องค์กรต่างๆ ได้พัฒนาซอฟต์แวร์ประเภท Middleware ขึ้นมาใช้งานเอง โดยจะมี Service ต่างๆ แล้วแต่ละองค์กรจะพัฒนาขึ้นมา
ในปัจจุบันความต้องการ Service ของ Middleware มีมากขึ้น เพื่อรองรับการดำเนินงานทางธุรกิจที่มีความสลับซับซ้อนมากขึ้น จึงต้องการระบบงานที่ยืดหยุ่นสามารถรองรับการเปลี่ยนแปลงได้อย่างรวดเร็ว เพื่อให้สามารถแข่งขันกับคู่แข่งทางธุรกิจได้ ประกอบกับการที่จะพัฒนา Middleware ขึ้นมาใช้เองนั้น เป็นเรื่องที่ยาก มีโอกาสที่จะล้มเหลวสูง ด้วยสาเหตุดังกล่าว จึงได้มีผู้มีผลิต Middleware ออกมาจำหน่าย โดยเรียกว่า Application Server จึงจะบรรจุ Service ต่างๆ ไว้ ทำให้ องค์กรไม่ต้องพัฒนา Service ขึ้นใช้เอง ซึ่งจะทำให้องค์กรมุ่งคิด หรือทำเฉพาะที่เป็น Business Logic ใน Business Domain ของตัวเองเพียงอย่างเดียวเท่านั้น วิธีการก็คือพัฒนาซอฟต์แวร์ขึ้นมา แล้วนำไป Deploy บน Application Server ที่เตรียมสภาวะแวดล้อมขณะ Runtime ไว้ให้ โดยมีการประกาศความต้องการ Service ให้ Application Server เตรียม Service ต่างๆ ไว้บริการ
J2EE ก็คือ Specification ของ Application Server ซึ่งมีบริษัท Sun Microsystem เป็นเจ้าภาพ โดยเชิญ บริษัทต่างๆ มากมาย มาร่วมกันจัดทำ ซึ่งจะทำให้ Specification ที่ได้สามารถตอบสนองกับความต้องการของผู้ใช้ และผู้สร้างได้เป็นอย่างดี ซึ่งตรงนี้เป็นจุดแข็งจุดหนึ่งของ J2EE เพราะทำให้ไม่เกิดการกำหนด Specification ที่เอื้อประโยชน์กับบริษัท Software บริษัทใด บริษัทหนึ่ง

EJB คืออะไร

ก่อนที่จะทำความเข้าใจเกี่ยวกับ EJB จำเป็นที่จะต้องทำความเข้าใจเกี่ยวกับ การพัฒนาซอฟต์แวร์ แบบ Software Component
Software Component เป็นการมอง ซอฟต์แวร์เป็นชุดๆ ส่วนๆ ที่สามารถทำงานบางสิ่งบางอย่างได้ในตัวของมันเอง ซึ่งจะทำให้สามารถนำ Software Component มาประกอบกันเพื่อทำเป็น Application ใช้ในองค์กร เช่น Software Component ด้านการกำหนดราคา Pricing Component (รูปภาพทั้งหมดนำมาจากหนังสือ Mastering EJB Second Edition ของ Ed Roman) ดังรูป

รูปที่ 1

จากรูปที่ 1 แสดงให้เห็นถึงการใช้งาน Pricing Component ติดต่อกับ Legacy System ซึ่งเป็นระบบเก่า โดย User ติดต่อผ่าน Dumb Terminal หรือ Work Station

รูปที่ 2

จากรูปที่ 2 เป็นการแสดงให้เห็นการทำงานในแบบ Web Application ที่ใช้ Pricing Component ในการทำงาน โดยมี Client เป็น Web Browser

รูปที่ 3

จากรูปที่ 3 แสดงให้เห็นการพัฒนา Application ที่นำ Software Component 3 Component มารวมกัน คือ Pricing Component, Billing Component และ Fulfillment Component มาประกอบกัน
จากตัวอย่างข้างต้น จะพบว่า การพัฒนาซอฟต์แวร์เป็น Component มีข้อดี คือ มีโอกาสที่จะนำ Component มาใช้ใหม่ได้สูง (Reusibility) ซึ่งจะทำให้ใช้เวลาพัฒนาระบบงานโดยรวมน้อยลง และในตัว Component เอง ก็จะนำ Business Logic ที่ดีที่นิยมใช้ในวงการนั้นๆ มาใช้ (Best Practice) ซึ่งทำให้องค์กรได้รับประโยชน์สูงสุด คือได้ใช้ Business Logic ที่ดี โดยไม่ต้องคิดตั้งแต่เริ่มต้น และในขณะเดียวกัน การพัฒนาเปลี่ยนแปลง Business Logic ให้ดีขึ้นเรื่อยๆ ก็สามารถทำได้ โดยไม่กระทบการใช้งาน ของ Client เลย
เนื่องจาก บริษัทที่ ผลิต Component ก็จะพัฒนา Application Server ขึ้นเองด้วย ปัญหาก็คือผู้ใช้งาน เมื่อซื้อ Software Component มาใช้งานแล้ว ถ้าต้องการเปลี่ยน Application Server ก็ไม่สามารถทำได้ เพราะ Software Component นั้น ไม่สามารถ Deploy และ Run บน Application Server ตัวใหม่ได้ ฉะนั้น ความต้องการ มาตรฐานของ Software Component จึงเกิดขึ้นเพื่อที่จะทำให้ Software Component สามารถที่จะ Deploy และ Run ได้กับทุก Application Server จึงเกิดการสร้าง Component Architecture ขึ้นมา ดังรูป

รูปที่ 4

จากรูปที่ 4 เป็นการกำหนดให้ Software Component ให้ปฏิบัติตามข้อตกลงที่อยู่ใน Component Architecture โดยต้องมี Interface ที่กำหนดไว้ ผลก็คือ เมื่อนำ Component ไป Run บน Application Server ที่ยึดถือตาม Component Architecture เดียวกัน ก็จะสามารถ Run ได้อย่างไม่มีปัญหา

EJB ก็คือ Component Architecture หรือข้อตกลง (Agreements) การทำงานของร่วมกันระหว่าง Software Component กับ Application Server (ในที่นี้ก็คือ J2EE Server) โดย EJB หรือ Enterprise Bean จะเป็น Software Component ที่ Run ในฝั่งของ Server (Server - Side) ในลักษณะ Distributed Component โดย EJB จะต้องเขียนด้วยภาษา Java เท่านั้น
ในลักษณะเช่นนี้ ทางด้าน Microsoft ก็มีเช่นเดียวกัน เรียกว่า .NET Managed Component ซึ่งจะ Run บน Application Server (MTS/COM+) ของ Microsoft เท่านั้น แล้วต้องเขียนด้วยภาษาที่ใช้เทคโนโลยี .NET เช่น VB.NET หรือ C# เป็นต้น และ อีกหนึ่ง Component Architecture เป็นของหน่วยงาน OMG (Object Management Group) ได้จัดทำข้อกำหนดไว้คือ CORBA (Common Object Request Broker Architecture) ในส่วนนี้สามารถใช้ภาษาใดๆ ก็ได้ ที่ Support มาตรฐาน CORBA ในตรงจุดนี้ EJB Servers ส่วนใหญ่ก็สามารถใช้งานหรือติดต่อกับ Software Component ของ CORBA ได้เช่นกัน
แทรกเพิ่มเติม!(Web Services) จากตรงจุดนี้เอง ที่ทำให้เกิดมาตรฐาน Web Services ขึ้นมา เพื่อให้สามารถเรียกใช้งาน Software Component ได้โดยไม่ขึ้นกับ Platform โดยใช้เทคโนโลยี XML (Extensible Markup Language) เป็นตัวกำหนด Interface ของ Component และมาตรฐานส่วนอื่นๆโดยแบ่งออกเป็น 3 ส่วน คือ SOAP (Simple Object Access Protocal), WSDL (Web Service Definition Language) และ UDDI (Universal Description and Discovery Integration) ซึ่งทั้งหมดนี้จะใช้งานบน HTTP/HTTPS ซึ่งเป็น Protocal ที่นิยมใช้ในปัจจุบัน ซึ่งทำให้สามารถ Component สามารถให้บริการผ่าน Web ได้ และเพื่อให้มีการใช้กันได้อย่างแพร่หลาย
ในส่วนของ Web Service WSDL จะเป็นตัวกำหนด Interface ของ Component ส่วน SOAP จะเป็นรูปแบบการเรียกใช้งาน Component แบบข้ามเครื่อง ข้ามเครือข่าย และ UDDI จะเป็นเหมือนฐานข้อมูลที่เก็บที่อยู่ และบริการของ Software Component ซึ่งสามารถเข้าไปค้นหา Component ที่ต้องการได้ โดย UDDI จะเก็บ WSDL ของแต่ละ Component ไว้ เมื่อทราบ Interface ก็สามารถ เขียน SOAP เพื่อเรียกใช้งาน Component ได้ต่อไป
ตารางแสดงการเปรียบเทียบเทคโนโลยี Software Component แบบ Distributed


จากตาราง แสดงให้เห็นว่า ในส่วน Component Architecture นั้นมี 2 ค่ายยักษ์ใหญ่ คือ Sun กับ Microsoft โดยมี OMG เป็นตัวเชื่อมทั้งสองค่ายเข้าด้วย แต่ในขณะเดียวกัน Web Services ซึ่งเป็นมาตรฐานใหม่ เริ่มได้รับความนิยม เพราะมันไม่ขึ้นกับ Platform โดยอาศัยเทคโนโลยี XML และใช้งานผ่าน HTTP/HTTPS ที่นิยมแพร่หลายอยู่ในปัจจุบัน

รูปที่ 5

จากรูปที่ 5 เป็นตัวอย่างแสดงสถานการณ์การทำธุรกิจในลักษณะ B2B โดยมี EJB เป็น Software Component ของระบบงานหนึ่งใน บริษัท Intel แล้วมี บริษัท Dell เป็นผู้ใช้บริการ โดยใช้ SOAP , UDDI , ebXML และ WSDL

การใช้งาน EJB
1.ทำ Business Logic เช่น การคำนวณภาษี การคิดราคาสินค้า หรือการส่งจดหมายอิเลค-ทรอนิกส์โดยใช้ API ที่ชื่อว่า Java Mail เป็นต้น
2. ทำ Database Logic โดยใช้ API ที่ชื่อว่า JDBC (Java Database Connectivity)
3. ติดต่อกับ Legacy System หรือระบบอื่นๆ โดยใช้ API ที่ชื่อว่า JCA (JavaBean Connector Architecture)

ความแตกต่างระหว่าง GUI กับ EJB
มองในแง่การใช้งาน GUI จะใช้งานทางฝั่ง Client เป็นหลัก (Client Side Operation) ส่วน EJB จะเป็นใช้งานทางฝั่ง Server เป็นหลัก (Server Side Operation)
ตัวอย่างหน้าที่ของ GUI (Graphic User Interface)
1. Thick Client เช่น Applet หรือ Java Application
2. Dynamic Web Page เช่น Applets หรือ JSP
3. XML-base Web Service ซึ่งในส่วนนี้บางทีอาจจะไม่ต้องการ GUI เลยก็ได้
ตัวอย่างหน้าที่ของ EJB
1. Executing complex algorithms ทำหน้าที่ประมวลผลต่างๆ
2. ทำ Transaction จำนวนมาก
3. รองการทำงาน 24 x 7 , fault-tolerant , transactional and security environment ซึ่งทั้งหมดนี้ Application Server จะสร้างสภาวะการทำงานให้ EJB ทำงาน (ทำให้ EJB มุ่งที่ Business Logic อย่างเดียว บริการอื่นๆ Applicaton Server จะจัดเตรียมไว้ให้)

EJB Ecosystem
EJB Specification ได้ให้คำแนะนำในการแบ่งกลุ่มของการทำงานต่างๆ ของสภาวะแวดล้อมในการพัฒนา EJB ไว้ 6 กลุ่ม เพื่อให้เกิดประสิทธิภาพ ซึ่งในความเป็นจริง ไม่จำเป็นต้องปฏิบัติตามก็ได้ กลุ่มต่างๆ แสดงได้ ดังรูป

รูปที่ 6

1. Bean Provider เป็นผู้ผลิต EJB ซึ่งจะประกอบด้วย Business Logic Support ให้กับธุรกิจประเภทต่างๆ
2. EJB Containment/Server Provider เป็นผลิต Application Server ตัวอย่าง Web Sphere ของ IBM หรือ JBOSS เป็นต้น
3. Application Assembler จะเป็นผู้ที่นำ Component EJB มาประกอบกันเป็น Application ตามที่ต้องการ
4. Tool Provider จะเป็นผู้ผลิต เครื่องมือต่างๆ เพื่อลดระยะเวลาในการพัฒนา เพิ่มความสะดวกให้กับผู้พัฒนา
5. Deployer เป็น จัดทำให้ Component EJB Deploy และ Run บน Application Server ได้
6. System Administrator หรือ Maintain Deployment เป็นผู้ดูแลระบบงานหลังจาก Deploy แล้ว
จากองค์ประกอบ ทั้ง 6 กลุ่ม ทำให้เห็นผู้ที่ต้องเข้ามาเกี่ยวข้องกับการพัฒนา EJB และได้เห็นขั้นตอนการทำงานโดยรวมของการพัฒนา Application

ความแตกต่างระหว่าง Java Bean และ EJB
Java Bean คือ การพัฒนาพัฒนา Java Class File ที่มี Method Set/Get มีความสามารถในเรื่อง ของ Event Handling , Propoties และ Methods (จะคล้ายกับ ActiveX Component ของ Microsoft) ซึ่ง Java Bean สามารถนำมาประกอบกัน ให้เป็น Java Appliation ได้
ในส่วนของ Java Bean จะมีขนาดเล็ก กว่า EJB มาก Java Bean จะมีลักษณะ Development Component แต่ส่วน EJB จะมีลักษณะ Deployment Component ทำให้ Java Bean ไม่ต้องการ Application Server เป็น Runtime Environment ที่จะบริการ Service ต่างๆ ให้ เช่น การ Instanciate Class ซึ่งใน Java Bean ตัว Application เองจะเป็นผู้ควบคุมการ Instanciate Class Java Bean แทน และ สามารถใช้ EJB ใน Application ที่มีขนาดใหญ่ ได้ดีกว่า Java Bean

J2EE Technology
ในการนำ J2EE มาใช้งาน จะต้องใช้พื้นฐาน จาก J2SE มาใช้งานด้วย ซึ่งจะพบว่า การทำงาน ใน J2EE เป็นการทำงานที่มีขนาดใหญ่มากพอสมควร ดังแสดงในรูปที่ 7 ใน J2EE จะประกอบด้วย API ต่างๆ ดังนี้
1. EJB Specification ซึ่งใน J2EE Version 1.3 จะ Support EJB 2.0
2. Java Remote Method Invocation (RMI) และ RMI/IIOP RMI เป็นการเรียกใช้งาน Component ข้ามเครื่อง (Distributed Component) ส่วน RMI/IIOP นั้นเป็นส่วนที่มีความสอดคล้องกับ CORBA
3. Java Naming and Directory Interface (JNDI) เป็นส่วนที่ติดต่อกับการใช้ Resource ต่างๆ เช่น การติดต่อใช้ EJB ก็ต้องใช้ JNDI ในการติดต่อ
4. Java Database Connectivity (JDBC) ใช้ในการติดต่อฐานข้อมูลเชิงสัมพันธ์ต่างๆ (Relational Database)
5. Java Transaction API (JTA) และ Java Transaction Service (JTS) ใช้การทำ Transaction ของระบบงาน ถ้าจะทำการเขียนเอง ก็ใช้ JTA แต่จะใช้บริการ Application Server ก็จะใช้ JTS
6. Java Message Service (JMS) เป็นการใช้การติดต่อโดยใช้ Message แทน ซึ่งเป็นแนวคิดใหม่ที่จะใช้กับ RMI/IIOP โดยจะส่ง Message ไปยัง Message Oreinted Middleware (MOM) เพื่อเข้าคิว แล้วตัว MOM จะส่ง Message ไปให้แทน จะใช้ในกรณีที่ไม่ต้องการทำงานแบบ Transaction หรือ Realtime มีข้อดีคือ จะรับประกันการส่ง Message ว่าไม่มีการสูญหาย ส่งถึงผู้รับแน่นอน
7. Java Servlet เป็น Server - Side Component ชนิดหนึ่ง ที่ใช้หลัก Request/Response ซึ่งต่างจาก EJB ที่ต้อง Run บน Application Server
8. JavaServer Page เป็น ภาษา Script ที่ทำหน้าที่คล้ายกับ Servlet มาก เพราะจะต้องแปลง JSP ไปเป็น Servlet เหมาะสำหรับการ Presentation ของ Web Page
9. Java IDL (Interface Definition Language) เป็นการนำ Specification ของ CORBA มาใช้ใน Java
10. Java Mail เป็น API ที่ใช้ในการเขียน โปรแกรมรับส่ง E-Mail
11. JavaBean Connector Architecture เป็นการเขียนโปรแกรมเพื่อเชื่อมต่อรับ Legacy System หรือ ระบบงาน อื่นๆ เช่น ระบบงาน ของ Business Partner เป็นต้น
12. Java API for XML Parsing/Processing เป็นชุด API ที่ใช้เขียนโปรแกรมร่วมกับ เทคโนโลยี XML
13. Java Authentication and Authorization Service (JAAS) เป็น API ที่ดูแลเกี่ยวกับระบบรักษาความปลอดภัย

จากรายการ API ข้างต้นทั้งหมด จะพบว่า J2EE ได้จัดเตรียม API ชุดใหญ่ ไว้อย่างเพียบพร้อมที่จะให้นักพัฒนาที่ต้องการพัฒนาระบบงานในระดับหน่วยงานขนาดใหญ่ได้เป็นอย่างดี ซึ่งทั้งนี้จะต้องรวมกับชุด API ในส่วนของ J2SE ด้วย เช่น AWT, IO หรือ NET เป็นต้น

รูปที่ 7

จากรูปที่ 7 เป็นการแสดงการนำ J2EE มาใช้งาน จะพบว่า แบ่งเป็น 3 ส่วน คือ Client Tier จะประกอบไปด้วย Web Browser , Wireless Device, Business Partner โดยใช้ Web Services และ CORBA Client และมีในส่วนของ Application Server ที่ยึดตาม Specification ของ J2EE เราอาจเรียกว่า J2EE Server จะเป็นแบ่งได้เป็น Servlet/JSP , EJB หรือ Connector ต่างๆ ในส่วนที่ 3 คือ ส่วนที่เป็น Back End ก็คือส่วนที่เป็น Database หรืออาจจะเป็น Legacy System หรือ จะเป็นระบบงานของ Business Partner ก็ได้

หลัก Distributed Object

รูปที่ 8

จากรูปที่ 8 แสดงการใช้งาน ของ Distributed Object จะพบว่า ในส่วนของ Client นั้นจะมี Stub และในส่วนของ Distributed Object จะมี Skeleton ซึ่งในส่วนของ Stub จะมี Remote Interfaces ที่เหมือนกับทางด้าน Distributed Object ด้วยวิธีนี้ ทำให้ Client ไม่รับรู้ว่าได้เรียกใช้ Object ที่ต่างเครื่องกันอยู่ ซึ่งสามารถทำได้โดยใช้มาตรฐานต่างๆ ได้มากมาย เช่น RMI/IIOP, CORBA หรือ DCOM

Distributed Object and Middleware
แบ่ง Middleware ออกเป็น 2 ประเภท คือ
1. Explicit Middleware
2. Implicit Middleware

Explicit Middleware

รูปที่ 9

จากรูปที่ 9 แสดงให้เห็นถึงการทำงานของ Middleware แบบ Explicit ซึ่งในตัวของ Distributed Object จะเป็นผู้เรียกใช้ API เอง ดังตัวอย่าง Psudo-code ดังรูปที่ 10

รูปที่ 10

จากรูปที่ 10 จะพบว่า ใน Psudo-code นั้นจะมีการเรียกใช้ API ในด้านต่างๆ เช่น Security Check , Transation และ JDBC และมีส่วนที่เป็น Business Logic ในบรรทัดที่ 4
ปัญหาในการเขียน Object แบบนี้ คือ ต้องเรียนรู้การใช้ API ต่างๆ มากมาย ทำให้เขียนยาก และเมื่อมีการเปลี่ยนแปลง API ก็ต้องเข้าไปเปลี่ยนแปลงใน Code ใน Object ด้วย ทำให้การ Maintainence ยาก

Implicit Middleware

รูปที่ 11

จากรูปที่ 11 จะพบว่า จะมี Request Interceptor เป็นตัวคั้นกลางระหว่าง Skeleton ที่จะเรียกใช้งาน Distributed Object และ ตัว Request Interceptor จะเป็นผู้ที่ทำหน้าที่ใช้ในการเรียกใช้งาน API ต่าง ๆ แทน ทำให้ Code ที่เขียนใน Distributed Object เหลือเพียงแต่ Business Logic เพียงอย่างเดียว ดังตัวอย่าง Psudo-codeในรูปที่ 12

รูปที่ 12

จากรูปที่ 12 จะเห็นว่าในส่วน ของ Distributed Object จะเหลือ Code ในส่วนที่เป็น Business Logic เท่านั้น โดยในการติดต่อการใช้ API อื่น ๆ จะเป็นหน้าที่ของ Request Interceptor แทน ซึ่งเป็นการทำให้ Distributed Object รับหน้าที่ในการทำ Business Logic เพียงอย่างเดียว ทำให้สะดวกในการพัฒนาเป็นอย่างมาก และ Loose Coupling กับ API ต่างๆ คือ ถ้า เปลี่ยนแปลง API ก็ไม่กระทบกับ Business Logic และ การเปลี่ยนแปลง Business Logic ก็ไม่กระทบกับ API ด้วยเช่นกัน ทำให้ง่ายกับการ Maintainence เป็นอย่างมาก

การนำ Implicit Middleware มาใช้ใน J2EE

รูปที่ 13

จากรูปที่ 13 พบว่า EJB Object จะทำหน้าที่เป็น Request Interceptor คือ เป็นตัวดักการเรียกใช้ งาน EJB จาก Client ไม่ว่าจะเป็น Servlet หรือ JSP ก็ตาม โดย EJB Object จะทำหน้าที่ในการติดต่อกับ EJB แทน และยังเรียกใช้งาน API แทนด้วย โดยทั้งหมดทำงานภายใต้ EJB Container/Server

The Home Interface

รูปที่ 14

จากรูปที่ 14 เมื่อ Client ต้องการสร้าง EJB Object จะสร้างโดยผ่าน Home Object ซึ่ง Home Object จะสร้างโดย Client โดยใช้ Method ที่บรรจุอยู่ใน Home Interface เมื่อสร้างแล้ว Home Object จะส่งค่า EJB Object Reference กลับไปให้ Client เพื่อใช้เรียก Business Logic ใน EJB โดย EJB Object ก็จะทำการ Intercept Request จาก Client แล้วส่งต่อไปให้ EJB ทำงานต่อไป

The Local Interface
เป็น Specification ที่เป็นเพิ่มเข้าใน EJB 2.0 ซึ่งเป็นการตัดทอนการทำงานในส่วนของ Stub และ Skeleton ซึ่งเป็นส่วนที่ใช้เวลานาน (Overhead) Local Interface จะใช้ในกรณีที่ การเรียกใช้กับกับ EJB อยู่ใน Process เดียวกัน ซึ่งจะช่วยลดเวลาการทำงานได้ดีขึ้นอย่างมาก
Local Interface จะทำหน้าที่ Remote Interface และ Local Home Interface จะทำหน้าที่แทน Home Interface โดยมี Local Object แทน EJB Object และ Local Home Object แทน Home Object

Deployment Descriptor
เป็นไฟล์ในรูปแบบ XML ที่แสดงการใช้งาน ทำให้ Middleware ทราบว่า จะต้องใช้บริการต่างๆ อย่างไร กับ EJB ที่ถูกเรียกใช้งาน เช่น ให้ทำหรือไม่ต้องทำ Transaction , Security และอื่นๆ เป็นต้น

EJB - jar File

รูปที่ 15

จากรูปที่ 15 เป็นการรวบรวมไฟล์ต่างๆ ที่จะใช้ Deploy ลงใน Application Server ให้อยู่ในรูปแบบที่เรียกว่าไฟล์ EJB-jar ซึ่งจะขึ้นอยู่ Application Server ว่าจะต้องทำอย่างไร

ประเภทของ EJB
EJB แบ่งออกได้เป็น 3 ประเภท ดังนี้
1. Session Bean เป็น EJB ที่เน้นถึงการกระทำ ของ Business Logic แบ่งเป็น 2 ชนิด ย่อย ๆ คือ Stateless Session Bean และ Stateful Session Bean โดยที่ Stateless Session Bean จะไม่การเก็บสถานะ แต่ Stateful Session Bean จะมีการเก็บสถานะการติดต่อไว้ได้ เพื่อใช้ประโยชน์ในการทำ Transaction
2. Entity Bean เป็น EJB ที่เน้นถึงสิ่งที่ต้องการเก็บข้อมูล แบ่งย่อยๆ ตามวิธีการ Persistent ได้ 2 อย่าง คือ แบบ Container Managed Persistent (CMP) ซึ่งจะให้ Container เป็นผู้จัดการทำให้แทน กับ แบบ Bean Managed Persistent (BMP) โดยภายในตัว EJB จะมี Logic ที่จัดการทำเอง ซึ่งตรงนี้สามารถกำหนดได้ใน Deployment Descriptor นั่นเอง
3. Message-Driven Bean เป็น EJB ที่ใช้ในการทำงานที่เกี่ยวกับ Message เป็นหลัก ซึ่งจะบรรจุ Message-Oreinted Logic เพื่อให้ Client เรียกใช้งาน

รูปที่ 16

รูปที่ 16 แสดงการใช้งาน EJB ประเภทต่างๆ จาก Client ต่างๆ จะพบว่า EJB สามารถที่จะเรียกกันและกันได้ด้วย จากรูปจะพบว่า จะใช้ Session Bean เป็นตัวควบคุมการทำงานของ Entity Bean หรือ ไปควบคุม Session Bean ตัวอื่นๆ จากรูปยังแสดงให้เห็นในกรณีที่ Web Server แยกกับ Application Server ซึ่ง ทั้ง Servlet และ JSP จะใช้ RMI/IIOP ในการเรียกใช้ EJB แต่ถ้าเป็น C++ Client จะใช้เป็น CORBA/IIOP แทน ซึ่งในส่วนของ Client ถ้าเป็น Browser ก็ใช้ HTTP แต่ถ้าเป็น Business Partner ก็ใช้ Protocol ต่างๆ ที่อยู่ใน Web Services แทน

ตัวอย่างการพัฒนา EJB Component (Session Bean)

รูปที่ 17

จากรูปที่ 17 แสดง Component Diagram ก็จะพบว่า สิ่งที่จะทำการเขียน ก็คือ 1. Local Interface 2.Remote Interface 3. Home Interface และ 4. Local Home Interface 5. Bean File โปรแกรมจะเป็นการทำงานง่ายๆ คือ พิมพ์คำว่า Hello World ออกมา และสุดท้าย ก็เขียนโปรแกรม Client เพื่อทดสอบการเรียกใช้งาน EJB
หลังจากที่จัดทำ ไฟล์ต่างๆ ทั้งหมดเสร็จแล้ว จะต้อง จัดทำไฟล์ Deployment Descriptor เพื่อนำไปรวมกับไฟล์ Bean ต่างๆ 5 ไฟล์ แล้วจัดทำเป็น EJB-jar ไฟล์ แล้วนำไป Deploy บน Application Server เพื่อให้ Client ต่างๆ เรียกใช้งานได้ต่อไป
หน้าต่อๆ ไป จะเป็นการแสดงตัวอย่าง Code ในการพัฒนา Session Bean แบบ Stateless ไล่เรียงกันไปดังนี้
1. Remote Interface (Hello.java)
2. Local Interface (HelloLocal.java)
3. Home Interface (HelloHome.java)
4. Local Home Interface (HelloLocalHome.java)
5. Bean Class (HelloBean.java)
6. Deployment Descriptor (ejb-jar.xml)
7. Client Class (HelloClient.java)

Remote Interface (Hello.java)



Local Interface (HelloLocal.java)



Home Interface (HelloHome.java)



Local Home Interface (HelloLocalHome.java)



Bean Class (HelloBean.java)



Deployment Description (ejb-jar.xml)



Client Class (HelloClient.java)




การร้องขอ Home Interface จาก JNDI





สรุป
J2EE คือ Specification ของ Middleware หรือ Application Server ที่บริษัท Sun เป็นเจ้าภาพในการกำหนด Specificaton ร่วมกับบริษัทอื่นๆ ทำให้ Specification ได้รับการยอมรับอย่างกว้างขวาง ส่วน EJB คือ Component Architecture Specification ของ Distributed Software Component ทั้งนี้เพื่อให้ Software Component สามารถมีโอกาสที่จะ Reusibility ได้สูง และ มีความ Portability ที่จะ Deploy บน Application Server ที่มี Service ไว้บริการแก่ Software Component เช่น Transaction Management , Resource Pooling และอื่นๆ ได้

ศัพท์ที่ควรทราบในเอกสารนี้
1. Interface / Implementation เป็นการแบ่งส่วนที่เป็นการนิยาม method หรือ function ออกจากส่วนที่มี Code ที่ทำงานจริงๆ ในส่วนที่นิยาม เรียกว่า Interface และในส่วนที่ทำงานจริงๆ เรียกว่า Implementation ซึ่งในตัวภาษา Java Support การ Coding ในลักษณะนี้

หัวข้อที่น่าสนใจ ที่สามารถศึกษาเพิ่มเติม
1. เรียนรู้ EJB ทั้ง 3 ชนิดอย่างละเอียด คือ
1.1 Session Bean
1.2 Entity Bean
1.3 Message-Driven Bean
2. เรียนรู้ Advanced concept
2.1 Transaction and Distributed Transaction
2.2 Design Pattern ของ GOF (Gang of Four) และ Design Pattern ของ EJB
2.3 การจัดทำ Application โดยใช้ Model-View-Control (MVC) Pattern ซึ่งจะประกอบไปด้วย EJB-JSP-Servlet
2.4 Service Oriented Architecture (SOA)
2.5 Low Coupling - High Cohesion Strategy
2.6 Declarative Programming
2.7 Executable UML , Model Driven Architecture (MDA)
3. เรียนรู้การใช้งาน Application Server ต่างๆ เช่น Websphere , JBOSS , Web Logic
3.1 การ Deployment ไฟล์ EJB-jar
3.2 การ Admin และ Maintenance
3.3 Feature พิเศษ ใน Application Server ของแต่ละค่าย
4. เรียนรู้การใช้ Tools ที่จะช่วยลดระยะเวลาในการพัฒนางาน ใน J2EE