1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
|
<HTML>
<HEAD>
<TITLE>Lessons Learned Building Reusable OO Telecommunication Software</TITLE>
</HEAD>
<BODY text = "#000000"
link="#000fff"
vlink="#ff0f0f"
bgcolor="#ffffff">
<HR>
<H3>Lessons Learned Building Reusable OO Telecommunication Software Frameworks</H3>
<DT>Douglas C. Schmidt
<DT>Department of Computer Science
<DT>Washington University, St. Louis
<DT><A HREF="http://www.cs.wustl.edu/~schmidt/">http://www.cs.wustl.edu/~schmidt/</A>
<DT><A HREF="mailto:schmidt@cs.wustl.edu">schmidt@cs.wustl.edu</A>
<P>The following article appeared in the Lucent Bell Labs ``Multiuse
Express'' magazine, Vol. 4, No. 6, December, 1996. <P>
<P><HR><P>
<H3>The Distributed Software Crisis</H3>
Developing complex software systems is expensive and error-prone.
Object-oriented (OO) programming languages [Stroustrup:91,Gosling:96],
components [Box:97], and frameworks [Lewis:95] are heavily touted
technologies for reducing software cost and improving software
quality. When stripped of their hype, the primary benefits of OO stem
from the emphasis on <EM>modularity</EM> and <EM>extensibility</EM>,
which encapsulate volatile implementation details behind stable
interfaces and enhance software reuse. <P>
Developers in certain well-traveled domains have successfully applied
OO techniques and tools for years. For instance, the Microsoft MFC
GUI framework and OCX components are <EM>de facto</EM> industry
standards for creating graphical business applications on PC
platforms. Although these tools have their limitations, they
demonstrate the productivity benefits of reusing common frameworks and
components.<P>
Software developers in more complex domains like telecom have
traditionally lacked standard off-the-shelf middleware components. As
a result, telecom developers largely build, validate, and maintain
software systems from scratch. In an era of deregulation and stiff
global competition, this in-house development process is becoming
prohibitively costly and time consuming. Across the industry, this
situation has produced a ``distributed software crisis,'' where
computing hardware and networks get smaller, faster, and cheaper; yet
telecom software gets larger, slower, and more expensive to develop
and maintain. <P>
The challenges of building distributed software stem from
<EM>inherent</EM> and <EM>accidental</EM> complexities [Brooks:87]
associated with telecom systems: <P>
<UL>
<LI> Inherent complexity stems from the fundamental challenges of
developing telecom software. Chief among these is detecting and
recovering from network and host failures, minimizing the impact of
communication latency, and determining an optimal partitioning of
service components and workload onto processing elements throughout
a network. <P>
<LI> Accidental complexity stems from limitations with tools and
techniques used to develop telecom software. A common source of
accidental complexity is the widespread use of algorithmic
decomposition, which results in non-extensible and non-reusable
software designs and implementations. <P>
</UL>
The lack of extensibility and reuse in-the-large is particularly
problematic for complex distributed telecom software. Extensibility
is essential to ensure timely modification and enhancement of services
and features. Reuse is essential to leverage the domain knowledge of
expert developers to avoid re-developing and re-validating common
solutions to recurring requirements and software challenges. <P>
While developing high quality reusable software is hard enough,
developing high quality extensible and reusable telecom software is
even harder. Not surprisingly, many companies attempting to build
reusable middleware fail -- often with enormous loss of money, time,
and marketshare. Those companies that do succeed, however, reap the
benefits resulting from their ability to develop and deploy complex
applications rapidly, rather than wrestling endlessly with
infrastructure problems. Unfortunately, the skills required to
successfully produce telecom middleware remain something of a "black
art," often locked in the heads of expert developers. <P>
<P><HR><P>
<H3>Lessons Learned Building Reusable OO Communication Software Frameworks</H3>
Over the past decade, I've worked with many companies (including
Motorola Iridium, Ericsson, Siemens, Bellcore, Kodak, and McDonnell
Douglas) building reusable OO communication software [Schmidt:96]. In
these projects, we've applied a range of OO middleware tools including
OMG <A HREF="http://www.cs.wustl.edu/~schmidt/corba.html">CORBA</A>
(an emerging industry standard for distributed object computing) and
the <A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</A>
framework (a widely used C++ framework that implements many strategic
and tactical design patterns for concurrent communication software).
The following are lessons learned from developing and deploying
reusable OO communication software components and frameworks in
practice: <P>
<UL>
<LI> <B><EM> Successful reuse-in-the-large requires non-technical
prerequisites -- </EM></B><P>
Many political, economical, organizational, and psychological
factors can impede successful reuse in telecom companies. I've
found that reuse-in-the-large works best when (1) the marketplace is
competitive (i.e., time-to-market is crucial, so leveraging existing
software substantially reduces development effort), (2) the
application domain is non-trivial (i.e., repeatedly developing
complete solutions from scratch is too costly), and (3) the
corporate culture is supportive of an effective reuse process (e.g.,
developers are rewarded for taking the time to build robust reusable
components). When these prerequisites <EM>don't</EM> apply, I've
found that developers often fall victim to the "not-invented-here"
syndrome and rebuild everything from scratch. <P>
<LI> <B><EM> Iteration and incremental growth is essential </EM></B> -- <P>
Expanding on the corporate culture theme, I've observed that it's
crucial for software managers to openly support the fact that good
components, frameworks, and software architectures take time to
craft and hone. For reuse to succeed in-the-large, management must
have the vision and resolve to support the incremental evolution of
reusable software. In general, an 80% solution that can be evolved
is often preferable to trying to achieve a 100% solution that never
ships. Fred Brook's observation that ``Plan to throw the first one
away, you will anyway'' [Brooks:75] applies as much today as it did
20 years ago. <P>
<LI> <B><EM> Integrate infrastructure developers with application developers
</EM></B> -- <P>
Truly useful components and frameworks are derived from solving real
problems, e.g., telecommunications, medical imaging, avionics, OLTP,
etc. Therefore, a time honored way of producing reusable components
is to generalize from working systems and applications. In
particular, resist the temptation to create ``component teams'' that
build reusable frameworks in isolation from application teams. I've
learned the hard way that without intimate feedback from application
developers, the software artifacts produced by a component team
won't solve real problems and will not be reused. <P>
<LI> <B><EM> Industry ``standards'' are not panaceas -- </EM></B> <P>
Expecting emerging industry standards (like CORBA or TINA) to
eliminate telecom software complexity today is very risky. For
instance, although some CORBA ORB implementations are suited for
certain telecom tasks (such as managing network elements), the
semantics of higher level OMG services (such as the Common Object
Services) are still too vague, under-specified, and non</EM></B>
-interoperable. Although CORBA isn't yet suited to address certain
demanding real-time performance and reliability requirements in the
telecom domain, over the next 2 years we'll see CORBA-based products
emerge that support such features [Schmidt:96].<P>
<LI> <B><EM> Beware of simple(-minded) solutions to complex software problems
-- </EM></B> <P>
Apply simple solutions to complex problems that sound too good to be
true typically are... For example, translating code entirely from
high-level specifications or using trendy OO design methodologies
and programming languages is no guarantee of success. In my
experience, there's simply no substitute for skilled software
developers, which leads to the following final ``lesson learned.''
<P>
<LI> <B><EM> Respect and reward quality developers </EM></B> -- <P>
Ultimately, reusable components are only as good as the people who
build and use them. Developing robust, efficient, and reusable
telecom middleware requires teams with a wide range of skills. We
need expert analysts and designers who have mastered design
patterns, software architectures, and communication protocols to
alleviate the inherent and accidental complexities of telecom
software. Moreover, we need expert programmers who can implement
these patterns, architectures, and protocols in reusable frameworks
and components. In my experience, it is exceptionally hard to find
high quality software developers. Ironically, many telecom
companies treat their developers as interchangeable, "unskilled
labor" who can be replaced easily. I suspect that over time,
companies who respect and reward their high quality software
developers will increasingly outperform those who don't. <P>
</OL>
<P><HR><P>
<H3>Concluding Remarks</H3>
Developing reusable OO middleware components and frameworks is not a
silver bullet. Software is inherently abstract, which makes it hard
to engineer its quality and to manage its production. The good news,
however, is that OO component and framework technologies are becoming
mainstream. Developers and users are increasingly adopting and
succeeding with object-oriented design and programming.<P>
On the other hand, the bad news is that (1) existing OO components and
frameworks are largely focused on only a few areas (e.g., GUIs) and
(2) existing industry standards still lack the semantics, features,
and interoperability to be truly effective throughout the telecom
software domain. Too often, vendors use industry standards to sell
proprietary software under the guise of open systems. Therefore, it's
essential for telecom companies to work with standards organizations
and middleware vendors to ensure the emerging specifications support
true interoperability and define features that meet telecom software
needs.<P>
Finally, to support the standardization effort, it's crucial for us to
capture and document the patterns that underlie the successful telecom
software components and frameworks that do exist. Likewise, we need
to reify these patterns to guide the creation of standard frameworks
and components for the telecom domain. I'm optimistic that the next
generation of OO frameworks and components will be a substantial
improvement over those we've worked with in the past.<P>
For more information on building reusable OO communication software
frameworks with CORBA and ACE, see the following WWW URLs:<P>
<A HREF="http://www.cs.wustl.edu/~schmidt/corba.html">http://www.cs.wustl.edu/~schmidt/corba.html</A><p>
<A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">http://www.cs.wustl.edu/~schmidt/ACE.html.</A>
<P><HR><P>
<H3>References</H3>
[Box:97] Don Box, "Understanding COM," Addison-Wesley,
Reading, MA, 1997.<P>
[Brooks:75] Frederick P. Brooks, "The Mythical Man-Month,"
Addison-Wesley, Reading, MA, 1975.<P>
[Brooks:87] Frederick P. Brooks, "No Silver Bullet: Essence and
Accidents of Software Engineering," IEEE Computer, Volume
20, Number 4, April 1987, 10-19.<P>
[Gosling:96] The Java Programming Language, Addison-Wesley,
Reading, MA, 1996.<P>
[Lewis:95], Ted Lewis et al., "Object Oriented Application
Frameworks," IEEE Computer Society Press, 1995.<P>
[OMG:95] Object Management Group, The Common Object Request Broker:
Architecture and Specification 2.0, July, 1995.<P>
[Schmidt:96] Douglas C. Schmidt, "A Family of Design Patterns for
Application-Level Gateways," Theory and Practice of Object
Systems, Wiley and Sons, 1996.<P>
[Schmidt:97] Aniruddha Gokhale, Douglas C. Schmidt, Tim Harrison, and
Guru Parulkar, "Towards Real-time CORBA," IEEE Communications
Magazine, Volume 14, Number 2, February 1997.<P>
[Stroustrup:91] Bjarne Stroustrup, The C++ Programming Language, 2nd
Edition, Addison-Wesley, Reading, MA, 1991.<P>
<P><HR><P>
Back to <A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">
ACE</A> home page.
<!--#include virtual="/~schmidt/cgi-sig.html" -->
</BODY>
</HTML>
|
