contidos na descrição do serviço para localizar, contactar e chamar o serviço. A figura mostra os componentes e a interação entre eles.

Transcrição

1 Web Services Web Service é um componente de software identificado por uma URI que independe de implementação ou de plataforma e pode ser descrito, publicado e invocado sobre uma rede por meio de mensagens padrão XML. As mensagens XML são transportadas usando protocolos padrões da Internet. Com web service é possível realizar a integração entre sistemas desenvolvidos em diferentes linguagens e plataforma, e disponibilizar serviços interativos na Web. É uma tecnologia de padrão aberto e padronizada pelo W3C. É 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. A arquitetura do Web Service é constituída por três componentes básicos: o servidor de registro (broker server ou service registry), o provedor de serviços (service provider) e o solicitante de serviços (service requestor). As interações entre esses componentes são de busca, publicação e interação de operações. Na operação de publicação o provedor publica a descrição do serviço de tal forma que um solicitante possa localizá-la. Na operação de busca o solicitante obtém a descrição do serviço diretamente ou consulta o servidor de registro procurando pelo tipo de serviço desejado. Essa operação pode ser executada em duas fases distintas: desenvolvimento ou execução. Na operação de interação o solicitante chama ou inicia uma interação com o provedor, em tempo de execução, utilizando os detalhes

2 contidos na descrição do serviço para localizar, contactar e chamar o serviço. A figura mostra os componentes e a interação entre eles. Componentes básicos da arquitetura do Web Service O provedor de serviços representa a plataforma que hospeda o web service permitindo que os clientes acessem o serviço. O provedor de serviços fornece o serviço e é responsável por publicar a descrição do serviço que provê. O solicitante de serviços é a aplicação que está procurando, invocando uma interação com o web service, ou seja, requisita a execução de um serviço. O solicitante de serviço pode ser uma pessoa acessando por meio do browser ou uma aplicação realizando uma invocação aos métodos descritos na interface do web service. O servidor de registro é um repositório central que contém a descrição (informação) de um web service, e é por meio do servidor de registro que essas descrições são publicadas e disponibilizadas para localização. Os clientes buscam por serviços no servidor de registro e recuperam informações referentes à interface de comunicação para os web service durante a fase de desenvolvimento ou durante a execuçãoo do cliente, denominadas interação estática

3 (static bind) e interação dinâmica (dinamic bind), respectivamente. Na interação estática, o cliente recupera a assinatura do serviço, necessária à codificação. Na interação dinâmica, o cliente recupera os valores de parâmetros e a localização do serviço. O ciclo de vida de um web service compreende quatro estados distintos: Publicação processo, opcional, por meio do qual o fornecedor do web services dá a conhecer a existência do seu serviço, efetuando o registro do mesmo no repositório do web service; Descoberta processo, opcional, por meio do qual uma aplicação cliente toma conhecimento da existência do web services pretendido pesquisando num repositório UDDI; Descrição processo pelo qual o web service expõe a sua API (documento WSDL). Desta maneira a aplicação cliente tem acesso a toda a interface do web service, onde encontram descritas todas as funcionalidades por ele disponibilizadas; Invocação (Mensagens) processo pelo qual o cliente e o servidor interagem, por meio do envio de mensagens; Ciclo de vida do web service A conjugação desses quatro estados permite constituir o ciclo de vida de um web service:

4 O fornecedor constrói o serviço utilizando a linguagem de programação que entender; De seguida, especifica a interface/assinatura do serviço que definiu em WSDL; Após a conclusão dos dois primeiros passos, o fornecedor registra o serviço no UDDI; O utilizador (aplicação cliente) pesquisa num repositório UDDI e encontra o serviço; A aplicação cliente estabelece a ligação com o web service e estabelece um diálogo com este, via mensagens SOAP. A interação entre os web services se dá sob vários protocolos abertos, em diferentes níveis de abstração. Os protocolos utilizados para realizar a comunicação são o: UDDI (Universal Description Discovery and Integration), WSDL (Web Services Description Language), XML, SOAP (Simple Object Access Protocol) e o HTTP, conforme figura. Protocolos de comunicação de Web services As mensagens trocadas são formatadas no protocolo SOAP, o que permite a interoperabilidade entre diferentes plataformas, em um processo denominado serialização XML. Porém, antes que as mensagens SOAP sejam trocadas, suas características são explicitadas por meio de documentos WSDL, que descrevem quais dados estarão sendo trocados, e como estes dados estarão organizados nas mensagens SOAP. Adicionalmente, os serviços

5 dos web services podem ser publicados através de UDDI, que é um formato utilizado para seu armazenamento em repositórios disponíveis na Internet. Assim, se um desenvolvedor precisar resolver uma determinada tarefa, pode encontrar o web service que mais se adequar à sua necessidade. Como os firewalls convencionais e proxies não bloqueiam a porta utilizada pelo protocolo HTTP, não existem grandes restrições para o uso deste tipo de aplicação em redes de longa distância. O objetivo dos Web Services é a comunicação de aplicações através da Internet. Esta comunicação é realizada com intuito de facilitar a EAI (Enterprise Application Integration) que significa a integração das aplicações de uma empresa, ou seja, interoperabilidade entre a informação que circula numa organização nas diferentes aplicações como, por exemplo, o comércio electrónico com os seus clientes e seus fornecedores. Esta interação constitui o sistema de informação de uma empresa. E para além da interoperabilidade entre as aplicações, a EAI permite definir um workflow entre as aplicações e pode constituir uma alternativa aos ERP (Enterprise Resource Planning). Com um workflow é possível otimizar e controlar processos e tarefas de uma determinada organização. Pode-se definir, resumidamente, o web service como sendo um serviço de software disponibilizado na Internet, descrito com um arquivo WSDL, registrado via UDDI, acessado utilizando SOAP e com dados representados em XML sendo transmitidos via HTTP. A disseminação no uso de web services nos últimos anos incentivou o mercado a oferecer uma grande variedade de ferramentas e aplicações para prover suporte a essa tecnologia. Atualmente, as principais plataformas para web services são: Sun Microsystems, IBM, BEA, Apache, Systinet e Microsoft.

