Java Architecture on the Web

  โดย  ประดับเก่ง

 
เกริ่นนำ
หลักจากที่เราเขียนโปรแกรมด้วยจาว่ากันมาพอสมควรแล้ว วันนี้เรามาคุยกันถึงวิวัฒนาการของ Server Side Application ที่ถูกใช้บนเวปตั้งแต่สมัยแรก ๆ จนถึงปัจจุบันกันซักนิดหนึ่งดีกว่า ถ้าใครจำได้จะเห็นว่าสมัยแรกสุดตอนที่มีเวปเกิดขึ้นมาใหม่ ๆ ส่วนประกอบหลักของเวปไม่ค่อยจะมีอะไรซักเท่าไหร่ เริ่มแรกสุดก็ทำกันอย่างง่าย ๆ โดยใช้หลักการพื้นฐานของ client/server architecture ซึ่งส่วนที่เป็น client ในเวปก็คือ web browser ยกตัวอย่างเช่น NCSA Mosaic, Lynx, Netscape และส่วนที่เป็น server ซึ่งก็คือ web server (ตอนนั้นจะมีแค่ NCSA web server ซึ่งเป็นต้นแบบของ Apache web server) นั่นเอง โดยทั่วไป web server หนึ่ง ๆ จะสามารถบริการส่งข้อมูลให้ตัว web browser ได้หลายตัว ซึ่งถ้าพูดกันแบบภาษาชาวบ้านก็คงจะเป็นลักษณะที่คนหลายคน (multiple clients) สามารถที่จะเข้าไปดูข้อมูลต่าง ๆ จากเวปไซด์เดียวกัน (1 server) ได้ในเวลาเดียวกันนั่นเอง


รูปที่  1. เบสิค client/server architecture เริ่มแรกสุดที่ใช้กันบนเวป

ต่อมาทั้งคนทำเวปและคนดูเวปก็คงจะเริ่มเบื่อจึงช่วยกันคิดค้นหาวิธีที่ทำให้เวปมีสีสันมากขึ้น  เทคโนโลยีที่เกิดขึ้นตามมาก็คือ CGI (Common Gateway Interface) หลักการของ CGI ก็ไม่มีอะไรมาก หลักการก็คือแทนที่ข้อมูลที่เราส่งไปให้ web server (โดยผ่านทาง web browser) จะถูก process โดยตัว web server อย่างเดียว ข้อมูลนี้ก็อาจจะถูกส่งไปให้อีกโปรแกรมหนึ่งซึ่งตัวโปรแกรมนี้จะสามารถถูกเรียกได้โดย web server เพื่อทำการประมวลผลข้อมูลที่มาจากเรา โดยทั้งนี้ข้อมูลของเราจะถูก process ที่ใดก็ขึ้นอยู่กับ Setting ต่าง ๆ ที่ทางเวปไซด์ที่เราเข้าไปดูกำหนดขึ้นมา ยกตัวอย่างเช่น ถ้าเราต้องการดูเพจธรรมดา ๆ หลักจากที่เราคลิกไปที่ตัวลิงค์ตัว web server ก็จะไปอ่านเพจ (html ไฟล์) ที่เราต้องการแล้วส่งกลับมาเป็น text stream ให้เรา แต่ถ้าเราต้องการที่จะ post ข้อความลงไปในเวป ทาง web server ก็จะส่งข้อความที่เราพิมพ์ไปให้โปรแกรมที่ทำหน้าที่ดูแลและเก็บข้อความที่เราส่งเข้าไป ยกตัวอย่างเช่นโปรแกรม message board เป็นต้น เทคโนโลยี CGI นี้สามารถเขียนขึ้นโดยภาษาอะไรก็ได้แต่ภาษาที่นิยมใช้กันอย่างกว้างขวางก็มักจะเป็น Perl และ C ตัวอย่างของ CGI Application ที่เราพบเห็นกันอยู่ในปัจจุบันก็อาจจะเป็น Counter, Guestbook, Message Board, Send Mail หรือแม้กระทั่งโปรแกรมส่งเพจ (Paging) เป็นต้น


รูปที่ 2. การ post ข้อความไปยัง CGI โปรแกรม


