Já estão disponíveis para download as apresentações da Conferência Architect Insight:

http://www.microsoft.com/uk/msdn/architecture/architectinsight/2007download.mspx

António Cruz

Aqui ficam os links para os resumos que compilei do segundo (e ultimo) dia da Microsoft Architect Insight 2007:

- Conference Architect Insight 2007, Active or Passive Federation for the Enterprise
- Conference Architect Insight 2007, Identity Scale Federation
- Conference Architect Insight 2007, What Do Architects Do, Anyway?
- Conference Architect Insight 2007, Enterprise Architect Group Final Meeting
- Conference Architect Insight 2007, Solution Supply Chains

Antonio Cruz

Caros,

Publiquei os meus resumos do primeiro dia da conferência em epígrafe. Peço desculpa por estar tudo em inglês mas levava muito tempo a traduzir à medida que escrevo.

- Conference Architect Insight 2007, Introduction
- Conference Architect Insight 2007, Enterprise Architect Group First Meeting
- Conference Architect Insight 2007, Where to place your SOA bets?
- Conference Architect Insight 2007, Clinics - The Future of Software Industry
- Conference Architect Insight 2007, Roadmap to Strategic SOA
- Conference Architect Insight 2007, SOA for Support and Maintenance
- Conference Architect Insight 2007, Service Capsules - A Language and Patterns Perspective on Service Design and Implementation
- Conference Architect Insight 2007, SaaS As A Disruptive Technology
- Conference Architect Insight 2007, Enterprise Architect Group Second Meeting

Espero que isto seja interessante para alguém. Ainda falta o segundo dia, por isso amanhã há mais...

António Cruz

Muitas vezes usar SOAP não é a melhor escolha de protocolo para acesso a um serviço. Isto é tanto verdade como dizer que usar REST nem sempre faz sentido, é claro. Tal como reza a máxima: "There's no silver bullets".

O REST popularizou-se ligado a serviços de informação não-sensitiva (que não usem dados pessoais, pagamentos, etc.), comunitários e sem grandes preocupações de automatização do consumo e descoberta. O SOAP, por seu lado, tem ganho notoriedade por oferecer a possibilidade de ser usado no contexto de soluções empresariais que recorrem a segurança, transacções, reliable messaging, queing e federação.

Isto quer dizer que provavelmente vamos continuar a desenvolver serviços aos quais acedemos usando HTTP GET e HTTP POST ainda por muito tempo. O REST é uma manifestação do uso de HTTP GET e POST e foi associado ao AJAX e JSON mas ao contrário do que possa parecer à primeira vista, não se tratam de tecnologias antagónicas, mas sim complementares.

As funcionalidades empresariais enunciadas acima correspondem às 4 grandes vertentes do WCF tal como ele se apresenta na actual versão 1.0. Para a versão 2.0 do WCF, está já previsto o suporte a publish-subscribing e a descoberta de serviços. Neste post, vou dar um exemplo de implementação de REST em WCF. O objectivo é duplo:

1) Que quem se inicia no WCF não desespere por achar que é impossível ou por não conseguir fazer os serviços HTTP GET e POST que já fazia com .ASMX (ou outra tecnologia);

2) Que possa ter a percepção do WCF como a API unificada para o desenvolvimento de serviços (tudo aquilo que se encontrava estava disperso no .ASMX, WSE, Remoting, COM/COM+ e Message Queuing).

Segue-se um exemplo de um contrato que possibilita usar REST:

[ServiceContract]
public interface ICalculator
{
    [OperationContract(Action="*", ReplyAction="*")]
    Message Calculate(Message message);
}

Em primeiro lugar, é digno de nota é que tanto os parâmetros de input como o de output são do tipo Message. Traduzindo isto em linguagem menos "WCF-centric", temos: o método Calculate aceita qualquer tipo de input, o que faz deste parâmetro tão genérico como pode ser em WCF. O mesmo para o retorno: podemos devolver qualquer tipo de mensagem.

