Session 1 : Introduction to SOA

งานนำเสนอเรื่อง: "Session 1 : Introduction to SOA"— ใบสำเนางานนำเสนอ:

1 Session 1 : Introduction to SOA
Dr. Nipat Jongswat

2 หัวข้อนำเสนอ คำถามเกี่ยวกับ SOA วิวัฒนาการสู่ SOA หลักการของ SOA
หลักการของ Service หลักการของ Connection Technology ตอบคำถามเกี่ยวกับ SOA บทสรุป Dr. Nipat Jongswat

3 ลองค้นคำว่า “SOA” เราได้ยินคำว่า SOA มากขึ้น และมักได้ยินควบคู่กับคำว่า Web Service แต่ SOA กับ Web Service คืออะไร ดีอย่างไร หรือเป็นเพียง hype Dr. Nipat Jongswat

4 คำถามเกี่ยวกับ SOA SOA คืออะไร ทำไมต้องใช้ SOA
SOA กับ Web Services เหมือนกันหรือไม่ จำเป็นต้องใช้ SOA ควบคู่กับ Web Services หรือไม่ อื่น ๆ มีคำถามมากมายเกี่ยวกับ SOA โดย Session 1 นี้จะนำเสนอภาพรวมของ SOA และ Service และพยายามตอบคำถามต่าง ๆ Dr. Nipat Jongswat

5 วิวัฒนาการสู่ SOA Dr. Nipat Jongswat

6 Data Silos (1) หน่วยงานในองค์กรต่างมี Application และฐานข้อมูลของตนเอง
ทำงานร่วมกันไม่สะดวกเพราะโครงสร้างหรือเทคโนโลยีในระบบต่างกัน ไม่มี API ให้เรียกข้ามระบบ ไม่สามารถใช้ข้อมูลร่วมกันได้โดยตรง เกิด Data Silos หรือ Islands of Data แลกเปลี่ยนข้อมูลกันโดย Manual Rekey ข้อมูลของระบบอื่น ส่งไฟล์ผ่าน Magnetic Tape หรือ Floppy Disk ส่งไฟล์แบบ Electronic Transfer เกิดปัญหา Synchronization ระหว่างสำเนาของข้อมูล และแก้ไขแบบ Manual Application ของแต่ละหน่วยงานต่างก็เติบโตโดยไม่คำนึงถึง Application ของคนอื่น จึงเกิดลักษณะที่เรียกว่า Vertical หรือ departmental dedication แก่ระบบของตน ข้อมูลที่แลกเปลี่ยนกันจะ move one way คือขาดการ sync ระหว่างหลาย ๆ เวอร์ชันของ data item เดียวกัน หากพบ conflict ก็จะแก้ไขแบบ manual เช่น โทรศัพท์คุยกัน แต่ระบบแบบนี้ก็ยังใช้งานอยู่ในปัจจุบันเพราะได้ลงทุนไปแล้วและมีข้อดีที่ไม่ต้องสนใจว่าระบบต่าง ๆ จะมีเทคโนโลยีที่ incompatible กันหรือไม่หรือซับซ้อนเพียงใด ข้อเสียก็คือ labour intensive และ เกิด error ได้ง่าย เพราะค่อนข้าง manual Dr. Nipat Jongswat

7 Data Silos (2) Order Entry Warehousing Finance & Accounting
Shipping & Receiving Inventory Dr. Nipat Jongswat

8 ERP Application Suite (1)
Enterprise Resource Planning Application Suite เป็นที่นิยมตั้งแต่ปี 1980 เป็น Integrated System ที่ประกอบด้วยหลาย Module มีฐานข้อมูลกลางร่วมกัน ทำให้เกิด Enterprise-Wide Integration ซึ่งแต่ก่อนทำไม่ได้ ต้นทุนสูง ส่วนใหญ่เป็นค่า System Integration และ Customization Module ไม่ยืดหยุ่น แก้ไขยาก การปรับเปลี่ยนที่ส่วนหนึ่งมักกระทบส่วนอื่น External System ติดต่อด้วยยาก การผนวกรวม ERP Systems สืบเนื่องจากการผนวกรวมองค์กรทำได้ยาก เกิด Data Silos ใน Scale ที่ใหญ่ขึ้น แทนที่การเป็น separate system ในแต่ละหน่วยงานแบบ Data Silos แต่ซื้อ license ของ software packages ต่าง ๆ มาใช้ เช่น Finance, Manufacturing, HR ต้นทุนในการ implement ได้แก่ค่า license, hardware, software, professional service สำหรับการ integration และ customization ให้ทำงานเข้ากับระบบ legacy ที่มีอยู่เดิมได้ รวมทั้งต้นทุนด้าน internal staffing Centralized database จะควบคุม data และ transaction ในทุกหน่วยงาน ส่วน external system ที่ไม่เป็นส่วนหนึ่งของ ERP system นี้ (เช่น CRM หรือ e-commerce system ที่ต้องการ create หรือ modify data ใน ERP ได้แก่ ข้อมูล order, employee, inventory item) ก็จะต้องขึ้นกับ ERP database และ transaction system ด้วย ปัญหาเกี่ยวกับ integration จึงยังคงมีอยู่ Dr. Nipat Jongswat