หลักจากที่ CGI กลายเป็นที่นิยมจนเป็นส่วนหนึ่งของ WWW Standard แล้ว Server Side Application ที่เป็นลูกหลานก็เกิดขึ้นกันมาอย่างมากมาย ยกตัวอย่างเช่น ASP, PHP, ColdFusion, Servlet และอื่น ๆ (อย่างไรก็ตามบทความนี้จะกล่าวถึงเทคโนโลยีที่เกี่ยวข้องกับ Server Side Application ที่ใช้จาว่า platform เป็นหลักเท่านั้น)

Java Servlet
จาว่ามีสโลแกนอันหนึ่งที่กล่าวไว้ว่า "สิ่งใดก็็ตามที่เป็นที่นิยมใช้กันอย่างกว้างขวาง ท้ายที่สุดสิ่งนั้นจะกลายเป็นจาว่า library" โดยผลพวงหนึ่งที่มาจากสโลแกนอันนี้ก็คือ Servlet นั่นเอง
Servlet อ้างอิงหลักการของ CGI โดยข้อดีของ Servlet ที่อยู่เหนือ CGI อย่างแรกก็คือตัวภาษาที่ใช้เขียนซึ่งก็คือจาว่านั่น จาว่าเป็นภาษาที่ใช้คอนเซ็ปของ Object Oriented ในการเขียน หลายคนที่เกี่ยวข้องกับการเขียนโปรแกรมคงจะทราบดีว่า Object Oriented สามารถลดความซับซ้อนโครงสร้างของโปรแกรมรวมไปถึงอำนวยความสะดวกในการ reuse ส่วนประกอบต่าง ๆ ของโปรแกรมที่เขียนไว้แล้วเพียงใด นอกจากนี้จาว่ายังเป็นภาษาที่เป็น platform independent ซึ่งจะช่วยให้เราสามารถทำการพัฒนาระบบโดยใช้ environment อะไรก็ได้ซึ่งโดยทั่วไปมักจะเป็น Widows environment โดยจะนำโปรแกรมที่เขียนเสร็จแล้วมารันบน Unix environment เพื่อเพิ่มความเสถียรภาพของโปรแกรมอีกทีหนึ่ง นอกจากนี้ Servlet ยังมีความเร็วที่เหนือกว่า CGI เพราะ Servlet ใช้หลักการของ thread โดยจะทำการสร้าง 1 thread ต่อหนึ่ง request ที่มาจาก client ซึ่งในทางกลับกัน CGI จะทำการสร้าง 1 process ต่อหนึ่ง request ซึ่งจะทำให้เปลืองทรัพยาการมากกว่าและ process ในการรันก็จะช้ากว่าด้วย
ถึงแม้ว่า Servlet จะอ้างอิงหลักการของ CGI อย่างไรก็ตามในการที่จะทำการรัน Servlet แล้ว ตัว web server จะไม่สามารถส่งข้อมูลไปให้ Servlet ได้โดยตรงเหมือนกับหลักการของ CGI แต่ตัว web server จะต้องเพิ่มอีกส่วนหนึ่งซึ่งเป็นส่วนที่ใช้เป็นเสมือนตัวห่อหุ้ม Servlet ต่าง ๆ ไว้โดยส่วนที่เพิ่มขึ้นมานี้เราเรียกว่า Servlet Engine หรือ Servlet Container


รูปที่ 3. Servlet Engine and its Servlets

โดยทั่วไป Servlet Engine จะเป็นส่วนที่มี Java Virtual Machine (JVM) อยู่ในตัวเองโดย Servlet Engine นี้จะมีหน้าที่รับ request จาก web server (ซึ่งมาจาก web browser) แล้วทำการเลือกตัว Servlet ขึ้นมาทำการประมวลผล request นั้นภายใต้ JVM ของมัน โดยผลที่ได้จากการประมวลผลของ Servlet ที่ถูกเลือกจะถูกส่งกลับไปยัง web server โดย web server นี้จะส่งผลกลับไปยัง web browser ในท้ายที่สุด ตัวอย่างของ Servlet Engine ที่ใช้กันอยู่ในปัจจุบันก็อาจจะเป็น Apache JServ, Apache Tomcat, Allaire JRun, IBM Websphere, BEA Weblogic, Servlet Exec เป็นต้น

