Hello everybody!
Depois de um longo inverno, retomo minha atividade de escrever. Juro que vou me policiar quanto à freqüência e gerenciar melhor o tempo para tal. Por isso vou experimentar escrever sempre um pouco por dia, para ao final de semana fechar o post. Vamos ver se vai dar certo!
Resolvi escrever então sobre SOA e “webservices”, termos que no momento estão em alta e que deixam um tom de sinônimo no ar, mas na realidade não é nada disso.
O termo SOA (do inglês “Service Oriented Architecture”) é a sigla do momento, aquela que anda na boca dos CIOs. Entre as perguntas que se devem fazer neste momento é se a arquitetura orientada a serviços é uma realidade ou mais uma daquelas tradicionais “hypes” do mundo da tecnologia. Mas há mais perguntas a serem respondidas: SOA veio para resolver ou para complicar? É bom para os negócios ou simplesmente mais um palavreado tecnológico? Está maduro e sendo adotado pelas empresas? Qual é o risco de adotá-lo?
São questões interessantes quem podemos levantar com o termo SOA, mas isso deixarei para um próximo artigo.
O que realmente me veio à mente foi mostrar as diferenças básicas em seu conceito, e que um vive perfeitamente sem o outro e também se complementam.
A Arquitetura Orientada a Serviços expressa um conceito onde aplicativos ou rotinas são disponibilizadas como serviços em uma rede de computadores (Internet ou Intranets) de forma independente e se comunicando através de padrões abertos.
Em entrevista à ComputerWorld um especialista de SOA (vice-presidente de tecnologia da divisão OpenEdge, Ken Wilner) foi indagado por algumas questões inteligentes e que sempre me veio à cabeça quando era indagado por alguém que se referia a desenvolvimento de sistemas utilizando essa filosofia. Foi respondido o seguinte:
“No curto prazo leva mais tempo, pois você tem de trabalhar mais nos requisitos de negócio, na arquitetura das aplicações, quais funções estarão expostas, dentre outras coisas. Mas, no médio e longo prazo a área de TI se tornará mais produtiva com o reuso de funções de negócio e a diminuição da necessidade de se reescrever códigos. O SOA requer uma disciplina. Não é como todo técnico pensa a questão de escrever o programa e sim em pensar o negócio da empresa. Você gasta mais tempo no desenho da arquitetura do que na programação.”
Com isso dá para ver claramente que o papel de arquiteto de sistemas aparece como figura essencial na especificação do reuso de funções de negócio. Nada de recriar a roda. Vamor reutilizá-la e caso não estejamos utilizando, compartilhar!
Enquanto isso na “liga da justiça” (não poderia deixar de falar isso), um “web service” é uma solução utilizada na integração de sistemas e na comunicação entre aplicações diferentes. Com esta tecnologia é possível que novas aplicações possam interagir com aquelas que já existem e que sistemas desenvolvidos em plataformas diferentes sejam compatíveis. Os Web services são componentes que permitem às aplicações enviar e receber dados em formato XML. Cada aplicação pode ter a sua própria “linguagem”, que é traduzida para uma linguagem universal, o formato XML.
Seguindo a entrevista de Ken, ele também dá uma pincelada o termo “web services”, vejam abaixo:
Ao fazer “web services” há quem pense que está fazendo SOA – e para fazer SOA se deve fazer web services.
É uma tecnologia para troca de informações, de conexão entre aplicações. O grande valor do SOA é a reutilização, o foco nas funcionalidades de negócio e quais delas eu quero expor aos parceiros ou internamente. O foco dos web services é expor funcionalidades como tecnologia de acesso.
Muitos dão sobrevida aos legados com “web services”, como os primeiros passos para o SOA. Não tem nada errado com isso, a não ser que a granuralidade dos objetos expostos é grande. Mas, quando nós trabalhamos com nossos parceiros ou clientes, não queremos saber em como conectar as aplicações entre si e sim quais são seus objetivos e necessidades de negócio. A tecnologia vem depois.
É errado escrever “web services” para seu legado? A resposta é: depende dos seus objetivos. Simples assim.
Ao mesmo especialista perguntaram a parte mais importante a ser seguida na implementação da filosofia SOA, o mesmo disse que a principal coisa é tratar o negócio e não a tecnologia. Se você começar pela tecnologia a implementação será um fracasso. Deve-se sempre perguntar o que isso significa para o seu negócio. Nada mais correto que isso.
Achei a entrevista com cunho de esclarecimento muito alto. Nessa sopa de letrinhas é importante separar bem essas palavras para não misturar alhos com bugalhos, ou, “web services” com SOA.
Vejo vocês no próximo artigo.
No próximo capítulo vou descrever algumas ferramentas web2.0 que utilizo e são sensacionais.
Vida Longa e Próspera
Referências:
Parabéns!!!!
Sou sua fã !!!!
Sucesso e muitas felicidades!