Seems to me like CS people like to invent new names for the same concept, doesn’t it? Don’t they all mean the same anyway – Service Oriented Architecture?
They do. The idea behind those terms is to decouple the business logic (BL) or the actual application code providing a service, from the front-end consuming that service. Basically, what webservices do. They provide a service and return the data in a standard format without adding any presentation information to it (i.e. HTML). That leaves the job of interpreting and rendering that data to the front-end application logic, which can very well be a piece of JS code running inside a browser.
This is really good, because it decouples the application (BL) logic – or Controller if you will – from the presentation logic, the View; meaning that you can develop them independent of each other – or change one of them without changing the other; as long as they both adhere to the contract laid out for the service, they work.
The downside of that approach is that most SOAs are inherently stateless because they assume that front-ends come by, request some kind of simple service and then go about their business – what theory nerds call ‘loose coupling’. Yahoo’s webservices are a good example – like the keyword extractor: Send a long text to it, and you get extracted keywords back, it’s as simple as that. This might be good for simple things, but as soon as services get more complex, require logging-in, or involve extensive BL, that becomes a drawback. Now there are only two options: Either forget the statelessness of the service or transfer that state w/ each request anew. The first breaks the model of SOA which is not good, whereas the second might end up transferring lots of data and – you guessed it – creating the same problem that HTML has all over again (crafting state onto a by definition stateless protocol).
But remember, SOA does not command to be stateless, it merely states that it is beneficial if the services are loosely-coupled. This can very well be achieved by breaking your BL into small, distinct services that might each preserve a small amount of state: an auth. service, a basket service, a pref. service etc. all communicating with each other. The downside again, is that this generates more traffic/latency between the services thus degrading overall performance. But – oh well – there is always a trade-off, right?
So, whats there to do? Well not much, either accept one of the two solutions, find a middle-way depending on your needs and environment or implement only simple services using SOA principles.