9 ERP Application Suite (2)
Manufacturing Module Finance Module HR Module Inventory Module Order Entry Module Shipping Module Accounting Module Warehousing Module Database เป็นการทำ integration แบบ data integration คือ integrate ผ่าน database โดยตรง โดย appl หนึ่ง access database ของอีก appl โดยตรง Dr. Nipat Jongswat

10 แนวทางการทำ Integration แบบที่ 1
ใช้เทคโนโลยีที่ Common กันของแต่ละระบบเป็นพื้นฐาน OE CRM Windows Appl (DCOM) Customer Record Customer# OE CRM EJB Appl (RMI) Windows Appl (DCOM) Customer Record Customer# รูปซ้ายเป็นสองระบบที่มีส่วน Common กันมาก การ bridge ทำเพียงเล็กน้อย รูปขวาเป็นสองระบบที่มีส่วน Common กันน้อยลง คือเป็นระบบบนคนละ platform ดังนั้นจะต้องจัดการความต่างของ Communication protocol และ data representation (ใน platform ที่ต่างกัน รูปแบบของการ store และ transmit ข้อมูล เช่น numbers, character strings, compound data structures จะต่างกัน) ดังนั้นจะเห็นว่าเมื่อเพิ่มระบบที่จะต้องทำงานร่วมกัน ก็จะมีส่วน common น้อยลง (เช่น ถ้าเพิ่มเป็น 3 ระบบ ส่วน overlap ก็จะเล็กลง) และยิ่งเพิ่มภาระในการ bridge ระหว่างกัน เช่น อาจต้องเขียนโค้ดเฉพาะสำหรับทำ data transformation สำหรับแต่ละคู่ของระบบที่จะติดต่อกันเลย (cost เป็น n2) อาจใช้ภาษาโปรแกรมเดียวกัน ใช้ Common Comm Protocol ในการส่งผ่านข้อมูลระหว่างกัน การแปลงข้อมูลมีเล็กน้อย ต้องหา Compatible Comm Protocol ต้องตีความ Data Representation ยึดรูปแบบข้อมูลของฝั่งหนึ่งแล้วเขียนโค้ดที่อีกฝั่งเพื่อแปลงข้อมูล Dr. Nipat Jongswat

11 แนวทางการทำ Integration แบบที่ 2
ใช้เทคโนโลยีที่ไม่ขึ้นกับแต่ละระบบเป็นพื้นฐาน CRM Customer Record Customer# Standardized Interface Windows Appl Appl C Appl A Appl B แนวทางนี้ใช้การ adopt integration standard รูปซ้ายแสดงระบบ CRM ที่กำหนด interface ตามมาตรฐาน สำหรับให้ข้อมูลเกี่ยวกับลูกค้าแก่ระบบอื่น รูปขวาแสดงระบบ 3 ระบบซึ่งต่างก็กำหนด interface ตามมาตรฐาน ดังนั้นแต่ละระบบจะติดต่อกับระบบอื่นได้ผ่านทาง interface โดยทำการ transform ข้อมูลระหว่างรูปแบบของระบบเองกับรูปแบบมาตรฐานที่แลกเปลี่ยนผ่าน interface (cost เป็น n) ระบบกำหนด Interface ตามมาตรฐานเพื่อติดต่อกับระบบอื่นทั้งในและนอกองค์กร มาตรฐานไม่ขึ้นกับเทคโนโลยีของระบบใดโดยเฉพาะ ไม่ต้องการสมมติฐานว่าระบบมีส่วน Common กัน การแปลงข้อมูลทำระหว่างระบบกับมาตรฐานของ Interface Dr. Nipat Jongswat

12 EAI Package (1) Enterprise Application Integration Package ใช้แนวทางการทำ Integration แบบที่ 2 เป็นที่นิยมตั้งแต่ปี 1990 เป็น Communication and Data Translation Platform ระหว่าง ERP System กับ External System EAI Hub เป็น Broker Server Connector เป็น Adapter ที่ Vendor มีให้ หรือใช้ Toolkit พัฒนาเอง แปลงระหว่างข้อมูลของระบบกับข้อมูลในรูปแบบกลางที่กำหนด สนับสนุน Workflow ระหว่างระบบภายในองค์กรเท่านั้น มีปัญหาในการแปลงข้อมูลที่รูปแบบหรือความหมายต่างกัน ต้นทุนสูง ส่วนใหญ่เป็นค่า System Integration และ Professional Service EAI เป็น software data translator เท่านั้น ไม่ provide business functionality Connector จะ provide โดย vendor สำหรับ ERP และ CRM package ที่เป็นที่นิยม แต่ถ้าไม่มี ก็ต้องพัฒนาเองโดย vendor มี developer toolkit ให้ เมื่อ install connector จะระบุ table ต่าง ๆ ที่เกี่ยวข้องกับการ integrate ระบบ และกำหนด mapping ระหว่างข้อมูลในแต่ละระบบกับข้อมูลในรูปแบบกลางที่เรากำหนดขึ้น เช่น ถ้าจะเชื่อม Order ใน order entry module ของ ERP เข้ากับ CRM ก็จะกำหนดรูปแบบกลางของ Order จากนั้นกำหนด mapping จาก field ต่าง ๆ ใน table ใน ERP และใน CRM เข้ากับรูปแบบกลาง EAI รองรับการกำหนด workflow การไหลของข้อมูลจากระบบหนึ่งไปอีกระบบหนึ่งเป็น Business Process แต่เป็น process เฉพาะภายในองค์กร ไม่ข้ามองค์กร และ process จะค่อนข้าง static เปลี่ยนแปลงยาก EAI ประสบปัญหาเช่นเดียวกับการแปลงข้อมูลทั่วไป คือ map ได้ไม่ clean เช่น address ใน appl หนึ่งยาว 40 chars แต่ในอีก appl หนึ่งยาว 30 chars หรือ name ใน appl หนึ่งเป็น single field แต่อีก appl หนึ่งแยกเป็น first, middle, last การ parse name มาตัดคำจะเกิด error ง่าย EAI มีต้นทุนสูง ทำนองเดียวกับ ERP คือ license ไม่แพง แต่ค่า professional service แพง Dr. Nipat Jongswat

