Service oriented architecture
This presentation is the property of its rightful owner.
Sponsored Links
1 / 64

Service Oriented Architecture PowerPoint PPT Presentation


  • 77 Views
  • Uploaded on
  • Presentation posted in: General

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. Personal Information. Director of Software Engineering, SOA Software

Download Presentation

Service Oriented Architecture

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Service oriented architecture

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


Personal information

Personal Information

  • Director of Software Engineering, SOA Software

  • 20 plus years in software development

  • MBA, Marshall School of Business

  • MS, Viterbi School of Engineering


Agenda objectives

Agenda & Objectives

  • Agenda

    • Section 1–Driving forces for increase in investment in software

    • Section 2–Discussion on general reuse

    • Section 3–SOA, motivation & benefits

    • Section 4–Industry 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


Section 1

SECTION 1

Driving Forces for Increase in Investment in Software Development


Driving forces for investment

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


Driving forces cont d

Driving Forces Cont’d

  • 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]


Insights on risk management

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


Insights on risk management1

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


Strategies for faster development

Strategies for Faster Development

  • Outsourcing

  • Commercial-Off-The-Shelf (COTS)

  • Acquisitions

  • Reuse


Overview of outsourcing

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


Overview of cots acquisitions

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


Overview of reuse

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


Section 2

SECTION 2

Discussion on General Reuse


Diffusion of innovation