A razão disto é que o WCF encapsula automaticamente todo e qualquer pedido num objecto do tipo Message, por isso se dizemos que aceitamos Message e devolvemos Message é o mesmo que dizer "aceito qualquer coisa" e "devolvo qualquer coisa".

Em segundo lugar, note-se que tanto a propriedade Action como a ReplyAction do atributo OperationContract têm o valor "*". O WCF por default, usa SOAP. Isto quer dizer que espera receber um determinado valor num HTTP Header ou num elemento de WS-Addressing chamado "SOAPAction" e "Action", respectivamente. Se não queremos usar SOAP mas sim REST, então não queremos indicar qualquer Action/ReplyTo no momento da invocação, pelo que a equipa do WCF decidiu (e bem) que teria que haver uma forma de suportar mensagens não-SOAP. A forma que convencionaram é esta: o "*" faz com que o runtime não verifique o valor destes parâmetros e deixe a mensagem fluir para o interior da operação sem lançar a excepção: "The message with Action '' cannot be processed at the receiver".

Segue-se um serviço de exemplo de implementação do contrato analisado:

[ServiceBehavior(AddressFilterMode=AddressFilterMode.Any)]
public class Calculator : ICalculator
{
    public Message Calculate(Message message)
    {
        HttpRequestMessageProperty messageProperty =
                message.Properties["httpRequest"] as HttpRequestMessageProperty;

            if (messageProperty != null)
            {
                if (messageProperty.Method.Equals("GET", StringComparison.OrdinalIgnoreCase))
                {
                    string[] segments = OperationContext.Current.IncomingMessageHeaders.To.Segments;

                    if (segments.Length > 2)
                    {
                        string operationName = segments[2].Replace("/", string.Empty).ToLower();

(...)

O serviço usa um ServiceBehavior que tem na propriedade AddressFilterMode o valor AddressFilterMode.Any. Isto quer dizer que não será analisado/validado o url usado para aceder ao endpoint do serviço. Por outras palavras, se podemos enviar qualquer payload *e* podemos usar qualquer tipo de sintaxe no url do serviço, temos o caminho aberto para usar REST com WCF.

Já no interior da operação, uso um HttpRequestMessageProperty para aceder ao pedido HTTP raw por via da propriedade httpRequest deste objecto. Assim, é fácil determinar qual o verbo HTTP que foi usado e agir em conformidade. Posso por exemplo processar os GET (select) de uma maneira e os POST (update) de outra, tal como convencionado em REST. E, é claro, processar qualquer outro verbo aceite pelo servidor da mesma forma (INSERT, APPEND, DEBUG, DELETE, etc.).

Finalmente, acedo a IncomingMessageHeaders para determinar o nome da operação. É interessante analisar os valores tanto de HttpRequestMessageProperty como de IncomingMessageHeaders, por isso sugiro que façam debug a esses objectos e naveguem pela informação que disponibilizam.

Este exemplo deixa claro como é fácil suportar REST em WCF. Considero boa prática suportar diversos protocolos de acesso à mesma funcionalidade, sempre que possível: por exemplo, suportar REST, JSON e SOAP, nesta altura, dá boas garantias de interoperabilidade com mashups de AJAX e deixa a porta aberta para o acesso via proxies de SOAP em C#, Java, PHP, Perl, etc.

António Cruz

[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/antoniocruz]

O contrato WSDL gerado automaticamente pelos serviços desenvolvidos com WCF é regra geral, composto por 4 ficheiros: 2 .wsdl e dois .xsd, cada um deles disponível num url diferente. Uma necessidade que tenho sentido é a de disponibilizar o contrato do serviço em apenas um ficheiro, de modo a ser mais fácil distribuir e arquivar.

Depois de fazer o merge manual destes ficheiros algumas vezes, cheguei à conclusão que faz sentido usar um utilitário que faça a mesma tarefa por mim. O código que se segue não será provavelmente bullet-proof para todo e qualquer .wsdl que contenha referências, mas para os serviços que desenvolvi, funciona lindamente:

using System;
using System.Collections.Generic;
using System.Xml;

namespace MyCompany.ApplicationBlocks.Metadata
{
    public class WsdlMerger
    {
        private static XmlNamespaceManager _namespaceManager = null;

        public static string Merge(string mainWsdlUrlAddress)
        {
            _namespaceManager = new XmlNamespaceManager(new NameTable());
            _namespaceManager.AddNamespace("wsdl", "http://schemas.xmlsoap.org/wsdl/");
            _namespaceManager.AddNamespace("xsd", "http://www.w3.org/2001/XMLSchema");

            XmlDocument wsdl = Load(mainWsdlUrlAddress);
            ResolveReferences(wsdl, wsdl);

            Clean(wsdl);

            return wsdl.OuterXml;
        }

        private static XmlDocument Load(string urlAddress)
        {
            XmlDocument xmlDocument = new XmlDocument();
            xmlDocument.Load(urlAddress);

            return xmlDocument;
        }

        private static void ResolveReferences(XmlDocument mainDocument, XmlDocument currentDocument)
        {
            XmlNodeList wsdlImports = currentDocument.SelectNodes("/wsdl:definitions/wsdl:import", _namespaceManager);

            foreach (XmlNode wsdlImport in wsdlImports)
            {
                string wsdlAddress = wsdlImport.SelectSingleNode("@location").InnerText;

                XmlDocument wsdl = Load(wsdlAddress);
                ImportWsdlNode(mainDocument, wsdl, wsdlImport);
                ResolveReferences(mainDocument, wsdl);
            }

            XmlNodeList xsdImports = currentDocument.SelectNodes("/wsdl:definitions/wsdl:types/xsd:schema/xsd:import", _namespaceManager);

            foreach (XmlNode xsdImport in xsdImports)
            {
                string xsdAddress = xsdImport.SelectSingleNode("@schemaLocation").InnerText;

                XmlDocument xsd = Load(xsdAddress);
                ImportXsdNode(mainDocument, xsd, xsdImport);
                ResolveReferences(mainDocument, xsd);
            }
        }

        private static void ImportWsdlNode(XmlDocument mainDocument, XmlDocument currentWsdlDocument, XmlNode wsdlImport)
        {
            XmlNodeList nodesToImport = currentWsdlDocument.SelectNodes("/wsdl:definitions/*[not(self::wsdl:types) and not(self::wsdl:import)]", _namespaceManager);

            foreach (XmlNode nodeToImport in nodesToImport)
            {
                XmlNode referenceNode = mainDocument.SelectSingleNode("/wsdl:definitions/wsdl:types", _namespaceManager);

                if (referenceNode == null)
                {
                    referenceNode = mainDocument.SelectSingleNode("/wsdl:definitions/wsdl:import", _namespaceManager);
                }

                string wsdlTargetNamespace = mainDocument.SelectSingleNode("/wsdl:definitions/wsdl:import/@namespace", _namespaceManager).Value;

                if (wsdlTargetNamespace != null)
                {
                    XmlNode targetNamespaceAttribute = mainDocument.SelectSingleNode("wsdl:definitions/@targetNamespace", _namespaceManager);

                    if (targetNamespaceAttribute != null)
                    {
                        targetNamespaceAttribute.Value = wsdlTargetNamespace;
                    }
                }

                XmlNode tnsPrefixNamespace = mainDocument.SelectSingleNode("/wsdl:definitions/namespace::tns", _namespaceManager);

                if (tnsPrefixNamespace != null)
                {
                    tnsPrefixNamespace.Value = wsdlTargetNamespace;
                }

                XmlNode importedNode = mainDocument.ImportNode(nodeToImport, true);
                mainDocument.SelectSingleNode("/wsdl:definitions", _namespaceManager).InsertAfter(importedNode, referenceNode);
            }
        }

        private static void ImportXsdNode(XmlDocument mainDocument, XmlDocument currentXsdDocument, XmlNode xsdImport)
        {
            List<string> namespacesToExclude = new List<string>();
            namespacesToExclude.Add("http://schemas.microsoft.com/2003/10/Serialization/");
           
            XmlNode targetNamespace = currentXsdDocument.SelectSingleNode("/xsd:schema/@targetNamespace", _namespaceManager);

            if (targetNamespace != null && !namespacesToExclude.Contains(targetNamespace.Value))
            {
                XmlNodeList nodesToImport = currentXsdDocument.SelectNodes("/xsd:schema", _namespaceManager);

                foreach (XmlNode nodeToImport in nodesToImport)
                {
                    XmlNode importedNode = mainDocument.ImportNode(nodeToImport, true);
                    mainDocument.SelectSingleNode("/wsdl:definitions/wsdl:types", _namespaceManager).PrependChild(importedNode);
                }
            }
        }

        private static void Clean(XmlDocument wsdl)
        {
            XmlNode wsdlImportNode = wsdl.SelectSingleNode("/wsdl:definitions/wsdl:import", _namespaceManager);

            if (wsdlImportNode != null)
            {
                wsdl.SelectSingleNode("/wsdl:definitions", _namespaceManager).RemoveChild(wsdlImportNode);
            }
        }
    }
}

Aqui está um exemplo de consumo:

using System;
using System.IO;

using MyCompany.ApplicationBlocks.Metadata;

namespace WSDLMerger
{
    class Program
    {
        static void Main()
        {
            string fullWsdl = WsdlMerger.Merge("http://mycompany/myservice.svc?wsdl");
            File.WriteAllText(@"C:\FullWSDL.wsdl", fullWsdl);
        }
    }
}

Podem facilmente ver que o código é susceptível de várias melhorias. A ideia foi disponibilizá-lo a quem possa ser útil desde já.

António Cruz

[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/antoniocruz]

Enquanto programador, acabei por reunir um conjunto de utilitários e práticas que me permitem maior eficácia no desempenho das minhas tarefas de desenvolvimento, debugging e monitorização de serviços. Neste post vou identificar o conjunto de programas que tenho usado, bem como descrever aquela que penso ser a sua utilidade, de acordo com os objectivos que referi.

1) Svcutil.exe - não uso o Add Service Reference. Se apenas quero gerar um proxy para o serviço, dispenso a verborreia que obtenho quando uso o output.config gerado e dispenso a criação da pasta respectiva na solução. Na maioria dos casos, na configuração só preciso dos elementos ABC (address, binding e contract) e um ou outro parâmetro de tuning, como por exemplo o "maxReceivedMessageSize". Na verdade, considero uma boa prática *não* usar o Add Service Reference. Dito isto, às vezes dá jeito usar a feature como "truque" para obter automaticamente a lista de todos os parâmetros e respectivos valores por default, que por sua vez nem sempre são fáceis de identificar na documentação.

2) Microsoft Fiddler - Para simular clientes POX/REST usando o basicHttpBinding, esta ferramenta serve lindamente. É fácil manipular os headers e o body da mensagem enviada, descompacta a stream da resposta quando esta vem gzipped e mostra a comunicação em raw, isto é, sem formatação, o que às vezes também dá jeito, principalmente para detectar problemas no encoding da stream da resposta.

 3) tcpTrace - Há muitos sniffers de rede (por exemplo, o Ethereal é muito bom), mas esta aplicação serve bem quando só quero mesmo fazer um pedido com alteração mínima da configuração (só mudo o endpoint para ser aquele em que escuta o tcpTrace). Podia usar o SvcConfigEditor.exe e alterar o .config para obter a mesma informação em ficheiros, mas geralmente sou mais rápido a i) alterar o endpoint, ii) lançar o tcpTrace e iii) monitorizar *live* a comunicação.

 4) SoapUI - Entre outras, esta aplicação tem uma funcionalidade que aprecio bastante: dou-lhe um endpoint ou um ficheiro que contenha um WSDL e obtenho a listagem de operações e o respectivo conjunto de sample SOAP requests que posso imediatamente usar para provocar um pedido ao serviço fazendo "Play".

