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

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

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

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

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

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

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

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

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

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

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.

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

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.

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.

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.

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

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

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

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.

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.

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.