Na visão da Microsoft/Don Box, a orientação a serviços pode definir-se por 4 tenets:
- Boundaries are explicit
- Services are autonomous
- Services share schema and contract, not class
- Compability is based upon policy
O primeiro deste tenet, “Boundaries are explicit”, foi descrito por Rich Turner como “Services are expressed at their boundary and there is only ONE way to access the information and/or functionality held within a service – through capabilities exposed at the Service Boundary. Also, assume that calling methods on a Service may take time and may be unreliable.”, e pelo próprio Don Box como “Services interact through explicit message-passing behind the boundaries. We make no assumptions on the space behind the service boundaries. Crossing service boundaries can be costly (for example, you may need to span geography, trust boundaries, or execution environments). We explicitly opt in to service invocation, by formally passing defined messages between services. The explicit boundaries allow us to formally express implementation independent interaction—we can be agnostic to choices of platform, middleware, or coding language used to implement other services.” (ver também este artigo, já agora)
Este post, e o foco no 1º tenet (e não só, para falar estritamente verdade), surge a propósito de um artigo que li chamado “A Note On Distributed Computing“. Escrito por uns rapazes da Sun em 1994, este artigo tenta demonstrar porque é que se deve lidar com objectos remotos de forma diferente da forma como se lida com objectos locais (i.e., num mesmo espaço de endereçamento). É como que uma defesa do 1º tenet, interessante, actual e rápida de ler, e tem tudo a ver com web services.
Logo a abrir, “In such systems, an object, whether local or remote, is defined in terms of a set of interfaces declared in an interface definition language. The implementation of the object is independent of the interface and hidden from other objects.” (can you spell w-s-d-l?)
No artigo identificam-se alguns motivos pelos quais se devem tratar invocações remotas de forma distinta de invocações locais:
- Latência: os tempos de espera em invocações remotas são a diferença mais óbvia entre os tipos de acesso (o artigo sugere algo similar a uma optimização que aproxime os objectos usados mais frequentemente, no SOA tende-se para uma visão em que a funcionalidade oferecida por cada serviço é mais rica);
- Acesso à memória: esta diferença prende-se especificamente a acesso à memória usando apontadores ou referências. Referem-se duas alternativas: ou todos os acessos à memória devem ser gerido pelo sistema, ou o programador deve estar consciente das diferenças entre acesso a memória local e remota;
- Falha parcial e concorrência: a principal classe de diferenças entre os dois modelos, refere-se por exemplo a situações em que o servidor falhe inesperadamente, e ao facto de “In a distributed system, the failure of a network link is indistinguishable from the failure of a processor on the other side of that link”. Há muito a dizer sobre este ponto, o artigo fá-lo melhor do que eu.
E quase a concluir: “A better approach is to accept that there are irreconcilable differences between local and distributed computing, and to be conscious of those differences at all stages of the design and implementation of distributed applications. […] While writing code, engineers will have to know whether they are sending messages to local or remote objects, and access those objects differently. While this might seem to add to the programming difficulty, it will in fact aid the programmer by providing a framework under which he or she can learn what to expect from the different kinds of calls.”
Com as devidas adaptações, e talvez lendo “serviços” onde o artigo usa geralmente “objectos [remotos]”, o artigo surpreendeu-me pela sua actualidade, e recomendo-o vivamente a quem desenvolva web services hoje, com ou sem o chapéu do SOA.
jota
Ps: isto não é um post “pró-Sun”, mas sim de surpresa por uma bela pérola encontrada ao acaso 🙂