13 EAI Package (2) E-Commerce ERP CRM Connector EAI Hub
เป็นการทำ integration แบบ application integration คือ appl หนึ่ง ไม่ได้ access database ของอีก appl โดยตรง แต่ได้ data โดยขอจากตัว appl Dr. Nipat Jongswat

14 โจทย์การพัฒนาแบบ Application Integration
แก้ปัญหา Data Silos ใช้ Standardized API แทน Centralized Hub และ Connector สนับสนุนการพัฒนาแบบ Modular และ Incremental เพื่อการปรับเปลี่ยนองค์ประกอบใน Application ได้อย่างยืดหยุ่น ลดต้นทุน Consultant และการ Maintenance ระบบ สนับสนุน Business Process Integration ระหว่างองค์กร ไม่ใช่เพียง Batch Update Integration ERP และ EAI เป็น intra-company system ไม่ได้ถูกออกแบบเพื่อการเชื่อมโยงกับระบบภายนอกองค์กรอย่างแท้จริง จึงมีความต้องการในการทำ Application integration ที่มีประสิทธิภาพตามประเด็นเหล่านี้ หาก appl สร้างจาก component เล็ก ๆ ที่สามารถปรับเปลี่ยน ถอดออกหรือใส่ใหม่เข้าไปได้ จะทำให้ appl ค่อย ๆ โต การ evolve จะต้นทุนต่ำลง ความเสี่ยงลดลง SOA อาจจะไม่ใช่คำตอบสุดท้ายที่แก้ปัญหาทุกอย่างได้ แต่ก็ contribute ได้มาก SOA Dr. Nipat Jongswat

15 หลักการของ SOA Dr. Nipat Jongswat

16 SOA คืออะไร Software Architecture1 คือ
“The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution” Service-Oriented Architecture2 คือ “A software architecture within which all functions are defined as independent services with well-defined invokable interfaces, which can be called in defined sequences to form business processes” 1IEEE 2Introduction to Service-Oriented Architecture (SOA), Dr. Nipat Jongswat

17 พื้นฐานของ SOA ใช้แนวทางการทำ Integration แบบที่ 2
Service เป็น Building Block Software Module ที่ให้บริการฟังก์ชันการทำงานเฉพาะอย่าง กำหนด Interface มาตรฐานซึ่งมีลักษณะ Platform-, Language- และ OS-Independent ไว้เป็น Contract สนับสนุน Loose Coupling (highly cohesion) ระหว่าง Service กับซอฟต์แวร์ที่เรียกใช้ ใช้ Connection Technology ในการติดต่อ Service Web Services Technology ได้รับความนิยม ซอฟต์แวร์อื่นค้นหา Service ได้แบบ Dynamic Service ภายในและภายนอกองค์กรถูกเรียกใช้ต่อเนื่องกันตาม Business Process ได้ รองรับ Legacy Application ที่มีอยู่แล้ว พื้นฐานของ SOA คือเรื่องของ service กลไกการเรียกใช้ และเทคโนโลยีที่ใช้ติดต่อ service SOA กำหนดว่า service กับ application ที่เรียกใช้ service จะสัมพันธ์กันอย่างหลวมผ่าน service interface เช่น พัฒนาด้วยเทคโนโลยีหรืออยู่บนแพลตฟอร์มที่ต่างกันได้ ดังนั้นจึงสามารถทำงานร่วมกับ legacy appl ที่ลงทุนไปแล้วได้ นอกจากนี้ยังสามารถถอดเปลี่ยน service ได้ ถ้ายังให้บริการตามที่ต้องการอยู่ Dr. Nipat Jongswat

18 องค์ประกอบของ SOA Service Directory Service Consumer Service Finds
Publishes Binds Service Contract Dr. Nipat Jongswat

19 Loose Coupling หลักการออกแบบ Application ที่เน้นการปรับเข้ากับสิ่งที่เปลี่ยนแปลงไปได้โดยง่าย (Agility) ลดความขึ้นต่อกันระหว่างองค์ประกอบ มีความคล่องตัว เป็นเป้าหมายของ SOA มีหลายแง่มุม Dr. Nipat Jongswat

