AW: Re: [service-orientated-architecture] Re: transfer vs. transport protocols

Wed, 24 May 2006 06:29:01 -0700

Radovan,

two things:

- Not coordinating the design of shared semantics (as in the Web case) is not a property of REST and REST does not prohibit that you enforce more control within an intra-enterprise or B2B context.

- You mention the cost in your example; I think it should also be pointed out that this is the cost for an infinite number of uncoordinated people designing shared semantics for the same domain. I think it is an extreme benefit that this gives practical results *at all*. The cost may be high, but compared to the achievement it we might want to consider it rather low. Also, it should be mentioned that the costs were saved for coordinating these people at design time.

Jan

 

 

  It's interesting how many REST discussions started by arbitrary topic end up at "what is the contract"? It's my personal issue as well. I do not share traditional anti HTTP complaints you hear from enterprise architects: lack of reliable messaging, lack of distributed transactions, and stuff like that. Many of these complaints have EAI (today ESB) roots and are largerly irrelevant to SOA (including HTTP/REST).

However, I see lack of contract as the main issue and perhaps even showstopper in enterprise. Let's take feed readers as trivial (hope not too trivial) example: these readers have to understand rss 0.91, 1.0, 2.0, atom at least. Now, look at your blogroll and do HTTP GET to few feeds you read - you'll get at least text/plain, text/xml, application/xml, application/rss+xml Content-Types regardless of what you send as Accept. And all of this is after many years of RSS being in production and development. You might say - but it works! Yes, it does. When I experience issues with FeedDemon (because it didn't support Atom) I switched to bloglines, then back to FeedFemon, then back to bloglines. I do not see any cost associated with thousands of developers working on tens of feed readers, blogs software, etc. That's why it works. Companies see the cost. You can't switch enterprise applications that quickly and companies don't have thousands of developers free for this. And they have roadmaps and deadlines.

Radovan

On 5/24/06, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote:
>It may be interesting to look at how poorly the web works from a
>program-to-program point of view. 

IMO, nobody has yet come up with a use case that cannot be successfully implemented using Web architecture. And your examples below are taken from MIME types designed for (eventually) human consumption and that were extremely affected by the browser wars and presentation issues.

Consider HTML, for example. 

I have been doing system to system integration with HTTP and RDF during the last two years and did not really have any problems that I would not have had with a non-REST arch. style.

>Our colleagues in the web world are really struggling to get a handle
>on this mess.  In the meantime, there exists considerable "tight
>coupling" between most web sites and particular browser implementations.

Well, that is bad design and not a problem of the arch. style, eh?

>But our "dumb" programs aren't anything like as smart.  In fact, the
>world of business and especially commercial transactions require
>quite "tight coupling" in the form of precise information
>understanding.

Hmm, I don't think that precise shared semantics increase coupling beyond an unavoidable amount. Besides: you need that precision for machine-to-machine communication in any case.

That is, commercial transactions need to understand
>exactly what is being said during a message exchange with no
>ambiguity. 

Can you give an example where any of the existing MIME types is ambigous?


>No, I think that we still have some way to go in order to realise the
>true issues and benefits of "loose coupling" when it comes to program-
>to-program interactions. 

IMO, the true issue is increasing the amount of work service and client developers can do on their own without a need for coordination between them. If you need to inform the (potentially residing in completely independent administrative realms) client maintainers for almost any change you make to the service implementations then that is a coordination cost (measurable in Dollars) you'd like to avoid.

REST does exactly that: reducing the overall coordination cost.

Jan


I just wish we could move on from the rather
>sterile SOAP vs. REST debate, with each side (esp. the latter)
>proclaiming "victory" onto what we need to do to solve the real issues
>involved...
>
>-Mike.
>
>
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>




SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture

YAHOO! GROUPS LINKS





--
Radovan Janecek
http://radovanjanecek.net/blog

SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture

YAHOO! GROUPS LINKS





SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture

YAHOO! GROUPS LINKS



Reply via email to