service oriented architecture

64
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

Upload: eithne

Post on 21-Jan-2016

34 views

Category:

Documents


0 download

DESCRIPTION

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 - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Service Oriented Architecture

Service Oriented Architecture

Presentation to CSCSI 510 ClassUniversity of Southern California, Viterbi School of EngineeringNovember 21, 2007Presenter: Len CayetanoProfessor: Dr. Barry Boehm

Page 2: Service Oriented Architecture

L. Cayetano-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

Page 3: Service Oriented Architecture

L. Cayetano-3

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

Page 4: Service Oriented Architecture

SECTION 1

Driving Forces for Increase in Investment in Software Development

Page 5: Service Oriented Architecture

L. Cayetano-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

Page 6: Service Oriented Architecture

L. Cayetano-6

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]

Page 7: Service Oriented Architecture

L. Cayetano-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

Page 8: Service Oriented Architecture

L. Cayetano-8

Insights on Risk Management

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

Synthesis of Risk Exposure for Product Development [17,42]

Page 9: Service Oriented Architecture

L. Cayetano-9

Strategies for Faster Development

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

Page 10: Service Oriented Architecture

L. Cayetano-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

Page 11: Service Oriented Architecture

L. Cayetano-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

Page 12: Service Oriented Architecture

L. Cayetano-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

Page 13: Service Oriented Architecture

SECTION 2

Discussion on General Reuse

Page 14: Service Oriented Architecture

L. Cayetano-14

Diffusion of Innovation Organizations face two innovation issues at the same

time when developing software:[11, 26]

1. Introduction of software technology into well-established products

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

Page 15: Service Oriented Architecture

L. Cayetano-15

Diffusion of Innovation

Figure 2: Adopter Categorization on the Basis of Innovativeness

Source: E.M. Rogers, Diffusion of Innovations, Simon & Schuster, 1995, p. 262

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

Page 16: Service Oriented Architecture

L. Cayetano-16

Diffusion of Innovation

Figure 3: Process By Which Innovation is Diffused Source: E.M. Rogers, Diffusion of Innovations, Simon & Schuster, 1995, p. 11

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

Page 17: Service Oriented Architecture

L. Cayetano-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.

Page 18: Service Oriented Architecture

L. Cayetano-18

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

Page 19: Service Oriented Architecture

L. Cayetano-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

Page 20: Service Oriented Architecture

L. Cayetano-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. 1. Software architectural style such as C2 [20] 2. Under-constrained architecture3. Variance-free architecture4. Parametric architecture5. Service-oriented architectures (SOA)

Clearly, education and practice are needed to select and implement a suitable architecture.

Page 21: Service Oriented Architecture

L. Cayetano-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. 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.

Page 22: Service Oriented Architecture

L. Cayetano-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.

Page 23: Service Oriented Architecture

L. Cayetano-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

Page 24: Service Oriented Architecture

L. Cayetano-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

Page 25: Service Oriented Architecture

L. Cayetano-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

Page 26: Service Oriented Architecture

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

Page 27: Service Oriented Architecture

L. Cayetano-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

Page 28: Service Oriented Architecture

L. Cayetano-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

Page 29: Service Oriented Architecture

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]

L. Cayetano-29

Page 30: Service Oriented Architecture

Reuse Economics-Operational Benefits

L. Cayetano-30

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

Page 31: Service Oriented Architecture

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 .

L. Cayetano-31

Tradeoff between quality and productivity.Source: W.C. Lim, Managing Software Reuse, Prentice Hall, 1998, p. 108

Page 32: Service Oriented Architecture

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

L. Cayetano-32

Reuse allows increased quality and /or productivity levels.Source: W.C. Lim, Managing Software Reuse, Prentice Hall, 1998, p. 109

Page 33: Service Oriented Architecture

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.

L. Cayetano-33

Page 34: Service Oriented Architecture

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. 

L. Cayetano-34

Page 35: Service Oriented Architecture

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

L. Cayetano-35

Page 36: Service Oriented Architecture

SECTION 3

SOA: Motivation & Benefits

Page 37: Service Oriented Architecture

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

Page 38: Service Oriented Architecture

L. Cayetano-38

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.

Page 39: Service Oriented Architecture

L. Cayetano-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.

Page 40: Service Oriented Architecture

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

Page 41: Service Oriented Architecture

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

Page 42: Service Oriented Architecture

L. Cayetano-42

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.

Page 43: Service Oriented Architecture

L. Cayetano-43

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.

Page 44: Service Oriented Architecture

L. Cayetano-44

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.

Page 45: Service Oriented Architecture

L. Cayetano-45

SOA Example – Gift Cards

CashierSwipes

Card @ POS

ID #ComparedTo record

ApproveSale

DisplayNo AuthMessage

RetailPOS

Gift CardProcessor

Authorize?

Post saleTo GL

RetailGeneralLedger

DebitCard

Balance

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

Page 46: Service Oriented Architecture

L. Cayetano-46

.NETClient

CustomJ2EEApp

COBOL app on CICs mainframe

ProprietaryInterfaces

MultiplemessageTransport Protocols

1

2

3

4

5

.NETClient

CustomJ2EEApp

COBOL app on CICs mainframe

ProprietaryInterfaces

MultiplemessageTransport Protocols

1

2

3

4

5

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.

Page 47: Service Oriented Architecture

L. Cayetano-47

IT assets tied to business processes seamlessly and dynamically

Elimination of proprietary interfaces

Agility

CashierSwipes

Card @ POS

ID #ComparedTo record

ApproveSale

DisplayNo AuthMessage

RetailPOS

Gift CardProcessor

Authorize?

Post saleTo GL

RetailGeneralLedger

