ซิป้า พัฒนาระบบ One Stop Services ด้วย SOA

ซิป้า พัฒนาระบบ One Stop Services ด้วย SOA Service Oriented Architecture

ซิป้าสร้างระบบ One Stop Service บูรณาการบริการของหน่วยงานราชการ นำหลักการของ Services-Oriented Architecture (SOA) เข้ามาช่วยเชื่อมโยงข้อมูลระหว่างหน่วยงานราชการต่างๆ ของภาครัฐ ช่วยลดความซ้ำซ้อนของข้อมูล เพิ่มประสิทธิภาพในการให้บริการประชาชน

นายมนู อรดีดลเชษฐ์ ผู้อำนวยการ สำนักงานส่งเสริมอุตสาหกรรมซอฟต์แวร์แห่งชาติ (องค์การมหาชน) กระทรวงเทคโนโลยีสารสนเทศและการสื่อสาร กล่าวว่า SOA จะเป็นสถาปัตยกรรมซอฟต์แวร์ที่สำคัญของอุตสาหกรรมซอฟต์แวร์นับจากนี้ไป ซึ่งไม่เพียงแต่นำไปใช้เพื่อบูรณาการข้อมูลขององค์กร และงานภาครัฐ แต่ยังเป็นแนวทางการสร้างระบบซอฟต์แวร์แบบ Service-based ที่เน้นเรื่องการนำมาใช้ใหม่และความคล่องตัวในการปรับเปลี่ยนซอฟต์แวร์ให้ทันสถานการณ์
โครงการ One Stop Service เป็นหนึ่งในโครงการ e-government โดยมี IBM Websphere Application Server 6.0 บริหารจัดการที่ระบบกลางเชื่อมโยงข้อมูลจากหน่วยงานต่างๆ ผ่านระบบอินเทอร์เน็ตซึ่งเมื่อโครงการดังกล่าวเสร็จสิ้น จะทำให้ผู้มาใช้บริการสามารถใช้บริการหลายๆ อย่างได้พร้อมกันในครั้งเดียว ช่วยลดเวลาในการให้บริการของผู้มาใช้บริการได้อย่างมาก
ในเบื้องต้นได้มีการเชื่อมโยงข้อมูลกับหน่วยงานที่เข้าร่วมโครงการนำร่อง อาทิ ระบบการให้บริการสาธารณูปโภคทั้งประเทศ ได้แก่ ไฟฟ้า น้ำประปา โทรศัพท์ ธนาคาร, ระบบสาธารณสุข โรงพยาบาลภูเก็ต, ระบบการศึกษาโรงเรียนภูเก็ต, ระบบตรวจคนเข้าเมืองภูเก็ต, ระบบจัดหางานภูเก็ต และระบบศาล-ตำรวจภูเก็ต เข้าไว้ด้วยกัน

นายกิตติพงษ์ อัศวพิชยนต์ รองกรรมการผู้จัดการ กลุ่มธุรกิจซอฟต์แวร์ บริษัท ไอบีเอ็ม ประเทศไทย จำกัด กล่าวว่า สถาปัตยกรรม SOA เป็นระบบที่มากกว่าแค่การเชื่อมต่อเว็บเซอร์วิสง่ายๆ ทั่วไป แต่เป็นการทำให้ระบบงานเก่าและใหม่สามารถเชื่อมโยง ทำงานร่วมกันได้ ช่วยให้ประหยัดต้นทุน และเพิ่มการใช้ทรัพยากรที่มีอยู่ให้เกิดประโยชน์สูงสุด

ทั้งนี้ การ์ทเนอร์ได้คาดการณ์เอาไว้ว่า ในปี พ.ศ.2551 จะมีองค์กรธุรกิจมากกว่า 60% จากองค์กรทั้งหมดทั่วโลกพัฒนาระบบโดยใช้ SOA ซึ่งจะเป็นหลักการสำคัญในการสร้างระบบโครงสร้างพื้นฐานไอที

ธ.ทหารไทยนำร่อง วางหลัก SOA สู่ การให้บริการธุรกรรมแห่งอนาคต

ธ.ทหารไทยนำร่อง วางหลัก Service Oriented Architecture SOA สู่ การให้บริการธุรกรรมแห่งอนาคต

นางสาวสายพิน กิตติพรพิมล ผู้ช่วยกรรมการผู้จัดการใหญ่สายงานเทคโนโลยี ธนาคารทหารไทย จำกัด (มหาชน) กล่าวว่า เนื่องจากธนาคารมีวิสัยทัศน์ที่ต้องการเพิ่มประสิทธิภาพและคุณภาพของบริการทั่วทั้งองค์กร จึงได้ตัดสินใจปรับระบบงานหลายระบบ โดยเล็งเห็นว่าหลักการของ Service-Oriented Architecture หรือ SOA เป็นสถาปัตยกรรมไอทีที่สามารถช่วยให้การพัฒนาระบบสะดวก รวดเร็ว ถูกต้อง และคุ้มค่าต่อการลงทุน ท่ามกลางความกดดันจากสภาวการณ์การแข่งขันสูงในอุตสาหกรรมการเงินการธนาคารและมีกฎระเบียบควบคุมของทางการที่เข้มงวดมากขึ้น ดังนั้น ธนาคารจึงร่วมมือกับไอบีเอ็มประกาศเป็นองค์กรต้นแบบที่ปรับกระบวนการทำงานภายในองค์กรในหลายส่วนบริการธุรกรรมทางการเงินตามหลัก SOA เพื่อเพิ่มประสิทธิภาพการดำเนินงานภายในองค์กร ปรับปรุงคุณภาพ ความรวดเร็วในการให้บริการดังกล่าวให้ฉับไว และการบริหารกำกับดูแลความเสี่ยงตาม Basel II

ผู้ช่วยกรรมการผู้จัดการใหญ่สายงานเทคโนโลยี ธนาคารทหารไทย กล่าวต่อไปว่า การปรับกระบวนการทำงานตามหลักการของ SOA ครั้งนี้ ธนาคารเลือกใช้ IBM WebSphere เป็นมิดเดิลแวร์หลัก ในการเพิ่มประสิทธิภาพการพัฒนาแอพพลิเคชั่นสำหรับหลายส่วนงาน อาทิ ระบบ Cash Management ที่ต้องมีการพัฒนาในส่วนของการเชื่อมต่อกับระบบหลังบ้านหลายระบบงาน ที่ประมวลผลอยู่บนหลากหลายแพลตฟอร์ม ระบบ ROSCs (Report on the Observance of Standards and Codes) ที่ต้องพัฒนาให้แล้วเสร็จทันตามกำหนดเวลาของทางการ ปปง. และ บริการโอนเงินข้ามธนาคารผ่านเคาน์เตอร์สาขา (Inter-bank Transfer via Teller) เป็นต้น

นางสาวสายพิน กล่าวด้วยว่า การปรับกระบวนการทำงานและระบบไอทีตามหลักการ SOA ช่วยให้ธนาคารสามารถพัฒนาแอพพลิเคชั่นใหม่ๆ หรือปรับปรุงแอพพลิเคชั่นที่ใช้งานอยู่เดิม สามารถทำงานเชื่อมต่อกันกับระบบเดิมที่มีอยู่หลากหลายเข้าด้วยกันอย่างมีประสิทธิภาพ โดยไม่มีข้อจำกัดด้านแพลตฟอร์ม ภาษาในการพัฒนาโปรแกรม ระบบปฏิบัติการ หรือแม้กระทั่งประเภทของเครื่อง นอกจากนี้ การพัฒนาแอพพลิเคชั่นบน IBM WebSphere Solution ตามหลักการของ SOA สามารถนำ Service เดิมที่พัฒนาใช้งานอยู่แล้วกลับมาใช้กับระบบงานใหม่ (Reusability) ได้โดยไม่ต้องเสียเวลาและค่าใช้จ่ายในการพัฒนาใหม่ทุกครั้ง ทำให้ประหยัดเวลา ค่าใช้จ่าย และสามารถใช้งานได้อย่างรวดเร็ว มีความถูกต้องและมีความปลอดภัยสูง

นางเจษฎา ไกรสิงขร รองกรรมการผู้จัดการ ธุรกิจซอฟต์แวร์ บริษัท ไอบีเอ็ม ประเทศไทย จำกัด กล่าวว่า ขณะที่องค์กรธุรกิจและภาครัฐ รวมถึงชุมชนมาตรฐานเปิดและองค์กรไอทีมาตรฐานสากลทั่วโลกกำลังตื่นตัวและตระหนักว่า SOA กำลังทวีบทบาทความสำคัญในโลกธุรกิจและอุตสาหกรรมไอทีทั่วโลกมากขึ้นเรื่อยๆ ไอบีเอ็มมีความยินดีที่ธนาคารทหารไทยได้เริ่มเป็นองค์กรต้นแบบในประเทศไทยและในระดับภูมิภาคอาเซียนในการเริ่มปรับขั้นตอนภายในขององค์กรและระบบไอทีไปตามหลักการของ SOA ซึ่งจะเป็นประโยชน์อย่างยิ่งต่อประสิทธิภาพการทำงานโดยรวมและช่วยให้ธนาคารทหารไทยบรรลุเป้าหมายทางธุรกิจในอนาคต

คู่มือ 10 ขั้นตอนก้าวสู่ SOA

คู่มือ 10 ขั้นตอนก้าวสู่ Service Oriented Architecture SOA

SOA เป็นแนวความคิด ไม่ใช่เทคโนโลยี

ในความเป็นจริง SOA (service-oriented architecture) นั้นสร้างขึ้นบนเลเยอร์ของโปรโตคอลที่ใช้กำหนดรูปแบบของเว็บเซอร์วิส เพียงแต่มันไม่ได้ถูกจำกัดที่เลเยอร์ของโปรโตคอลเท่านั้น มันได้ร่างภาพ XML, SOAP และ WSDL ออกไปไกลเฉกเช่นกับที่เกิดขึ้นกับแนวคิดของการรีเอนจิเนียริ่งในภาคธุรกิจต่างๆ การวางตำแหน่งของกรอบการทำงานที่อยู่บนพื้นฐาน SOA ซึ่งเป็นเซอร์วิสที่ต้องสร้าง มอบหมายผู้รับผิดชอบ จัดการ และจัดให้ทำงานได้อย่างสอดคล้องกันเพื่อเสาะหาโครงสร้างพื้นฐานทางทางไอทีที่ทันสมัยและมีความตื่นตัวมากขึ้นเพื่อตอบสนองต่อความต้องการทางธุรกิจที่เปลี่ยนแปลงตลอดเวลา

วิสัยทัศน์ที่กว้างไกลอาจทำให้ภาพของ SOA ดูเบลอไม่ชัดเจน อย่างไรก็ตาม ผลลัพธ์ที่ชัดเจนในการลดต้นทุนไอที และการทำให้ธุรกิจมีความความตื่นตัวมากขึ้นนั้นไปกระตุ้นให้องค์กรมากมายเริ่มเข้าสู่เส้นทางของ SOA เพื่อชี้เป้าไปยังจุดที่องค์กรใหญ่เกือบทั้งหมดมีแผนนำเสนอ SOA ที่อยู่ระหว่างการดำเนินการในขณะนี้ เหตุผลข้อหนึ่งที่ทำให้เราต้องติดตามอย่างใกล้ชิดคือ SOA อาจส่งผลกระทบอย่างรุนแรงต่อการเปลี่ยนแปลงทั้งองค์กร แต่เป็นไปในทางตรงข้ามกับความพยายามแบบ “ไฟไหม้ฟาง” อื่นๆ ซึ่งแอพพลิเคชันและโครงสร้างพื้นฐานเกือบทั้งหมดนั้นมีพร้อมแล้วจะให้คุณนำมาติดตั้ง

ตลอดระยะเวลาสองปีที่ผ่านมา เราเคยได้สัมภาษณ์นักออกแบบสถาปัตยกรรมระดับองค์กร นักพัฒนา และพนักงานออฟฟิศผู้นำพาองค์กรต่างๆ มุ่งสู่การติดตั้ง SOA และยังเป็นผู้ได้รับบทเรียนแสนสาหัสที่ได้เพิ่มพูนข้อมูลเชิงลึก และเผชิญหน้ากับช่องว่างของเทคโนโลยีต่างๆ ตลอดเส้นทางการพัฒนา หลายๆ คนกำลังมีความสุขกับผลตอบแทนจาก SOA ที่สามารถควบรวมระบบได้ง่ายและสามารถนำรหัสข้อมูลกลับมาใช้ใหม่ได้ดี เมื่อนำประสบการณ์ของพวกเขาและข้อเสนอแนะจากผู้เชี่ยวชาญทางเทคโนโลยีอุตสาหกรรม พวกเราขอเสนอคู่มือปฏิบัติในการวางแผน ออกแบบสร้าง ติดตั้ง และบริหารจัดการ SOA

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

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

ขั้นตอนที่หนึ่ง

จงคิดการณ์ให้ใหญ่ แต่จงเริ่มต้นจากจุดเล็กๆ

SOA เริ่มต้นด้วยคำมั่นสัญญาทางธุรกิจประการหนึ่งที่ว่า ปล่อยองค์กรให้มีการรีเอนจิเนียร์ ตัวเองเพื่อให้พร้อมที่จะทะยานไปข้างหน้า จากจุดเริ่มต้นดังกล่าว จึงเริ่มต้นมองหาโอกาสต่างๆ ในการพัฒนาองค์กรให้มีความไวมากขึ้น ยิ่งเพิ่มพลวัตแก่ธุรกิจของเรามากแค่ไหน ธุรกิจยิ่งสามารถนำ SOA มาใช้ให้เกิดผลได้ดีมากขึ้นเท่านั้น และยิ่งคุณแบ่งปันวิสัยทัศน์ทาง SOA ร่วมกันมากแค่ไหน ผลดียิ่งมากขึ้นเป็นเงาตามตัว โดยตัวมันเองจะช่วยให้หุ้นส่วนทางธุรกิจของคุณเข้าใจในผลตอบแทนสูงสุดที่ได้จากการลดต้นทุนและการเพิ่มความไวในการตอบสนองต่อการเปลี่ยนแปลงต่างๆ ระหว่างองค์กร

“พวกเราค่อนข้างโชคดีที่ไม่จำเป็นต้องขายแนวความคิดเรื่อง SOA แต่อย่างใด” Ben Moreland ผู้ช่วยผู้อำนวยการฝ่ายบริการพื้นฐานที่ Hartford ซึ่งนำ SOA เข้ามาหลายปีก่อน “รองประธานอาวุโสของเรา John Chu ตระหนักดีถึงข้อดีและคุณค่าของ SOA อยู่แล้ว”

วิสัยทัศน์ที่มีการแลกเปลี่ยนให้กันนี้อาจดูกว้างครอบคลุมทุกส่วน แต่จะนำไปสู่การเริ่มต้นที่จุดเล็กๆ จุดหนี่งเสมอ “อย่าพยายามทำโครงงานประเภท ‘ต้มมหาสมุทรให้เดือด’” Ed Horst รองประธานฝ่ายการตลาดที่ AmberPoint ให้คำแนะนำในฐานะผู้เคยสังเกตการณ์เห็นความผิดพลาดจากการวางแผนที่มุ่งมั่นมากเกินไป “ผมคิดว่าโครงงานริเริ่มที่สัมฤทธิ์ผลมากที่สุดที่เราเคยเห็นคือโครงงานที่มีขนาดเล็ก ที่มีเซอร์วิสเพียงหกถึงสิบงานที่ผนวกองค์ประกอบสองสามอย่างเข้าด้วยกัน และใช้เวลาดำเนินการให้เสร็จสิ้นประมาณหกเดือน

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

โครงงานข้างต้นอาจให้ผลตอบแทนที่ลดน้อยลงไป แต่ SOA จะให้คุณค่าสูงสุด (และจะยิ่งเพิ่มขยายมากขึ้นในอนาคต) เมื่อคุณเริ่มต้นวาดกล่องสี่เหลี่ยมล้อมรอบกระบวนการทางธุรกิจที่เกี่ยวข้องกันชุดหนึ่งที่จำเป็นต้องมีการสตรีมมิ่งข้อมูล มากกว่าจะจู่โจมปัญหาทางเทคนิคก่อน Scott Thomson นักสถาปัตยกรรมอาวุโสของ H&R block มีประสบการณ์ในการเลือกใช้แนวทางดังกล่าว “พวกเราจำเป็นต้องทำใจให้สงบลงจากการตีความหมายของข้อมูล และหันไปสร้างเซอร์วิสบนพี้นฐานของข้อมูลเหล่านี้แทน เนื่องจากพวกเราทำได้เพียงแต่สอบถามว่า ธุรกิจของเรามีปัญหาอะไรบ้างที่พยายามแก้ไขอยู่ และขีดความสามารถในการประยุกต์เรื่องใดบ้างที่มีปัญหาเชิงธุรกิจที่กระทบต่อส่วนงานอื่นของบริษัท

Jean-Michel Van Lippevelde นักออกแบบสถาปัตยกรรมระบบที่ Accelior Consulting ก็ได้ข้อสรุปเดียวกัน “จงแก้ปัญหาจากบนสู่ล่างจากมุมมองของกระบวนการทางธุรกิจ” ผลลัพธ์ที่ได้สามารถมองเห็นได้ชัดเจนมาก ดังที่ Accelior’s engagement กับบริษัท ING Lease Belgium ซึ่งตั้งเป้าไว้ที่การผนวก กระบวนการร้องขอสำหรับออกใบเสนอราคาเข้าไปในการร่างใบสัญญาโดยอัตโนมัติ ก่อนหน้านี้กระบวนการดังกล่าวกินเวลาหนึ่งวัน แต่หลังจากที่ทำให้กระบวนการไหลลื่นขึ้น ด้วยการเล็งเห็นความสำคัญของบริการต่างๆ และนำระบบอัตโนมัติมาทดแทนขั้นตอนที่ใช้แรงงานคน ทำให้สามารถลดเวลารอคอยของลูกค้าได้หลายนาที

ขั้นตอนที่สอง

ใช้กระดานไวท์บอร์ด

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

“พวกเราเริ่มต้นการร่างแผนภูมิกระบวนการทำงานด้วยการประชุมกับองค์กรรัฐแต่ละกลุ่มที่เป็นอิสระต่อกัน” Dan Thomas ผู้อำนวยการหลักสูตร DC Stat ที่สำนักงานของ CTO ในรัฐโคลัมเบีย โครงงานที่เต็มไปด้วยความกระตือรือร้นกำลังผูก data warehouse ของหน่วยงานรัฐบาลกว่า 65 แห่งในรัฐโคลัมเบียทำให้เหล่าวุฒิสมาชิกทำงานได้อย่างโปร่งใสยิ่งขึ้นด้วยข่าวสารเพื่อการตัดสินใจเชิงนโยบายที่หลั่งไหลเข้ามาเกือบทุกนาที

ทีมงานของ Thomas พบปะกับองค์กรรัฐแต่ละกลุ่มเพื่อร่างภาพรวมของนโยบายการสรรหาข้อมูลและชี้บ่งให้ได้ว่าทำอย่างไรข้อมูลดังกล่าวจะถูกกลั่นกรองจนสามารถใช้นำเสนอได้ “มันเป็นกระบวนการที่กินเวลานานทีเดียว” เขากล่าว “แต่เราก็ไม่ได้พยายามพาเอาองค์กรรัฐทั้ง 65 แห่งออกมาพร้อมกันนะครับ พวกเราลดจำนวนลงให้อยู่ในระดับที่สามารถบริหารจัดการได้ ซึ่งในขณะนี้พวกเขากำลังอยู่ในความดูแลของเราแล้ว”

Timothy Vibbert วิศวกรระบบอาวุโสของบริษัท Lockheed Martin นำเอาวิธีแผนผังความคิดมาใช้ ในการนำเสนอบริการอย่างมืออาชีพให้กับองค์กรรัฐบาล โดยเขาใช้เวลามากไปกับกระดานไวท์บอร์ด เขากล่าวว่า“พวกเราก้าวผ่านการย่อยสลายโดเมนขนาดใหญ่ให้เล็กลง ก่อนที่เราจะคิดถึงการบริการต่างๆ เสียอีก คุณควรจะเริ่มมองหาสิ่งที่อยู่ภายนอกบริษัทที่สามารถนำกลับมาใช้ได้อีกครั้ง และเมื่อคุณไปกำหนดพันธะกิจหรือกระบวนการต่างๆ แล้วค่อยเจาะลึกลงสู่สิ่งที่คุณต้องการ”

หลังจากกำหนดขอบเขตงานแล้ว เป็นเรื่องสำคัญยิ่งที่คุณจะต้องกำหนดผู้ที่เข้ามามีส่วนร่วม หลังจากนั้นคุณก็เริ่มเขียนความต้องการในการใช้ระบบ (Use cases) ก่อนแล้วจึงเริ่มต้นแยกความต้องการการใช้ระบบย่อยออกมา เสร็จแล้วจึงเข้าสู่กระบวนการสรรหาทรัพยากรและข้อมูลต่างๆ เริ่มต้นวางเซอร์วิสต่างๆ ของคุณไว้ในระดับสูงและยังต้องพูดถึงข้อมูลที่มีการไหลไปตามที่ต่างๆ ด้วย” เขากล่าวย้ำเน้นว่า ขั้นตอนเหล่านี้เป็นขั้นตอนที่ต้องทำเป็นกิจวัตรซึ่งต้องอาศัยการทำซ้ำหลายรอบก่อนที่จะเขียนแผนกลยุทธ์ที่ถูกต้องเหมาะสมได้”

การเริ่มต้น SOA ทุกโครงการนั้นมีเอกลักษณ์เฉพาะตัว ดังนั้นระยะเวลาที่กระบวนการวางแผนใช้จึงแตกต่างกัน แต่ Vibbert ได้ให้เคล็ดลับว่า คุณจะแก้ไขแผนงานได้นานแค่ไหน คือ “ถ้าคุณมีองค์ประกอบบางชิ้นของ SOA วางไว้อยู่บ้างแล้ว คุณจะสามารถลดระยะเวลาลงได้อย่างรวดเร็ว โครงงาน SOA จากจุดเริ่มอาจกินเวลาหลายเดือนถ้าปราศจากความตั้งใจจริง”

ขั้นตอนที่สาม

สำรวจสภาวะแวดล้อมขององค์กรคุณ

เอาละตอนนี้กระบวนการทำงานทั้งหมดเริ่มปรับเข้าหาภาพลักษณ์ทางเทคโนโลยี ก่อนที่คุณจะนำมันมาใช้ จงพิจารณาว่าคุณสามารถควบคุมสิ่งใดได้บ้าง กฎพื้นฐานของ SOA ที่จำเป็นในระยะเริ่มต้นก็คือ จงเริ่มทำในสิ่งที่คุณมีและมองเห็นมันได้ชัดเจน แต่จงระมัดระวังไม่ให้ตัวเองยึดติดกับวิธีปฏิบัติหรือเทคโนโลยีที่ยังไม่มีความแน่นอนในอนาคตเกี่ยวกับความเข้ากันได้กับองค์ประกอบอื่นหรือเพิ่มขยายระบบ

