Consumindo RESTful WebServices em C# com WCF e JSON (parte 1/2)

Introdução

Faz realmente muito tempo que não escrevo um artigo sobre desenvolvimento de sistemas mais técnico. Quem me conhece, sabe do meu passado bem próximo de linguagens como Pascal, Delphi, Java e C#. Já escrevi muitos artigos quando trabalhava na Borland, e alguns deles sobre WebServices. WebServices, lembram? Aquela tecnologia super moderna que permite a publicação e consumo de serviços e metadados (WSDL) via Web trafegando pacotes em XML? Pois é… super moderno não?

Na verdade, não. Apesar de se ainda suportar WebServices SOAP por aí, a tendência da Web 2.0 é a de se manter as coisas o mais simples e fáceis possíveis (KISS, entende?). Além disso, com o advento do AJAX e do browser como a plataforma cliente preferida da Web 2.0, o consumo de XMLs passou a ser uma coisa um pouco, por assim dizer, pesada para ser feita em AJAX, que normalmente faz uso de JavaScript.

Este conjunto de novos requisitos tecnológicos fez surgir dois novos “animais” magrinhos para a implementação de serviços via web, que estão rapidamente suplantando os WebServices SOAP convencionais (e gordinhos):

  • WebServices RESTful (versus SOAP-based)
  • JSON (versus XML)

Este é o primeiro de dois artigos que exploram as capacidades do WCF para comunicação com RESTFul WebServices e JSON.

WebServices RESTful

O protocolo SOAP é extremamente rico e cheio de funcionalidades. Via SOAP você consegue descrever objetos e mensagens de forma fortemente tipada, utilizando XML. Contudo, a infraestrutura para suporte a WebServices SOAP é bem pesada e, como já citei, pouco aderente a clientes “leves” como JavaScript rodando em um browser.

Com o objetivo de tornar a invocação de métodos remotos e de troca de dados um processo mais leve, surgiu o conceito de WebServices RESTful. Estes WebServices não seguem um protocolo complexo como o SOAP, mas devem seguir as características REST definidas por Roy T. Fielding. Basicamente, WebServices RESTFul são stateless e acessados a partir de operações HTTP padrão (GET, POST, PUT, DELETE) e retornam qualquer conteúdo (normalmente XML, JSON ou outro mime type).

Outra característica interessante desse tipo de WebServices é a de que a infraestrutura existente de servidores web pode ser utilizada, sem a necessidade de se incluir application servers, gateways, proxies, etc. (contudo, não há proibição de usá-los). O melhor é que servidores web existentes (Apache, IIS, etc.) suportam caching, autenticação, criptografia, etc.  sem grande necessidade de programação ou configuração, o que aumenta a performance e diminui a necessidade de recursos dos serviços.

JSON

Como uma alternativa ao XML, Douglas Crockford criou o JSON, que se tornou um RFC oficial (RFC 4627). A sua sintaxe é bem mais leve que o XML e é facilmente “parseavel” por qualquer linguagem de desenvolvimento. Baseia-se em um subset do JavaScript. Segue um exemplo de um bloco JSON:

  1: {"menu": {
  2:   "id": "file",
  3:   "value": "File",
  4:   "popup": {
  5:     "menuitem": [
  6:       {"value": "New", "onclick": "CreateNewDoc()"},
  7:       {"value": "Open", "onclick": "OpenDoc()"},
  8:       {"value": "Close", "onclick": "CloseDoc()"}
  9:     ]
 10:   }
 11: }}

WCF – Acessando a API do Twitter


Como exemplo de uso de WebServices RESTful com JSON, vou utilizar a api do Twitter, mais especificamente a chamada “statuses/public_timeline”.


Para começar, em seu Visual Studio 2008 ou Visual C# 2008 Express, crie um projeto Console.


Adicione referências aos assemblies abaixo:



  • System.ServiceModel.dll
  • System.ServiceModel.Web.dll

