[MUSIC] Welcome to the fourth course of the Software Design and Architecture specialization. Brought to you in partnership by Coursera and the University of Alberta. We'll be exploring service-oriented architecture in this course. If you've already taken any of the first three courses of our specialization, welcome back. Previously, you saw how to build systems using objects and apply design principles and patterns. You also saw how to organize systems on a larger scale using various software architectures to structure the components. Now you'll learn about creating systems by assessing and combining services. If you've just arrived, you may want to check out our previous courses in this specialization. They're on topics of object-oriented design, design patterns and software architecture. These courses will set a foundation for this course on service-oriented architecture. In particular, we'll visit notions like coupling, separation of concerns, and layering. As well as using different UML diagrams to understand the structure and behavior of service-oriented systems, web applications and web services. With that being said, all of our courses stand alone. So if you're just interested in expanding your knowledge on service-oriented architecture, then we're happy to have you join us. This course follows the same pattern as the previous three. There are four modules with the first three focused on video content. Throughout the course there's a capstone project, so you can apply your new knowledge. You will complete assignments for the capstone project throughout the course, but the majority of the work will take place in the fourth module. The first module will teach you about system space and services, service-oriented architecture and a variety of important web standards. These standards are useful, not only understand the architecture of web applications, but also understanding systems based on web services. In the second module, you learn about using first generation web services. In the third module, you'll get into REST architecture and REST services, also based on web standards. In your capstone project, you'll be dealing with REST services. So let's get started. Your first lesson will introduce services and service-oriented architectures. >> Imagine that you are a busy software developer with little spare time. You want to get onto that piece of code you're working on. You don't want to spend your time doing chores. Luckily, all kinds of services exist so you can do just that. Instead of doing chores, like your own laundry, you can drop your clothes off at a laundromat and pick them up later, clean and pressed. Instead of doing all your cooking yourself, you can have all or a part of this process done for you. You might get meals at a restaurant or from a lunch service, or maybe you get meal boxes that are prepared but not cooked. You don't even need to drive yourself to work. You can use a ride service with just a few taps on your mobile phone. These are just a few of the examples of the services that modern humans have access to. Just like us humans, software can use external services. Does your software need to know the weather? You could build weather stations and prediction models, or you could just get the weather forecast from a service on the Internet. Do you need to know the exchange rate between the British pound and US dollar? You could query the buy and sell rates of several banks that exchange between the two currencies and build an estimate that way, but plenty of estimates of exchange rates already exist. Wouldn't it be easier to use an existing service? A service, as opposed to a component, is external to the software requesting it and often remote, either in another server in the company or somewhere out there on the Internet. Deploying a service means providing a tool that other software can use, whether it is software in the same organization but a different department, or software that uses your service over the Internet. When we talk about services, we often talk about two roles. The service requester, which is the software requesting the service, and the service provider, which fulfills the request. These are very similar to the client and server roles in similar domains, so sometimes those are used as well. Service-oriented architecture is all about how to build, use and combine services. So why is service orientation so important? Why do we have a whole course dedicated to service-oriented architecture? Let's return for a second to your service-oriented life. We streamline our lives by using the services that other people and businesses provide. We trust that they give us what we need, while they focus on providing those services. Most businesses in turn rely on other services. A restaurant relies on food supply chains, while a laundromat relies on appliance mechanics for their washing machines. We are going to talk about bringing the concept of services into software. Instead of building large software suites that do everything, service-oriented architecture is all about achieving your software goals by building and using services and designing an architecture that supports their use. We'll talk about it two contexts, on the Internet and in large organizations. You may also hear these described as external or internal, that's external or internal to an organization. The overall idea is the same in both cases, but the results look a little bit different. Let's start with web services. Web services refers to services that are offered on the Internet. One way to build featureful apps on the Internet is by using existing outside services on the web to fulfill some of the tasks. For example, imagine that you want to build a web application for trip budgeting. Let's call it Backpack Budgeter. The first thing your perspective customers may want to know is how much it costs to get there. Luckily, the lowest fly prices are available on the Internet, so you can use an existing service to get this information. We've already talked about currency exchange rates, your software will use existing service for these conversions and, similarly, for local food and tour prices. The key point is that most of the services you need for your Backpack Budgeter app are already available in the form of services on the web. All you had to do was combine them together to create an app. In large enterprises or organizations, in-house code can be turned into services that can be used by different parts of the businesses or combining two more services. These services can be built from the ground up or by adding interfaces to existing software. Once implemented, services can be used to drive the business or organization goals. Let's take a look. For example, the information technology or IT department at many companies tracks support cost in their software. When another department need this information, they can ask the IT department for it, and it's sent over email. But wouldn't it be better if the support cost were offered as a software service? The IT department could provide an interface for software systems in other departments to ask for information about support costs. Now that support costs are offered as a service, other departments can query the service as needed. Maybe management wants this information to calculate returns on investment, and accounting needs this information for tax services. Now that the service is provided any department who needs the information can get it through the software interface. Internal service-oriented architecture encourages organizations to build general, reusable software services that can be used and combined as needed. This allows businesses to respond to opportunities quickly, rather than being slow to act because of a rigid internal software system. Services are easier to access for new business units, like when there's a new department or a merger. Service-oriented architecture, also called SOA, is an architecture like any other. It involves trade-offs and design decisions in implementation. On the web, the ease of using existing services must be balanced against the qualities of the services. Something that developers may not be able to control. Non-functional requirements become very important. For example, response time, if you are relying on a service, you may want to know how quickly it can be provided. Supportability, do you trust the service provider and the service? Will it always be available in the future? Availability, is the service always running and available for use? In large organizations, one of the chief disadvantages of an extensive service-oriented architecture is that it is often completely different from the status quo. That means that a full switch to SOA could be costly and difficult to support compared to its benefits. When this is the case, services are often introduced bit by bit, separating out the most useful, cross-departmental functions first. SOA is also not easy. The idea sounds simple, but in fact, the modularity and platform independence needed to make services effective do not come by accident. In this course, we will touch on the properties that services and service-oriented architectures need and some ways that these properties are built in. Once a service-oriented architecture is in place, it is very powerful because it provides modularity, extensibility and code reuse. Applications can be built by combing services. New services can be created by combining existing services, or new services can be created from the ground up or by adding interfaces to existing code. >> So we use web services profoundly and thoroughly throughout our company and throughout the projects that we have. Virtually all of the business logic that we have is encapsulated in web services of some kind. And these range from utility services for managing storage or object storage in a shared system, all the way up to high-level web services that encapsulate an entire business flow. So there's different levels of abstraction in the services, different layers of that architecture. >> Our main architectural view is that we do two things when we look at a problem. We look at what the client is doing, and we try and identify if from the client's standpoint, what are the things that they do that can be kind of encapsulated into conceptual chunks. Those we call services. So for example, in the engineering applications we do, one of the services that clients have to worry about is the sign off steps that occur in engineering workflow. Where designs go through various stages, and once they're signed off, aspects of that design are frozen. And then if you want to change them, you have to go back, and then you have to start the workflow process again. That whole management of change part can be encapsulated as a conceptual service. So we sort of say, okay, for this particular client, they need a management of change service. They might also need particular version control in escrow services. So we start off by saying, okay, what are these kind of chunks that the problem can be divided into that are expressed in terms of doing some particular thing? We, of course, also have the other services that are down at the low level, which are the implementation services. User interface, the database, we view them as services. And then what makes something a service, well, at least trying to articulate what the interface to it is. If I were to use the database I know that my interface is typically SQL. If I'm going to use the workflow service, what's the kind of requests I'm going to make to the service? What's the kind of responses? Once we've got a API, and this kind of fuzzy, box. Well, not even box, cloud of things that we call a service. Then we can start putting the services on the white board and showing the relationship between them, and that's kind of the beginning of the architecture. So it's this decomposition of services that's important. Noting, of course, that services as these conceptual notions, they actually might get implemented across many different parts of a system. But that's okay, that's an implementation issue. Hide information from the users of a service as much as possible. Notice, I'm thinking in terms of services again. If you're going to combine services, try and make the coupling as simple as possible, but it might be complicated. And if you do have awkward relationships between services make sure that's well documented. And if it's possible, if you have complicated interactions between services make sure that that is understood by the whole team, because that's where your high risk is. Whenever you have very complicated interactions between parts of a system that's where a lot of your risk of failure is going to be.
