Service Oriented Architecture

1
Service Oriented Architecture

• Presentation to CSCSI 510 Class
• University of Southern California, Viterbi School
  of Engineering
• November 21, 2007
• Presenter Len Cayetano
• Professor Dr. Barry Boehm

2
Personal Information

• Director of Software Engineering, SOA Software
• 20 plus years in software development
• MBA, Marshall School of Business
• MS, Viterbi School of Engineering

3
Agenda Objectives

• Agenda
• Section 1Driving forces for increase in
  investment in software
• Section 2Discussion on general reuse
• Section 3SOA, motivation benefits
• Section 4Industry examples of SOA implementation
  
• Objectives
• Increase understanding of SOA
• Recognize that SOA is an architecture used to
  implement reuse
• Implementation issues similar to implementation
  issues for reuse
• Understand benefits disadvantages of SOA

4
SECTION 1

• Driving Forces for Increase in Investment in
  Software Development

5
Driving Forces for Investment

• Substantial increase in investment in software
• Businesses, governments, academia
• Driving forces for investment 11,24
• Shortage of supply of software engineers
• Concurrent, rapid proliferation of personal
  computers
• Increase demand for more applications systems
  software

6
Driving Forces Contd

• Continued increase in complexity of technology
  required to complete product
• Need to integrate technology that is outside core
  competencies of organizations 16
• e.g. Databases, other 3rd party software
• Competitive pressures to introduce market
  products rapidly 42
• Increased willingness to accept relatively high
  degree of risks 17

7
Insights on Risk Management

• Definition Risk exposure (RE) is the probability
  of loss multiplied by size of loss 17
• Time-to-market and risk exposure are balanced
  differently for different types of companies 42
  
• An Internet startup may be willing to deploy a
  product with high level of risk exposure
• Cannot afford to miss introducing the product to
  the market within a certain time frame
• E.g. Greeting Cards Web Site I worked on
• Time-to-ship for a typical safety-critical system
  is longer than that of an Internet startup
• Insufficient quality may lead to loss of life
• E.g. Aircraft

8
Insights on Risk Management

• Synthesis of Risk Exposure for Product
  Development 17,42

Figure 1-1a Sweet Spot for Internet Startup
Figure 1-1b Sweet Spot for
Safety-Critical System Source B. W. Boehm,
Competing on Schedule, Cost, and Quality  The
Role of Software Models, USC Center
for Software Engineering, August, 2001
9
Strategies for Faster Development

• Outsourcing
• Commercial-Off-The-Shelf (COTS)
• Acquisitions
• Reuse

10
Overview of Outsourcing

• Outsourcing is considered when
• Functionality needs to be developed from scratch
• The firm requiring the functionality does not
  have the requisite core competency 16
• No suitable COTS product exists that can provide
  the functionality that is required by the
  organization
• There is a need to reduce development costs

11
Overview of COTS Acquisitions

• COTS is considered when
• A quick and sometimes proven solution exists
• Acquisitions
• In this context, refers to an exclusive purchase
  of technology explicitly or implicitly
• Implicit example is through a merger with another
  company

12
Overview of Reuse

• Reuse involves
• Reviewing what software capabilities have been
  developed in-house
• Identifying parts that are candidates for reuse
• Developing a process for integrating the
  reusable parts across different product lines

13
SECTION 2

• Discussion on General Reuse

14
Diffusion of Innovation

• Organizations face two innovation issues at the
  same time when developing software11, 26
• Introduction of software technology into
  well-established products
• The potential introduction of new software
  engineering techniques.
• A key challenge is that these two innovations
  need to be diffused simultaneously in the
  stakeholder community 11, 26
• Everrett M. Rogers in his book, Diffusion of
  Innovations, defines diffusion as the process
  by which an innovation is communicated through
  certain channels over time among members of a
  social system. 41
• Diffusion is a psychosocial activity, and is
  therefore multidimensional an nontrivial

15
Diffusion of Innovation

• In Figure 2 Rogers partitions the innovativeness
  variable (x) in five adopter categories based on
  standard deviations from the average time of
  adoption. 41
• Innovators
• Early adopters
• Early majority
• Late majority
• Laggards

Figure 2 Adopter Categorization on the Basis of
Innovativeness Source E.M. Rogers, Diffusion of
Innovations, Simon Schuster, 1995, p. 262
16
Diffusion of Innovation

