หลักการความเป็นอิสระของบริการ
ความเป็นอิสระของบริการเป็นหลักการออกแบบที่นำมาใช้ภายในกระบวนทัศน์การออกแบบที่มุ่งเน้นบริการ เพื่อให้บริการมีความเป็นอิสระจากสภาพแวดล้อมการดำเนินการมากขึ้น[ 1 ]ซึ่งส่งผลให้มีความน่าเชื่อถือมากขึ้น เนื่องจากบริการสามารถทำงานได้โดยพึ่งพาทรัพยากรน้อยลง ซึ่งเราควบคุมได้น้อยหรือไม่สามารถควบคุมได้เลย
วัตถุประสงค์
แนวคิดการออกแบบที่เน้นการบริการ (Service-Orientation Design) ให้ความสำคัญกับการนำบริการกลับมาใช้ซ้ำตาม หลักการออกแบบ การนำบริการกลับมาใช้ซ้ำ (Service Reusability Design) ภายใต้แนวคิดนี้ การนำบริการกลับมาใช้ซ้ำอย่างมาก ความน่าเชื่อถือจึงมีความสำคัญอย่างยิ่งต่อการรับประกันอายุการใช้งานของบริการ ในทางกลับกัน ความน่าเชื่อถือของบริการขึ้นอยู่กับการควบคุมการทำงานของตรรกะบริการและทรัพยากรการใช้งานพื้นฐาน เพื่อลดการพึ่งพาแหล่งทรัพยากรภายนอกที่ตนเองควบคุมได้น้อยหรือไม่มีเลย เช่น ตรรกะบริการที่ใช้ร่วมกัน หรือฐานข้อมูลที่ใช้ร่วมกัน ซึ่งอาจไม่พร้อมใช้งานเมื่อบริการต้องการใช้งาน
การพัฒนาซอฟต์แวร์แบบดั้งเดิมที่ใช้ส่วนประกอบก็เผชิญกับข้อกำหนดด้านความเป็นอิสระเช่นเดียวกัน การจัดหาความเป็นอิสระและความน่าเชื่อถือในสถานการณ์เช่นนี้ จะถูกปล่อยให้เป็นหน้าที่ของสภาพแวดล้อมการทำงานจริง เช่น โดยการให้การสนับสนุนการทำงานล้มเหลว หรือโดยการปรับใช้โซลูชันบนเซิร์ฟเวอร์เฉพาะ อย่างไรก็ตาม ภายในแนวคิดการให้บริการ ความเสี่ยงจะยิ่งสูงขึ้นไปอีก เนื่องจากโซลูชันที่มุ่งเน้นการให้บริการสามารถประกอบด้วยบริการ[ 2 ]ที่อยู่นอกขอบเขตขององค์กร ดังนั้นในกรณีนี้ การออกแบบตัวบริการเองจึงมีความสำคัญ และบริการจำเป็นต้องได้รับการออกแบบในลักษณะที่สามารถควบคุมการทำงานของตนได้อย่างเต็มที่ หลักการความเป็นอิสระของบริการพยายามให้แนวทางในการออกแบบบริการที่เป็นอิสระ เพื่อให้บริการที่ได้นั้นสามารถคาดการณ์ได้และน่าเชื่อถือมากขึ้น
แอปพลิเคชัน
การประยุกต์ใช้ความเป็นอิสระของบริการนั้นเกี่ยวข้องกับความเป็นอิสระสองประเภทที่ช่วยเพิ่มความเป็นอิสระโดยรวมของบริการ ได้แก่ ความเป็นอิสระในขั้นตอนการออกแบบ และความเป็นอิสระในขั้นตอนการทำงาน
ความเป็นอิสระในขั้นตอนการออกแบบ
ความเป็นอิสระในขั้นตอนการออกแบบ หมายถึง ความเป็นอิสระที่บริการสามารถพัฒนาต่อไปได้โดยไม่ส่งผลกระทบต่อผู้ใช้บริการ ความเป็นอิสระประเภทนี้มีความจำเป็น เนื่องจากทรัพยากรเดิมที่อยู่เบื้องหลังบริการอาจต้องได้รับการปรับปรุงใหม่ หรือตรรกะของบริการอาจต้องได้รับการปรับปรุงใหม่เพื่อให้มีประสิทธิภาพมากขึ้น
การประยุกต์ใช้ หลักการ เชื่อมโยงแบบหลวมๆ ของบริการและ หลักการ นามธรรมของบริการช่วยให้บรรลุความเป็นอิสระในขั้นตอนการออกแบบ เนื่องจากผลลัพธ์ที่ได้คือบริการที่มีสัญญาแยกต่างหากจากตรรกะและการใช้งาน ดังนั้นจึงสามารถออกแบบบริการใหม่ได้โดยไม่ส่งผลกระทบต่อผู้ใช้บริการ
ความเป็นอิสระขณะทำงาน
Run-time autonomy refers to the extent of the control that a service has over the way its solution logic[3] is processed by the run-time environment. The more control a service has over its run-time environment, the more predictable is its behavior. Run-time autonomy is achieved by providing dedicated processing resources to the service. For example, if the service logic performs memory intensive tasks then the service could be deployed to a server with reserved or conserved resources. Similarly, by providing locally cached copies of data, where applicable, the service's dependency on a remote shared database can be reduced. As a result, the overall autonomy of the service is increased...
There is a direct relationship between run-time autonomy and the design-time autonomy. Increasing the design-time autonomy automatically increases the ability to evolve service's implementation environment.
Service types
Although increasing service autonomy to the maximum extent is always desirable, it is not always possible to design each and every service with maximum design-time and run-time autonomy. As a result, the services need to be prioritized so that their autonomy could be addressed according to their value for business. This could be done by having a look at the functional context of the service. Services whose functional contexts are independent of any particular business process, e.g. entity [4] and utility[5] services, are good candidates for increasing their autonomy. This is because they offer functionality that is of interest to different types of consumers. On the other hand, business process specific services, e.g. task[6] and orchestrated task services, are less reusable and are dependent upon the individual autonomy of their composed services.
Considerations
The provisioning of service autonomy may require additional infrastructure and needs to be applied on a per-need, prioritized basis. On some occasions, services may need to be isolated and deployed in a customized and dedicated environment, with emphasis on designing the correct functional context since making fundamental changes to such a service is likely to be difficult.
The autonomy of services that encapsulate legacy resources may be hard to predict and increase. This may require additional analysis on part of utility services, as the level of autonomy depends upon the functionality provided by the service.