20 Loose Coupling ใน SOA (1)
แง่มุม Heterogeneous Technologies SOA ใช้ Standardized Interface แทนการใช้ Standardized Code อิสระในการพัฒนา Service ด้วยเทคโนโลยีใดก็ได้ ได้ Technology Decoupling โดยยอมเสีย Interface Coupling แง่มุม Data Exchange SOA ใช้รูปแบบข้อมูลที่อิสระกับเทคโนโลยี หลีกปัญหา Low-Level Data-Type Compatibility แง่มุม Published Schema Service Directory ช่วยในการตกลงเรื่องการให้บริการอย่าง Dynamic แง่มุม Delayed Binding Binding ทำตอนเรียกใช้ Service และยึด Standardized Interface การเปลี่ยนแปลง Service Implementation ไม่กระทบผู้ใช้ แง่ Heterogeneous Technology - Service จะ implement ด้วยภาษาใดบนแพลตฟอร์มใดก็ได้ แต่ในยุคก่อน ซอฟต์แวร์จะติดต่อกันได้ต้องมีอะไรบางอย่างเหมือนกัน จึง tightly coupled กว่า แง่ Data Exchange - การใช้ข้อมูลรูปแบบมาตรฐานที่ไม่ขึ้นกับแพลตฟอร์ม ทำให้ไม่มีปัญหาเรื่อง representation ของข้อมูลที่แลกเปลี่ยน แง่ Published Schema – Service Directory ทำให้ค้นหา Service ที่ต้องการติดต่อได้แบบ dynamic และช่วยให้ศึกษารูปแบบ Interface และรูปแบบข้อมูลเพื่อติดต่อได้อย่างสะดวก แทนการตกลงติดต่อกันแบบ manual แง่ Delayed Binding – การเปลี่ยนแปลง Service Implementation หรือเปลี่ยนเวอร์ชันไม่ได้ต้องการ Application ให้ compile ใหม่ เพราะ bind เมื่อเรียกใช้ Dr. Nipat Jongswat

21 Loose Coupling ใน SOA (2)
แง่มุม Fault Tolerance Connection Technology รองรับการติดต่อที่สามารถ Decouple Service ออกจาก Application ที่เรียกใช้ ลด Sensitivity ต่อ Latency และ Reliability ของ Service แง่มุม Data Semantics SOA สนับสนุนการสร้าง Adapter Service แทนการ Recode สองฝ่ายมี Data Semantics ที่ต่างกันได้ แง่มุม Applicability Service สามารถ Reuse ได้กับหลาย Application ในหลายประเภท แง่ Fault Tolerance – การรองรับ interaction ที่สามารถแยก appl ออกจาก service ได้ จะช่วยให้ appl ไม่ต้องยุ่งยากในกรณีมี service failure หรือ comm failure จึง loosely coupled กว่า แง่ Data Semantics – เนื่องจากยังไม่มีการ standardize semantics ของ data ที่แลกเปลี่ยนกันใน vertical domain การสร้าง adapter หรือ transformation service จะดีกว่าการต้องเขียนโค้ดใหม่ไปฝังไว้ที่ฝั่งหนึ่งเพื่อให้แปลงข้อมูลที่มาจากอีกฝั่งหนึ่ง ตัวอย่างเช่น currency converter แง่ Applicability – เนื่องจาก SOA ไม่ได้จำกัดว่า service และซอฟต์แวร์ที่เรียกใช้ต้องพัฒนาโดยเทคโนโลยีเดียวกัน ดังนั้นจึงใช้งานได้โดยซอฟต์แวร์ในหลายสภาพแวดล้อม ตราบใดที่ซอฟต์แวร์เหล่านั้นต้องการบริการแบบเดียวกัน Dr. Nipat Jongswat

22 หลักการของ Service Dr. Nipat Jongswat

23 Service คืออะไร Service เป็น Software Module ที่ให้บริการฟังก์ชันการทำงานเฉพาะอย่าง มีคุณลักษณะ เช่น ชื่อ ฟังก์ชันงานตามธุรกิจ ที่ติดต่อ นโยบายเกี่ยวกับ Security Dr. Nipat Jongswat

24 Service Granularity ระดับรายละเอียดของขอบเขตงานที่กำหนด Service Interface ขอบเขตเล็ก เช่น การดึงข้อมูล Customer Lookup Account Lookup ขอบเขตใหญ่ เช่น การทำงานตาม Business Process Order Processing Hotel Reservation Loan Processing Service ควรจะ Coarse-Grained ซอฟต์แวร์ที่พัฒนาขึ้นจะมี functionality หลายอย่าง ส่วนฟังก์ชันใดควรจะกำหนดเป็น service นั้น ขึ้นกับการออกแบบ แต่ service จะมีลักษณะเป็น high-level component ที่ encapsulate ฟังก์ชันงานหลัก ๆ ที่ให้บริการซ้ำ ๆ หรือให้บริการในหลายสถานการณ์ ดังนั้นจึงควรมองให้ coarse-grained กว่าระดับของ object และ software component Dr. Nipat Jongswat