• In Figure 3 Soon after the innovation is
  introduced, a small percentage of early adopters
  embrace an innovation 41
• At some point, when the innovation gains momentum
  and critical mass, an early majority accepts the
  innovation
• The innovation gains more acceptance over time
  until late adopters accept it

Figure 3 Process By Which Innovation is Diffused
Source E.M. Rogers, Diffusion of
Innovations, Simon Schuster, 1995, p. 11
17
Need for Radical Paradigm Shift

• Successful implementation requires a radical
  paradigm shift in the way software development is
  done. (Lim 11, Reifer 15 )
• Current activities and mindsets are 11 to
• Develop software from scratch
• Treat each product or system individually
• Reward engineers based on the number of lines of
  code that are written
• There is typically a single life cycle for
  creating a system or product.
• Tools implemented are for traditional software
  development, and each engineer typically does
  his/her own work.

18
Need for Radical Paradigm Shift

• Required paradigm shift (Boehm et al. 2,
  Lim11)
• Develop with reusable assets
• View products or systems as a portfolio
• Reward engineers for how few lines of code are
  written
• Rather than focusing on a single life cycle,
  multiple processes are used for producing,
  brokering, and consuming assets
• Tools are used for supporting and linking
  producers, brokers, and consumers of reuse
• Finally, there is a culture of reusing assets
  throughout the consumer life cycle

19
Architectural Considerations

• Garlan et al. articulate their support for reuse
  in the following observations 7
• Software designers may hit a production ceiling
  in generating large, high-quality software
  applications.
• Need to shift from the current build-from-scratch
  techniques that dominate most software
  production
• Need to embrace techniques that emphasize
  construction from reusable building blocks
• While there has been considerable support for
  building reusable components, the goal of
  constructing large-scale software applications in
  a systematic manner from existing parts remains
  an elusive goal

20
Architectural Considerations

• The selection process can be very challenging
  (Garlan et al. 7)
• Most architects use trial-and-error instead of a
  systematic, proven methodology to design
  architectures.
• The selection of an appropriate, generic product
  line architecture is a critical success factor
  for any reuse strategy
• Perry 21 asserts that there are five possible
  ways to achieve genericness in a product line
  architecture.
• Software architectural style such as C2 20
• Under-constrained architecture
• Variance-free architecture
• Parametric architecture
• Service-oriented architectures (SOA)
• Clearly, education and practice are needed to
  select and implement a suitable architecture.

21
Architectures that Support Reuse

• More on Architectural Styles 21
• A key advantage of a software architectural style
  is that it is easy to add new products to the
  product line
• Need to confirm to the architectural style
• A disadvantage of using an architectural style is
  that it is so generic that in practice a lot of
  work may be required to develop a usable product
  architecture that adheres to the rules of the
  style.
• Please see Roy T. Fieldings paper 22 for a
  perceptive insight into architectural styles
• More on Under-constrained architecture 21
• Different from an architectural style
• Does not just define the essential architectural
  features of the product line
• Its description of the generic architecture of
  the product line is more complete, although not
  fully complete.

22
Architectures that Support Reuse

• More on Variance-free architecture 21
• Different from an under-constrained architecture
• Architecture is completely defined
• The only differences in the products are in
  design and implementation.
• For example, a differentiator could be the
  platform upon which the product is built.
• More on Parametric architecture 21
• Good example is ADA generics
• There is an a priori definition of the
  capabilities of the architecture including what
  can be parameterized
• A disadvantage of parametric architectures is
  that the product line is limited to the
  parameters that are defined.

23
Challenge Architectural Mismatch

• Garlan et al. 7 describes a class of problem,
  called architectural mismatch
• Very pervasive when building systems from
  multiple parts
• Architectural mismatch results from the
  mismatch assumptions that the reusable parts
  make about how the system is structured
• Assumptions often conflict with other assumptions
  of other parts, and these assumptions are often
  implicit rather than explicit
• Manifestation of architectural mismatches in an
  integrated system (Aesop) at Carnegie Mellon
  University
• Excessive code
• Poor performance
• Need to modify some of the reusable packages
• Need to reinvent existing functions and
  complicated tools
• High costs to make modifications

24
Challenge Architectural Mismatch

• Architectural framework an important concept
  (Shaw and Garlan 18 )
• Definition An architectural framework is a
  collection of computational components, referred
  to simply as components, together with a
  description of interactions among these
  components 18
