Sophie: ace-doc-0:5.7.2-1mdv2010.0 x86

ace-doc-5.7.2-1mdv2010.0.x86_64.rpm

<HTML>

<!-- $Id: ACE-lessons.html 80826 2008-03-04 14:51:23Z wotte $ -->
<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>