I do not think I’m confused. I mean exactly what you seem to imply I mean. SOA web services expect you to describe the semantics of any interaction. REST, on the other hand, does not. Even if you only had two possible interactions with a SOA web service, they would still be more complex than the REST equivalent.
I would argue that what you call “application semantics” is independent of the technology being used and, therefore, a constant we can dismiss. (If it can’t be factored away, as you say, then it is always there… so it is a constant.)
Let us take your example of a gene or protein. Should the web service need to know the taxonomy or ontology of genes or proteins? I think not. Does it need to know that these two unique identifiers refer to the same thing? I think not. I think information should be provided strictly on a “need-to-know” basis. The minute you start tying things together, you introduce coupling, and therefore complexity. Your software starts making assumptions, you increase (without cause) the level of abstraction, and things break.
One should always aim for the simplest possible solution… and providing lots of semantics is not a simple feat.
Aren’t you confusing service semantics and application semantics? REST reduces the possible ways to interact with a remote application/service to 4 (really 2, most of the time). This is clearly less complex. However, the application semantics don’t seem any simpler to me. The developer has to understand what the result is of GETting a resource at a particular URI. They need to understand the interface or API being used. This seems potentially very complex — am I getting a gene or protein, is the name based on terminology A or B, what is the precision of the expression level, etc. This kind of complexity can’t be factored away.
I think we’re in agreement. I just wanted to point out that of the hard things that need to be done in interacting with a service, the nuts-and-bolts of the interaction are the simple parts. It’s the application logic that is complex. But a lot of the debate seems to ignore that aspect.
Stephan Hagemannsays:
I feel that one can track the origin of the semantic complexity with SOAs to their explicitness and – as you discussed – interaction formalization. However, (informal) semantics are present in REST architectures as well. Here a programmer has to figure out more meaning prior to implementing – otherwise his code will not work. As the semantics are not explicitly handled any more once the programs run there are few points of failure, as you state.
Nirmit Desaisays:
I think SOA is a much broader paradigm than you seem to imply. In my understanding REST is just another way to interact with web services. REST is an alternative to SOAP, and not SOA. SOA would include in addition to the interaction protocols, service description, service publishing, service discovery, service matching, service selection, and service engagement.
Nirmit: Yes, there is a whole lot of stuff (for lack of a better word) in the SOA stack. But I do precisely mean that people are sidestepping all of it in favor of something several orders of magnitude Web-friendlier.
I predicted in 2002 that SOA would go nowhere. We are in 2007 and it has gone nowhere so far. And people keep claiming that it will make it, finally, maybe next year, but it won’t.
Oh! Microsoft has web services. Java has web services. But these things do not interoperate. There are nothing else but proprietary remote function calls as we have had them for years and years.
We have not come forward one iota.
Shopautodotca Seocontestsays:
Hi, all excess are harmful even in technology. The best motto is to keep it short and simple. As you pointed out, the simplier, the better.
I do not think I’m confused. I mean exactly what you seem to imply I mean. SOA web services expect you to describe the semantics of any interaction. REST, on the other hand, does not. Even if you only had two possible interactions with a SOA web service, they would still be more complex than the REST equivalent.
I would argue that what you call “application semantics” is independent of the technology being used and, therefore, a constant we can dismiss. (If it can’t be factored away, as you say, then it is always there… so it is a constant.)
Let us take your example of a gene or protein. Should the web service need to know the taxonomy or ontology of genes or proteins? I think not. Does it need to know that these two unique identifiers refer to the same thing? I think not. I think information should be provided strictly on a “need-to-know” basis. The minute you start tying things together, you introduce coupling, and therefore complexity. Your software starts making assumptions, you increase (without cause) the level of abstraction, and things break.
One should always aim for the simplest possible solution… and providing lots of semantics is not a simple feat.
Aren’t you confusing service semantics and application semantics? REST reduces the possible ways to interact with a remote application/service to 4 (really 2, most of the time). This is clearly less complex. However, the application semantics don’t seem any simpler to me. The developer has to understand what the result is of GETting a resource at a particular URI. They need to understand the interface or API being used. This seems potentially very complex — am I getting a gene or protein, is the name based on terminology A or B, what is the precision of the expression level, etc. This kind of complexity can’t be factored away.
I think we’re in agreement. I just wanted to point out that of the hard things that need to be done in interacting with a service, the nuts-and-bolts of the interaction are the simple parts. It’s the application logic that is complex. But a lot of the debate seems to ignore that aspect.
I feel that one can track the origin of the semantic complexity with SOAs to their explicitness and – as you discussed – interaction formalization. However, (informal) semantics are present in REST architectures as well. Here a programmer has to figure out more meaning prior to implementing – otherwise his code will not work. As the semantics are not explicitly handled any more once the programs run there are few points of failure, as you state.
I think SOA is a much broader paradigm than you seem to imply. In my understanding REST is just another way to interact with web services. REST is an alternative to SOAP, and not SOA. SOA would include in addition to the interaction protocols, service description, service publishing, service discovery, service matching, service selection, and service engagement.
Nirmit: Yes, there is a whole lot of stuff (for lack of a better word) in the SOA stack. But I do precisely mean that people are sidestepping all of it in favor of something several orders of magnitude Web-friendlier.
I predicted in 2002 that SOA would go nowhere. We are in 2007 and it has gone nowhere so far. And people keep claiming that it will make it, finally, maybe next year, but it won’t.
Oh! Microsoft has web services. Java has web services. But these things do not interoperate. There are nothing else but proprietary remote function calls as we have had them for years and years.
We have not come forward one iota.
Hi, all excess are harmful even in technology. The best motto is to keep it short and simple. As you pointed out, the simplier, the better.