• Interactions among components are called
  connectors.
• Clients, servers, filters, layers, and databases
  are examples of components
• Pipes, protocols, event broadcast, and procedure
  calls are examples of connectors

25
Challenge Architectural Mismatch

• Garlan et al. 7 assert that architectural
  mismatches can arise because of assumptions
  about
• Nature of components
• Nature of connectors
• The global architectural structure
• The construction process

26
Examples of Architectural Mismatch
Example 1 Concurrency Suppose component A, prior
to integration, accessed a database and was able
to read and write information to the database,
and only component A accessed the database.
Furthermore, component A is single-threaded such
that there is not the possibility of having
multiple threads access the database
simultaneously. Also suppose that component B,
in the integrated system, also needs to update
(read/write) the database. In this scenario
there would be the potential for synchronization
problems. Once detected, the problem of
synchronization could be avoided by modifying
both components so that the data being accessed
is locked when it is being used by either
component. This could be done early in the
development cycle. Please see references 43,
44 for a more extensive treatment of
concurrency. Example 2 Encapsulation Suppose
component A has objects defined and the private
data contains information, X, that component B
needs in an integrated system. Component B would
not be able to access X that is a part of
component As private data. To correct this
problem component B would have to be modified so
that X is redefined to be public.
27
Solutions for Architectural Mismatch

• Garlan et al. 7 recommend the following
• Make architectural assumptions explicit by
  documenting them
• Use orthogonal subcomponents to construct large
  pieces of software to make it easy to substitute
  subcomponents easily to test architectural
  assumptions
• Use techniques to bridge mismatches. A typical
  example is putting a wrapper around a component
• Find and use resources that provide best
  practices for architectural design

28
Solutions for Architectural Mismatch

• Boehm et al. recommend the following 1
• Analyze various architectural styles 18, 22
• Devise a set of architectural conceptual features
  that could be used to detect architectural
  mismatches early
• Idea is to
• Analyze the parts that are being used to compose
  a system
• Determine the architectural features that are
  intrinsic to the various parts
• For each architectural feature, research whether
  or not a known cause of architectural mismatch
  exists

29
Reuse Economics-Operational Benefits

• Increased development productivity is achieved
  through reuse because less input is required to
  obtain the same output 11
• Productivity is also enhanced through more
  efficient development and maintenance of code 2,
  8, 11, 17
• Increased productivity is also derived from the
  opportunity to explore multiple concepts early
  through prototyping 2, 8, 17
• The opportunity to prototype early and test
  multiple ideas as well as the opportunity to
  identify and mitigate risks early contribute to
  higher productivity also 2, 8, 17
• Productivity gains have been reported by several
  sources in industry11

30
Reuse Economics-Operational Benefits
Effect of reuse on software productivity. Source
W.C. Lim, Managing Software Reuse, Prentice
Hall, 1998, p. 107
Effect of reuse on software quality. Source
W.C. Lim, Managing Software Reuse, Prentice
Hall, 1998, p. 106
31
Reuse Economics-Operational Benefits 11

• In resource-limited situations, every
  organization must decide how to allocate its
  limited resources to produce a certain set of
  outputs.
• A concave curve viewed from the origin, is called
  a production-possibility frontier and shows the
  organizations menu of choices for quality and
  productivity.
• This production-possibility frontier curve
  assumes that the resources of the organization
  are fully and efficiently employed .

Tradeoff between quality and productivity. Source
W.C. Lim, Managing Software Reuse, Prentice
Hall, 1998, p. 108
32
Reuse Economics-Operational Benefits 11

• Note shift of the production-possibility frontier
  to the right
• Illustrates that with reuse a higher level of
  quality can be achieved with the same level of
  productivity
• Similarly, a higher level of productivity can be
  achieved for the same level of quality
• Simultaneous increase in quality and productivity

Reuse allows increased quality and /or
productivity levels. Source W.C. Lim, Managing
Software Reuse, Prentice Hall, 1998, p. 109
33
Reuse-Economic Benefits 2, 8, 11, 17

• Cost reduction. Costs are reduced because less
  investment of time and resources are required to
  design, develop and maintain the product,
  resulting in shorter software life cycles.
• Cost avoidance. Costs are avoided such as the
  hiring of technical people since inherent in
  reuse is the leverage of technical skills and
  knowledge.
• Increased Profit. This follows naturally from
  reducing costs as well as the other operational
  benefits mentioned earlier.
