Service Oriented Architecture - PowerPoint PPT Presentation


Title: 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.
View by Category
About This Presentation
Title:

Service Oriented Architecture

Description:

Service Oriented Architecture Presentation to CSCSI 510 Class University of Southern California, Viterbi School of Engineering November 21, 2007 – PowerPoint PPT presentation

Number of Views:185
Avg rating:3.0/5.0
Slides: 65
Provided by: J751
Learn more at: http://sunset.usc.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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.
About PowerShow.com