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.
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.
What is API?
What is Importance of it?
give me example of it?
how can developer use API?
For a broad answer to your question you can check wikipedia:
http://en.wikipedia.org/wiki/Application_programming_interface
An API is an abstraction that describes an interface for the interaction with a set of functions used by components of a software system. The software providing the functions described by an API is said to be an implementation of the API.
An application programming interface (API) is an interface implemented by a software program which enables it to interact with other software. It facilitates interaction between different software programs similar to the way the user interface facilitates interaction between humans and computers. An API is implemented by applications, libraries, and operating systems to determine their vocabularies and calling conventions, and is used to access their services. It may include specifications for routines, data structures, object classes, and protocols used to communicate between the consumer and the implementer of the API
What Good Are They?
APIs allow us to tie functionality into websites that would otherwise take an enormous amount of time and effort to build from scratch. APIs are a sanctioned way of reusing someone else’s functionality without having to build it all yourself.
http://en.wikipedia.org/wiki/Application_programming_interface
I was today trying to figure out on working with WebService and found many articles really gospel over the Web Service and its effectiveness in the Market share.
My Questions are:
For a Complex project of critical data, is it better to opt for WebService?
What Makes WebService different from other way of fetching the data?
The answer is... it depends. Web services are not really the next Big thing, they have been a Huge Thing for years now. In business applications, web services allow a big level of interoperability and capabilities never seen before.
They help integration with legacy systems, cooperation between distinct departments, defining loosely coupled interfaces and such. You should read some about Service-oriented architecture.
If all you need is a PHP application that handles data from a single database, you might not need web services at all. If you are designing a solution that revolves around multiple data sources, with complex security involved, multiple languages and/or multiple applications, then web services become essential.
SOAP is a protocol; if working with PHP, you'll need to check out the PHP: SOAP guide to understand how it works. For every language (almost), there are existing APIs to develop web services. Anyhow you might want to check RESTful web services instead of SOAP-based ones, they are generally simpler to implement/understand. But that's another debate ;-).
Cheers.
That mostly depends on the definition of "big thing".
My experience with the WS stack and SOAP and all the acronym soup is that it takes an awful lot of workforce to deploy it. The status of the frameworks is complex, and definitely not something a hobbyist can put to work in a couple of afternoons. We have seen how many things on the net became the next big thing just because they were easy. Easy to understand, easy to interact with, easy in technology. Wikipedia, twitter, digg, youtube are internet big things, and they are, from the interaction point of view, light years away from SOAP/WS based interaction. They are KISS: simple and stupid. A whole horizontal market was opened just because of their simplicity. Even multiprocessing platforms like BOINC don't use anything near the WS stack, but they are the core of many high-throughput efforts.
Now, if you have to deal with complex multi-host transactions, authentication, credential delegation, caching... WS is there. It's the target that makes the need: banks, flight reservation, stuff like this. but they won't impact the common programmer. They require too much energy and too many different competences at once to become something usable for a horizontal market of developers.
Also, I am a REST person. I never advocated SOAP with much emphasis, but there was nothing else and it was a better evolution over XMLRPC (which, if you have to perform dumb RPC, IMHO it's still a good choice). Now I changed my mind. You mostly have resources on the web, and you interact with them with HTTP methods. SOAP is nothing but RPC on hypersteroids. No, REST is not the solution that replaces WS. At all. it's simply easier to use and to debug, albeit more difficult to design (you have to think in terms of resources instead of method calls). It's KISS. That's why it has more chances for success on the horizontal market.
It depends.
Web services can be useful if you need to expose the data across security boundaries, where a direct connection to an RDBMS would be a bad idea.
Popular method for implementing web services nowdays is to use RESTful API (eg. via Ajax/JSON). It's already "next big thing" – almost every major player has been offering it for years. Google, Flickr, Twitter, you name it.
The big advantage is that they help to implement an API layer.
If you implement your solution using a "bus" where the web services sit, it opens up your product to a far greater range of users and moves away from being a proprietary product.
It also enables people to interface using a wide range of solutions e.g web service clients can be implemented using command line, Jsp, Java, Asp, .NET, PHP etc.
They also enable code re-use e.g. if you implement GetClientDetails (ID) as a web service for one user, when the next group comes along wanting the same thing, all you have to do is give them the WSDL and they are away.
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.