[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/antoniocruz]

Por eventualmente ser de interesse para quem pretende iniciar o estudo do WCF, resolvi fazer este post. A ideia é identificar quais são os requisitos desejáveis para serem WCF starters e, de seguida, apresentar alguns recursos que considero de qualidade para quem deseja aprofundar conhecimentos na matéria:

Requisitos:

- Programação em .NET, especialmente componentes, usando interfaces, atributos, genéricos, threading, herança e transacções.
- Bons conhecimentos de arquitecturas distribuídas, em especial usando web services e/ou remoting e queuing, WSE e/ou .ASMX, COM e/ou DCOM.
- Conhecimentos dos core standards usados em web services: REST, JSON, XML, XML Namespaces, XML Schemas, WSDL, WS-Addressing.
- Conhecimentos funcionais de standards WS-*, particularmente WS-Security, WS-Reliable Messaging, WS-Transactions e WS-Trust.
- Compreensão de conceitos ligados a SOA: Orientação a Serviços, Messaging, Concorrência, Transacções Distribuídas, P2P, Federação, Single Sign-On.
- Familiaridade com design patterns como proxy, broker, publish-subscriber, data transfer object, adapter, façade e singleton.
- Muita vontade de aprender a usar a software factory template para desenvolvimento de serviços mais avançada que existe.