DebitCard

Balance

IT assets tied to business processes seamlessly and dynamically

Elimination of proprietary interfaces

Agility

CashierSwipes

Card @ POS

ID #ComparedTo record

ApproveSale

DisplayNo AuthMessage

RetailPOS

Gift CardProcessor

Authorize?

Post saleTo GL

RetailGeneralLedger

DebitCard

Balance

CashierSwipes

Card @ POS

ID #ComparedTo record

ApproveSale

DisplayNo AuthMessage

RetailPOS

Gift CardProcessor

Authorize?

Post saleTo GL

RetailGeneralLedger

DebitCard

Balance

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.

Page 48: Service Oriented Architecture

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

Page 49: Service Oriented Architecture

L. Cayetano-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 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.

Page 50: Service Oriented Architecture

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

Page 51: Service Oriented Architecture

SECTION 4

Industry Examples of SOA VerizonFortune 50 Financial ServicesGlobal Consumer Brand Company PfizerSempra Energy

Page 52: Service Oriented Architecture

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

Page 53: Service Oriented Architecture

L. Cayetano-53

Verizon • IT Workbench

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

Page 54: Service Oriented Architecture

L. Cayetano-54

SOA Inc., Service Manager

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

Page 55: Service Oriented Architecture

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

Page 56: Service Oriented Architecture

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

Page 57: Service Oriented Architecture

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

Page 58: Service Oriented Architecture

L. Cayetano-58

Pfizer • SOA

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

Page 59: Service Oriented Architecture

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

Page 60: Service Oriented Architecture

SECTION 5

References

Page 61: Service Oriented Architecture

L. Cayetano-61

References1. 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, 199812. 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.20. 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)21. D. E. Perry, “Generic Architecture Descriptions for Product Lines,” Bell Laboratories, Murray Hill, N.J. (Not published in any

paper)

Page 62: Service Oriented Architecture

L. Cayetano-62

References22. R. T. Fielding, “Software Architectural Styles for Network-based Applications,” University of California, Irvine, July 15, 1999.23. B.W. Boehm and T.A. Standish, “Software Technology in the 1990’s: using an evolutionary paradigm,” Computer, vol. 16, pp.

30-7, 1983.24. “Failed technology projects(The Standish Group Report),” in Investor’s Business Daily. Los Angeles, Jan. 1995, pp. A8.25. B. Bongard, B. Gronquist, and D. Ribot, "Impact of Reuse on Organizations," Cap Gemini Innovation, Esprit project REBOOT,

Grenoble, France, Sept. 4, 1992.26. N. Buxton and R. Malcolm, "Software technology transfer," Software Engineering journal, vol. 6, no.1, pp. 17-23, Jan., 1991.27. G. Caldiera, "Domain Factory and Software Reusability," Software Engineering Symposium: New Frontiers for Software

Maintenance, May, 1991.28. 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.29. 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.30. R. Joos, "Software Reuse in an Industrial Setting," 4th Annual Workshop on Software Reuse, Nov.18-22, 1991.31. D. Parkhill, "Object-oriented technology transfer: techniques and guidelines for a smooth transition," Object Magazine, pp.

57-59, May/June, 1992.32. R. Prieto-Diaz, "Making software reuse work: an implementation model," SIGSOFT Software Engineering Notes, vol. 16, no.3,

pp. 61-8, July, 1991. 33. "Reuse adoption guidebook," Software Productivity Consortium, Hemdon, VA, SPC-92051-CMC, Version 01.00.03, Nov., 1992. 34. "Software Reuse Guidelines," U.S. Army Information Systems Engineering Command (USAISE), ASQB-GI-90-015, Apr ., 1990. 35. 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.

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

37. T. Davis, "Adopting a policy of reuse," IEEE Spectrum, vol. 31, pp. 44-8, June 1994.38. W. B. Frakes and C. J. Fox, "Sixteen questions about software reuse," Communications of the ACM, vol. 38, pp. 75-87, 112,

June 1995.39. 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.40. R. M. Sonnemann, "Exploratory study of software reuse success," Ph.D. dissertation, Dep. Engineering, George Mason

University, Fairfax, VA, 1996.

Page 63: Service Oriented Architecture

L. Cayetano-63

References41. E.M. Rogers, Diffusion of Innovations, Simon & Schuster, 1995.42. B.W. Boehm, Competing on Schedule, Cost, and Quality : The Role of Software Models, USC Center for Software Engineering,

August, 2001.43. C.J. Date, An Introduction to Database Systems Volume II, Addison-Wesley, 1983.44. A. S. Tanenbaum, Distributed Operating Systems, Prentice Hall, 1995.45. 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, 198946. 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.47. 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.48. W. C. Lim, “A Cost-Justification Model for Software Reuse," 5th Annual Work- this shop for Institutionalizing Software Reuse,

Oct. 26-29, 1992.49. R. A. Malan and K. Wentzel, "Economics of Reuse Revisited," Hewlett Packard Laboratories, Palo Alto, CA, Technical Report,

HPL-93-31, Apr., 1993.50. 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.

51. B. Bloom, Deploying and Managing Microsoft .NET Web Farms, Sams Publishing, 2001.52. H. Taylor, “Service-Oriented Architecture (SOA) 101 ‘What’s Hype, What’s Real?’“, Juniper Networks, Inc.,2007.53. Wiehler, Gerard. Mobility, Security and Web Services: Technologies and Service-Oriented Architectures for a new Era of IT

Solutions. Publicis Corporate Publishing, 2004.54. Pulier, Eric and Hugh Taylor. Understanding Enterprise SOA. Manning Publications Co., 2006.

Page 64: Service Oriented Architecture

L. Cayetano-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.