9. CONCLUSIONIn this paper we used

9. CONCLUSION
In this paper we used architectural principles and decisions as
a comparison method to illustrate the conceptual and technological
differences between RESTful Web services and WSDL/SOAPbased
“Big” Web services. On the principle level, the two approaches
have similar quantitative characteristics. On the conceptual
level, less architectural decisions must be made when deciding
for WS-* Web services, but more alternatives are available. On
the technology level, the same number of decisions must be made,
but less alternatives have to be considered when building RESTful
Web services. Thus, the perceived simplicity of REST now can
be understood from a quantitative perspective – choosing REST
removes the need for making a series of further architectural decisions
related to the various layers of the WS-* stack and makes
such complexity appear as superfluous. Still, if advanced functionality
as delivered by WS-* is needed, it will be no simple matter
to extend a RESTful Web service to support it in an interoperable
manner. Furthermore, according to our experience several of the
decisions that are very easy to make for RESTful services lead to
significant development efforts and technical risk, for example the
design of the exact specification of the resources and their URI addressing
scheme.
From our comparison it can also be seen that the two styles
are rather similar, as long as the same subset of technology decisions
is compared, for example when ignoring the more advanced
features of the WS-* stack and only comparing POX/HTTP and
SOAP/HTTP. It could even be argued that these two approaches
are two technology-level variants of the same conceptual design.
Assuming that the enterprise-level features of WS-* (transactions,
reliability, message-level security) are not required, the key
decision drivers at present are degree of flexibility and control,
but also development efforts and technical risk (in implementation
design, development, and maintenance), degree of open source
and vendor tool support, and programming interface convenience.
REST scores better with respect to flexibility and control, but requires
a lot of low-level coding; WS-* provides better tool support
and programming interface convenience, but introduces a dependency
on vendors and open source projects. The main conclusion
from this comparison is to use RESTful services for tactical, ad hoc
integration over the Web (à la Mashup) and to prefer WS-* Web
services in professional enterprise application integration scenarios
with a longer lifespan and advanced QoS requirements.

ผลลัพธ์ (ไทย) 2:

9. สรุป
ในบทความนี้เราใช้หลักการสถาปัตยกรรมและการตัดสินใจเป็น
วิธีการเปรียบเทียบให้เห็นถึงแนวความคิดและเทคโนโลยีที่
แตกต่างระหว่างบริการเว็บสงบและ WSDL / SOAPbased
"บิ๊ก" บริการเว็บ ในระดับหลักการทั้งสองวิธี
มีลักษณะเชิงปริมาณที่คล้ายกัน เกี่ยวกับแนวความคิด
ในระดับการตัดสินใจสถาปัตยกรรมน้อยจะต้องทำเมื่อตัดสินใจ
สำหรับ WS- * บริการเว็บ แต่ทางเลือกที่มีอยู่ ใน
ระดับเทคโนโลยีที่หมายเลขเดียวกันของการตัดสินใจจะต้องทำ
แต่ทางเลือกน้อยจะต้องมีการพิจารณาเมื่อสร้างสงบ
บริการเว็บ ดังนั้นการรับรู้ความเรียบง่ายของส่วนที่เหลือในขณะนี้สามารถ
ที่จะเข้าใจจากมุมมองเชิงปริมาณ - เลือก REST
ขจัดความจำเป็นในการทำชุดของการตัดสินใจสถาปัตยกรรมเพิ่มเติม
ที่เกี่ยวข้องกับชั้นต่างๆของสแต็ค WS- * และทำให้
ความซับซ้อนดังกล่าวปรากฏเป็นฟุ่มเฟือย ยังถ้าการทำงานขั้นสูง
เช่นการส่งมอบโดย WS- * เป็นสิ่งจำเป็นก็จะไม่มีเรื่องง่าย
ที่จะขยายบริการเว็บสงบที่จะสนับสนุนในการทำงานร่วมกัน
อย่าง นอกจากนี้ตามประสบการณ์ของเราหลาย
ตัดสินใจที่ง่ายมากที่จะทำให้การให้บริการสงบนำไปสู่ความ
พยายามในการพัฒนาอย่างมีนัยสำคัญและความเสี่ยงทางด้านเทคนิคเช่น
การออกแบบของสเปคที่แน่นอนของทรัพยากรและที่อยู่ของพวกเขา URI
โครงการ.
จากการเปรียบเทียบของเราก็สามารถ นอกจากนี้ยังจะเห็นได้ว่าทั้งสองรูปแบบ
จะค่อนข้างคล้ายกันตราบใดที่ย่อยเดียวกันของการตัดสินใจเทคโนโลยีที่
มีการเปรียบเทียบตัวอย่างเช่นเมื่อไม่สนใจที่สูงขึ้น
คุณสมบัติของ WS- * สแต็คและมีเพียงการเปรียบเทียบ POX / HTTP และ
SOAP / HTTP แม้มันอาจจะแย้งว่าทั้งสองวิธี
มีสองสายพันธุ์เทคโนโลยีระดับของการออกแบบแนวความคิดเดียวกัน.
สมมติว่าคุณสมบัติขององค์กรระดับ WS- * (การทำธุรกรรม
น่าเชื่อถือความปลอดภัยข้อความระดับ) ไม่จำเป็นต้องคีย์
ไดรเวอร์ตัดสินใจ ในปัจจุบันมีระดับของความยืดหยุ่นและการควบคุม
แต่ยังพยายามในการพัฒนาและความเสี่ยงทางเทคนิค (ในการดำเนิน
การออกแบบการพัฒนาและการบำรุงรักษา), ระดับของการเปิดแหล่งที่มา
และการสนับสนุนเครื่องมือที่ผู้ขายและความสะดวกสบายอินเตอร์เฟซการเขียนโปรแกรม.
REST คะแนนที่ดีขึ้นเกี่ยวกับการมีความยืดหยุ่นและการควบคุม แต่ต้องใช้
จำนวนมากของการเข้ารหัสระดับต่ำ; WS- * ให้การสนับสนุนเครื่องมือที่ดีกว่า
และความสะดวกสบายอินเตอร์เฟซการเขียนโปรแกรม แต่แนะนำการพึ่งพา
ผู้ขายและโครงการโอเพนซอร์ส ข้อสรุปหลัก
จากการเปรียบเทียบนี้คือการใช้บริการสงบสำหรับยุทธวิธีเฉพาะกิจ
บูรณาการผ่านเว็บ (àลา Mashup) และจะชอบ WS- * เว็บ
บริการในสถานการณ์รวมโปรแกรมองค์กรมืออาชีพ
ด้วยอายุการใช้งานอีกต่อไปและต้องการ QoS ขั้นสูง