summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorschmidt <douglascraigschmidt@users.noreply.github.com>1997-06-26 04:13:21 +0000
committerschmidt <douglascraigschmidt@users.noreply.github.com>1997-06-26 04:13:21 +0000
commit2df950ee5f5f41b4ec601957c4085a8cd006e1bf (patch)
treea570114a46c605562a7a362b9ddb0f2a2c7aa1c8 /docs
parent9889d49a7edfac0f9ef060f83ea283f727b3326d (diff)
downloadATCD-2df950ee5f5f41b4ec601957c4085a8cd006e1bf.tar.gz
*** empty log message ***
Diffstat (limited to 'docs')
-rw-r--r--docs/ACE-lessons.html267
1 files changed, 267 insertions, 0 deletions
diff --git a/docs/ACE-lessons.html b/docs/ACE-lessons.html
new file mode 100644
index 00000000000..64c8db551ef
--- /dev/null
+++ b/docs/ACE-lessons.html
@@ -0,0 +1,267 @@
+<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="corba.html">CORBA</A> (an emerging industry standard for
+distributed object computing) and the <A HREF="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>