Distributed SystemsDistributed Systems Architectures & Service
Transcript of Distributed SystemsDistributed Systems Architectures & Service
Chapters 12/31Chapters 12/31
Distributed SystemsDistributed SystemsArchitectures & Service-Oriented
Software Engineering
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 1
Distributed Systems ArchitecturesDistributed Systems Architectures
Architectural design for software that executes on more than one processor
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 2
Service Oriented Software EngService-Oriented Software Eng
A way of developing distributed systems where the components are stand-alone services.“Currently a hot topic…as important a development as object-oriented software engineering.”
(For Chap 31, skip sections: 31.2 and 31.3.1)
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 3
ObjectivesObjectivesTo explain the advantages and disadvantages ofTo explain the advantages and disadvantages of distributed systems architectures.To describe different approaches to the development of liclient-server systems.
To explain the differences between client-server and distributed object architecturesdistributed object architectures.To describe object request brokers and the principles underlying the CORBA standards.To introduce service-oriented SE, an increasingly important approach in business application development.
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 4
Topics coveredTopics covered
Multiprocessing systemsMultiprocessing systemsDistributed systems architectures
Client-server architecturesDistributed object architectures
CORBA (Common Object Request Broker Architecture)Service-oriented SE
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 5
Topics coveredTopics covered
Multiprocessing systemsMultiprocessing systemsDistributed systems architectures
Client-server architecturesDistributed object architectures
CORBA (Common Object Request Broker Architecture)Service-oriented SE
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 6
Multiprocessor architecturesMultiprocessor architectures
System composed of multiple processes whichSystem composed of multiple processes which may or may not execute on different processors.Distribution of process to processor may be pre-Distribution of process to processor may be predetermined (e.g., by type of process) or may be under the control of a dispatcher.p
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 7
A multiprocessor traffic control systemsystem
Traffic light controlprocessor
Traffic flowprocessor
Sensorprocessor
Lightcontrolprocess
processorprocessorprocessor
Sensorcontrolprocess
Displayprocess
Traffic lights
Operator consolesTraffic flow sensors
and cameras
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 8
Types of multiprocessing systemsTypes of multiprocessing systems
Personal systems that are not distributed and thatPersonal systems that are not distributed and that are designed to run on a personal computer or workstation. (e.g., word processors)( g , p )
Embedded systems that run on a single processor or on an integrated group of processors.processor or on an integrated group of processors. (e.g., control systems, real-time systems)
Distributed systems where the system software y yruns on a loosely integrated group of processors linked by a network. (e.g., ATM systems)
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 9
Distributed systemsDistributed systemsVirtually all large, computer-based systemsVirtually all large, computer based systems are now distributed systems.Processing is distributed over several computersProcessing is distributed over several computersrather than confined to a single machine.Distributed software engineering is now very g g yimportant.
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 10
Distributed system characteristics / advantagescharacteristics / advantages
Resource sharing (hardware and software)Resource sharing (hardware and software)
Openness (standard protocols allow equipment and softwarefrom different vendors to be combined)from different vendors to be combined)
Concurrency (parallel processing)
Scalability (up to capacity of network)Scalability (up to capacity of network)
Fault tolerance (potential)
Transparency (resources can be accessed without knowledgeTransparency (resources can be accessed without knowledgeof their physical or network location – item deleted after 6th
Ed.)
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 11
Distributed system disadvantagesDistributed system disadvantages
Complexity (number of factors affecting emergent properties)Complexity (number of factors affecting emergent properties)
Security (multiple access points, network eavesdropping, etc.)
Manageability (h t it )Manageability (heterogeneity)
Unpredictable responsiveness
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 12
Design issue DescriptionResourceid tifi ti
The resources in a d istributed system are spread across differentt d i h h t b d i d th tidentification computers and a naming scheme has to be devised so that users can
discover and re fer to the resources that they need. An example ofsuch a naming scheme is the URL (Uniform Resource Locator) thatis used to identify WWW pages. If a meaningful and universallyunderstood identification scheme is not used then many of theseunderstood identification scheme is not used then many of theseresources will be inaccessible to system users.
Communications The universal availability of the Internet and the efficientimplementation of Internet TCP/IP communication protocols meansthat, for most distributed systems, these are the most effective wayfor the computers to communicate. However, where there arespecific requirements for performance, reliability etc. alternativeapproaches to communications may be used.
Quality of service The quality of service offered by a system reflects its performance,availability and reliability It is affected by a number of factors suchavailability and reliability. It is affected by a number of factors suchas the allocation of processes to processes in the system, thedistribution of resources across the system, the network and thesystem hardware and th e adaptability of the system.
Software The software architecture describes how the applicationfarchitectures
ppfunctionality is distributed over a number of logical components andhow these components are distributed across processors. Choosingthe right architecture for an application is essential to achieve thedesired quality of service.
Issues in distributed system design
Distributed systems architecturesDistributed systems architectures
Client server architectures di t ib t dClient-server architectures – distributed services are called on by clients. Servers that provide services are treated differently from clients that use services.
Distributed object architectures – removesdistinction between clients and servers. Any object in the system may provide and use services from other objects.
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 14
MiddlewareMiddleware
Software that manages and enables communSoftware that manages and enables commun-ication between the diverse components of a distributed system.yUsually off-the-shelf rather than specially written.Distributed system frameworks, e.g. CORBA and DCOM, is an important class of middle-, pware described later.
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 15
Client server architecturesClient-server architectures
The application is modelled as a set of servicesThe application is modelled as a set of services that are provided by servers and a set of clients that use the services.Clients must know of servers but servers need not know of clients. (e.g., “installing” a network printer)
Clients and servers are logical processes as opposed to physical machines. The mapping of processors to processes is not necessarily 1:1.
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 16
P i li t tProcesses in a client-server system
c2 c3 c4
c11
c12
Server process
s1 s4c1
c5c10
Server process
s2 s3
c5
c9
Client process
c6c7 c8
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 17
C t i li t t kComputers in a client-server network
CC1 CC2 CC3c1 c2 c3, c4
Network
SC1SC2
Servercomputer
s1, s2 s3, s4
SC1SC2
Clientcomputerc5, c6, c7 c8, c9 c10, c11, c12
CC5 CC6CC4
computerc5, c6, c7 c8, c9 c10, c11, c12
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 18
Application layers modelApplication layers model
Presentation layer d ithPresentation layer – concerned withpresenting the results of a computation to system users and with collecting user inputs. implemented
on client only
Application processing layer – concerned with implementing the logic (functionality) of the
on client only
application. implemented on client or server
Data management layer – concerned with all system database operations. implemented on
server only
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 19
Application layersApplication layers
Presentation layer
Application processinglayerlayer
Data managementlayer
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 20
Distributing layers to processorsDistributing layers to processors
Two-tier C/S architecture – the three layers areTwo-tier C/S architecture – the three layers are distributed between a server processor and a set of clients.
Three-tier C/S architecture – the layers are distributed among two server processes / processorsand a set of clientsand a set of clients.
Multi-tier C/S architectures – the layers are distributed among multiple server processes / g p pprocessors (each associated with a separate database, for example) and a set of clients.
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 21
Two-tier architectures: thin and fat clientsand fat clients
Thin client model th li i l i dThin-client model – the application logic anddata management are implemented on the server;clients only handle the user interface.
Fat-client model – the server is only responsible for data management; clients handle the application logic and the user interface.
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 22
Thin and fat clientsThin and fat clients
Thin-clientmodel Client
Server
Data managementApplication
Presentation
model Applicationprocessing
Presentation
Fat-clientmodel Client
Server
Datamanagement
PresentationApplication processing
management
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 23
Thin client modelThin-client modelOften used when centralized legacy systemsOften used when centralized legacy systems evolve to a C/S architecture; the user interface is migrated to workstations or terminals and the legacy system acts as a serverlegacy system acts as a server.Places a heavy processing load on both the server and the network; this is wasteful whenserver and the network; this is wasteful when clients are powerful workstations.
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 24
Fat client modelFat-client modelMore processing is delegated to the client asMore processing is delegated to the client as the application logic is executed locally (i.e., on the client).But system management is more complex, especially when application function changes and new logic must be installed on each clientand new logic must be installed on each client.
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 25
A client server ATM systemA client-server ATM systemfat- or thin-client
ATM model?
Account server
CustomerTele-
ATM
Customeraccountdatabase
Tele-processing
monitorATM
ATMtransaction manager
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 26
Three tier architecturesThree-tier architecturesEach application architecture layer may executeEach application architecture layer may execute on a separate processor.Allows for better performance and scalabilityAllows for better performance and scalability than a thin-client approach and is simpler to manage than a fat-client approach. (Why?)
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 27
A 3 tier C/S architectureA 3-tier C/S architecture
Presentation
Client
Server
Datamanagement
PresentationServer
Applicationprocessing managementprocessing
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 28
An internet banking systemAn internet banking system
Database serverWeb server
Client HTTP interaction
Database server
Customeraccountdatabase
Web server
Client Account serviceprovision
SQLSQL query
database
Client
Application processing
Data management
Client
processing management
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 29
Presentation
Use of C/S architecturesUse of C/S architecturesArchitecture ApplicationsT ti C/S L t li ti h ti li tiTwo-tier C/Sarchitecture withthin clients
Legacy system applications where separating applicationprocessing and data management is impracticalComputationally-intensive applications such as compilers withlittle or no data managementData-intensive applications (browsing and querying) with littleor no application processing.
Two-tier C/Sarchitecture with
Applications where application processing is provided byCOTS (e.g. Microsoft Excel) on the client
fat clients( g )
Applications where computationally-intensive processing ofdata (e.g. data visualisation) is required.Applications with relatively stable end-user functionality usedin an environment with well-established system managementin an environment with well-established system management
Three-tier ormulti-tier C/Sarchitecture
Large scale applications with hundreds or thousands of clientsApplications where both the data and the application arevolatile.A li ti h d t f lti l i t t d
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 30
Applications where data from multiple sources are integrated
Review of C/S system models/typesReview of C/S system models/typesTwo logical process typesTwo logical process types
servers (providing services)clients (using services)
Three application layersThree application layerspresentation (always associated with clients)processing logic (thin model: associated with server; fat model: associated with clients)model: associated with clients)data management (always associated with servers)
Three layer-to-processor mappings2-tier (1 server + a set of clients)3-tier (2 servers + a set of clients)multi-tier (n servers + a set of clients)
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 31
Distributed object architecturesDistributed object architecturesEliminates the distinction between clients andEliminates the distinction between clients and servers.System components are objects that provideSystem components are objects that provide services to, and receive services from, other objects.Object communication is through middlewarecalled an object request broker (effectively a software bus)software bus)
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 32
Distributed object architecturesDistributed object architecturesObject name
o1 o2 o3 o4
S (o1) S (o2) S (o3) S (o4)
Software bus (ORB)Software bus
o5 o6
(ORB)
S (o5) S (o6)
Services
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 33
Advantages of distributed object architecturesobject architectures
Allows system designer to delay decisions onAllows system designer to delay decisions on where and how services should be provided. (Service-providing objects may execute on any network node.)
Very open architecture – allows new resources to be added as required. Flexible and scaleable.System is dynamically reconfigurable – objects can migrate across the network as required. (Thus improving performance.)
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 34
Uses of distributed object architecturesarchitectures
1 As a logical model for structuring and1. As a logical model for structuring and organizing a system solely in terms of services provided by a number of distributed objects. (E.g., a data mining system.)
2. As a flexible means of implementing C/S systems. Both clients and servers are realised as distributed objects communicating through a software busa software bus.
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 35
A data mining systemA data mining system
Database 1 Report gen.Database 1Integrator 1
Report gen.
Database 2
Integrator 2
Visualiser
Database 3
Integrator 2
Display
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 36
Disadvantages of distributed object architecturesobject architectures
Complex to design due to model generalityComplex to design due to model generalityand flexibility in service provision.C/S systems seem to be a more natural modelC/S systems seem to be a more natural modelfor most systems. (They reflect many human service transactions.)
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 37
CORBA (Common Object Request Broker Architecture) est 1991Broker Architecture) – est. 1991
International standards for an Object Request BrokerInternational standards for an Object Request Broker (ORB) – middleware to manage communications between distributed objects. (Version 3.1, 2008)
Several implementations of CORBA are available (Unix and MS OS’s). www.corba.org
Defined by the Object Management Group (> 500Defined by the Object Management Group (> 500 companies, including Sun, HP, IBM). (OMG → UML)
DCOM (Distributed Component Object Model) is an alternative standard developed and implemented by Microsoft – now deprecated in favor of Microsoft .NET
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 38
Components of the OMG visionof a distributed applicationof a distributed application
Application objects designed and implemen-Application objects designed and implemented for this application.Domain-specific objects defined by the OMG.Domain specific objects defined by the OMG. (e.g., finance/insurance, healthcare)
Fundamental CORBA distributed computing i h di t i d itservices such as directories and security
management.Horizontal facilities (such as user interfaceHorizontal facilities (such as user interface facilities) used in many different applications. (cross domain)
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 39
CORBA application structureCORBA application structure
Domain HorizontalApplication Domainfacilities
HorizontalCORBA facilities
Applicationobjects
Object request broker
CORBA services
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 40
The OMG VisionThe OMG VisionApplication
specificspecific
Horizontal facilities
Domain specific facilities CORBA
iservices
Major elements of the CORBA standardsstandards• An application object model where objectsAn application object model where objects
encapsulate state and have a well-defined, language-neutral interface defined in an IDL (interface d fi i i l )definition language).
• An object request broker (ORB) that locates objects providing services, sends service requests, andproviding services, sends service requests, and returns results to requesters.
• A set of general object services of use to many di ib d li idistributed applications. (Horizontal facilities)
• A set of common components built on top of these services. (Task forces are currently defining these.)
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 42
services. (Task forces are currently defining these.) (domain specific facilities)
CORBA objectsCORBA objects
Objects that provide services have IDLObjects that provide services have IDL skeletons that link their interface to an implementation.pCalling objects have IDL stubs for every object being called.j gIDL stubs and skeletons are “visible” to ORB.Objects do not need to know the location or jimplementation details of other objects.
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 43
Object request broker (ORB)Object request broker (ORB)
The ORB handles object communications ItThe ORB handles object communications. It knows of all objects in the system and their interfaces.The calling object binds an IDL stub that defines the interface of the called object.jCalling this stub results in calls to the ORB which then calls the required object through a published IDL skeleton that links the interface to the service implementation.
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 44
ORB based object communicationsORB-based object communications
o1 o2
S (o1) S (o2)S (o1) S (o2)
Object providing
Calling object
IDLstub
IDLskeleton
providing service
object
(For 02)
Object Request Broker
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 45
Inter ORB communicationsInter-ORB communicationsORBs handle communications between objectsORBs handle communications between objects executing on the same machine.Inter-ORB communications are used forInter ORB communications are used for distributed (remote) object calls.CORBA supports ORB-to-ORB communication ppby providing all ORBs access to all IDL interface definitions and by implementing the OMG’s standard Generic Inter-ORB Protocol (GIOP)standard Generic Inter-ORB Protocol (GIOP).
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 46
Inter ORB communicationsInter-ORB communications
o1 o2
S (o1) S (o2)
o3 o4
S (o3) S (o4)S (o1) S (o2)
IDL
S (o3) S (o4)
IDLIDL IDL
Object Request Broker
IDL IDL
Object Request BrokerObject Request Broker Object Request Broker
Network
GIOP
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 47
GIOP
Examples of general CORBA servicesservices
Naming and trading services these allowNaming and trading services – these allow objects to discover and refer to other objects on the network.
Notification services – these allow objects to notify other objects that an event has occurred. (selective broadcasting)(selective broadcasting)
Transaction services – these support atomic transactions and rollback on failure. (recovery ( yfunctions)
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 48
The future of CORBA support for Internet computingfor Internet computing
Proponents of CORBA envisioned it as becomingProponents of CORBA envisioned it as becoming the dominant model for code and service-reuse over the Internet.However difficulties encountered with firewalls, insecure machines, etc., have resulted in an increased use of normal HTTP requests in combination with web browsers, as well as i i h d l f linterest in other models of inter-organizational computing…
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 49
Inter organizational computingInter-organizational computing
For security and inter-operability reasons mostFor security and inter-operability reasons, most distributed computing has been implemented at the enterprise level.Local standards, management and operational processes apply.Newer models of distributed computing have been designed to support inter-organisational
i h diff d l d icomputing where different nodes are located in different organizations.
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 50
Peer to peer architecturesPeer-to-peer architectures
Peer to peer (p2p) systems are decentralisedPeer to peer (p2p) systems are decentralised systems where computations may be carried out by any node in the network.The overall system is designed to take advantage of the computational power and storage of a large number of networked computers.
h b lMost p2p systems have been personal systems but there is increasing business use of this technology
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 51
technology.
S i i t d hit t (Ch 31)Service-oriented architectures (Ch. 31)A means of developing distributed systemsA means of developing distributed systems where the components are stand-alone (usually web-based) servicesStandard, XML-based protocols have been developed to support service communication and information exchange (“perhaps the keyand information exchange ( perhaps the key reason for success”)Services are platform and language independent.Systems can be constructed using services from different providers (using a workflow language) with seamless interaction
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 52
with seamless interaction.
Web servicesWeb services
Serviceregistry
PublishFind
Service Serviceid Service
requestor provider Service
Bind
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 53
Web service standardsWeb service standards
Support (WS-Security, WS-Addressing, ...)
XML technologies (XML, XSD, XSLT, ....)
Process (WS-BPEL)
Service definition (UDDI, WSDL)
Transport (HTTP, HTTPS, SMTP, ...)
Messaging (SOAP)
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 54
Transport (HTTP, HTTPS, SMTP, ...)
Principal XML based standardsPrincipal XML-based standardsMessaging: SOAP (Simple Object Access Protocol):Messaging: SOAP (Simple Object Access Protocol):message exchange standard that supports service communicationService Definition:Service Definition:
WSDL (Web Service Definition Language): defines a service interface and its bindingsUDDI (Universal Description, Discovery and Integration): defines the components of a service that may be used to discover its existence
Process: WS-BPEL (Web Service Business Process Execution Language): standard for workflow languages used to define service composition
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 55
used to define service composition
Web servicesWeb services(UDDI)
Serviceregistry
(UDDI)
PublishFind
Service Serviceid Service
requestor provider Service
(WSDL)Bind (SOAP)
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 56
Principal XML based standardsPrincipal XML-based standardsMessaging: SOAP (Simple Object Access Protocol):Messaging: SOAP (Simple Object Access Protocol):message exchange standard that supports service communicationService Definition:Service Definition:
WSDL (Web Service Definition Language): defines a service interface and its bindingsUDDI (Universal Description, Discovery and Integration): defines the components of a service that may be used to discover its existence
Process: WS-BPEL (Web Service Business Process Execution Language): standard for workflow languages used to define service composition
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 57
used to define service composition
Web servicesWeb services(UDDI)
Serviceregistry
(UDDI)
PublishFind
Service Serviceid Service
requestor provider Service
(WSDL)Bind (SOAP)
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 58
Principal XML based standardsPrincipal XML-based standardsMessaging: SOAP (Simple Object Access Protocol):Messaging: SOAP (Simple Object Access Protocol):message exchange standard that supports service communicationService Definition:Service Definition:
WSDL (Web Service Definition Language): defines a service interface and its bindingsUDDI (Universal Description, Discovery and Integration): defines the components of a service that may be used to discover its existence
Process: WS-BPEL (Web Service Business Process Execution Language): standard for workflow languages used to define service composition
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 59
used to define service composition
Web servicesWeb services(UDDI)
Serviceregistry
(UDDI)
PublishFind
Service Serviceid Service
requestor provider Service
(WSDL)Bind (SOAP)
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 60
Principal XML based standardsPrincipal XML-based standardsMessaging: SOAP (Simple Object Access Protocol):Messaging: SOAP (Simple Object Access Protocol):message exchange standard that supports service communicationService Definition:Service Definition:
WSDL (Web Service Definition Language): defines a service interface and its bindingsUDDI (Universal Description, Discovery and Integration): defines the components of a service that may be used to discover its existence
Process: WS-BPEL (Web Service Business Process Execution Language): standard for workflow languages used to define service composition
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 61
used to define service composition
Examples of “Supporting standards”Examples of “Supporting standards”
WS Reliable Messaging: ensures messagesWS-Reliable Messaging: ensures messages will be delivered once and once onlyWS-Security: specify security policies andWS Security: specify security policies and standards for use of digital signaturesWS-Addressing: specifies representation ofWS Addressing: specifies representation of addresses in SOAP messagesWS-Transactions: specifies how transactions pshould be coordinated across services
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 62
S i bl tServices as reusable components
A service can be defined as:A service can be defined as:
A l l l d bl ft tA loosely-coupled, reusable software component that encapsulates discrete functionality which may be distributed and programmaticallymay be distributed and programmatically accessed. A web service is a service that is accessed using standard Internet (HTTPaccessed using standard Internet (HTTP, TCP/IP) and XML-based protocols.
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 63
S i bl t ( t’d)Services as reusable components (cont’d)
A critical distinction between a service and aA critical distinction between a service and a component as defined in CBSE is that services are independentservices are independent.
Services do not have a ‘requires’ interfaceServices rely on message basedServices rely on message-basedcommunication using XML (versus synchronous method calls)sy c o ous et od ca s)
(CBSE covered in Chap. 19)
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 64
Message-based communication vs. i t ti i th d llinteraction via method calls
restaurant order via synchronous method calls
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 65
Message-based communication vs. i t ti i th d ll ( t’d)interaction via method calls (cont’d)
restaurant order via an XML message<starter>
<dish name = “soup” type = “tomato” /><dish name = “soup” type = “fish” />
di h “ i l d” /<dish name = “pigeon salad” /></starter><main course>
<dish name = “steak” type = “sirloin” cooking = “medium” /><dish name steak type sirloin cooking medium /><dish name = “steak” type = “fillet” cooking = “rare” /><dish name = “sea bass”>
</main course><accompaniment>
<dish name = “french fries” portions = “2” /><dish name = “salad” portions = “1” />
</accompaniment>
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 66
</accompaniment>
Software development with servicesSoftware development with services
Existing services are composed and configured toExisting services are composed and configured to create new composite services and applications.The basis for service composition is often aThe basis for service composition is often a workflow.
Workflows are logical sequences of activities that, g q ,together, model a coherent business process.For example, consider a workflow providing a travel
ti i hi h ll fli ht hi dreservation services which allows flights, car hire and hotel bookings to be coordinated…
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 67
Service compositionService composition
Suppose an airline wishes to compose its ownSuppose an airline wishes to compose its own booking services with services offered by a hotel booking agency, car hire and taxi companies, and g g y, p ,local attraction providers.The sequence of steps for this “vacation package” q p p gapplication could be modeled (in simplified form) as the following workflow:
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 68
Vacation package workflowVacation package workflow
Note that this simplified model does NOT reflect the possibility of service failure, exceptional user requests, etc.
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 69
Construction by compositionConstruction by composition
The process of designing new services by composing existing services is, essentially, a process of software design with reuse.
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 70
External service testing issuesExternal service testing issuesServices are “black-boxes,” so code-based (i e , “white-Services are black boxes, so code based (i.e., whitebox”) testing techniques cannot be used at the service level.S i b difi d b th i idServices may be modified by the service provider.Dynamic binding means that the service used in an application may vary.pp y yNon-functional behavior is unpredictable as it depends on other (concurrent) uses of the service.If services have to be paid for as used testing may beIf services have to be paid for as used, testing may be expensive.It may be difficult to test compensating actions which
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 71
rely on the failure of services.
Key pointsAlmost all new large systems are distributed
Key pointsAlmost all new large systems are distributed systems.Distributed systems support resource sharing,Distributed systems support resource sharing,openness, concurrency, scalability, fault tolerance, and transparency.Client-server architectures involve services being delivered by servers to programs operating on clientsclients.
User interface software always runs on the clientand data management on the server
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 72
and data management on the server.
Key points (cont’d)Key points (cont’d)
In a distributed object architecture there is noIn a distributed object architecture, there is no distinction between clients and servers.Distributed object systems require middle-ware toDistributed object systems require middle-ware to handle object communications.The CORBA standards are a set of middle-wareThe CORBA standards are a set of middle ware standards that support distributed object architectures.Peer to peer architectures are decentralised architectures where there is no distinction between
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 73
clients and servers.
Key points (cont’d)Key points (cont’d)Service-oriented software engineering is based onService oriented software engineering is based on the notion that programs can be constructed by composing independent services which encapsulate
bl f i lireusable functionality.Service interfaces are defined in WSDL. A WSDL specification includes a definition of the interfacespecification includes a definition of the interface types and operations, the binding protocol used by the service, and the service location.Service-level code-based testing cannot be used in service-oriented systems that rely on externally provided services
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 74
provided services.