Based on an understanding of architectural styles, you will review architectures for web applications, then explore the basics of Service-Oriented Architecture (SOA) in two approaches: Web Services (WS*) and Representational State Transfer (REST) architecture. In the Capstone Project you will connect a Java-based Android application with Elasticsearch, a web service with a REST application programmer interface (API). After completing this course, you will be able to: • Describe SOA (Service-Oriented Architecture) to structure web-based systems. • Explain WS* services (i.e., SOAP over HTTP, WSDL, UDDI, BPEL). • Apply REST architecture (i.e., JSON over HTTP, URI). • Identify REST design principles. • Create a system using REST interfaces. • Apply microservice architecture.
4.1.1 – Introduction to Service-Oriented Architecture
Loading...
Del curso dictado por University of Alberta
Service-Oriented Architecture
127 calificaciones
University of Alberta
127 calificaciones
Curso 4 de 4 en SpecializationSoftware Design and Architecture
De la lección
Web Technologies
In this module, we will introduce you to service-oriented architectures and their basic principles. Then, you will get a crash course on the technologies that underpin the Web, so that you are ready to learn about web services in the next module. This module also covers some earlier precursors of service-oriented architecture.
Conoce a los instructores
Kenny WongAssociate Professor
Computing Science, Faculty of Science
[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.
Explora nuestro catálogo
Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.
Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.
© 2019 Coursera Inc. Todos los derechos reservados.