Relational Database
ช่วงที่มี Server Side Application ใหม่ ๆ ข้อมูลต่าง ๆ มักจะถูกเก็บไว้ในไฟล์โดยโปรแกรมจะทำการอ่านไฟล์ทุกครั้งที่มีการโหลดข้อมูลดังกล่าวขึ้นมาใช้ ตัวอย่างที่เราพบเห็นกันโดยทั่วไปสำหรับโปรแกรมที่ต้องอ่านหรือเก็บข้อมูลต่าง ๆ ลงไปในไฟล์ยกตัวอย่างเช่น เวปบอร์ด, guest book หรือแม้กระทั่ง counter เป็นต้น สำหรับเวปบอร์ดแล้วข้อมูลที่จะถูกจัดเก็บอาจจะเป็นลิสของข้อความที่มีอยู่ทั้งหมดในแต่ละกระทู้หรืออาจจะเป็นข้อมูลที่เกี่ยวกับ login และ password ของผู้ใช้แต่ละคนในกรณีที่เวปบอร์ดดังกล่าวจะอนุญาตให้ใช้กับเฉพาะบุคคลที่อยู่ในกลุ่มเท่านั้น การจัดเก็บข้อมูลในไฟล์มีผลเสียในแง่ของการยากต่อการดูแลและจัดเก็บ ตลอดจนประสิทธิภาพและความเร็วที่ลดลงของโปรแกรมในแง่ของการตอบสนองกับผู้ใช้ปลายทางเนื่องจากที่โปรแกรมมีกิจกรรมที่เกี่ยวข้องกับ I/O เป็นหลักใหญ่ ซึ่งในท้ายสุดการจัดเก็บข้อมูลในไฟล์ก็ถูกแทนที่ด้วยการจัดเก็บข้อมูลในเดต้าเบสแทน
เดต้าเบสเป็นส่วนที่ถูกเพิ่มขึ้นมาใน Server Side Application โดยมักจะเป็นส่วนที่อยู่ทางท้ายสุดของระบบ ส่วนที่จะเป็นตัวเรียกใช้เดต้าเบสมักจะเป็นส่วนที่่ทำหน้าที่ประมวลผล request ที่มาจากผู้ใช้ซึ่งโดยทั่วไปก็คือ Servlet Engine นั่นเอง [ในกรณีของ JSP(Java Server Pages) ตัว JSP Container จะเป็นส่วนที่ทำการติดต่อกับเดต้าเบสโดย JSP เพจจะทำการเรียกใช้ข้อมูลต่าง ๆ โดยผ่านทางจาว่าคลาสที่อยู่ในรูปของ JavaBean หรือ Tag Library] ตัวอย่างของ Server Side Application ที่มีเดต้าเบสมาเกี่ยวข้องอาจจะเป็นดังรูปข้างล่างนี้ 


รูปที่ 4. Servlets(in Servlet Engine) connecting to Relational Database via JDBC

Applet (on Web Browser) to Application
ทุกคนคงจะรู้จัก Applet กันเป็นอย่างดี Applet เป็นโปรแกรมที่เขียนขึ้นโดยใช้จาว่าซึ่งจริงๆ แล้วจะสามารถรันที่ไหนก็ได้ที่มี JVM อยู่ แต่โดยทั่วไปตัว Applet นี้มักจะถูกรันภายใต้ JVM ที่อยู่ใน Web Browser หรือไม่ก็ AppletViewer เสียมากกว่า ในช่วงแรก ๆ Applet ที่ใช้รันบนเวปมักจะถูกเขียนขึ้นเพื่อใช้ตกแต่งเพจต่าง ๆ ให้มีความสวยงามแต่ด้วยความสามารถที่ว่า Applet สามารถสร้าง connection กลับไปยังเซฟเวอร์ที่เป็นตัวเก็บ Applet ดังกล่าวได้ Applet จึงถูกใส่ความสามารถอื่น ๆ เข้าไปเกินกว่าที่จะเป็นเพียง client side application แต่เพียงอย่างเดียว วิธีการแรกที่นิยมใช้กันก็คือการให้ Applet ติดต่อกับ Application ที่รันอยู่ที่ตัวเซฟเวอร์ที่เก็บ Applet นั้นไว้โดยหลักการก็คือการใช้ web server เป็นแค่เพียงตัวเก็บ Applet เพื่อให้ web browser สามารถโหลด Applet มาจาก web server ได้โดยหลักจากที่ web browser ทำการโหลด Applet เสร็จแล้ว ตัว Applet ก็จะทำการสร้าง connection ไปยัง Application ที่รันอยู่บน Server เดียวกับที่รัน web server แทน หลักการดังกล่าวกลายเป็นจุดเริ่มต้นของคำ ๆ หนึ่งคือ Application Service Provider (ASP) ซึ่งก็หมายถึงบริษัทที่ให้บริการแก่ลูกค้าในการใช้ application ต่าง ๆ ผ่านทางเวปโดยไม่ต้องทำการ install ตัว application นั้นลงไปที่เครื่องของลูกค้าแต่จะทำการโหลด application นั้นมาใช้เมื่อถึงเวลาที่ต้องการนั่นเอง (บางคนจะเรียกว่า apps-on-tap โดยจะเปรียบ applications เป็นเหมือนกับน้ำที่เราใช้ดื่มใช้กินโดยได้มาจากการเปิดก๊อกน้ำ[tap])
ตัวอย่างของ Applet พวกนี้ก็อาจจะเป็นพวก Stock Monitor ที่ใช้ Applet ในการดูดัชนีของหุ้นต่าง ๆ ในแบบ real-time หรืออาจจะเป็น online Banking ซึ่งเป็น Applet ที่ธนาคารใช้เพื่อให้บริการต่าง ๆ กับลูกค้าเช่น การฝาก/ถอน การโอนเงิน การตรวจเช็ดยอดบัญชีต่าง ๆ เป็นต้น


