Com o WCF, ou novos standards como WS-Transaction, torna-se muito fácil contextos transaccionais e envolver os serviços nos mesmos. Isso não desafiará alguns tenets ? Nomeadamente a autonomia dos serviços ?

Por outro lado, trabalhar numa base de compensação, parece-me voltar uns 15 anos atrás ao tempo das transacções host....

Independentemente de haver suporte tecnológico, acho que determinadas questões vão continuar a ser resolvidas usando compensação. Imagina o cenário bancário tradicional, com transferência de fundos entre contas. Os exemplos académicos, frequentemente apresentados, fazem o rollback de forma atómica (ACID) em caso de erro. No "mundo real", se isto pode eventualmente acontecer intra-bancos, inter-bancos não acontece certamente, e utiliza-se um modelo de compensação, ao que sei. Uma questão que se pode pôr é a da confiança: tu, do banco X queres mesmo estabelecer uma transacção distribuída com o banco Y, em que vais aceder ao pedido do banco Y para bloquear recursos teus?

Em termos de tenets, no entanto, acho que um serviço transaccional continua a ser autónomo, só que marcado (eventualmente) com policies a indicar que exige um determinado contexto transacional para a sua invocação. Isto faz sentido?

Obrigado pela resposta.

Então mas isso não é um pouco contracensual ? Permitir bloquear recursos meus vs autonomia ??

Uma das regras de SOAs é nunca confiar nos consumidores. (se confio não tenho uma verdadeira SOA). Ora se eu não confio nos utilizadores, como é que posso deixar que eles bloqueiem recursos meus ? :)

Acho que depende do que entendes por autonomia... :-) Seja como for, e apesar de autónomos, os serviços devem ser capazes de cooperar e ser a base de composição/orquestração, e tal como no caso da segurança (WS-Security), acordar em determinadas coisas. Se o cliente do teu serviço satisfizer determinadas condições, tu aceitas estabelecer a transacção, mas eventualmente sem esquecer que com um nível de confiança reduzido, e estando preparado para lidar com falhas no lado do cliente, ou até eventualmente com clientes mal intencionados...

Mas, a terminar, só uma "curiosidade", do blog do Udi Dahan (o "Software Simplist"):

http://udidahan.weblogs.us/archives/034645.html
The tenets of Service Orientation as put forth by Microsoft include one about “autonomy”. The tenet states that “Services should be autonomous”. After some digging, I found out that the intent of the authors was “The teams that develop different services should not be dependent on each other”, or in shortened form “Autonomous Teams”. This revelation was surprising to me since the real meaning of the tenet was less profound than what I had imagined – autonomous computing.

sabes que isto é um bocado para provocar a confusão ;)

Levantas uma outra questão curiosa... serão as definições dos 4 tenets tão curtas que possam causar ambiguidade!?

Eu já me perguntei é se os "four tenets of service orientation", identificados pelo Don Box, não foram uma qualquer brincadeira... conhecendo-o, não me surpreenderia.

De qualquer forma, dois apontamentos:

1º) os 4 tenets foram definidos pela Microsoft, que é a única empresa que os apresenta na forma em que estamos a falar. Veja-se a IBM/Gartner...

2º) voltando à questão da autonomia, o Vasters tem um post interesasnte de 2004 em que fala disto:

(1) Policy-negotiated behavior, (2) Explicitness of Boundaries, (3) Autonomy and (4) Contract/Schema Exchange are the proclaimed tenets of service orientation. As I am getting along with the design for the services infrastructure we're working on, I find that one of the four towers the others in importance and really doesn't really fit well with them: Autonomy.
[...]
Autonomy, on the other hand, is rather independent from the edge of a service. It describes a fundamental approach to architecture. An "autonomous digital entity" is "alive", makes independent decisions, hides its internals, and is in full control of the data it owns. An autonomous digital entity is not fully dependent on stuff happening on its edge or on inbound commands or requests. Instead, an autonomous service may routinely wake up from a self-chosen cryostasis and check whether certain data items that it is taking care of are becoming due for some actions, or it may decide that it is time to switch on the lights and lower the windows blinds to fends off burglars while its owner is on vacation.

Autonomy is actually quite difficult to (teach and) achieve and much more a matter of discipline than a matter of tooling. If you have two "Web services" that sit on top of the very same data store and frequently touch what's supposed to be each others private (data) parts, each of them may very well fulfill the P, E, CE tenets, but they are not autonomous. If you try to scale out and host such a pair or group of Web services in separate locations and on top of separate stores, you end up with a very complicated Siamese-twins-separation surgery.