Introduction to Service Software Engineering

Transcription

1 Ingegneria del Software Orientata ai Servizi Corso di Laurea Magistrale in Informatica Introduction to Service Software Engineering Davide Rossi Dipartimento di Informatica Università di Bologna

2 Rationale Building software systems is complex Building large software systems is more complex Building large software system integrating functions provided by multiple organizations is even more complex

3 Managing complexity How do we face complexity? Abstractions Models

4 Abstraction The process of formulating generalized ideas or concepts by extracting common qualities from specific examples...the entire history of software engineering is one of rising levels of abstraction (for abstraction is the primary way we as humans deal with complexity) [G. Booch]

5 Model A representation of the system under analysis that answers as the system does for a given set of questions

6 Model A representation of the system under analysis that answers as the system does for a given set of questions All models are in simulacra, that is, simplified reflections of reality, but, despite their inherent falsity, they are nevertheless extremely useful

7 Model

8 Our key ingredients In this course we will learn how to manage the complexities of large distributed system (and the organizations they support) using two main abstractions: Services Processes

9 Services and processes Services are the structural... Processes are the behavioral... cornerstones around which we design our systems Services expose functions realized by processes Processes implement services (potentially using other services)

10 Services and processes Services will be discussed in the context of Service-Oriented Architectures (SOAs) Processes will be discussed in the context of Business Process Management (BPM) We will analyze SOA and BPM from a conceptual and from a technological point of view

11 Software architecture The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. Bass, Clements, Kazman - Software Architecture in Practice

12 Software architecture A software architecture defines a structure that organizes the software elements and the resources of a software system. Software elements and resources are represented by subsystems. In a given software architecture, these subsystems have specific responsibilities and relationships to other subsystems.

13 Software architecture The set of principal design decisions governing a system. Taylor, Medvidovic, Dashofy Software Architecture

14 Software architecture All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change. Grady Booch

15 Service-Oriented Architectures One of the great buzzwords of the beginning of the 21 st century A concept impacting both IT and management Several (broad) definitions: almost every distributed system can fit one of these

16 The SOA mandate All teams will henceforth expose their data and functionality through service interfaces. Teams must communicate with each other through these interfaces. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

17 The SOA mandate It doesn t matter what technology they use. HTTP, Corba, Pub-Sub, custom protocols doesn t matter. [...] All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions. Anyone who doesn t do this will be fired. Jeff Bezos

18 The SOA mandate This effort was still underway when I left to join Google in mid-2005, but it was pretty far advanced. From the time Bezos issued his edict through the time I left, Amazon had transformed culturally into a company that thinks about everything in a servicesfirst fashion. It is now fundamental to how they approach all designs, including internal designs for stuff that might never see the light of day externally. Steve Yegge

19 OASIS OASIS is a nonprofit consortium that drives the development, convergence and adoption of open standards for the global information society. OASIS promotes industry consensus and produces worldwide standards for security, Internet of Things, cloud computing, energy, content technologies, emergency management, and other areas. OASIS open standards offer the potential to lower cost, stimulate innovation, grow global markets, and protect the right of free choice of technology. OASIS members broadly represent the marketplace of public and private sector technology leaders, users and influencers. The consortium has more than 5,000 participants representing over 600 organizations and individual members in more than 65 countries.

20 The Open Group The Open Group is a global consortium that enables the achievement of business objectives through IT standards. With more than 500 member organizations, we have a diverse membership that spans all sectors of the IT community customers, systems and solutions suppliers, tool vendors, integrators and consultants, as well as academics and researchers to: Capture, understand and address current and emerging requirements, and establish policies and share best practices Facilitate interoperability, develop consensus, and evolve and integrate specifications and open source technologies Offer a comprehensive set of services to enhance the operational efficiency of consortia Operate the industry s premier certification service

21 Service-Oriented Architecture The SOA Source Book (Open Group) Service-Oriented Architecture (SOA) is an architectural style that supports service-orientation. Service-orientation is a way of thinking in terms of services and service-based development and the outcomes of services. A service: Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports) Is self-contained May be composed of other services Is a black box to consumers of the service

22 Service-Oriented Architecture Reference Model for SOA (OASIS) Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. [...] In SOA, services are the mechanism by which needs and capabilities are brought together.