25 ประเภทของ Service Intra-System Service Internal Service
ให้บริการภายในระบบหนึ่ง ๆ ซึ่ง Tightly-Coupled อาจไม่ถือเป็น Service ก็ได้ เพราะไม่ช่วยการทำงานข้ามระบบ Internal Service Behind-the-Firewall Service ให้บริการระหว่างระบบภายใน Trust Domain หนึ่ง ๆ ทั้ง Consumer และ Provider ควบคุมโดย Single Authority เช่น บริษัท หรือ ฝ่าย External Service Beyond-the-Firewall Service ให้บริการทั้งภายในและภายนอก Trust Domain หนึ่ง ๆ ทั้งแก่คู่ค้าและสาธารณะ Consumer และ Provider ควบคุมโดย Authority ที่ต่างกัน ต้องจัดการประเด็น Security, Business Agreement, Data Semantics Intra-System Service - ให้บริการภายในคอมพิวเตอร์เดียวกันหรือกลุ่มของคอมพิวเตอร์ในระบบเดียวกันที่ tightly-coupled หรือ homogeneous ดังนั้นนักคอมพิวเตอร์บางคน (Purist) จะไม่ถือว่าเป็น service เพราะไม่ได้ตั้งใจให้ interoperate กับ remote system ที่ใช้ภาษาหรือ OS ต่างกัน Internal Service - ให้บริการภายในหน่วยงานเดียวกัน มี heterogeneity ระหว่างระบบมากขึ้น External Service - ให้บริการข้ามองค์กร Dr. Nipat Jongswat

26 Service Collaboration
Orchestration Primary Service เรียกใช้ Service อื่น ๆ ตามลำดับ ลำดับการทำงานตาม Business Logic ฝังอยู่ใน Primary Service Business Interaction Coordination Mechanism จัดการลำดับการทำงานของ Long-Lived Service Coordination Mechanism อาจเป็น Business Process Execution Engine, Work Flow Engine หรือ Enterprise Service Bus Interception Intermediary Service รับ-ส่งข้อความระหว่างผู้ส่งกับ Service ปลายทางอย่าง Transparent Dr. Nipat Jongswat

27 Service Reuse and Aggregation
Customer Relation Service Upgrade Status Check Credit Member Register Consumer1 Place Order Approve Order Order Processing Service Consumer2 Service ถูก decompose เป็น smaller logic ตามฟังก์ชันงานและมีความสัมพันธ์กัน (cohesion) Service เมื่อถูกสร้างแล้ว สามารถใช้ซ้ำ ๆ ได้ โดยการเรียกใช้ของ consumer หลาย ๆ ราย หรือเป็นการใช้ซ้ำโดยการ aggregate เข้ามาเป็นส่วนหนึ่งของการทำงานของ service อื่น เช่น Consumer2 เรียกใช้ Order Processing Service เพื่อ Place Order แต่มีการไป reuse Customer Relation Service เพื่อเช็คว่า Consumer2 เป็นลูกค้าของบริษัทอยู่ก่อนหรือไม่ Dr. Nipat Jongswat

28 Service Encapsulates Logic
Process Step Service Subprocess Process SOA สนับสนุน service assembly ดังนั้นใน Business Process ของ appl สามารถสร้างขึ้นโดยการนำ service มาประกอบกัน และเนื่องจาก service มีหลาย granularity จากรูปจะแสดงการ capture การทำงาน 1 process step หรือ 1 subprocess มาเป็น 1 service ทำให้ business process ทำงานได้โดยการเรียกใช้ service อื่น ๆ หรือแม้กระทั่งสามารถ capture ทั้ง business process เป็น 1 service เลยก็ได้ Dr. Nipat Jongswat

29 Interface vs Application Implementation
Service New Implementation Service Interface Service Implementation สามารถเปลี่ยน Implementation โดยไม่กระทบ Service Interface Dr. Nipat Jongswat

30 Write Once, Access from Anywhere
Service Consumer Service .NET Platform Java Platform Dr. Nipat Jongswat

31 Application Architecture ที่เปลี่ยนไป (1)
Tax Rate Data Tax Algorithms Shipping Algorithms Retail Application Modules Linkage Editor Integrated Application Shipping Rate Source Shipping Rate Data CD-ROM Build Time Configuration Time Run Time Traditional Approach ตัวอย่าง Retail Application มีการคำนวณ sales tax และจัดการ shipping ซึ่ง rate หรือวิธีการคำนวณอาจเปลี่ยนบ่อย ใน traditional approach จะ license ทั้งสอง package นี้มา integrate เข้ากับ retail application และ subscribe update โดย vendor จะให้ update มาเป็น CD หรือ download จาก Internet ได้ เป็น batch mode เรื่อง sales tax และ shipping จะไม่ใช่ core business activity ของเรา และน่าจะดีถ้ามีคนอื่นคอยดูแลให้ up-to-date เสมอ ถ้ารับบริการทั้งสองอย่างนี้น่าจะดี Dr. Nipat Jongswat

32 Application Architecture ที่เปลี่ยนไป (2)
Tax Calculation Service Shipping Rate Service Retail Application Modules Linkage Editor Integrated Application Build Time Run Time Service-Based Approach ถ้า sales tax และ shipping เป็นแบบ service แทน rate ที่เปลี่ยนแปลงจะมาแบบ real-time และ algorithm จะคำนวณที่ site ของ vendor แทนที่จะเป็นที่ site ของ appl กล่าวคือทั้ง data และ algorithm จะไม่เป็นส่วนหนึ่งของ local infrastructure ของ appl และการ integrate change ต่าง ๆ ในส่วนของ sales tax และ shipping จะถูก defer ไปอยู่ตอน run-time ทำให้ appl ไม่ต้องกังวลเกี่ยวกับ code module ใหม่ ๆ หรือ DB update เลย (future proofed) Dr. Nipat Jongswat