Diffusion of Innovation

  • Organizations face two innovation issues at the same time when developing software:[11, 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


Diffusion of innovation1

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


Diffusion of innovation2

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


Need for radical paradigm shift

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.


  • Need for radical paradigm shift1

    Need for Radical Paradigm Shift

    • Required paradigm shift (Boehm et al. [2], Lim[11]):

      • 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


    Architectural considerations

    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


    Architectural considerations1

    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.


    Architectures that support reuse

    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. Fielding’s 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.


    Architectures that support reuse1

    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.


    Challenge architectural mismatch

    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 implicitrather 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


    Challenge architectural mismatch1

    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


    Challenge architectural mismatch2

    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


    Examples of architectural mismatch

    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 A’s private data. To correct this problem component B would have to be modified so that X is redefined to be public.


    Solutions for architectural mismatch

    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


    Solutions for architectural mismatch1

    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


    Reuse economics operational benefits

    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 industry[11]


    Reuse economics operational benefits1

    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


    Reuse economics operational benefits 11

    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 organization’s 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


    Reuse economics operational benefits 111

    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


    Reuse economic benefits 2 8 11 17

    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.


    Reuse costs

    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 reuse[2]:

      • 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. 


    Reuse costs 2 8 11 17

    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


    Section 3

    SECTION 3

    SOA: Motivation & Benefits


    What is soa first understand tight coupling

    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 ‘What’s Hype, What’s Real?’“, Juniper Networks, Inc.,2007.


    Challenges with tight coupling

    Challenges with Tight Coupling

    • While tight coupling is inherently sound, the following challenges are encountered in its implementation:

      • It’s 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 can’t keep up with business needs, but it’s 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 ‘What’s Hype, What’s Real?’“, Juniper Networks, Inc.,2007.


    Example of soa using corba

    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.


    Soa the ideal of open interoperability loose coupling

    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 ‘What’s Hype, What’s Real?’“, Juniper Networks, Inc.,2007.


    Core soa definitions

    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 ‘What’s Hype, What’s Real?’“, Juniper Networks, Inc.,2007.


    How soa is used

    How SOA is Used

    • B2B

    • EAI

    • Application to Application

    • Government

    Source: H. Taylor, “Service-Oriented Architecture (SOA) 101 ‘What’s Hype, What’s Real?’“, Juniper Networks, Inc.,2007.


    Tomorrow s e business architecture

    Tomorrow’s e-business Architecture

    • Figure illustrates Enterprise B accessing Enterprise A’s 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.

    Tomorrow’s e-business solution architecture.

    Source: Mobility, Security and Web Services: Technologies and

    Service-Oriented Architectures for a new Era of IT Solutions by Gerhard Wiehler, p. 46.


    Service oriented architecture1

    Service Oriented Architecture

    • Figure illustrates tomorrow’s e-business solution architecture

    • 4 stakeholders communicate via Web services

      • Suppliers

      • Customers

      • Enterprise

      • Employees

    Tomorrow’s e-business solution architecture.

    Source: Mobility, Security and Web Services: Technologies and

    Service-Oriented Architectures for a new Era of IT Solutions by Gerhard Wiehler, p. 46.


    Service oriented architecture

    Approve

    Sale

    Display

    No Auth

    Message

    Cashier

    Swipes

    Card @ POS

    Retail

    POS

    ID #

    Compared

    To record

    Debit

    Card

    Balance

    Gift Card

    Processor

    Authorize?

    Post sale

    To GL

    Retail

    General

    Ledger

    SOA Example – Gift Cards

    Source: H. Taylor, “Service-Oriented Architecture (SOA) 101 ‘What’s Hype, What’s Real?’“, Juniper Networks, Inc.,2007.


    Service oriented architecture

    Effect of Tight Coupling on

    Business Process

    Source: H. Taylor, “Service-Oriented Architecture (SOA) 101 ‘What’s Hype, What’s Real?’“, Juniper Networks, Inc.,2007.


    Service oriented architecture

    How SOA Can Improve a Tight Coupling Situation

    Source: H. Taylor, “Service-Oriented Architecture (SOA) 101 ‘What’s Hype, What’s Real?’“, Juniper Networks, Inc.,2007.


    Major players in soa space

    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 ‘What’s Hype, What’s Real?’“, Juniper Networks, Inc.,2007.


    Soa all hype

    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

      • It’s an incremental shift that is possible to adopt without scrapping earlier IT efforts

    Source: H. Taylor, “Service-Oriented Architecture (SOA) 101 ‘What’s Hype, What’s Real?’“, Juniper Networks, Inc.,2007.


    Soa is not a silver bullet

    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 ‘What’s Hype, What’s Real?’“, Juniper Networks, Inc.,2007.


    Section 4

    SECTION 4

    Industry Examples of SOA

    Verizon

    Fortune 50 Financial Services

    Global Consumer Brand Company

    Pfizer

    Sempra Energy


    Verizon it workbench

    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 ‘What’s Hype, What’s Real?’“, Juniper Networks, Inc.,2007.


    Verizon it workbench1

    Verizon • IT Workbench

    Source: H. Taylor, “Service-Oriented Architecture (SOA) 101 ‘What’s Hype, What’s Real?’“, Juniper Networks, Inc.,2007.


    Soa inc service manager

    SOA Inc., Service Manager

    Source: H. Taylor, “Service-Oriented Architecture (SOA) 101 ‘What’s Hype, What’s Real?’“, Juniper Networks, Inc.,2007.


    Fortune 50 financial services

    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 ‘What’s Hype, What’s Real?’“, Juniper Networks, Inc.,2007.


    Global consumer brand company

    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 ‘What’s Hype, What’s Real?’“, Juniper Networks, Inc.,2007.


    Service oriented architecture

    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 ‘What’s Hype, What’s Real?’“, Juniper Networks, Inc.,2007.


    Service oriented architecture

    Pfizer • SOA

    Source: H. Taylor, “Service-Oriented Architecture (SOA) 101 ‘What’s Hype, What’s Real?’“, Juniper Networks, Inc.,2007.


    Service oriented architecture

    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 ‘What’s Hype, What’s Real?’“, Juniper Networks, Inc.,2007.


    Section 5

    SECTION 5

    References


    References

    References

    • B.W. Boehm and C. Gacek, “Composing Components: How Does One Detect Potential Architectural Mismatches?,” USC Center for Software Engineering, Los Angeles, CA, 1999.

    • 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).

    • B.W. Boehm, Software Engineering Economics, Prentice Hall, Englewood Cliffs, N.J., 1981.

    • 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.

    • 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.

    • 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.

    • D. Garlan, R. Allen, and J. Ockerbloom. “Architectural Mismatch: Why Reuse Is So Hard,” Software, IEEE Computer Society, November 1995, pp. 17-26.

    • E.M. Hall, Managing Risk: Methods for Software Systems Development, Addison-Wesley, 1998.

    • W.S. Humphrey, Managing the Software Process, Addison-Wesley, 1989.

    • I.M. Jacobson and P. Jonsson, Software Reuse: Architecture, Process, and Organization for Business Success, Addison-Wesley, 1997.

    • W.C. Lim, Managing Software Reuse, Prentice Hall, 1998

    • S. Vinoski, “CORBA: Integrating Diverse Applications Within Distributed Heterogeneous Environments,” IEEE Transactions on Software Engineering, 1996.

    • D. J. Reifer, Making the Software Business Case, Addison-Wesley, Upper Saddle River, N.J., 2000.

    • J.S. Poulin, Measuring Software Reuse: Principles, Practices, and Economic Models, Addison-Wesley, 1997.

    • D.J. Reifer, Practical Software Reuse, John Wiley & Sons, 1997.

    • C.K. Prahalad and G. Hatmel “The Core Competence of the Corporation,” Harvard Business Review, May-June, 1990.

    • B.W. Boehm, “Software Risk Management: Principles and Practices,” IEEE Transactions on Software Engineering, January 1991, pp. 32-41.

    • M. Shaw and D. Garlan, Software Architecture: Perspectives On An Emerging Discipline, Prentice Hall, Upper Saddle River, N.J., 1996.

    • C.J. Date, An Introduction to Database Systems Volume II, Addison-Wesley, 1983.

    • R.N. Taylor, N. Medvidovic, K.M. Anderson, E. J. Whitehead Jr., J.E. Robbins, K.A. Nies, P. Oreizy, and D. L. Dubrow, “A Component-and Message-Based Architectural Style for GUI Software.” (Not published in any paper)

    • D. E. Perry, “Generic Architecture Descriptions for Product Lines,” Bell Laboratories, Murray Hill, N.J. (Not published in any paper)


    References1

    References

    • R. T. Fielding, “Software Architectural Styles for Network-based Applications,” University of California, Irvine, July 15, 1999.

    • B.W. Boehm and T.A. Standish, “Software Technology in the 1990’s: using an evolutionary paradigm,” Computer, vol. 16, pp. 30-7, 1983.

    • “Failed technology projects(The Standish Group Report),” in Investor’s Business Daily. Los Angeles, Jan. 1995, pp. A8.

    • B. Bongard, B. Gronquist, and D. Ribot, "Impact of Reuse on Organizations," Cap Gemini Innovation, Esprit project REBOOT, Grenoble, France, Sept. 4, 1992.

    • N. Buxton and R. Malcolm, "Software technology transfer," Software Engineering journal, vol. 6, no.1, pp. 17-23, Jan., 1991.

    • G. Caldiera, "Domain Factory and Software Reusability," Software Engineering Symposium: New Frontiers for Software Maintenance, May, 1991.

    • 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.

    • 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.

    • R. Joos, "Software Reuse in an Industrial Setting," 4th Annual Workshop on Software Reuse, Nov.18-22, 1991.

    • D. Parkhill, "Object-oriented technology transfer: techniques and guidelines for a smooth transition," Object Magazine, pp. 57-59, May/June, 1992.

    • R. Prieto-Diaz, "Making software reuse work: an implementation model," SIGSOFT Software Engineering Notes, vol. 16, no.3, pp. 61-8, July, 1991.

    • "Reuse adoption guidebook," Software Productivity Consortium, Hemdon, VA, SPC-92051-CMC, Version 01.00.03, Nov., 1992.

    • "Software Reuse Guidelines," U.S. Army Information Systems Engineering Command (USAISE), ASQB-GI-90-015, Apr ., 1990.

    • 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.

    • 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

    • T. Davis, "Adopting a policy of reuse," IEEE Spectrum, vol. 31, pp. 44-8, June 1994.

    • W. B. Frakes and C. J. Fox, "Sixteen questions about software reuse," Communications of the ACM, vol. 38, pp. 75-87, 112, June 1995.

    • 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.

    • R. M. Sonnemann, "Exploratory study of software reuse success," Ph.D. dissertation, Dep. Engineering, George Mason University, Fairfax, VA, 1996.


    References2

    References

    • E.M. Rogers, Diffusion of Innovations, Simon & Schuster, 1995.

    • B.W. Boehm, Competing on Schedule, Cost, and Quality : The Role of Software Models, USC Center for Software Engineering, August, 2001.

    • C.J. Date, An Introduction to Database Systems Volume II, Addison-Wesley, 1983.

    • A. S. Tanenbaum, Distributed Operating Systems, Prentice Hall, 1995.

    • 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

    • 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.

    • 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.

    • W. C. Lim, “A Cost-Justification Model for Software Reuse," 5th Annual Work- this shop for Institutionalizing Software Reuse, Oct. 26-29, 1992.

    • R. A. Malan and K. Wentzel, "Economics of Reuse Revisited," Hewlett Packard Laboratories, Palo Alto, CA, Technical Report, HPL-93-31, Apr., 1993.

    • 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.

    • B. Bloom, Deploying and Managing Microsoft .NET Web Farms, Sams Publishing, 2001.

    • H. Taylor, “Service-Oriented Architecture (SOA) 101 ‘What’s Hype, What’s Real?’“, Juniper Networks, Inc.,2007.

    • Wiehler, Gerard. Mobility, Security and Web Services: Technologies and Service-Oriented Architectures for a new Era of IT Solutions. Publicis Corporate Publishing, 2004.

    • Pulier, Eric and Hugh Taylor. Understanding Enterprise SOA. Manning Publications Co., 2006.


    About soa software

    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.


  • Login