Recursos:

- Windows Communication Foundation Hands-On, Craig McMurtry, SAMS, 0672328771. Este livro é bastante acessível para quem começar a ler os primeiros textos sobre WCF. Não sendo exaustivo em nenhum tópico, apresenta o mérito de incluir um pouco de informação sobre cada tema relacionado com esta tecnologia, diversidade esta que nem sempre encontrei em outras fontes: P2P, CardSpace, Federação, REST, Custom Behaviors, Custom Transports, etc.
- Programming WCF Services, Juval Löwy, O'Reilly Media, 0596526997. Ainda só disponível em "Rough Cuts" na O'Reilly, este é provavelmente o melhor livro disponível até à data. Bastante orientado a aspectos práticos e com muitos exemplos de código reutilizável em projecto. A não perder: todos os exemplos de código disponível no site IDesign.net. Não comecem a desenvolver/testar uma nova funcionalidade a partir do zero, i. é, sem procurar se existe já um exemplo feito. Usando um exemplo como template temos acesso a um excelente ramp-up.
- Windows SDK. Disponibilidade obrigatória como Programmer's Reference no dia-a-dia.
- http://wcf.netfx3.com/. Site da comunidade de WCF. Aqui temos acesso a apresentações, artigos, vídeos, webcasts, podcasts, exemplos de código e até acesso a fazer um Hands-On Labs on-line. Aqui, sugiro começarem por ler os whitepapers referidos e depois ver alguns videos, por exemplo.
- WCF Forum. Este é o forum a ter em conta sobre WCF. Seguido atentamente por elementos da equipa de desenvolvimento, é fácil colocar uma dúvida que seja respondida rapidamente.
- Finalmente, o recurso mais importante: nós próprios! Não há *nada* que substitua a experimentação sucessiva e metódica das features e o passar por problemas em projecto participando na sua resolução. Isto quer dizer que devem tentar equilibrar o que vão lendo e ouvindo, com o que vão fazendo.