การดูแลสินค้าคงคลังเป็นกระบวนการที่มีหลายขั้นตอน ขั้นแรกคุณจำเป็นต้องลงบันทึกแหล่งข้อมูลและแอพพลิเคชันเดิมที่มีส่วนเกี่ยวข้องกับการดำเนินงานขั้นแรกของคุณคือ ทบทวนเซอร์วิสของหุ้นส่วนที่อยู่ภายนอกไฟล์วอลล์ที่คุณจำเป็นต้องประสานงานด้วยและจัดกลุ่มเซอร์วิสเหล่านั้นด้วยความระมัดระวังเทียบเท่ากับเซอร์วิสที่อยู่ภายในบริษัท ขั้นต่อมานำเทคโนโลยีที่คุณมีอยู่ทั้งหมดมาเก็บรวบรวมไว้ใช้ในโครงงาน SOA ของคุณ แน่นอนว่ามันเป็นงานช้าง และไม่จำเป็นต้องทำให้เสร็จสมบูรณ์ก่อนทำโครงงานเริ่มต้น แต่ก็ไม่สามารถละเลยได้ถ้าโครงงาน SOA เป็นเป้าหมายของคุณ

SOA มีความเกี่ยวข้องกับเทคโนโลยีกลุ่มหนึ่งที่ทวีจำนวนมากขึ้นเรื่อยๆ สิ่งที่ต้องเตรียมคือ เครื่องมือสำหรับสร้างหรือตรวจสอบเซอร์วิสเหล่านั้น, ค่ารีจีสตรีต่างๆ ที่เกี่ยวข้อง โครงสร้างพื้นฐานแมสแสจสื่อสารที่วางไว้สำหรับเซอร์วิสและแอพพลิเคชันต่างๆ ไว้ใช้ในการติดต่อสื่อสารกัน วิธีการต่างๆ ที่ใช้ผนวกเซอร์วิสต่างๆ เข้าด้วยกัน และการจัดการเซอร์วิสบางประเภทที่เกี่ยวข้องกับตัวกลางเลเยอร์การสื่อสารต่างๆ งานบริหารเครือข่ายในระดับแอพพลิเคชันอาจเข้ามามีบทบาทด้วยเหมือนกัน ดังเช่นแอพพลิเคชันประเภท BPM (Business Process Management) และ BAM (Business Activity Monitoring) คุณอาจต้องเหนื่อยสักหน่อยในการมองหาอินเทอร์เฟซของเว็บเซอร์วิสสำหรับแอพพลิเคชันขององค์กรคุณ

มีตัวเลือกอยู่มากมายแต่คุณอาจไม่ต้องเสียแรงในการตัดสินใจเปลี่ยนแปลง เพิ่มเติม หรือเลือกเทคโนโลยีที่คุณจะใช้มากนัก คุณจะวุ่นอยู่กับการคิดหาวิธีเชื่อมโยงและปรับสภาพข้อมูลระหว่างระบบต่างๆ ที่มีอยู่ให้สอดคล้องกัน จากที่ Timothy Vibbert ของ Lockhead ได้บันทึกไว้ว่า ข้อมูลจากระบบต่างๆ นั้นสามารถ “กำหนดคุณลักษณะได้ถึง 15 วิธี 15 แบบสำหรับองค์ประกอบพื้นฐานที่เหมือนกัน” การผนวก metadata เข้าด้วยกันนั้นเป็นงานที่ค่อนข้างยากและน่าเบื่อ

ถ้าคุณไม่ได้เป็นผู้เชี่ยวชาญทางาด้าน SOA และยังไม่ไว้ใจที่จะจ้างที่ปรึกษาภายนอก จงอย่างเพิ่งหมดหวัง ยังไม่มีความจำเป็นต้องวิ่งไปสมัครเรียนที่ Learning Annex จงทำให้มากที่สุดเท่าที่คุณจะทำได้ ถ้าองค์กรของคุณประกอบไปด้วยรหัสคำสั่งชุดเล็กๆ และซอฟต์แวร์สำเร็จรูปเกือบทั้งหมด ลองติดต่อตัวแทนจำหน่ายของคุณดูสักครั้งหนึ่ง สอบถามเกี่ยวกับแผนโครงงานและขีดความสามารถของ SOA หลายๆ ครั้งคุณอาจประหลาดใจแนวทางที่พวกเขานำเสนอให้ และคุณอาจได้รับข้อมูลบางอย่างที่มีคุณค่าที่จะส่งผลดีต่อกำหนดการโครงการและการเลือกแพลตฟอร์มในอนาคต

“พวกเราย้ายแฟ้มข้อมูลผลิตภัณฑ์ไปสู่ SOA เนื่องจากลูกค้าเราต้องการแบบนั้น” Dwain Kinghorn ซีทีโอของ Altiris, ผู้ผลิตแพลตฟอร์มการจัดการด้านความปลอดภัย เครือข่ายและสินทรัพย์รายใหญ่ กล่าว “มันทำให้ลูกค้าเรามีอิสระในการเลือกการบริหารจัดการในแบบต่างๆ ของเรา พวกเขาสามารถเลือกหยิบข้อมูลการจัดการที่ต้องการทีละชิ้นและรวมกันเข้าบนอินเทอร์เฟซการจัดการแบบ SOA ในจอเดียวกัน พวกเขาอาจพัฒนาอินเทอร์เฟซติดต่องานของเขาเองก็ได้”

ขั้นตอนที่สี่

เริ่มต้นเชื่อมต่อกับเซอร์วิสตัวแรกของคุณ

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

คุณลักษณะพื้นฐานใดที่เซอร์วิสควรจะมีบ้าง?
Timothy Vibbert ร่างไว้ว่า เซอร์วิสต้องสามารถนำกลับมาใช้ซ้ำได้, ต้องมีพันธะสัญญา, มีการควบคุมที่เหมาะสม, ต้องมีความเสถียร, และต้องสามารถค้นหาได้ง่าย” ผู้ที่นำ SOA ไปใช้งานส่วนใหญ่มักกล่าวว่าเซอร์วิสนั้นควรมีลักษณะเป็น “เมล็ดใหญ่ๆ” นั่นคือ มันควรที่จะเชื่อมโยงขั้นตอนกระบวนการทางธุรกิจหรือหน้าที่มากกว่าจะเป็นองค์ประกอบของแอพพลิเคชัน อันจะช่วยให้เรามั่นใจได้ว่าความสามารถในการนำกลับมาใช้งานได้ใหม่และหลีกเลี่ยงการทับซ้อนของหน้าที่งานต่างๆ

Scott Thompson จาก H&R Block ได้เรียนรู้คุณค่าของแนวคิดแบบเมล็ดหยาบอย่างยากลำบาก “ผมคิดไว้ในตอนเริ่มต้นออกแบบ พวกเราพยายามพัฒนาเซอร์วิสโดยการปรับแต่งในระดับเชิงวัตถุมากกว่าเป็นงานบริการของธุรกิจอย่างแท้จริง ทำให้ความสามารถนำกลับมาใช้ได้ของเซอร์วิสที่สร้างขึ้นไม่สูงเท่าที่เราหวังไว้” เขากล่าว “ดังนั้นเราจึงย้อนกลับไปทำการออกแบบเซอร์วิสของเราใหม่ให้สามารถนำกลับมาใช้ใหม่ได้มากขึ้น ไม่เพียงแต่เฉพาะในโครงงานนี้เท่านั้นแต่ยังต้องมีการปรับแต่งด้วยวัตถุประสงค์ทางธุรกิจที่เซอร์วิสต่างๆ ถูกออกแบบให้มารองรับ”

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

เซอร์วิสต่างๆ โดยทั่วไปจะเผยแพร่ในแบบเว็บเซอร์วิส ซึ่งมีศักยภาพสูงสุดในการนำกลับมาใช้ใหม่ เนื่องจากใช้โปรโตคอลมาตรฐานที่กำหนดเว็บเซอร์วิสถูกออกแบบให้ไม่ขึ้นกับแพลตฟอร์มและภาษาโปรแกรมใดๆ โดยทั่วไปในทางปฏิบัติ SOA จะเปิดโอกาสให้เรามองเห็นเซอร์วิสชนิดอื่นด้วยเป็นต้นว่า JMS (Java Message Service)

คุณจะตัดสินใจได้อย่างไรว่าควรจะใช้เซอร์วิสแบบใด? “ประการหนึ่งคือมันขึ้นอยู่กับปริมาณภาระงาน” Vibbert จาก Lockhead กล่าว “ถ้าแมสแสจที่คุณส่งไปกลับมีขนาดไม่ใหญ่มาก เว็บเซอร์วิสก็พอใช้ได้ หรือถ้าความเร็วในการใช้งานไม่สำคัญมาก เว็บเซอร์วิสอาจเป็นทางเลือกที่ดีที่สุด แต่ถ้าคุณต้องทำงานกับข้อมูลปริมาณมากส่งไปกลับ หรือเวลาในการใช้งานเป็นเรื่องสำคัญ คุณอาจใช้เว็บเซอร์วิสไม่ได้” และควรใช้เข้าถึงเซอร์วิสผ่านทาง JMS หรือโปรโตคอลไบนารี่แบบอื่นๆ

เซอร์วิสสามารถวางไว้บนเครื่องเซิร์ฟเวอร์จาวาแอพพลิเคชัน บนเซิร์ฟเวอร์วินโดวส์ หรือแม้แต่วางไว้บนระบบดั้งเดิม ต้องขอบคุณความสามารถในการทำงานบนหลายๆ แพลตฟอร์มของเว็บเซอร์วิส นักพัฒนาระบบของคุณสามารถเลือกเครื่องมือและแพลตฟอร์มที่ถนัดในการพัฒนาระบบ “สิ่งหนึ่งที่ SOA ให้คุณคืออรรถประโยชน์ในตอบสนองความต้องการอันดับรองๆ ลงไป” Charles Stack ซีอีโอ Flashline ผู้ให้บริการจดทะเบียนโอเพ่นซอร์สกล่าว “คุณามารถเปลี่ยนแปลงแพลตฟอร์มต่างๆ ที่ระดับเซอร์วิสได้โดยไม่กระทบต่อ SOA ของคุณเลย เซอร์วิสต่างๆ นั้นจะวางอยู่บนระดับโครงสร้างพื้นฐานเท่านั้น ช่วยให้ง่ายต่อการตัดสินใจว่าควรใช้อุปกรณ์ใดบ้าง”

ขั้นตอนที่ห้า

เลือกและติดตั้งรีจิสทรีหรือคลังจัดเก็บ

องค์กรต่างๆ หลายแห่งมักกำหนดจุดเริ่มต้นโครงการ SOA เมื่อพวกเขาได้ติดตั้งรีจิสทรีไว้เป็นกลไกในการเปิดใช้งานเซอร์วิส อย่างน้อยรีจิสทรีก็ป้องกันการทำงานที่ซ้ำซ้อน เป็นแหล่งที่ทำให้นักพัฒนาระบบสามารถระบุว่าเซอร์วิสนั้นได้ถูกสร้างขึ้นมาแล้วหรือยัง Timothy Vibbert ของ Lockheed บันทึกไว้ว่า “มันอาจเป็นแค่เพียงเว็บไซต์หนึ่งที่มีรายการของเซอร์วิสต่างๆ ก็ได้ ซึ่งอาจเป็นคู่มือค้นหาแต่ก็ต้องสามารถค้นหาเซอร์วิสได้ง่ายเช่นเดียวกัน”

ทว่าขณะที่จำนวนเซอร์วิสและแอพพลิเคชันที่ใช้เซอร์วิสเพิ่มขึ้นเรื่อยๆ คุณจำเป็นต้องใช้รีจิสทรีที่ถูกต้อง “พวกเราเลือก UDDI รีจิสทรีในปี 2003 และนำไปใช้ในการผลิตปี 2004” Ben Moreland จาก Hartford กล่าว “พวกเราใช้รีจิสทรีตัวนี้เพราะความสามารถลักษณะ dynamic binding ซึ่งทำให้เรามีการเชื่อมโยงระหว่างฝั่งยูสเซอร์และผู้สร้างเซอร์วิสอย่างยืดหยุ่น”

การติดตั้ง SOA ส่วนใหญ่เป็นการนำเอาชุดของรีจิสทรีหรือคลังจัดเก็บเชิงพาณิชย์ที่ระบุขอบเขตหน้าที่การทำงานอย่างละเอียดมากกว่าที่กำหนดไว้ในข้อกำหนดของ UDDI ซึ่งโดยหลักๆ แล้วจะมีระเบียบวิธีในการจัดเก็บและจัดการ metadata ของเซอร์วิสอย่างเป็นแบบแผนมากกว่า เมื่อพิจารณาให้ลึกลงไปเราจะเห็นความแตกต่างระห่างรีจิสทรีและคลังจัดเก็บเพียงเล็กน้อย ตามคำจำกัดความบอกว่ารีจิสทรีประกอบไปด้วยข้อมูลที่เกี่ยวกับเซอร์วิสต่างๆ อันประกอบไปด้วยตำแหน่งที่ตั้ง แผนผังแบบ XML และอื่นๆ ขณะที่คลังจัดเก็บข้อมูลนั้นมีตัวเซอร์วิสต่างๆ อยู่ภายใน ในความเป็นจริง เซอร์วิสยังคงทำงานอยู่บนแพลตฟอร์มที่กำหนดไว้ ดังนั้นคลังข้อมูลจะจัดเก็บข้อมูล metadata ที่อยู่ในระดับที่ลึกลงไป กล่าวโดยเสริมคือ รีจีสตรีที่โดยทั่วไปจะมีความสามารถของคลังข้อมูลอยู่ในตัวอยู่แล้ว เพียงแต่ไม่ได้มีการเรียกใช้แต่อย่างใด

การเลือกรีจิสทรีอาจเป็นการตัดสินใจครั้งแรกสุดในการเลือกซื้ออุปกรณ์อยู่ภายใต้ข้อกำหนดของ SOA และอาจเป็นครั้งแรกที่คุณต้องเผชิญหน้ากับการตัดสินใจเลือกระหว่างข้อเสนอที่ผู้ผลิตแต่ละรายกับโซลูชั่นของผู้ผลิต SOA ชั้นยอด ผู้ผลิตแพลตฟอร์มรายใหญ่ทั้งหมดเช่น บีอีเอซิสเต็มส์ ไอบีเอ็ม ไมโครซอฟท์ ออราเคิล และซันจะมีรีจิสทรีและคลังข้อมูลของพวกเขาเอง ทว่าผู้ผลิตซอฟต์แวร์เฉพาะทางโดยตรงที่ประสบความสำเร็จไม่ว่าจะเป็น Above All Software, Flashline, Infravio, SOA Software, และ Systinet โดยทั้งหมด ต่างก็แสดงให้เห็นถึงการผสมผสานความสามารถในด้านต่างๆ ได้อย่างกลมกลืน คุณได้พบกับเครื่องมือต่างๆ มากมายไม่ว่าจะเป็นการแสดงผลความสัมพันธ์ระหว่าง WSDL กับเซอร์วิสต่างๆ ในแบบกราฟิก ระบบรักษาความปลอดภัยด้วยรหัสส่วนบุคคลเพื่อจำกัดสิทธิ์การเข้าถึงเซอร์วิสต่างๆ กลไกควบคุมที่ช่วยจัดการนโยบายของเซอร์วิสต่างๆ และอื่นๆ อีกมากมาย

เมื่อต้องตัดสินใจระหว่างรีจิสทรีกับคลังจัดเก็บข้อมูล David Aubrey นักวางระบบอาวุโสที่ Komatisoft บริษัทผู้บุกเบิกแอพพลิเคชันทางการเงินในนิวยอร์ค เลือกที่จะพิจารณาในมุมมองของผู้ผลิตรายเดี่ยว “หากคุณกำลังใช้เฟรมเวิร์คแบบใดอยู่ก็ตาม พวกเขาจะผลักดันให้ใช้คลังข้อมูล ในพื้นที่ทำงานหนึ่งๆ ผมพยายามที่จะไม่ใช้ทางเลือกจากบริษัทอื่นอีกนอกจากจำเป็นต้องใช้จริงๆ ซึ่งอย่างน้อยในวันนี้ยังไม่จำเป็นต้องใช้ สิ่งสำคัญก็คือความสามารถในการทำงานร่วมกันกับเฟรมเวิร์คและกลไกควบคุมของมันได้ซึ่งนั่นเป็นสิ่งที่ผู้ผลิตรายเดี่ยวรับประกันให้คุณได้ แต่ถ้าคุณนำโซลูชั่นจากผู้ผลิตรายอื่นเข้ามาอีก คุณกำลังทำให้ความสอดคล้องของระบบโดยรวมตกอยู่ในความเสี่ยง”

ขณะที่ Stack ของ Flashline มีมุมมองที่ตรงข้ามกัน “ถ้าคุณกำลังสร้างโครงสร้างพื้นฐานให้กับ SOA บนแพลตฟอร์มของผู้ผลิตรายหนึ่งที่เหมาะสมรายใดรายหนึ่ง ผมคิดว่าคุณกำลังทำผิดมหันต์ เรามักจะเตือนลูกค้าทั้งหมดของเราอยู่เสมอจากจุดยืนของโครงสร้างพื้นฐานให้เปิดกว้างโดยเลือกสิ่งที่ดีเยี่ยมใส่ลงไป เนื่องจากคุณจะพบกับประสบการณ์ที่เลวร้ายจากการมีมุมมองติดอยู่ในวังวนของผู้ผลิตเพียงรายเดียว

ขั้นตอนที่หก

เริ่มประสานกับการกำกับดูแล

รีจิสทรีต่างๆ เป็นมากกว่าแค่กล่องบรรจุเซอร์วิสต่างๆ ที่อธิบาย metadata และทำให้ผู้ใช้และเซอร์วิสตัวอื่นหาเซอร์วิสที่ต้องการได้ง่าย รีจิสทรียังเป็นศูนย์กลางของการกำกับดูแลกับ SOA ที่ที่ฝ่ายไอทีสามารถที่จะเก็บรายการเจ้าของเซอร์วิสต่างๆ, หรือบริหารจัดการรายการปรับปรุงเวอร์ชั่นต่างๆ หรือใช้ตรวจสอบให้แน่ใจว่าเซอร์วิสนั้นมีความสอดคล้องกับความต้องการขององค์กร ฯลฯ ในไม่ช้าคุณจะเริ่มมองเห็นได้ดีขึ้นว่าการกำกับดูแลเกี่ยวข้องมีขั้นตอนกลไกการดำเนินการอย่างไรบ้าง

การกำกับดูแลนั้นอาจสามารถนิยามได้ชัดเจนว่าเป็นการผสมผสานของระเบียนวิธีในการดำเนินงานต่างๆ เช่นว่า ใครมีส่วนต้องรับผิดชอบในเซอร์วิสใด เมื่อมีเหตุการณ์ใดเกิดขึ้น เมื่อใดที่การรับประกันคุณภาพไม่ครอบคลุมถึงปัญหาต่างๆ และอื่นๆ รวมทั้งการจัดการเกี่ยวกับคำนิยามในอินเทอร์เฟซของเซอร์วิสต่างๆ คำนิยามเหล่านี้จะแฝงตัวอยู่ในผังองค์กรไอทีที่จะค่อยๆ เปลี่ยนรูปแบบอันเนื่องจากผลกระทบของ SOA อย่างคาดไม่ถึง “วิธีที่ดีที่สุดในการพิจารณาอินเทอร์เฟซของเซอร์วิสคุณก็คือมองว่าพวกมันถูกออกแบบจากธุรกิจคุณหรือไม่” Randy Heffner รองประธานบริษัท Forrester Research กล่าว “พวกมันควรที่จะได้รับการเอาใจใส่และกำกับดูแลพอๆ กับเวลาที่คุณออกแบบธุรกิจของคุณ”

SOA เป็นกรอบความคิดพื้นฐานใหม่ของไอที ดังที่ผู้บริหารไอทีของบริษัทการเงินผู้ไม่ประสงค์ออกนามกล่าวไว้ว่า “เมื่อคุณเพิ่มความซับซ้อนและการเกี่ยวพันเข้าไปในระบบ มันจะทำให้เกิดปัญหากลุ่มใหม่ขึ้นมา ยิ่ง SOA ประสบความสำเร็จมากแค่ไหน การบริหารจัดการยิ่งมีปัญหามากขึ้นเท่านั้น” ผู้บริหารคนนี้เชื่อว่า การกำกับดูแลควรเป็นการกระจายศูนย์มากกว่าการรวมศูนย์ซึ่งเป็นไปในทางเดียวกับที่ทางความสัมพันธ์ระหว่างรัฐบาลกลาง มลรัฐ และการปกครองส่วนท้องถิ่นในระบอบประชาธิปไตย และเขาก็หมายความในสิ่งที่เขาพูดอย่างตรงไปตรงมาเนื่องจากในขณะนี้เขากำลังศึกษาบทความของรัฐบาลกลางอย่างเจาะลึก

ในปี 2004 บริษัท Harford จัดตั้งทีมงานด้านการออกแบบสถาปัตยกรรมองค์กรเพื่อนำเอากระบวนการกำกับดูแลที่อยู่แวดล้อมโครงการต่างๆ ตามที่ Moreland กล่าวไว้ในตอนเริ่มต้นว่า กระบวนการกำกับดูแลเป็นเรื่องเกี่ยวกับการติดต่อสื่อสารทั้งสิ้น “พวกเรามีนักสถาปนิกนั่งคุยกันเป็นครั้งแรกที่ช่วยกันแก้ปัญหาเดียวกันแต่อยู่คนละสายงานธุรกิจ ตอนนี้เรามาถึงจุดที่เราอาจหยุดโครงการถ้ามันไม่สอดคล้องกับสถาปัตยกรรมเดิมหรือไม่อยู่ในพิมพ์เขียวสายงานธุรกิจ และพวกเราได้รับอำนาจหน้าที่ที่ได้รับมอบหมายจากผู้บริหารระดับบนในการดำเนินการดังกล่าว”

Moreland ให้กรณีตัวอย่างหนึ่งของปัญหาที่หากมีการกำกับดูแลที่ดีจะสามารถหลีกเลี่ยงได้ เมื่อไม่นานมานี้ หน่วยธุรกิจหนึ่งของ Hartford ที่ได้เผยแพร่เซอร์วิสที่มีประโยชน์ตัวหนึ่งในฟอร์มของ SOAP ที่เหมาะสม ขอบข่ายอื่นของธุรกิจได้ประยุกต์เซอร์วิสดังกล่าวไปใช้ อีกทั้งยังขอร้องให้เซอร์วิสคืนค่าข้อมูลเพิ่มเติมกลับมาในรูป XML “เจ้าของเซอร์วิสตัวแรกกล่าวว่า ‘ผมไม่มีเงินทุน งบประมาณหรือทรัพยากรที่จะทำอย่างนั้น ผมยังต้องทำอีกหลายอย่าง’” Moreland ย้อนกลับไปถึงเหตุการณ์ในอดีต ในกรณีดังกล่าวเขากล่าวว่าการกำกับดูแลที่ดีนั้นจะระบุได้ถึงเซอร์วิสที่มีปัญหานั้นที่ควรจะถูกดูแลโดยทีมงานที่ทุ่มเทกับการดูแลปรับปรุงมันเพื่อองค์กรทั้งหมด