33 สร้าง Service ได้หลายแบบ
New Service Service Consumer Wrapped Legacy Interface Proxy Composite Service Service Interface Service Implementation Dr. Nipat Jongswat

34 การออกแบบ Service ออกแบบ Interface ออกแบบ Implementation
ออกแบบข้อมูลที่แลกเปลี่ยน ออกแบบ Service Contract ออกแบบความสัมพันธ์กับ Service อื่น Dr. Nipat Jongswat

35 หลักการของ Connection Technology
Dr. Nipat Jongswat

36 Connection Technology คืออะไร
เทคโนโลยีเพื่อการเชื่อมต่อและสื่อสารระหว่าง Disparate Systems วิวัฒนาการ CORBA (Common Object Request Broker Architecture) Platform-, Language- และ OS-independent ต้องใช้ CORBA Protocol (IIOP) และ Application ส่วนใหญ่เป็น OO ซับซ้อนและต้นทุนสูง DCOM (Distributed Component Object Model) เชื่อมต่อ Object ใน Windows Application บนคอมพิวเตอร์ต่างเครื่อง Application พัฒนาด้วยหลายภาษาได้ RMI (Remote Method Invocation) เชื่อมต่อ Object บนคอมพิวเตอร์ต่างเครื่องซึ่งพัฒนาด้วยภาษา Java Object อยู่บนหลายแพลตฟอร์มได้ อาศัยหลักการของ Service ที่ให้บริการผ่าน Interface CORBA เป็น software agent ที่ vendor-independent จริง ๆ ใช้ในองค์กรใหญ่ มีเงิน มีระบบใหญ่ ๆ แต่เป็น closely-controlled application development environment ใช้ binary data protocol DCOM พัฒนามาจาก COM ซึ่ง link object ใน Windows-based appl บน Windows OS บนเครื่องคอมพิวเตอร์เดียวกัน DCOM เป็น Distributed COM ที่ link object บนต่างเครื่องได้ แต่เฉพาะโลกของ Microsoft RMI link object เฉพาะที่เขียนด้วยจาวา เทคโนโลยีเหล่านี้ต่างรองรับหลักการให้บริการของ Service ผ่าน Interface มาตรฐานเช่นกัน ดังนั้นเรื่องของ Service จึงไม่ใช่ของใหม่ เพียงแต่เทคโนโลยีเหล่านี้สามารถทำให้เกิด loose coupling ในระดับหนึ่ง แต่ยังไม่เต็มที่นัก Dr. Nipat Jongswat

37 Web Services เป็น Connection Technology ที่ได้รับความนิยม
ช่วย SOA ให้บรรลุเป้าหมาย Loose Coupling ได้ดี ใช้หลายมาตรฐานที่เกี่ยวกับการสื่อสารและเป็นที่แพร่หลายแล้ว ได้แก่ HTTP, XML (แก้ปัญหา CORBA) Platform-Independent เพราะ Service Interface สามารถแยกจาก Service Implementation (แก้ปัญหา DCOM) Language-Independent เพราะ Service Interface สามารถแยกจาก Service Implementation (แก้ปัญหา RMI) Web Services เป็น evolution ของ connection technology เก่า ๆ มากกว่าเป็น revolution เพราะพอดีว่า เทคโนโลยีหลาย ๆ อย่างเป็นที่ยอมรับแล้วและใช้อย่างแพร่หลายแล้ว แล้ว Web Services ก็ไปนำเทคโนโลยีเหล่านี้มาใช้ร่วมกัน Microsoft ก็เปลี่ยนมาสู่ยุค .NET โดย component ติดต่อกันด้วย binary (non-XML) version ของ SOAP แทนการใช้ DCOM IBM product เช่น Lotus Note, DB2 ก็ adopt Web service interface ในโลกของ Java ก็จะใช้ Web service แทนการใช้ RMI โดยตรง CORBA messaging ก็จะถูกแทนที่ด้วย Web service ในบางส่วน Web services จะไม่ได้แทนที่ connection technology ที่องค์กรใช้อยู่เดิม แต่จะมาทำงานร่วมด้วย Dr. Nipat Jongswat

38 Synchronous Messaging (1)
Consumer ส่ง Request แล้วหยุดรอ Response พัฒนาง่าย ไม่ต้อง Correlate Request กับ Response ใช้กับการ Query และ Update ง่าย ๆ เช่น Stock Quote Weather Report Delivery Tracking ไม่เหมาะกับ Service ที่ต้องการ Decouple Request จาก Response Dr. Nipat Jongswat

39 Synchronous Messaging (2)
Consumer Service 1 Service 2 Order Gift 1 Sell Gift 1 Order Gift 2 Time Sell Gift 2 Dr. Nipat Jongswat

40 Asynchronous Messaging (1)
Consumer ส่ง Request แล้วไม่หยุดรอ Response อาจจะได้รับ Acknowledgement Service ประมวลผลในภายหลัง และส่ง Response กลับ Consumer ต้อง Correlate Response กับ Request สอดคล้องกับการเรียกใช้ Service ใน Real-World Business Process Dr. Nipat Jongswat

41 Asynchronous Messaging (2)
Consumer Service 1 Service 2 Order Gift 1 Order Gift 2 Ack Order 1 Ack Order 2 Time Ship Gift 2 Ship Gift 1 Dr. Nipat Jongswat