Com isto, espero ter ajudado alguém a iniciar-se no tema. Comentários, dúvidas e/ou sugestões, just say it.

[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/antoniocruz]

Hmm, isto promete:

http://projects.nikhilk.net/Projects/ScriptSharp.aspx

Recentemente necessitei de uma forma de gerar um XML Schema a partir de um ficheiro de XML. A ideia é poupar as pessoas de terem que fazer os XML Schemas desde o início, principalmente quado já têm um XML de exemplo e agora só necessitam de gerar o Schema correspondente. É de facto mais fácil e rápido começar por um XML Schema gerado a partir do XML, servindo como base e dessa forma só teremos que o alterar com o que pretendemos.

Em .NET, há várias ferramentas que fazem essa tarefa, incluindo o próprio Visual Studio, o utilitário XSD.exe que vem no SDK de .NET ou até no site gotdotnet.com também existe disponível para download uma aplicação de consola chamada Microsoft XSD Inference 1.0.

No entanto, o que necessitava era uma forma de disponibilizar esta funcionalidade a qualquer pessoa, em qualquer plataforma (Linux/Perl, Windows/Java, etc), e de preferência, usando uma aplicação browser-based, de modo a não ser necessário instalar qualquer aplicação, runtime, etc.

Usando a nova classe XmlSchemaInference da versão 2.0 do .NET Framework, foi fácil implementar a dita aplicação.