23 Enterprise applications Enterprise applications include: Manufacturing: Engineering, bills of material, scheduling, capacity, workflow management, quality control, cost management, manufacturing process, manufacturing projects, manufacturing flow; Supply chain management: Order to cash, inventory, order entry, purchasing, product configurator, supply chain planning, supplier scheduling, inspection of goods, claim processing, commission calculation; Financials: General ledger, cash management, accounts payable, accounts receivable, fixed assets; Projects: Costing, billing, time and expense, activity management; Human resources: Human resources, payroll, training, time and attendance, rostering, benefits; Customer relationship management: Sales and marketing, commissions, service, customer contact and call center support; Data warehouse and various self-service interfaces for customers, suppliers, and employees. wikipedia

24 Early architectures POM DB Purchase Order Management Human Resources Application OS HR DB OS WM FS Warehouse Management OS

25 Early architectures POM DB Purchase Order Management Human Resources Application OS HR DB Redundancy of data OS WM FS Warehouse Management OS

26 Enterprise Resource Planning Systems An ERP is an enterprise-wide information system designed to coordinate all the resources, information, and activities needed to complete business processes such as order fulfillment or billing. ERPs are commonly based on an integrated and consistent database.

27 Back to the future At around year 2000, stand-alone Supply Chain Management Systems and Customer Relationship Management Systems start to be deployed along existing ERP. These new systems were not integrated with the ERP bringing back the old integration problems.

28 Siloed enterprise applications GUI GUI GUI Application logic of CRM system CRM DB Application logic of SCM system SCM DB Application logic of ERP system ERP DB OS OS OS

29 Enterprise Application Integration Enterprise application integration (EAI) is the process of linking siloed applications in order to simplify and automate business processes. The main challenge is information exchange: data transfer and data transformation. Two main integration patterns: mediation and federation. Two main topologies: hub-and-spoke and bus.

30 Service-enabled application ERP Enterprise Services ERP system ERP DB OS

31 Composite Service-based Application Composite Application Composite Application ERP Enterprise Services SCM Enterprise Services CRM Enterprise Services ERP system SCM system CRM system OS OS OS

32 Enterprise Service Bus ERP System CRM System SCM System HR Management Data Warehouse Inventory Mgmt

33 Enterprise Service Bus Alternative to point-to-point integration Message routing Content adaptation Mediation (deployment and versioning) Transaction management, security, monitoring, error handling,

34 The big picture Buyer Place Order Receive Invoice Receive Products Settle Invoice Business-to- Business Processes Human Interaction Workflows Service Interfaces SystemWorkflows/ Composite Applications ServiceLayer M. Weske: BusinessProcessManagement, Springer-VerlagBerlinHeidelberg2007 EnterpriseApplicationIntegration Enterprise Application Integration EAI Adapter ERPSystem SCMSystem CRMSystem Enterprise Applications Data Fig2.26.Businessprocessmanagement landscape

35 SOA is dead SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession. SOA is survived by its offspring: mashups, BPM, SaaS, Cloud Computing, and all other architectural approaches that depend on services. [Anne Thomas Manes, 2009]

36 Really? Successful SOA (i.e., application rearchitecture) requires disruption to the status quo. SOA is not simply a matter of deploying new technology and building service interfaces to existing applications; it requires redesign of the application portfolio. And it requires a massive shift in the way IT operates.

37 SOA manifesto Service orientation is a paradigm that frames what you do. Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation. We have been applying service orientation to help organizations consistently deliver sustainable business value, with increased agility and cost effectiveness, in line with changing business needs.

38 SOA manifesto - values Through our work we have come to prioritize: Business value over technical strategy Strategic goals over project-specific benefits Intrinsic interoperability over custom integration Shared services over specific-purpose implementations Flexibility over optimization Evolutionary refinement over pursuit of initial perfection That is, while we value the items on the right, we value the items on the left more.

39 SOA manifesto - principles Respect the social and power structure of the organization Recognize that SOA ultimately demands change on many levels The scope of SOA adoption can vary. Keep efforts manageable and within meaningful boundaries Products and standards alone will neither give you SOA nor apply the service orientation paradigm for you

40 SOA manifesto - principles SOA can be realized through a variety of technologies and standards Establish a uniform set of enterprise standards and policies based on industry, de facto, and community standards Pursue uniformity on the outside while allowing diversity on the inside Identify services through collaboration with business and technology stakeholders

41 SOA manifesto - principles Maximize service usage by considering the current and future scope of utilization Verify that services satisfy business requirements and goals Evolve services and their organization in response to real use Evolve services and their organization in response to real use At every level of abstraction, organize each service around a cohesive and manageable unit of functionality