42 Asynchronous Messaging (3)
Message Queuing ช่วยจัดการเรื่อง Load และ Failure ของ Service Sending Service A Messaging Server B Queue 1 Message Acknowledgement 2 Internet or Intranet Message 3 4 Acknowledgement Asynchronous messaging โดยตัวมันเองยังไม่พอสำหรับการทำงาน Message queue จะมาช่วยเสริมให้เป็นประโยชน์มากขึ้น โดยเป็นเหมือน buffer คอยประสานงานกันเพื่อส่งต่อข้อความสองฝั่ง ถ้ามี load มาก receiving service สามารถทยอยมารับ request ตามกำลังที่รับได้ หรือถ้าฝั่งใดฝั่งหนึ่ง fail ข้อความก็จะมารออยู่ใน queue ก่อนได้ Messaging Server C Queue Receiving Service D Poll 5 6 Message Dr. Nipat Jongswat

43 RPC Style มักใช้ติดต่อ Service แบบ Synchronous Request/Response (แต่อาจเป็น Asynchronous และอาจไม่มี Response) Message ระบุชนิดข้อมูลทั้งแบบพื้นฐาน และแบบ Compound ที่แลกเปลี่ยนกันในการเรียกใช้ฟังก์ชันของ Service อาจจะ Fine-Grained เกินไปสำหรับการติดต่อในธุรกิจจริง RPC style เป็น default ใน Java-based Web services Dr. Nipat Jongswat

44 Document Style ใช้ติดต่อ Service โดยส่ง Self-Contained Document ให้
เหมาะกับการติดต่อในเชิงธุรกิจ เช่น ส่งทั้ง Purchase Order เหมาะกับการติดต่อแบบ Asynchronous (แต่เป็น Synchronous ก็ได้) Service ใช้ข้อมูลเท่าที่จำเป็นใน Document Service ส่งต่อ Document ให้ Service อื่นได้ จำนวน Message สำหรับการทำงานที่ซับซ้อน จะน้อยลงกว่าแบบ RPC Document style เป็น default ใน .NET Web service Dr. Nipat Jongswat

45 ตอบคำถาม Dr. Nipat Jongswat

46 Q1: ถ้าไม่ใช้ Web Services จะทำ SOA ได้หรือไม่ A1: เทคโนโลยี เช่น CORBA และ RMI อาศัยหลักการของ Service และการ Publish Standard Interface รวมทั้งสามารถทำ Service Aggregation ได้ แต่เนื่องจากมี Technology Coupling จึงตอบสนองหลักการของ SOA ได้ระดับหนึ่งเท่านั้น Q2: อะไรที่ต้องมีใน Application จึงจะถือว่าเป็นไปตาม SOA ถ้าไม่มีจะถือว่าไม่เป็น A2: อย่างน้อยต้องมี Service เพราะเป็น Building Block อย่างไรก็ตาม การออกแบบ Service ต้องคำนึงถึงหลักการต่าง ๆ ของ SOA ด้วย เช่น การมี Loose Coupling การมี Granularity ที่เหมาะสมกับการให้บริการ Dr. Nipat Jongswat

47 Q3: ถ้า Application เรียกใช้เพียง 1 Service จะถือว่าเป็น SOA แล้วหรือไม่ A3: ยังไม่พบข้อกำหนดเกี่ยวกับจำนวน Service ที่ใช้ กับความเป็น SOA ดังนั้นน่าจะถือว่าเป็น SOA ได้ แต่สิ่งที่สำคัญกว่าจำนวน ก็คือการสร้าง Application และ Service นั้นได้คำนึงถึงหลักการของ SOA แล้วหรือไม่ Q4: Service จำเป็นต้อง Reuse โดยผู้อื่นหรือไม่ ถ้าสร้างไว้ใช้เอง จะถือว่าเป็นไปตามหลักการของ SOA หรือไม่ A4: การกำหนด Service สามารถใช้ Reusability เป็นแนวทางได้ คือหากฟังก์ชันหนึ่งถูกใช้ซ้ำ ๆ โดยหลาย Application เราก็จะกำหนดเป็น Service ขึ้นมา แต่ Reusability ไม่ใช่สาเหตุเดียวในการสร้าง Service สมมติว่ามีเพียง Application เดียวที่ใช้ฟังก์ชันหนึ่ง แต่ฟังก์ชันนั้นมีการเปลี่ยนแปลงบ่อยมาก หรือมีปัญหาเรื่อง Heterogeneous Technology ในการติดต่อใช้งาน การสร้างฟังก์ชันนั้นเป็น Service ก็น่าจะเหมาะสม เพื่อช่วย Decouple ส่วน Interface ของการใช้งานฟังก์ชันออกจากส่วน Implementation Dr. Nipat Jongswat

