51:
service-orientation, more knowledge is not necessarily better. There is a chance that additional information could impede the reusability of the service as the service consumer designer may streamline his design based on this knowledge. However, doing so would affect the evolution of the service contract as now the service consumer is indirectly coupled to the service implementation, which may need to be replaced in the future. This increases the
146:
Although information hiding is considered a healthy practice, however, too much of information hiding could be counter productive as it can limit the re-usability level of the service. This can also result in redundant services as service designers don’t have enough information about the capabilities
116:
The programmatic details about the service logic need to be abstracted as knowledge about how the service actually performs its functionality can result in service consumers that factor in this information and are consequently designed under these assumptions. This can seriously hamper service logic
94:
A service contract which has not been subjected to this principle could be termed as a 'detailed contract' that reveals much of business rules and the validation logic. Once this principle has been applied to a fair degree, the contract could be termed as a ‘concise contract’. Further application of
90:
This form of abstraction is dependent upon how much of the service logic is exposed as service capabilities. An example would be of a class whereby some of its methods are private while others are public. A class would only expose those methods as public that it deems to be important to its objects,
29:
so that the information published in a service contract is limited to what is required to effectively utilize the service The service contract should not contain any superfluous information that is not required for its invocation. Also that the information should be limited to the serviced contract
103:
Any information about the underlying technology used within the service would result in a low technology information abstraction as the service contract explicitly tells the service consumers how the service logic and its implementation are designed. This extra information might result in service
129:
Quality abstraction relates to the details provided within the service’s accompanying service level agreement. It is important to concentrate only on that kind of information that would actually help in determining the reliability and availability of the service, no other information should be
137:
abstractions are in place. An 'open access' would provide free access to everyone that is interested in finding out the design specifications of a service. In a 'controlled access', only authorized people are granted access and a 'no access' policy would totally deny any access to the design
50:
A service contract that contains details about what it encapsulates (e.g., the logic, implementation and the technology used to build the service) may end up being used in a particular manner by providing the service consumer more knowledge about the working of the service. In the case of
73:
to hide the actual method logic. The same concept is applied by the service abstraction principle in order to hide the unnecessary details about the working of the service with a view to ease the evolution of the service.
147:
of the service. For this, each service contract needs to be designed in a concise yet comprehensive manner so that the service’s capabilities can be effectively discovered and interpreted as dictated by the
130:
included that exposes unnecessary details e.g. details about how does a service sit within the overall business process and which other services it uses for fulfilling its functionality.
154:
The kind of information exposed in the service contract can lead to some security related concerns as well. for example, a service that propagates the details about the
105:
52:
303:
82:
The application of this design principle requires looking into four different types of abstractions that could be applied to a service.
42:
should be made available to the service consumers other than the service contract that contains additional service related information.
162:
and attempts to connect to the database. This could be addressed by the application of the message screening and exception shielding
65:
remains one of the key principles within object-oriented paradigm that promotes abstracting away the inner workings of a
148:
249:, pp. 1–10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 8 April 2010.
95:
this design principle would result in a 'optimized contract' that maximizes the reuse potential of the service.
104:
consumers being designed in a way that specifically targets that particular implementation, thereby developing
56:
270:
263:
246:
31:
133:
The level of access control applied to a service would decide how much of technology, logic and
39:
207:
117:
refactoring efforts and can be considered as an anti-pattern towards the application of the
59:
can negatively impact the evolution of both the service provider and the service consumer.
8:
118:
23:
134:
62:
271:
Application of New
Automation Software Design and Integration Technologies in Teaching
230:
257:
Service-Orientation and Object-Orientation Part II:A Comparison of Design
Principles
219:
159:
66:
163:
55:
type of coupling, which is a positive type of coupling. However, having too much
26:
158:
in use as result of an internal error can fall a victim to an attack where the
70:
297:
247:
Service
Oriented Device Integration - An Analysis of SOA Design Patterns.
91:
any helper methods that are not relevant to the objects are kept hidden.
256:
252:
194:
182:
155:
35:
288:
283:
195:
Principles and
Patterns at the U.S. Department of Defense
264:
Guidelines for Using Web
Service Contract Technologies
200:
98:
224:
22:is a design principle that is applied within the
295:
213:
160:attacker makes use of the reported error details
187:
85:
69:. A classic example would be the use of
296:
124:
304:Service-oriented (business computing)
111:
13:
239:
176:
99:Technology information abstraction
14:
315:
277:
149:service discoverability principle
141:
273:. Date accessed: 13 April 2010.
259:. Date accessed: 13 April 2010.
266:.Date accessed: 13 April 2010.
210:.Date accessed: 13 April 2010.
197:.Date accessed: 13 April 2010.
77:
1:
169:
30:(technical contract and the
7:
208:SOA Contract Maturity Model
10:
320:
106:consumer-to-implementation
45:
206:Kjell-Sverre Jerijærvi.
32:service level agreement
86:Functional abstraction
53:consumer-to-contract
231:Exception Shielding
125:Quality abstraction
119:service refactoring
24:service-orientation
20:Service abstraction
289:SOA Terms Glossary
135:quality of service
63:Information hiding
220:Message Screening
112:Logic abstraction
34:) only, no other
311:
233:
228:
222:
217:
211:
204:
198:
193:Dennis Wisnosky.
191:
185:
180:
121:design pattern.
71:abstract classes
67:software program
16:Design principle
319:
318:
314:
313:
312:
310:
309:
308:
294:
293:
280:
242:
240:Further reading
237:
236:
229:
225:
218:
214:
205:
201:
192:
188:
181:
177:
172:
164:design patterns
144:
127:
114:
101:
88:
80:
48:
27:design paradigm
17:
12:
11:
5:
317:
307:
306:
292:
291:
286:
279:
278:External links
276:
275:
274:
267:
260:
250:
245:Mauro. et al.
241:
238:
235:
234:
223:
212:
199:
186:
174:
173:
171:
168:
143:
142:Considerations
140:
126:
123:
113:
110:
100:
97:
87:
84:
79:
76:
47:
44:
15:
9:
6:
4:
3:
2:
316:
305:
302:
301:
299:
290:
287:
285:
282:
281:
272:
268:
265:
261:
258:
254:
251:
248:
244:
243:
232:
227:
221:
216:
209:
203:
196:
190:
184:
179:
175:
167:
165:
161:
157:
152:
150:
139:
136:
131:
122:
120:
109:
107:
96:
92:
83:
75:
72:
68:
64:
60:
58:
54:
43:
41:
37:
33:
28:
25:
21:
284:SOA Concepts
262:Tost. et al.
226:
215:
202:
189:
178:
153:
145:
132:
128:
115:
102:
93:
89:
81:
61:
49:
19:
18:
269:Pekka Alho.
138:documents.
78:Application
253:Thomas Erl
170:References
108:coupling.
57:dependence
298:Category
156:database
36:document
183:Service
46:Purpose
40:medium
38:or
300::
166:.
151:.
255:.
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.