Does REST constitute a Service Oriented Architecture?
SOA and REST are both architectural styles. They have some common architectural styles they draw from (like Client/Server and Layered System) but the also draw from some different styles that aren't shared (e.g. SOA builds on Pipes & Filters and REST on Uniform Interface).
You can build RESTful SOA's but you'd have to adhere to the principles of both to that.
Also don't confuse REST with just using HTTP technology for implementing SOA.
You can see this pdf which contains chapter 10 of my book. Section 10.1 discusses REST & SOA in more detail
This is a pretty philosophical and a very general question that is very likely to be removed, I'll share my thoughts though.
There is a concept called Resource Oriented Architectures, defined by Richardson and Ruby in RESTful Web Services (O'REILLY 2007). I think the term is the best one to describe the most common approach to REST.
The main idea of ROA is defined by four concepts:
Resources
Their names (URIs)
Their representations
The links between them
and four properties:
Addressability
Statelessness
Connectedness
A uniform interface
When talking about RESTful Web Services, I think it's good to stick to the term ROA and all information it carries.
As for SOA, the name is extremely vague. Some people think it should be reserved for Big (SOAP-based) Web Services only. Personally, I consider ROA a variant of SOA. The authors of the book, hovewer, refuse to make a final statement.
Service-Oriented Architecture (SOA) is perhaps the least well-defined term of all, which
is why I called it out in Chapter 1 as a term I wasn’t going to use. I know of no litmus
test which indicates whether a given implementation is SOA or not.
Richardson & Ruby, RESTful Web Services, O'REILLY 2007
EDIT
The book quoted here has been made available under a Creative Commons License and is now possible to download free of charge.
Related
I have been reading on difference between REST and SOAP. I see in many posts that SOAP is a better choice for distributed transactional resources.
Please give me a practical example of SOAP being used for distributed transaction.
SOAP has been the main player for many years inside enterprise applications simply because there was no alternative. REST came later.
Since SOAP is a protocol it is easier to build tools around it since you know how it behaves always (i.e. as the protocol is defined). For this reason and because it's mature as technology, a lot of other specifications were build around it, to cover any uses one might have for doing something with SOAP. See a list here. There are of course some for transactional semantics also. If you use
SOAP with a technology like Java or C# (which are heavyweight champions in the enterprise applications field) then you can have these transactional specifications already implemented in the framework or libraries and you just use them.
REST on the other hand is an architectural style of building applications. It's harder to limit it to a set of specifications. You can implement it in many ways. It is also going somehow against "the way of the SOAP" by staying away of creating new standards or specifications and instead just reusing the ones of the web. For this reason, there are no specs or tools to help you with transactional RESTful services. You have to build your own.
So when your application is build by self-contained web services, and these services need to cooperate on creating the applications outcome, and you need a distributed transaction to guarantee that outcome is consistent (all operations succeeding or none succeeding) then it's (more) practical to go for the technology that has the better tooling in supporting it.
I am studying on Resful web services with RestEasy API. In docs of API at chapter 8 there is a topic called "Linking Resources." I read that chapter several times and I can not understand what it is.
What is linking resources?
What can we do with it?
Why do we need it?
I believe it refers to level 3 of the Richardson Maturity Model:
Hypermedia – resources contain links to related resources and
collections, and also links to perform actions on the resources
themselves. APIs are now self-documenting and discoverable.
As to why do we need it, here's a much more details answer than I could ever write.
Of course, all these are theoretical notions - but at the same time your question doesn't seem to be too tightly coupled to the actual RestEasy implementation details.
Is there a general standard (in development) towards RESTful services? Since it's HTTP, I'm not talking about the technical standard ofcourse, but a more common way of exposing methods and functionality and implementing those.
And if not, are there general rules, to follow when developing a RESTFul service?
Or should we base ourselves on general API design, where there's already tons of books written about. Only question then to bear in mind, does it always translate to the web as well.
No there is no standard for RESTful design. It is simply a style. Following the constraints of the style allows many different valid design approaches.
You cannot translate many general procedural API design guidelines into web API design because distributed computing has many different issues than library level APIs.
What is the difference between BPM and Workflow ?
Also, between BPEL and ESB ?
BPM is a discipline called Business Process Management, it's not about technology. You will find BPM Systems or Suites which are software that guides you to implement the different stages of the BPM discipline. This term is not technical is more Business Oriented.
The term Workflow is used on conjunction with BPM, but it was originally intended to describe Human To Human interactions in Document oriented companies and scenarios. The term Business Process represent more generic situations where systems and human actors interact to achieve a goal. This term can also be used outside the technical arena.
BPEL (Business Process Execution Language) is a standard also known as WS-BPEL which defines the interactions between systems, using an XML format. This standard was widely adopted by a lot of companies to define their systems to systems interactions (one of the big things against BPEL was the lack of support for the Human Interactions). This is an extremely technical thing, because it's about how to integrate systems that are exposed via web services (provides a web service endpoint to interact.)
An ESB is an Enterprise Service Bus, ESBs are commonly used to integrate different systems. The main idea is to provide a set of business connectors that allows different applications to interact under different protocols and technologies.
I suggest you to take a look at BPMN2 (Business Process Modeling and Notation 2) which is the new standard adopted by most of the BPM Systems nowadays. Check www.jbpm.org for more information.
Cheers
Is CSLA.NET architecture is a good choice in an enterprise level application?
That depends on what you mean by enterprise level... what is the application? Is a desktop application, Web based? Middleware? A shared library?
CSLA has some good and bad points. I've asked a similar question. Look at that one and this one
My criticisms are that it is very verbose, and sometimes over complex and that it encapsulates the data layer within its classes meaning that TDD is tough with it.
However it was designed for business and gives you some brilliant funcitonality straight out of the tin. The book is well worth a read.