 In this last part of module 5, I will now go into service orientation and microservices in the end. And that's mainly because microservices have recently really gained in popularity and are somewhat of a hype topic. So I think it's important to at least touch upon what this actually means. So at the core of this is something that we call service orientation. So the idea is instead of going, I would say, in the classical way by functional components, so we have a component that does UI, we have a component that does business logic, and we have accordingly specialized teams, interface designers, business logic people, database people, they know their stuff in that area. Instead of that, we structure our system according to services. So we have one service, and then we have another service. And of course, they don't have to be layered, they can be structured in any kind of way. And the idea of a service is that it is something that is independent of the product you're offering, and that it provides some kind of capability, some kind of value, you could say. And then your overall application is just taking different services and putting it together. This sounds a bit complicated, but you can, for example, remember what I did in the UML slides on the component diagram. I discussed something, I even called it a service, the payment service. So imagine you have your web shop, the web shop allows you to put stuff in your shopping basket, pay for it, and then you have this component that's called a payment service. Now, payment you can use in a variety of different applications. So even if you decide to close down your web shop, you might still be using this component for something else. For example, instead of a web shop, you decide that you would like to have some kind of application that offers business to business buying of different contractual services. So it's something that is independent of your concrete application that you can reuse in different contexts, and something that provides value in itself. So here, if you take away the UI in the database, the business logic doesn't provide you much value, but the payment service would still be a valuable thing even if you take the web shop or service one away. So the idea is that the overall system is composed of different services. And they should be coupled in a loose fashion. So it should be easy to add or remove services if you would like. They should be combined or combinable in innovative ways. So maybe you realize, well, if I take in, there is another service that some other company offers, service four. If I take that into my application, I can offer something that is really new and really cool. So it's not something that's very planned, but you can just combine things in an innovative way. So that's something you can do, and then ideally these things should be platform independent. So service one might run on an Android phone. This too might be on a Windows computer and service three runs on Linux implemented in JavaScript. This is implemented in Java. This is implemented in C++ or something else. So ideally this should be platform independent and the communication should be standardized. And this is actually or this evolved over time into an architectural style that is called service oriented architecture or SOA. And what you had in this style is a service registry. So someplace where you can register your services and say, hey, I'm having a payment service here. You can use it if you want. You have the service provider, the company or the individual that actually implements and runs the service. And well, you have the service user, you could say. You have the application that actually wants to use it. And that application could then check with the registry what kind of services are offered. Well, that registry knows about all the providers and basically deals with the communication. So the providers publish their services and the users find these services and then the users can, well, bind them. It's called in the SOA style, basically use them. That's the overall idea. So you have some kind of central place where you can say, hey, look, these are the services that I provide. And then the user can go in and say, yes, this is cool. I want that service. And you can combine them at runtime. The problem here is, of course, this has to be standardized. So you have to know how to publish services. You have to know how to look for them. And this is very often a semantic problem. So you could say, I have a service offering payment and you can publish your interface. These are the methods that you can use. But exactly what the semantics are, how you use that service, you have to somehow explain that. And that's not very trivial. So what happened in practice, and that's why SOA, I would say, never really took off, what happened in practice is that they tried to standardize all these things very strictly and it became a very complicated thing. So the idea was to keep this very lightweight, very loose, very easy to exchange or procure, buying new services. But in the end, it ended up as a very complicated thing. So here you have these different protocols. For example, SOA is down here and you had interface description in WSTL. Just so you have seen the acronyms. Those are kind of the technologies that people try to come up with to make the SOA style possible. But it never took off as much. Now, this recently evolved into something that is called microservices and we'll cover that now in the last.