• A reduction in cost as well as a reduction in
  time-to-market can result in achieving higher
  sales.
• Reduced number of people on a project. An
  organization can put people who would otherwise
  be on the project on other projects.

34
Reuse Costs

• Costs are incurred while doing a feasibility
  study
• Tools to aid in reuse need to be purchased
• Once there is a commitment for reuse, personnel
  with the appropriate level of skill need to be
  hired and trained
• As observed by Boehm 2, there is an additional
  cost for the creation, development, and
  maintenance of reusable assets
• The COCOMO II model 4 estimates the following
  costs for the different types of reuse2
• Add 10 if the software will only be reused
  across an individual project.
• Add 30 if the software will only be reused
  across an individual product line.
• Add 50 if the software will only be reused
  across multiple product lines. 

35
Reuse Costs 2, 8, 11, 17

• Another potential cost is performance
  degradation
• For example, a reusable component may not meet
  the performance requirements of a
  high-performance system
• There is always the risk of obsolete assets
• This can occur, for example, if a reusable asset
  does not support a required platform such as
  Microsoft Windows XP
• Reusable software can pose a security risk
• Some of the designs in a reusable asset may be
  proprietary or may contain trade secrets

36
SECTION 3

• SOA Motivation Benefits

37
What is SOA? First, Understand Tight Coupling

• Data and functionality typically reside on more
  than one system (and application)

• Applications need to be able to talk to each
  other

• Status quo Proprietary or custom communication
  interfaces between applications

Source H. Taylor, Service-Oriented Architecture
(SOA) 101 Whats Hype, Whats Real?, Juniper
Networks, Inc.,2007.
38
Challenges with Tight Coupling

• While tight coupling is inherently sound, the
  following challenges are encountered in its
  implementation
• Its costly to maintain
• Slow and costly to change
• Cost and complexity compounded by multi-party
  scenarios such as B2B or integration with the
  public sector
• Cost and complexity of managing and changing a
  tightly coupled architecture translates into IT
  being a drag on business agility (IT cant keep
  up with business needs, but its not their fault)
• Recognized for many years as a challenge the
  industry wanted to solve
• Many previous attempts to create an SOA
• CORBA (Common Object Request Broker Architecture)
  
• COM (Component Object Model)
• EAI (Enterprise Application Integration )
• Reasons they did not work
• Lack of open standards
• Proprietary components

Source H. Taylor, Service-Oriented Architecture
(SOA) 101 Whats Hype, Whats Real?, Juniper
Networks, Inc.,2007.
39
Example of SOA Using CORBA

• SOA has evolved from using technologies such as
  CORBA (Common Object Request Broker Architecture)
  to using Web services
• Tier1 belongs to traditional Web browsers and
  Web-centric applications
• Tier 2 runs on any server that can support HTTP
  and CORBA clients
• CORBA objects, like EJBs, encapsulate business
  logic
• Tier 3 consists of almost anything a CORBA object
  can access

The 3-Tier CORBA/Java Object Web. Source
Client/Server Programming with JAVA and CORBA
Second Edition by R. Orfali and D.
Harkey, p. 45.
40
SOA The Ideal of Open Interoperability (Loose
Coupling)

• SOA A Definition
• An IT architecture composed of software that has
  been exposed as Services i.e. invoked on
  demand using a standard communication protocol.
• Web Services software available as a
  service using Internet protocols.
• One software application talking to another using
  a standards-based (i.e. non-proprietary) language
  over a standards-based communication protocol.
• Universal Dial Tone between software
  applications
• An IT architecture that enables loose coupling
  of applications

Source H. Taylor, Service-Oriented Architecture
(SOA) 101 Whats Hype, Whats Real?, Juniper
Networks, Inc.,2007.
41
Core SOA Definitions

• XML Extensible Markup Language
• SOAP Simple Object Access Protocol
• WSDL Web Services Description Language
• UDDI - Universal Description, Discovery and
  Integration
• ESB Enterprise Service Bus
• Key Concepts
• Network Transparency
• Virtualized endpoint
• Self-describing software
• Universally discoverable software
• Universally understood software
• Machine to machine interaction

Source H. Taylor, Service-Oriented Architecture
(SOA) 101 Whats Hype, Whats Real?, Juniper
Networks, Inc.,2007.
42
How SOA is Used

• B2B
• EAI
• Application to Application
• Government