รูปที่ 5. Applet to Application Communication

Applet (on Web Browser) to Servlet
ในกรณีที่เวปไซด์ต้องการความสวยงามหรือความ interactive กับผู้ใช้อย่างสูงจนกระทั่งการใช้ HTML และ Widget ต่าง ๆ (เช่นปุ่มหรือพวก html form) ที่ทาง web browser จัดเตรียมไว้ให้ไม่สามารถที่จะให้ความสวยงามตลอดจนความยืดหยุ่นเพียงพอต่อความต้องการของผู้ที่ออกแบบเวปไซด์นั้นได้ Applet ก็มักเป็นอีกทางเลือกหนึ่งที่หลาย ๆ คนนิยมใช้เพื่อลดช่องว่างในส่วนนี้ ลักษณะของ Applet ที่ติดต่อกับ Servlet จะต่างจาก Applet ที่ใช้ติดต่อกับ Application ตรงที่ว่า Applet ที่ใช้ติดต่อกับ Servlet จะยังคงใช้ HTTP protocol ในการติดต่อสื่อสารกับ Server โดยถ้าเปรียบเทียบก็คือแทนที่เราจะให้ user ใช้ HTML Form ต่าง ๆ ของ web browser ในการติดต่อสื่อสารกับ Servlet (ที่อยู่ที่ web server) เราก็ใช้ Applet เป็นตัวแทนของ HTML Form แทน ซึ่งนอกจากที่ Applet จะสามารถแทนที่ HTML Form ได้แล้ว เราก็ยังสามารถเพ่ิมความสวยงามและความ interactive เข้าไปใน Applet ได้ตามแต่จินตนาการของเราอีกด้วย หลายคนอาจจะสงสัยว่าแล้ว Applet จะติดต่อกับ Servlet ได้อย่างไร วิธีการที่นิยมใช้กัน*ก็คือ แทนที่จะให้ web browser สร้าง HTTP Request ไปยัง Servlet เหมือนอย่างแต่ก่อนเราก็ให้ Applet ที่รันอยู่บน web browser สร้าง HTTP Request ติดต่อไปยัง Servlet แทนโดยวิธีการเช่นนี้เราเรียกว่า HTTP Tunnel ซึ่งสามารถทำได้ง่าย ๆ โดยให้ Applet สร้าง HTTP Connection ไปยัง Servlet ผ่านทางคลาส java.net.URLConnection


รูปที่ 6. Applet to Servlet communcation via java.net.URLConnection class

