Chapter 17 – Distributed software engineering
Chapter 18 - Service-oriented software engineering
# Quiz
Service-oriented architecture is an approach to software engineering where reusable, standardized services are the basic building blocks for application systems.
Service-Oriented Architecture (SOA) is a style of software design where services are provided to the other components by application components, through a communication protocol over a network. Its principles are independent of vendors and other technologies. In service oriented architecture, a number of services communicate with each other, in one of two ways: through passing data or through two or more services coordinating an activity. This is just one definition of Service-Oriented Architecture. An article on Wikipedia goes into much more detail.
Service-oriented systems have tightly coupled architectures where service bindings should not change during system execution
Service-oriented architecture promotes loose coupling between service consumers and service providers and the idea of a few well-known dependencies between consumers and providers. A system's degree of coupling directly affects its modifiability.
In a RESTful architecture, everything is represented as a resource.
REST architecture treats every content as a resource. These resources can be Text Files, Html Pages, Images, Videos or Dynamic Business Data. REST Server simply provides access to resources and REST client accesses and modifies the resources. Here each resource is identified by URIs/ Global IDs.
Which is not a fundamental polymorphic operation in a RESTful architecture
REST – a sort of Web-based CRUD (Create, Read, Update, Delete) architecture.
A POST request is used to a resource
POST is used to create a resource. It has associated data that defines the resource.
GET is used to read the value of a resource and return that to the requestor in the specified representation, such as XHTML, that can be rendered in a web browser.
PUT is used to update the value of a resource.
DELETE is used to delete the resource.An important difference between RESTful services and SOAP-based services is that RESTful services are not exclusively .
SOAP needs more bandwidth for its usage whereas REST doesn't need much bandwidth. Comparing SOAP vs REST API, SOAP only works with XML formats whereas REST work with plain text, XML, HTML and JSON. SOAP cannot make use of REST whereas REST can make use of SOAP.
A problem with RESTful services are there are no standards for RESTful interface description, so service users must rely on informal documentation to understand the interface.
REST is an Architecture, Not a Standard
While HTTP is a standard, REST itself is not. Rather, it's an architectural style that provides constraints that guide API design. Many APIs do not conform to every element of REST, which has caused some to use the term RESTful to describe the most common types of APIs.A benefit of distrubuted systems are that they can be scaled to cope with increasing demand
Advantages of Distributed Computing
- Reliability, high fault tolerance: A system crash on one server does not affect other servers.
- Scalability: In distributed computing systems you can add more machines as needed.
- Flexibility: It makes it easy to install, implement and debug new services.
- Fast calculation speed: A distributed computer system can have the computing power of multiple computers, making it faster than other systems.
- Openness: Since it is an open system, it can be accessed both locally and remotely.
- High performance: Compared to centralized computer network clusters, it can provide higher performance and better cost performance.
Client-server systems are distributed systems in which the system is structured into layers, with the presentation layer implemented on a computer. Servers provide data management, application, and database services.
Client–server systems are structured into layers, with the presentation layer implemented on a client computer. Servers provide data management, application and database services. Client-server systems may have several tiers, with different layers of the system distributed to different computers.
SaaS stands for “Software as a Science”
Chong and Carraro at Microsoft3 define shared software as software-as-a-service (SaaS) deployed as a hosted service and accessed over the Internet. The key features of SaaS are where the programs reside and how they are accessed.
This idea of involves hosting the software remotely and providing access to it over the Internet.
Software as a service (SaaS) is a software distribution model in which a cloud provider hosts applications and makes them available to end users over the internet.
# Exercise
What do you understand by “scalability”? Discuss the differences between scaling up and scaling out and explain when these different approaches to scalability may be used.
Scalability is the ability of an application to deliver high quality of service as demands on the system increase. It is the ability of the system to cope with increasing numbers of users without reducing the overall quality of service that is delivered to any user.
Scaling out and scaling up can be differentiated in terms of size and cost.
Scaling up means replacing resources in the system with more powerful resources. For example, when database runs out of resources on the current hardware there is no need to make changes to the database instead, the memory in the server may be increased.
Scaling out means adding new resources to the existing system. That means, adding additional servers and so also increasing the number of transactions that can be processed in parallel. For example an extra web server to work along with the existing server.
Scaling out is often more cost effective than scaling up.
Generally when considering scalability in the context of SaaS (Software as a Service), scaling out is considered rather than scaling up.Explain why distributed software systems are more complex than centralized software systems, where all of the system functionality is implemented on a single computer.
Distributed software systems are more complex than centralized software systems that run on a single computer. This complexity of distributed software systems arises because,
- It is practically impossible to have a top-down model of control of these systems.
- The nodes in the system that deliver functionality are often independent systems with no single authority in charge of them.
- The network connecting these nodes is a separately managed system.
- It is a complex system in its own right and cannot be controlled by the owners of systems using the network.
There is therefore an inherent unpredictability in the operation of distributed systems that has to be taken into account by the system designer.
What are the different logical layers in an application with a distributed client–server architecture?
An application with a distributed client-server architecture will be structured into four layers:
- A presentation layer that is concerned with presenting information to the user and managing all user interaction.
- A data-handling layer that manages the data that is passed to and from the client. This layer may implement checks on the data, generate web pages, and so on.
- An application processing layer that is concerned with implementing the logic of the application and so providing the required functionality to end-users.
- A database layer that stores the data and provides transaction management and query services.
You have been asked to design a secure system that requires strong authentication and authorization. The system must be designed so that communications between parts of the system cannot be intercepted and read by an attacker. Suggest the most appropriate client-server architecture for this system and, giving the reasons for your answer, propose how functionality should be distributed between the client and the server systems.
When a system is proposed which requires strong authentication and authorization, two-tier client server architecture with fat clients is effective. In this model some of the application processing is carried out on the client and the data management and database functions are implemented on the servers. Data management is carried out straightforward as there is no need to manage the interaction between the client and application processing system.
Consider an example of bank ATM system, the ATM is the client computer and the server is a mainframe which runs the customer account database. The communication between ATM and server (database) is not direct rather a middleware like teleprocessing monitor is used which organizes communication with remote clients and serializes client transactions for processing by the database. This ensures that transactions are independent and do not interfere with one other and hence attacker cannot intercept the transactions. The system can recover from faults without corrupting the system data because of serial transactions.
Your company wishes to move from using desktop applications to accessing the same functionality remotely as services. Identify three risks that might arise and suggest how these risks may be reduced.
- Security: The most significant feature which a local application does not have to account for is security; after all, if you’re logged into the computer and able to open the app, you’re probably supposed to be there. However, networked services have no such protection; anyone in the network (which could likely be the global web) may interface with the service. This means that security becomes a significant issue; by having every application user’s information stored and computed within this networked service, it creates a significant potential for a malicious entity to intercept, view, or alter this data; with potentially ruinous effects on the individuals under attack. Therefore, remote services must have significant and extensive security in place, to protect the confidentiality and integrity of its processes. The only way to solve security is to take it seriously. Most likely, all aspects of validation, verification, and communication between client and server will have to be redesigned in order to take advantage of modern network security frameworks; luckily, many of these frameworks are becoming increasingly well-designed and easy to implement, making security approachable as a requirement, despite never being truly solvable.
- Accessibility: If the application has any large calculations which it performs, then these features must be implemented with great caution when put into a networked service. After all, if a client (or number of clients) connects to the service and ask it to run its most computationally intensive functionality, the service must be able to juggle its responsibilities such that no single client monopolizes the service; and that new users will be able to join and still have their user experiences unharmed. To solve this, the application must be converted to utilize a task manager with hierarchies of tasks. This way, core communications can be given priority across all sessions and all users, while the expensive operations can be relegated to be given proportional distribution of the available remaining calculation space. Another option might be to make for ‘fat’ clients; where these heavy calculations are given to the client rather than the server; but this solution might not be available depending on the specifications of the project, and comes with its own issues.
- Concurrency: Many of the core functionalities of the application may be designed to be the exclusive user of a resource at any given time. For instance, opening a file which then stays open until the application is exited, which then overrides the saved file with the one in memory. This functionality, which is fine for the local app, would be ruinous for a networked software with shared resources, as one application may override the changes of another simply by having been opened first and closed last. This may be less significant of a risk if the application utilized network-friendly data storage methods, such as SQL. To address this issue, care must be taken to ensure that there are no concurrency issues for all file/data-based operations. Moreover, data access cannot simply be rewritten to networked equivalents; in some cases the core logic of any given I/O operation may have to be revised.
Why is it important to define exceptions in service engineering?
Defining exceptions and how these exceptions can be communicated to service users is particularly important. Service engineers do not know how their services will be used. It is usually unwise to make assumptions that service users will have completely understood the service specification. Input messages may be incorrect, so you should define exceptions that report incorrect inputs to the service client. It is generally good practice in reusable component development to leave all exception handling to the user of the component. Service developers should not impose their views on how exceptions should be handled.
Define and give an example of a RESTful service.
REST is an architectural style based on transferring representations of resources from a server to a client. It is the style that underlies the web as a whole and has been used as a much simpler method than SOAP/WSDL for implementing web service interfaces.(Sommerville, 2015)
In a RESTful architecture, everything is represented as a resource. Resources have a unique identifier, which is their URL. Resources are a bit like objects, with four fundamental polymorphic operations associated with them:- Create—bring the resource into existence.
- Read—return a representation of the resource.
- Update—change the value of the resource.
- Delete—make the resource inaccessible.
The Web is an example of a system that has a RESTful architecture. Web pages are resources, and the unique identifier of a web page is its URL.
The web protocols http and https are based on four actions, namely, POST, GET, PUT, and DELETE. These map onto the basic resource operations:- POST is used to create a resource. It has associated data that defines the resource.
- GET is used to read the value of a resource and return that to the requestor in the specified representation, such as XHTML, that can be rendered in a web browser.
- PUT is used to update the value of a resource.
- DELETE is used to delete the resource.
Suggest how the SimpleInterestCalculator service could be implemented as a RESTful service.
REST (REpresentational State Transfer) is an architectural style based on transferring representations of resources from a server to a client. RESTful services are all based around the sacred idea that "everything is represented as resources and can be accessed by an address (URI)". This means we can think about "creating a calculation" without having to persist the result of that calculation at it's own URL. Your API could look like this:
Request: POST /calculations Content-Type: text/plain 1 + 1 Response: 200 OK Content-Type: text/plain 2This has the benefit that you're not passing "content" through the URL, which will break when you try to submit a long calculation through a client or proxy with limited length for URLs. You could also make support different representations for requests and responses.
Giving reasons for your answer, suggest two important types of application where you would not recommend the use of service-oriented architecture.
The two important types of application where the use of a service-oriented architecture is not recommended are:
- Embedded applications in devices where a network connection cannot be guaranteed. These are unlikely to make use of services as there is no guarantee that these services will be available when required.
- Real-time applications with stringent deadlines, especially those with lots of user interaction e.g. computer games. In these applications, the performance overhead in coding and decoding XML messages is likely to be unacceptable.