ขั้นตอนที่เจ็ด

วางแผนระบบความปลอดภัยของคุณ

หลายปีก่อนเมื่อครั้งที่วงการอุตสาหกรรมเริ่มนำเสนอแนวคิดเว็บเซอร์วิส คำคัดค้านประการแรกที่หยิบยกขึ้นมาคือ แล้วอะไรคือระบบความปลอดภัยล่ะ นั่นเป็นเพราะเมื่อมองย้อนกลับไปสิ่งที่กำลังอยู่ในความสนใจคือการผนวก XML ระหว่างองค์กร ในทางตรงข้าม SOA มีแนวโน้มที่จะมุ่งความสนใจไปที่สถาปัตยกรรมแบบองค์กรเดี่ยว หรือองค์กรที่อยู่ใกล้ชิดกันเท่านั้น ภายใต้ข้อสมมติฐานที่ว่าทุกสิ่งทุกอย่างเกิดขึ้นในอาณาเขตที่ได้รับความไว้วางใจขนาดใหญ่เขตเดียว

“คนมากมายมีความรู้สึกว่า ‘เมื่อผมทำอะไรภายในไฟล์วอลล์ ภายใต้บริเวณเครือข่ายจำกัดสิทธิ์หรืออะไรก็ตาม ผมรู้สึกปลอดภัยแม้ว่าจะปราศจากระบบรักษาความปลอดภัยที่ซับซ้อนในสภาพแวดล้อมของเซอร์วิสผม’” Heffner จาก Forrester กล่าว “เมื่อทุกคนพูดว่า ‘ผมต้องทำบางสิ่งบางอย่างเกี่ยวกับความปลอดภัย’ มักหมายถึงการเชื่อมต่อภายนอก”

แม้ว่า SOA จะย้ายจุดสนใจไปสู่สถาปัตยกรรมภายใน การผนวกกิจการแบบ B to B ของหุ้นส่วนเป็นการขยายตัวโดยธรรมชาติ และในหลายกรณีก็คือผลประโยชน์หลัก โซลูชั่นในการทำงานข้ามไฟล์วอล์ลสองฝั่งอาจทำได้ง่ายๆ โดยใช้การเชื่อมต่อแบบ SSL ทั้งสองข้าง แต่ก่อนที่คุณจะข้ามไปสู่ข้อสรุปทางเทคโนโลยีใดๆ Heffner ให้คำแนะนำว่าการตัดสินใจครั้งแรกของคุณคือการบอกว่าองค์กรของคุณเป็นแบบ Hub หรือ Spoke

Heffner กล่าวว่า Hub เปรียบได้กับกฎหมาย “ถ้าคุณคือ Walmart ในฐานะที่เป็น Hub คุณเพียงแค่บอกว่าสถาปัตยกรรมจะออกมาในรูปแบบใด เนื่องจากทุกคนต้องทำตามที่คุณบอก” ขณะที่ Spoke “คุณต้องพิจารณาว่าหุ้นส่วนของคุณ ใครบ้างที่คุณต้องติดต่อด้วย สถาปัตยกรรมความปลอดภัยแบบใดที่กำลังทำอยู่ และเมื่อตัดสินใจกำหนดว่ากลยุทธ์ความปลอดภัยของขอบเขตภายนอก ดังนั้นคุณจึงต้องมีเกตเวย์ที่มีระบบความปลอดภัยแบบ XML ซึ่งสามารถกำหนดให้สิทธิการเข้าถึงและสิทธิการใช้งานในระดับนั้นๆ” หรือในความปลอดภัยระดับที่ลึกลงไปที่ซึ่งสิทธิการเข้าถึงอยู่ในรูปเอกสาร XML ขณะที่พวกมันเคลื่อนที่ไปมาภายในองค์กร

โชคดีที่วงการอุตสาหกรรมต่างเห็นพ้องต้องกันในเรื่องกรอบการทำงานพื้นฐานสำหรับการรักษาความปลอดภัยแมสแสจ XML ที่อยู่เหนือเวลาขณะที่พวกมันกำลังเดินทางอยู่: WS-Security ซึ่งอาจเป็นข้อกำหนดเว็บเซอร์วิสที่ใช้บ่อยที่สุดหลังจาก SOAP และ WSDL ทุกวันนี้องค์กรต่างๆ มากมายได้รวม WS-Security กับ SAML tokens เพื่อประกาศตัวตนของผู้ใช้ตลอดจนทุกขั้นตอนของการโอนถ่ายข้อมูล ซึ่งเป็นโซลูชั่นที่มีประโยชน์มากสำหรับองค์กรที่ให้บริการทางด้านการเงิน

ข้อกำหนดทางด้านความปลอดภัยมากมายที่อยู่ในขั้นตอนการพัฒนา WS-Trust เป็นส่วนขยายของ WS-Security ที่ยืนยันว่าผู้ร้องขอเซอร์วิสได้รับสิทธิการใช้ก่อนที่ security token จะได้การตอบรับ WS-SecureConversation นำข้อมูล trust ที่ดึงออกมาจากระบบยืนยันตัวตนที่ได้รับการยอมรับ (positive authentication) ส่งไปยังกลุ่มแมสแสจต่างๆ แล้ว WS-SecurityPolicy จะอนุญาตให้เซอร์วิสสามารถแลกเปลี่ยนนโยบายความปลอดภัยและเจรจากับระบบยืนยันตัวตน (authentication) และระบบยืนยันสิทธิการใช้งาน (authorization) โดยปราศจากการแทรกแซงของยูสเซอร์ อย่างไรก็ตามข้อกำหนดทั้งสามตัวนี้ที่มีใช้กันอย่างแพร่หลายในปัจจุบันนั้นยังไม่มีตัวใดเลยที่ครอบคลุมเพียงพอสำหรับโลกของการสื่อสารแมสแสจ XML ข้ามโดเมน
“สำหรับเราแล้ว นี่คืออีกขอบเขตงานหนึ่งที่เรากำลังทุ่มเทอย่างเต็มกำลังความสามารถจนกว่ามาตรฐานใหม่และการประยุกต์ใช้จะเกิดขึ้นและทำให้งานต่างๆ ง่ายขึ้น” Bob Laird หัวหน้าทีมออกแบบระบบไอทีที่ MCI กล่าว ในเวลาเดียวกัน Laird กำลังให้ความสนใจกับระบบป้องกันการโจมตีจากภายนอก อันเป็นความพยายามที่จะผสมผสานการสร้างตัวจัดการความปลอดภัยโครงสร้างพื้นฐานที่คอยระมัดระวังการไหลของการจราจรและการโอนถ่ายข้อมูลใหม่ๆ และการลงทุนกับฮาร์ดแวร์เชิงป้องกันของ SOA เช่น ไฟล์วอลล์ XML จาก Sarvega

“เรื่องที่ไม่ดีบางอย่างอาจเกิดขึ้นก่อนที่เครื่องมือรักษาความปลอดภัย SOA จะได้เริ่มต้นใช้งาน” Laird กล่าว “พวกเราจะได้เห็นการโจมตีบน XML อาจเป็นไวรัสเข้าเจาะระบบของบางคน ซึ่งนั่นจะนำไปสู่การกระตุ้นให้วงการอุตสาหกรรมเกิดการตื่นตัว”

ขั้นตอนที่แปด

วางโครงสร้างพื้นฐานระบบสื่อสารแมสแสจ

การตัดสินใจที่สำคัญขั้นต่อไปในการเลือกเทคโนโลยีคือ แมสแสจต่างๆ มีการรับส่งระหว่างเซอร์วิสและแอพพลิเคชันได้อย่างไร ด้วยการดำเนินการโครงการ SOA ในสเกลเล็กๆ ทำให้คุณสามารถทดลองเชื่อมต่อ XML แบบซิงโครนัสเพื่อจำลองว่าเซอร์วิสนั้นพร้อมใช้งานตลอดเวลา อย่างไรก็ตามหากมีการประยุกต์ใช้งานกว้างขึ้นและซับซ้อนขึ้นการสื่อสารแมสแสจแบบอะซิงโครนัสที่มีความเชื่อถืออาจมีความจำเป็น เนื่องจากแบบแผนการสื่อสารแมสแสจที่แตกต่างกันสามารถรองรับได้กลายวิธีและอันตรายจากการเกิด lock-in ก็เพิ่มขึ้นด้วย

ESB (Enterprise Service Buses) และ EAI middleware จากพันธมิตรทางธุรกิจอย่างเช่น Tibco หรือ webMethods และเซิร์ฟเวอร์แอพพลิเคชันจากบีอีเอ ไอบีเอ็ม และออราเคิล ขยายขีดความสามารถด้วยการผนวกโปรแกรมเสริมที่ทำหน้าที่สื่อสารแมสแสจแบบอะซิงโครนัสที่ไว้ใจได้ ซึ่งจะรองรับครอบคลุมโปรโตคอลสื่อสารแมสแสจทั้งหมดรวมทั้ง SOAP, JMS (Java Message Service), และ MQ (Message Queuing) และซึ่งได้เพิ่มตัวแปลงแอพพลิเคชันสำหรับระบบดั้งเดิม อย่างไรก็ตามในปัจจุบันโซลูชั่นแต่ละตัวมีวิธีการของตัวเองในการยืนยันว่าแมสแสจได้มาถึงแล้ว ซึ่งเป็นสภาพการณ์ที่ไม่ค่อยจะมีการเปลี่ยนแปลงแม้จะมีมาตรฐานการตรวจจับข้อมูลที่กว้างเช่น WS-ReliableMessaging

ESB รับผิดชอบขอบเขตการทำงานที่ยังมีความคลุมเครืออยู่ ขณะที่ Ben Moreland จาก Harford กล่าวว่า “ถ้าคุณมีนักออกแบบระบบ 10 คนอยู่ด้วยกัน คุณอาจได้รับคำนิยาม ESB ถึง 11 แบบ บางคนบอกว่ามันเป็นรูปแบบทางสถาปัตยกรรม ขณะที่อีกคนหนึ่งบอกว่ามันคือผลิตภัณฑ์เดี่ยวตัวหนึ่ง คนอื่นที่เหลือก็อาจบอกว่าเป็นชุดผลิตภัณฑ์กลุ่มหนึ่ง” แม้แต่ในหมู่ผลิตภัณฑ์ของ ESB ที่ทางห้องทดสอบของเราได้ลองทดสอบก็ยังประหลาดใจที่พบว่าผลิตภัณฑ์เหล่านี้มีความหลากหลายมาก

ผู้คนส่วนใหญ่มักมีแนวโน้มตามธรรมชาติที่จะยึดติดกับสิ่งที่พวกเขามีอยู่เดิม Bob Laird ที่ MCI แบ่งปันประสบการณ์ให้ฟังเป็นกรณีตัวอย่าง “พวกเราตัดสินใจร่วมกันที่จะใช้ WebSphere เนื่องจากเราได้ติดตั้ง IBM MQ อยู่แล้ว ซึ่งฟังแล้วดูสมเหตุผล ประกอบกับมันทำให้นักพัฒนาระบบของเราปรับตัวสู่แนวคิดของ SOA ได้สะดวกขึ้นด้วยเครื่องมือที่พวกเขาคุ้นเคย”

Vibbert จาก Lockhead ไม่เห็นด้วยกับแนวโน้มข้างต้นอย่างสิ้นเชิง แม้ว่าเขาจะชอบโซลูชั่นทางด้านสื่อสารแมสแสจที่เป็นมาตรฐานและมีขนาดเล็กของ Sonic ESB ที่อาศัยโครงสร้างของ JMS เขาไม่ได้พยายามชักจูงให้ผู้ใช้งานเปลี่ยนมาใช้ถ้าหากพวกเขามีความสัมพันธ์ที่ลึกซึ้งกับผู้ให้บริการเจ้าอื่นที่มีฟังก์ชั่นการทำงานคล้ายคลึงกัน

ทว่ามีเรื่องเล่าบางเรื่องโดยเฉพาะจากร้านค้าขนาดเล็กที่ได้ลดความสนใจลงจากเดิมที่เคยใช้ผู้ค้ารายเดียว “สำหรับเราแล้ว ความยืดหยุ่นเป็นสิ่งที่สำคัญที่สุด” Paul Lindo ผู้ชำนาญการพัฒนาระบบมานานกว่า 13 ปีที่ Federal Reserve และในตอนนี้ดำรงตำแหน่งเป็นซีไอโอบริษัทพัฒนาระบบเล็กๆ ในนิวยอร์ก “สิ่งที่คุณจะได้จากระบบสื่อสารแมสแสจเช่น MQ คือเทคโนโลยีตัวเก่าเอามาปรับปรุงใหม่ด้วยแนวคิดใหม่ของ SOA สำหรับพวกเราแล้วการยึดติดกับมาตรฐานของเว็บเซอร์วิสเป็นเรื่องที่สมเหตุผลมากกว่า”

Laird จาก MCI ยอมรับว่าการพึ่งไอบีเอ็มไปจำกัดทางเลือกในระยะยาว แต่เขาก็เต็มใจที่จะยอมรับมันแลกกับการที่สามารถเริ่มต้น SOA ได้ในวันนี้, พอใจกับการมีต้นทุนแพลตฟอร์มเริ่มต้นที่ต่ำ และทำให้โครงงาน SOA ของเขาเจริญเติบโตไปพร้อมๆ กับชุดผลิตภัณฑ์ของไอบีเอ็ม “และได้โปรดอย่างคิดว่าพวกเราหลับหูหลับตายอมใช้เครื่องมือที่เก่าๆ โทรมๆ” Laird ชี้แจงว่า MCI ท้าทายให้นักพัฒนาระบบของเขาให้ลองใช้เครื่องมืออื่นๆ ที่ไม่ใช่ของไอบีเอ็มตั้งแต่มันเริ่มวางตลาด ซึ่งกลายเป็นที่นิยมในการจัดซื้อในปริมาณน้อยๆ ในตอนแรกและจับรวมไว้ในโครงการเฉพาะกิจต่างๆ ในภายหลัง ถ้าพวกมันผ่านการทดสอบ พวกมันจะให้ผลตอบแทนอย่างมหาศาล “ด้วยวิธีนี้ เรายังคงรักษาให้มีการเปิดกว้างทางความคิดขณะที่สามารถหลีกเลี่ยงปัญหาความไม่สอดคล้องกับระบบโดยรวมได้”
“บริษัทส่วนมากที่ใช้งานระบบมิดเดิ้ลแวร์ที่เน้นการสื่อสารแมสแสจอยู่นั้นไม่ได้ออกแรงเท่ากับกับที่พวกเขาเคยมีเนื่องจากมันไม่มีเหตุผลที่จะใช้แบบโครงสร้างข่ายงานสื่อสารแมสแสจแบบโรบัส ที่มีหลายบริษัทอยู่ในตำแหน่งเดียวกัน” Stack จาก Flashline กล่าว “ดังนั้นเว้นแต่ว่าคุณจะไม่ต้องการมีสิ่งดังกล่าว ดูเหมือนว่าโซลูชั่น MOM (Message-Oriented Middleware) จะกำลังกลายเป็นเซอร์วิสการสื่อสารแมสแสจที่น่าเชื่อถือ และส่วนใหญ่ยังประกาศความตั้งใจในการสนับสนุนโปรโตคอลการสื่อสารแมสแสจที่เชื่อถือได้

ผู้บริหารด้านเทคโนโลยีที่สมาคมเกี่ยวการเงินเป็นหลักเสนอการสนับสนุนมุมมองแบบนี้ โซลูชั่นของเขาเกี่ยวกับการสื่อสารแมสแสจแบบอะซิงโครนัสเป็นผลิตภัณฑ์ของ EAI ที่นอกจากออกแบบสร้างขึ้นเป็นอย่างดีแล้วยังมี binary throughput ที่จำเป็นสำหรับการโอนถ่ายข้อมูลปริมาณมากๆ เมื่อถูกถามความเห็นเกี่ยวกับ ESB เขาตอบกลับด้วยคำถามว่า “ทำไมผมจะต้องไปหาโซลูชั่น JMS ที่มีขนาดเล็กตัวอื่นอีกในเมื่อผมมีโซลูชั่นที่ทรงประสิทธิภาพตัวหนึ่งอยู่แล้ว?”

ขั้นตอนที่เก้า

ติดตั้งระบบบริหารจัดการเซอร์วิส

ถ้าเซอร์วิสมีจำนวนมากกว่าที่ดูแลได้ทั่วถึงเริ่มทำงานและถ้าทั้งหมดมีความจำเป็นอย่างยิ่งต่อพันธะกิจแล้วละก็ คุณจำเป็นที่จะต้องจัดการเซอร์วิสเหล่านี้ด้วยวิธีที่คุณสามารถนำทรัพยากรเครือข่ายทั้งหมดมาใช้ได้อย่างเต็มประสิทธิภาพ ผู้ผลิตหลายรายเสนอโซลูชั่นในลักษณะของหน้าปัดควบคุมเพื่อตรวจสอบสุขภาพของเซอร์วิส ดูแลรักษาให้ระดับเซอร์วิสให้อยู่ในมาตรฐาน เพิ่มประสิทธิภาพของเซอร์วิส ปรับตั้งค่าใหม่เมื่อมีความผิดพลาดเกิดขึ้น จัดการกับเหตุการณ์ที่ไม่คาดคิด และอื่นๆ สิ่งเหล่านี้เป็นไปได้เนื่องมาจากความมหัศจรรย์ของการสื่อสารแมสแสจด้วย XML ซึ่งยอมให้ตัวกลางอื่นๆ ที่เป็นเซอร์วิสเหมือนกันหรือบางครั้งก็เป็นแพ็คเกจที่อยู่ในอุปกรณ์ต่างๆ เพื่อแทรกเข้าไปในสตรีมของแมสแสจต่างๆ

ตัวกลางดังกล่าวจะสร้างชิ้นส่วนใหม่ของหน้าที่ระหว่างเลเยอร์เครือข่ายกับเลเยอร์แอพพลิเคชัน เมื่อพิจารณาอรรถประโยชน์อื่นๆ ตัวกลางตัวกลางทำให้มองเห็นเซอร์วิสต่างๆ สร้าง proxy ที่ซ่อนรายละเอียดของการใช้งานเซอร์วิสจากฝั่งผู้ใช้บริการแล้วเพิ่มความปลอดภัยเข้าไป ตัวกลางอาจอยู่ในไฟล์วอลล์ XML ก็ได้หรือมีคุณสมบัติในการเร่งความเร็วขณะที่ความสามารถในการปรับปรุงกลุ่มเซอร์วิสใหญ่จากอินเทอร์เฟซควบคุมเดียว เพื่อตอบสนองต่อการเปลี่ยนแปลงในสภาวการณ์ปกติหรือเมื่อพบกับความต้องการใหม่ๆ เกี่ยวกับระบบรักษาความปลอดภัย

การจัดการเซอร์วิสกำลังพัฒนามาตรฐานขึ้นอย่างช้าภายใต้การอนุมัติ WSDM (Web Service Distributed Management) จาก OASIS เมื่อเดือนมีนาคมที่ผ่านมา ข้อกำหนดที่สอง WS-Management ซึ่งคาบเกี่ยวเล็กน้อยกับ WSDM แต่มุ่งความสนใจไปที่การจัดการฮาร์ดแวร์เครือข่ายมากกว่าการสื่อสารแมสแสจในระดับแอพพลิเคชัน ซึ่งถูกเสนอโดยทีมงานเฉพาะกิจด้านการบริหารจัดการเชิงกระจายศูนย์ (Distributed Management Task Force) โดยความร่วมมือของอินเทล ไมโครซอฟท์ และซัน ไมโครซิสเต็ม เมื่อเดินมิถุนายนที่ผ่านมา แต่ปัจจุบันในการใช้งานจริงส่วนมากแล้วคุณจำเป็นต้องใช้โซลูชั่นการจัดการบริหารเว็บเซอร์วิสกับการใช้งาน SOA ของคุณในกรณีที่คุณต้องการควบคุมการดำเนินงานแบบรวมศูนย์ เช่นที่ Bob Laird ของ MCI กล่าวว่า “ในตอนนี้มันกลายเป็นเรื่องที่มีความยุ่งเหยิงซับซ้อนแล้ว และพวกเราก็ทำได้แค่ลองผิดลองถูกไปเรื่อย”

เหล่าบรรดาผู้ผลิตซอฟต์แวร์ทางด้านนี้โดยตรงประกอบไปด้วย Actional, AmberPoint, Blue Titan, และ SOA software ที่เป็นผู้นำเสนอระบบจัดการบริหารเว็บเซอร์วิส แต่ผู้ผลิตระบบการจัดการเครือข่ายขนาดใหญ่กำลังรับช่วงต่อ เช่น บีเอ็มซี ซีเอ เอชพี ไอบีเอ็ม และโนเวลล์ ต่างก็ให้การสนับสนุน WSDM และอยู่ในขั้นตอนสถานะของการร่วมมือกันสร้างระบบจัดการเว็บเซอร์วิสตามข้อเสนอของพวกเขา ทางหนึ่งเป็นการกำเนิดของ AON (Application-Oriented Networking) ของ Cisco ที่ควรจะออกมาเป็นผลิตภัณฑ์ทางด้านเครือข่ายในอีกไม่ช้าพร้อมความสามารถทางด้านการจัดการเซอร์วิสด้วย

Scott Thompson ของ H&R Block กล่าว “พวกเราใช้ AmberPoint” แม้ว่าเขาจะยอมรับว่า เขาได้ค้นพบในเวลาต่อมาว่า โซลูชั่นดังกล่าวมีข้อจำกัดในเรื่องวิธีการที่ไม่ค่อยเป็นมาตรฐานเท่าไหร่ “พวกเรากำลังอยู่ในขั้นเริ่มหัดเดิน” เขากล่าว “เริ่มต้นด้วยระบบตรวจสอบการจัดการในระดับเซอร์วิสพื้นฐาน หลังจากนั้นพวกเราก็หันมาตรวจสอบเหตุการณ์ที่ไม่ปกติ แต่ในความเป็นจริงแล้วเราต้องการที่จะปรับปรุงตัวแบบของเราให้สามารถจัดการฟังก์ชั่นในส่วนของการเข้ารหัส การถอดรหัสข้อมูล การตรวจสอบสิทธิ และการให้สิทธิการเข้าถึงทรัพยากรของระบบ”

Ben Moreland ของ Hartford ให้ความเห็นว่า “ความสามารถในการตรวจพบเมื่อเกิดความผิดพลาดแบบ SLA หรือความผิดพลาดในส่วนของเซอร์วิส และความสามารถเพื่อผลักดันนโยบายต่างๆ” เป็นเหตุผลที่องค์กรเขาเลือกใช้เครื่องมือการจัดการบริหารเว็บเซอร์วิส

