แปลและย่อมาจาก MS Architecture Journal : Lightweight SOAs: Exploring Patterns and Principles of a New Generationof SOA Solutions
Introduction
ตลอดหลายปีที่ผ่านมาหลายคนเฝ้ามองและตั้งคำถามว่าเพราะอะไรถึงทำให้วิธีการสร้าง Service Oriented (SOA) ด้วยวิธีการแบบดั้งเดิมถึงไม่สามารประสบความสำเร็จในเรื่องของการเพิ่มคุณค่าทางธุรกิจและตอบสนองความต้องการทางธุรกิจได้อย่างรวดเร็ว เหมือนกับตอนที่มันถูกสร้างขึ้น เนื่องจากโจทย์สองข้อนี้ถือเป็นหัวใจหลักในการนำเสนอเรื่องของ SOA เข้ามาในองค์กร ในบทความนี้เราจะมาพิจรณาถึงจุดต่างๆในสถาปัตยกรรมของมันที่เป็นปัจจัยให้เราไม่สามารถทำ SOA ได้สำเร็จได้ไม่ว่าจะเป็น ความซับซ้อนของ SOAP, WS-* หรือ Enterprise Service Bus เอง หลังจากนั้นเราจะนำเสนอสถาปัตยกรรมทางเลือกที่ดูยืดหยุ่นกว่า ไม่ซับซ้อนมาก อย่าง REST และ Web-Oriented Architecture
SOA: Architecting Without Constraints
SOA ถือเป็นเสาหลักของ distributed system ในช่วงหลายปีที่ผ่านมาโดยที่หัวใจหลักของ SOA คือความสามารถในการตอบสนองของฝั่ง IT ที่มีต่อการเปลี่ยนแปลงทางธุรกิจอย่างรวดเร็วในปัจจุบันด้วยการนำเสนอแนวคิดของการสร้างเซอร์วิสใหม่ๆจากการประกอบเอาเซอร์วิสอินเทอร์เฟสหลักที่ถูกเตรียมไว้แล้ว ซึ่งเซอร์วิสหลักเหล่านั้นจะถูกนำกลับมาใช้ได้บ่อยมากทำให้ระยะเวลาในการสร้างเซอร์วิสใหม่ลดลงไปอย่างมาก แต่ข้อเสียหลักๆของ traditional SOA คือมันไม่มี Constraints หรือข้อกำหนดหลักว่าการทำ SOA ต้องประกอบไปด้วยคุณลักษณะอะไรบ้างซึ่งถือว่าเป็นข้อเสียหลักของมันเลยเพราะทุกคนก็จะตีความและทำกันไปแบบไร้ทิศทาง สำหรับปัจจุบัน SOA นั้น ถ้าเราพิจรณาจากวิธีการทางสถาปัตยกรรมจะพบว่าการได้มาซึ่งวิธีการทำงานแบบในลักษณะนี้นั้น SOA แบบดั้งเดิมจำเป็นต้องมีคุณลักษณะพื้นฐานดังนี้
- ต้องมีการยกระดับให้ SOAP และ WSDL ให้เป็นอินเทอร์เฟสหลักสำหรับการเชื่อมต่อกับเซอร์วิสต่าง
- ใช้มาตรฐานตระกูล WS-* เข้ามารับมือกับการทำงานระดับ mission-critical
- ติดตั้ง ESB เพื่อใช้สำหรับซ่อนการทำงานที่ซับซ้อนของการเชื่อมต่อเซอร์วิสและการประสานงานข้ามแพลทฟอร์มและโปรโตคอล
- ใช้ Integration Server เข้ามาช่วยในเรื่องของการจำลอง complex business process
- ใช้ SOA-governance tool เข้ามาช่วยในเรื่องของการจัดการและบริหารภาพรวมทั้งหมดของ SOA
- ซึ่งดูจากลิสท์แล้วเรายังเห็นว่ามันดูเรียบง่าย และเมื่อเราร่างภาพออกมาเราจะได้โครงสร้างของ SOA ออกมาคร่าวๆดังภาพ
- SOAP and transport abstraction
- Abuse of description languages
- ESB complexity
- WS-* interoperability
- SOA governance
SOAP and the Illusion of Transport Abstraction
อ้างถึงมาตรฐานเวอร์ชั่นล่าสุดของ SOA นั้นมาตรฐานการส่งข้อมูลจะถูกทำผ่าน Simple Object Access Protocol (SOAP) ซึ่งแนวคิดหลักของแนวคิดนี้คือการแยกส่วนของโปรโตคอลที่ใช้สื่อสารออกมาจากเซอร์วิสที่ให้บริการเพื่อลดความซับซ้อนของการทำงาน ซึ่งตามทฤษฎีแล้ว SOAP สามารถถูก deploy ไว้บนโปรโตคอลที่แจกต่างกันได้เช่น HTTP และ MSMQ แต่ในทางปฏิบัติแล้วเราพบว่าการออกแบบให้ SOAP ให้ทำงานได้หลายๆโปรโตคอลนั้นจะต้องมีค่าใช้จ่ายสูงมาก ดังนั้นทางออกคลาสสิคสำหรับปัญหานี้คือการทำให้ SOAP ทำงานบน HTTP เท่านั้น
ถึงแม้ว่าในทางปฏิบัติแล้ว SOAP จะทางงานบน HTTP เป็นส่วนใหญ่แต่อย่างไรก็ตาม SOAP เองก็ใช้ความสามารถเพียงน้อยนิดของ HTTP โดยเฉพาะ SOAP นั้นจะเน้นการใช้ POST method เป็นหลักและมีเฮดเดอร์เดต้าอีกเล็กน้อย ในความเป็นจริงแล้ว HTTP เป็นโปรโตคอลที่ดีมากเนื่องจากมันมีความสามารถในการขยายสูงมากหรือสูงที่สุดในประวัติศาสตร์ของคอมพิวเตอร์ที่เคยมีมา อย่างไรก็ตามถ้าเราลองพิจรณาข้อดีของ SOAP คือมันใช้ XML !!!! ซึ่งถือเป็นมาตรฐานที่ใช้แลกเปลี่ยนข้อมูลมากที่สุด แต่นอกเหนือจากนั้นเราต่างยอมรับว่า SOAP เองไม่สามารถบรรลุในจุดประสงค์ที่มันถูกสร้างขึ้นมาเลย เนื่องจากถ้าเราพิจรณาลงไปในรายละเอียดแล้ว SOAP เองไม่ simple ไม่ได้เกี่ยวกับ object access, น่าเกลียด และที่สำคัญ มันไม่ใช่โปรโตคอล !!!!
WSDL Abuse
จุดประสงค์หลักของ Web Service Description Language (WSDL) คือการอธิบายความสามารถของเซอร์วิสที่เราเตรียมไว้เช่นมันต้องการพารามิเตอร์กี่ตัว ประเภทไหนบ้าง เมสเสจถูกเข้ารหัสด้วยมาตรฐานไหน ซึ่งถ้าเราสืบประวัติไปลึกๆแล้ว WSDL เป็นตัวแทนของบรรพบุรุษของมันที่มีลักษณะคล้ายๆกันเช่น Interface Definition Language (IDL) ที่เป็นหัวใจหลักของสถาปัตยกรรมแบบ distributed แบบเก่าเช่น CORBA , COM ดังนั้นหล้าที่หลักของ WSDL คือมันจะถูกโหลดไปไว้ที่ฝั่งไคล์แอนท์เพื่อนำไปสร้างสิ่งที่เรียกว่า “proxy” ที่ใช้สำหรับเป็นตัวแทนของเซอร์วิสที่เราให้บริการ การใช้งาน proxy เพื่อเป็นตัวหลางระหว่าไคล์แอนท์กับเซิร์ฟเวอร์นั้นเป็นแนวคิดที่ดีมากเพราะทำให้เราสามารถทำงานบนสภาพแวดล้อมที่ไม่ซับซ้อน แต่อย่างไรก็ตามปัญหาหลักคือระะดับของ coupling ระหว่างสองฝั่งจะสูงมาก และลองนึกภาพระบบขนาดใหญ่ที่มีเซอร์วิสเป็นจำนวนร้อยและมีไคล์แอนท์อีกเป็นร้อยจะทำให้เราพบกับปัญหาเรื่องของการทำ service-management และ versioning ดังภาพ
To ESB or Not to ESB
การประสานการทำงานของ line-of-business (LOB) ที่แตกต่างกันถือเป็นความสามารถหลักของ SOA ซึ่งหน้าที่ในการทำ integration นั้นถือเป็นหน้าที่หลักของส่วนที่เรียกว่า Enterprise Service Bus (ESB) ซึ่งตัวมันเองเป็นคอมโพเนนท์ที่ทำหน้าที่ integrate LOB เข้าด้วยกันด้วย common integration-pattern ทั้งหลายที่ได้รับความนิยมมากๆ
อย่างไรก็ตามสำหรับ ESB แล้วยังไม่มีมาตรฐานกลางระหว่างผู้ผลิตทั้งหมด จริงๆแล้ว ESB นั้นมีหล้าที่ทำงานพื้นฐานต่างเช่น protocol mapping, service chreographies, LOB Adapter, message distribution, transformations และ durability ซึ่งเราสามารถนำ ESB มาวางไว้เป็นแกนกลางของระบบเพื่อทำหน้าที่เชือมต่อเซอร์วิสต่างๆเข้าด้วยกัน
.png)
ในฐานะที่เราเป็น Architect เราย่อมอยากได้การทำงานของระบบที่อยู่บนพื้นฐานของภาพด้านบนแต่ในทางปฏิบติเราจะพบว่าการใช้สถาปัตยกรรมแบบนี้นั้นมีความเป็นไปได้ต่ำมากเนื่องจากข้อจำกัดทางเทคนิคมากมายเช่น management, performance และ scalability และอีกเรื่องที่สำคัญคือเราเอาส่วนของการ integration ทั้งหมดไปฝากไว้กับเทคโนโลยีปิด ซึ่งอาจทำให้มันกลายเป็นคอขวดของระบบในมุมของ agility, governance และ scalability ทำให้ทางออกสำหรับเรื่องนี้คือการใช้ ESB ออกมาตามรูปด้านล่าง
.png)
WS-* Madness
หลังจากคลื่นลูกแรกของ SOA specification ถูกสร้างขึ้น, เราพบว่าผู้ที่มีส่วนร่วมในการร่างได้พยายามใส่ความสามารถต่างๆที่ SOA ควรจะทำได้สำหรับการรองรับงานระดับ enterprise ไม่ว่าจะเป็นเรื่องของ security, reliable messaging และ transaction เข้้าไปใน SOAP/WSDL model. ผลที่ตามมาคือเราได้มาตรฐานย่อยออกมาอีกชุดใหญ่ๆเช่น WS-Security, WS-Trust, WS-ReliableMessaging ซึ่งเราเรียกกลุ่มของมตรฐานนี้ว่า WS-* ซึ่งถ้าเราลองนับดูรวมรวมกันแล้วจะพบว่ามี WS-* เกือบร้อยตัวที่มีให้ใช้งานอยู่ในขณะนี้ ผลที่ตามมาคือเรามันมีเยอะเกินไปจนทำให้สับสนได้เช่นบริษัทบางเจ้าก็มี WS-* หลายแบบแล้วแต่เครื่องมือที่เราจะใช้ บางครั้งก็มี WS-* สำหรับ Protocol เดียวกันหลายเวอร์ชั่น และการสร้างมารฐานคร่อมกันไปมาแบบนี้ทำให้การทำงานร่วมกันแบบข้ามแพลทฟอร์ม (Java กับ .NET) ทำได้แย่ลงไปอีกมากมายเนื่องจากต่างคนต่างมีมาตรฐานของตัวเองซึ่งมาตรฐานนั้นอาจไม่รองรับการทำงานข้ามไปมาระหว่าง Java และ .NET ที่แย่ไปกว่านั้นคือการที่เราไม่สามารถดึงภาษาเชิง scripting เข้ามาร่วมทำงานได้ด้วยดังภาพด้านล่าง
.png)
SOA Governance or SOA Dictatorship
ในองค์กรขนาดใหญ่นั้นการ implement SOA จำเป็นจะต้องพึ่งพากลุ่มคนที่ทำหน้าที่จัดการและบริหาร service ต่างๆเชนการทำ version, deploy, monitor โดยที่เราเรียคนกลุ่มนี้ว่า SOA-governance โดยที่เราก็มีมาตรฐานหรือแพลทฟอร์มสำหรับการทำงานของคนชุดนี้ที่เรียกว่า Universal Description, Discovery, and Integration (UDDI) platformอย่างไรก็บางในบางครั้งเราพบว่า SOA-governance platform ของเรานั้นมีข้อจำกัดมากเกินไปจนทำให้ไม่เหมาะสมกับการจัดการกับ Web services อันแสนจะซับซ้อน ปัจจัยหลักที่ทำให้ Governance Platform มีความสามารถไม่เพียงพอก็เพราะเราต้องยอมรับว่าเทคโนดลยีของ Web Services เปลี่ยนแปลงเร็วมากทำให้ SOA-governance platform เปลี่ยนตามได้ไม่ทัน เนื่องจาก traditional governance นั้นนิยมที่จะเก็บข้อมูล ข้อกำหนด ต่างๆไว้ที่ศูนย์กลางที่เดียวและควบคุมทุกอย่างจากที่นั่น ซึ่งโมเดลนี้เหมาะกับองค์กรขนาดไม่ใหญ่มาก เนื่องจากโมเดลนี้จะเต็มไปด้วยปัญหาเรื่อง interoperability, performance, scalability
.png)
- Leveraging RESTful services
- WS-* interoperability
- Federated ESB
- Lightweight SOA governance
- Embracing cloud computing
Embracing the Web: RESTful Services
เนื้อหาในส่วนที่แล้วเราได้เห็นข้อจำกัดมากมายของ traditional SOA ไม่ว่าจะเป็น XML, SOAP, WSDL และ WS-* อย่างที่เรารู้ว่า Web Services นั้นทำงานอยู่บน HTTP เป็นหลักแต่เนื่องจากเราสร้างมาตรฐานแปลกๆมากมายขึ้นมาควบคุมทำให้เราสร้างข้อจำกัดขึ้นมาครอบตัวเราเองส่งผลให้เราไม่สามารถทำงานได้เหมือน Web ทำให้ช่วงหลังๆ SOA เริ่มหันมาให้ความสนใจกับเทคโนโลยี่ที่เป็นมิตรกับ Web มากๆอย่างเช่น REST ซึ่งเราเริ่มเห็นแนวโน้มจากปัจจุบันได้แล้วว่า REST เริ่มเข้ามาเป็นทางเลือกของ SOAP/WS-* มากขึ้นโดยข้อดีของ REST ที่เราเห็นเด่นชัดคือระดับของ Interoperability และ Scalability สูงกว่า SOAP/WS-* มากๆ
ต่อไปคือคุณสมบัติสำคัญของ REST
- URI-addressable resources
- HTTP-based interactions
- Interoperability
- Stateless interactions
- Leveraging syndication formats
- Multiple resource representation
- Link-based relationships
- Scalability
- Caching
- Standard methods
WS-* Interoperability
เพื่อเป็นการย้ำอีกครั้งว่า WS-* นั้นไม่เคยได้รับสิ่งที่เราคาดหวังจากมันเลย โดยเฉพาะเรื่อง interoperability และ complexity ยังคงเป็นเรื่องที่ยังค้างคาใจอยู่เสมอในการนำ WS-* มาพัฒนา SOA ในองค์กรขนาดใหญ่ เมื่อเราต้องการแก้ปัญหาเรื่องของ Ineroperability ระหว่าง WS-* สิ่งที่ดีที่สุดนั้นคือการหันกลับไปพิจรณาความสามารถของ consumers ก่อนจะทำให้เราสามารถประมาณได้ว่าโปรโตคอลใดใน WS-* เหมาะที่สุดสำหรับ scenarios ที่เราต้องการทั้งหมด เพราะว่าในระบบที่ซับซ้อนมากๆมีสภาพแวดล้อมที่หลากหลายมากเราต้องเปิดให้ service endpoint ต่างๆรองรับความสารมารถของ WS-* ยกตัวอย่างเช่น เราต้องการ secure service ของเราเพื่อให้สามารถให้บริการ .NET, Sun Metro, Oracle WebLogic และ Ruby เราต้องเปิดสาม service endpoint ที่มี configuration ที่แตกต่างกันซึ่งจะได้ภาพดังนี้
.png)
Lightweight Federated ESBs
เรื่องต่อมาคือเรื่องการแก้ปัญหาของ Centralize ESB เนื่องจากเราไม่สามารถใช้ ESB ตัวเดียวเข้ามารับการทำงานทุกประเภทได้ไม่ว่าจะเป็น message routing, transformation และ workflow ทำให้เราต้องเจอปัญหาใหญ่เรื่องของ scalability ดังนั้นเราต้องแก้ปัญหานี้ด้วยการเปลี่ยน Pattern การใช้งานให้เป็น Federated ESB เพื่อใช้สร้าง ESB ที่มีความสามารถเรื่องการ scale สูงกว่าดังรูป
.png)
สำหรับ federated-ESB นั้นถูกนำมาใช้เพื่อแก้ไขข้อจำกัดของ centrlize-ESB ด้วยการแบ่ง infastructure ออกเป็น ESB ตัวเล็กๆที่สามารถ scale ได้ง่ายกว่าและถูก config แยกออกจากกัน ยกตัวอย่างเช่น เราอาจใช้ ESB สำหรับรับหน้าที่เกี่ยวกับ B2B เลย และ ESB อีกตัวรับหน้าที่เกี่ยวกับ Finacial แต่อย่างไรก็ตาม service ต่างๆที่เป็น service นั้นจะถูกรวมไว้ที่ศูนย์กลางไม่ว่าจะเป็น security, endpoint configuration
Lightweight Governance
ข้อจำกัดของ UDDI ในการสร้าง SOA ใน scale ที่ใหญ่มากทำให้เรามองหาทางออกที่ lightweight กว่าและทำงานได้หลากหลายกว่าสำหรับ SOA-governance model ใหม่ ซึ่งหนึ่งในทางเลือกที่ดีที่สุดคือ REST และ Web 2.0 ซึ่งวิธีการใหม่นี้จะเข้ามาช่วยเราในเรื่องของการลบความซับซ้อนต่างๆของ UDDI based และแทนมันเข้าไปด้วย HTTP, ATOM และ JSONหนึ่งใน SOA-Governanace แบบใหม่ที่กำลังเป็นที่นิยมคือ RESTful Service Repository โดยสิ่งต่างๆที่ Traditional SOA เตรียมไว้ให้ไม่ว่าจะเป็น service, endpoint, operation และ message จะถูกนำเสนอใหม่ผ่าน RESTful interface ซึ่งจะนำเสนอผ่านวิธีการแบบ Resource Oriented เช่น Atom และ Atom Publishing Protocol (APP)
.png)
โมเดลนี้จะดูเบากว่าและ flexible กว่าไม่ว่าจะเป็นเชิง runtime และ design time governance ยกตัวอย่างเช่นในจังหวะ runtime เราต้องการ resolve service endpoint ก็สามารถทำได้ด้วยการใช้ HTTP GET ผ่าน REST interface เท่านั้นทำให้เราไม่ถูกผูกติดอยู่กับ stub ทั้งหลายและมันยังช่วยเพิ่มระดับของ language interoperability ให้มากขึ้นอีกด้วย
Welcoming the Cloud
เรื่องต่อไปที่เราต้องให้ความสนใจคือเรื่องของ cloud computing ที่ถูกคาดหวังว่าจะถูกควบรวมเข้ามากับ SOA ในอนาคต ในรูปแบบของ cloud กับ no-premisees SOA
.png)
Cloud-based service bus—เราสามารถสร้าง ESB บน Cloud ได้ไหม? แน่นอนได้เรายังคงสามารถได้รับบริการต่าง message routing, publish-subscribe, transformations, และ service orchestration โดยมันจะถูกมองว่าเป็น no-premises ESB
Cloud-based security services—หลายปีที่ผ่านมาเราได้เห็น security services บน internet มากมายไม่ว่าจะเป็น Windows Live ID หรือFacebook Connect. ดังนั้นมันจึงเป็นเรื่องที่เป็นไปได้ที่เราจะไปอาศัยใช้กระบวนการเรื่อง security เหล่านั้นบนระบบของเราเพื่อลดภาระเรื่อง security เช่น authentication, identity representation, authorization, และ federation ผ่าน Internet Web-service APIs.
Cloud-based storage services— เรื่องของ storage เราได้เห็น Amazon S3 หรือ Azure DB แล้วมันคือ cloud infrastructures การข้ามไปใช้งาน cloud storage ทำให้เรามีระบบ storage ที่ flexible มากๆและสามรถทำงานได้หลาย platform ซึ่งเราเรียกมันว่า no-premises stoeage
สุดยอดมากๆครับพี่