Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
Presentation
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Recorded at:
The Counterintuitive Web
- Sections
- Enterprise Architecture,
- Architecture & Design
- Topics
- Web Services ,
- HTTP ,
- W3C ,
- REST ,
- SOA ,
- QCon ,
- Architecture ,
- Enterprise Architecture ,
- QCon London 2010 ,
- Specifications ,
- Conferences
-
- The next QCon is in New York June 18-22, Join us!
How would you like to view the presentation?
In case you are having issues watching this video, please follow these simple steps to help us investigate the issue:
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
Summary
Ian Robinson considers that programming for the web requires a different architectural approach than for applications: clients are interested only in URIs, clients are responsible for the integrity of a sequence of requests, and one should implement application protocols as protocol resources , not domain resources.
Bio
Ian Robinson (http://iansrobinson.com) is a Principal Consultant with ThoughtWorks, where he specializes in the design and delivery of service-oriented and distributed systems. He has written guidance for Microsoft on implementing integration patterns, and has published articles, most recently in The ThoughtWorks Anthology. He is currently co-authoring a book on RESTful enterprise integration.
About the conference
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community.QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
Ian Robinson considers that programming for the web requires a different architectural approach than for applications: clients are interested only in URIs, clients are responsible for the integrity of a sequence of requests, and one should implement application protocols as protocol resources , not domain resources.
Bio
Ian Robinson (http://iansrobinson.com) is a Principal Consultant with ThoughtWorks, where he specializes in the design and delivery of service-oriented and distributed systems. He has written guidance for Microsoft on implementing integration patterns, and has published articles, most recently in The ThoughtWorks Anthology. He is currently co-authoring a book on RESTful enterprise integration.
About the conference
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community.QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
- See more SOA content at: http://www.infoq.com/soa
- See more QCon content at: http://www.infoq.com/qcon
- Other recent content items in this topic
What's wrong with having to peer inside the body?
by
Bediako George
Posted
Re: What's wrong with having to peer inside the body?
by
Nat Pryce
Posted
Re: What's wrong with having to peer inside the body?
by
Bediako George
Posted
Did he just make stuff up.
by
William Cherry
Posted
Re: Did he just make stuff up.
by
John Schlesinger
Posted
-
One of the reasons peering inside the body causes issues is that it leads to code in your controllers/handlers that looks like this ...
if (body has this)
{
//this stuff
}
else if (body has that)
{
//that stuff
}
else if (body has the other)
{
//the other stuff
}
else if (etc ...
Instead think of separating each of those state checks in separate controllers each referenced by a single URI. For every "if else" you may need another resource. In this way the URI act as a type of router, automatically routing the resource you are changing to the right controller.
A direct side effect of this is easier to understand code, greater decoupling, and in my opinion less bugs created by trying to wrap your minds around all those if statements.
This video is a very good treatment on resource oriented design and Rest.
Impressive. -
Seems like the first two examples he presented were just complete BS. Who would write code (and call it a REST service) when it completely violates all principles of REST. No one that has been a programmer for more then three days is going to write an Order "service" that is so course grained that it handles completely different payloads at the same URI/method. The ..\Order\123 GET should get a resource named 123, ..\Order PUT, creates a resource, ..\Order\123 POST should modify the order. Period. There might have been useful information in this talk but I couldn't make it past the premise that a professional developer would write services of this armature nature.
-
Not if you use an OO design in your service.
In that case, the handler looks up an unmarshaller keyed by the content type of the body, uses the unmarshaller to turn the bitstream of the body into a running object, tells the object to act. and the object does whatever it does.
E.g.
Unmarshaller unmarshaller = unmarshallers.lookUp(request.contentType);
PostAction action = unmarshaller.unmarshall(request.body);
action.performUpon(theActualResource); -
I think you got PUT and POST the wrong way around. PUT is idempotent (if I replace the resource twice the end result is the same) whereas POST is unsafe and creates a new resource.
... The ..\Order\123 GET should get a resource named 123, ..\Order PUT, creates a resource, ..\Order\123 POST should modify the order. Period. ...
-
How did you create the request.contentType? How does the lookUp method choose the right marshaller? If there any if-then-else-if statements in any of those?
5 comments
Watch Thread Reply