Source H. Taylor, Service-Oriented Architecture
(SOA) 101 Whats Hype, Whats Real?, Juniper
Networks, Inc.,2007.
43
Tomorrows e-business Architecture

• Figure illustrates Enterprise B accessing
  Enterprise As Inventory Web Service
• Both enterprises access an authentication Web
  service provided by an external provider.
• Enterprises separately access Web services that
  provide payment and logistics services.

Tomorrows e-business solution architecture. Sourc
e Mobility, Security and Web Services
Technologies and Service-Oriented
Architectures for a new Era of IT Solutions by
Gerhard Wiehler, p. 46.
44
Service Oriented Architecture

• Figure illustrates tomorrows e-business solution
  architecture
• 4 stakeholders communicate via Web services
• Suppliers
• Customers
• Enterprise
• Employees

Tomorrows e-business solution architecture. Sourc
e Mobility, Security and Web Services
Technologies and Service-Oriented
Architectures for a new Era of IT Solutions by
Gerhard Wiehler, p. 46.
45
SOA Example Gift Cards
Source H. Taylor, Service-Oriented Architecture
(SOA) 101 Whats Hype, Whats Real?, Juniper
Networks, Inc.,2007.
46
Effect of Tight Coupling on Business Process
Source H. Taylor, Service-Oriented Architecture
(SOA) 101 Whats Hype, Whats Real?, Juniper
Networks, Inc.,2007.
47
How SOA Can Improve a Tight Coupling Situation
Source H. Taylor, Service-Oriented Architecture
(SOA) 101 Whats Hype, Whats Real?, Juniper
Networks, Inc.,2007.
48
Major Players in SOA Space

• IBM WebSphere SOA Product Suite
• BEA Aqualogic
• Oracle Fusion Middleware
• Microsoft .NET
• SAP NetWeaver

Source H. Taylor, Service-Oriented Architecture
(SOA) 101 Whats Hype, Whats Real?, Juniper
Networks, Inc.,2007.
49
SOA All Hype?

• In a profound sense, the industry hype about SOA
  is actually true.
• It does work
• It is being used in major deployments
• It does cut costs and enable agility
• Its an incremental shift that is possible to
  adopt without scrapping earlier IT efforts

Source H. Taylor, Service-Oriented Architecture
(SOA) 101 Whats Hype, Whats Real?, Juniper
Networks, Inc.,2007.
50
SOA Is Not a Silver Bullet

• Assumes costs and challenges inherent in reuse
• SOA does not make politics go away
• Your IT organization still has to master it
• Governance is a major challenge
• Security can be a big issue
• Vendors may not necessarily cooperate in an
  effort that commoditizes their products
• Vendors may be embedded in your organization,
  rendering some of the theoretical benefits of SOA
  moot
• Getting started with SOA may require longer and
  more expensive project cycles the first time
  around
• Need high reuse potential reuse aptitude
• Some SOA standards are still immature, leading to
  confusion and vendor-driven proprietary creep

Source H. Taylor, Service-Oriented Architecture
(SOA) 101 Whats Hype, Whats Real?, Juniper
Networks, Inc.,2007.
51
SECTION 4

• Industry Examples of SOA
• Verizon
• Fortune 50 Financial Services
• Global Consumer Brand Company
• Pfizer
• Sempra Energy

52
Verizon IT Workbench

• Between 2.5 and 3 million transactions per day
• Up from 10,000 transactions per day at the start
  of 2004
• Customer information search
• New service request
• Customer credit history
• Cut IT budget significantly
• Reduced duplication of resources from an average
  of 25x
• Built 57 applications in year 1 (vs. a target of
  10)
• Enabled 200 services in year 1

Source H. Taylor, Service-Oriented Architecture
(SOA) 101 Whats Hype, Whats Real?, Juniper
Networks, Inc.,2007.
53
Verizon IT Workbench
Source H. Taylor, Service-Oriented Architecture
(SOA) 101 Whats Hype, Whats Real?, Juniper
Networks, Inc.,2007.
54
SOA Inc., Service Manager
Source H. Taylor, Service-Oriented Architecture
(SOA) 101 Whats Hype, Whats Real?, Juniper
Networks, Inc.,2007.
55
Fortune 50 Financial Services

• Problem/Issues
• Is driving new business models through trading
  partner integration