บางแห่งมองการจัดการนโยบายแบบรวมศูนย์ว่าเป็นสัญญาที่สำคัญที่สุดเหนือสิ่งอื่นๆ เนื่องจากมันทำให้การตรวจสอบสุขภาพของการทำงานเว็บเซอร์วิสในระดับท้องถิ่นทำได้ง่ายกว่าแบบอื่น แต่การปรับตั้งค่าเว็บเซอร์วิสนับพันตัวข้ามองค์กร คุณต้องการมาตรฐานการทำงานข้ามแพลตฟอร์มด้วย ซึ่งมาตรฐานของ WS-Policy ถูกออกแบบเพื่อรองรับงานนี้โดยเฉพาะ แต่การประยุกต์ใช้กับผลิตภัณฑ์ต่างๆ ยังอยู่ในระยะเริ่มต้นเท่านั้น

ขั้นตอนที่สิบ

พิจารณาการประสานการทำงานให้สอดคล้องกัน

ทุกแพลตฟอร์มนั้นรวมถึงวิธีบางอยางที่ทำให้เซอร์วิสสอดประสานการทำงานเข้าด้วยกัน ส่วนมันจะทำงานได้ดีหรือไม่นั้นเป็นอีกคำถามหนึ่ง ที่สุดแล้วการที่เซอร์วิสทำงานสอดคล้องกันจะเป็นสิ่งสำคัญยิ่งต่อการรวบรวมแอพพลิเคชันที่ประกอบกันด้วยกระบวนการทางธุรกิจในลักษณะที่เป็นพลวัตภายใต้วิสัยทัศนของ SOA มีไม่กี่แห่งที่กำลังอยู่ในช่วงทดลองนำมาใช้ทุกวันนี้เนื่องจากมันมีความซับซ้อนเกินกว่าจะถอดปลั๊กออกมาได้ง่ายๆ และเนื่องจาก SOA ที่ทันสมัยที่สุดเกิดอุบัติเหตุที่แฝงตัวอยู่ในโลกความเป็นจริงนั้นไม่ต้องการมันจริงๆ

Randy Heffner จาก Forrester Research เสนอแนวทางปฎิบัติบางประการ “จุดเริ่มต้นในการพิจารณาเกี่ยวกับความสอดคล้องนั้น ผมมีคำร้องประการเดียวคือ...ผมสามารถทำให้งานในหน่วยธุรกิจเสร็จสมบูรณ์ได้อย่างไร” เขาถาม “ถ้าคำตอบคือ ‘เอาละ ผมได้ทำหลายสิ่งให้เกิดขึ้นมาตามลำดับโดยมีแอพพลิเคชันหลายตัวที่อยู่ภายใต้งานเหลานั้น’ เมื่อนั้นแสดงว่าคุณกำลังอยู่สภาพแวดล้อมของการทำงานที่สอดประสานกัน” Heffner เสริมว่า การสอดประสานนั้นต้องการความอดทนในการค้นหาสิ่งที่ซ่อนอยู่ “เนื่องจากมีหลายสิ่งหลายอย่างที่คุณจำเป็นต้องทำในแอพพลิเคชันระดับที่ต่ำกว่า คุณแน่ใจได้เลยว่าจะไม่มีทางทำให้เกิดความสอดคล้องได้ในเวลาเสี้ยววินาที หรือแต่ในเวลา 5 วินาที”

ปัจจุบัน BPEL (Business Process Execution Language) ได้ให้วิธีการที่เป็นมาครฐานในการประสานการทำงานให้สอดคล้องกัน แม้ว่าโซลูชั่นทางด้าน BPM (Business Process Management) ที่ให้โครงสร้างความสอดคล้องในการทำงานที่เพียงพอมาหลายปีแล้ว “การสอดประสานคือความพยายามที่จะรวบรวมหลักเกณฑ์ของ BPM” Lindo ผู้ทำงานในองค์กรพัฒนาระบบในนิวยอร์คกล่าว “และนั่นเป็นความซับซ้อนจนคาดไม่ถึง ถ้าคุณนำมันไปใช้ในอุตสาหกรรมบางอย่างเช่น อุตสาหกรรมการผลิต คุณสามารถทุ่มเทความสนใจเพียงพอให้การจัดการแนวคิดดังกล่าวเป็นไปได้ ในการจัดการธุรกิจทั่วๆ ไป ความเกี่ยวพันต่างๆ นั้นซับซ้อนเกินกว่าที่จะจับรวมเป็นโครงงานจากมุมมองของการเขียนรหัสคำสั่งหรือออกแบบอินเทอร์เฟซติดต่ออันเป็นงานทำได้เชื่องช้าอย่างมาก”

Heffner จาก Forrest ร่างภาพความแตกต่างให้เห็นชัดเจนยิ่งขึ้นระหว่างความสอดประสานของเซอร์วิสต่างๆกับ BPM ซึ่งมีรากฐานมาจากการสร้างตัวแบบขั้นตอนการทำงานตั้งแต่เริ่มต้นจนสิ้นสุด “ทั้งสองส่วนยังเชื่อมต่อกันได้ไม่ดีเท่าไหร่” เขากล่าวขึ้น “ในภาษาของการสร้างตัวแบบ,... ไม่มีทางที่จะมีมุมมองของกระบวนการทำงานที่สมบูรณ์ทั้งหมดที่ผมบอกได้ว่า ‘ตกลงผมเห็นด้วย, จับขั้นตอนดังกล่าวใส่ลงใน BPEL ได้เลย’ ผมยังไม่เคยได้ทำอย่างว่าเลยสักครั้ง”

ในความเห็นของ Stack จาก Flashline ความผิดพลาดในการปรับแต่งเพิ่มความสะดวกให้กับการปฎิสัมพันธ์กับผู้ใช้งานเป็นจุดอ่อนที่สุดของ BPEL “เมื่อวงการอุตสาหกรรมกำลังพยายามนำ BPEL เข้ามาใช้เมื่อปีกลาย ผมคิดว่าการตัดสินใจที่จะทำโดยให้มีความสอดประสานการแบบเครื่องจักรไปยังเครื่องจักรเท่านั้นเป็นความผิดอย่างใหญ่หลวง” Stack กล่าวไว้ “พวกเราไม่มีลูกค้าคนใดเลยที่ใช้ BPEL ในทุกขั้นตอนเพียงแต่ใช้เพราะคิดว่าอยากทดลองหรือเป็นเรื่องเล็กน้อย” เขาเสริม รวมทั้งลูกค้าที่ใช้เว็บเซอร์วิสที่ซับซ้อนมากเช่น Sabre และ Countrywide

Ben Moreland จาก Hartford มองเห็นศักยภาพของส่วนขยายจากข้อกำหนด BPEL ที่มาจากการเสนอร่วมกันของ IBM และ SAP “เวลาผ่านไป เรามี BPEL4People ซึ่งเป็นมาตรฐานที่ผู้ผลิตรายใหญ่สองแห่งได้ร่วมกันผลักดันให้เกิดขึ้นมา เนื่องจากพวกเขาตระหนักถึงประสิทธิภาพของขั้นตอนการไหลของงานภายในข้อกำหนดของ BPEL” เขาอธิบาย “ผมคิดว่าในสองเลเยอร์ดังกล่าวคือ ความสอดประสานของ BPEL กับนั้นตอนการไหลของงาน BPM กำลังผนวกเข้าด้วยกันแล้ว”

ในเวลาเดียวกัน มันก็ไม่ได้กระทบต่อการเสาะหาโซลูชั่นทาง BPM ที่เหมาะสม ดังที่ Scott Thompson แห่ง H&R Block ได้ค้นพบ เป็นเรื่องที่น่าขันที่การทำงานกับเครื่องมือทาง BPM ของ Tibco จะช่วยให้ SOA เพิ่มประโยชน์ในบริษัทนี้ “กระทั่งเราได้เริ่มประสานการทำงานของเซอร์วิสที่หลากหลายเข้าด้วยกันไปสู่กระบวนการทางธุรกิจแล้ว เราไม่ได้มีการปรับแต่ง SOA ที่เห็นได้ชัดแต่อย่างใด” เขากล่าว “มันเป็นมากกว่าโครงการทางด้านไอทีระดับล่างเท่านั้น”

ก้าวอย่างสู่อนาคต

ทุกคนคงเคยได้ยินถ้อยคำที่นักเขียนชอบใช้กันที่ว่า “ปรับแต่งธุรกิจและไอที” นั้นคือนักเทคโนโลยีจำเป็นต้องอุทิศตัวเพื่อตอบสนองความต้องการของธุรกิจ ปัญหาไม่ได้เกิดจากความตั้งใจ แต่เกิดจากวิธีการ SOA ให้กรอบการทำงานที่จำเป็นสำหรับความรับผิดชอบของไอทีในอีกระดับหนึ่ง แม้ว่าเทคโนโลยีบางอย่างจะยังไม่สมบูรณ์ก็ตาม

การนำ BPM ไปสู่โครงสร้างพื้นฐานของ SOA ขนาดใหญ่นั้นแทนการก้าวกระโดดไปสู่ยุคใหม่ อีกส่วนคือการนำโซลูชั่น BAM แบบบูรณาการไปใช้ในวงกว้าง ซึ่งจะตรวจสอบสตรีมการสื่อสารแมจแสจของ SOA เพื่อช่วยในการบ่งชี้ว่ากระบวนการและแอพพลิเคชันต่างๆ ที่ทำงานร่วมกันนั้นได้ให้คุณค่าทางธุรกิจที่ดีที่สุดเท่าที่เป็นไปได้หรือไม่ นอกเหนือจากเทคโนโลยีเหล่านี้แล้ว ตัวกระตุ้นอุตสาหกรรมของ SOA วางตำแหน่งของตัวเองให้สูงขึ้น กว่าการปรับตั้งระบบไอทีใน Nirvana ให้เหมาะสมซึ่งการตรวจตราและปรับตั้งโครงสร้างพื้นฐานของแอพพลิเคชันและเครือข่ายด้วยตัวเองตามการปรับกฎทางธุรกิจที่เปลี่ยนแปลงไป

ถ้าการปรับตั้งค่าที่เหมาะสมโดยอัตโนมัติของ SOA มาถึงในสเกลขนาดใหญ่แล้ว มันไม่จำเป็นต้องเกิดขึ้นภายในทศวรรษนี้ก็ได้ ด้วยความก้าวหน้าขององค์กรในปัจจุบันในการบรรลุถึงความสอดประสานในการทำงาน SOA จำเป็นต้องอาศัยส่วนเติมเต็มช่องว่างอีกเล็กน้อย ในเรื่องความปลอดภัย การสื่อแมสแสจที่เชื่อถือได้ มุมมองทางสังคมศาสตร์ การจัดการกระบวน และอื่นๆ รวมทั้งการทำงานในวิธีการของมันโดยอาศัยประเด็นการกำกับดูแลสำคัญๆ ทั้งหมด

อย่างไรก็ตาม ยังมีคำถามว่าอะไรคือคุณค่าจริงที่ SOA นำมาให้เรา? “สิ่งหนึ่งที่ผมมองเห็นจากเรื่องราวส่วนใหญ่คือ การนำเอาเซอร์วิสต่างๆ ไปไว้ในที่ของมัน” Randy Heffner ของ Forrester “บางเซอร์วิสก็เป็นเซอร์วิสทางธุรกิจ แต่เซอร์วิสหลายตัวเป็นเซอร์วิสในระดับแอพพลิเคชันที่ไม่ได้จำลองแบบมาจากธุรกิจแต่อย่างใด แต่เปิดหนทางสู่แอพพลิเคชันที่คนทั่วไปไม่เคยทำได้มาก่อน” การตรวจประเมินดังกล่าวอาจให้ความกระจ่างในการเทียบกับคำมั่นสัญญาในโครงการใหญ่ แต่สำหรับงานไอทีมันเป็นสิ่งที่ทำให้ประโยชน์มาก

ในขณะเดียวกัน ผู้ที่วางแผนบนไวท์บอร์ดต้องทำงานหนักขึ้นเพื่อเตรียมให้พร้อมสำหรับอนาคตของ SOA มากกว่านักปรับแต่งระบบในอดีตที่ผลักดันให้เกิดการทำงานสอดประสานจนถึงขีดจำกัดของระบบ ตามที่ Ben Moreland ของ Hartford “จากมุมมองขององค์กร ประเด็นที่สำคัญที่สุดที่พวกเรามีนั่นคือการศึกษา SOA และการทำให้ผู้คนในองค์กรเข้าใจในบทบาทและหน้าที่ที่ได้รับมอบหมายอันแตกต่างจากที่เป็นอยู่เดิมเล็กน้อย ซึ่งเป็นมากกว่าการแบ่งความรับผิดชอบ ในตอนนี้คุณให้ความสนใจในขอบเขตพื้นที่ต่างๆ ของธุรกิจคุณ การควบคุมโครงสร้างพื้นฐานและเซอร์วิสต่างๆ จากขอบเขตพื้นที่อื่นๆ ซึ่งคุณอาจไม่เคยควบคุมได้มาก่อน” ในอีกความหมายหนึ่งคือ การเปลี่ยนแปลงวัฒนกรรมที่ให้สอดคล้องกับความท้าทายของ SOA สามารถเริ่มต้นได้ทุกเวลาที่คุณต้องการ

ส่วน Bruce Richardson หัวหน้าฝ่ายวิจัยที่ AMR Research กล่าวว่า “SOA เป็นการเดินทาง ไม่ใช่เป้าหมาย” ความพยายามในการทำ SOA ครั้งแรกจะสร้างความเชื่อมโยงในการสื่อสารระหว่างฝ่ายไอทีกับส่วนธุรกิจ และในบางกรณี การเริ่มต้นจะส่งผลกระทบต่อโครงสร้างองค์กรโดยรวมขณะที่ผู้คนเติบโตขึ้นด้วยความเข้าใจว่าวิถีทางของเซอร์วิสสามารถขจัดการทำงานที่ซ้ำซ้อนและลดเวลาในการพัฒนาระบบงานได้อย่างไร โดยนัยนี้อนาคตนั้นได้เริ่มเดินทางมาถึงแล้ว

บริหารจัดการแบบ SOA : กฎของการแข่งขันในธุรกิจ

บริหารจัดการแบบ Service Oriented Architecture SOA : กฎของการแข่งขันในธุรกิจ

SOA (Service-Oriented Architecture) สถาปัตยกรรมระบบแบบมุ่งให้บริการและเป็นอีกก้าวหน้าที่พัฒนาขึ้นเพื่อให้องค์กรได้รับประโยชน์มากที่สุด โดยเน้นไปที่การนำโค้ดกลับมาใช้ใหม่ ลดค่าใช้จ่ายโดยรวมขององค์กร มีการรักษาความปลอดภัยที่ดีขึ้น และแน่นอนว่าจุดสำคัญหนีไม่พ้นที่เพิ่มโอกาสทางธุรกิจให้มากขึ้นอีกด้วย มีการดำเนินธุรกิจที่คล่องตัวรวดเร็วเมื่อองค์กรได้รับผลประโยชน์ตามที่กล่าวมา แต่บางครั้งการจะได้ประโยชน์ทั้งหมดที่กล่าวมานั้นอาจจะต้องพึ่งพาการกำหนดโพลิซีและกำหนดรูปแบบการทำงานมากกว่า การให้ความสำคัญกับการเขียนโค้ดหลายเท่าตัวนัก

SOA ต้องการองค์กรที่มีรูปแบบในการทำงานที่ดีมากกว่าโมเดลในการพัฒนารูปแบบอื่น ซึ่งโดยความรู้สึกแล้วคุณอาจจะคิดว่าเราควรจะได้ผลลัพธ์ที่ยืดหยุ่นมากกว่าการโค้ดที่สั้นกว่าเดิม แต่สำหรับบางกรณีก็ไม่แน่เสมอไป

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

การกำหนดมาตรฐานเป็นการเสริมสร้างรากฐานสำหรับการบริหารจัดการแบบ SOA ระหว่างหน่วยงานต่าง ๆ ภายในองค์กร เพื่อป้องกันการพัฒนาด้านไอทีอย่างไม่เหมาะสมด้วยความสลับซับซ้อน ในอุตสาหกรรมต้องมีการจัดสร้างชั้นของซอฟต์แวร์ในเรื่องการลงทะเบียน ที่เก็บรวบรวม และระบบการจัดการใช้งาน นั่นเป็นการช่วยรักษากฎให้เป็นไปตามระเบียบ โดยไม่มีการสร้าง SOA ตามความต้องการ มากกว่าการที่จะนำ SOA ไปใช้เป็นเครื่องมือรากฐาน การบริหารจัดการแบบ SOA ต้องการองค์กรด้านไอทีที่ทำงานอย่างเอาจริงเอาจังในการเลือกเกี่ยวกับการออกแบบที่ซึ่งเป็นผลในกฎที่ออกแบบ

ชีวิตที่ขึ้นอยู่กับกฏ

การออกแบบกฎต้องกำหนดในเรื่องต่าง ๆ ไม่ว่าจะเป็นอินเทอร์เฟซ การพิจารณาแยกแยะส่วนประกอบที่แน่นอน และการแยกแยะขอบเขตระหว่างระบบย่อย เนื่องจากเป้าหมายเบื้องต้นของการออกแบบก็เพื่อเพิ่มเกณฑ์สำหรับการวัด และสร้างความชัดเจนในส่วนพื้นฐานที่เป็นนามธรรมของเซอร์วิส APIs หลังจากเลือกออบชันทั้งหมดแล้วสิ่งที่จำเป็นก็คือการบันทึก การสื่อสารให้รับรู้ และบังคับใช้ ซึ่งท้ายที่สุดแล้วเมื่อเรานำกฏที่ออกแบบขึ้นมาบังคับใช้ กฏนั้นก็จะกลายเป็นนโยบายที่ปฏิเสธไม่ได้อีกต่อไป

การพัฒนาและการบังคับให้เป็นไปตามกฎของนโยบาย SOA และระเบียบปฎิบัติเป็นไปโดยชื่อ การบริหารจัดการ(Governance)แบบ SOA การบริหาร การจัดการและสถาปัตยกรรมที่ออกแบบจะไปพร้อมกัน ในวิธีเดียวกันกับการสร้างโค้ด, มาตรฐาน และแม้แต่วิธีการตรวจสอบกระบวนการต่าง ๆ เพื่อให้ทุกอย่างเป็นไปตามกรอบที่วางเอาไว้ และSOA Governance นั้นก็จะเป็นส่วนนอกที่ครอบทั้งในเรื่องจองการออกแบบและสถาปัตยกรรมต่าง ๆ เอาไว้ทั้งหมดอีกเช่นกัน

“ถ้าหากไม่มีการบริหารจัดการแบบ SOA คุณก็จะลงเอยแบบ Web services ที่เป็น DLL แย่ ๆ ออกมา” Roman Stanek หัวหน้าการออกแบบซอฟต์แวร์และผู้ก่อตั้ง Systinet ผู้ให้บริการเกี่ยวกับ SOA กล่าว “การบริหารจัดการแบบ SOA ช่วยให้เกิดความแน่นอนในการดำเนินงาน ความสามารถในการคาดการณ์ และทำให้สามารถสร้างแอพพลิเคชันขนาดใหญ่จากงานในส่วนเล็กๆออกมาได้”

ถ้าคุณมีการปฏิบัติงานทางด้านไอทีเต็มรูปแบบอยู่ภายในองค์กรแล้ว นี่จะช่วยส่งเสริมการก่อตั้งการบริหารจัดการแบบ SOAมาได้ง่ายขึ้น ถ้าคุณมีความเชื่อมั่นการบริหารจัดการแบบอย่างไม่เป็นทางการในอดีต การขยับไปสู่การบริหารจัดการแบบ SOA ต้องการการเปลี่ยนแปลงบางสิ่งบางอย่างในการที่จะทำอย่างไรในการจัดการด้านการพัฒนาและการปฏิบัติงาน “องค์กรส่วนใหญ่จะประสบความล้มเหลวถ้าพวกเขาไม่ดำเนินการในสิ่งที่ถูกต้องในการบริหารจัดการ” Anne Thomas Manes ตำแหน่งรองประธานและผู้อำนวยการด้านวิจัยที่กลุ่มธุรกิจ Burton กล่าว “SOA เป็นเรื่องเกี่ยวกับพฤติกรรม ไม่ใช่บางสิ่งบางอย่างที่คุณจะสร้างหรือซื้อหา คุณจะต้องมีการเปลี่ยนพฤติกรรมเพื่อทำให้เกิดผลอย่างแท้จริง”

เมื่อกล่าวถึงในเรื่องนโยบายก็อาจจะทำให้ผู้เชี่ยวชาญด้านไอทีต้องเหงื่อตกกันบ้าง เพราะผู้พัฒนาโดยเฉพาะอย่างยิ่งผู้ที่คิดค้นสิ่งใหม่ๆ มักจะกังวลว่านโยบายและกฏเกณฑ์ต่าง ๆ นั้นจะทำให้ทำงานได้ไม่คล่องตัว เนื่องจากสิ่งที่เลวร้ายกว่าที่พวกเขาได้เรียนรู้จากประสบการณ์ก็คือนโยบายหลายอย่างเป็นไปไม่ได้ในโลกของความเป็นจริง พวกเขากลัวว่าการบริหารจัดการแบบนั้นจะนำไปสู่ภาวะคอขวดและเป็นไปไม่ได้ในทางปฏิบัติด้วยข้อจำกัดที่อยู่บนหอคอยงาช้าง แต่ถึงอย่างไรก็ตามถ้าให้ความสำคัญก็เป็นไปได้ที่จะสร้างแนวทางการบริหารจัดการที่ส่งเสริมการให้บริการให้สามารถทำได้ และได้ผลตอบแทนคุ้มค่าจากการที่มีพนักงานที่ทุ่มเทให้กับงาน

การกำหนดนโยบายให้เป็นที่พอใจ

จากข้อมูลของ Systinet’s Stanek ระบุว่าการจะให้ได้ผลในการบริหารจัดการนั้นขึ้นอยู่กับกระบวนการปฏิบัติงาน ที่ใช้สร้างนโยบายออกมา หรืออธิบายได้ว่า เป็นวิธีที่คุณใช้ทำ, สื่อสาร และกำหนดตัวเลือกที่บังคับใช้

การบริหารจัดการแบบ SOA ที่ดีเป็นการปฏิบัติที่เหมือนกับการมาประชุมกันของคนจำนวนมาก ๆ มากกว่าเป็นการทำการแบบเผด็จการ “สิ่งผิดพลาดที่ใหญ่ที่สุดขององค์กรที่ได้ทำคือการขาดการติดต่อสื่อสารทำความเข้าใจกันอย่างเพียงพอและขาดการทำงานร่วมกัน” จากคำกล่าวของ Burton’s Manes

