Este artigo procura apresentar conceitos de SOA na utilização de integrações de aplicações desenvolvidas em outras plataformas. É realizado um foco mostrando também como WCF é importante no .NET para estas integrações.
Em que situação o tema é útil
Em inúmeras situações existirá a necessidade de se integrarem diferentes sistemas, de maneira que se estabeleçam mecanismos para a transferência de informações entre os mesmos. Tal integração pode não ficar restrita apenas ao ambiente interno de uma companhia, assim como poderão ocorrer casos em que se fará o compartilhamento de dados entre duas ou mais organizações. A adoção de uma arquitetura orientada a serviços (SOA) em cenários que envolvam soluções distribuídas procura, via de regra, garantir a interoperabilidade entre aplicações heterogêneas, bem como maximizar o reuso de componentes de software que correspondam a funcionalidades específicas. Um dos meios de se implementar tal arquitetura, quando se leva em conta a plataforma .NET, é através do uso da tecnologia WCF.
Implementando SOA em WCF
É extremamente comum, dentro de ambientes corporativos, a existência de uma ampla gama de sistemas legados concebidos nas mais diferentes plataformas. Soma-se a isto o fato de que novas soluções são desenvolvidas a cada dia, buscando deste modo satisfazer a diferentes demandas da organização em questão. Diante deste quadro, surgirá inevitavelmente a necessidade de se estabelecer algum meio de integração entre as aplicações de negócio num determinado instante. SOA é um padrão arquitetural que procura fornecer respostas a isto, baseando-se na exposição de funcionalidades como serviços, além de privilegiar o reuso de software e a interoperabilidade entre sistemas. O desenvolvimento de soluções orientadas a serviço dentro da plataforma .NET é feito, normalmente, por meio do uso da tecnologia WCF. Esta última conta com um excelente suporte aos principais padrões que envolvem o uso de serviços, tornando possível com isto a comunicação com aplicações dos mais variados tipos.
SOA (sigla em inglês para Service Oriented Architecture - ou Arquitetura Orientada a Serviços, em português) é um tipo de arquitetura computacional no qual funcionalidades de software são implementadas através de estruturas conhecidas como serviços. Busca-se, através da utilização deste paradigma, a construção de soluções que possibilitem o intercâmbio de informações entre aplicações desenvolvidas muitas vezes nas mais diferentes plataformas (.NET, Java, mainframe, etc.).
Um serviço representa a unidade básica para a construção de um projeto orientado a serviços. Este tipo de estrutura corresponde, por sua vez, a um componente de software dotado de capacidades possíveis de serem consumidas por outras aplicações, estando ligado a um contexto específico de negócio. Capacidades devem ser compreendidas como sendo funcionalidades relativas ao fornecimento de informações ou, ainda, à execução de processos de negócio em atendimento a uma determinada finalidade.
Todos estes tipos de aplicações mencionados encontram-se, normalmente, dispostos em um modelo conhecido como computação distribuída: diversos computadores são empregados na hospedagem das soluções de software existentes.
Importante ressaltar que será quase certa, em um dado momento, a necessidade de se efetuar alguma forma de integração entre tais sistemas, compartilhando assim informações que possuam importância para os softwares envolvidos neste processo.
Arquivos-texto foram um dos primeiros mecanismos utilizados para se estabelecer um meio de comunicação entre aplicações: uma rotina ou processo cuidava da extração dos dados e geração dos arquivos correspondentes, ao passo que um ou mais softwares de destino consumiam as informações resultantes.
Com o advento da Internet e de tecnologias como XML (Extensible Markup Language) surgiram os Web Services. Estes últimos são estruturas que expõem funcionalidades de negócio, com a capacidade de serem consumidas remotamente por outras aplicações, utilizando como maneira para se realizar tal comunicação o protocolo HTTP / HTTPS. Um dos principais meios de se implementar uma Arquitetura Orienta a Serviços consiste justamente na utilização de Web Services.
Além da preocupação com aspectos de cunho técnico, algo comum a qualquer arquitetura de software, os princípios e práticas da abordagem SOA buscam alinhar a atuação da área de tecnologia de uma companhia aos objetivos estratégicos da mesma.
Propondo uma série de recomendações, este modelo computacional procura contribuir para uma maior eficiência, produtividade e agilidade dos departamentos de TI nas organizações, a fim de possibilitar a economia de recursos, esforços e tempo dos envolvidos nos projetos. Para isto existe, dentro da arquitetura SOA, uma grande preocupação com a padronização daquilo que se está construindo, de forma a se aumentar com isto o potencial de reuso das funcionalidades de software concebidas, bem como assegurar a interoperabilidade entre diferentes aplicações.
A ênfase na utilização de padrões não implica, contudo, na adoção de uma única tecnologia para a construção de uma solução. Não é fato raro que a implementação de uma Arquitetura Orientada a Serviços envolva a combinação de plataformas heterogêneas; neste caso, o projeto em questão se dependerá que as tecnologias envolvidas tenham condições de se comunicar entre si.
Observando a necessidade crescente por soluções em SOA com foco na interoperabilidade e no reuso, a Microsoft concebeu a tecnologia WCF como forma de atender a este tipo de demanda. WCF é parte integrante da plataforma .NET, sendo utilizada para a construção de aplicações orientadas a serviço. Um dos grandes benefícios desta tecnologia está na compatibilidade da mesma com uma ampla gama de protocolos de comunicação (HTTP / HTTPS, TCP / IP, dentre outros); graças a esta característica, serviços construídos em WCF podem ser consumidos por aplicações desenvolvidas não apenas em .NET: existe com isso a possibilidade de integração com soluções Java, PHP e mainframe, por exemplo.
Um outro ponto de destaque, ao se considerar a tecnologia WCF, diz à compatibilidade desta com as principais especificações criadas para o uso de Web Services. Tais definições são conhecidas como WS-*, sendo que as mesmas indicam regras para uma série de comportamentos tais como controle transacional, segurança, gerenciamento de estado, etc.
Este artigo tem por finalidade abordar a aplicação de alguns conceitos e práticas de SOA na construção de soluções envolvendo serviços. Para isto, serão discutidos ainda vantagens e pontos de alerta quanto à adoção desta arquitetura. Por fim, serão construídos Web Services de exemplo a partir da tecnologia WCF, buscando-se com isto demonstrar o uso prático das técnicas aqui apresentadas.
O conjunto de padrões chamado de WS-* é resultado do esforço conjunto entre gigantes do mercado de tecnologia (Microsoft, Oracle, IBM, dentre outros). Tal iniciativa busca suportar os heterogêneos ambientes de TI presentes no mundo corporativo, além de possibilitar uma maior aderência dos Web Services construídos a conceitos e práticas de orientação a serviços. Exemplos de especificações deste tipo são os padrões WS-Security (para a utilização de mecanismos de segurança) e WS-Transaction (para controle transacional em operações envolvendo serviços).
Benefícios de SOA
As abordagens propostas por SOA também visam possibilitar uma melhor compreensão e, consequentemente, uma maior organização nos processos de negócio dentro de uma organização. A modelagem de um processo envolverá muitas vezes uma análise acerca de suas características, sendo possível ainda que a solução SOA correspondente introduza melhorias na forma de atuação do mesmo.
O reuso é outro aspecto-chave dentro do paradigma SOA. Equipes de TI com um bom grau de maturidade na aplicação de conceitos de orientação a serviços tendem, durante a atuação em novos projetos ou na evolução de aplicações existentes, a pensar no desenvolvimento de soluções sob uma nova perspectiva. Funcionalidades-chave para o negócio poderão, nestes casos, serem expostas como serviços, de maneira que as mesmas possam ser reaproveitadas futuramente.
A redução de custos é uma das consequências diretas do foco em reuso que SOA propõe. Reaproveitar capacidades pré-existentes permite que se diminuam os custos de manutenção, devido à eliminação de funcionalidades que seriam redundantes ao longo de diversos sistemas. Além disso, recursos financeiros podem ser economizados em novos projetos, com estes últimos tirando vantagem de serviços construídos anteriormente, evitam-se desse modo gastos no desenvolvimento de novas funções de software.
Economia de tempo é outra meta perseguida ao se implementar SOA, sendo que este fator também está diretamente relacionado à questão do reuso. O consumo de funcionalidades já desenvolvidas anteriormente contribui enormemente para se alcançarem menores prazos, flexibilizando o processo de desenvolvimento e tornando mais ágeis as tarefas para construção de novas aplicações.
Pontos de atenção ao se implantar SOA
O contrato de um serviço irá sempre determinar uma dependência entre este elemento e suas aplicações consumidoras. Mediante isto, a introdução de mudanças estruturais em operações já definidas anteriormente ou, ainda, alterações deste gênero em tipos complexos manipulados pelo serviço podem, em muitos casos, comprometer o funcionamento de aplicações que dependam das capacidades envolvidas.
O uso indiscriminado de serviços, através da exposição de quaisquer capacidades por meios desses recursos é algo totalmente desaconselhável. Um erro de compreensão comum ao se implementar o modelo SOA é partir do pressuposto que, daquele ponto em diante, qualquer funcionalidade com valor de negócio deverá ser disponibilizada para outras aplicações que queiram consumi-la. Um processo de análise orientada a serviços busca justamente coibir tal tipo de prática.
Embora a utilização de projetos empregando SOA venha crescendo dentro das organizações, muitos profissionais de TI ainda não dispõem de um bom nível de conhecimento acerca desta arquitetura. Este fato deve ser levado em conta antes do início de um projeto, de maneira que os envolvidos possam contar com os conhecimentos necessários para atuar em projetos que façam uso deste paradigma.
A segurança é outro detalhe que requer cuidados ao se considerar a construção de uma solução orientada a serviços. Dada a natureza distribuída e baseada na comunicação remota por meio de redes para este tipo de aplicação, a situação tende a tornar este tipo de projeto vulnerável a ameaças das mais variadas naturezas (injeção de scripts SQL, de ataques de negação de serviço, tentativas de acesso sem uso autorizado, etc.).
Web Services: uma visão geral
Conforme já mencionado anteriormente, Web Services representam o mais comum artefato técnico empregado na construção de soluções orientadas a serviços. Este tipo de mecanismo permite a integração entre sistemas que compreendam um mesmo padrão pré-estabelecido. Para isto, Web Services expõem em suas definições uma ou mais capacidades (funcionalidades), encapsulando nas mesmas alguma forma de lógica de negócio.
O processo de intercâmbio de informações é estabelecido normalmente de forma online, utilizando para isto algum canal de transmissão (a Internet e uma rede corporativa privada constituem exemplos válidos disto). O desenvolvimento deste tipo de serviço envolve o uso de um variado escopo de recursos tecnológicos. Levando em conta as especificações e padrões suportados, os Web Services podem ser classificados como sendo de primeira ou segunda geração.
Web Services de primeira geração estão fundamentados nas seguintes especificações e protocolos:
• Web Services Description Language (WSDL): padrão XML empregado na descrição da interface de um serviço. A partir do mesmo, aplicações consumidoras podem gerar proxies para assim usar as funcionalidades disponibilizadas via Web Service;
• XML Schema Definition Language (XSD): especificação utilizada na definição (schema) dos diversos tipos de objetos manipulados por um Web Service. Documentos no formato XSD normalmente estão referenciados em descrições WSDL de contratos de serviços;
• SOAP (the Simple Object Access Protocol): formato baseado em XML e empregado no intercâmbio de dados entre aplicações consumidoras e Web Services;
• UDDI (Universal Description, Discovery and Integration): padrão para registro e localização de Web Services;
• WS-I Basic Profile: é uma especificação que visa possibilitar, através de um conjunto de convenções e princípios de orientação geral, a interoperabilidade entre Web Services e soluções que venham a consumi-los.
Já a segunda geração de Web Services originou-se a partir do desenvolvimento das extensões WS-*. Estas definições introduziram diversos aperfeiçoamentos em aspectos como a segurança na utilização de Web Services (WS-Security), controle transacional (WS-Transaction), interoperabilidade entre diferentes plataformas computacionais, etc.
WCF oferece, por meio dos numerosos recursos que a integram, total suporte para a construção de Web Services compatíveis com as especificações de primeira e segunda geração. São exemplos disto os seguintes mecanismos:
• Service contracts: possibilitam a definição da interface para consumo de um serviço, sendo a base para a geração do documento WSDL correspondente;
• Data contracts: são utilizados, basicamente, para a definição da estrutura de tipos de objetos manipulados por um serviço. A partir das instruções especificadas num Data Contract serão geradas as referências XSD indicadas no documento WSDL do serviço;
• Bindings: conjunto de configurações que pode determinar comportamentos de um serviço como formatos de comunicação empregados, níveis de segurança, controle transacional, dentre outras características.
SOA e Web Services
Um erro de percepção bastante comum, quando se leva em conta o desenvolvimento de aplicações compostas por Web Services, é considerar que a solução resultante disto está automaticamente adaptada a uma Arquitetura Orientada a Serviços. Embora a construção de Web Services seja um dos meios de chegar a um resultado que implemente este tipo de arquitetura, SOA por si só é um conceito bem mais abrangente e que não se restringe somente a aspectos técnicos de implementação.
A simples construção de um Web Service utilizando o padrão SOAP ou REST, por exemplo, não implica que o mesmo contará automaticamente com um grande potencial de reuso ou, ainda, que tal serviço tenha sido concebido de uma maneira coesa e que conduza a um baixo acoplamento entre as aplicações que consumirão o mesmo. Toda uma análise se faz necessária ao se implementar SOA em um projeto, de forma que com isto seja possível se aproveitar ao máximo os benefícios técnicos e ganhos estratégicos representados por esta arquitetura.
...
