Re: [service-orientated-architecture] Should Transactional Systems be SOA Based?

[Steve Jones]

Depends what they mean, the first assumption is that they mean SOA=technology rather than modelling (which I'd disagree with for starters).

If they mean "don't do massive amounts of fine grained transactional calls via Web Services, because that would be stupid", then fair enough.  If they mean doing XA multistep transaction management, then fair enough.

If they mean don't ever have a service which internally has transactions, or don't call multiple services which internally have transactions then I'd disagree because that is where compensations come in.

But I'd argue that you can always MODEL these sorts of systems in terms of services even if the WS (or REST) technologies aren't the smart choice of technology.  Lots of military systems have had a history of independent services that communicate via events and messages but they certainly didn't use XML!

Steve

On 08/10/06, jeffrschneider <[EMAIL PROTECTED]> wrote:

I just ran across some advice posted at the U.S. Army web site:
http://www.army.mil/escc/erp/soa.htm

--------
When to Use SOA
...
Transactional Processes – Not good SOA Candidates because large
transaction volumes are too burdensome to the technical infrastructure.
--------

Do you agree?
Jeff

__._,_.___

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

__,_._,___