Transcript Session 1: Introduction to SOA

Session 1 : Introduction to SOA
Dr. Nipat Jongswat
หัวข้อนำเสนอ
•
•
•
•
•
•
•
คำถำมเกี่ยวกับ SOA
วิวฒ
ั นำกำรสู่ SOA
หลักกำรของ SOA
หลักกำรของ Service
หลักกำรของ Connection Technology
ตอบคำถำมเกี่ยวกับ SOA
บทสรุป
Dr. Nipat Jongswat
ลองค้นคำว่ำ “SOA”
Dr. Nipat Jongswat
คำถำมเกี่ยวกับ SOA
•
•
•
•
•
•
•
SOA คืออะไร
ทำไมต้ องใช้ SOA
ใช้ SOA เมื่อไร ไม่ใช้ ได้ หรื อไม่
พัฒนำ SOA อย่ำงไร
SOA กับ Web Services เหมือนกันหรื อไม่
จำเป็ นต้ องใช้ SOA ควบคูก่ บั Web Services หรื อไม่
อื่น ๆ
Dr. Nipat Jongswat
วิวฒั นำกำรสู่ SOA
Dr. Nipat Jongswat
Data Silos (1)
• หน่วยงำนในองค์กรต่ำงมี Application และฐำนข้ อมูลของตนเอง
• ทำงำนร่วมกันไม่สะดวกเพรำะโครงสร้ ำงหรื อเทคโนโลยีในระบบต่ำงกัน
– ไม่มี API ให้ เรี ยกข้ ำมระบบ
– ไม่สำมำรถใช้ ข้อมูลร่วมกันได้ โดยตรง
• เกิด Data Silos หรื อ Islands of Data
• แลกเปลี่ยนข้ อมูลกันโดย
– Manual Rekey ข้ อมูลของระบบอื่น
– ส่งไฟล์ผ่ำน Magnetic Tape หรื อ Floppy Disk
– ส่งไฟล์แบบ Electronic Transfer
• เกิดปั ญหำ Synchronization ระหว่ำงสำเนำของข้ อมูล และแก้ ไขแบบ
Manual
Dr. Nipat Jongswat
Data Silos (2)
Order Entry
Warehousing
Finance &
Accounting
Shipping &
Receiving
Inventory
Dr. Nipat Jongswat
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 ที่ใหญ่ขึ ้น
Dr. Nipat Jongswat
ERP Application Suite (2)
HR
Module
Finance
Module
Manufacturing
Module
Order Entry
Module
Database
Inventory
Module
Warehousing
Module
Accounting
Module
Shipping
Module
Dr. Nipat Jongswat
แนวทำงกำรทำ Integration แบบที่ 1
• ใช้ เทคโนโลยีที่ Common กันของแต่ละระบบเป็ นพื ้นฐำน
Customer#
Windows
Appl
(DCOM)
OE
CRM
Customer#
Windows
Appl
EJB Appl
(DCOM)
(RMI)
Customer Record
OE
CRM
(DCOM)
Customer Record
้
อาจใชภาษาโปรแกรมเดี
ยวกัน
ต ้องหา Compatible Comm Protocol
ใช ้ Common Comm Protocol ในการสง่ ผ่าน
ข ้อมูลระหว่างกัน
ต ้องตีความ Data Representation
การแปลงข ้อมูลมีเล็กน ้อย
Windows
Appl
ยึดรูปแบบข ้อมูลของฝั่ งหนึง่ แล ้วเขียนโค ้ดทีอ
่ ก
ี
ฝั่ งเพือ
่ แปลงข ้อมูล
Dr. Nipat Jongswat
แนวทำงกำรทำ Integration แบบที่ 2
• ใช้ เทคโนโลยีที่ไม่ขึ ้นกับแต่ละระบบเป็ นพื ้นฐำน
Windows
Appl
Customer#
Appl B
Appl A
CRM
Standardized
Interface
Customer Record
Appl C
ระบบกาหนด Interface ตามมาตรฐานเพือ
่
ติดต่อกับระบบอืน
่ ทัง้ ในและนอกองค์กร
ไม่ต ้องการสมมติฐานว่าระบบมีสว่ น Common
กัน
มาตรฐานไม่ขน
ึ้ กับเทคโนโลยีของระบบใด
โดยเฉพาะ
การแปลงข ้อมูลทาระหว่างระบบกับมาตรฐาน
ของ Interface
Dr. Nipat Jongswat
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
Dr. Nipat Jongswat
EAI Package (2)
CRM
ERP
Connector
Connector
EAI Hub
Dr. Nipat Jongswat
E-Commerce
Connector
โจทย์กำรพัฒนำแบบ Application Integration
• แก้ ปัญหำ Data Silos
• ใช้ Standardized API แทน Centralized Hub และ Connector
• สนับสนุนกำรพัฒนำแบบ Modular และ Incremental เพื่อกำร
ปรับเปลี่ยนองค์ประกอบใน Application ได้ อย่ำงยืดหยุน่
• ลดต้ นทุน Consultant และกำร Maintenance ระบบ
• สนับสนุน Business Process Integration ระหว่ำงองค์กร ไม่ใช่เพียง
Batch Update Integration
Dr. Nipat Jongswat
หลักกำรของ SOA
Dr. Nipat Jongswat
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
1471-2000
2Introduction to Service-Oriented Architecture (SOA),
http://www.devshed.com/c/a/Web-Services/Introduction-to-ServiceOriented-Architecture-SOA/
Dr. Nipat Jongswat
พื้นฐำนของ 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 ที่มีอยู่แล้ ว
Dr. Nipat Jongswat
องค์ประกอบของ SOA
Service
Directory
Finds
Service
Consumer
Publishes
Service
Binds
Dr. Nipat Jongswat
Service
Contract
Loose Coupling
• หลักกำรออกแบบ Application ที่เน้นกำรปรับเข้ำกับสิ่งที่
เปลี่ยนแปลงไปได้โดยง่ำย (Agility)
– ลดควำมขึ้นต่อกันระหว่ำงองค์ประกอบ มีควำมคล่องตัว
• เป็นเป้ำหมำยของ SOA
• มีหลำยแง่มุม
Dr. Nipat Jongswat
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 ไม่กระทบผู้ใช้
Dr. Nipat Jongswat
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 ในหลำยประเภท
Dr. Nipat Jongswat
หลักกำรของ Service
Dr. Nipat Jongswat
Service คืออะไร
• Service เป็ น Software Module ที่ให้ บริกำรฟั งก์ชนั กำร
ทำงำนเฉพำะอย่ำง
• มีคณ
ุ ลักษณะ เช่น
–
–
–
–
ชื่อ
ฟั งก์ชนั งำนตำมธุรกิจ
ที่ติดต่อ
นโยบำยเกี่ยวกับ Security
Dr. Nipat Jongswat
Service Granularity
• ระดับรำยละเอียดของขอบเขตงำนที่กำหนด Service Interface
• ขอบเขตเล็ก เช่น กำรดึงข้ อมูล
– Customer Lookup
– Account Lookup
• ขอบเขตใหญ่ เช่น กำรทำงำนตำม Business Process
– Order Processing
– Hotel Reservation
– Loan Processing
• Service ควรจะ Coarse-Grained
Dr. Nipat Jongswat
ประเภทของ Service
• Intra-System 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
Dr. Nipat Jongswat
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
Service Reuse and Aggregation
Consumer1
Upgrade
Status
Consumer2
Check
Member
Place Order
Order Processing
Service
Approve
Order
Dr. Nipat Jongswat
Customer
Relation Service
Check
Credit
Register
Member
Service Encapsulates Logic
Process
Step
Service
Service
Subprocess
Process
Service
Dr. Nipat Jongswat
Interface vs Application Implementation
Service
New
Implementation
สามารถเปลีย
่ น Implementation
โดยไม่กระทบ Service Interface
Dr. Nipat Jongswat
Service
Interface
Service
Implementation
Write Once, Access from
Anywhere
Service Consumer
Service
.NET Platform
Java Platform
Dr. Nipat Jongswat
Application Architecture ที่เปลี่ยนไป
(1)
• Traditional Approach
Tax
Algorithms
Shipping
Algorithms
CD-ROM
Integrated
Application
Linkage
Editor
Retail
Application
Modules
Build Time
Tax
Rate
Data
Shipping
Rate
Source
Configuration Time
Dr. Nipat Jongswat
Shipping
Rate
Data
Run Time
Application Architecture ที่เปลี่ยนไป
(2)
• Service-Based Approach
Linkage
Editor
Retail
Application
Modules
Tax
Calculation
Service
Integrated
Application
Shipping
Rate
Service
Run Time
Build Time
Dr. Nipat Jongswat
สร้ำง Service ได้หลำยแบบ
New Service
Service Consumer
Wrapped
Legacy
Interface Proxy
Composite
Service
Service
Interface
Service
Implementation
Dr. Nipat Jongswat
กำรออกแบบ Service
• ออกแบบ Interface
• ออกแบบ Implementation
• ออกแบบข้ อมูลที่แลกเปลี่ยน
• ออกแบบ Service Contract
• ออกแบบควำมสัมพันธ์กบั Service อื่น
Dr. Nipat Jongswat
หลักกำรของ Connection
Technology
Dr. Nipat Jongswat
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 ที่ให้ บริDr.กำรผ่
ำน Interface
Nipat Jongswat
Web Services
• เป็ น Connection Technology ที่ได้ รับควำมนิยม
• ช่วย SOA ให้ บรรลุเป้ำหมำย Loose Coupling ได้ ดี
– ใช้ หลำยมำตรฐำนที่เกี่ยวกับกำรสื่อสำรและเป็ นที่แพร่หลำยแล้ ว ได้ แก่
HTTP, XML (แก้ ปัญหำ CORBA)
– Platform-Independent เพรำะ Service Interface
สำมำรถแยกจำก Service Implementation (แก้ ปัญหำ
DCOM)
– Language-Independent เพรำะ Service Interface
สำมำรถแยกจำก Service Implementation (แก้ ปัญหำ
RMI)
Dr. Nipat Jongswat
Synchronous Messaging (1)
• Consumer ส่ง Request แล้ วหยุดรอ Response
– พัฒนำง่ำย ไม่ต้อง Correlate Request กับ Response
• ใช้ กบั กำร Query และ Update ง่ำย ๆ เช่น
– Stock Quote
– Weather Report
– Delivery Tracking
• ไม่เหมำะกับ Service ที่ต้องกำร Decouple Request
จำก Response
Dr. Nipat Jongswat
Synchronous Messaging (2)
Consumer
Service 1
Dr. Nipat Jongswat
Service 2
Asynchronous Messaging (1)
• Consumer ส่ง Request แล้ วไม่หยุดรอ Response
– อำจจะได้ รับ Acknowledgement
• Service ประมวลผลในภำยหลัง และส่ง Response กลับ
• Consumer ต้ อง Correlate Response กับ
Request
• สอดคล้ องกับกำรเรี ยกใช้ Service ใน Real-World
Business Process
Dr. Nipat Jongswat
Asynchronous Messaging (2)
Consumer
Service 1
Dr. Nipat Jongswat
Service 2
Asynchronous Messaging (3)
• Message Queuing ช่วยจัดกำรเรื่ อง Load และ Failure
ของ Service
1
Sending
Service A
Acknowledgement
Message
4
Messaging
Server C
Queue
Internet or
Intranet
Poll
6
Messaging
Server B
Message
Message
Dr. Nipat Jongswat
2
Queue
3
Acknowledgement
5
Receiving
Service D
RPC Style
• มักใช้ ติดต่อ Service แบบ Synchronous
Request/Response (แต่อำจเป็ น Asynchronous
และอำจไม่มี Response)
• Message ระบุชนิดข้ อมูลทังแบบพื
้
้นฐำน และแบบ
Compound ที่แลกเปลี่ยนกันในกำรเรี ยกใช้ ฟังก์ชนั ของ
Service
• อำจจะ Fine-Grained เกินไปสำหรับกำรติดต่อในธุรกิจจริง
Dr. Nipat Jongswat
Document Style
• ใช้ ติดต่อ Service โดยส่ง Self-Contained
Document ให้
• เหมำะกับกำรติดต่อในเชิงธุรกิจ เช่น ส่งทัง้ Purchase Order
• เหมำะกับกำรติดต่อแบบ Asynchronous (แต่เป็ น
Synchronous ก็ได้ )
• Service ใช้ ข้อมูลเท่ำที่จำเป็ นใน Document
• Service ส่งต่อ Document ให้ Service อื่นได้
• จำนวน Message สำหรับกำรทำงำนที่ซบั ซ้ อน จะน้ อยลงกว่ำแบบ
RPC
Dr. Nipat Jongswat
ตอบคำถำม
Dr. Nipat Jongswat
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
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
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 ในที่ที่มนั อยู่
Dr. Nipat Jongswat
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 เล็ก ๆ โดยทำเป็ น IntraSystem Service หรื อ Internal Service แล้ วค่อยขยำยเป็ น Internal Service
ที่มีขอบเขตใหญ่ขึ ้น หรื อแม้ กระทัง่ ให้ บริ กำร External Service
Dr. Nipat Jongswat
บทสรุ ป
Dr. Nipat Jongswat
SOA ในองค์กร (1)
• เน้ นกำรรวมระบบซอฟต์แวร์ เข้ ำด้ วยกันแบบองค์รวม โดยกำหนด
Service และ Collaboration ระหว่ำงกัน
• ไม่ใช่เป็ นเพียงกำรเรี ยกใช้ ฟังก์ชนั โดยอิสระจำกเทคโนโลยีเท่ำนัน้ แต่
นำไปสูก่ ำรพัฒนำ Long-Running Business Process
ข้ ำมองค์กร
• มีเทคโนโลยีในกำรพัฒนำ SOA หลำกหลำยแบบที่ควรเลือกให้
เหมำะสม
Dr. Nipat Jongswat
SOA ในองค์กร (2)
New
CRM
Application
Internet
Partner
Application
SOA Infrastructure
Discovery
Post GL
GL
Legacy
System
Security
Dev Tools
Reverse
GL
Check
Out
Inventory
Legacy
System
Dr. Nipat Jongswat
Standards
Get
Product
Info
External
System
Service
ประโยชน์ของ SOA
• Application มีควำมยืดหยุน่ ปรับเปลี่ยนง่ำย เพรำะอิงมำตรฐำน
และถอดเปลี่ยน Service ได้
• สำมำรถพัฒนำ Application ได้ เร็ว โดยกำรประกอบ Service
เข้ ำด้ วยกัน
• ลดต้ นทุนและควำมเสี่ยง ไม่ต้องพัฒนำและบำรุงรักษำทุกส่วนของ
Application เอง
• สำมำรถนำระบบที่มีอยูแ่ ล้ วมำใช้ ร่วมกันแบบองค์รวมได้ กำรลงทุนไม่
สูญเปล่ำ
Dr. Nipat Jongswat
เอกสำรอ้ำงอิง
•
•
•
•
Debu Panda, “An Introduction to Service-Oriented Architecture
from a Java Developer’s Perspective”, 26 January 2005. Available:
http://www.onjava.com/pub/a/onjava/2005/01/26/soa-intro.html
Jagadish Chatarji, “Introduction to Service-Oriented Architecture
(SOA)”, 13 October 2004. Available:
http://www.devshed.com/c/a/Web-Services/Introduction-toService-Oriented-Architecture-SOA/
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