48 Q5: Service, Object และ Software Component เหมือนหรือต่างกันอย่างไร
A5: หลักการของ Service คล้ายคลึงกับหลักการของ Object และ Software Component ในแง่ที่การติดต่อส่วนประกอบในระบบทำผ่าน API ที่แยกออกจากส่วน Implementation และสนับสนุน Reuse แต่ก็มีความแตกต่างกัน แง่มุม Granularity: Object จะ Fine-Grained โดยเป็นหน่วยเล็ก ๆ ในระดับโค้ด ส่วน Software Component จะ Abstract กว่า Object โดยเป็น Packaging ของ Object ภายใน Service จะ Coarse-Grained กว่า และเป็นส่วนประกอบที่อยู่ระดับบนกว่า แง่มุม Reuse: Object และ Software Component ทำให้เกิดการ Reuse Code แต่จะ Tightly-Coupled เพราะ Application ต่อ ๆ ไปที่จะพัฒนาด้วย Object หรือ Software Component นี้ จะพัฒนาด้วยภาษาเดิมหรือบนแพลตฟอร์มเดิม Service ไม่ต้องการ Port Source Code หรือใช้ Library ในการสร้าง Application แต่ Code ของ Service จะ Execute ในที่ที่มันอยู่ *** Service ไม่ใช่ library เพราะมีความสมบูรณ์และมีอิสระในการทำงานโดยตัวมันเอง ถ้าเป็น library มันจะไม่ทำงานโดยตัวมันเอง จะมีคนอื่นมาเอาไปใช้ Dr. Nipat Jongswat

49 Q6: Service จะมาแทนที่ Object และ Software Component หรือไม่ A6: หลักการของ Service เกี่ยวกับการมี Interface มาตรฐาน ไม่ได้เกี่ยวกับ Implementation ดังนั้น Service จะไม่ได้มาแทนที่ Object แต่สามารถใช้ Object เป็นเทคโนโลยีในการพัฒนาส่วน Implementation ของ Service ได้ เช่นเดียวกับแบบ Non-OO อย่างไรก็ตาม ในการใช้ OO ในการพัฒนา หากทำเพียงแค่สร้าง Wrapper ครอบ Fine-Grained Object แล้วเรียกว่า Service ก็จะไม่เหมาะสม Q7: ควรเริ่มทำ SOA เมื่อไร และอย่างไร A7: องค์กรสามารถเริ่มปรับตัวเพื่อทำ SOA ได้เลย ขณะนี้เทคโนโลยีมาตรฐานพื้นฐานเริ่มนิ่งแล้ว แต่ก็ยังมีอีกหลายส่วนที่ยังพัฒนาอยู่ การทำ SOA ในช่วงที่แนวคิดนี้ยังค่อนข้างใหม่อยู่ จะทำให้องค์กรมีความได้เปรียบ แต่ต่อไปเมื่อแนวคิดนี้เป็นที่แพร่หลายแล้วและองค์กรไม่ทำ SOA ก็จะกลายเป็นเสียประโยชน์ไป การเริ่มต้นอาจเริ่มจากการทำ Pilot Project เล็ก ๆ โดยทำเป็น Intra-System Service หรือ Internal Service แล้วค่อยขยายเป็น Internal Service ที่มีขอบเขตใหญ่ขึ้น หรือแม้กระทั่งให้บริการ External Service Dr. Nipat Jongswat

50 บทสรุป Dr. Nipat Jongswat

51 SOA ในองค์กร (1) เน้นการรวมระบบซอฟต์แวร์เข้าด้วยกันแบบองค์รวม โดยกำหนด Service และ Collaboration ระหว่างกัน ไม่ใช่เป็นเพียงการเรียกใช้ฟังก์ชันโดยอิสระจากเทคโนโลยีเท่านั้น แต่นำไปสู่การพัฒนา Long-Running Business Process ข้ามองค์กร มีเทคโนโลยีในการพัฒนา SOA หลากหลายแบบที่ควรเลือกให้เหมาะสม Dr. Nipat Jongswat

52 SOA ในองค์กร (2) External System Service New CRM Application Partner
Internet SOA Infrastructure Discovery Security Dev Tools Standards Post GL Check Out Get Product Info Reverse GL Vendor จะ provide infrastructure สำหรับการ develop ให้ระบบ legacy สามารถ expose เป็น service ได้ และให้ทั้ง Application ที่เป็น service และไม่เป็น service ทำงานร่วมกันได้ รวมทั้งมีการจัดการสภาพแวดล้อมการทำงานให้ด้วย GL Legacy System Inventory Legacy System Dr. Nipat Jongswat

53 ประโยชน์ของ SOA Application มีความยืดหยุ่น ปรับเปลี่ยนง่าย เพราะอิงมาตรฐาน และถอดเปลี่ยน Service ได้ สามารถพัฒนา Application ได้เร็ว โดยการประกอบ Service เข้าด้วยกัน ลดต้นทุนและความเสี่ยง ไม่ต้องพัฒนาและบำรุงรักษาทุกส่วนของ Application เอง สามารถนำระบบที่มีอยู่แล้วมาใช้ร่วมกันแบบองค์รวมได้ การลงทุนไม่สูญเปล่า Dr. Nipat Jongswat

54 เอกสารอ้างอิง Debu Panda, “An Introduction to Service-Oriented Architecture from a Java Developer’s Perspective”, 26 January Available: Jagadish Chatarji, “Introduction to Service-Oriented Architecture (SOA)”, 13 October Available: Doug Kaye, “Loosely Coupled: The Missing Pieces of Web Services”, RDS Press, 2003. Douglas K. Barry, “Web Services and Service-Oriented Architectures: The Savvy Manager’s Guide”, Morgan Kaufmann Publishers, 2003. Dr. Nipat Jongswat