ในส่วนของการปฏิบัติการตัดสินใจสามารถดำเนินการได้หลายทาง แต่ท้ายที่สุดกระบวนการทางสังคมที่ทำงานตามวัฒนธรรมในองค์กรเป็นวิธีที่ดีที่สุด “การเพิ่มขึ้นของระบบสังคมซอฟต์แวร์นั้นไม่ต่างจาก LinkedIn ที่ช่วยให้หลายๆ ส่วนเกิดความพอใจในการบริหารจัดการแบบ SOA” Miko Matsumura รองประธานด้านการตลาดที่ Infravio กล่าว “ขึ้นอยู่กับการวิเคราะห์ว่าบุคคลต่างๆ นั้นจะถูกจัดการอย่างไร การบริหารจัดการแบบ SOA ช่วยดึงเอาลักษณะการดำเนินงานหรือเคลื่อนไหวขององค์กรกับพฤติกรรมการทำงานของบุคคลภายในองค์กรเข้ามารวมกันไว้ในจุดที่เกิดประโยชน์สูงที่สุด”

สถาปัตยกรรมสำหรับเอ็นเตอร์ไพรส์ในบริษัทที่ให้บริการด้านการเงินรายใหญ่ ๆ แสดงให้เห็นว่าการขาดการสื่อสารระหว่างกันนั้นจะส่งผลต่อการบริหาร “ถ้าหากคุณทดลองกำนนดให้การรายงานอย่างเป็นทางการในเรื่องของโปรเจ็ก SOA และจัดให้เป็นส่วนหนึ่งของกระบวนการทำงานทั้งหมด คงไม่มีเหตุผลต้องสงสัยว่าจะมีนักพัฒนาคนไหนที่อยากทำตัวเด่นแล้วไม่ทำตามรูปแบบที่ตกลงกัน ทุกอย่างที่จำเป็นถูกกำหนดเอาไว้ในเอกสารทั้งหมด การเขียนข้อควรระวัง, กำหนดข้อยกเว้น หรืออื่น ๆ ทุกอย่างชัดเจนทั้งหมด ดังนั้นคุณจึงไม่จำเป็นต้องวางแผนทำอะไรที่เป็นเหมือนรหัสลับน่าปวดหัวออกมาให้วุ่นวายอีกต่อไป”

หลายองค์กรสร้างศูนย์อื่นๆ หรือศูนย์กลางข้อมูลขึ้นในกลุ่มการสร้างและออกแบบซอฟต์แวร์สำหรับกิจการ เพื่อจะเป็นผู้ให้คำแนะนำและให้ทรัพยากร เป็นคลังเก็บข้อมูลวิธีปฏิบัติที่ดีที่สุด และใช้บริหารเครื่องมือที่ใช้สนับสนุนกระบวนการบริหารจัดการ (Governance) แนวคิดเกี่ยวกับการสร้างและออกแบบซอฟต์แวร์ (SOA)

ที่ Aeroplan ซึ่งเป็นผู้วางแผนเกี่ยวกับความซื่อสัตย์จงรักภักดีของผู้บริโภคชาวแคนาดานั้น มิสเตอร์อังเดร เฮอร์เบิร์ต ได้พยายามสร้างให้การบริหารจัดการ (Governance) แนวคิดเกี่ยวกับการสร้างและออกแบบซอฟต์แวร์ (SOA) เข้าเป็นหนึ่งในการปฏิบัติงานของเขา “เรามีแผนผังการสร้างและออกแบบซอฟต์แวร์นี้เป็นส่วนหนึ่งของความรู้สึกนึกคิดของเรา หากคุณชอบ เวลาใดก็ตามที่มีโครงการใดถูกคิดขึ้นมาและต้องการองค์ประกอบทั้งภายในและภายนอกใหม่นั้นจะต้องผ่านคณะกรรมการการสร้างและออกแบบซอฟต์แวร์เสมอ” มิสเตอร์เฮอร์เบิร์ตซึ่งเป็นผู้อำนวยการฝ่ายเทคโนโลยีและอีบิซสิเนสของ Aeroplan อธิบาย “ดังนั้น สิ่งนี้จึงเป็นตัวกรองชนิดหนึ่งในแต่ละวันภายในองค์กรของเรา”

กล่าวง่ายๆ คือกระบวนการบริหารจัดการ (Governance) นั้นควรทำให้ง่ายเข้าไว้เพื่อความถูกต้อง และยากที่จะทำผิดพลาด “สร้างโรงเรียน ไม่ใช่สร้างคุก” มิสเตอร์มาร์ค อีริคสัน หัวหน้าด้านเทคโนโลยีของ Mindreef กล่าว “เป้าหมายก็เพื่อช่วยให้บุคลากรเห็นพ้องกับวิธีปฏิบัติที่ดีที่สุด ไม่ใช่ไปกำกับควบคุมพวกเขา”

นโยบายที่ 1

นโยบายสามารถมีผลกระทบต่อทุกมุมมองด้านระยะเวลาของโปรแกรม รวมถึงการออกแบบ การนำไปใช้งาน และการปฏิบัติการ ตัวอย่างเช่น นโยบายในขณะออกแบบอาจเป็นการเริ่มการสะสมของชื่อเพื่อวัตถุประสงค์เฉพาะต่างๆ ที่เกี่ยวกับบริษัท (Corporate namespace) ส่วนนโยบายการนำไปใช้งานอาจต้องการให้โปรแกรมของระดับผลิตภัณฑ์ตรงตามความต้องการที่กำหนดไว้โดยองค์กร WS-I(Web Service Interoperability) นโยบายการปฏิบัติการอาจต้องการให้โปรแกรมทั้งหมดที่นำมาใช้ประโยชน์ได้รับการจัดการและใช้ระบบพื้นฐานความปลอดภัยของบริษัท

แต่ในองค์กรส่วนใหญ่ถือว่าเป็นเหตุเป็นผลที่จะเริ่มต้นพยายามกำหนดนโยบายให้เป็นมาตรฐาน เพราะหลังจากนั้นมาตรฐานต่างๆ จะทำให้การสร้าง SOA มีความเป็นไปได้ กิจการแต่ละแห่งจะต้องกำหนดว่าจะใช้มาตรฐานใดที่ไหนและเวลาใด ตัวอย่างเช่น ความปลอดภัยของบริการบนเว็บ (WS-Security) และนโยบายบริการบนเว็บ (WS-Policy) จะนำมาใช้หรือไม่ และภายใต้สถานการณ์เช่นไรที่จะต้องนำมาใช้

คุณสามารถทำให้เห็นมาตรฐานเฉพาะบางประการในนโยบายส่วนบุคคล แต่กลยุทธ์ที่ดีกว่าคือการสร้างกรอบของการปฏิบัติงานร่วมกัน (IF:Interoperability Framework) กรอบของการปฏิบัติงานร่วมกันนี้เป็นนโยบายพิเศษที่จะแจงรายการมาตรฐานต่างๆที่องค์กรของคุณจะนำมาใช้ และบ่งชี้ข้อมูลอ้างอิงและสถานภาพของตัวเลือกที่ผ่านการเห็นชอบแล้ว เป็นความจริงในทางปฏิบัติ กำลังจะเกิดขึ้น ยังรักษาไว้ให้คงอยู่ ล่วง/ตกลงไปแล้ว หรือยังอยู่ในกระบวนการ

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

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

สิ่งที่มีคุณค่าของการบริหารจัดการที่ยังคงเป็นข้อโต้เถียง

กระบวนการบริหารจัดการ (Governance) จะสร้างนโยบายต่างๆ แผนการเกี่ยวกับ XML เอกสารเกี่ยวกับWSDL การจัดเตรียมเอกสารต่างๆ และประดิษฐ์กรรมอื่นๆ และสิ่งเหล่านี้จะถูกแจกจ่ายให้กับผู้สนใจ

การสื่อสารที่มีประสิทธิภาพมีความหมายมากกว่าแค่การส่งอีเมล์สิ่งที่มีค่าเหล่านี้หรือแค่การนำขึ้นบนเว็บไซต์ ดังนั้นเพื่อให้เกิดประโยชน์สูงสุด ประดิษฐ์กรรมทางความคิดที่เกี่ยวกับการบริหารจัดการนั้นจะต้องสามารถค้นหาได้เป็นเรื่องเป็นชุด และนำมาใช้อ้างอิงได้อย่างง่ายๆ และถูกต้องแม่นยำ ยิ่งกว่านั้นประดิษฐกรรมทางความคิดเหล่านี้ควรจะอยู่ในรูปแบบที่สามารถใช้งานได้กับเครื่องยนต์กลไก เพื่อสามารถค้นพบและรวบรวมได้อย่างแคล่วคล่อง

การลงทะเบียนเป็นเครื่องมืออันดับแรกๆ ที่องค์กรใช้สำหรับการจัดการ และการสื่อสารที่เกี่ยวกับประดิษฐ์กรรมทางความคิดด้านการบริหารจัดการ เช่นเดียวกันกับการทำให้กิจกรรมทางการบริหารจัดการที่สำคัญเป็นไปโดยใช้กลไกควบคุม การลงทะเบียนจะทำให้มีการอ้างอิงได้จากศูนย์กลาง หรือ”ระบบสถิติข้อมูล” สำหรับโปรแกรมต่างๆ คิดถึงสิ่งนี้ในที่ที่ผู้ให้สามารถโฆษณาบริการต่างๆ ได้ และลูกค้าภายในองค์กรก็จะค้นพบโฆษณานั้นๆ จุดควบคุมสำหรับการใช้ประโยชน์จากโปรแกรมการบริหารจัดการที่มีอยู่ การออกเป็นเรื่องราวเป็นชุดๆ และความสอดคล้องกับความต้องการทั้งภายในและภายนอก

ผู้ค้าบางรายเสนอสิ่งที่พวกเขาเรียกว่า “คลัง (Repositories)” การลงทะเบียนที่ใช้เป็นที่เก็บข้อมูลที่มีการเปลี่ยนแปลงได้สำหรับบริการต่างๆ ที่ยิ่งกว่าเอกสารที่เกี่ยวกับ WSDL เพราะว่าการลงทะเบียนและคลังข้อมูลนั้นมีความสำคัญต่อกระบวนการพัฒนา ลองดูซอฟต์แวร์ที่สามารถผสมผสานได้อย่างดียิ่งกับสภาพแวดล้อมในการพัฒนาของคุณ ตัวอย่างเช่น ถ้าคุณคือ Eclipse Shop ก็ต้องมั่นใจว่าคุณเลือกการลงทะเบียนที่มี plug-in สำหรับ Eclipse

การลงทะเบียนยังมี APIs ซึ่งถูกใช้โดยแอพพลิเคชันในเวลาทำงานเพื่อค้นหาโปรแกรมและนโยบายที่เกี่ยวข้องได้อย่างแคล่วคล่อง ตัวอย่างเช่น ข้อมูลที่เปลี่ยนแปลงอื่นๆ อาจบอกแก่ผู้บริโภคโปรแกรมว่านโยบายความปลอดภัยใดที่โปรแกรมต้องการเพื่อที่ว่าลูกค้าสามารถปรับให้เข้ากับข้อเสนอโปรแกรมความเปลี่ยนแปลงได้อย่างคล่องแคล่วมีพลัง

นโยบายการแสดงระยะเวลานั้นมีประสิทธิภาพที่สุดก็ต่อเมื่อมันสามารถแสดงให้เห็นได้ด้วยระบบ WSM (Web services management) อาทิ ระบบของ Actional AmberPoint, Blue Titan, หรือซอฟต์แวร์ SOA ระบบ WSM ส่วนมากจะสื่อถึงสภาพของการถูกบังคับให้กระทำบนซอง SOAP ภายในระยะเวลาที่กำหนด ตัวอย่างเช่น WSM สามารถทำให้มั่นใจได้ว่าบริการต่างๆ ใช้ตัวแบบความปลอดภัยเป็นการเฉพาะ หรือ เอกสาร XML ที่แนบมานั้นสอดคล้องกับแผนการเฉพาะ

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

โดยทั่วไปกิจการต่างๆ ควรใช้เครื่องยนต์กลไกในกระบวนการบริหารจัดการให้มากที่สุดเท่าที่จะเป็นไปได้ และนั่นก็ต้องการการลงทุนโดยภาพรวมเกี่ยวกับเรื่องบุคลากร องค์กร และเครื่องมือสำหรับสร้างเนื้อหาสาระที่เหมาะสมสำหรับแนวคิดเกี่ยวกับ SOA ด้วยการดำเนินการอย่างเหมาะสม กระบวนการการบริหารจัดการของคุณและโครงสร้างพื้นฐานที่เกี่ยวข้องอื่นๆ อาจเป็นส่วนสำคัญโดยภาพรวมๆ เพียงประการเดียวในการใช้ประโยชน์จากแนวคิดเกี่ยวกับSOA

วางกฏในการทำงาน

การสร้างโค้ดต่างๆ จะไม่มีประสิทธิภาพมากนักหากไม่มีการวางผังการออกแบบเตรียมเอาไว้ให้ลงตัวเสียก่อน หรืออาจจะทำออกมาแล้วไม่ได้ผลเลยหากไม่มีการตรวจสอบ ในทำนองเดียวกันนโยบายแนวคิดเกี่ยวกับ SOA จะไม่มีค่าเลยถ้าไม่ถูกนำไปใช้ปฏิบัติ

นโยบายบางอย่างจะถูกนำไปทำให้เป็นระบบด้วย WSM หรือระบบการพัฒนา และสามารถถูกนำไปปฏิบัติได้โดยอัตโนมัติ บางนโยบายอาจมีเป้าหมายที่การเปลี่ยนแปลงหรือควบคุมพฤติกรรมของคน อาทิ คำสั่งที่บริการต่างๆ นำไปใช้กับโปรแกรมคุณภาพผลิตภัณฑ์นั้นจะต้องถูกบันทึกลงในทะเบียนผลิตภัณฑ์และถูกนำมาจัดระบบได้ไม่ง่ายเลย เพียงแค่นำคำสั่งใดคำสั่งหนึ่งไปปฏิบัติดีกว่า

การจัดการโครงการของกิจการมักเป็น One-stop shop สำหรับการบังคับใช้นโยบาย ผู้จัดการโครงการสามารถนำโครงการไปสู่การยินยอมปฏิบัติตามโดยปราศจากการบังคับเข้มงวด เทคนิควิธีอื่นๆ รวมถึงการทบทวนโครงการโดยร่างการบริหารจัดการแนวคิดเกี่ยวกับ SOA ก่อนที่จะนำกองทุนออกมา

สิ่งสำคัญเหนืออื่นใดคือพึงระลึกไว้ว่าเป้าหมายนโยบายแนวคิดเกี่ยวกับ SOA จะต้องเป็นไปในแนวทางเดียวกับสิ่งกระตุ้นทางด้านการเงิน ถ้าไม่เช่นนั้นแล้วความเป็นไปได้ของโปรแกรมจะดำเนินไปแบบไม่ได้รับการใส่ใจเท่าที่ควร “ในความเป็นจริงองค์กรที่พัฒนาจะดำเนินไปสวนทางกับงบประมาณและกำหนดระยะเวลาและความเป็นไปได้ของโปรแกรมที่ถูกละทิ้งไว้ โดยปราศจากกระบวนการบริหารจัดการที่เข้มแข็ง แนวคิดเกี่ยวกับ SOA จะมีการใช้ประโยชน์ไม่สม่ำเสมอทั่วทั้งองค์กร” บ็อบ ลาร์ด หัวหน้าสถาปนิกที่ MCIกล่าว “ถ้าบางส่วนขององค์กรไม่สามารถนำแนวคิดเกี่ยวกับ SOA มาใช้ได้แล้วละก็ คุณจะเสียเปรียบอย่างแน่นอน”

การบังคับใช้ต้องการการปิดช่องว่างที่มี เมื่อโปรแกรมหรือกระบวนการใดมีความไม่พร้อมจะยินยอมทำตามได้ คุณต้องดำเนินการแก้ไขในทางตรงกันข้าม การไม่ยินยอมทำตามอาจบ่งชี้ว่านโยบายนั้นอาจมีข้อจำกัดมากเกินไปหรือเขียนไว้แย่มากๆ เพื่อความมั่นใจว่ากระบวนการตอบสนองมีแนวทางที่นำไปสู่การปรับปรุงนโยบาย

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

การร่างสัญญา (Crafting Contracts)

นโยบายต่างๆ ต้องขยายออกไปจากการบริหารจัดการที่เป็นพื้นฐานอย่างกว้างๆ ไปสู่กฎข้อบังคับเฉพาะโปรแกรมที่รวมไว้ในสัญญาบางอย่าง มันอาจจะดูแปลกที่จะคิดถึงว่าส่วนใดส่วนหนึ่งขององค์กรสร้างพันธสัญญากับอีกส่วนหนึ่ง แต่นั่นก็เป็นสิ่งที่ทำให้โปรแกรมมีความแตกต่างจากการแค่ส่งต่อรหัส

“สัญญาต่างๆ จะนำวงจรชีวิตทั้งของผู้บริโภคและผู้ผลิตมารวมเข้าด้วยกัน” สตาเน็คจากซิสติเน็ตอธิบาย “สัญญาเป็นจุดที่ใช้อ้างอิงในการอธิบายความต้องการของทั้งสองฝ่าย” สัญญาไม่ใช่ข้อตกลงระดับการบริการ (Service-level agreement) แบบทางเดียว แต่สัญญาอาจกำหนดพฤติกรรมของผู้บริโภคที่สามารถยอมรับได้ก็เพื่อว่าผู้ประกอบการด้านโปรแกรมสามารถวางแผนการบริโภค แนวทางก็คือให้ผู้ผลิตเฝ้าติดตามและคาดคะเนความต้องการของผู้บริโภค

สัญญาจะระบุกลุ่มของนโยบายที่ทั้งสองฝ่ายเห็นชอบปฏิบัติตามร่วมกัน ไม่มีมาตรฐานใดๆ สำหรับการเป็นตัวแทนด้านสัญญา แต่โดยมากก็สามารถประสบความสำเร็จได้ด้วยระดับโปรแกรมที่กำหนดไว้ก่อนล่วงหน้า และทำต้นแบบจากแผนผังความคิดรวบยอดที่เป็นนโยบาย สัญญาในสาระนี้มีความเป็นเอกสารตามกฎหมายน้อยยิ่งกว่าข้อตกลงที่สนับสนุนปฏิสัมพันธ์ระหว่างผู้ผลิตและผู้บริโภค และข้อตกลงที่ควบคุมการดำเนินทางธุรกิจที่เกิดขึ้นตามเนื้อหาสาระนั้นๆ

การเริ่มต้นในแนวทางที่ถูกต้อง

การบริหารจัดการนั้นง่ายที่จะถูกละเลยในตอนต้น ซึ่งก็ไม่เป็นไรสำหรับในระยะทดลองของการใช้แนวคิดเกี่ยวกับ SOA แต่จากนั้นควรเปลี่ยนอย่างรวดเร็วเมื่อบริการเข้าใกล้ระยะผลิตภัณฑ์ ตามที่เบอร์ตันได้บ่งชี้ไว้ว่า “องค์กรต่างๆ มากมายมิได้เริ่มคิดเกี่ยวกับการบริหารจัดการจนกระทั่งไม่สามารถควบคุมสิ่งใดได้อีกแล้ว

การบริหารจัดการแนวคิดเกี่ยวกับ SOA เริ่มต้นที่การมองว่ากระบวนการบริหารจัดการอะไรที่จะประสบความสำเร็จ การมองเช่นนั้นเป็นการรวบรวมความพยายามของบุคลากรที่จะออกแบบ สร้าง และใช้ประโยชน์บริการต่างๆ ไม่ใช่แค่นักพัฒนาเท่านั้น แต่ผู้จัดการด้านสารสนเทศและผู้นำหน่วยธุรกิจด้วยวิสัยทัศน์ที่มุ่งมั่นอยู่บนพื้นฐานของความคิดเห็นของคนส่วนใหญ่ที่มาจากการมีส่วนร่วมอย่างกว้างขวาง

เอ็ดฮอร์ส ผู้อำนวยการฝ่ายกลยุทธ์ผลิตภัณฑ์ของ AmberPoint ได้แนะนำให้สร้างระบบพื้นฐานการบริหารจัดการแต่เนิ่นๆ “พยายามใช้การจัดการ การลงทะเบียน และความปลอดภัยที่ละน้อยตั้งแต่แรกเริ่ม” นิสัยที่ไม่ดีจะเกิดขึ้นในเรื่องเหล่านี้ซึ่งจะทำให้ความพยายามที่จะใช้บริการจัดการโดยใช้แนวคิดเกี่ยวกับ SOA นั้นยุ่งยากซับซ้อนมากขึ้น หากไม่มีระบบการจัดการ นักพัฒนาจะพัฒนาซอฟต์แวร์ที่ฝังเหตุผลของการจัดการลงซอร์สโค้ดของโปรแกรมโดยตรง (hardcode) และก็ต้องเสียเวลามาเขียน พวกเขาจะไม่มีความคิดว่าจะได้ข้อมูลการจัดการมาอย่างไรในเมื่อพวกเขาใช้ระบบการจัดการจริงๆ อยู่” เขากล่าว

เพราะแนวคิดเกี่ยวกับ SOA เป็นการกระจายอำนาจโดยปกติวิสัย การบริหารจัดการ (Governance) คือความแตกต่างระหว่างความสำเร็จกับความสับสนวุ่นวาย ตามที่เมนได้กล่าวไว้ “การทำโครงการ Web service เล็กๆ จำนวนมากโดยมิได้บริหารจัดการนั้น ยังไงก็ไม่ใช่ SOA แต่เป็นแค่ของเล่นเท่านั้น”

ข้อปฏิบัติสำคัญในสำหรับการบริหารจัดการ SOA ที่ดี

การบริหารงานการจัดการแบบ SOA เป็นการอยู่ร่วมกันในสังคมแบบธรรมชาติ เป็นการเปิดโอกาสให้มีการพุดคุยกันอย่างต่อเนื่องระหว่าวผู้พัฒนาและผู้ออกแบบ

การตั้งคณะกรรมการเพื่อพิจารณา: นโยบายในการบริหารงานการจัดการ ควรมีการพัฒนา รักษาให้คงอยู่ไว้ และปรับปรุงเปลี่ยนแปลง โดยมีคณะกรรมการเป็นผู้ดำเนินการมากกว่าทำโดยการสั่งการ คนที่รู้ว่าอะไรกำลังเกิดขึ้นในเบื้องล่างต้องได้รับรู้ในสิ่งที่เป็นจริง

การพัฒนากรอบของความสามารถในการทำงานระหว่างกันเป็นลำดับแรก: ความเป็นมาตรฐานเป็นหลักสำคัญของการบริหารงานการจัดการแบบ SOA เริ่มต้นด้วยการสร้างกรอบของความสามารถในการทำงานระหว่างกันให้กว้างขวาง โดยรายละเอียดของโพรโคอลเป็นไปตามองค์กรของคุณ

อย่าให้ความสำคัญในเรื่องรายละเอียด: รายละเอียดของนโยบายที่มากเกินไปเป็นการยากที่จะรักษาไว้และเป็นข้อจำกัดในการคิดสิ่งใหม่ ๆ สำหรับการประยุกต์ใช้เพื่อให้องค์กรมีความเสี่ยงต่ำ ควรมีการจัดห้องที่มีความยืดหยุ่นมีความคล่องตัวต่อการใช้งานไว้มาก ๆ

