Welcome to the Cloud Computing Applications course, the first part of a two-course series designed to give you a comprehensive view on the world of Cloud Computing and Big Data! In this first course we cover a multitude of technologies that comprise the modern concept of cloud computing. Cloud computing is an information technology revolution that has just started to impact many enterprise computing systems in major ways, and it will change the face of computing in the years to come. We start the first week by introducing some major concepts in cloud computing, the economics foundations of it and we introduce the concept of big data. We also cover the concept of software defined architectures, and how virtualization results in cloud infrastructure and how cloud service providers organize their offerings. In week two, we cover virtualization and containers with deeper focus, including lectures on Docker, JVM and Kubernates. We finish up week two by comparing the infrastructure as a service offering by the big three: Amazon, Google and Microsoft. Week three moves to higher level of cloud offering, including platform as a service, mobile backend as a service and even serverless architectures. We also talk about some of the cloud middleware technologies that are fundamental to cloud based applications such as RPC and REST, JSON and load balancing. Week three also covers metal as a service (MaaS), where physical machines are provisioned in a cloud environment. Week four introduces higher level cloud services with special focus on cloud storage services. We introduce Hive, HDFS and Ceph as pure Big Data Storage and file systems, and move on to cloud object storage systems, virtual hard drives and virtual archival storage options. As discussion on Dropbox cloud solution wraps up week 4 and the course.
3.3.1 Web Services
Loading...
Из курса от партнера University of Illinois at Urbana-Champaign
Cloud Computing Applications, Part 1: Cloud Systems and Infrastructure
374 оценки
Из урока
Module 3: MAAS, PAAS, Web Services
Welcome to the third module, where we introduce Metal as a Service (provision real hardware in the cloud), Platform as a Service (provide a platform to run user code on) and Web Middleware as the glue technology that empowers cloud computing.
Познакомьтесь с преподавателями
Roy H. CampbellProfessor of Computer Science
Department of Computer Science
Reza FarivarData Engineering Manager at Capital One, Adjunct Research Assistant Professor of Computer Science
Department of Computer Science
[SOUND]
We described how to build clouds and
how you can create scalable cloud services.
The question is, what sort of services would you provide?
And, if you like 101 is Web Services providing just the feasibility
of a scalable web server that can cope with multiple requests and
an increasing number of requests that would require more servers,
and perhaps that fluctuates from being enormous to a small amount.
You can imagine, for example, the Olympics.
The Olympic servers might, you might just have one server serving everybody but
as we get close to the Olympics you're going to want a large number of
servers providing Olympic information.
And that's going to scale up over the period.
If there's excitement about a particular event, you may have to duplicate servers
for that particular event serving out the web requests.
And then eventually, it'll be history, and you can shrink that whole operation down.
You will have seen from the previous descriptions,
say OpenStack, of what you can provide as an infrastructure to do this.
But what we didn't describe is just how would you make a web service
that's scalable and can operate that way, and in this lecture,
and in the NP you're going to be doing, what we're going to be
exercising is web services and the ability to be able to scale.
So, overview, today we'll be well, how do you provide web services?
And that might seem simple to a lot of you, but hold on.
As we go through it, well there will be ramifications of what we're
describing that might get a little bit more complicated.
We're going to talk about how web services can migrate into
providing remote procedure calls using SOAP and RMI.
And this forms the basis of doing many of the operations that you saw
we needed in order to be able to run OpenStack or even [INAUDIBLE].
That they communicate from a front end, a dashboard to various servers.
And they use protocols to do it, and
those protocols are based on HTTP and actually SOAP underneath.
Well, later we'll find out that they use JSON and XML and
all sorts of other things.
What we will then go and talk about is a prescribed way of using HTTP,
the record state associated with HTTP, so
individual HTTP requests can move you through the state effectively,
the server behaves like a state machine and the requests come in and
move you through to that state machine and that description is called REST.
We'll describe that.
And then we'll go for richer descriptions of HTTP, JSON and
XML which add information on or above, just
straight HTTP requests so that you can have a richer communication environment.
The reason for all of that will be we'll get to load balancing and
what we're going to describe is this situation where you provide
a web service to lots of people.
And as those people increase, what you would like to do is to take their
requests and move them to different servers.
You're going to use load balancing to do that and you're going to exploit some of
the features that were in those earlier protocols to allow you to do that easily.
So that's the name of the game, and what we're going to start off is just talking
about web servers is we're going to ease into it, and then by the time you get to
load balancing, you'll see why we're being careful about defining our terms.
So, this is the notion, we're going to introduce you to web services and
load balancing.
And typically you're out there in the cloud, in the internet,
you're accessing through whatever mechanisms, but
it'll involve routers into your data center.
There will be a server in the data center and
that will be running on its own machine.
All those requests coming off the router will go into that load balancer.
Typically, the load balancer doesn't do very much.
What it does is to farm out those web requests to different servers.
It makes sure that if you're client A say,
you're going to go for web service to a particular server
A in a consistent manner throughout your session with the trial.
The next time you come back you might go to a different node but
this time you will be going to that particular node to provide the service.
So, the load balancer is going to look at the overall incoming requests and
it's going to say well, I've got a lot of load on these machines, I need perhaps to
create a node with a new web server for you.
Puts it up and then lets you talk to it.
So what it's in charge of is fair sharing if you like, or
sharing out all those requests for service amongst the available servers.
And if it doesn't have enough servers, it will go and
create extra ones as necessary.
Depending upon how sophisticated the load balancer is.
So, once you actually farm out the request and
you notice the flow goes down, we got the internet here.
It's going to go down through the router, but the load balancer
is going to send the request to the individual web servers.
They're all going to be sort of identical, duplicates of each other.
They're going to provide the same information, but
they're going to respond particularly to one particular person.
That web server is going to reply to you with the results of your
web request and so that will follow the network back to you.
So there has to be a linkage between your request and the reply.
Well, the techniques for doing all this commonly lumped together in one
definition of software is this sort of middleware layer for the web.
Basically, middleware that provides services to applications beyond those
available from the operating system point of view.
The middleware allows you to have libraries,
all sorts of different services.
So, typically the web services would be classed as middleware.
And what we going to describe is how all those
components needed to make this happen.
So, why middleware?
Well, what we're trying to do is to provide those functionalities
across different applications, across different types of implementation,
trying not to duplicate software that we don't need to.
And also making sure that people don't reinvent the wheel, and
don't have all sorts of different ways to do very similar things.
So what you're going to find is there's middleware for HTTP,
there's middleware for the web services,
there middleware for JSON, all that stuff is implemented in that sort of layer.
What we're going to be doing is building distributed systems.
They're going to be very, very identical to each other for maintenance purposes.
They're not going to be that different from a single node, they're just going to
be tweaked, if you like, so that they work in a distributed fashion.
So here we've got the applications,
they're going to want to communicate down to your cloud systems.
Those cloud systems are running operating system services.
The middle layer is in the middle and it implements all different functionalities.
It's going to Put/Get Data for the HTTP requests.
It may implement remote procedure calls,
meaning what it will do is to simulate the effect of a procedure, but
that procedure will cross the boundaries from your application on your browser to
the remote site where it will look like a procedure there on the actual cloud.
And then you will get return values coming back to your
browser just as if you called a procedure locally.
And that's implemented with SOAP.
There's going to be support for applications beneath that.
So that support needs meta data about what you're doing.
And that meta data is provided in different data
representations like JSON and so on.
And so there's another middleware layer that's responsible for that.
And then the operating system will be actually running the servers and
interacting, the middleware will be communicating with those servers and
so it will all fit together.
So, let's first look at SOAP, as an example.
We understand HTTP.
What's HTTP does is to put and get data to and from a server,
you put a request, you get back the web page, and that's a Get.
And that is get send display.
Well, let's suppose you want to do something more sophisticated than that.
Let's suppose that what you want to do is to make a request to
create a OpenStack server, say.
How would you do it?
Well, the mechanism that's used is to transmit
an HTTP request with a Put to the OpenStack interface.
And it'll be coded in XML with all sorts of special meta data in it.
And what you're going to get back is a handle
in the form of a XML document if you like.
That would describe the instance, the OpenStack has created for you.
So that sort of return and reply, what it's done is to change the state of
the cloud in response to a request for you.
And so it really acts like a procedure call in a sense.
And there's lots and lots of different circumstances where you can
actually make those type of procedures out of the web requests.
But SOAP is a protocol that allows you to do it simply.
It's well defined so that you can read those SOAP requests and
see what's going on.
And there are tools actually to build SOAP systems, it really underlies
the web service description language, WSDL that you can find on the world wide web.
Or in other places it describes a sort of protocol for
establishing more complex relationships other than just a plain web service.
So that type of description
that SOAP is an example of providing procedure calls as we said.
In general, procedure calls can be two objects, meaning
it's not just the procedure call that is a special argument in the procedure
that denotes a specific entity on the cloud service that you want to talk to.
So, in this way, you can talk about lots of different
objects within the cloud by using that object parameter in your request.
So you have procedure calls, you have a special parameter which is the objects.
Typically, if you do that then the procedure call will be routed
to that object to actually invoke the procedure on that object,
and you have a sort of remote object call effectively.
You also find that there's notions of shared memory
which don't really work across a distributed system.
So as a consequence what you do is to have representatives of objects.
You have identifiers for the objects.
And you pass these backwards and
forwards because you don't really have a shared memory environment.
And you can't just name an address, you have to use some sort of handle,
some sort of identifier.
And what we're going to find is in things like SOAP and so on,
you're going to be using web addresses actually,
those strange slash slash slash slash path names
to actually identify the objects that you want to talk about and which is shared.
So the middleware is going to provide all the software
to allow this to happen in a distributed application.
It's all going to be transparent to you as a client, what is occurring,
the middleware will provide that level of functionality.
We're going to start by backing off, if you like, going to square one.
What are objects?
What are procedure calls?
And let's just see how then that gets mapped into HTTP.
So, within a process' address space, you typically have an object.
It's gotta set of data or set of methods.
You probably met it as a C++ object, you probably met it as a Chord object.
There could be all sorts of ways you might see this.
The object reference is usually some sort of identifier which uniquely
designates that particular object, and typically in C++ it will be a pointer.
Now nothing like that will work in a distributed system, and so
we need to find substitutes.
We need to find distributed substitutes to these in our middleware.
And at the interface, what you're going to be doing is processing requests,
which will be basically calls to different procedures.
And one way of talking about that is you'll have a set of methods on an object.
Each of those methods will be a procedure.
There'll be a unique object in the procedure parameters that's the,
the object method or designates the object to which the method is being applied.
You'll going to want to describe what that formal mechanism is and
that will be a signature.
These requests will return arguments and
so you will have this two way protocol.
So, put(objectname), get(objectname),
those are the types of things that you will have for talking to objects.
You will provide, or
the middleware will provide mechanisms to go across address spaces, as we've said.
So you're talking your application space, you want to talk to the servers.
Your going to want to cross those address spaces,
you use something called a remote method invocation,
meaning that you will look as if your application is calling a procedure and
what it turns into is a set of HTTP request to the server at the back end.
The server take those request, submit them back into a procedure call
on the right object, get the return values, return them again with the web and
they will again get mapped back on your machine into the results.
So remote objects will be objects that can receive
remote invocations following a procedure call, looking like a procedure call.
Remote object reference will be some sort of string, perhaps a URL that
refers to a remote object can be used instead of a pointer or an address.
And a remote interface, well that's going to be how you call these,
how you actually invoke the procedure mechanisms and typically it's going to
look like some sort of web server in our implementations we're going to describe.
[MUSIC]
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2019 Все права защищены.