Ótimo! Estamos prontos para definir o contrato de dados


Definido o contrato de dados


Vamos utilizar o atributo DataContract para definir nosso “contrato de dados” com o serviço “statuses/public_timeline” em uma nova classe assim:

  1: using System;
  2: using System.Collections.Generic;
  3: using System.Linq;
  4: using System.Text;
  5: using System.ServiceModel;
  6: using System.Runtime.Serialization;
  7: 
  8: namespace TwitterClientPlayground
  9: {
 10:     [DataContract]
 11:     public class Status
 12:     {
 13:         [DataMember(Name = "text")]
 14:         public string text {get; set;}
 15: 
 16:         [DataContract]
 17:         public class User
 18:         {
 19:             [DataMember(Name = "screen_name")]
 20:             public string screenName {get; set;}
 21:         }
 22:         [DataMember (Name="user")]
 23:         public User user { get; set; }
 24: 
 25: 
 26:     }
 27: }

Você pode ver acima que a classe é uma classe C# como qualquer outra, com anotações em seus membros. A anotação “DataContract” define que a classe deve ser utilizada como contrato de dados pelo WCF. “DataMember” define membros do contrato de dados.


Uma questão interessante é que quando estamos utilizando uma “nested class”, esta também precisa ser marcada com “DataContract” (ver a classe “User” acima).


Definindo o contrato de serviço


O contrato de serviços é equivalente a um “stub” SOAP criado pelo “Add Web Reference” do IDE. Segue o nosso exemplo abaixo:

  1: using System;
  2: using System.Collections.Generic;
  3: using System.Linq;
  4: using System.Text;
  5: using System.ServiceModel;
  6: using System.ServiceModel.Web;
  7: 
  8: namespace TwitterClientPlayground
  9: {
 10:     [ServiceContract]
 11:     public interface ITwitterClient
 12:     {
 13:         [OperationContract]
 14:         [WebGet(
 15:             ResponseFormat = WebMessageFormat.Json,
 16:             UriTemplate="statuses/public_timeline.json"
 17:             )]
 18:         List<Status> Statuses_PublicTimeLine();
 19:     }
 20: }

O atributo “ServiceContract” define uma interface que irá ser utilizada pelo WCF como contrato de serviços entre o cliente e o servidor. “OperationContract” define uma operação e “WebGet” indica que a operação (método) será equivalente a uma chamada HTTP GET e permite que configuremos detalhes como o formato da resposta em ResponseFormat(no caso, JSON) e o fragmento da URI para acesso ao serviço em UriTemplate. A UriTemplate suporta parâmetros (entre chaves {}), que devem ter o mesmo nome do parâmetro do método sendo anotado, quando a operação do serviço assim o requerer. No caso, “statuses/public_timeline” não aceita parâmetros.


Conclusão


Por enquanto, neste artigo, procurei explicar os conceitos de WebServices RESTful e JSON, bem como a definição de contratos WCF para o consumo deste tipo de WebServices. No próximo artigo, iremos finalmente utilizar os contratos aqui definidos para efetuarmos chamadas ao WebService do Twitter.


Até lá!

Metodologias Ágeis: Outsourcing

No meu artigo anterior sobe SCRUM, comentei sobre um assunto polêmico: o uso de ferramentas para gerenciar projetos ágeis. Agora… mais pano para a manga: outsourcing e metodologias ágeis, vamos lá: Se você for ler o Manifesto Ágil e seus princípios, você acabará esbarrando na seguinte afirmação:

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Hmmm… quer dizer então que processos e metodologias ágeis só fazem sentido quando a equipe de desenvolvimento e os donos do produto estão localizadas em um mesmo andar ou prédio? O termo chave aqui é o “face-to-face”. (muitos se referem este tipos de time como “tight matrix” ou “collocated”).