ติดต่อสื่อสารกันบ่อยครั้ง: นโยบายเป็นสิ่งที่ต้องการการอธิบายมากกว่าหนึ่งครั้ง และผู้จัดการต้องการความแน่ใจในสิ่งที่เป็นปัจจุบันได้รับการเผยแพร่อย่างถูกต้อง

การแต่งตั้งกรรมการผู้จัดการใหญ่ (CEO)(เป็นศูนย์รวมของความเก่งความสามารถ): ในองค์กรขนาดใหญ่ กรรมการผู้จัดการ จะต้องมีพนักงานที่ทำงานเต็มเวลาอย่างเต็มที่เพื่อสนับสนุนการบริหารงานการจัดการแบบ SOA กรรมการผู้จัดการที่ทำงานอย่างมีประสิทธิผลจะช่วยชี้นำและศึกษาการบริหารงานการจัดการที่ได้พยายามทำไปด้วยกัน

สร้างนโยบายด้วยความพร้อมเพียงกัน: การปราศจากการบังคับทำให้นโยบายมีความหมายน้อยมาก สร้างนโยบายลงในเซอร์วิสในจุดที่เป็นไปได้นอกจากนั้นตรวจสอบให้แน่ใจว่าผู้พัฒนาเข้าใจและระวังไม่ฝ่าฝืนกฏต่างๆ อีกด้วย

SOA กับ Web Services เหมือนหรือแตกต่างกันอย่างไร

Service Oriented Architecture SOA กับ Web Services เหมือนหรือแตกต่างกันอย่างไร

SOA เป็นรูปแบบของการพัฒนาซอฟต์แวร์ที่เน้นให้ซอฟต์แวร์สามารถให้บริการได้โดยไม่ มีเงื่อนไขหรือข้อกำหนดของแพลตฟอร์มที่ใช้ของผู้ร้องขอบริการ ส่วน Web service เป็นซอฟต์แวร์ที่ให้บริการผ่านทางอินเทอร์เน็ตซึ่งข้อมูลระหว่างผู้ให้บริการและผู้ขอบริการอยู่ในรูปแบบของภาษาเอกซ์เอ็มแอล ฉะนั้นจริง ๆ แล้ว Web service คือซอฟต์แวร์ที่สามารถพัฒนาในอยู่ในรูปแบบของ SOA การที่ผู้ให้บริการ Web service และ ผู้ร้องขอ Web service สื่อสารกันด้วยภาษาเอกซ์เอ็มแอลซึ่งเป็นภาษามาตรฐานที่ใช้ในการนำเสนอและแลกเปลี่ยนข้อมูลผ่านทางอินเทอร์เน็ต จึงทำให้การเรียกใช้ Web service ไม่ขึ้นอยู่กับแพลตฟอร์มของผู้เรียกใช้ โดยสรุปแล้ว SOA เป็นสไตล์หรือเป็นรูปแบบ ส่วน Web service Technology เป็นวิธีการพัฒนา ความสัมพันธ์ระหว่าง SOA และ Web Services ก็คือ Web service เป็นซอฟต์แวร์ที่ทำให้ SOA เกิดขึ้นจริงและใช้ได้จริง

คุณเคยได้ยินเรื่องเล่าเกี่ยวกับ SOA บ้างหรือเปล่า?

คุณเคยได้ยินเรื่องเล่าเกี่ยวกับ Service Oriented Architecture SOA บ้างหรือเปล่า?

จากคำถามที่ว่า Service Oriented Architecture หรือ SOA นั้นเป็นกลยุทธ์ทางด้านธุรกิจ ชุดเว็บเซอร์วิส หรือว่าเป็นผีในตำนานที่ชอบซ่อนอยู่ใต้เตียงของพนักงานฝ่ายไอทีในตอนกลางคืนกันแน่?

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

ต่อไปนี้คือ เรื่องเล่า 5 เรื่องเกี่ยวกับ SOA ที่มีการพูดถึงกันมาก ซึ่งเราจะชี้ให้เห็นถึงข้อเท็จจริงที่เกี่ยวข้องในแต่ละประเด็น:

1. ราคาสูง

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

2. บุคคลลึกลับ

SOA ถูกตรวจพบขณะกำลังซ่อนตัวอยู่ที่เบาะด้านหลังรถของผู้จัดการฝ่ายไอที เมื่อผู้จัดการฝ่าย

ไอทีเดินเข้าไปใกล้รถ เขาพบว่ามีอะไรบางอย่างซ่อนอยู่ที่เบาะหลัง และเขาก็เห็นว่า SOA กำลังเตรียมที่จะปล่อยชุดเว็บเซอร์วิสต่างๆ ซึ่งทั้งหมดล้วนได้รับการออกแบบเพื่อรองรับกระบวนการธุรกิจอัตโนมัติที่เหมือนกันเป๊ะ ผู้จัดการฝ่ายไอทีจึงรีบโทรแจ้งตำรวจท้องที่ และพวกเขาก็ช่วยกันปลดอาวุธ SOA และกำจัดกระบวนการธุรกิจที่ซ้ำซ้อน

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

3. SOA เป็นความรับผิดชอบของพนักงานฝ่ายไอที

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

4. ลูกกวาดป๊อปร็อค น้ำอัดลม และซอฟต์แวร์โอเพ่นซอร์ส

การผนวกรวมแอพพลิเคชันแบบปิด (Proprietary) เข้ากับซอฟต์แวร์โอเพ่นซอร์ส (open source) บนสถาปัตยกรรม SOA ของคุณ นับว่าเป็นส่วนผสมที่มีอานุภาพทำลายล้างเทียบเท่ากับการใส่ลูดกวาด

ป๊อปร็อคลงไปในน้ำอัดลมเลยทีเดียว เนื่องจากสภาพแวดล้อมที่ประกอบด้วยผลิตภัณฑ์จากผู้ผลิตหลายราย (Heterogeneous) เป็นสิ่งที่พบเห็นได้ทั่วไปในโลกปัจจุบัน ดังนั้นความต้องการ SOA จึงมีแนวโน้มเพิ่มสูงขึ้น โปรดจำไว้ว่า SOA ได้รับการออกแบบเป็นพิเศษ เพื่อเพิ่มความสะดวกในการผนวกรวมผู้ใช้ กระบวนการ และข้อมูลต่างๆ เข้าด้วยกัน โดยไม่คำนึงถึงตำแหน่งที่ตั้งหรือแหล่งที่มา

5. คุณยังคงได้เกรด A อยู่ดี แม้ว่าคุณจะสอบตกก็ตาม

ถ้าหากโครงการ SOA ของคุณเกิดล้มเหลวระหว่างทางก่อนที่จะไปถึงจุดหมาย คุณก็จะได้เกรด 4.0 โดยอัตโนมัติ แม้ว่าคุณประโยชน์และผลตอบแทนจากการลงทุน (ROI) สำหรับ SOA จะสามารถตรวจวัดได้ในรูปแบบของประสิทธิภาพการทำงานและการประหยัดค่าใช้จ่าย แต่ก็ยังคงมีหลายๆ กรณีที่เกิดความล้มเหลวในช่วงแรกของการดำเนินการ กระนั้น คุณก็ไม่ควรปล่อยให้ความเชื่อที่ผิดๆ เป็นอุปสรรคขัดขวางไม่ให้คุณก้าวเดินต่อไปตามเส้นทาง SOA ทั้งนี้ หนึ่งในเหตุผลหลักที่โครงการ SOA ล้มเหลวในช่วงเริ่มแรกเป็นเพราะขาดการวางแผนเชิงกลยุทธ์และการสร้างแบบจำลองสำหรับระบบงานธุรกิจ ในขณะที่องค์กรธุรกิจทุกขนาดยังคงปรับใช้กลยุทธ์ SOA อย่างต่อเนื่อง ก็จะมีหลักฐานเพิ่มมากขึ้น ทั้งในรูปแบบของเรื่องเล่าและตัวเลขที่เป็นรูปธรรม ซึ่งจะช่วยหักล้างความเชื่อที่ผิดๆ เหล่านี้ ซึ่งได้รับการบอกเล่าปากต่อปาก

กรอบงานของธุรกิจที่ใช้ หลัก SOA เพื่อรองรับความไม่แน่นอน

กรอบงานของธุรกิจที่ใช้ หลัก Service Oriented Architecture SOA เพื่อรองรับความไม่แน่นอน

SOA กับ Web Services เหมือนหรือแตกต่างกันอย่างไร
SOA เป็นรูปแบบของการพัฒนาซอฟต์แวร์ที่เน้นให้ซอฟต์แวร์สามารถให้บริการได้โดยไม่ มีเงื่อนไขหรือข้อกำหนดของแพลตฟอร์มที่ใช้ของผู้ร้องขอบริการ ส่วน Web service เป็นซอฟต์แวร์ที่ให้บริการผ่านทางอินเทอร์เน็ตซึ่งข้อมูลระหว่างผู้ให้บริการและผู้ขอบริการอยู่ในรูปแบบของภาษาเอกซ์เอ็มแอล ฉะนั้นจริง ๆ แล้ว Web

service คือซอฟต์แวร์ที่สามารถพัฒนาในอยู่ในรูปแบบของ SOA การที่ผู้ให้บริการ Web service และ ผู้ร้องขอ Web service สื่อสารกันด้วยภาษาเอกซ์เอ็มแอลซึ่งเป็นภาษามาตรฐานที่ใช้ในการนำเสนอและแลกเปลี่ยนข้อมูลผ่านทางอินเทอร์เน็ต จึงทำให้การเรียกใช้ Web service ไม่ขึ้นอยู่กับแพลตฟอร์มของผู้เรียกใช้ โดยสรุปแล้ว SOA เป็นสไตล์หรือเป็นรูปแบบ ส่วน Web service Technology เป็นวิธีการพัฒนา ความสัมพันธ์ระหว่าง SOA และ Web Services ก็คือ Web service เป็นซอฟต์แวร์ที่ทำให้ SOA เกิดขึ้นจริงและใช้ได้จริง

กรอบงานของธุรกิจที่ใช้ หลัก SOA เพื่อรองรับความไม่แน่นอน
เมื่อไม่นานมานี้ โมเดลของการบริการธุรกิจแบบ service oriented ได้ถูกคิดค้นขึ้นในฟังก์ชันของกิจกรรมที่ถูกกำหนดด้วยตัวบริการของธุรกิจและไอที ภายใต้โมเดลนี้ กิจกรรมจะถูกนำมานิยามใหม่ในส่วนของการดำเนินธุรกิจและกิจกรรมไอที โดยใช้ส่วนประกอบพื้นฐานของฟังก์ชันธุรกิจและไอทีมาแยกเป็นส่วน ๆ แล้วทำเป็นเซ็ตมาตรฐานของธุรกิจหรือบริการทางไอที ที่มีการกำหนดบริการพื้นฐานที่นำเสนอขึ้นมาและจัดทำหน้าจออินเตอร์เฟตที่มีความยืดหยุ่นต่อการนำมาประกอบใหม่ เพื่อให้เข้าใจนิยามของคำว่า โมเดล service oriented business จึงของสรุปคำว่า Service Oriented Enterprise อย่างกว้าง ๆ ว่าคือ การใช้งานของระบบและการทำงานร่วมกันทางไอทีจากระบบและงานไอทีที่เหมาะสม SOE เป็นโมเดลสำหรับสถาปัตยกรรมทางซอฟต์แวร์และโครงสร้างพื้นฐานทางด้านไอที โดยทำงานร่วมกับรูปแบบของสถาปัตยกรรมในปัจจุบัน ทำให้สามารถกลายเป็นตัวขับเคลื่อนกระบวนการสถาปัตยกรรมที่น่าเชื่อถือ ที่สามารถครอบคลุมส่วนประกอบของฟังก์ชันการทำงานของธุรกิจในงานบริการที่สามารถนำมาใช้ซ้ำในฟังก์ชันของธุรกิจที่หลากหลายได้
หัวใจหลักของการทำงาน SOE จะใช้บริการเครือข่ายในการทำให้บรรลุผลตามวัตถุประสงค์ที่ตั้งไว้ การบริการผ่านเครือข่ายจะเป็นตัวแนะนำแนวคิดของหน้าจอแบบทั่วไปที่สามารถติดต่อภายใต้กลไกพื้นฐานเดียวกันเพื่อที่ใช้หน้าจอหรือหน้าจอระหว่างผู้ร่วมค้าเดียวกันได้ หน้าจออินเตอร์เฟสที่สามารถใช้งานได้ทั่วไปจะช่วยลดการรวมกลุ่มของเครือข่ายและการสร้างเครือข่ายเฉพาะกลุ่ม

SOE นำหลักการ interoperability (แนวทางที่จะทำให้ข้อมูลในระบบหรือคอมโพเนนท์ต่าง ๆ สามารถพูดคุยกันได้ โดยระบบไม่จำเป็นต้องมาจากที่เดียวกัน แต่ต้องสามารถคุยกันได้ ติดต่อสื่อสารกันได้ แลกเปลี่ยนข้อมูลกันได้) และความไวต่อการเปลี่ยนแปลงมาเป็นองค์ประกอบของการออกแบบธุรกิจและระบบไอที หัวข้อหลักสำหรับ SOE เป็นการสมมติให้ระบบธุรกิจและไอทีที่สามารถรวมความต้องการเบื้องต้นไว้ด้วยกัน มากกว่าที่จะทำการเพิ่มขึ้นมาเหมือนในอดีต

คำนิยามความไม่แน่นอนและสาเหตุ
การบริการแบบไม่แน่นอนหมายถึง ธรรมชาติของการไม่สามารถทำนายผลของการให้บริการได้ แม้ว่าทั้งบริการของโพรไวด์เดอร์และบริการของผู้บริโภคจะชี้เฉพาะเจาะจงก็ตาม แต่ความแน่นอนก็ยังส่งผลให้การบริการต่าง ๆ ยากที่จะทำนายล่วงหน้า
สาเหตุของความไม่แน่นอนมาจากต้นกำเนิดของความหลากหลาย สาเหตุบางส่วนสามารถควบคุมได้และบางส่วนก็ควบคุมได้เพียงเล็กน้อย สำหรับตัวอย่าง เช่น คุณภาพที่ต่ำของการบริการอาจจะทำให้คาดเดาการบริการการขนส่งได้เพียงเล็กน้อย
ปัจจัยที่ควรคำนึงถึงสำหรับการบริการที่รองรับความไม่แน่นอน
คีย์หลักที่เกี่ยวข้องกับความไม่แน่นอนของบริการที่ควรจะใช้อ้างอิงในการทำคำสั่งในกิจการ เพื่อให้ได้รับผลประโยชน์ที่แท้จริงจากการรวมบริการธุรกิจของ service oriented ควรคำนึงถึงสิ่งต่าง ๆ

การพัฒนาข้อตกลงการบริการ(Service Agreement Development) : เพื่อทำให้การบริการอยู่ในระดับที่น่ามั่นใจของคุณภาพและผลลัพธ์ของการบริการ กิจการต่าง ๆ จะต้องมีการทำงานในส่วนของการออกข้อรายละเอียดของข้อตกลงของการบริการกับบริการของโพรไวเดอร์สำหรับเทอมและสภาวะของระดับการบริการสัญญาและค่าธรรมเนียมที่เกี่ยวข้องกับบริการ
การออกแบบส่วนประกอบทั้งหมดของการบริการ (Service Composition Design) : ด้วยการเจาะจงข้อตกลงของการบริการ กิจการสามารถออกแบบว่าวิธีการบริการควรจะประกอบด้วยสิ่งใดเพื่อบรรลุจุดประสงค์ของธุรกิจของการบริการที่ประกอบขึ้นมา การออกแบบอาจจะกำหนดโดยเริ่มต้นเป็น Roadmap เป็นแผนการทำงานคร่าว ๆ ของการดำเนินการบริการที่มีอยู่ การเริ่มต้นการออกแบบจะต้องมีการวิเคราะห์และกำหนดด้วยการประเมินผลในทางบวกและข้อควรคำนึงถึงต่าง ๆ

การประเมินค่าส่วนประกอบต่าง ๆ ของการบริการ (Service Composition Evaluation) : ผลลัพธ์ของการบริการจะต้องถูกจับและวิเคราะห์ในแง่ของต้นทุนและกำไรทางด้านเศรษฐศาสตร์ การออกแบบส่วนประกอบของการบริการจะถูกประเมินค่าโดยยึดหลักของเศรษฐศาสตร์ในคุณค่าของการลดต้นทุน, ประสิทธิภาพที่พัฒนาขึ้น และคุณค่าทางกลยุทธ์ทั้งหมด แสดงเป็น functional กับ non functional
การจัดการการปฏิบัติงานของบริการ (Service Operation Management) : ในท้ายที่สุด ระหว่างที่มีการปฏิบัติงานจริง ลักษณะต่าง ๆ ของการบริการจะต้องถูกจัดการโดยกิจการ ข้อยกเว้นจะต้องถูกจัดการลงและคุณภาพของการบริการจะถูกควบคุมและจัดการ
การบริการแบบไม่แน่นอนในบริการต่าง ๆ

การพิจารณาที่ไม่คำนึงถึงความแน่นอน จะมีมุมมองเพียงมุมมองเดียวของการบริการต่างๆ ในการออกแบบที่รองรับความไม่แน่นอนจะต้องอาศัยกฎเกณฑ์เช่นการเลือกขอบข่ายการบริการจากคำอธิบายบริการ, หน้าจออินเตอร์เฟสที่เข้ากันได้และคุณภาพของลักษณะการบริการ ดังนั้น การบริการต่าง ๆในแต่ละส่วน จึงต้องมีการออกแบบที่ชัดเจนกำหนดไว้สำหรับนโยบายเดียวและทำให้ส่วนต่าง ๆ มีความสัมพันธ์ต่อกัน การรวมกันของการบริการแบบไม่แน่นอนของการรวมบริการข้ามบริษัท การออกแบบต้องพิจารณาถึงส่วนประกอบต่าง ๆ ทั้งหมด จะไม่พิจารณาเพียงผลลัพธ์เดียว แต่จะรวมคลุมถึงหลาย ๆ ผลลัพธ์จากการบริการที่มีส่วนประกอบอยู่ทั้งหมด

ผู้เขียนบทความวิจัยได้เสนอโมเดลในการแก้ปัญหา โดยพิจารณามาจากการค้นหานโยบายที่เหมาะสมที่สุดในบริการต่าง ๆ แล้วนำคีย์หลักจะมาแปลงเป็นโมเดล, การกระทำ และผลของการกระทำสำหรับการบริการภายใต้ความไม่แน่นอน แสดงเป็นแผนภาพโมเดล

สถาปัตยกรรมบริการเชิงรุก (Service Oriented Architecture: SOA)

สถาปัตยกรรมบริการเชิงรุก (Service Oriented Architecture: SOA)

ความหมายของ SOA
ความหมายของเซอร์วิส (Service) คือเป็นการรวมฟังก์ชันจากระบบสนับสนุน งานธุรกิจทั้งที่มีอยู่หรือที่สร้างใหม่ให้เป็นหน่วยเดียวตามมาตรฐานที่กำหนด และประกาศฟังก์ชันที่รวมขึ้นเป็นหนึ่งเดียวนั้นซึ่งจะทำให้ระบบอื่นสามารถค้นหาเซอร์วิส (Service Discovery) และเรียกใช้งาน (Service) ได้ง่ายขึ้น และ SOA (Service-Oriented Architecture) หมายถึงโมเดลของการพัฒนาซอฟต์แวร์ที่สร้างฟังก์ชันต่าง ๆ ให้เป็นบริการหรือ Service ซึ่งสามารถนำมาใช้ทำงานร่วมกันได้ผ่านอินเตอร์เฟส (Interface) ที่เป็นมาตรฐานที่นิยามอย่างชัดเจน และมีการกำหนดเงื่อนไขรายละเอียดของบริการ (Contract) ไว้

องค์ประกอบที่สำคัญของ SOA
องค์ประกอบต่อไปนี้เป็นองค์ประกอบที่จำเป็น เพื่อให้สามารถเรียกใช้บริการอื่นๆ ได้ ดังนี้
1. เซอร์วิส (Service) กลุ่มของอินเตอร์เฟสที่ระบุฟังก์ชันต่างๆ ที่สามารถให้ระบบอื่นสามารถเรียกใช้บริการได้
2. ผู้ให้บริการ (Service Provider) กลุ่มของคอมโพเนนต์ที่สามารถทำฟังก์ชันที่เป็นบริการตามที่กำหนดไว้เป็นเซอร์วิส (Service Specification)
3. ผู้รับบริการ (Service Consumer or Requestor) ระบบอื่นๆ ที่เรียกใช้เซอร์วิสซึ่งระบบอื่นๆ อาจจะเป็นเซอร์วิสที่เรียกใช้เซอร์วิสด้วยกันก็ได้
4. ผู้ให้บริการข้อมูลรายละเอียดของเซอร์วิสและค้นหาสถานที่ตั้งของผู้ให้บริการ (Service Locator) เป็นผู้ให้บริการประเภทหนึ่ง ซึ่งมีหน้าที่ลงทะเบียนรายละเอียดเกี่ยวกับผู้ให้บริการ (Service Registry) และคอยให้บริการข้อมูลรายละเอียดที่จำเป็นสำหรับการเรียกใช้บริการ
5. ตัวแทนติดต่อระหว่างผู้รับบริการและผู้ให้บริการ (Service Broker) ทำหน้าที่ช่วยติดต่อส่งคำร้องขอบริการจากผู้รับบริการไปยังกลุ่มของผู้ให้บริการ เพื่อเพิ่มความสะดวกในการติดต่อเรียกใช้บริการ

ขั้นตอนการทำงานร่วมกันระหว่างผู้รับบริการ ผู้ให้บริการ ตัวแทน และผู้ให้บริการข้อมูลรายละเอียดของเซอร์วิส เพื่อให้ผู้รับบริการสามารถเรียกใช้เซอร์วิสที่ต้องการได้ องค์ประกอบต่อไปนี้เป็นองค์ประกอบที่จำเป็น เพื่อให้สามารถเรียกใช้บริการอื่นๆ ได้ ดังนี้1. เซอร์วิส (Service) กลุ่มของอินเตอร์เฟสที่ระบุฟังก์ชันต่างๆ ที่สามารถให้ระบบอื่นสามารถเรียกใช้บริการได้2. ผู้ให้บริการ (Service Provider) กลุ่มของคอมโพเนนต์ที่สามารถทำฟังก์ชันที่เป็นบริการตามที่กำหนดไว้เป็นเซอร์วิส (Service Specification)3. ผู้รับบริการ (Service Consumer or Requestor) ระบบอื่นๆ ที่เรียกใช้เซอร์วิสซึ่งระบบอื่นๆ อาจจะเป็นเซอร์วิสที่เรียกใช้เซอร์วิสด้วยกันก็ได้4. ผู้ให้บริการข้อมูลรายละเอียดของเซอร์วิสและค้นหาสถานที่ตั้งของผู้ให้บริการ (Service Locator) เป็นผู้ให้บริการประเภทหนึ่ง ซึ่งมีหน้าที่ลงทะเบียนรายละเอียดเกี่ยวกับผู้ให้บริการ (Service Registry) และคอยให้บริการข้อมูลรายละเอียดที่จำเป็นสำหรับการเรียกใช้บริการ5. ตัวแทนติดต่อระหว่างผู้รับบริการและผู้ให้บริการ (Service Broker) ทำหน้าที่ช่วยติดต่อส่งคำร้องขอบริการจากผู้รับบริการไปยังกลุ่มของผู้ให้บริการ เพื่อเพิ่มความสะดวกในการติดต่อเรียกใช้บริการ ขั้นตอนการทำงานร่วมกันระหว่างผู้รับบริการ ผู้ให้บริการ ตัวแทน และผู้ให้บริการข้อมูลรายละเอียดของเซอร์วิส เพื่อให้ผู้รับบริการสามารถเรียกใช้เซอร์วิสที่ต้องการได้