เมื่อไรก็ตามที่มีการเปลี่ยนแปลงเกิดขึ้นกับ Applet ซึ่งเป็นผลมาจาก activitity ต่าง ๆ ของผู้ใช้ ตัว Applet จะทำการส่งค่าที่เปลี่ยนแปลงนี้ไปยัง Servlet เพื่อทำการประมวลผล โดยหลังจากที่ Applet ได้รับผลที่ส่งไปกลับมาจาก Servlet แล้ว Applet จะทำการตีความผลที่ได้เพื่อทำการเปลี่ยนแปลงตัวมันเองโดยผลที่ได้สำหรับผู้ใช้ก็คือการเปลี่ยนแปลงของค่าตัวเลขต่าง ๆ ที่อยู่บน Applet ในกรณีที่ Applet นั้นถูกใช้สำหรับแสดงค่าจำนวนตัวเลข ตลอดจนการเปลี่ยนแปลงรูปร่างหน้าตาของ Applet ไปยัง state อื่น ๆ ในกรณีของ Applet ที่ใช้สำหรับปฏิทิน เป็นต้น
วิธีการ Applet to Servlet นี้นิยมใช้กันมากเพราะเป็นการลดโหลดหรือการคำนวณที่หนักหน่วงจากส่วนของ client (Applet) ไปยังส่วนของ server (Servlet) แทน โดยมักจะมีศัพท์คำหนึ่งที่ใช้แทนลักษณะ architecture แบบนี้ซึ่งเราเรียกว่า thin client
* นอกจาก HTTP โปรโตคอลแล้ว Applet อาจจะใช้ RMI หรือ CORBA ในการติดต่อสื่อสารกับ Servlet ที่สนับสนุน Middleware สองอันนี้ก็ได้

Application Server
สำหรับเวปไซด์เล็ก ๆ แล้วโครงสร้างของ Server Side Application ที่กล่าวถึงข้างต้นก็มักจะเพียงพอต่อความต้องการสำหรับประโยชน์ใช้สอย อย่างไรก็ตามสำหรับเวปไซด์ใหญ่ ๆ ที่มีผู้ใช้จำนวนมหาศาล ส่วนประกอบที่สำคัญอีกอย่างหนึ่งที่มักจะถูกเพิ่มเข้าไปมักจะเป็นส่วนที่เรียกว่า Application Server
Application Server เป็นส่วนประกอบอีกส่วนหนึ่งที่ถูกสร้างขึ้นมาเพื่อสนองความต้องการที่ว่า ในการสร้างระบบที่ดีระบบหนึ่งขึ้นมานั้น เราควรจะแยกส่วนที่ทำหน้าที่เกี่ยวกับการบริการต่าง ๆ รวมไปถึงการจัดสรรข้อมูลออกมาเป็นอีกส่วนต่างหาก(Business Logic) ทั้งนี้เพื่อเพิ่มความคล่องตัวในการเปลี่ยนแปลงของระบบ รวมไปถึงการจัดระบบให้แบ่งออกเป็นส่วน ๆ อย่างชัดเจนมากยิ่งขึ้น โดยถ้าดูจากบทบาทของ Application Server ที่ผ่านตั้งแต่อดีตจนถึงปัจจุบันเราอาจจะพูดได้ว่า Application Server ก็คือส่วนที่ช่วยอำนวยความสะดวกให้กับ Server Side Application โดยมักจะเป็นตัวช่วยในการคำนวณข้อมูล(Services), ช่วยเป็นตัวกลางในการจัดส่งข้อมูล(Messaging Services), ช่วยในการควบคุมการจัดเก็บข้อมูลลงไปในเดต้าเบสอย่างถูกต้อง(Transaction) ตลอดจนช่วยในการเพิ่มความเร็วให้กับระบบโดยการเก็บออฟเจคต่าง ๆ ที่่ใช้หรือไม่ใช้แล้วไว้เพื่อนำมาใช้อีก(Caching) เป็นต้น (ในแง่ของการออกแบบระบบ Application Server มักจะเป็นส่วนที่เราใช้ในส่วนที่เรียกว่า Services Layer ซึ่งในจาว่าแล้วส่วนนี้ก็มักจะเกี่ยวข้องกับ Enterprise Java ต่าง ๆ เช่น EJB, JTS, JMS, JNDI นั่นเอง)


รูปที่ 7. Application Server

ประโยชน์อย่างหนึ่งของ Application Server ที่เรามักพบเห็นโดยทั่วไปก็คือการนำมาใช้สำหรับรัน EJB (Enterprise Java Bean)
ถ้าพูดกันในเชิงนิยามแล้ว EJB ไม่ได้ถูกรันที่ Application Server แต่จะถูกรันกับส่ิงหนึ่งที่เรียกว่า EJB Server อย่างไรก็ตาม Application Server ส่วนมากมักจะสนับสนุน EJB ซึ่งเป็นส่วนหนึ่งของ J2EE ดังนั้น Application Server ส่วนมากจึงมีส่วนหนึ่งที่ทำหน้าที่เป็น EJB Server เพื่อรัน EJB ต่าง ๆ ได้. EJB แบ่งออกอย่างคร่าว ๆ เป็นสามแบบคือ