Quando estamos fisicamente presentes em um mesmo ambiente, temos a possibilidade de nos comunicar não verbalmente. Quando o componente não verbal está ausente, perdemos grande parte do conteúdo da mensagem¹. Portanto, realmente, o valor do “face to face” é indiscutível. Além disso, manter o trabalho em equipe quando o time precisa se comunicar virtualmente é bem mais trabalhoso, pois a socialização, o “cafezinho” para relaxar em conjunto, por exemplo, não existe.

Contudo, vivemos momentos conturbados. Muitas decisões são tomadas sob um aspecto inerentemente financeiro. Tudo o que é financeiro é mensurável e é aí que a defesa do “face to face” fica complicada. Como combater o ROI do outsourcing?

A favor do outsourcing, vivemos em um mundo extremamente conectado, um mundo de Instant Messengers, twitter, blogs, VOIP, web cams… A associação disso tudo a ferramentas colaborativas de gerência de projetos permite que nos aproximemos bastante da experiência face a face.

Outra possibilidade, que permite às empresas usufruir das vantagens financeiras do Outsourcing e favorece o trabalho em equipe, é a do Outsourcing in-house, que permite a interação direta com a equipe outsourced, pois esta trabalha em um ambiente fisicamente próximo a do cliente.

Para concluir: O outsourcing de desenvolvimento de software é um fato e está muito presente nos dias de hoje, mas, como vimos nesta discussão, não há necessidade de se descartar as metodologias ágeis. De fato, as vantagens da agilidade continuam relevantes.

---

¹ Christopher K. Hsee, Elaine Hatfield & Claude Chemtob (1992): Assessments of the emotional states of others: Conscious judgments versus emotional contagion. Journal of social and clinical psychology 14 (2): 119-128. e
Mehrabian, Albert & Susan R. Ferris (1967): Inference of attitudes from nonverbal communication in two channels. Journal of consulting psychology 31 (3): 248-252.

SCRUM: Ferramentas

Essa é uma discussão que, tenho certeza, dá muito pano pra manga.

Os puristas vão dizer: ferramentas para gerenciar o processo ou projeto não importam. São um overhead que afeta a agilidade. O que importa é seguir o processo. E em processos ágeis somente precisamos de:

  1. Blocos de Post-it®;
  2. Um whiteboard (quadro branco/lousa);
  3. Marcadores
  4. Uma sala dedicada para os Scrum Meetings, Sprint Planning Sessions e Retrospectives e Reviews
  5. Um wiki (no máximo)

Outros dirão: ferramentas importam sim. Não podemos nos dar ao luxo de termos uma sala dedicada com um enorme whiteboard lotado de post-its e anotações diversas. Salas de reunião são compartilhadas e não podemos perder os dados dos backlogs do sprint e do produto. Além disso, poder navegar em uma ferramenta para acessar resultados de sprints anteriores ajuda muito no planejamento de sprints futuros com lições aprendidas, estimativas de tamanho dos stories, etc.

Bem. confesso que a minha escolha natural está no grupo dos Outros. Acredito em manter a “memória corporativa” para melhorarmos iterativamente as nossas entregas de projeto. Meu background em processos e desenvolvimento de software me faz acreditar que ferramentas corretamente implementadas aumentam a produtividade de equipes. (a boa e velha tríade “People, Processes and Technology”)

E – aqui entre nós – tenho certeza que na próxima reunião na mesma sala, o quadro branco será apagado pela outra equipe.  Mesmo que alguém coloque um recado de “não apagar” gigante.

Que ferramenta eu gosto de usar? Neste momento estou usando o Banana Scrum, uma ferramenta gratuita da CodeSprinters disponibilizada em um ambiente on-line, modelo SaaS (Software as a Service), e sinto-me bastante satisfeito. Outras opções:

Outsourcing de TI – O que faz sentido?

Esse é um assunto bem quente. Não porque seja uma grande novidade ou algo assim, mas principalmente por ser polêmico.

