Há já algum tempo que penso nas implicações do uso das técnicas denominadas de AJAX nas arquitecturas service-oriented. Neste post, vou partilhar alguma da experiência conseguida entretanto.
Cenário: Necessitamos de pesquisar a base de dados de uma aplicação já em produção de forma a apresentarmos a informação com HTML, num browser. A aplicação apenas disponibiliza feeds de RSS, permitindo pesquisar a base de dados e paginar os resultados mediante parâmetros em querystring. Não é viável proceder a alterações na aplicação pelo que se prefere uma solução que não implique fazer alterações ao código existente.
Solução:
a) Usar o HTML DOM para navegar o XML do RSS e ir construindo dinamicamente os elementos e atributos de HTML de que necessitamos para apresentar a informação. Apesar de dar bastante trabalho, esta abordagem tem a vantagem de ser cross-browser e não possuir dependências externas;
b) Usar XSLT em client-side (fazendo transformações no browser). Recorrendo a uma livraria como a Sarissa, será fácil transformar em HTML os RSS devolvidos pelo servidor. Também é possível usar o XSL para transformarmos o RSS em JSON (e a partir daí construír a apresentação). Este .xsl faz uma transformação genérica de XML para JSON, embora eu tenha detectado problemas com atributos e aparentemente as secções de CDATA não são suportadas;
c) Usar um broker, isto é, uma aplicação server-side que receba os pedidos que se destinam à aplicação de RSS e faça forward destes para essa aplicação. Porque todos os pedidos (e respectivas respostas) passam pelo broker, é fácil proceder à transformação das respostas em HTML (ou outro formato).
Na minha opinião, a melhor hipótese é a c). Aqui ficam as razões da escolha:
- O uso do padrão de brokering é pelo menos bastante recomendado (pessoalmente, acho obrigatório) em arquitecturas service-oriented. O decoupling decorrente da "intercepção" dos pedidos é só por si, razão suficiente para justificar a sua adopção, mas muitas outras vantagens são obtidas a partir da sua implementação.
- Embora não comparável ao leque de serviços oferecido por um ESB, um broker simples traz a vantagem de que tanto os clientes como os serviços não têm de se preocupar com os formatos dos respectivos pedidos e respostas: o problema das traduções pode sempre ficar a cargo do broker (v. o resto da solução).
Assumindo que optámos pelo broker, enuncio mais algumas hipóteses:
a) Usar um elemento de <script> estático que incluímos na página, cuja propriedade src aponta para o broker. O broker pode fazer a transformação do RSS para JSON usando qualquer linguagem em server-side (não precisa de ser XSLT, pode ser C#, Java, PHP, etc.). Para um exemplo de código que produz JSON a partir de XML usando C#, podem ver aqui. O único problema que até agora encontrei neste código foi o facto de (também) não suportar CDATA. Mas foi simples fazer uma alteração para suportar esse elemento e neste momento tenho uma versão que suporta CDATA, atributos, arrays, etc. (se alguém estiver interessado nesta versão basta fazer um post).
b) Usar o objecto HTTPRequest para fazer o pedido, embora neste caso ficamos sujeitos às restrições de pedidos cross-domain (a propósito, acho que devia chamar-se cross-server, porque não basta estarmos no mesmo domínio para funcionar). Uma solução para isto (mais uma vez) usar um broker no mesmo servidor da aplicação. Esta abordagem tem apenas o problema de termos que ter um broker a fazer de reverse proxy em cada uma das aplicações que pretendemos consumir (caso fossem várias);
c) Usar um elemento <script>, tal como descrito em a), mas criado dinamicamente, usando o HTML DOM. Para um exemplo da criação dinâmica, podem consultar este artigo. De notar que também neste caso é um pressuposto que o JSON seja criado no servidor;
d) Para os casos em que hajam muitos pedidos concorrentes ao servidor, o facto de serem feitas transformações de XML para JSON pode revelar-se problemático, devido ao overhead introduzido pelas transformações. Neste caso, sugiro usarem a abordagem descrita em c) para devolverem apenas o RSS encapsulado numa propriedade de um objecto de JSON e proceder à sua transformação para JSON, mas no cliente. Vamos ganhar com isto que a carga das transformações de XML para JSON são distribuídas por cada cliente, ficando o broker com a carga mínima de criar uma string que apenas contém o RSS pretendido. Para uma implementação de conversões entre XML e JSON usando JavaScript, podem ver aqui.
Face ao exposto, considerem que em alguns casos, não faz grande sentido desenvolvermos XML Web Services que sejam compatíveis com o Basic Profile 1.1 da WS-I, etc. Se a complexidade de o fazer é superior ao benefício alcançado, então a melhor opção pode encontrar-se num mero... RSS (no entanto, a opção de usar JSON em vez de XML também traz várias condicionantes conhecidas como ausência de schema que permita a validação das mensagens, ausência de contrato automatizável como o WSDL, etc.).
Penso que a abordagem descrita em d) condensa a melhor abordagem possível em termos da arquitectura Web 2.0 num cenário SOA, conforme o que ficou descrito. Também penso ter demonstrado o interesse (e actualidade) de pensarmos em que termos a Web 2.0 condiciona/potencia as arquitecturas service-oriented e a arquitectura de software de um modo geral.
[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/antoniocruz]