diff options
Diffstat (limited to 'ACE/docs/ACE-lessons.html')
| -rw-r--r-- | ACE/docs/ACE-lessons.html | 270 |
1 files changed, 270 insertions, 0 deletions
diff --git a/ACE/docs/ACE-lessons.html b/ACE/docs/ACE-lessons.html new file mode 100644 index 00000000000..4448644ae68 --- /dev/null +++ b/ACE/docs/ACE-lessons.html @@ -0,0 +1,270 @@ +<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> |