Para quem estiver interessado, aqui fica o source do .aspx e do respectivo code-behind:

using System;
using System.IO;
using System.Text;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.HtmlControls;
using System.Xml;
using System.Xml.Schema;

public partial class XML2XSD : Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
         if (XML.Text.Length > 0)
        {
             using (MemoryStream inputStream = new MemoryStream(Encoding.UTF8.GetBytes(XML.Text)))
            {
                 using (XmlReader xmlReader = XmlReader.Create(inputStream))
                {
                     XmlSchemaInference xsdi = new XmlSchemaInference();
                     XmlSchemaSet schemaSet = xsdi.InferSchema(xmlReader);

                     XSDContent.Controls.Clear();
                     HtmlGenericControl textArea = null;

                     foreach (XmlSchema schema in schemaSet.Schemas())
                    {
                         using (MemoryStream outputStream = new MemoryStream())
                         {
                              using (XmlTextWriter xmlWriter = new XmlTextWriter(outputStream, Encoding.UTF8))
                              {
                                   xmlWriter.Formatting = Formatting.Indented;
                                   schema.Write(xmlWriter);
                                   outputStream.Position = 0;

                                   using (StreamReader streamReader = new StreamReader(outputStream, true))
                                   {
                                        textArea = new HtmlGenericControl("textarea");
                                        textArea.Attributes.Add("rows", "20");
                                        textArea.Attributes.Add("cols", "80");
                                        textArea.InnerText = streamReader.ReadToEnd();
                                        XSDContent.Controls.Add(textArea);

                                        streamReader.Close();
                                   }

                                   xmlWriter.Close();
                               }

                               outputStream.Close();
                           }
                       }

                       xmlReader.Close();
                   }

                   inputStream.Close();
               }
           }
      }
}

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]

Tenho feito alguns testes com JSON e brevemente espero usá-lo em produção. O JSON tem vindo a ganhar notoriedade e mesmo o ATLAS usa internamente um JSON Serializer. 

Há algum tempo subscrevi o grupo de JSON do Yahoo e tenho acompanhado uma discussão interessante sobre a possibilidade (necessidade?) de estender o JSON para suportar a identificação de vários tipos de dados primitivos noutras linguagens, como por exemplo o DateTime e até de alguns tipos de dados complexos, como o DataSet.

Para possibilitar essas features, há até quem proponha usar "tags" no JSON (!) e fazer um Schema que permita validar JSON. E apesar de solicitado, o Douglas Crockford não se pronunciou sobre estas questões. Quer dizer, pelo menos até este fim-de-semana, em que fez um post (ao que me pareceu deliberadamente lacónico), em que simplesmente anuncia ao newsgroup que o RFC do JSON foi publicado.