diff options
Diffstat (limited to 'docs/ACE-lessons.html')
| -rw-r--r-- | docs/ACE-lessons.html | 270 |
1 files changed, 0 insertions, 270 deletions
diff --git a/docs/ACE-lessons.html b/docs/ACE-lessons.html deleted file mode 100644 index b9cca0bd7cf..00000000000 --- a/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> -</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.<BR> -Back to <A HREF="index.html">ACE Documentation Home</A>. -<!--#include virtual="/~schmidt/cgi-sig.html" --> -</BODY> -</HTML> |