1. บทนำ
ทุกวันนี้ ทุกองค์กรกำลังมองหาวิธีปรับปรุงประสิทธิภาพการผลิต และพวกเขายังกระตือรือร้นที่จะสำรวจการปรับโครงสร้างสินทรัพย์ไอทีใหม่อีกด้วย องค์กรไอทีมีความคืบหน้าในการเอาชนะปัญหาเหล่านี้ด้วยความช่วยเหลือของเทคโนโลยีสถาปัตยกรรมเชิงบริการ (SOA) อย่างไรก็ตาม ในกรณีส่วนใหญ่ จะมีการนำพอร์ตโฟลิโอบริการไอทีทั้งหมดไปใช้เพียงส่วนเล็กๆ เท่านั้น ในปัจจุบัน ความพยายามส่วนใหญ่ในด้านนี้เป็นเพียงการบรรลุสถานะการนำ SOA "เพียงพอ" มาใช้ ซึ่งก็คือการปรับปรุงความสามารถในการสร้างแอปพลิเคชันและบูรณาการเข้ากับตลาดได้เร็วขึ้น ดีขึ้น และถูกกว่า และดังที่เราได้เรียนรู้มา การบรรลุเป้าหมายเหล่านี้พูดง่ายกว่าทำ
2. แอปพลิเคชันคอมโพสิตที่ใช้มิดเดิลแวร์แบบดั้งเดิม
ข้อเท็จจริงที่มีอยู่ก็คือ SOA นั้นเป็นมิดเดิลแวร์ประเภทหนึ่ง และในกรณีดั้งเดิม มิดเดิลแวร์มักจะอาศัยมิดเดิลแวร์มากกว่าในการแปลข้อมูลให้อยู่ในสถานะที่เป็นมิตรต่อผู้บริโภค ในที่สุดเมื่อคุณพบว่าการสร้างแอปพลิเคชันคอมโพสิตที่รวมเอาเทคโนโลยี SOA ไม่เพียงแต่ต้องใช้พอร์ทัล (มิดเดิลแวร์) เท่านั้น แต่ยังอาจต้องใช้กลไก BPEL (หรือแม้แต่มิดเดิลแวร์) เพื่อจัดเตรียมมัน แน่นอนว่าสิ่งนี้ทำให้คุณเป็น ผิดหวังมาก ที่แย่กว่านั้นคือคุณอาจทำงานภายในองค์กรที่เผยแพร่การลงทะเบียน UDDI และลงทะเบียนบริการเว็บจำนวนมาก น่าเสียดาย ในกรณีส่วนใหญ่ มีแอปพลิเคชันน้อยมากที่ใช้บริการเหล่านี้จริงๆ จะเป็นเช่นนี้ได้อย่างไร
หากการไม่สามารถสร้างแอปพลิเคชันที่ใช้บริการ SOA เหล่านี้ทำให้เราสรุปได้ว่ามีบางอย่างผิดปกติหรือไม่ เป็นเพราะนักพัฒนาเนื้อหาทางธุรกิจจะสร้างแอปพลิเคชันที่ใช้บริการ SOA โดยตรงได้หรือไม่ ที่ต้องพึ่งพาองค์กรไอทีอื่น ๆ เพื่อสร้างแอปพลิเคชันดังกล่าวให้เราหรือไม่ การขาดโครงสร้างการกำกับดูแล SOA เป็นอุปสรรคต่อเราหรือไม่ ฉันคิดว่าคำตอบทั้งหมดข้างต้นคือ "ใช่" และมีเหตุผลที่สำคัญมาก: เป็นเรื่องยากเกินไปสำหรับนักพัฒนาธุรกิจเท่านั้นที่จะใช้บริการ SOA ดังกล่าวที่เปิดเผยโดยองค์กรไอที! ที่จริงแล้วปัญหาที่แท้จริงคือการไม่มีวิธีง่ายๆ ในการเพิ่มอินเทอร์เฟซ SOA - และ นี่คือข้อดีของการรวมเทคโนโลยี AJAX เข้ากับ SOA
โดยทั่วไปแล้ว บริการ SOA จะถูกนำไปใช้เป็นบริการเว็บที่เชื่อมโยงอย่างหลวมๆ ซึ่งห่อหุ้มและเปิดเผยฟังก์ชันการทำงานทางธุรกิจ นี่อาจฟังดูตรงไปตรงมามาก แต่มีความซับซ้อนและนำไปปฏิบัติได้ยาก นักพัฒนามักถกเถียงกันถึงรายละเอียดการพัฒนาของบริการ SOA อย่างไรก็ตาม นักพัฒนาส่วนใหญ่เห็นพ้องต้องกันว่ารายละเอียดการพัฒนา "ระดับธุรกิจ" เป็นสิ่งที่เหมาะสมที่สุด อย่างไรก็ตาม ยังคงต้องใช้ผู้เชี่ยวชาญโดเมนที่เกี่ยวข้องจำนวนมากมาร่วมงานและทำงานกับเนื้อหาทางธุรกิจเพื่อสรุปขนาดของบริการเหล่านี้
3. การฟื้นตัวของ SOA
โชคดีที่ผู้คนสนใจ SOA อย่างลึกซึ้งเมื่อไม่นานมานี้ บางทีธุรกิจต่างๆ อาจตระหนักได้ว่า SOA สามารถช่วยเหลือพวกเขาได้มหาศาลจริงๆ บางทีนี่อาจเป็นเพราะเครื่องมือการพัฒนาและบริการเว็บที่ดีขึ้นซึ่งได้รับการส่งเสริมโดย Amazon, Yahoo และ eBay อาจเป็น AJAX ใช่ไหม นั่นคือเหตุผลที่ฉันเขียนบทความนี้ จริงๆ แล้ว ฉันคิดว่า AJAX ได้กลายเป็นแรงผลักดันสำคัญในการต่ออายุความเข้าใจของผู้คนเกี่ยวกับ SOA โดยเฉพาะอย่างยิ่งในสาขาแอปพลิเคชันไฮบริดของเทคโนโลยีใหม่ต่างๆ ในปัจจุบัน อย่างไรก็ตาม ทั้งสองเทคโนโลยีที่แตกต่างกันมากควรจะรวมและเชื่อมต่อเข้าด้วยกันเพื่อปลดปล่อยพลังที่มากขึ้นได้อย่างไร ให้เรามาดูคำจำกัดความของเทคโนโลยี AJAX ในปัจจุบันของ Wikipedia กันก่อน หน้าเว็บมีส่วนเกี่ยวข้อง แต่ไม่ได้กล่าวถึง SOA เลย คำอธิบายคือ:
"AJAX ซึ่งย่อมาจาก 'Asynchronous JavaScript+XML' เป็นเทคโนโลยีการพัฒนาเว็บสำหรับการสร้างแอปพลิเคชันเว็บเชิงโต้ตอบ โดยมีวัตถุประสงค์คือเพื่อทำให้หน้าเว็บส่วนหน้าง่ายขึ้นโดยการแลกเปลี่ยนข้อมูลจำนวนเล็กน้อยกับเซิร์ฟเวอร์ ในพื้นหลัง ให้ความรู้สึกตอบสนองมากขึ้น ดังนั้น ทุกครั้งที่ผู้ใช้ทำการเปลี่ยนแปลง ไม่จำเป็นต้องโหลดหน้าเว็บใหม่ทั้งหมด เป้าหมายสูงสุดคือการปรับปรุงการโต้ตอบ การตอบสนอง และการใช้งานของเว็บเพจให้ดียิ่งขึ้น
SOA ไม่ได้กล่าวถึงในคำจำกัดความนี้ ไม่น่าแปลกใจเลย เนื่องจากแอปพลิเคชัน AJAX ในยุคแรก ๆ มุ่งเน้นไปที่การปรับปรุงฟังก์ชันและการใช้งานของเพจ สิ่งนี้ได้รับการพิสูจน์แล้วในแอปพลิเคชั่นมากมาย เช่น Google Maps, Flickr และ Yahoo Mail อย่างไรก็ตาม ไม่ใช่แอปพลิเคชันสำหรับผู้บริโภคที่ทำให้ฉันตื่นเต้นเกี่ยวกับศักยภาพของ AJAX แต่เป็นแอปพลิเคชันทางธุรกิจที่ทำงานอยู่เบื้องหลังไฟร์วอลล์ของบริษัทที่ใช้ประโยชน์จากสิ่งที่ดีใน AJAX อย่างแท้จริง เพราะมันแสดงให้เราเห็นลักษณะสำคัญสองประการ : หนึ่งคือลูกค้า -รูปแบบการเขียนโปรแกรมด้านข้างและอีกรูปแบบหนึ่งคือการใช้งานการโทรแบบอะซิงโครนัสไปยังเซิร์ฟเวอร์อย่างง่ายดาย ความสามารถหลักสองประการนี้—ความสามารถในการใช้ตรรกะบนไคลเอนต์ (เบราว์เซอร์) และความสามารถในการเข้าถึงข้อมูลเซิร์ฟเวอร์โดยไม่รบกวนเว็บเพจ—เปิดประตูสู่การสร้างแอปพลิเคชันระดับองค์กร Web 2.0 ใหม่ที่สมบูรณ์ยิ่งขึ้น ขอบเขตการใช้งานที่เป็นไปได้มากมายของโปรแกรม .
ก่อนหน้านี้ ฉันบอกว่า SOA ขาดอินเทอร์เฟซ นี่คือที่มาของ AJAX - เพิ่มรูปลักษณ์ที่ดีให้กับ SOA ในที่นี้ขออนุญาตอธิบายเพิ่มเติมอีกเล็กน้อย เราอาจคิดเหมือนกันว่าจะเกิดอะไรขึ้นหากบริการ SOA ปรากฏทางออนไลน์ บริการดังกล่าวมักจะต้องลงทะเบียนในทะเบียนหรือคลังสินค้า (ถ้าเราโชคดี) จากนั้นจึงจะสามารถนำไปใช้บริโภคได้ ตัวอย่างเช่น มาดูกันว่ามีอะไรบ้างในเว็บไซต์ StrikeIron ( www.StrikeIron.com ) StrikeIron ประสบความสำเร็จในการสร้าง "ตลาดบริการบนเว็บ" สำหรับประชาชนทั่วไป เมื่อมองแวบแรก กลไกไดเรกทอรีใน StrikeIron ดูเหมือนรายการที่มีอยู่ในแอปพลิเคชันธุรกิจขนาดเล็กมาก แต่ในภายหลัง คุณจะพบว่าสิ่งเหล่านี้ไม่ใช่แค่แอปพลิเคชัน แต่เป็นบริการบนเว็บจริงๆ แนวคิดของบริษัทเดียวที่ให้บริการเว็บ WSDL/REST แก่ผู้บริโภคในวงกว้างมีความหมายหลายประการ แต่สำหรับตอนนี้เรามาดูกันว่าบริษัทนี้ขายอะไรบ้าง ตามข้อมูลที่จัดทำโดย StrikeIron (ซึ่งให้การเข้าถึงบริการเหล่านี้) บริการบนเว็บที่ได้รับความนิยมมากที่สุด ได้แก่:
· การตรวจสอบที่อยู่ของสหรัฐอเมริกา
· บริการ SMS ทั่วโลก
· ภาษีการขายและการใช้งาน
· การตรวจสอบอีเมล
· การค้นหาโทรศัพท์แบบย้อนกลับ
ไม่มีอะไรไม่ต้องสงสัยเลย บริการบนเว็บเหล่านี้ค่อนข้างมีประโยชน์และสามารถใช้ได้ในด้านต่างๆ มากมาย แต่ในขณะเดียวกัน มันก็เป็น "สินค้าโภคภัณฑ์" มากเกินไป กล่าวอีกนัยหนึ่ง ฉันอาจไม่สนใจว่าใครให้บริการเหล่านี้ แต่เพียงต้องการได้รับข้อมูลที่ฉันต้องการ ในทางกลับกัน ฉันจะใช้บริการทางเว็บเพื่อโอนเงินจากบัญชีกระแสรายวันไปยังบัญชีออมทรัพย์ของฉันหรือไม่ ฉันต้องสร้างความไว้วางใจในบริการนี้ก่อน ดังนั้นฉันจึงต้องสร้างความสัมพันธ์บางอย่างกับผู้จำหน่ายที่ให้บริการ "วงจรแห่งความไว้วางใจ" ที่มีอยู่ระหว่างฉัน (ผู้บริโภค) และผู้ให้บริการยังแสดงถึงความสัมพันธ์ภายในองค์กรและพันธมิตรด้วย
4. การรวมเทคโนโลยี AJAX + SOA
องค์กรต่างๆ ยังสามารถใช้วิธีการเดียวกันข้างต้นเพื่อให้บริการเว็บแก่ฐานผู้ใช้ที่กว้างขึ้น ผ่านตลาดบริการบนเว็บ องค์กรสามารถลงทะเบียนบริการบนเว็บต่างๆ ได้ และบริการทางเว็บเหล่านี้มักจะใช้ได้เฉพาะภายในองค์กรหรือกับคู่ค้าเท่านั้น เห็นได้ชัดว่าผู้ขายในตลาดต้องการให้สิ่งนี้เกิดขึ้น แต่ที่สำคัญกว่านั้น เราเห็นโอกาสในการใช้เทคโนโลยี AJAX+SOA เพื่อขับเคลื่อนแอปพลิเคชันทางธุรกิจ Web 2.0 ประเภทใหม่
เป็นครั้งแรกที่ผู้คนเริ่มรู้สึกว่าในที่สุดการพัฒนาแอปพลิเคชันและ SOA ก็มารวมกัน เรามีฟังก์ชันการทำงานทางธุรกิจที่อธิบายไว้ในรูปแบบที่นำมาใช้ซ้ำได้ - บริการ SOA เรามีการเชื่อมต่อที่แพร่หลาย—เว็บ เรามีเบราว์เซอร์ที่พิสูจน์แล้วว่าเป็นคอนเทนเนอร์แอปพลิเคชันใหม่ เรามีโมเดลการเขียนโปรแกรมในคอนเทนเนอร์/เบราว์เซอร์แอปพลิเคชันประเภทนี้ - JavaScript และพวกเขาทั้งหมดใช้มาตรฐานเปิด! เราจะขออะไรอีกล่ะ?
ฉันอยากเห็นวิธีที่เร็วกว่าในการพัฒนาแอปพลิเคชันที่ใช้เทคโนโลยีข้างต้นทั้งหมด ซึ่งเป็นวิธีสร้างแอปพลิเคชันโดยไม่ต้องพึ่งพามิดเดิลแวร์ที่รวมเข้ากับบริการ SOA นี่คือสิ่งที่ฉันต้องการให้เว็บแอปพลิเคชันสามารถทำได้ - "การเชื่อมต่อโดยตรงกับ SOA" "การเชื่อมต่อโดยตรงกับ SOA" นี้ควรจะสามารถหลีกเลี่ยงอุปสรรคพอร์ทัลแบบดั้งเดิมและกลไกกระบวนการที่มีน้ำหนักมาก เพื่อเข้าถึงบริการ SOA ได้โดยตรง (อย่างน้อยในแนวความคิด เราจะเรียนรู้เพิ่มเติมเกี่ยวกับเรื่องนี้ในภายหลัง) ด้วยเหตุนี้ ฉันไม่ได้หมายถึงเพียงบริการบนเว็บเท่านั้น แต่ยังอาจเป็นบริการประสาน BPEL บริการ POJO แบบหยาบ ฟีด RSS หรือสิ่งอื่นใดที่สามารถเปิดเผยได้ว่าเป็น "บริการ" แน่นอนว่าอินเทอร์เฟซควรได้รับการเปิดเผยโดยใช้มาตรฐานแบบเปิด
โมเดลการพัฒนาและรันไทม์ใหม่นี้สร้างวิธีใหม่ในการสร้างแอปพลิเคชันคอมโพสิตที่ขับเคลื่อนด้วยแอปพลิเคชัน มีความน่าดึงดูดใจประเภทไคลเอนต์/เซิร์ฟเวอร์ โดยไม่ต้องแบกสัมภาระหนักเหมือนไคลเอนต์/เซิร์ฟเวอร์รุ่นหนาแบบดั้งเดิม มันทำงานบนฝั่งเบราว์เซอร์และสามารถใช้งานได้ตามความต้องการเฉพาะ
5. แอปพลิเคชันคอมโพสิตที่อิงตามผู้ใช้
ในช่วงไม่กี่ปีที่ผ่านมา เราทุกคนเคยได้ยินเกี่ยวกับแนวคิดของ "แอปพลิเคชันคอมโพสิต" อย่างไรก็ตาม ผู้จำหน่ายส่วนใหญ่พูดถึง "บริการแบบคอมโพสิต" ซึ่งเป็นวิธีการปรับโครงสร้างบริการโฮสต์ของตนให้เป็นบริการหรือแอปพลิเคชันพอร์ทัลที่มีประโยชน์อื่นๆ ผมขอเปรียบเทียบเพื่ออธิบายเพิ่มเติม
AcmeGrid ผู้จำหน่ายการประมวลผลกริดสมมติของเราในบทความนี้ ให้บริการ—การประมวลผลกริด—ที่ช่วยให้แอปพลิเคชันของคุณทำงานเป็นบริการได้ ลูกค้าของบริษัทบอกว่าพวกเขาต้องการวิธีรวมบริการต่างๆ เข้าด้วยกันเป็นบริการแบบหยาบ แน่นอนว่า AcmeGrid ได้เปิดตัว AcmeGrid Composite Application Builder (CAB) ที่ใช้ Eclipse ที่น่าสนใจคือ CAB ดูเหมือนนักออกแบบ BPEL มาก แต่มีการผสานรวมเข้ากับบริการที่เผยแพร่โดย AcmeGrid อย่างแน่นหนามากกว่า แม้ว่าจะสวยงามมาก แต่ก็ไม่ใช่แอปพลิเคชันจริง แต่ที่ดีที่สุดก็เป็นเพียงบริการเท่านั้น โดยพื้นฐานแล้ว CAB เป็นเหมือนผู้สร้างบริการมากกว่า แต่ใครบ้างที่ต้องการตัวสร้างบริการเมื่อเราพยายามสร้างแอปพลิเคชัน ในไม่ช้า ผู้จำหน่ายสมมติรายอื่น เรียกว่า AcmePortal ได้ประกาศเปิดตัว Portal Composite Application Builder (PCAB) นอกจากนี้ยังมาพร้อมกับนักออกแบบที่ใช้ Eclipse แม้ว่าหน้าตาและความรู้สึกจะเหมือนกับนักออกแบบ BPEL แต่โปรแกรมนี้ "รู้" วิธีสร้างพอร์ทัล ในหลายกรณี พอร์ทัลก็ใช้งานได้เช่นเดียวกับแอปพลิเคชัน อย่างไรก็ตาม หากคุณยืนกรานที่จะแปลงพอร์ทัลเป็นแอปพลิเคชัน มันก็จะไร้ประโยชน์
อันที่จริง ฉันต้องการใช้แอปพลิเคชันคอมโพสิตที่อิงตามผู้ใช้มากกว่าแอปพลิเคชันคอมโพสิตที่ใช้มิดเดิลแวร์ ในการดำเนินการนี้ ฉันจำเป็นต้องมีแพลตฟอร์มการพัฒนาและรันไทม์ที่ไม่เพียงแต่สามารถใช้ AJAX และ SOA เท่านั้น แต่ยังจัดการทั้งสองอย่างได้ด้วย ผู้จำหน่ายบางรายได้นำแนวคิดของแอปพลิเคชัน AJAX ไปอีกขั้นหนึ่ง โดยเรียกบริการเว็บที่ใช้ WSDL โดยตรงจากเบราว์เซอร์ ซึ่งโดยพื้นฐานแล้วคือการเรียก SOAP วิธีการนี้มีชื่อเรียกว่า "Client/SOA" นี่อาจใช้ได้สำหรับแอปพลิเคชันทั่วไปที่ไม่ใช่องค์กรหรือผู้บริโภค แต่ไม่ใช่สำหรับโปรแกรมระดับองค์กรที่แท้จริง เพราะเมื่อคุณเรียกใช้บริการเว็บโดยตรงจากเบราว์เซอร์ ฟังก์ชันการควบคุมดูแลจะเทียบเท่ากับการส่งผ่านไปยังเบราว์เซอร์ ซึ่งหมายความว่าไม่มีปัญหาการควบคุมดูแลเลย รูปที่ 1 แสดงบล็อกไดอะแกรมของการใช้บริการเว็บที่ไม่ได้รับการดูแล ฉันไม่เคยพบกับบริษัทที่ไม่ควบคุมการให้บริการ และฉันไม่เชื่อว่าบริษัทต่างๆ จะยอมให้สิ่งนี้เกิดขึ้นเพียงเพราะว่าในทางเทคนิคแล้วเรามีประสิทธิภาพมากในเรื่องนี้ หากคุณไม่เชื่อฉัน โปรดจำไว้ว่าองค์กรต่างๆ ไม่เคยเปิดไฟร์วอลล์ของตนไปยังแอปพลิเคชันอื่นที่ไม่ใช่ HTTP และ SSL ไม่ว่าเราจะโน้มน้าวผู้ดูแลระบบมากแค่ไหนเขาก็จะไม่เปิดพอร์ตอื่น
6. เราต้องการแพลตฟอร์มรูปแบบใหม่
ดังที่เห็นได้จากข้างต้น สิ่งที่เรากำลังพูดถึงไม่ใช่แค่เกี่ยวกับเทคโนโลยี AJAX และ SOA เท่านั้น ในความเป็นจริง สิ่งที่เราต้องการจริงๆ คือแพลตฟอร์มที่สามารถมอบความสามารถในการกำกับดูแลที่จำเป็นสำหรับ AJAX และ SOA เพื่ออยู่ร่วมกันในองค์กร แพลตฟอร์มนี้ยังมอบความสามารถในการใช้บริการ SOA จากมุมมองของลูกค้า และยังสามารถตรวจสอบการใช้บริการได้อีกด้วย รูปที่ 2 แสดงวิธีจัดการบริการบนเว็บผ่านเกตเวย์บริการ จริงๆ แล้ว เกตเวย์บริการนั้นเป็นนามธรรมฝั่งเซิร์ฟเวอร์ที่ตรวจสอบและควบคุมการเข้าถึงบริการในนามของไคลเอนต์ ซึ่งในกรณีที่เราเพิ่งพูดถึงคือแอปพลิเคชัน AJAX บนเบราว์เซอร์ ข้อดีของการใช้เกตเวย์บริการก็คือ คุณไม่ได้ถูกจำกัดให้เข้าถึงเฉพาะบริการที่ทำงานภายในองค์กรเท่านั้น เกตเวย์บริการนี้สามารถดูแลบริการใดๆ ที่ลงทะเบียนภายในองค์กรได้ ในบริการเว็บที่ใช้ WSDL องค์กรจะลงทะเบียน WSDL และ WSDL จัดเตรียมการเชื่อมโยงกับบริการในขณะรันไทม์ นี่อาจเป็นบริการที่ทำงานในศูนย์ข้อมูลขององค์กร แต่อาจเป็นบริการที่ทำงานในศูนย์ข้อมูลของพันธมิตรได้อย่างง่ายดายพอๆ กัน หากองค์กรอนุญาตให้แอปพลิเคชัน (ผ่านการควบคุม) เข้าถึงบริการได้ ก็ไม่สำคัญว่าบริการเหล่านั้นจะทำงานอยู่ที่ใด
7. บทสรุป
หลังจากอ่านบทความนี้ ฉันหวังว่าคุณจะเริ่มเข้าใจถึงพลังของการนำ AJAX และ SOA มารวมกัน โดยเฉพาะอย่างยิ่งวิธีที่ทั้งสองสามารถอยู่ร่วมกันและเปิดใช้งานแอปพลิเคชันบนเว็บประเภทใหม่พร้อมความสามารถด้านกฎระเบียบที่แอปพลิเคชันบริการขององค์กรกำหนด . ฉันเชื่อมั่นว่าเราอยู่ในยุคใหม่ของโอกาสที่น่าอัศจรรย์ ในยุค Web 2.0 เครือข่ายโซเชียล การแบ่งปันรูปภาพ และเทคโนโลยีคำอธิบายประกอบต่างๆ ล้วนยอดเยี่ยม แต่สิ่งที่มีอิทธิพลอย่างแท้จริงคือการตอบสนองของ Web 2.0 ต่อองค์กรต่างๆ