• Membership rewards points as online currency
• Stored value cards (Best Buy, Dell)
• Retail web sites selling insurance (COSTCO)
• How to encourage partners to securely connect to
  company systems and services
• SOA Software Solution
• SOA Software Partner Manager (Now Service
  Manager)
• Controller hosted by IBM Global Services
• Appliances at company
• Software proxies at partners (moving to
  appliances)
• Rapid, low-cost provisioning of secure XML
  communications between partners. Reduced partner
  onramp time by 90

Source H. Taylor, Service-Oriented Architecture
(SOA) 101 Whats Hype, Whats Real?, Juniper
Networks, Inc.,2007.
56
Global Consumer Brand Company

• Problem/Issues
• Managing and securing Web services across a
  global enterprise
• Assuring scalability and performance of SOA in a
  demanding, high load production environment
• Interoperation between WebSphere Application
  Server and Oracle Databases
• SOA Software Solution
• Successful deployment of SOA infrastructure,
  using SOA Software Service Manager product suite
• Console
• Management Point
• Registry
• Policy Manager
• Alert Manager

Source H. Taylor, Service-Oriented Architecture
(SOA) 101 Whats Hype, Whats Real?, Juniper
Networks, Inc.,2007.
57
Pfizer SOA

• Problem/Issues
• Pfizer Global Pharmaceuticals Group (PGP) needed
  a secure SOA infrastructure to leverage a growing
  number of Web services and deliver shared
  services from numerous, heterogeneous
  applications residing in different business
  groups
• PGP needed its SOA to work with its existing
  technologies, including Java Connection
  Architecture and BEA WebLogic
• SOA Software Solution
• Network Director enables shared services to be
  consumed by multiple lines of business across the
  world, regardless of disparate technologies
• Network Director enables leveraging existing data
  across multiple processes, establishing
  consistent standards for IT systems, and
  preserving the value of existing IT assets
• Using Network Director, PGP can maintain and
  enforce consistent policies across their
  computing infrastructure, which is critical to
  making shared services usable enterprise-wide
• PGP established its Approvals Portal using
  Network Director and BEA WebLogic, which made an
  immediate and tangible impact on operations by
  eliminating several separate portals that were
  required for executive approvals of invoices and
  expenses

Source H. Taylor, Service-Oriented Architecture
(SOA) 101 Whats Hype, Whats Real?, Juniper
Networks, Inc.,2007.
58
Pfizer SOA
Source H. Taylor, Service-Oriented Architecture
(SOA) 101 Whats Hype, Whats Real?, Juniper
Networks, Inc.,2007.
59
Sempra HR Portal

• Problem/Issues
• Enable a secure HR portal for employees
  customers
• Extensive IBM Mainframe integration
• Strict security requirements due to nature of the
  industry
• SOA Software Solution
• Services Group design, build and deploy identity
  management solution for HR portal and backend
  services
• Web services used to integrate HR portal with
  mainframe and other systems, both within Sempra
  and over the Internet
• Management Server for Web services Management and
  Security
• Central Registry of Services
• Security Policy Enforcement
• SLA Management

Source H. Taylor, Service-Oriented Architecture
(SOA) 101 Whats Hype, Whats Real?, Juniper
Networks, Inc.,2007.
60
SECTION 5

• References

61
References

1. B.W. Boehm and C. Gacek, Composing Components
   How Does One Detect Potential Architectural
   Mismatches?, USC Center for Software
   Engineering, Los Angeles, CA, 1999.
2. B.W. Boehm and W.L. Scherlis, Megaprogramming,
   Proceedings of the DARPA Software technology
   Conference, April 1992 (available via USC Center
   for Software Engineering, Los Angeles, CA,
   90089-0781).
3. B.W. Boehm, Software Engineering Economics,
   Prentice Hall, Englewood Cliffs, N.J., 1981.
4. B.W. Boehm, C. Abts, A.W. Brown, S. Chulani, B.K.
   Clark, E. Horowitz, R. Madachy, D. Reifer, and B.
   Steece, Software Cost Estimation with COCOMO II,
   Prentice Hall, Upper Saddle River, N.J., 2000.
5. Carnegie Mellon University, Software Engineering
   Institute (M.C. Pauk, C.V. Weber, B. Curtis, and
   M.B. Chrissis). The Capability Maturity Model
   Guidelines for Improving the Software Process,
   Addison-Wesley, 1999.