องค์ประกอบต่อไปนี้เป็นองค์ประกอบที่จำเป็น เพื่อให้สามารถเรียกใช้บริการอื่นๆ ได้ ดังนี้1. เซอร์วิส (Service) กลุ่มของอินเตอร์เฟสที่ระบุฟังก์ชันต่างๆ ที่สามารถให้ระบบอื่นสามารถเรียกใช้บริการได้2. ผู้ให้บริการ (Service Provider) กลุ่มของคอมโพเนนต์ที่สามารถทำฟังก์ชันที่เป็นบริการตามที่กำหนดไว้เป็นเซอร์วิส (Service Specification)3. ผู้รับบริการ (Service Consumer or Requestor) ระบบอื่นๆ ที่เรียกใช้เซอร์วิสซึ่งระบบอื่นๆ อาจจะเป็นเซอร์วิสที่เรียกใช้เซอร์วิสด้วยกันก็ได้4. ผู้ให้บริการข้อมูลรายละเอียดของเซอร์วิสและค้นหาสถานที่ตั้งของผู้ให้บริการ (Service Locator) เป็นผู้ให้บริการประเภทหนึ่ง ซึ่งมีหน้าที่ลงทะเบียนรายละเอียดเกี่ยวกับผู้ให้บริการ (Service Registry) และคอยให้บริการข้อมูลรายละเอียดที่จำเป็นสำหรับการเรียกใช้บริการ5. ตัวแทนติดต่อระหว่างผู้รับบริการและผู้ให้บริการ (Service Broker) ทำหน้าที่ช่วยติดต่อส่งคำร้องขอบริการจากผู้รับบริการไปยังกลุ่มของผู้ให้บริการ เพื่อเพิ่มความสะดวกในการติดต่อเรียกใช้บริการ ขั้นตอนการทำงานร่วมกันระหว่างผู้รับบริการ ผู้ให้บริการ ตัวแทน และผู้ให้บริการข้อมูลรายละเอียดของเซอร์วิส เพื่อให้ผู้รับบริการสามารถเรียกใช้เซอร์วิสที่ต้องการได้

จากรูปเริ่มต้นที่การประกาศแจ้งการให้บริการ (Publish) เมื่อผู้ให้บริการต้องการประกาศแจ้งให้ผู้อื่นทราบและสามารถเรียกใช้บริการได้ ผู้ให้บริการจะต้องนำรายละเอียดการให้บริการ (Service Description) มาลงทะเบียนเก็บไว้ ที่ผู้ให้บริการข้อมูลรายละเอียดของเซอร์วิส (Service Registry) เพื่อให้ผู้ต้องการรับบริการได้มาค้นหาและเรียกใช้

เมื่อผู้รับบริการต้องการเรียกใช้บริการจะต้องเริ่มจากการค้นหาบริการที่ต้องการ (Find) ว่ามีผู้ให้บริการใดบ้างที่ให้บริการตามที่ตนต้องการ ซึ่งผู้ให้บริการข้อมูลรายละเอียดของเซอร์วิส จะเป็นผู้ค้นคืน รายละเอียดของผู้ให้บริการที่จำเป็นสำหรับติดต่อขอรับบริการเชื่อมต่อไปยังผู้ให้บริการและเรียกใช้ (Bind and Invoke) หลังจากผู้รับบริการได้รายละเอียดของผู้ให้บริการจะทำการเชื่อมต่อไปยังผู้ให้บริการ ตามที่อยู่ด้วยวิธีการติดต่อสื่อสาร (Transport Protocol) เพื่อส่งคำร้องขอบริการ ตามรายละเอียดวิธีการเรียกใช้บริการและผลของการให้บริการจะถูกส่งกลับมายังผู้ร้องขอบริการด้วยวิธีการและมีรายละเอียดตามที่กำหนดเช่นกัน

ตัวอย่างการนำ SOA มาประยุกต์ใช้
ตัวอย่างที่นำมาเสนอ คือ เฟรมเวิร์กสถาปัตยกรรมบริการเชิงรุกสำหรับ Mobile Services (A Services-Oriented Architecture Framework for Mobile Services) ซึ่งมีวัตถุประสงค์ก็คือ การนำ SOA มาเข้ามาใช้เพื่อช่วยในการออกแบบ mobile service ที่มี service ที่หลากหลายและให้ service เหล่านั้นสามารถทำงานร่วมกันได้

จากรูปที่ 2 จะเป็นการแสดงมุมมองใหม่ของ SOA ที่รองรับ mobile service ตั้งแต่ component หลักของ mobile service ซึ่งแต่ละ service จะมีเป็นของตัวเอง รวมถึงการแสดง component ที่เป็น mobility controller โดยมีลำดับขั้นตอนการทำงานดังนี้ เริ่มจากตัว service ได้ทำการลงทะเบียนไว้ที่ service directory เพื่อเป็นการบ่งบอกว่าจะให้ใช้ service อะไรได้บ้าง และเมื่อ service consumer ต้องการใช้บริการ ก็จะไปค้นหา service ที่ต้องการในตัว service directory ซึ่งในตัว service จะบอกว่าสามารถเรียกใช้ได้ที่ไหน และมีวิธีใช้อย่างไร เมื่อได้ service ที่ต้องการแล้วตัว service consumer ก็ทำการร้องขอใช้บริการไปที่ตัว service ซึ่งตัว service ก็จะให้บริการนั้นเลยโดยใช้ component ของตัวเอง แต่ถ้าต้องการใช้ component อื่นร่วมด้วย ตัว service ก็ให้ตัว Mobility Controller เป็นตัวจัดการ และตัว Mobility Controller ก็จะไปค้นหา service ที่ต้องการมา และก็นำมาใช้ร่วมกัน

ประโยชน์ของ SOA
1. ช่วยให้ระบบเดิมยังสามารถทำงานได้ เนื่องจากการติดต่อเรียกใช้บริการในสถาปัตยกรรม SOA จะเรียกใช้ผ่านอินเตอร์เฟสคอมโพเนนต์ที่ให้บริการจะพัฒนาด้วยเทคโนโลยีใดก็ได้
2. ทำให้การบูรณาการงานต่าง ๆ ในระดับธุรกิจทำได้ง่ายขึ้นและลดความซับซ้อน เนื่องจากสถาปัตยกรรมของ SOA เชื่อมโยงบริการต่าง ๆ เข้าด้วยกันผ่านอินเตอร์เฟส
3. ใช้เวลาน้อย ลดต้นทุนในการพัฒนาระบบสารสนเทศ และเพิ่มทรัพยากรที่มีอยู่

ที่มา:

:Roadmap to SOA สำหรับหน่วยงานราชการ กรณีศึกษา One Stop Services, สำนักงานส่งเสริมอุตสาหกรรมซอฟต์แวร์แห่งชาติ (องค์การมหาชน)
:http://www-128.ibm.com/developerworks/webservices/newto/#1
:Do van Thanh Telenor & Norwegian University of
Scienceand Technology email: thanh-van.do@telenor.com
:Ivar Jorstad Norwegian University of Science and
Technology email: ivar@ongx.org

JBoss บุกตลาด SOA ด้วย jBPM และ JBoss ESB

JBoss บุกตลาด Service Oriented Architecture SOA ด้วย jBPM และ JBoss ESB

JBoss ลุย SOA เต็มตัว ด้วยซอฟต์แวร์ jBPM(Java Business Process Management) สนับสนุน BPEL 1.1 และ 1.2
และจะออก ESB(Enterprise Service Bus) beta version ในสัปดาห์นี้

jBPM เป็นแพลตฟอร์มสำหรับ workflow, การจัดการกระบวนการทางธุรกิจ(Business Process Management:BPM) และการประสานงาน
ของกระบวนการ(Process Orchestration) นอกจากนี้ยังสนับสนุน jPDL(jBPM Process Definition Language) ด้วย
BPM มีความสำคัญยิ่งกับ SOA เพราะ SOA เป็นการทำงานร่วมกันของกระบวนการทางธุรกิจ และการสร้าง service ให้ผู้อื่นเรียกใช้

JBoss อ้างว่า มีการดาว์โหลด jBPM เพิ่มขึ้นถึง 3 เท่าจากปีที่แล้ว ปัจจุบันมีการดาวน์โหลด 20,000 ครั้งต่อเดือน BPEL 1.1 จะถูกเพิ่มใน jBPM ในเดือนกันยายน ส่วน BPEL 2.0 อยู่ระหว่างการอนุมัติจาก OASIS

