99:
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 and utility 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 and orchestrated task services, are less reusable and are dependent upon the individual autonomy of their composed services.
48:
within service-orientation, the stakes are even higher as a service-oriented solution can be composed of services that exist outside of the organizational boundary. So in this case, it's the design of the service itself that matters and the service needs to be designed in a way that it exercises maximum control over how it fulfills its functionality. The service autonomy principle attempts to provide guidelines for designing autonomous services so that the resulting services are more predictable and reliable.
86:
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...
85:
Run-time autonomy refers to the extent of the control that a service has over the way its solution logic 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
64:
Design-time autonomy refers to the independence with which the services could be evolved without impacting their service consumers. This type of autonomy is required as the service's underlying legacy resources might need an overhaul or the service's logic might need refactoring in order to make it
43:
design principle. Under this paradigm of a heavily reused services, reliability becomes critical to ensure service longevity. In turn, service reliability depends on the service's operational control of service logic and underlying implementation resources to reduce dependence on external resources
107:
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
47:
Traditional component-based software development also faces the same autonomy requirements, the provisioning of autonomy and reliability, in such circumstances, is left to the actual run-time environment e.g. by providing fail-over support or by deploying a solution on dedicated servers. However,
98:
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
76:
principles helps in attaining design-time autonomy as their application results in services whose contracts are shielded from their logic and implementation and hence, the services could be redesigned without affecting their service consumers.
111:
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.
89:
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.
30:
with improved independence from their execution environments. This results in greater reliability, since services can operate with less dependence on resources over which there is little or no control.
218:
129:
56:
The application of service autonomy involves two types of autonomy that allow an increase the overall autonomy of the service, design time autonomy and run time autonomy.
69:
44:
over which it has little or no control such as shared service logic or a shared database, which may not be available when required by the service.
234:
197:
152:
211:
207:, pp. 1–10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 8 April 2010.
40:
27:
204:
175:
164:
8:
186:
73:
20:
39:
The service-orientation design paradigm emphasizes service reuse as dictated by the
219:
Service-Oriented Device
Communications Using the Devices Profile for Web Services
23:
108:
since making fundamental changes to such a service is likely to be difficult.
228:
205:
Service
Oriented Device Integration - An Analysis of SOA Design Patterns.
130:
E-Government Based on Cloud
Computing and Service-Oriented Architecture
141:
198:
Principles and
Patterns at the U.S. Department of Defense
212:Access Control and Service-Oriented Architectures
19:is a design principle that is applied within the
226:
122:
59:
227:
214:.page 50.Date accessed: 15 April 2010.
135:
128:Wojciech Cellary, Sergiusz Strykowski.
235:Service-oriented (business computing)
80:
13:
14:
246:
180:
169:
158:
146:
102:
93:
221:.Date accessed: 17 April 2010.
200:.Date accessed: 15 April 2010.
155:.Date accessed: 17 April 2010.
153:Service-orientation Principles
132:.Date accessed: 17 April 2010.
51:
1:
115:
7:
10:
251:
34:
68:The application of the
70:service loose coupling
60:Design-time autonomy
142:Service Composition
74:service abstraction
41:service reusability
21:service-orientation
81:Run-time autonomy
242:
196:Dennis Wisnosky.
189:
184:
178:
173:
167:
162:
156:
150:
144:
139:
133:
126:
65:more efficient.
17:Service autonomy
250:
249:
245:
244:
243:
241:
240:
239:
225:
224:
193:
192:
185:
181:
176:Utility Service
174:
170:
163:
159:
151:
147:
140:
136:
127:
123:
118:
105:
96:
83:
62:
54:
37:
24:design paradigm
12:
11:
5:
248:
238:
237:
223:
222:
217:Jammes. et al.
215:
208:
203:Mauro. et al.
201:
191:
190:
179:
168:
165:Entity Service
157:
145:
134:
120:
119:
117:
114:
104:
103:Considerations
101:
95:
92:
82:
79:
61:
58:
53:
50:
36:
33:
9:
6:
4:
3:
2:
247:
236:
233:
232:
230:
220:
216:
213:
209:
206:
202:
199:
195:
194:
188:
183:
177:
172:
166:
161:
154:
149:
143:
138:
131:
125:
121:
113:
109:
100:
94:Service types
91:
87:
78:
75:
71:
66:
57:
49:
45:
42:
32:
29:
26:, to provide
25:
22:
18:
187:Task Service
182:
171:
160:
148:
137:
124:
110:
106:
97:
88:
84:
67:
63:
55:
46:
38:
16:
15:
210:Kees Leune.
52:Application
116:References
229:Category
72:and the
28:services
35:Purpose
231::
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.