6 Vantagens e Desvantagens Os Web Services são modelos que surgiram para o desenvolvimento de aplicações típicas de negócio electrónico, envolvendo e suportando o estabelecimento da colaboração e negociação de forma aberta, distribuída e dinâmica entre distintos parceiros. Os Web Services podem no futuro representar um sucesso significativo por causa de existir um esforço significativo, por parte da maioria dos parceiros industriais, na normalização das tecnologias envolvidas. As tecnologias subjacentes aos Web Services (tais como HTTP, SOAP, WSDL, UDDI, XML) são abertas, amplamente divulgadas e consensuais. Por outro lado, existe potencial para haver uma real independência das linguagens de programação (Java, C++, VB, Delphi, C#), das arquitecturas de computadores e sistemas operacionais, o que permite uma evolução mais suave e econômica para este modelo computacional. No entanto, existe críticas que demonstram medos ou falsas expectativas que os investimentos em Web Services podem suscitar. Uma dessas críticas diz respeito ao facto do SOAP é menos eficiente do que os sistemas de RPC existentes. Por exemplo, as mensagens (com os respectivos envelopes e descrição de tipos) trocadas entre as partes são descritas em formato de texto/xml enquanto que nos sistemas clássicos de RPC são trocadas em formato binário. No entanto, esta desvantagem é compensada significativamente pela facilidade de interoperação entre os serviços, sem os problemas conhecidos de segurança/firewalls, e pela facilidade de se esconder os detalhes proprietários das infra-estruturas de suporte. Você pode baixar o PDF Modelo de Referência para Arquitetura Orientada a Serviço 1.0 OASIS

7 Vejam um resumo que encontrei no Scribd: View this document on Scribd Fonte: Handbook de TI ABC da SOA O que é arquitetura orientada a serviços (SOA)? Service-Oriented Architecture (SOA) ou, em português, Arquitetura Orientada a Serviços é um termo que descreve duas coisas muito diferentes. As duas primeiras palavras expressam uma metodologia para desenvolvimento de software. A terceira palavra é um panorama de todos os ativos de software de uma empresa, assim como uma planta arquitetônica é uma representação de todas as peças que, juntas, formam uma construção. Portanto, service-oriented architecture é uma estratégia que proclama a criação de todos os ativos de software de uma empresa via metodologia de programação orientada a serviços. O que é um serviço? Serviços são porções ou componentes de software construídas de tal modo que possam ser facilmente vinculadas a outros componentes de software. A idéia por trás destes serviços é simples: a tecnologia expressa de forma que o pessoal de negócio possa entender, e não como um aplicativo enigmático. No centro do conceito de serviços está a idéia de que é possível definir partes dos códigos de software em porções

8 significativas o suficiente para serem compartilhadas e reutilizadas em diversas áreas da empresa. Com isso, algumas tarefas passam a ser automatizadas por exemplo, enviar uma query para um website de relatório de crédito para descobrir se um cliente se qualifica para um empréstimo. Se os programadores em um banco puderem abstrair todo este código em um nível mais alto (isto é, pegar todo o código que foi escrito para realizar a verificação de classificação de crédito e reuni-lo em uma única unidade chamada obter classificação de crédito ), eles poderão reutilizar esta porção da próxima vez que o banco decidir lançar um novo produto de empréstimo que requeira a mesma informação, ao invés de ter que escrever o código a partir do zero. Para chegar a isto, os desenvolvedores criam um invólucro complexo em torno do código empacotado. Este invólucro é uma interface que descreve o que a porção faz e como conectar a ele. É um conceito antigo, que data dos anos 80, quando a programação orientada a objetos surgiu. A única diferença é a demanda atual por objetos de software muito maiores e mais sofisticados. Na operadora norte-americana Verizon, por exemplo, o serviço get CSR (get customer service record, obter registro de serviço ao cliente) é uma miscelânea complexa de ações de software e extrações de dados que emprega infra-estrutura de integração da empresa para acessar mais de 25 sistemas em quatro data centers ao redor do país. Antes de criar o serviço get CSR, desenvolvedores da Verizon que precisavam desta porção crítica de dados tinham que criar links para todos os 25 sistemas acrescentar seus próprios links sobre a teia complexa de links que já pendiam dos sistemas populares. Porém, com o serviço get CSR situado em um repositório central na intranet da Verizon, estes desenvolvedores agora podem usar o simple object access protocol (SOAP) para criar um único link para a interface cuidadosamente elaborada ao redor do serviço. Estes 25 sistemas entram em fila e marcham

9 imediatamente, enviando informação do cliente para o novo aplicativo e poupando meses, ou mesmo anos, de tempo de desenvolvimento dos desenvolvedores cada vez que eles usam o serviço. Existem muitas maneiras diferentes de conectar serviços, como links de programação customizados ou software de integração de fornecedores, mas, desde 2001, um conjunto de mecanismos de comunicação de software conhecido como web services, criados sobre a onipresente World Wide Web, tornou-se um método cada vez mais popular para integrar componentes de software. Qual é a diferença entre SOA e web services? SOA é a arquitetura abrangente para criar aplicações dentro de uma empresa pense em um projeto arquitetônico mas, neste caso, a arquitetura demanda que todos os programas sejam criados com uma metodologia de desenvolvimento de software específica, conhecida como programação orientada a serviço. Web services são um conjunto de mecanismos-padrão de comunicação criados sobre a World Wide Web. Ou seja, os web services são uma metodologia para conectar e comunicar. Enquanto SOA é uma estratégia de TI. Como sei se devo adotar uma estratégia SOA? Sendo uma estratégia arquitetural, SOA envolve muito mais do que o mero desenvolvimento de software. A criação de uma arquitetura baseada em um portfólio de serviços demanda que os CIOs elaborem um case convincente para uma arquitetura corporativa, uma metodologia de desenvolvimento centralizada e uma equipe centralizada de gerentes de projeto, arquitetos e desenvolvedores. Também requer um CEO e uma equipe executiva dispostos, que preparem o terreno para que o pessoal de TI possa mergulhar em processos core da empresa. Entender estes processos e conquistar adesão para o compartilhamento corporativo são a pedra angular de uma transformação do negócio baseada em SOA.

10 Governança é vital. Para que os serviços sejam reutilizados na empresa, tem de haver uma metodologia de desenvolvimento de software única e centralizada de modo que áreas diferentes não criem o mesmo serviço de maneiras diferentes ou usem conectores incompatíveis. Tem que haver um repositório centralizado para que os desenvolvedores saibam onde procurar serviços e TI saiba por quem eles estão sendo utilizados. Os serviços têm de ser bem documentados para que os desenvolvedores saibam para que eles servem, como integra-los e as regras para usá-los. Algumas empresas, por exemplo, cobram taxas de utilização dos serviços e criam acordos de performance para garantir que os serviços funcionem bem e não sobrecarreguem a rede corporativa. A maioria das empresas que avançou no caminho para SOA criou um grupo de arquitetura centralizado para escolher processos que serão capacitados para serviço e consultar áreas diferentes da empresa para criar os serviços específicos. O grupo centralizado também cria um mecanismo conveniente para governança. Se todas as solicitações de serviço têm de passar pelo grupo de arquitetura, as metodologias de desenvolvimento de serviço, os projetos e os acordos de performance podem ser gerenciados mais facilmente. As empresas que tiveram mais êxito com SOA até agora são as que sempre tiverem êxito com tecnologia: grandes empresas com grandes budgets para TI cujo negócio é baseado em tecnologia (serviços de telecomunicação e financeiros). Elas também tendem a ter líderes de negócio envolvidos com a área de TI e dispostos a apoiar seus projetos. Para empresas sem estas vantagens, SOA talvez não seja tudo o que promete. Para empresas menores, empresas que apostaram alto em pacotes de aplicativos integrados e empresas que já adotam estratégias sólidas de integração de aplicativos, SOA não tem a ver com quando, mas com se. Os CIOs têm de ser cuidadosos porque, na arquitetura orientada a serviços, os elementos desenvolvimento de serviço e planejamento de arquitetura

11 são distintos, porém não independentes precisam ser considerados e executados paralelamente. Serviços que são criados isoladamente, sem levar em conta as metas de arquitetura e de negócio da empresa, podem apresentar pouco potencial de reutilização (um dos benefícios mais importantes da SOA) ou fracassar por completo. Quais as vantagens da SOA? Antes de mais nada, os benefícios de da arquitetura orientada a serviços devem ser contextualizados. Se sua empresa não for grande ou complexa, isto é, se não tiver mais de dois sistemas primários que exijam algum nível de integração, é improvável que o modelo proporcione grandes benefícios. Em meio a todo o hype atual em torno da SOA, esquece-se facilmente que a metodologia de desenvolvimento em si não traz vantagens é o efeito que ela tem sobre uma infra-estrutura redundante e complexa que o faz. Os arquitetos dizem que a criação de um bom aplicativo orientado a serviços envolve mais trabalho do que a tradicional integração de aplicativos. (Pesquisas mostram que SOA está sendo usada para integração tradicional de aplicativos na maioria das empresas.) Assim, o desenvolvimento da SOA gera um custo inicial extra. Para que este trabalho produza benefícios, portanto, SOA tem que eliminar trabalho em outro ponto qualquer, já que a própria metodologia não gera benefícios para o negócio. Assim, o primeiro passo é descobrir se existem aplicativos redundantes e mal integrados que poderiam ser consolidados ou eliminados como resultado da adoção. Se este for o caso, então há benefícios potenciais. Para entender o panorama geral dos benefícios apregoados por SOA, você precisa examiná-lo em dois níveis: primeiro, as vantagens táticas do desenvolvimento orientado a serviços e, segundo, as vantagens da SOA como estratégia de arquitetura global. Vantagens do desenvolvimento orientado a serviços:

12 1. Reutilização de software. Se o pacote de códigos que constitui um serviço tiver o tamanho e o escopo certos (um grande se, dizem os veteranos em SOA), então ele poderá ser reutilizado da próxima vez que a equipe de desenvolvimento precisar de uma função específica para um novo aplicativo que queira desenvolver. Digamos que uma empresa de telecomunicações tenha quatro divisões diferentes, cada qual com seu próprio sistema para processar pedidos. Todos estes sistemas executam determinadas funções similares, como verificações de crédito e buscas de registros de clientes. Mas, tendo em vista que cada sistema é altamente integrado, nenhuma destas funções redundantes pode ser compartilhada. O desenvolvimento orientado a serviços coleta o código necessário para criar uma versão de verificação de crédito que possa ser compartilhada pelos quatro sistemas. O serviço pode ser uma porção de software totalmente nova ou um aplicativo composto, consistindo de código de alguns dos sistemas ou de todos eles. De qualquer forma, o composite é envolto por uma interface que oculta sua complexidade. Da próxima vez que os desenvolvedores quiserem criar um aplicativo que exija verificação de crédito, vão criar um link simples para o novo aplicativo. Eles não precisam se preocupar em conectar aos sistemas individuais na realidade, nem precisam saber como o código foi incluído ou de onde ele vem. Só precisam criar uma conexão para ele. Em uma empresa que desenvolve constantemente sistemas novos que se apóiam em funcionalidade similar uma empresa seguradora com muitas divisões diferentes, cada uma com produtos ligeiramente diferentes, por exemplo, ou uma empresa que está sempre adquirindo outras o tempo economizado nas tarefas de desenvolver, testar e integrar esta mesma funcionalidade de software é uma vantagem. Mas a reutilização não é garantida. Se desenvolvedores em outras partes da empresa não souberem que os serviços existem ou não confiarem que eles são bem construídos, ou se as

13 metodologias de desenvolvimento variarem dentro da empresa, os serviços podem definhar e não se repetir. As empresas adeptas da reutilização desenvolveram mecanismos de governança equipes de desenvolvimento centralizadas, metodologia única de desenvolvimento e repositórios de serviços para aumentar suas chances de reutilização. Às vezes, porém, o serviço simplesmente não é bem projetado. Ele não realiza operações suficientes para ser amplamente aplicável na empresa ou tenta realizar operações demais. Ou os desenvolvedores não levaram em conta que outros possam querer usar o serviço de maneiras diferentes. Para profissionais experientes no assunto, o dimensionamento adequado dos serviços também conhecido como granularidade é tanto uma arte quanto uma ciência, e a má-granularidade pode reduzir drasticamente as possibilidades de reutilização. Pesquisas do Gartner estimam que apenas algo entre 10% e 40% dos serviços são reutilizados. 2. Aumentos de produtividade. Se os desenvolvedores reutilizam serviços, os projetos de software podem andar mais rápido e a mesma equipe de desenvolvimento pode trabalhar em mais projetos. A integração se torna mais barata (no mínimo 30%, de acordo com estimativas do Gartner) e mais rápida, eliminando alguns meses dos ciclos de desenvolvimento de novos projetos. Shadman Zafar, vicepresidente sênior para arquitetura e e-services da Verizon, diz que seu catálogo de serviços dispensou-o de montar uma equipe de projeto para o desenvolvimento de um processo de pedido de linha telefônica porque os serviços necessários para compor o processo já existiam. Com integração ponto a ponto, teríamos uma equipe de projeto central criando a integração geral e equipes locais para cada um dos sistemas ao qual precisávamos integrar. Com o processo de pedido de linha telefônica, tínhamos uma única equipe focada quase que inteiramente em teste de uma ponta a outra, explica. Isso poupa tempo e recursos e melhora a qualidade de novos

14 aplicativos, porque o teste não é mais o último obstáculo de um processo de desenvolvimento de aplicativos exaustivo; ele é o foco. 3. Maior agilidade. Mesmo que os serviços não sejam reutilizados, podem agregar valor se facilitarem a modificação de sistemas de TI. Na ProFlowers.com, por exemplo, não existem aplicativos redundantes ou múltiplas unidades de negócio clamando por serviços. Mas, com a divisão do processo de pedido de flores em serviços discretos, cada componente pode ser isolado e modificado conforme o necessário para lidar com os picos de demanda que acontecem em datas festivas, segundo Kevin Hall, CIO da ProFlowers. Quando a ProFlowers tinha apenas um aplicativo monolítico encarregado do processo, uma única alteração no processo ou um crescimento do volume de transações (no dia dos namorados, por exemplo) exigia que o sistema inteiro fosse recriado. No novo sistema, os servidores reagem aos picos de atividade durante cada fase do processo de pedido, transferindo capacidade para o serviço específico que está precisando mais dela. O sistema está muito mais previsível e não houve interrupções desde que o processo capacitado por serviço foi implantado, no início de 2002, de acordo com Hall. Visto que podemos escalar horizontalmente [mais servidores] e verticalmente [dividindo os serviços], não tenho que comprar hardware de acordo com as cargas mais altas, afirma. Vantagens de uma estratégia SOA: 1. Melhor alinhamento com o negócio. A arquitetura orientada a serviços é o panorama geral de todos os processos e fluxos de negócio de uma empresa. Significa que o pessoal de negócio pode visualizar, pela primeira vez, como a empresa é construída em termos de tecnologia. Quando projetos de TI são apresentados em termos de atividades e

15 processos de negócio e não na forma de aplicativos complexos, o pessoal de negócio pode apreciar e suportar melhor os projetos de TI. Quando eu disse que tínhamos 18 versões de verificação de crédito ligeiramente diferentes embutidas em aplicativos diferentes, em agências diferentes, os diretores das agências entenderam por que era problemático e apoiaram a criação de uma única versão que fosse usada por todos, recorda Matt Miszewski, CIO para o estado de Wisconsin. A visão grandiosa da SOA é que, quando TI capacitar plenamente para serviços os processos importantes de um negócio, o pessoal de negócio poderá assumir controle sobre modificar e mesclar os diferentes serviços em novas combinações de processo próprias. Mas esta visão ainda está a muitos anos de distância. 2. Uma maneira melhor de vender arquitetura para o negócio (e TI). Há tempos a arquitetura corporativa tem sido o conceito que não ousa dizer seu nome. Alguns CIOs chegam ao ponto de não usar o termo com os colegas por medo de assustá-los, perdê-los ou simplesmente entediá-los. Arquitetura corporativa sempre foi uma empreitada grande, complexa e cara. Seu ROI, com freqüência, é nebuloso para o negócio. Padronizar, mapear e controlar ativos de TI não torna o negócio claramente mais flexível, capaz ou lucrativo. Como resultado, os esforços de arquitetura de TI muitas vezes fracassam ou se tornam completamente centrados em TI. A arquitetura orientada a serviços proporciona o valor ao negócio que, na velha arquitetura corporativa, raramente passava de uma vaga promessa. Reutilização, maior produtividade e agilidade em TI e uma infra-estrutura de software ajustada para processos de negócio específicos são as iscas para vender uma iniciativa de arquitetura corporativa para o negócio. Mas lembre-se de que arquitetura não é para todos. Empresas pequenas ou empresas extremamente descentralizadas talvez não consigam justificar uma equipe centralizada de gerentes de projeto, arquitetos e

16 desenvolvedores. Como equilibrar a necessidade de planejamento de arquitetura em SOA com a necessidade de provar o valor para o negócio rapidamente? Planejamento arquitetural consome tempo. O desenvolvimento orientado a serviços, baseado em princípios de programação conhecidos e padrões de tecnologia amplamente disponíveis (SOAP, HTTP e assim por diante), pode ser muito mais veloz. Mas os dois têm que acontecer paralelamente, ensinam os especialistas. Fazemos projetos de desenvolvimento conforme o necessário e, paralelamente, temos um projeto plurianual, mais longo, de mapear os processos e criar serviços no nível corporativo, diz Kurt Wissner, diretor de arquitetura corporativa e desenvolvimento da American Electric Power (AEP). As pessoas precisam ver o benefício da SOA muito rapidamente. É por isso que gosto de projeto; do contrário, você não tem nada tangível para vender a ninguém sobre a razão de fazer o que está fazendo. Ajudaria ter o plano arquitetural e o mapeamento de processo implantados antes de criar os serviços (para aumentar as chances de reutilização), mas o planejamento de arquitetura não apresenta retorno no curto prazo, o que pode ser devastador. Tentei um plano ambicioso demais em outra empresa e fracassei, lembra Wissner. Criamos um grande plano de arquitetura de milhões de dólares que duplicou o que já tínhamos. O plano não apresentou muito valor em relação à integração ponto a ponto tradicional e nossos esforços não deram em nada. Se você já começa com a empresa inteira, são muitos os riscos de fracassar. Ao abordar o planejamento empresarial em porções menores na AEP, Wissner pode se recuperar mais facilmente de revezes. Tivemos tropeços, mas conseguimos tomar atitudes corretivas porque não era nada muito grande, diz. Como sei quais serviços vão gerar mais valor em troca do meu investimento?

17 Quando estiver em dúvida, comece com processos que envolvem clientes, afetam diretamente a receita e abordem um ponto nevrálgico da empresa. De acordo com pesquisa realizada em 2006 pelo Business Performance Management Institute, mudanças em necessidades e preferências de clientes são o principal motor de mudança em processos de negócio ou de adoção de novos aplicativos, seguidas por ameaças competitivas e novas oportunidades de receita. Aplicativos de ponta são os que fornecem o maior valor para o negócio e têm um bom conjunto de requisitos de mudança que surgem com muita freqüência, diz Daniel Sholler, vice-presidente de pesquisa do Gartner. Se você puder aprimorar estes aplicativos em 10%, é melhor do que aprimorar aplicativos de nível mais baixo em 50%. Obviamente, acrescenta Sholler, a SOA pode não fornecer mais valor do que um bom aplicativo empacotado, por exemplo. Mas, se é algo que você mesmo teria que criar de qualquer forma, então tem que ser orientado a serviço. Como SOA vai afetar meu grupo de TI? Se você tem uma empresa descentralizada, prepare-se para lutar. SOA leva à centralização. Na realidade, pede centralização. Você precisa ter alguém liderando, você precisa ter um indivíduo ou uma pequena equipe gerenciando a arquitetura, aconselha Mike Falls, engenheiro sênior de sistemas da Fastenal, empresa de suprimentos industriais e de construção. Se for cada equipe por si, elas podem acabar adotando maneiras diferentes de criar serviços. Você precisa de um grupo, um conjunto de pesquisas e alguém para garantir que os grupos de desenvolvimento se atenham à metodologia de desenvolvimento de serviço. À medida que o portfólio de serviços cresce, o processo de desenvolvimento pode começar a assemelhar-se a uma linha de montagem. Transforma-se em uma fábrica, diz Wissner, da AEP. Você tem equipes de projeto diferentes através das quais canaliza o trabalho e elas podem aumentar e diminuir conforme o necessário.

18 Depois que a fábrica SOA está produzindo a todo vapor, prepare-se para acrescentar mais gerentes de projeto, analistas de negócio e arquitetos à medida que a produtividade dos desenvolvedores aumenta, diz Haal, da ProFlowers. Dois desenvolvedores agora podem fazer o trabalho de seis, observa. Isso significa que os arquitetos e gerentes de projeto estão se esforçando para acompanhar o trabalho dos engenheiros. Provavelmente estamos realizando 50% de trabalho a mais do que há três anos. Estes programadores precisam entender programação orientada a objeto e aplicativos distribuídos o que implica investimentos em treinamento. Segundo pesquisa de CIO/Computerworld, apenas 25% dos entrevistados têm as equipes de que necessitam para adotar arquitetura orientada a serviços 49% planejam ter ou já têm programas de treinamento para que a equipe atual trabalhe a todo vapor. Fonte: CIO O que é Interoperabilidade? Interoperabilidade é a capacidade de um sistema (informatizado ou não) de se comunicar de forma transparente (ou o mais próximo disso) com outro sistema (semelhante ou não). Para um sistema ser considerado interoperável, é muito importante que ele trabalhe com padrões abertos ou ontologias. Seja um sistema de portal, seja um sistema educacional ou ainda um sistema de comércio eletrônico, ou e-commerce, hoje em dia se caminha cada vez mais para a criação de padrões para sistemas. Interoperabilidade não é somente integração de sistemas nem somente integração de redes. Não referencia unicamente troca

19 de dados entre sistemas e não contempla simplesmente definição de tecnologia. É, na verdade, a soma de todos esses fatores, considerando, também, a existência de um legado de sistemas, de plataformas de hardware e software instaladas. Parte de princípios que tratam da diversidade de componentes, com a utilização de produtos diversos de fornecedores distintos. Tem por meta a consideração de todos os fatores para que os sistemas possam atuar cooperativamente, fixando as normas, as políticas e os padrões necessários para consecução desses objetivos. Para que se conquiste a interoperabilidade, as pessoas devem estar engajadas num esforço contínuo para assegurar que sistemas, processos e culturas de uma organização sejam gerenciados e direcionados para maximizar oportunidades de troca e reuso de informações, interna e externamente ao governo federal. As faces da Interoperabilidade Na área da tecnologia de informação a interoperabilidade é a troca de informações e/ou dados através de computadores. Interoperabilidade é também a capacidade de comunicar, executar programas através de várias unidades funcionais, utilizando-se de linguagens e protocolos comuns. A Interoperabilidade tem várias faces, a interoperabilidade técnica é, talvez, o sistema mais responsável por manter os sistemas de informação interoperáveis, mas existem outros conceitos importantes para o nosso conhecimento: Interoperabilidade Técnica É o contínuo desenvolvimento de padrões de comunicação, transporte, armazenamento e representação de informações, através do envolvimento de um conjunto de organizações. É de

20 competência da I.T facilitar a convergência de padrões, onde seja possível ter um conjunto de padrões no sistema em benefício da comunidade. Interoperabilidade semântica É o significado ou semântica das informações de diferentes origens, é solucionada através de ferramentas comuns de representação da informação, como classificação e ontologias. Interoperabilidade política/humana É de enorme importância a forma que as informações são disseminadas e a decisão de torná-las disponíveis é fundamental à organização (para equipes envolvidas e para os usuários). Políticas públicas devem existir para resolver os problemas da exclusão digital, lutar pela democratização do acesso, e pelos programas de educação a distância. A falta de interoperabilidade humana esta relacionada à falta de compreensão ou de entendimento entre os homens a respeito de um tema. Um exemplo deste fenômeno é a resistência de alguns dirigentes de universidades ou mesmo da área governamental em adotar as iniciativas do acesso livre ao conhecimento científico. Um outro exemplo, ainda na área governamental, diz respeito ao empreendimento de uma mesma ação na mesma área ou setor. Interoperabilidade intercomunitária Muitas informações são escritas todos os dias e uma grande parte delas não tem compromisso com a verdade, são muitas fontes e não há controle. Nas áreas de pesquisa essa problemática é ainda maior, é muito importante a criação de fóruns para discussão. Interoperabilidade legal São exigências e implicações legais de tornar livremente disponíveis itens de informação. Interoperabilidade Internacional È necessário conduzir bem a língua, atentar as diferenças linguisticas, normas e padrões. Interoperabilidade Organizacional Envolve a edição de

21 processo das organizações que tenham objetivos e metas que envolvam a cooperação do grupo. A interoperabilidade, intercâmbio coerente de informações e serviços entre sistemas, possibilita a substituição de qualquer componente ou produto usado nos pontos de interligação por outro de especificação similar, sem comprometimento das funcionalidades do sistema. É objetivo da política da informação assegurar a interoperabilidade entre os sistemas de segurança da informação. Fontes: droes-de-interoperabilidade/o-que-e-interoperabilidade Arquitetura de Aplicações em 2, 3, 4 ou N camadas Fiz uma compilação de partes de textos e iremos aqui discutir cada um dos conceitos, mostrando as vantagens e desvantagens de aplicações em cada quantidade de camadas existentes, ou seja, toda sua evolução. Modelo Cliente/Servidor Cliente-servidor é um modelo computacional que separa clientes e servidores, sendo interligados entre si geralmente utilizando-se uma rede de computadores. Cada instância de um cliente pode enviar requisições de dado para

22 algum dos servidores conectados e esperar pela resposta. Por sua vez, algum dos servidores disponíveis pode aceitar tais requisições, processá-las e retornar o resultado para o cliente. Apesar do conceito ser aplicado em diversos usos e aplicações, a arquitetura é praticamente a mesma. O modelo Cliente/Servidor, foi criado tendo como base a descentralização dos dados e recursos de processamento, em oposição ao modelo Centralizado utilizado na época em que o Mainframe dominava absoluto. No modelo Cliente/Servidor, conforme indicado pela figura abaixo, em uma rede de computadores, existem uma ou mais máquinas que atuam como Servidores, disponibilizando recursos para as demais máquinas, as quais atuam como Clientes. A máquina servidor é um host que está executando um ou mais programas de servidor que partilham os seus recursos com os clientes. Um cliente não compartilha de seus recursos, mas solicita o conteúdo de um servidor ou função de serviço. Os clientes, portanto, iniciam sessões de comunicação com os servidores que esperam as solicitações de entrada. Modelo Cliente-Servidor Conforme pode ser visto na figura, temos Servidores para Arquivos, Banco de dados e outras funções, tais como: Servidores de impressão, Servidores Web, etc. Estas redes,

23 tipicamente, são formadas por Servidores, os quais são equipamentos com um maior poder de processamento e armazenamento do que os clientes, os quais, na maioria dos casos, são Microcomputadores ligados em rede. Aplicações em 2 Camadas No início da utilização do modelo Cliente/Servidor, as aplicações foram desenvolvidas utilizando-se um modelo de desenvolvimento em duas camadas. Neste modelo, um programa, normalmente desenvolvido em um ambiente de desenvolvimento, como o Visual Basic, Delphi ou Power Builder, é instalado em cada Cliente. Este programa acessa dados em um servidor de Banco de dados, conforme ilustrado na figura abaixo: 2 Camadas No modelo de duas camadas, temos um programa que é instalado no Cliente, programa esse que faz acesso a um Banco de dados que fica residente no Servidor de Banco de dados. Na maioria dos casos, a máquina do Cliente é um PC rodando Windows, e a aplicação Cliente é desenvolvida utilizando-se um dos ambientes conhecidos, conforme citado anteriormente. Sendo a aplicação Cliente, um programa para Windows (na grande maioria dos casos), esta deve ser instalada em cada um dos computadores da rede, que farão uso da aplicação. É o processo de instalação normal, para qualquer aplicação Windows. No

24 modelo de 2 camadas, a aplicação Cliente é responsável pelas seguintes funções: Apresentação: O Código que gera a Interface visível do programa, que é utilizada pelo usuário para acessar a aplicação, faz parte da aplicação Cliente. Todos os formulários, menus e demais elementos visuais, estão contidos no código da aplicação Cliente. Caso sejam necessárias alterações na interface do programa, faz-se necessária a geração de uma nova versão do programa, e todos os computadores que possuem a versão anterior, devem receber a nova versão, para que o usuário possa ter acesso as alterações da interface. Aí que começam a surgir os problemas no modelo de 2 camadas: Uma simples alteração de interface, é suficiente para gerar a necessidade de atualizar a aplicação, em centenas ou milhares de computadores. O gerenciamento desta tarefa, é algo extremamente complexo e de custo elevado. Lógica do Negócio: Aqui estão as regras que definem a maneira como os dados serão acessados e processados, as quais são conhecidas como Lógica do Negócio. Fazem parte das Regras do Negócio, desde funções simples de validação da entrada de dados, como o cálculo do digito verificador de um CPF, até funções mais complexas, como descontos escalonados para os maiores clientes, de acordo com o volume da compra. Questões relativas a legislação fiscal e escrita contábil, também fazem parte da Lógica do Negócio. Por exemplo, um programa para gerência de Recursos Humanos, desenvolvido para a legislação dos EUA, não pode ser utilizado, sem modificações, por uma empresa brasileira.. Alterações nas regras do negócio são bastante freqüentes, ainda mais com as repetidas mudanças na legislação do nosso país. Com isso, faz-se necessária a geração de uma nova versão do programa, cada vez que uma determinada regra muda, ou quando regras forem acrescentadas ou retiradas. Desta forma, todos os computadores que possuem a versão

25 anterior, devem receber a nova versão, para que o usuário possa ter acesso as alterações. Mais problemas com o modelo de 2 camadas: Qualquer alteração nas regras do negócio, é suficiente para gerar a necessidade de atualizar a aplicação, em centenas ou milhares de computadores. O gerenciamento desta tarefa, é algo extremamente complexo e de custo elevado. A outra camada, vem a ser o Banco de dados, o qual fica armazenado em Servidor da rede. Uma aplicação desenvolvida em Visual Basic, a qual acessa um Banco de dados em um servidor Microsoft SQL Server, é um típico exemplo de uma aplicação em 2 camadas. Com a evolução do mercado e as alterações da legislação, mudanças nas regras do negócio são bastante freqüentes. Com isso o modelo de duas camadas, demonstrou-se de difícil manutenção e gerenciamento, além de apresentar um custo de propriedade muito elevado. Isto sem contar com o problema conhecido como DLL Hell (Inferno das DLLs), onde diferentes aplicativos, instalam diferentes versões da mesma DLL e um conflito é gerado. É o caso típico onde a instalação de um programa, faz com que um ou mais programas, instalados anteriormente, deixem de funcionar. Em resumo, como diria um famoso comediante: Uma verdadeira visão do Inferno. Inferno para o usuário, que não tem os programas funcionando como deveriam; inferno para a equipe de desenvolvimento que não tem o seu trabalho reconhecido e, normalmente, tem que trabalhar apenas apagando incêndios ; e inferno para a Administração/Gerência da rede que não consegue gerar os resultados esperados pela Administração da empresa, apesar dos elevados valores já investidos. Resumindo: Sistemas em camadas surgiram para: Melhor aproveitar os PCs da empresa

26 Oferecer sistemas com interfaces gráficas amigáveis Integrar o desktop e os dados corporativos Em outras palavras, permitiram aumentar a escalabilidade de uso de Sistemas de Informação Os primeiros sistemas cliente-servidor eram de duas camadas Camada cliente trata da lógica de negócio e da UI Camada servidor trata dos dados (usando um SGBD) Pode parecer difícil de acreditar, mas um grande número de empresas ainda tem a maioria dos seus aplicativos baseados no modelo Cliente/Servidor de 2 camadas. Em busca de soluções para os problemas do modelo de duas camadas, é que surge a proposta do modelo de 3 camadas. Aplicações em 3 Camadas Modelo em três camadas, derivado do modelo n camadas, recebe esta denominação quando um sistema cliente-servidor é desenvolvido retirando-se a camada de negócio do lado docliente. O desenvolvimento é mais demorado no início comparando-se com o modelo em duas camadas pois é necessário dar suporte a uma maior quantidade de plataformas e ambientes diferentes. Em contrapartida, o retorno vem em forma de respostas mais rápidas nas requisições, excelente performance tanto em sistemas que rodam na Internet ou em intranet e mais controle no crescimento do sistema. Como uma evolução do modelo de 2 camadas, surge, com o crescimento da Internet, o modelo de três camadas. A idéia básica do modelo de 3 camadas, é retirar as Regras do Negócio do cliente e centralizá-las em um determinado ponto, o

27 qual é chamado de Servidor de Aplicações. O acesso ao Banco de dados é feito através das regras contidas no Servidor de Aplicações. Ao centralizar as Regras do Negócio em um único ponto, fica muito mais fácil a atualização destas regras. A figura, nos dá uma idéia geral do modelo em 3 camadas: 3 Camadas Todo o acesso do cliente ao Banco de dados, é feito de acordo com as regras contidas no Servidor de aplicações. O cliente não tem acesso direto ao Banco de dados, sem antes passar pelo servidor de aplicações. Com isso as três camadas são as seguintes: Apresentação: Continua no programa instalado no cliente. Alterações na Interface do programa, geram a necessidade de atualizar a aplicação em todos os computadores, onde esta está sendo utilizada. Porém cabe ressaltar, que alterações na interface, são menos freqüentes do que alterações nas regras do negócio. Lógica: São as regras do negócio, as quais determinam de que maneira os dados serão utilizados. Esta camada foi deslocada para o Servidor de aplicações. Desta maneira, quando uma regra do negócio for alterada, basta atualizá-la no Servidor de aplicações. Após a atualização, todos os usuários passarão a ter acesso a nova versão, sem que seja necessário reinstalar o programa em cada um dos computadores da rede. Vejam que

28 ao centralizar as regras do negócio em um Servidor de aplicações, estamos facilitando a tarefa de manter a aplicação atualizada. Dados: Nesta camada temos o servidor de Banco de dados, no qual reside toda a informação necessária para o funcionamento da aplicação. Cabe ressaltar, novamente, que os dados somente são acessados através do Servidor de aplicação, e não diretamente pela aplicação Cliente. Resumindo: A arquitetura cliente/servidor em 2 camadas sofria de vários problemas: Falta de escalabilidade (conexões a bancos de dados) Enormes problemas de manutenção (mudanças na lógica de aplicação forçava instalações) Dificuldade de acessar fontes heterogêneas (legado CICS, 3270, ) Inventou-se a arquitetura em 3 camadas Camada de apresentação (UI) Camada de aplicação (business logic) Camada de dados Problemas de manutenção foram reduzidos, pois mudanças às camadas de aplicação e de dados não necessitam de novas instalações no desktop Observe que as camadas são lógicas: Fisicamente, várias camadas podem executar na mesma máquina Quase sempre, há separação física de máquinas Com a introdução da camada de Lógica, resolvemos o problema de termos que atualizar a aplicação, em centenas ou milhares de computadores, cada vez que uma regra do negócio for alterada. Porém continuamos com o problema de atualização da aplicação, cada vez que forem necessárias mudanças na Interface. Por isso que surgiram os modelos de n-camadas. Agora vamos falar um pouco sobre o modelo de 4 camadas.

29 Aplicações em 4 Camadas (Web Based) Como uma evolução do modelo de três camadas, surge o modelo de quatro camadas. A idéia básica do modelo de 4 camadas, é retirar a apresentação do cliente e centralizá-las em um determinado ponto, o qual na maioria dos casos é um servidor Web. Com isso o próprio Cliente deixa de existir como um programa que precisa ser instalado em cada computador da rede. O acesso a aplicação, é feito através de um Navegador, como o Internet Explorer ou o Netscape Navigator. A figura nos dá uma idéia geral do modelo em quatro camadas: 4 Camadas Para acessar a aplicação, o cliente acessa o endereço da aplicação, utilizando o seu navegador. Por exemplo Todo o acesso do cliente ao Banco de dados, é feito de acordo com as regras contidas no Servidor de aplicações. O cliente não tem acesso direto ao Banco de dados, sem antes passar pelo servidor de aplicações. Com isso as quatro camadas são as seguintes: Cliente: Nesta caso o Cliente é o Navegador utilizado

30 pelo usuário, quer seja o Internet Explorer, quer seja o Netscape Navigator, ou outro Navegador qualquer. Apresentação: Passa para o Servidor Web. A interface pode ser composta de páginas HTML, ASP, ou qualquer outra tecnologia capaz de gerar conteúdo para o Navegador. Com isso alterações na interface da aplicação, são feitas diretamente no servidor Web, sendo que estas alterações estarão, automaticamente, disponíveis para todos os Clientes. Com isso não existe a necessidade de reinstalar a aplicação em todos os computadores da rede cada vez que uma alteração for feita na camada de apresentação. Fica muito mais fácil garantir que todos estão acessando a versão mais atualizada da aplicação. A única coisa que o cliente precisa ter instalado na sua máquina, é o Navegador. O acesso ao Banco de dados, é feito através do Servidor de aplicações. Lógica: São as regras do negócio, as quais determinam de que maneira os dados serão utilizados. Esta camada está no Servidor de aplicações. Desta maneira, quando uma regra do negócio for alterada, basta atualizá-la no Servidor de aplicações. Após a atualização, todos os usuários passarão a ter acesso a nova versão, sem que seja necessário reinstalar o programa em cada um dos computadores da rede. Vejam que ao centralizar as regras do negócio em um Servidor de aplicações, estamos facilitando a tarefa de manter a aplicação atualizada. Dados: Nesta camada temos o servidor de Banco de dados, no qual reside toda a informação necessária para o funcionamento da aplicação. Com o deslocamento da camada de apresentação para um Servidor Web, resolvemos o problema de termos que atualizar a aplicação, em centenas ou milhares de computadores, cada vez que a interface for alterada. Neste ponto a atualização das aplicações é uma tarefa mais gerenciável, muito diferente do que acontecia no caso do modelo em duas camadas.

31 Os servidores de Aplicação, servidor Web e servidor de Banco de dados, não precisam, necessariamente, ser servidores separados, isto é, uma máquina para fazer o papel de cada um dos servidores. O conceito de servidor de Aplicação, Web ou Banco de dados, é um conceito relacionado com a função que o servidor desempenha. Podemos ter, em um mesmo equipamento, um Servidor de aplicações, um servidor Web e um servidor de Banco de dados. Claro que questões de desempenho devem ser levadas em consideração. Resumindo: A arquitetura em 3 camadas original sofre de problemas: A instalação inicial dos programas no desktop é cara O problema de manutenção ainda persiste quando há mudanças à camada de apresentação Não se pode instalar software facilmente num desktop que não está sob seu controle administrativo Em máquinas de parceiros Em máquinas de fornecedores Em máquinas de grandes clientes Em máquinas na Internet Então, usamos o Browser como Cliente Universal Conceito de Intranet A camada de aplicação se quebra em duas: Web e Aplicação Evitamos instalar qualquer software no desktop e portanto, problemas de manutenção Evitar instalação em computadores de clientes, parceiros, fornecedores, etc. Às vezes, continua-se a chamar isso de 3 camadas porque as camadas Web e Aplicação freqüentemente rodam na mesma máquina (para pequenos volumes)

32 Arquitetura em N Camadas Os problemas remanescentes: Não há suporte a Thin Clients (PDA, celulares, smart cards, quiosques, ) pois preciso usar um browser (pesado) no cliente Dificuldade de criar software reutilizável: cadê a componentização? Fazer aplicações distribuídas multicamadas é difícil. Tem que: Implementar persistência (impedance mismatch entre o mundo OO e o mundo dos BDs relacionais) Implementar tolerância a falhas com failover Implementar gerência de transações distribuídas Implementar balanceamento de carga Implementar resource pooling etc. As empresas não querem contratar PhDs para implementar sistemas de informação! O truque é introduzir middleware num servidor de aplicação que ofereça esses serviços automaticamente Além do mais, as soluções oferecidas (J2EE,.Net) são baseadas em componentes As camadas podem ter vários nomes: Apresentação, interface, cliente Web Aplicação, Business Dados, Enterprise Information System (EIS)