6. F. DeRemer and H.H. Kron. Programming
   in-the-large versus programming-in-the-small,
   IEEE Transactions on Software Engineering,
   SE-2(2), June 1976, pp. 80-86.
7. D. Garlan, R. Allen, and J. Ockerbloom.
   Architectural Mismatch Why Reuse Is So Hard,
   Software, IEEE Computer Society, November 1995,
   pp. 17-26.
8. E.M. Hall, Managing Risk Methods for Software
   Systems Development, Addison-Wesley, 1998.
9. W.S. Humphrey, Managing the Software Process,
   Addison-Wesley, 1989.
10. I.M. Jacobson and P. Jonsson, Software Reuse
    Architecture, Process, and Organization for
    Business Success, Addison-Wesley, 1997.
11. W.C. Lim, Managing Software Reuse, Prentice
    Hall, 1998
12. S. Vinoski, CORBA Integrating Diverse
    Applications Within Distributed Heterogeneous
    Environments, IEEE Transactions on Software
    Engineering, 1996.
13. D. J. Reifer, Making the Software Business Case,
    Addison-Wesley, Upper Saddle River, N.J., 2000.
14. J.S. Poulin, Measuring Software Reuse
    Principles, Practices, and Economic Models,
    Addison-Wesley, 1997.
15. D.J. Reifer, Practical Software Reuse, John Wiley
    Sons, 1997.
16. C.K. Prahalad and G. Hatmel The Core Competence
    of the Corporation, Harvard Business Review,
    May-June, 1990.
17. B.W. Boehm, Software Risk Management Principles
    and Practices, IEEE Transactions on Software
    Engineering, January 1991, pp. 32-41.
18. M. Shaw and D. Garlan, Software Architecture
    Perspectives On An Emerging Discipline, Prentice
    Hall, Upper Saddle River, N.J., 1996.
19. C.J. Date, An Introduction to Database Systems
    Volume II, Addison-Wesley, 1983.

62
References

1. R. T. Fielding, Software Architectural Styles
   for Network-based Applications, University of
   California, Irvine, July 15, 1999.
2. B.W. Boehm and T.A. Standish, Software
   Technology in the 1990s using an evolutionary
   paradigm, Computer, vol. 16, pp. 30-7, 1983.
3. Failed technology projects(The Standish Group
   Report), in Investors Business Daily. Los
   Angeles, Jan. 1995, pp. A8.
4. B. Bongard, B. Gronquist, and D. Ribot, "Impact
   of Reuse on Organizations," Cap Gemini
   Innovation, Esprit project REBOOT, Grenoble,
   France, Sept. 4, 1992.
5. N. Buxton and R. Malcolm, "Software technology
   transfer," Software Engineering journal, vol. 6,
   no.1, pp. 17-23, Jan., 1991.
6. G. Caldiera, "Domain Factory and Software
   Reusability," Software Engineering Symposium New
   Frontiers for Software Maintenance, May, 1991.
7. T. Durek, "Strategies and Tactics for Software
   Reuse Tutorial," presented at Improving the
   Software Process and Competitive Position via
   Software Reuse and Reengineering, Alexandria, V
   A, 1991.
8. R. Holibaugh, s. Cohen, K. Kang, and S. Peterson,
   "Reuse where to begin and why," Proceedings.
   TRI-Ada '89, pp. 266-77, Oct. 23-26,1989.
9. R. Joos, "Software Reuse in an Industrial
   Setting," 4th Annual Workshop on Software Reuse,
   Nov.18-22, 1991.
10. D. Parkhill, "Object-oriented technology
    transfer techniques and guidelines for a smooth
    transition," Object Magazine, pp. 57-59,
    May/June, 1992.
11. R. Prieto-Diaz, "Making software reuse work an
    implementation model," SIGSOFT Software
    Engineering Notes, vol. 16, no.3, pp. 61-8, July,
    1991.
12. "Reuse adoption guidebook," Software
    Productivity Consortium, Hemdon, VA,
    SPC-92051-CMC, Version 01.00.03, Nov., 1992.
13. "Software Reuse Guidelines," U.S. Army
    Information Systems Engineering Command (USAISE),
    ASQB-GI-90-015, Apr ., 1990.
14. B. Whittle, W. Lam, and T. Kelly, A pragmatic
    approach to reuse introduction in an industrial
    setting," Systematic Reuse Issues in Initiating
    and Improving a Reuse Program. Proceedings of the
    International Workshop on Systematic Reuse, pp.
    104-15, 1996.
