Re: [service-orientated-architecture] Re: Bray Prefers it Web-Style

[Eric Newcomer]

Jan,

 

The question is not always whether or not it's possible or suitable, but whether or not it is the best solution for a given requirement.

 

Customers I talk with are concerned about the qualities of service in HTTP based systems, especially around security, reliability, and yes, transactionality.  It may often be possible to code around the fact that HTTP based systems don't include as robust features and functions in these areas, but then the question is why one should do so.  It is possible to code your own database management systems and application servers but why would you?

 

I believe this has more to do with HTTP's design center around wide area network scalability than it does human-human or computer-computer paradigms.  I completely agree that HTTP can be used (and in many cases should be used) for computer-computer interactions. 

However as I have mentioned before, it is missing a key component compared to transport protocols designed for local area network use - persistent sessions - which was done of course to avoid the expense of persistent sessions on Internet scale interactions.

 

In the specific case of 2PC I am not sure you intended this meaning but it is not really a networking function or even a distributed processing capability.  Transactions are a platform capability because they are concerned with operations on data.  And while the costs of 2PC are frequently mentioned, it is really a question of a cost/benefit analysis in which the benefits in many cases outweigh the costs.  If you do not have a 2PC engine to ensure that multiple operations on data succeed or fail as a unit you either have to write a lot of code to compensate or recover, or include manual intervention to discover and correct partial results.  And this means any kind of failure, not just networking failure - and of course by far the largest cause of failure derives from failures in software systems and next from human operations of them.

 

If your application requires 2PC you benefit from its use - coding around it is not really practical since a 2PC engine has to be absolutely reliable and it is not easy to implement a reliable transaction manager.  I would agree it's not applicable in all cases - no more so than HTTP is always applicable - but where it fits it is a very good technology to have in the toolbox.

 

Eric

----- Original Message ----
From: algermissen1971 <[EMAIL PROTECTED]>
To: service-orientated-architecture@yahoogroups.com
Sent: Tuesday, September 26, 2006 11:37:05 AM
Subject: [service-orientated-architecture] Re: Bray Prefers it Web-Style

On 9/25/06, Steve Jones <jones.steveg@ gmail.com> wrote:
>there are very very few systems (and practically nothing I've seen in
REST world) or indeed developers and architects who can yet build
effective agent systems

>Taking the "power" of this model and trying to apply it to standard
computer to computer systems is much more likely to cause failure than
not.

I think the question of human to human or computer to computer
interaction is comletely misleading as it is only related to how
unambigously specified the payloads are.

I could pass the number 10 through a void parameter in an RPC style
system to a human and she would be able to make sense of it given a
context - a computer won't. Or the other way round: I can pass an Atom
entry to a computer and the computer can look for the edit link in the
entry data and update the entry all without human interaction because
Atom is specified unambigously enough.

The suitability of REST (or HTTP or WWW) for computer to computer
interactions is a question of system requirements and so far I have
only seen mentioned two scenarios where REST is not suitable: one has
been mentioned by Mark and involved the transfer or enormous amounts
of tiny messages (IIRC) and the other one IMHO is a scenario where two
phase commit transactions are inevitable. (Re the later one: if you
design a networked system (read: involving networks that might fail,
multiple independent parties etc.) and think 2 phase commit is
inevitable, you should propably rethink the design to eliminate the
2PC anyway).

Jan

__._,_.___

SPONSORED LINKS

Computer software program	Computer software spy	Computer job
Database software	Discount computer software

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___