summaryrefslogtreecommitdiff
path: root/ACE/docs/ACE-lessons.html
diff options
context:
space:
mode:
Diffstat (limited to 'ACE/docs/ACE-lessons.html')
-rw-r--r--ACE/docs/ACE-lessons.html270
1 files changed, 0 insertions, 270 deletions
diff --git a/ACE/docs/ACE-lessons.html b/ACE/docs/ACE-lessons.html
deleted file mode 100644
index 4448644ae68..00000000000
--- a/ACE/docs/ACE-lessons.html
+++ /dev/null
@@ -1,270 +0,0 @@
-<HTML>
-
-<!-- $Id$ -->
-<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>
-</UL>
-
-<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.<BR>
-Back to <A HREF="index.html">ACE Documentation Home</A>.
-<!--#include virtual="/~schmidt/cgi-sig.html" -->
-</BODY>
-</HTML>