นักวิเคราะห์ กล่าวว่า การสนับสนุน BPEL และการออก ESB เป็นเรื่องจำเป็นอย่างมากของ JBoss ในปัจจุบันนี้ซอฟต์แวร์สนับสนุน SOA เป็นสิ่ง
สำคัญมาก การมีแค่ Application Server ไม่พอเสียแล้วสำหรับตอนนี้ JBoss ต้องมีโครงสร้างพื้นฐานที่รองรับเซอร์วิสที่ใช้ในสภาพแวดล้อมขององค์กร
JBoss กำลังตามหลังผู้พัฒนา open source เจ้าอื่นอย่าง Apache ซึ่งตอนนี้ก็มี ServiceMix(http://servicemix.org) การออก JBossESB และ jBPM เป็นเรื่องที่ JBoss ต้องทำเพื่อความอยู่รอด นอกจากนี้การสนับสนุน BPEL ก็ไม่ใช่เรื่องใหม่อะไร และยังทำให้ BPM engine ของ JBoss ซับซ้อนยิ่งขึ้น เพราะมันไม่ได้รองรับ BPEL ตั้งแต่ต้น

JBoss ESB ตอนนี้เป็น Beta version จะออก final version ภายในปีนี้ JBoss ESB จะเป็นเหมือนกาวที่เชื่อมเซอร์วิสต่างๆ ให้ทำงานร่วมกันได้เพื่อ สร้าง SOA application ดาวน์โหลดได้ที่ http://labs.jboss.com/portal/jbossesb/downloads

Oracle ออก Oracle SOA suite Developer Preview

Oracle ออก Oracle Service Oriented Architecture SOA suite Developer Preview

Oracle ออก developer preview ให้นักพัฒนาได้ดาวน์โหลด Oracle SOA suite ไปลองใช้กัน

Oracle SOA suite เป็นคอมโพเนนต์ที่ประกอบด้วยโครงสร้างพื้นฐานสำหรับ สร้าง, deploy และจัดการเซอร์วิส โดยประกอบไปด้วย
-Integrated Service Environment (ISE) : สำหรับพัฒนาเซอร์วิส โดยใช้ JDeveloper, BPEL และ ESB designer
-Oracle BPEL Process Manager : ช่วยประสานงานเซอร์วิสในการสร้างกระบวนการทางธุรกิจ
-ESB : เพื่อติดต่อกับระบบ IT เดิมขององค์กร และระบบขององค์กรอื่น
-Oracle Business Rules : เป็น rule engine สำหรับใช้กฎธุรกิจในการตัดสินใจ สนับสนุนการแยกกฎธุรกิจออกจากกระบวนการทำงาน
-Oracle Business Activity Monitoring : มีหน้าที่ตรวจสอบเซอร์วิส และเหตุการณ์ต่างๆ โดยทำงานเป็นแบบ real-time
-Oracle Web Services Manager : จัดการด้านความปลอดภัย เช่น การพิสูจน์ตัวจริง(authentication),การให้อำนาจ(authorization) และการเข้ารหัส เป็นต้น

ในเวอร์ชัน developer preview จะมี UDDI registry กับ Oracle Application Server 10g Release 3 เพิ่มมาให้ด้วย
นอกจากนี้ Oracle ยังออก developer preview ของ JDeveloper และ Oracle J2EE Container (OC4J) สนับสนุน EJB 3.0 และ JPA

ผลสำรวจชี้ SOA ไม่ค่อยได้รับความสนใจในเอเชีย

ผลสำรวจชี้ Service Oriented Architecture SOA ไม่ค่อยได้รับความสนใจในเอเชีย

Springboard(www.springboardresearch.com) ทำการสำรวจ CIO และผู้รับผิดชอบ IT ขององค์กรต่างๆ 2,615 คนในประเทศออสเตรเลีย จีน อินเดีย และสิงคโปร์ พบว่ามีเพียง 21% เท่านั้นที่สนใจ SOA จากผลการสำรวจยังพบอีกว่า IBM เป็นผู้นำด้าน IT เหนือกว่า vendor เจ้าอื่น โดย 50% ขององค์กรที่วางแผนจะสร้าง SOA บอกว่า IBM เป็นตัวเลือกที่ดีสุดที่จะช่วยบริษัทในการย้ายจากระบบเดิมไปเป็น SOA
Springboard พบว่าองค์กรที่กำลังพัฒนา SOA ส่วนใหญ่หรือ 54% ใช้ SOA เพื่อการรวมแอพพลิเคชันต่างๆ เข้าไว้ด้วยกัน อีก 27% ใช้ SOA เพื่อรองรับเว็บเซอร์วิส และเว็บแอพพลิเคชัน อีก 9%ใช้เพื่อการการรวม และใช้ข้อมูลร่วมกันในองค์กร และสุดท้ายอีก 9% ใช้เพื่อสร้างเซอร์วิสที่ใช้ร่วมกันในองค์กร

การสำรวจนี้ยังมีรายละเอียดเกี่ยวกับปัจจัยเสี่ยงสำหรับองค์กรที่สร้าง SOA ด้วย ความเสี่ยงพื้นฐานที่สุดที่องค์กรต่างๆอ้างคือ พวกเขายังไม่แน่ใจถึงประโยชน์ที่จะได้รับจาก SOA นั่นเอง

ผลสำรวจชี้โปรเจ็กต์ SOA น่าผิดหวังถึง 1 ใน 4

ผลสำรวจชี้โปรเจ็กต์ Service Oriented Architecture SOA น่าผิดหวังถึง 1 ใน 4

จากการสำรวจของ InformationWeek พบว่าการสร้าง SOA ยาก และใช้เวลากับเงินมากกว่าที่คาดการณ์ไว้ (อย่างน้อยก็ใช้เวลากับเงินมากกว่าที่ vendor ที่บอกเรา)

จากการสำรวจผู้เชี่ยวชาญด้านเทคโนโลยี และธุรกิจขององค์กร 273 องค์กร พบว่ามี 73% ที่อยู่ระหว่างการพัฒนาเว็บเซอร์วิส หรือ SOA โดย 24% หรือ 1 ใน 4 ของกลุ่มนี้บอกว่าโปรเจ็กต์ให้้ผลลัพธ์ต่ำกว่าที่คาดไว้ โดย 55% บอกว่าเกิดจากความซับซ้อนที่เพิ่มขึ้นอย่างมากในระบบ IT และ 41% บอกว่ามาจากต้นทุนมากกว่าที่คาดการณ์ไว้มาก
จาก 73% ข้างต้นมีเพียง 7% ที่บอกว่าผลลัพธ์ที่ได้ดีกว่าที่ตั้งเป้าไว้ ส่วนอีก 69% ที่เหลือยังไม่ได้ประเมินผลลัพธ์จาก SOA

อย่างไรก็ดี ยังไม่มีใครมาหยุดความร้อนแรงของ SOA ได้ บริษัท 2 ใน 3 เริ่มศึกษา SOA และ 45% บอกว่าโปรเจ็กต์ SOA สำคัญอย่างมากต่อเป้าหมายทางธุรกิจ โดย 55% หวังว่า SOA จะช่วยเพิ่มประสิทธิภาพในการติดต่อกับ business partner และ 40% หวังจะนำมาช่วยเพิ่มความเร็วในการออกผลิตภัณฑ์ของบริษัท

ผลสำรวจชี้ให้เห็นว่า SOA ต้องใช้เวลานานกว่าจะสร้างประโยชน์ที่เป็นรูปเป็นร่างให้กับองค์กร ผลลัพธ์ที่ได้ยังน่าผิดหวัง และยังขาดประโยชน์ทางธุรกิจที่จับต้องได้จริงๆ

Review หนังสือ SOA ของ Thomas Erl

Review หนังสือ SOA ของ Thomas Erl

ช่วงนี้ผมมีความจำเป็นต้องศึกษาเรื่อง SOA อย่างลึกซึ้งครับ,
จึงได้ไปค้นหาดูว่าใน amazon มีเล่มไหนน่าสนใจบ้าง
เล่มแรกครับที่เจอ คือ
Service-Oriented Architecture: Concepts, Technology, and Design
ของ Thomas Erl เกือบ 800 หน้า

เนื้อหาหนักแน่น ครบถ้วน! ข้อดีที่สุดของเล่มนี้ที่ผมชอบก็คือการเขียนถึง SOA Life Cycle:

การวางแผน (Planning)
การวิเคราะห์ระบบ (Analysis)
เทคโนโลยีที่เกี่ยวข้องในการ implement (Technology)
และการออกแบบ (Design)
ซึ่งเล่มอื่น ๆ จะไม่ลงรายละเอียดถึงขนาดนี้

และที่สำคัญมีการนำ case study ที่เกิดขึ้นจริงมาแทรกอยู่ในทุก ๆ บทที่เกี่ยวข้อง แต่ถ้าใครคาดหวังว่าจะมีสอนการ coding ในเล่มนี้, ไม่มีครับ!
แต่จะอ้างถึงในส่วนเทคโนโลยีที่เกี่ยวข้องเท่านั้น เพื่อให้เข้าใจในแนวคิด

ผู้แต่งใช้เวลาถึงปีเศษ ๆ กว่าจะเขียนเล่มนี้จบ ตีพิมพ์ครั้งแรกเมื่อปี 2005, ในสมัยที่ผู้คนยังกล่าวถึง SOA ไม่มากอย่างทุกวันนี้ (เล่มที่ผมซื้อเป็นการพิมพ์ครั้งที่ 6) ผมจึงตัดสินใจเลือกซื้อเล่มนี้เป็นเล่มแรก, ได้ไปสืบหาดูมีขายที่ศูนย์หนังสือจุฬา ฯ และ IT Book House ราคาประมาณ 1,8XX บาท
วันก่อนผมแวะไปที่ห้องสมุดมารวยของตลาดหลักทรัพย์แห่งประเทศไทย ก็มีให้ยืมเล่มนี้เช่นกัน

เจาะแก่น SOA ตอนที่ 3 BPEL

เจาะแก่น Service Oriented Architecture SOA ตอนที่ 3 BPEL

จากบทความก่อนหน้า ผมบอกว่า web service (WS) ก็คล้าย method แต่ว่าถูกดึงออกมาอยู่ข้างนอกลอย ๆ
ที่นี้เราจะทำอย่างไร เพื่อเรียกใช้มันเพื่อสร้าง application หรือ business process ที่ประกอบด้วย web service หลาย อัน

ก่อนอื่นขอแบ่งประเภทของเว็บเซอร์วิสเป็น 2 ประเภท

1. Atomic web service - เว็บเซอร์วิสทำงานด้วยตัวเอง ไม่จำเป็นต้องพึ่งพาเว็บเซอร์วิส
2. Composite web service - เว็บเซอร์วิสที่ต้องเรียกใช้เว็บเซอร์วิสอื่น เพื่อสร้าง service ของตัวเอง

จากนั้นเราแบ่งจุดประสงค์ของการเรียกใช้ WS เป็น 2 แบบ

1. เรียกใช้ เพราะเราต้องใช้จริงๆ ผู้เรียกมักเป็นend user client เช่น ผู้ใช้ส่งข้อมูลไปยัง WS ของบริษัททัวร์ เพื่อซื้อ packageทัวร์
2. เรียกใช้ เพราะจะไปให้คนอื่นใช้ต่อ ก็คือ Composite WS นั่นละ ต้องเรียกใช้หลายๆ WS มาประกอบกันเพื่อสร้าง service ของตัวเอง
เช่น WS ของบริษัททัวร์ เรียกใช้ WS ของโรงแรมเพื่อจองห้อง, สายการบินเพื่อจองตั๋ว และธนาคารเพื่อตัดยอดเงิน

การเรียกใช้ web service มี 2 วิธีหลักๆ ได้แก่

1. ใช้ Web service client API เช่น WSIF, WSE เป็นต้น ก็คือเราเขียน application (ด้วยJava หรือ .NET) ของเราไปตามปกติ เมื่อถึงเวลาต้องเรียกใช้ WS ก็เรียกใช้ API แทน เหมือนกับการเขียนโปรแกรมปกติทั่วไป วิธีนี้เหมาะกับ end user client ที่เป็นผู้ใช้ปลายทางจริงๆ เพราะไม่ค่อยมีการเปลี่ยนแปลงบ่อย และมักเรียกเพียงไม่กี่ service อย่างไรก็ตามวิธีนี้ไม่เหมาะกับการสร้าง Composite WS เพราะเรามักใช้ Composite WS เพื่อสร้าง business process (business process คือ บริการที่เห็นหรือสัมผัสได้โดยตรงจากผู้ใช้หรือลูกค้า และให้ผลตอบแทนกับองค์กร นั่นก็คือservice นอกสุดที่ให้บริการลูกค้าโดยตรงนั่นเอง) ซึ่งมี business logic ซึ่งอาจเปลี่ยนแปลงบ่อยๆ นอกจากนี้ business goal ของการสร้างapplication ด้วย WS ก็เพื่อความคล่องตัว (agility) ปรับเปลี่ยนง่าย จะได้สอดคล้องกับสภาพธุรกิจปัจจุบันที่มีการแข่งขันสูง ดังนั้นการผูกแต่ละ WS ไว้ด้วยการ coding แบบเก่านั้น จึงไม่เหมาะกับการสร้าง business process ด้วย WS ตามหลักการของ SOA

2. ใช้ WS ตัวกลาง (mediator) มาเรียกใช้ sub-WS นั่นคือใช้ BPEL (Business Process Execution Language) นั่นเอง
การจะสร้าง business process หรือ composite WS จาก BPEL ต้องประกอบด้วย 2 ส่วน ได้แก่
2.1 BPEL file - BPEL เป็นภาษาที่ไว้ใช้กำหนด business process ซึ่งจริงๆ แล้ว เป็นภาษา xml
ลักษณะของ BPEL คือ เป็น procedural language คล้ายกับ flow chart ทำหน้าที่กำหนดว่าจะเรียก WS ไหน, เมื่อไหร่ และอาจเก็บตัวแปรด้วย การทำงานจะไปข้างหน้าเรื่อย ๆ จนจบไฟล์ (ลองนึกถึง file build.xml ของ Ant อาจเข้าใจ การทำงานคล้ายอย่างงั้นเลย)
2.2 BPEL engine คือ ตัวที่จะมาอ่าน BPEL ที่เราเขียน และ สร้าง composite WS ให้ทำงานตามที่กำหนดใน BPEL นั่นเอง (คล้าย Ant tool ที่อ่าน build.xml) client ที่เรียกใช้จะเห็น composite WS ที่สร้างขึ้นเป็นเหมือน WS ทั่วไป BPEL engine ปัจจุบันก็เช่นBPEL manager ของ oracle ซึ่ง vendor ส่วนใหญ่จะมี BPEL designer ติดมาด้วย เพื่อสร้างและแปลง flow chart เป็น bpel (อย่างที่บอกว่าbpel เป็นภาษาที่เหมือน flow chart อยู่แล้ว ไม่มีแยก function มี control flow แค่switch-case, loop และก็อย่างอื่นอีกนิดหน่อย สามารถดูตัวอย่างได้ที่ link อ้างอิง)

นอกจากนี้ BPEL ยังสนับสนุนการทำงานแบบ concurrent, asynchronous และ exception handling ด้วย อย่างไรก็ตาม BPEL ก็คือ procedural language ที่ไว้ใช้สร้าง Composite web service โดยการระบุการเรียกใช้ WS อื่นๆ เพื่อสนับสนุนแนวความคิดของ SOA นั่นเอง

เจาะแก่น SOA ตอนที่ 2 WebService กับ SOA

เจาะแก่น SOA ตอนที่ 2 WebService กับ Service Oriented Architecture SOA
จากภาคแรก ผมเกริ่นเกี่ยวกับ SOA เอาไว้ ในตอนที่ 2 นี้ผมจะเขียนความเกี่ยวข้องระหว่าง SOA กัน web services

ที่ SOA เป็นพูดถึงกันมากส่วนหนึ่งก็เพราะ web services นั่นเอง ความจริง SOA ไม่ใช่ของใหม่ ถ้าเราสังเกตลักษณะของ service จะมีส่วน implementation แยกกับ interface เสมอ เพื่อลด coupling ระหว่าง service กับผู้เรียก ซึ่งแนวคิดนี้มีใน J2EE (RMI), CORBA และ COM อยู่แล้ว นั่นคือเราสามารถใช้ RMI technology (ซึ่งเป็น distributed technology) ทำ SOA ได้

แต่ว่า จุดขายที่สำคัญของ web services คือ platform independent ผู้เรียกกับ service ไม่จำเป็นต้องเป็น platform เดียวกัน (java application เรียกใช้ .NET service) ซึ่งต่างจาก RMI ที่ต้องเป็น java หรือ CORBA ที่ต้องเป็น Java หรือ C++

ในปัจจุบันถ้า web services คือหัวใจของ SOA, XML ก็คือเส้นเลือดหล่อเลี้ยงหัวใจ เพราะ XML ทำให้ Web services เป็น platform independent technology ซึ่งช่วยให้สามารถ communicate ระหว่าง B2B หรือ new system กับ legacy system ที่เป็นต่างภาษา หรือ platform ได้

XML เป็น markup language มีลักษณะเป็น text ใครก็เปิดอ่านได้ และอ่านรู้รื่องได้ไม่ยาก ขอให้ผู้เรียกกับ service เข้าใจ xml ก็เป็น web services ได้แล้ว ซึ่ง technology ที่เกี่ยวกับ web services ส่วนใหญ่เกี่ยวข้องกับ XML ทั้งนั้น เช่น WSDL, SOAP, BPEL

SOA กับ web services จะเป็นเครื่องมือสำคัญในการพัฒนา enterprise application ในอนาคต ด้วยจุดเด่น คือ
1. loose coupling
2. ความคล่องตัว ปรับเปลี่ยนง่าย
3. high reusability
4. ที่สำคัญช่วยลด cost ในการ mainteinence

ตามหลักการแล้ว web service สามารถเรียกข้ามองค์กร (cross organization)ได้ แต่ว่า spec บางอย่างของ Web services ยังไม่นิ่ง เช่น security, trasaction, และ QoS ต่าง ๆ ดังนั้น การใช้ SOA ส่วนใหญ่จึงเป็นการเรียกใช้ web service ภายในองค์กรของตัวเองเท่านั้น
สิ่งที่ทำได้ตอนนี้ คือ เกาะติดความก้าวหน้าของ SOA และพิจารณาความเสี่ยงเมื่อนำ SOA มาใช้อย่างรอบคอบ เพราะ SOA ก็มีต้นทุนสูง, learning curve พอสมควร และที่สำคัญจะได้ไม่เป็นเหยื่อคำโฆษณาของเหล่า vendor นั่นเอง

เจาะแก่น SOA ตอนที่ 1 เริ่มต้น

เจาะแก่น Service Oriented Architecture SOA ตอนที่ 1 เริ่มต้น

วันนี้ขอเขียนเรื่องที่กำลังพูดถึงกันมากอยู่ขณะนี้ คือ เรื่อง SOA ครับ บทความนี้ผมจะแนะนำให้ทุกคนรู้จัก SOA ครับ SOA (Service Oriented Architecture) เป็นรูปแบบในการออกแบบระบบ (system) หรือ โปรแกรมประยุกต์ (application) แบบหนึ่ง อย่าง object oriented เวลาออกแบบระบบ เราจะมองเป็น object หรือ class แยกแยะระบบออกมาเป็น class และความสัมพันธ์ (relations) แต่ SOA จะมองระบบ ประกอบด้วยการทำงานหรือบริการ (service) ต่างๆ

แล้ว service คืออะไรล่ะ?
service ก็คล้าย function หรือ method นั่นแหละ คือมีหน้าที่ทำอะไรสักอย่าง ถึงเวลาเราก็เรียกใช้ แต่ service มีลักษณะ high level และเป็นมุมมองเชิงธุรกิจมากกว่า เช่น มองระบบธนาคารประกอบด้วยบริการถอน withdrawal service, บริการฝาก deposit service แทนที่จะมองเป็น class Customer หรือ class Teller ที่มี operation withdrawal หรือ deposit

สิ่งที่ service ทำได้ แต่ method ทั่วไปทำไม่ได้ คือ distributed system นั่นคือแต่ละ service สามารถถูกเรียกจากต่างระบบ, host หรือ JVM กันได้ แต่ละ service มีอิสระต่อกัน ไม่ได้กระจุกติดกันอยู่ใน application หรือ jar file หนึ่ง พูดง่าย ๆ service ก็คือ method ที่ถูกดึงมาไว้ข้างนอกนั่นเอง

ข้อดีของ service คือ loose coupling และสามารถใช้ร่วมกันได้ บางคนอาจเถียงว่า method ก็สามารถใช้ร่วมกันได้ แต่ service สามารถใช้ร่วมกันระดับ application ครับ เช่น ธนาคาร A มี Deposit service ธนาคาร B, C สามารถเขียน application มาเรียกใช้ Deposit service ของธนาคาร A ได้ นั่นคือเป็นการ reuse ระดับ high-level ขึ้นมาอีก

SOA ขับเคลื่อนองค์กรสู่บริการ เทรนด์ใหม่ที่ต้องปรับตัว

Service Oriented Architecture SOA ขับเคลื่อนองค์กรสู่บริการ เทรนด์ใหม่ที่ต้องปรับตัว

เมื่อการแข่งขันมาถึงจุดที่การให้บริการลูกค้าเป็นสิ่งสำคัญมากกว่าการแข่งขันเรื่องราคา หรือผลิตภัณฑ์ใหม่ๆ ที่ใครๆก็สามารถทำได้ เหตุนี้ทำให้องค์กรต้องปรับเปลี่ยนรูปแบบการให้บริการเพื่อขยายให้ทันกับความต้องการของลูกค้า ตัวอย่างเช่น บริษัทผู้ให้บริการโทรศัพท์เคลื่อนที่ ในการสร้างบริการให้ลูกค้าเข้าถึงด้วยการเข้าใช้บริการผ่านร้านให้บริการ ไม่ว่าจะเป็นการเปิดบริการ ซ่อมเครื่อง รวมไปถึงสอบถามบริการผ่านคอลเซ็นเตอร์ แทนที่จะเข้ามารับบริการที่ส่วนกลาง

ทว่าระบบต่างๆที่กระจายอยู่ตามร้านให้บริการ และคอลเซ็นเตอร์นั้น ต้องพึ่งระบบไอทีจากส่วนกลางในการให้บริการ

ดังนั้น ระบบไอทีหลังบ้านจึงจำเป็นต้องสนับสนุนการทำงานที่ขยายเพิ่มขึ้น !!!

ดังนั้น แนวคิดการใช้ SOA (Service-Oriented Architecture )จึง เกิดขึ้น เพราะการใช้ไอทีในองค์กรไม่ได้จำกัดอยู่เพียงการใช้ซอฟต์แวร์สำเร็จรูป ที่ไม่เพียงพอต่อการทำงานที่เพิ่มขึ้น อีกต่อไป

SOA กระทบโครงสร้างไอทีขององค์กร

SOA ไม่ใช่ซอฟต์แวร์ หรือ แพ็คเกจ นายพัฒน์พงศ์ บุปผรัตน์ ที่ปรึกษาอาสุโสด้านธุรกิจและหัวหน้าทีมพัฒนาธุรกิจขององค์กร บริษัท เครือเจริญโภคภัณฑ์ จำกัด อธิบายถึงแนวคิดของ SOA ว่า SOA แบ่งเป็น 2 คำ Service-Oriented และ Architecture

คำแรก Service-Oriented เป็น Software ที่ไม่ใช่ซอฟต์แวร์ แพ็คเกจ แต่เป็นซอฟต์แวร์ตัวเล็ก ทำงานเฉพาะด้าน ขึ้นอยู่กับว่าจะแบ่งเป็นบริการอะไรบ้าง

คำที่สอง Architecture คือการออกแบบ โดยจะมององค์กรโดยรวมว่าต้องการบริการอะไรบ้าง ก็จะแบ่งบริการนั้นๆออกเป็นส่วนย่อยๆ

ทั้งนี้ หลายคนมองว่า SOA คือ web service แต่จริงๆแล้วไม่ใช่เพราะ web service เป็นแค่เครื่องมือในการใช้งาน

ดังนั้น SOA จึงไม่ใช่สินค้า หาซื้อไม่ได้ แต่มันคือแนวคิดที่ต้องสร้างเองในองค์กร

สำหรับสินค้าที่เกี่ยวข้องกับ SOA ประกอบด้วย 4 ส่วนคือ 1. Enterprise Service Bus เป็นโครงข่ายสำคัญในการขับเคลื่อน SOA ทั้งหมด เป็นการเชื่อมต่อระหว่างแอพพลิเคชัน

2.Design-Time Governance เป็น ดาต้า เบส กลางช่วยรวบรวมว่าองค์กรมีบริการอะไรบ้าง และช่วยนำบริการออกไปยังหน่วยงานและควบคุมบริการให้เหมาะสมกับองค์กรด้วย

3.Run-Time management เป็นตัวจัดการ ทำอย่างไรให้บริการทำงานสอดคล้องกับ SOA ที่ตั้งไว้ และ 4.Security Gateway ในที่นี้ไม่ได้หมายถึง Firewall ที่เป็นเน็ตเวิร์ก แต่เป็น Application Firewall ที่เข้าใจ คำสั่ง XML นอกจากนี้ต้องมี Application Delivery Control ช่วยเร่งความเร็วในการทำงานของ SOA ด้วย

เมื่อนำแนวคิด SOA เข้ามาใช้ แอพพลิเคชันแบบเก่าต้องถูกรื้อใหม่

จากแนวคิดเรื่อง SOA ทำให้เกิดการทำ Software as a service (SaaS) และ web 2.0 ขึ้น

SaaS คือ แอพพลิเคชัน แต่ไม่ใช่ แอพพลิเคชันตัวใหญ่ มีหน้าทีทำงานเฉพาะด้านในด้านหนึ่ง โดยการใช้งานของผู้ใช้ ไม่จำเป็นต้องเป็นเจ้าของแอพพลิเคชัน สามารถขอเช่าใช้งาน โดยมี Vender หรือหน่วยงานที่เกี่ยวข้องเป็นผู้ดูแลรักษา

การ์ทเนอร์ คาดการณ์ในปี 2010 ซอฟต์แวร์ทุกอย่างจะเป็น SaaS ในสัดส่วน 25%

ขณะที่ web 2.0 หลักการคือ คนใช้งานเป็นผู้จัดการข้อมูลได้ด้วยตัวเอง เจ้าของเว็บไซต์เป็นเพียงผู้ให้บริการ ไม่ใช่เจ้าของที่ทำหน้าที่ให้ข้อมูลเพียงฝ่ายเดียว การให้ข้อมูลต้องเกิดจากผู้ใช้งานและเป็นข้อมูลที่มีการสื่อสารได้ 2 ทาง

ตัวอย่างของสิ่งที่เกิดขึ้นจากแนวคิด web 2.0 ที่เห็นในตลาด ได้แก่ Blog ที่เจ้าของและสมาชิกเข้ามาแลกเปลี่ยนข้อมูลกันได้ ทำนองเดียวกับ Wikipedia หรือ Google Adsearch ที่ผู้ใช้สามารถเข้าไปควบคุมการทำงานว่าต้องการได้รับบริการรูปแบบใด




เมื่อเทรนด์เป็นเช่นนี้ องค์กรต่างๆที่ต้องการสร้างบริการให้เกิดความพึงพอใจแก่ลูกค้าจำเป็นต้องนำแนวคิดนี้ไปสร้างให้เกิดประโยชน์ในทางการตลาด
ช่องโหว่ SOA ที่ไม่ควรมองข้าม

ทว่าแนวคิด SOA ก็ต้องได้รับความปลอดภัยสูงเช่นกัน ในมุมมองของผู้ผลิตอุปกรณ์เครือข่าย อย่างบริษัท ทรีคอม (ประเทศไทย) จำกัด โดยนายสุรชัย ไชยรังกิจรัตน์ กล่าวว่า แนวคิด SOA คือการออกแบบอยู่บนซอฟต์แวร์ที่แยกกันเป็นส่วนๆ ถ้ามีซอฟต์แวร์ 10 ตัว ระบบก็ต้องรายงาน 10 ตัว ไม่เหมือนซอฟต์แวร์แบบดั้งเดิมที่รายงานรวมกันทั้งหมดเพียงครั้งเดียว

นอกจากนี้ เนื่องจาก SOA ใช้ web service เป็นเครื่องมือ ที่วิ่งอยู่บน Protocal XML ดังนั้นจึงเป็นมิตรกับมนุษย์ นั่นหมายถึงคนสามารถเข้าไปอ่านข้อมูลได้เพียงรู้ ชื่อผู้ใช้งาน ไม่เหมือนภาษาคอมพิวเตอร์แบบสมัยก่อน

ดังนั้นแต่ละช่องของซอฟต์แวร์ที่คุยกันจึงมีช่องว่างด้านความปลอดภัย ถูกโจมตีง่าย !!!

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

เมื่อ SOA คือคำตอบของการวางโครงสร้างพื้นฐานด้านไอทีแล้ว เพราะการใช้งานด้านไอที ไม่ได้จำกัดอยู่แต่เพียงการใช้ซอฟต์แวร์สำเร็จรูปเพื่อบันทึกข้อมูลของบุคลากรอีกต่อไป แต่ยังจำเป็นต้องวิเคราะห์และบริการจัดการข้อมูล และสร้างบริการในเชิงลึกอีกมาก สิ่งที่องค์กรต้องคำนึงถึงในการเลือกเวนเดอร์เพื่อเข้ามาสนับสนุนการวางระบบให้ สามารถเลือกได้ 2 แบบ คือ แบบแรก ใช้เวนเดอร์เจ้าเดียวเพื่อหาโซลูชันที่ต้องการให้ ซึ่งวิธีการนี้จะไม่มีปัญหาในการนำโซลูชันหลายๆอย่างมาอินทริเกรทกัน เพราะเวนเดอร์จะรู้ระบบและสามารถกระทำได้จากโซลูชันที่ได้เลือกมา วิธีที่สอง คือ ใช้เวนเดอร์หลายเจ้าโดยเลือกจากเวนเดอร์ที่มีจุดแข็งในแต่ละโซลูชัน แต่อาจมีปัญหาเรื่องการอินทริเกรทโซลูชัน เพราะเป็นโซลูชันจากคนละเวนเดอร์มาอยู่ด้วยกัน ดังนั้น ควรเลือก โซลูชันที่เป็นโอเพ่น ซอร์ส จะไม่มีปัญหาในการอินทริเกรท เนื่องจากเป็นซอฟต์แวร์เปิด

องค์กรใช้ไอทีในการขับเคลื่อนธุรกิจ ไม่ควรพลาดในการนำแนวคิด SOA ไปใช้ในองค์กร!!!

Microsoft Highlights “Real-World” Approach to SOA at SOA & Business Process Conference

Microsoft Highlights “Real-World” Approach to SOA at SOA & Business Process Conference

Microsoft showcases customer successes, guidance and road map for an incremental approach to service-oriented architecture based on over half a decade of customer engagements.

At the Microsoft SOA & Business Process Conference, Microsoft Corp. today highlighted customers that have successfully deployed service-oriented architecture (SOA) solutions by taking a “real-world” approach, and announced updated guidance and upcoming advances in its interoperability and technology road map to extend its commitment to “real-world” SOA solutions.

Today’s conference highlights some of the world’s largest and most successful service-oriented architecture SOA deployments, including those at Commonwealth Bank of Australia, Dell Inc., CitiGroup and Sandvik. In addition, customers such as Clear Channel Communications Inc., HP and Jet Blue Airways joined more than 700 participating customers and industry partners to share best practices on achieving success with service-oriented architecture SOA by adopting an approach that focuses on the business problem at hand and strong architecture at the solution level. This “real-world” approach departs from the industry norm of applying a high-risk, heavy, “top-down” strategy to SOA implementations that starts with major enterprisewide infrastructure investments that often fail to show results in a relevant timeframe or offer a compelling return on investment. Instead, the “real-world” approach to SOA advocated by Microsoft and practiced in successful customer service-oriented architecture SOA deployments relies on achieving rapid success around a focused business problem, which can result in broader SOA implementations.

Recent independent surveys of CIOs from Goldman Sachs & Co.* and Merrill Lynch & Co.** show Microsoft leading in mindshare and customer preference with its approach to SOA service-oriented architecture. Goldman Sach’s IT spending survey placed Microsoft in a clear leadership position as the vendor of choice in assisting the “move to SOA/Web services.” Separately, Merrill Lynch’s recent survey of CIOs ranked Microsoft the “most important provider of Web services/SOA software (applications and infrastructure).”

“Real-World” SOA service-oriented architecture

Microsoft’s “real-world” approach to SOA was initiated more than seven years ago with the introduction of the .NET platform that continues to set the industry bar as the first native Web services-based platform built from the ground up. Further, the platform goes beyond service orientation to address capabilities such as federated data, identity and access, and integrated user experience across diverse applications, with guidance available on the MSDN® Architecture Center (http://msdn.microsoft.com/architecture). Coupled with a strong focus on interoperability through work with partners and standards bodies (such as the Web Services Interoperability Organization), Microsoft has additionally worked hard to support service-oriented approaches in heterogeneous environments.

“Microsoft understands that building enterprise architectures for technology’s sake doesn’t benefit customers with a need to solve business challenges with technology,” said Ron Schmelzer, senior analyst at ZapThink LLC. “SOA service-oriented architecture isn’t about finding a single infrastructure product that addresses all of your technology challenges, but instead about using architectural guidelines and practices to enable the creation and ongoing management of a new breed of agile applications. Microsoft and its customers are demonstrating great progress in this area and sharing their learnings at this week’s SOA & Business Process conference.”

Siemens AG is one example of a customer that has realized significant results from this approach to service-oriented architecture SOA implementation. During the past two years, the company has implemented a mission-critical infrastructure for SOA and business process management that enables its IT operational processes to support 400,000 employees worldwide. This has increased Siemens’ business productivity and reduced its deployment time of new processes by 83 percent.

“Contrary to industry hype around the need for large-scale architectures, Siemens AG is finding extreme value in a more incremental approach to service-oriented architecture SOA as advocated by Microsoft,” said Thomas Buse, section manager in Siemens ITO, Concepts and Processes at Siemens AG. “Through our Microsoft SOA implementation, we will implement over 400 new business processes with a frequency of four to eight new processes every six to 12 weeks, which allows us the agility to solve business problems and seize opportunities as we identify them.”

Upcoming Advancements

Microsoft today highlighted a road map of current and ongoing investments. This included new guidance on how to deliver Enterprise Service Bus (ESB) functionality to simplify and accelerate the development of service-oriented architectures. In addition, customers will be able to take advantage of IBM midrange and mainframe integration solutions via BizTalk Adapter for Host Systems, which will be shipped this calendar year in BizTalk® Server Enterprise and Standard editions, designed to help customers connect applications, data sources, messaging and security systems between IBM mainframe and mid-range systems and Microsoft® Windows® environments.

Microsoft also underscored upcoming advancements with Microsoft’s Office Business Application strategy, made possible by new platform capabilities in the 2007 Microsoft Office system. This further enables customers to realize the “real-world” value from their service-oriented architecture SOA implementations by enabling information workers to use the familiar Microsoft Office and SharePoint® Server environments for accessing services and interacting with business applications.

“Unlike enterprise infrastructure-centric approaches, Microsoft’s core technologies for ‘real-world’ SOA, including the .NET Framework 3.0, 2007 Microsoft Office System and BizTalk Server 2006, are poised to unlock ‘real-world’ value from existing assets in the enterprise, by bridging the world of structured and unstructured process,” said John deVadoss, director of Architecture Strategy at Microsoft. “Over the past half a decade we’ve seen that the biggest and most successful service-oriented architecture SOA deployments are by customers that have started small and have iteratively built broader success. Given the industry dialogue around large-scale SOA implementations not delivering the promised return, the goal of today’s conference is to share real-world customer references and the lessons learned with this approach to rapid time-to-value.”

Founded in 1975, Microsoft (Nasdaq “MSFT”) is the worldwide leader in software, services and solutions that help people and businesses realize their full potential.

Note to editors: If you are interested in viewing additional information on Microsoft, please visit the Microsoft Web page at http://www.microsoft.com/presspass on Microsoft’s corporate information pages. Web links, telephone numbers and titles were correct at time of publication, but may since have changed. For additional assistance, journalists and analysts may contact Microsoft’s Rapid Response Team or other appropriate contacts listed at http://www.microsoft.com/presspass/contactpr.mspx.