A onda Outsourcing é parecida com o do downsizing, da reengenharia e de muitas “reestruturações” de empresas: ir a extremos para “cortar custos”. Empresas mais maduras já entendem que muitas vezes o custo total (do retrabalho, falha nas entregas, etc.) é muito maior quando a decisão de fazer outsourcing é tomada sem critério.

Dito isto, não acredito que exista uma resposta simples para a pergunta do título deste artigo. Contudo, acredito, sim, que uma regra simples deve ser utilizada no processo de tomada de decisão.

O serviço sendo considerado para ser outsourced é “core” ou estratégico para o negócio da minha companhia?

[   ] Sim – A princípio, outsourcing não deve ser considerado.

[   ] Não – Outsourcing é provavelmente uma boa opção.

A regra é simples, mas responder a pergunta do que é “core” ou estratégico muitas vezes nos faz enveredar por um caminho bem mais tortuoso do que incialmente imaginamos.

Especialmente porque o CIO ou gestor de TI de uma companhia vai precisar discutir esse assunto com outros stakeholders (por exemplo, diretores de outra áreas). A decisão ideal é o resultado de uma visão compartilhada dos participantes da discussão. Não vou me enveredar agora em questões relacionadas a planejamento estratégico, tais como Análise SWOT, Missão e Visão, Balanced Scorecard, etc. Sugiro, somente, que algum método estruturado para se chegar a uma conclusão compartilhada seja utilizado. Do contrário a discussão pode ser demorada e dolorosa.

Uma vez que os objetivos estratégicos de mercado, financeiros, processuais, etc. da companhia estão esclarecidos, temos uma veredito sobre outsourcing, correto? A princípio, sim.

Contudo, se mesmo assim por questões, por exemplo, de custo, a decisão for a de se efetuar o outsourcing do serviço em questão, aqui vão algumas considerações:

Conceito Básico Desejável
Seleção de fornecedores Analise cuidadosamente os fornecedores sob todos os aspectos. O custo é importante, mas a capacidade de entrega é primariamente o que deve ser analisado. Uma vez que o serviço é estratégico ou “core”, um processo formal e detalhado de análise de potenciais fornecedores deve ser utilizado, tal como RFIs e RFPs Se possível e se o tempo estiver a seu favor, uma prova de conceito é extremamente desejável. Normalmente os fornecedores que “confiam no seu taco” não se opõem a POCs. Outra modalidade de avaliação detalhada é o “try and buy”. Contudo cuidado: muitas vezes o “try” faz com que você, essencialmente, tenha se tornado dependente do fornecedor e não tenha muita escolha senão partir para o “buy”.
Visibilidade Utilize como um dos critério primordiais no processo de definição do fornecedor a visibilidade que este o dará durante a execução do serviço. Como em sua maioria das vezes o serviço será executado fora da empresa cliente, a possibilidade de se visualizar o estágio, estado e passos intermediários do serviço é essencial para que você não receba “presentes de grego” nas entregas do fornecedor. Se possível e cabível, faça uso do “in house outsourcing”: use serviços outsourced dentro da estrutura da sua própria empresa para poder acompanhar o andamento do serviço ou projeto de perto.
Qualidade Questões de controle e garantia de qualidade tornam-se ainda mais delicadas… portanto tente associar remuneração a entregas com “aceite formal” Implemente cláusulas contratuais que penalizem monetariamente o fornecedor no caso de erro ou quebra de SLA (o que faz mais sentido em serviços de operação de sistemas financeiros tais como folha de pagamento, contabilidade etc.)
Gerente local O papel do gestor ou gerente do projeto/serviço também deve ser desempenhado por alguém com as competências adequadas da empresa cliente, e não somente por um representante do fornecedor. Desta forma temos um “pai para a criança” e “blindamos”  ainda mais a qualidade das entregas. Apesar da gestão ser compartilhada entre cliente/fornecedor, a responsabilidade final é a do cliente. Para o fornecedor, um resultado negativo pode significar a perda de um cliente. Para o cliente, a perda de uma oportunidade que pode ser, no limite, “time sensitive” e com impacto relevante em seu negócio.