15. T. J. Biggerstaff, " An Assessment and Analysis
    of Software Reuse " in Advances in Computers,
    vol. 34, M. C. Yovits, Ed., New York, N. Y .
    Academic Press, 1992
16. T. Davis, "Adopting a policy of reuse," IEEE
    Spectrum, vol. 31, pp. 44-8, June 1994.
17. W. B. Frakes and C. J. Fox, "Sixteen questions
    about software reuse," Communications of the ACM,
    vol. 38, pp. 75-87, 112, June 1995.
18. A. J. Incorvaia, A. M. Davis, and R. E. Fairley,
    "Case studies in software reuse," presented at
    Fourteenth Annual International Computer Software
    and Applications Conference (Cat. No.90CH2923-1
    ), 1990.
19. R. M. Sonnemann, "Exploratory study of software
    reuse success," Ph.D. dissertation, Dep.
    Engineering, George Mason University, Fairfax,
    VA, 1996.

63
References

1. E.M. Rogers, Diffusion of Innovations, Simon
   Schuster, 1995.
2. B.W. Boehm, Competing on Schedule, Cost, and
   Quality  The Role of Software Models, USC Center
   for Software Engineering, August, 2001.
3. C.J. Date, An Introduction to Database Systems
   Volume II, Addison-Wesley, 1983.
4. A. S. Tanenbaum, Distributed Operating Systems,
   Prentice Hall, 1995.
5. T. B. Bollinger and S. L. Pfleeger, "The
   Economics of Software Reuse," Contel Technology
   Center, Chantilly, VA, Tech. Report
   CTC-TR-89-014, Dec. 13, 1989
6. J. E. Gaffney and T. A. Durek, "Software
   Reuse-Key to Enhanced Productivity Some
   Quantitative Models, Software Productivity
   Consortium, Herndon, V A, Tech. Report SPC-
   TR-88-015, Apr., 1988.
7. E. Guerrieri, L. A. Lashway, and T. B.
   Ruegsegger, "An Acquisition Strategy for
   Populating a Software Reuse Library," National
   Conference on Software Reusability, July 19-20,
   1989.
8. W. C. Lim, A Cost-Justification Model for
   Software Reuse," 5th Annual Work- this shop for
   Institutionalizing Software Reuse, Oct. 26-29,
   1992.
9. R. A. Malan and K. Wentzel, "Economics of Reuse
   Revisited," Hewlett Packard Laboratories, Palo
   Alto, CA, Technical Report, HPL-93-31, Apr.,
   1993.
10. J. S. Poulin and J. M. Caruso, "A reuse metrics
    and return on investment model," Proceedings
    Advances in Software Reuse. Selected Papers from
    the Second International Workshop on Software
    Reusability (Cat. No. 93THO495- 2), pp. 152-66,
    Mar. 24-26, 1993.
11. B. Bloom, Deploying and Managing Microsoft .NET
    Web Farms, Sams Publishing, 2001.
12. H. Taylor, Service-Oriented Architecture (SOA)
    101 Whats Hype, Whats Real?, Juniper
    Networks, Inc.,2007.
13. Wiehler, Gerard. Mobility, Security and Web
    Services Technologies and Service-Oriented
    Architectures for a new Era of IT Solutions.
    Publicis Corporate Publishing, 2004.
14. Pulier, Eric and Hugh Taylor. Understanding
    Enterprise SOA. Manning Publications Co., 2006.

64
About SOA Software
SOA Software is the leading provider of
comprehensive enterprise class Integrated SOA
Governance solutions. It is the largest
specialist vendor of SOA lifecycle management,
registry/repository, security, mediation and
management solutions, and the only company that
offers a comprehensive SOA infrastructure
solution that can govern Web Services on all
major platforms. SOA Software products provide a
comprehensive closed-loop SOA governance solution
(Workbench), a high-performance, scalable SOA
management and security solution (Service
Manager), and a mainframe Web services solution
for CICS applications (SOLA). SOA Software
products process over 500 million mission
critical transactions a month and are used by the
largest Fortune 1000 corporations, including
Merrill Lynch, Verizon, and Pfizer. SOA
Software is a privately held company backed by
leading investors including Redpoint, Draper
Fisher Jurvetson, Palisades Ventures Fund,
Paladin Capital Group, and Goldman Sachs.