1. Session Bean เป็น EJB ที่มักจะถูกใช้เป็นตัวเก็บรายละเอียดของผู้ใช้ที่กำลังทำกิจกรรมบางอย่างกับระบบหรืออาจจะถูกใช้เป็น Object Pool สำหรับ object ต่าง ๆ ที่ JSP หรือ Servlet สามารถเรียกใช้เพื่ออำนวยความสะดวกในการประมวลผลตลอดจนใช้ในการเปลี่ยนแปลงสถานะต่าง ๆ ของระบบโดยเรามักเรียกส่วนนี้ว่า Services Layer นั่นเอง

2. Entity Bean เป็น EJB ที่ใช้สำหรับเก็บเดต้าต่าง ๆ ที่เราทำการแมปมาจากเดต้าที่อยู่ในเดต้าเบส, ไฟล์, LDAP objects หรืออื่น ๆ ซึ่งจุดหลักของการนำเดต้าต่าง ๆ มาใส่ไว้ใน Entity Bean ก็คือการเพิ่มความง่ายในการเปลี่ยนแปลงเดต้าโดยผ่านทาง EJB Object, การง่ายต่อการควบคุมการอ่านและเขียนเดต้าต่าง ๆ ได้อย่างถูกต้องในกรณีที่ระบบมีมากกว่า 1 thread เข้ามาเกี่ยวข้องในการอ่านเขียนหรือเปลี่ยนแปลงเดต้าตัวเดียวกันในเวลาเดียวกัน รวมไปถึงความเร็วที่เพิ่มขึ้นในการเก็บเดต้าต่าง ๆ ไว้ในหน่วยความจำ (Bean Caching) แทนที่จะต้องทำการอ่านเดต้าใหม่จากเดต้าเบสทุกครั้งที่เราต้องการทำกิจกรรมบางอย่างกับเดต้าเหล่านั้น โดยข้อดีต่าง ๆ ที่กล่าวมาข้างต้นเหล่านี้จะเกิดขึ้นได้จากการทำงานร่วมกันระหว่าง Entity Bean, EJB Container และ EJB Server
อย่างไรก็ตามนักพัฒนาระบบก็ยังคงถกเถียงกันอยู่ถึง performance ที่เกิดขึ้นจากการใช้ Entity Bean เพื่อเก็บเดต้าต่าง ๆ ไว้ โดยผลกระทบนี้มาจากการที่แต่ละ thread จะต้องแย่งกันเข้าไปใช้ Entity Bean ตัวเดียวกันเพื่อทำการเขียนอ่านหรือแปลงแปลงเดต้า(Bean Contention) ซึ่งผลที่เกิดขึ้นอาจจะทำให้ระบบช้าลงกว่าการใช้ JDBC หรือ Object Database ธรรมดาทั่ว ๆ ไปก็ได้

3. Message-driven Bean (2.0 Proposed Final Draft) เป็น EJB ชนิดใหม่ที่ถูกเพิ่มเข้ามาเพื่อทำการสนันสนุน JMS (Java Message Service) โดย EJB นี้จะถูกควบคุมได้ใช้ event ต่าง ๆ ที่เกิดขึ้นจาก JMS Message (สำหรับรายละเอียดเกี่ยวกับ EJB ผู้อ่านสามารถอ่านเพิ่มเติมได้จาก http://java.sun.com/products/ejb/)

B2B (Business to Business)
นอกเหนือจากติดต่อสื่อสารระหว่าง web browser กับ Server Side Application แล้วข้างหลังฉากของ Server Side Application จากที่ ๆ หนึ่งอาจมีการติดต่อสื่อสารเพื่อแลกเปลี่ยนข้อมูลหรือทำการซื้อขายต่าง ๆ กับ Server Side Application ของอีกที่หนึ่งก็ได้ เรามักจะเรียกการติดต่อสื่อสารแบบนี้ว่า B2B (Business to Business) เทคโนโลยีในจาว่าที่นิยมใช้กันใน B2B มักจะเป็น JMS (Java Message Service), Socket ที่นักพัฒนานิยาม application protocol ขึ้นมาเอง, CORBA (Common Object Request Broker Architecture) หรืออาจเป็น Servlet to Servlet communication โดยมักนิยมใช้ SSL (Secure Sockets Layer) สำหรับ encrypt ข้อมูลและอาจใช้ XML เป็นเสมือน message สำหรับใช้รับส่งข้อมูลของทั้งสองฝ่ายก็ได้


Copyright (C) 2000-2001 www.jarticles.com.