Não há regra geral, mas existem alguns serviços de TI que são comumente considerados como commodities e, portanto, são candidatos a serem outsourced:

  • Data centers;
  • Colocation/hosting;
  • Suporte a infra-estrutura de rede e servidores;
  • Backups/restores;
  • Email, Calendário, Contatos;
  • etc.

Serviços que ficam geralmente em uma “área cinza” que dependem de uma análise mais detalhada como a citada neste artigo:

  • Desenvolvimento de Software;
  • Administração dos servidores ;
  • Business Intelligence (desenvolvimento);
  • Software-as-a-service (CRM, Folha de Pagamento, Recrutamento/RH, etc.)

Alguns serviços que pessoalmente não recomendo serem outsourced:

  • Gerência de Projetos;
  • Gerência de Requisitos;
  • Planejamento Estratégico de TI (apoio consultivo, OK);
  • Gerência de operações de TI;
  • Gerência SOX TI;
  • etc.

Mesmo a lista acima pode variar bastante, dependendo de cada caso. Portanto, analise bem e pense: por que fazer Outsourcing quando se pode fazer “Rightsourcing”?

Cheers!

Metodologias Ágeis - SCRUM

Existem muitas abordagens ágeis disponíveis no ecossistema de processos e metodologias de projetos de software. Entretanto, dentre todas, sinto-me mais confortável – no momento – com o SCRUM.

Uma das maiores vantagens do SCRUM é a sua capacidade de ser genérico o bastante sem perder a praticidade e aplicabilidade no dia-a-dia. Uma vez que tenhamos começado a estudar o processo, gasta-se pouco mais que um par de dias para se começar a aplicar seus conceitos, que são bastante diretos.

Seus princípios são tão universais que é possível se utilizar o SCRUM combinado com outros processos (ex.: FDD ou XP) ou ainda para projetos em áreas que nada tenham a ver com desenvolvimento de sistemas, tais como material de treinamento, marketing, etc. Alguns dos princípios:

  • Sprint: Iteração de 2-4 semanas de um projeto SCRUM. O tamanho do sprint escolhido deve ser mantido durante todo o projeto. O escopo de um sprint iniciado não pode ser.
  • Papéis:
    • Scrum Master: Facilitador do processo e projeto (o equivalente a um Project Manager)
    • Product Owner: Representante do cliente do projeto
    • Equipe: Responsáveis pela implementação, testes e documentação do projeto
  • Cerimônia:
    • Planning Session: Sessão de priorização e detalhmento do escopo de um sprint.
    • Daily Scrum: também conhecido com “stand up meeting”. Reunião diária, de 15 minutos de acompanhamento do projeto. Perguntas:
      • O que você fez ontem?
      • O que você fará hoje?
      • Algum obstáculo?
    • Sprint Review: Tipicamente uma demonstração dos resultados obtidos em um sprint. Todos podem participar (mesmo quem não participa do projeto)
    • Sprint Retrospective: Sessão rápida (15-30 minutos) para compartilhamento de “lições aprendidas”
  • Artefatos:
    • Product backlog: conjunto de requisitos ou funcionalidades (stories) de todo o trabalho desejado para o projeto. Cresce livremente, mas é priorizado pelo Product Owner.
    • Sprint backlog: stories do product backlog selecionadas e detalhadas no Planning Session  que devem ser entregues durante um sprint.
    • Burndown chart: Gráfico que torna visível o andamento de um sprint. Permite entender a “velocidade” de desenvolvimento de um sprint.

image

Visão geral do processo:

Artigos e cursos introdutórios podem ser encontrados aqui:

Treinamentos oficiais no Brasil podem ser procurados na AdaptWorks, empresa onde trabalham meus bons amigos Alexandre Magno e Edmilson Miyasaki.

Para acessar o calendário de cursos oficiais: http://www.scrumalliance.org/training

Google Apps + Startups = Lucro!

Muito bem, com a (auto) justificativa de se iniciar um blog já resolvida, posso começar a escrever algo sério aqui.

Se você está iniciando seu próprio negócio e está preocupado com custos, começar a sua infra-estrutura de TI com um empurrãozinho de serviços Web 2.0 da Google não atrapalha nada. Como é que disse Sir Isaac Newton?

Se eu vi mais longe, foi por estar de pé sobre ombros de gigantes.

Não sei quanto a você, mas a Google é gigante o bastante para mim.

Muitos serviços e produtos que há muito tempo eram muito bem pagos, podem ser agora desfrutados gratuitamente ou a um preço bem camarada usando-se o Google Apps.

Por exemplo:

  • Hosting do web site de sua empresa – Google Sites;
  • Servidor de e-mail – Google Apps Email;
  • Servidor de calendário – Google Apps Calendar;
  • Servidor de diretório corporativo – Google Apps Contacts;
  • Servidor de chat corporativo – Google Apps Chat;
  • Pacote de Edição de Textos, Planilhas e Apresentação – Google Apps Docs;

Todos os serviços acima, entre outros, são disponibilizados em duas versões: Permier Edition (US$ 50/ano/usuário) e Standard Edition (gratuito). A lista completa e comparação das funcionalidades pode ser vista aqui.

Uma das desvantagens deste tipo de serviço é que seus dados ficam em um servidor fora do seu controle. Mas isso também é uma vantagem, pois não ter que se preocupar com o hosting ou colocation, administração e backup de servidores significa mais economia ainda, o que é essencial no caso de startups com restrições de custo.

O que resta? O controle sobre os dados. Para isso, o Google oferece ferramentas e tecnologias de sincronização de e-mail (via IMAP/POP3/SMTP), tarefas, contatos e calendários com o Outlook (via Google Calendar Sync) e celulares (Google Mobile Sync).

O Google Apps oferece, assim, um conjunto de funcionalidades básicas de colaboração tradicional equivalentes às funcionalidades igualmente básicas de softwares caros e complexos de se instalar e administrar tais como Lotus Notes, Microsoft Exchange.

Para começar, clique aqui.

Se precisa de ajuda, é só comentar neste artigo!

IT Reflections | Reflections on IT – Por que?

Finalmente tomei a decisão: vou começar meu blog.

A partir de um certo ponto em nossas carreiras, depois de uma certa idade vivência (aham), é natural sentirmos que nossas cabeças estão prestes a explodir de tantas idéias. Aí, temos duas escolhas: ficarmos quietos e eternamente assombrados por essas danadas dessas idéias ou extravasá-las em artigos, monografias, livros, ou… blogs.

E aqui estou! Sabe aquela história de plantar uma árvore, ter um filho e escrever um livro? Veja o que penso:

1) Plantar uma árvore: desnecessário. Hoje em dia, quem tem tempo para conseguir uma muda, preparar e adubar a terra e, finalmente, plantar uma árvore? Há diversas formas de se contribuir positivamente com o nosso ecossistema:

2) Ter um filho: vai que é tua! Você só descobre as verdadeiras alegrias (e preocupações) da vida depois que você tem um filho. E ainda por cima, treinar é super divertido :)

3) Escrever um livro: que nada! Esse negócio de escrever livro é tão Geração X!!! Quem escreve livro é coroa. O negócio agora é mandar ver em artigos de blogs! E blogs de que? No meu caso, as tais idéias que assombram minha cuca são de TI, mesmo. Fazer o que?

Pronto (ufa!) agora sinto que estou perfeitamente justificado em começar este blog.