J2EE และ EJB (Java 2 Enterprise Edition and Enterprise Java Bean) Cont.

02:18 เขียนโดย QA Optimization - Performance and Stability






















จากรูปที่ 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 เป็นการกำหนดให้ 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 ที่นิยมแพร่หลายอยู่ในปัจจุบัน


0 ความคิดเห็น:

แสดงความคิดเห็น