SlideShare una empresa de Scribd logo
1 de 61
Descargar para leer sin conexión
Universidade Federal de Pernambuco
Centro de Informática
Especialização em Tecnologias da Informação
para Formação
AVALIANDO ARQUITETURAS ORIENTADAS A SERVIÇOS
EM UMA EMPRESA DE TECNOLOGIA DA INFORMAÇÃO
(TI)
por
RODRIGO MINERVINO PEREIRA
Recife, junho de 02
Agradecimentos
Agradeço primeiramente aos meus pais, que me ofereceram tudo o que foi
possível, para que eu me tornasse um pós-graduado com apenas 23 anos, um
especialista em Tecnologia de Informação.
Um agradecimento em especial a minha namorada Evinha (como gosta de
ser chamada), que me ajudou muito na preparação e finalização da monografia.
Ainda mais tendo que me aturar em momentos difíceis e de forte estresse.
Agradeço a minha irmã, tios, primos e minhas avós que sempre me deram
força e sempre acreditaram no meu potencial. Aos meus amigos, que sem eles
nada nessa vida seria possível.
Obrigado ao meu orientador Sérgio Soares, que sempre me cobrou quando
necessário, e me fez produzir uma monografia de boa qualidade.
Agradeço muito ao pessoal da Pitang, local em que trabalho, que mesmo o
projeto estando em fases de finalização, me deu a oportunidade de acabar a
minha especialização. Agradecimento em especial a Flávio Almeida que me
ajudou muito na produção da monografia.
Por fim agradeço a todos aqueles que torcem pelo meu sucesso. “Sucesso
Total e Absoluto” (Flávio Almeida).
Sumário
LISTA DE FIGURAS _________________________________________ V
LISTA DE TABELAS ________________________________________ VI
RESUMO_________________________________________________ VII
ABSTRACT_______________________________________________ VIII
CAPÍTULO 1 INTRODUÇÃO __________________________________9
1.1 Motivação ________________________________________________________________ 9
1.2 Objetivo_________________________________________________________________ 10
1.2.1 Objetivo Geral _______________________________________________________ 10
1.2.2 Objetivos Específicos __________________________________________________ 10
1.3 Organização da monografia ________________________________________________ 11
CAPÍTULO 2 ORIENTAÇÃO A SERVIÇOS______________________12
2.1 Introdução ______________________________________________________________ 12
2.2 Princípios de projeto da Arquitetura orientada a serviços _______________________ 13
2.2.1 Contratos de serviços _____________________________________________________ 13
2.2.2 Acoplamento de serviços __________________________________________________ 15
2.2.3 Abstração de serviços_____________________________________________________ 20
2.2.4 Capacidade de reuso de serviços ____________________________________________ 21
2.2.5 Autonomia de serviço ____________________________________________________ 24
2.2.6 Independência de estado __________________________________________________ 25
2.2.7 Visibilidade do serviço____________________________________________________ 27
2.2.8 Composição de serviços___________________________________________________ 28
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
iv
CAPÍTULO 3 TECNOLOGIAS ________________________________33
3.1 Web service______________________________________________________________ 33
3.2 XML ___________________________________________________________________ 34
3.3 SOAP___________________________________________________________________ 36
3.4 WSDL __________________________________________________________________ 38
3.5 UDDI ___________________________________________________________________ 40
3.6 ESB ____________________________________________________________________ 41
CAPÍTULO 4 IMPLANTANDO SOA EM UMA EMPRESA TI ________43
4.1 Implantação em um novo projeto____________________________________________ 44
4.2 Adaptação dos projetos já em andamentos ____________________________________ 44
4.3 Cenário de implantação de SOA em uma empresa de TI_________________________ 45
CAPÍTULO 5 CONSIDERAÇÕES FINAIS _______________________49
5.1 Contribuições ____________________________________________________________ 50
5.2 Trabalhos futuros_________________________________________________________ 51
5.3 Aprendendo a vender SOA na sua empresa ___________________________________ 52
REFERÊNCIAS_____________________________________________55
ANEXOS __________________________________________________60
Lista de Figuras
FIGURA 1: ALTO ACOPLAMENTO. (VENTURA, 2008). _________________________16
FIGURA 2: WEB SERVICE. (OLIVEIRA E. C., 2009) __________________________34
FIGURA 3: EXEMPLO DE UM ARQUIVO XML. (WIKIPÉDIA, 2010) _________________36
FIGURA 4: EXEMPLO DE UM ENVELOPE SOAP. (WIKIPÉDIA, 2009)_______________37
FIGURA 5: EXEMPLO DE UM WEB SERVICE UTILIZANDO SOAP. (MSDN MICROSOFT,
2003)_______________________________________________________38
FIGURA 6: DIAGRAMA DE UM DOCUMENTO WSDL. (W3C ,2001) ________________39
FIGURA 7: EXEMPLO DA RELAÇÃO DO UDDI ENTRE OUTROS PROTOCOLOS. (OASIS,
2006)_______________________________________________________40
FIGURA 8: EXEMPLO DE UMA APLICAÇÃO SOA UTILIZANDO ESB. (PROGRESS
SOFTWARE, 2010) _____________________________________________42
FIGURA 9: CENÁRIO DE IMPLANTAÇÃO DE SOA PARA GRANDES EMPRESAS. (GARTNER,
2008)_______________________________________________________47
FIGURA 10: CENÁRIO DE IMPLANTAÇÃO DE SOA PARA MÉDIAS E PEQUENAS EMPRESAS.
(GARTNER, 2008) ______________________________________________48
Lista de Tabelas
TABELA 1: PERFIL DO PRINCÍPIO DO CONTRATO DE SERVIÇOS. __________________15
TABELA 2: PERFIL DO PRINCÍPIO DO BAIXO ACOPLAMENTO DE SERVIÇOS. __________18
TABELA 3: RESUMO DOS TIPOS DE ACOPLAMENTO E INFLUÊNCIAS ASSOCIADAS. _____19
TABELA 4: PERFIL DO PRINCÍPIO DA ABSTRAÇÃO DE SERVIÇO. __________________21
TABELA 5: PERFIL DO PRINCÍPIO DA CAPACIDADE DE REUSO DE SERVIÇO. __________24
TABELA 6: PERFIL DO PRINCÍPIO DA AUTONOMIA DE SERVIÇO. __________________25
TABELA 7: PERFIL DO PRINCÍPIO DA INDEPENDÊNCIA DE ESTADO DO SERVIÇO._______27
TABELA 8: PERFIL DO PRINCÍPIO DA VISIBILIDADE DO SERVIÇO. __________________28
TABELA 9: PERFIL DO PRINCÍPIO DA COMPOSIÇÃO DE SERVIÇO. _________________32
Resumo
O grande desafio das fábricas de software é o aumento da produtividade
mantendo o nível de qualidade dos softwares. Os princípios da arquitetura
orientada a serviços (SOA) têm técnicas, que possibilita a percepção do aumento
da produtividade em um espaço curto de tempo.
Grandes estudiosos afirmam que SOA é uma arquitetura conceitual, que
cria serviços com perfis que atendam as suas normas ou princípios. Esses
serviços são criados para retirar, por exemplo, lógicas repetidas onde esta seja
independente e reutilizada. O objetivo desse trabalho é de propor uma solução
arquitetural para aumentar a produtividade e manter a qualidade do software.
O uso de tecnologias no desenvolvimento de SOA, que já são conhecidas
pelo mercado, é fundamental para que esta agilidade na construção seja visível. E
que não passe de mais uma sugestão de melhoria de código (software) sem
sucesso. Contudo é sobre esta arquitetura e seus princípios, que será
apresentado este trabalho.
Palavras-chave: software, serviços, arquitetura orientada a serviços,
princípios.
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
viii
Abstract
The challenge of software factories is increasing productivity while
maintaining the quality of software. The principles of service-oriented architecture
(SOA) are techniques which allow the perception of increased productivity in a
short space of time.
Great scholars argue that SOA is a conceptual architecture, which creates
profiles with services that meet its standards or principles. These services are
designed to remove, for example, where repeated this logic is independent and
reused. The aim of this paper is to propose an architectural solution to increase
productivity and maintain quality software.
The use of technologies in the development of SOA, which are already
known by the market, is key to this speed in construction is visible. And that as just
a suggestion for improving the code (software) without success. But this is about
architecture and its principles, which will be presented this work.
Keywords: software, services, service-oriented architecture, principles.
Capítulo 1 Introdução
Esse capítulo apresenta a motivação e os objetivos deste trabalho,
informando quais os principais problemas encontrados dentro de uma empresa de
tecnologia da informação que incentivou a pesquisa e produção do mesmo. Tem
como foco o aumento da produtividade, ou seja, produzir mais em menos tempo
(Saturino, 2009). Dessa forma visa-se evitar esforços, pois segundo a MSW
Métricas e Software cerca de 50% a 70% dos esforços gastos no programa serão
perdidos após realizar a entrega ao cliente.
1.1 Motivação
A motivação desse trabalho é aumentar a agilidade, a qualidade das
soluções de software, utilizando alguns princípios da arquitetura orientada a
serviços, gerando assim menos bugs e uma maior satisfação dos clientes. Visto
que, é percebido como um dos grandes obstáculos encontrados no
desenvolvimento de software (RD Consultoria, 2009).
“O grande desafio das fábricas de software é produzir atendendo às
necessidades do cliente sob aspectos funcionais e de qualidade, cumprindo
prazos cada vez menores e torná-lo viável aos investimentos dos clientes“
(Saturino, 2009). Atualmente é percebido que as falhas de planejamento, de
construção de software, são apresentadas frequentemente a cada novo projeto.
Mas Segundo Saturino (2009), o processo de software deve ter um mecanismo de
melhorias contínuas, sendo aperfeiçoado a cada novo projeto.
Fábricas de softwares sentem um pouco mais este problema, pois os
projetos são desenvolvidos por equipes diferentes que, em geral, não investem
tempo para discutir os problemas encontrados anteriormente. Devido à pressão
para produzir mais, com melhor qualidade e em um tempo cada vez menor.
Como experiência vivenciada pelo autor desta monografia, percebe-se que
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
10
a agilidade na produção é uma preocupação frequente das equipes de
desenvolvimento. Esta informação sempre está sendo medida e comparada para
avaliar o desempenho do projeto, buscando a satisfação do cliente, que segundo
a RD Consultoria (2009): o cliente é a pessoa mais importante, pois o sucesso e a
própria existência da empresa de software dependem dele.
Pode-se conseguir a satisfação do cliente construindo software de
qualidade que permita a diminuição de erros inesperados, evitando, dessa forma,
desperdiçar tempo com esforços na correção dos erros. Tendo em vista que um
software de qualidade permite que se consiga um aumentando na produtividade
da construção do software. Desta forma uma empresa de TI obtém seu objetivo
satisfazendo seu cliente, entregando os projetos em um tempo hábil.
1.2 Objetivo
A seguir são apresentados o objetivo geral e os objetivos específicos.
1.2.1 Objetivo Geral
O objetivo geral deste trabalho é diminuir o retrabalho das equipes de
softwares; diminuindo os esforços com correções de erros inesperados, causando
uma menor quantidade de horas extras. Ou seja, aumentar a produtividade na
construção de softwares mantendo uma boa qualidade para evitar uma grande
quantidade de erros.
1.2.2 Objetivos Específicos
Aumentar o conhecimento referente à arquitetura orientada a serviços
(SOA) dos colaboradores das organizações de TI, o qual foi um ponto de
dificuldade na pesquisa para a elaboração deste trabalho.
Mostrar tecnologias essenciais no desenvolvimento de SOA, visto que na
produção de software a escolha certa das melhores tecnologias proporciona uma
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
11
melhor construção, baseada no conceito da orientação a serviços.
Sugestão de implantação da arquitetura orientada a serviços, em projetos
novos ou a adaptação em projetos que já estão em andamento, mostrando um
passo a passo de como fazê-la segundo especialistas.
1.3 Organização da monografia
Esta monografia esta organizada da seguinte forma:
No Capítulo 2, Orientação a serviços, são apresentadas as definições
sobre o conceito da orientação a serviços, exibindo todos os seus princípios.
No Capítulo 3, Tecnologias, são apresentadas as definições das
tecnologias mais conhecidas para o desenvolvimento de uma arquitetura
orientada a serviços (SOA).
No Capítulo 4, Implantando SOA em uma empresa de TI, são propostas
algumas maneiras de implantação da arquitetura orientada a serviços de acordo
com a grandeza da empresa e o momento do projeto escolhido.
No Capítulo 5, Considerações Finais, são abordadas as conclusões
tiradas pela pesquisa para produzir a monografia e quais foram às dificuldades
encontradas. Também são exibidos quais os trabalhos futuros esperados e um
passo a passo de como vender SOA.
Capítulo 2 Orientação a Serviços
Nesse capítulo é introduzido o conceito de orientação a serviços e os seus
princípios, que devem ser encarados como boas práticas. Para que os objetivos
citados sejam alcançados e os problemas encontrados corrigidos, é necessário
seguir tais princípios.
2.1 Introdução
Existem alguns mitos referentes ao conceito de SOA. Muitos acreditam que
é uma tecnologia, outros que é uma ferramenta, ou ainda um produto, no entanto
o conceito da arquitetura orientada a serviços segundo Gabriel (2008) diz
respeito:
“A arquitetura orientada a serviços na verdade é um conceito
arquitetural corporativo que permite a criação de serviços
interoperáveis, que podem facilmente ser reutilizáveis e
compartilhados entre aplicações e empresas.”
SOA é utilizada como uma arquitetura de software conceitual que utiliza um
conjunto de características ou princípios, que servem como boas práticas para a
aplicação dentro dos projetos e até mesmo dentro da organização. Tendo em
vista que ambos propõem um meio de alcançar algo com base na experiência ou
na aceitação por todo mercado, segundo especialistas.
Esta estrutura de software implementa serviços aprimorando a eficiência,
agilidade e a produtividade dentro da empresa, reutilizando funcionalidades de
negócios dentro da organização, fazendo com que os serviços sejam os principais
meios das soluções lógicas.
Os serviços são programas de software que são fisicamente independentes
do projeto principal e com características de projeto (design) distintas. Cada
serviço recebe seu próprio contexto funcional e um conjunto de capacidades
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
13
relacionadas a esse contexto. Os contratos de serviços públicos servem para
expor as capacidades dos serviços, ou seja, aquilo que eles estão dispostos a
fazer, para os programas externos (Erl, 2009).
Como citado anteriormente, no que diz respeito às características de SOA,
existem duas que são mais voltadas para a organização das funcionalidades e
serviços, que são a composição e o inventário de serviços, as quais serão
explicitadas na Seção 2.2.8.
Uma implementação SOA, como forma de arquitetura, pode consistir em
uma combinação de tecnologias e produtos, que auxiliarão no desenvolvimento
dos princípios da arquitetura orientada a serviços. Contudo sabe-se que está
combinação de tecnologias e produtos é uma decisão de projeto.
Um projeto que possui vários serviços acoplados à implementação, não
garante que a arquitetura e os negócios sejam orientados a serviços, pois alguns
princípios devem ser seguidos, como exposto na Seção 2.2. No entanto, se faz
necessário que a cultura da organização e as condições financeiras do projeto
sejam favoráveis, para que tanto a arquitetura quanto os negócios sejam
orientados a serviços.
2.2 Princípios de projeto da Arquitetura orientada a
serviços
O princípio de projeto representa, no momento de construir soluções, algo
fundamental para dar forma, da maneira ideal, à lógica (Erl, 2009). Existem oito
princípios básicos, que fornecem regras e diretrizes, que ajudam a determinar
exatamente como a lógica deve ser decomposta e modelada em unidades
distribucionais. Esses princípios serão detalhados nas seções a seguir.
2.2.1 Contratos de serviços
O contrato de serviço é um dos princípios ou normas de modelagem mais
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
14
importantes para a visibilidade, à autonomia e o reuso do serviço, pois são neles
que estão sendo expostas todas as características, ou seja, todas as
funcionalidades que poderão ser usadas por outras aplicações ou serviços.
A abstração de ferramenta e tecnologia, características e limitações, dados
não técnicos, detalhes da implementação, são informações que tornam um
contrato de serviço fundamental para que a aplicação seja capaz de crescer e
modificar sem que haja grandes, ou nenhum, impacto no lado do consumidor de
tais serviços.
Segundo Gabriel (2009), tais contratos são capazes de traduzir com
detalhes a funcionalidade dos serviços específicos para que os clientes possam
buscá-los e utilizá-los conforme sua necessidade. Mas existem algumas
dificuldades:
“Para que todos os detalhes de implementação de um serviço
sejam especificados, são necessários diversos padrões de
contratos a serem utilizados por toda a corporação. Isso pode se
tornar uma tarefa complexa caso haja a necessidade de migração
de documentos (já criados) para o conjunto de padrões
escolhidos.” (GABRIEL, 2009)
Os padrões WSDL (Web Service Description Language), UDDI (Universal
Description Discovery Integration), SOAP (Simple Object Access Protocol) são
muitos utilizados no dia-a-dia e serão explicados com mais detalhes no Capítulo
3. Portanto, um contrato é um documento textual que descreve o que o serviço
faz.
É de grande importância que o desenvolvimento do contrato seja
acompanhado com a construção das funcionalidades do serviço, pois este tende
a evoluir e o contrato deve conter todas as características do mesmo,
considerando possíveis evoluções. Este é um dos maiores riscos encontrados,
pois o controle de versão nem sempre é feito. Outra dificuldade é a deficiência de
ferramentas para o desenvolvimento.
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
15
Segue abaixo a Tabela 1, com o perfil que o serviço tem que ter para
atender o princípio de contrato de serviços, segundo Erl (2009):
Perfil do princípio
Breve definição Serviços compartilham contratos padronizados
Definição completa Cada contrato de serviços deve estar de acordo com
os mesmos padrões de design aplicados a contratos
de outros serviços dentro de um inventário de
serviços.
Objetivos 1. Ativar serviços com um nível significativo da
interoperabilidade natural dentro do limite de um
inventário de serviços. Isso reduz a necessidade
de transformação de dados, por que os modelos
de dados consistentes são utilizados para a troca
da informação;
2. Permitir que o propósito e as capacidades dos
serviços sejam entendidos de maneira mais fácil e
intuitiva.
Característica de design 1. Um contrato de serviços (composto por uma
interface técnica ou um ou vários documentos de
descrição de serviços) deve ser fornecido com o
serviço;
2. O contrato de serviços é padronizado pelo
aplicativo de padrões de design.
Tabela 1: Perfil do princípio do contrato de serviços.
2.2.2 Acoplamento de serviços
Outro princípio de SOA é o acoplamento de serviços. O conceito de baixo e
alto acoplamento ainda sofre por má compreensão, pois não é algo que ouvimos
com tanta freqüência. O alto acoplamento é um serviço que possui uma grande
dependência de outros para que seu fluxo principal funcione, por exemplo, em
uma engrenagem onde para que a mesma funcione é necessário que todas suas
peças estejam trabalhando em conjunto, como ilustra a Figura 1 abaixo:
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
16
Figura 1: Alto acoplamento. (Ventura, 2008).
Um serviço não é apenas acoplado ou desacoplado (Schmelzer, 2007),
existe um grau de granularidade do acoplamento. Um serviço nunca será 100%
desacoplado, mas o desafio é achar o grau de desacoplamento que torne o
serviço flexível para compor outros serviços e com custo não tão elevado
(Schmelzer, 2007).
Um dos principais objetivos de um serviço é que tenha a mínima
dependência com um mundo exterior, ou seja, tenha um baixo acoplamento com
os seus consumidores (Erl, 2009). Para que isso seja possível, é comum utilizar a
tecnologia chamada ESB (Enterprise Service Bus), a qual abstrai a forma de troca
de mensagens feitas pelos sistemas. Usando o ESB, o arquiteto de software
reúne aplicações e componentes integrados para criar conjunto de serviços de
processos de negócios. Por exemplo, existem aplicações de diferentes
tecnologias (.NET, JAVA, PHP e etc.) que se comunicam por diferentes
protocolos, como por exemplo SOAP, RNI, REST e JNI. No entanto essas formas
de comunicação devem ser abstraídas pelo serviço para que, dessa forma, exclua
a dependência do protocolo de comunicação, sendo esta a principal finalidade do
ESB.
O contrato de serviço é fundamental, pois nele será informado qual o
máximo de acoplamento que o serviço terá e quais são os critérios escolhidos
para a utilização da aplicação. É interessante também ter vários contratos,
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
17
diminuindo dessa forma o acoplamento da lógica central, ou seja, formular várias
formas de entradas e saídas de informações.
É importante ter bastante cuidado, pois a busca do menor acoplamento
pode trazer problemas de desempenho e de manutenção, pois as soluções serão
complexas, utilizando soluções reutilizáveis com alguns padrões de projetos
(Gamma, Helm, Johnson, & Vlissides ,2000).
Segunto Erl (2009), quando se busca uma flexibilidade excessiva, é
necessário que a lógica do serviço realize processamento extra, para interpretar
os dados recebidos, por exemplo, aumentando os requisitos de desempenho.
Para atingirmos este baixo acoplamento o serviço deve ter um perfil que
atenda ao princípio de Acoplamento de serviços. Segue a abaixo a Tabela 2 que
ilustra o que foi citado acima (Erl, 2009).
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
18
Perfil do princípio
Breve definição Serviços são fracamente acoplados.
Definição completa Contratos de serviços impõem baixos requisitos de
acoplamento de consumidor e são desacoplados de
seu ambiente adjacente.
Objetivos Ao promover consistentemente um acoplamento
reduzido dentro e entre os serviços, trabalhamos em
direção a um estado em que os contratos de serviços
aumentam a independências com base em suas
implementações, e os serviços são cada vez mais
independentes entre si, Isso promove um ambiente no
qual os serviços e seus consumidores podem evoluir
e se adaptar ao longo do tempo, com impacto mínimo
um sobre o outro.
Característica de design 1. Existência de um contrato de serviços que,
idealmente, é desacoplado dos detalhes de
implementação e tecnologia;
2. Contexto de serviços funcional, que não é
dependente da lógica externa;
3. Requisitos mínimos de acoplamento de
consumidor.
Tabela 2: Perfil do princípio do baixo acoplamento de serviços.
Existem vários de tipos de acoplamentos, mas alguns não são aceitáveis,
pois foge alguns princípios de SOA, segue a Tabela 3, que demonstra esta
realidade (Erl, 2009).
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
19
Tipo de Acoplamento Negativo? Nota
Lógica ao contrato Não O alto acoplamento da lógica de serviços
ao contrato é aceitável e suportado pelo
princípio do contrato de serviço
padronizado.
Contrato à lógica Sim Essa forma de acoplamento não é
recomendável e pode ser evitada pelo uso
de abordagens de design „primeiro o
contrato‟.
Contrato à tecnologia Sim O contrato de serviços é, de maneira
ideal, desacoplado da tecnologia do
fornecedor, e suportado pelo uso de XML
aberto e dos padrões de Web service.
Contrato à
funcionalidade
Sim Este tipo de acoplamento negativo é
evitável pela aplicação do princípio da
capacidade de reuso de serviço, mas
pode ser requerido para certos tipos de
serviços.
Contrato à
implementação
Sim Essa forma de acoplamento não é
recomendável, especificamente em
relação a recursos de implementação
externos e compartilhados.
Consumidor à
implementação
Sim O modelo de design de centralização de
contratos é utilizado especificamente para
evitar esse tipo de acoplamento.
Consumidor ao
contrato
Não Esta é a forma positiva de acoplamento,
mas seu benefício está relacionado a até
que ponto os níveis negativos do
acoplamento de contrato de serviços
foram evitados.
Tabela 3: Resumo dos tipos de acoplamento e influências associadas.
O baixo acoplamento pode influenciar em outros princípios (Erl, 2009),
encorajando a moderação da quantidade e da complexidade do conteúdo técnico
do contrato, e assim permite minimizar os requisitos da dependência de
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
20
consumidor. Além desse o princípio de baixo acoplamento afeta a capacidade de
reuso, autonomia e a visibilidade do serviço.
2.2.3 Abstração de serviços
A abstração de serviço tem como objetivo principal criar uma interface de
comunicação com um mundo exterior, informando quais as entradas e qual o
retorno, caso necessite, a funcionalidade do serviço utiliza. Essas informações
estarão explicitamente contidas no contrato de serviços. Com isso, todo o
desenvolvimento do negócio fica em uma camada completamente isolada de
outros serviços, possibilitando modificações lógicas, ou até mesmo novas
funcionalidades e tornando essas variações invisíveis para os que estão
utilizando. Segundo Gabriel (2009), serviços devem ser tratados como uma caixa
preta.
O serviço deve ter um perfil que atenda a capacidade de reuso, autonomia
e independência de tecnologia, garantindo dessa forma a abstração da lógica, ou
seja, as modificações se tornem transparente para o consumidor do serviço.
Segundo experiência do autor, vivenciada em empresas onde atuou, o mesmo
percebeu que quando não se obtém essa transparência poderá acarretar em
“desgosto” por parte do usuário.
Erl (2009) descreve o perfil que o serviço deve seguir, informando quais as
suas características, objetivos e definições, de acordo com a Tabela 4.
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
21
Perfil do princípio
Breve definição Informações de serviço dispensáveis são abstraídas.
Definição completa Serviços são projetados para limitar informações no
contrato de serviços ao que é realmente necessário
para que o serviço seja funcionalmente útil a
consumidores agora e no futuro. Informações além
das que são publicadas no contratado de serviços são
consideradas privadas e não devem ser
disponibilizadas para a criação de consumidores de
serviço potenciais.
Objetivos Muitos dos outros princípios enfatizam a necessidade
de publicar mais informações no contrato de serviços.
O papel principal desse princípio é manter a
quantidade e os detalhes do conteúdo do contrato
concisos e equilibrados e evitar o acesso
desnecessário a detalhes de serviço adicionais.
Característica de design 1. Serviços abstraem constantemente informações
específicas sobre tecnologia, lógica e função do
mundo exterior – o mundo fora do limite de
serviço;
2. Serviços têm contratos que definem concisamente
requisitos de interação e limitações e outros
metadetalhes de serviço necessários;
3. Fora do que é documentado no contrato de
serviços, as informações sobre um serviço são
controladas ou completamente ocultas dentro de
determinado ambiente.
Tabela 4: Perfil do princípio da abstração de serviço.
2.2.4 Capacidade de reuso de serviços
A capacidade de reuso que o serviço deve ter é fundamental para
aumentar a agilidade do desenvolvimento das aplicações. Não é interessante
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
22
“reinventar a roda”, ou seja, sempre utilizar aquilo que já está pronto, que outra
pessoa já definiu e programou. Para que os serviços sejam reusados, os
contratos de serviços devem ter as informações necessárias e bem claras sobre
as suas capacidades. Segundo Gabriel (2009):
“Um serviço reutilizável é aquele que não carrega particularidades
técnicas de uma implementação ou regra de negócio específica e
é genérico o suficiente para atender outros projetos.”
Os contratos de serviços devem conter todas as informações fundamentais
para que os consumidores possam utilizar suas funcionalidades com confiança.
Por tanto os fundamentos devem ser seguidos para que os riscos e o temor para
a sua reutilização diminuam. Fazer um serviço bastante reutilizável é um
investimento de médio prazo e que demanda tempo e dinheiro e muitas vezes os
investidores não enxergam a sua verdadeira e fundamental importância (Erl,
2009).
A capacidade de reuso é um dos princípios que mais se destaca em um
desenvolvimento de SOA, pois a sua identificação e o seu desenvolvimento
parecem nunca ser possível sair do papel. A Tabela 5 demonstra a definição do
serviço de acordo com o princípio da capacidade de reuso (Erl, 2009).
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
23
Perfil do princípio
Breve definição Serviços são reusáveis.
Definição completa Serviços contêm e expressam lógicas e podem ser
definidos como recursos da empresa.
Objetivos Os objetivos por trás da capacidade de reuso de
serviço estão diretamente associados a alguns
objetivos mais estratégicos na computação orientada
a serviços:
1. Permitir que a lógica do serviço pudesse ser
repetidamente alavancada ao longo do tempo, de
modo que isso possa resultar em um retorno cada
vez maior sobre o investimento inicial de
desenvolvimento do serviço;
2. Aumentar a agilidade do negócio em um nível
organizacional que permita o atendimento rápido
dos futuros requisitos de automação dos negócios
por meio da composição de serviço em larga
escala;
3. Possibilitar a realização de modelos de serviço
agnóstico, ou neutro;
4. Permitir a criação de inventários de serviços com
alta percentagem de serviços neutros.
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
24
Característica de design 1. O serviço é definido por um contexto funcional
agnóstico - A lógica encapsulada pelo serviço
associa-se a um contexto suficientemente
agnóstico para que qualquer cenário de uso possa
ser considerado reutilizável;
2. A lógica de serviço é altamente genérica – A lógica
encapsula pelo serviço é genérico o bastante, o
que permite que ela facilite inúmeros cenários de
uso por diferentes tipos de consumidores de
serviço;
3. O serviço tem um contrato genérico e extensível –
O contrato de serviços é flexível o bastante para
processar uma grande variedade de mensagens
de entrada e saída;
4. A lógica de serviço pode ser acessada
concorrentemente – Os serviços são projetados
para facilitar o acesso simultâneo por múltiplos
programas de consumidor.
Tabela 5: Perfil do princípio da capacidade de reuso de serviço.
2.2.5 Autonomia de serviço
A autonomia de serviço é a capacidade que o serviço tem de se governar,
tendo em vista que dessa forma o mesmo não tem grandes dependências com
outros serviços (Erl, 2009). Embora se pense em um serviço autônomo, o que
esse princípio aborda é que o mesmo deve ter o mínimo de dependência e que a
sua lógica principal seja bastante independente.
O ato de se autogovernar ou autonomia de serviço, pode trazer alguns
benefícios claros, como por exemplo, o desempenho (Erl, 2009). Tendo em vista
que dessa forma se terá o mínimo de dependências com outros serviços e as
execuções das funcionalidades se tornam mais diretas e conseqüentemente o
número de erros inesperados diminui consideravelmente. Essa autonomia é
medida e disponibilizada nos contratos formais, tendo como finalidade esclarecer
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
25
o nível de independência aos seus consumidores.
A Tabela 6 explica com mais detalhes as suas características. (Erl, 2009)
Perfil do princípio
Breve definição Serviços são autônomos.
Definição completa OS serviços aumentaram a confiabilidade e a
previsibilidade comportamental para suportar a
execução autônoma, exercendo um alto nível de
controle sobre a lógica e recursos em runtime.
Objetivos 1. Aumentar a confiabilidade, o desempenho e a
previsibilidade de um serviço em runtime,
particularmente ao ser reusado e composto;
2. Aumentar a quantidade de controle que um serviço
tem sobre o ambiente em runtime.
Característica de design 1. Os serviços têm um contrato que expressa um
limite funcional bem definido, que não deve
envolver outros serviços;
2. Os serviços são implantados em um ambiente no
qual eles exercem muito controle; e
preferivelmente, um nível exclusivo;;
3. As instâncias de serviços estão em um ambiente
que convive com a alta concorrência quanto a
propósitos e escalabilidade.
Tabela 6: Perfil do princípio da autonomia de serviço.
2.2.6 Independência de estado
A independência de estado é quando um serviço não precisa reter nenhum
dado do estado para que outro serviço processe a sua lógica. Podemos citar
como exemplo, o uso do protocolo HTTP. O qual monta seu cabeçalho e todo o
conteúdo da página que é enviada para o navegador (browser), retornando a uma
condição de independência de estado em que ele não retém nenhuma solicitação
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
26
ou memória adicional do browser (Erl, 2009).
Os serviços são projetados para minimizar o período, durante o qual eles
existem em uma condição de dependência de informação de estado, aumentando
a escalabilidade do serviço.
Os contratos de serviços devem ter menos restrições, com a finalidade de
permitir o recebimento e a transmissão de uma grande quantidade de dados de
estado em execução em tempo real (runtime) (Erl, 2009).
O gerenciamento das informações de estado quando é feito dentro do
próprio serviço torna uma abordagem na construção de uma lógica confiável. Pois
é bem mais fácil manter e evoluir um serviço que tenha total controle sobre seu
próprio processamento de estado. Porém quando essa responsabilidade é
transferida há uma arquitetura externa alguns benefícios são claramente
identificados como: o reuso e a divisão de responsabilidades. Mas as
dependências resultantes do design e a opção do controle externo precisam ser
cuidadosamente avaliadas em longo prazo, principalmente.
Outro cuidado fundamental que deve ser observado é a questão do
desempenho em runtime, pois quando são criadas mais camadas há uma
possibilidade de se ter uma sobrecarga de processamento.
A Tabela 7 ilustra com mais detalhes o perfil do serviço para atender o
princípio da independência de estados, expondo as suas características e os
objetivos (Erl, 2009).
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
27
Perfil do princípio
Breve definição Serviços minimizam a dependência de estado.
Definição completa Serviços são explicitamente projetadas para minimizar
o período durante o qual eles existem em uma
condição de dependência de informações de estado.
Objetivos 1. Aumentar a escalabilidade do serviço;
2. Dar suporte ao design de lógica agnósticos e
aprimorar o potencial do reuso do serviço.
Característica de design O que torna a independência de estado de serviço um
princípio quase único é o fato de que ela promove
uma condição do serviço que, por natureza, é
temporária. Dependendo do modelo de serviço e da
abordagem de diferimento de estado utilizados,
diferentes tipos de características de design podem
ser implementados.
Tabela 7: Perfil do princípio da independência de estado do serviço.
2.2.7 Visibilidade do serviço
A visibilidade do serviço, como o nome já diz, tem como objetivo principal
fazer com que o serviço se torne visível a todos, aumentando assim a agilidade, a
produtividade e a confiabilidade dos consumidores. Os serviços são projetados
para que sejam encontrados e seus propósitos e capacidades sejam claramente
entendidos, ou seja, os contratos de serviços devem ter metainformações extras
que transmitem claramente o que o serviço realmente faz (Erl, 2009).
A aplicação desse princípio após a implantação de um serviço pode
comprometer a qualidade da sua visibilidade, portanto é uma boa prática
adicionar as metainformações antes do lançamento da versão inicial.
Existe um protocolo que especifica um método para publicar e descobrir
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
28
diretórios de serviços em uma arquitetura orientada a serviços, que é conhecido
como UDDI (Universal Description, Discovery Integration) que será abordado no
Capítulo 3.
A visibilidade de serviço afeta alguns outros princípios, mas afeta
principalmente a capacidade de reuso. Os serviços ou funcionalidades devem ser
encontrados, é necessário que sejam flexíveis e que seus propósitos e
capacidades sejam claros para que outros possam utilizá-los. Erl (2009) também
afirma que:
“Alcançar esse objetivos requer a previsão e uma boa
compreensão da natureza do próprio serviço. Dependendo do tipo
do modelo de serviço que é projetado, perceber esse princípio
pode exigir perícia nos negócios, assim como perícia técnica.”.
A Tabela 8 destaca estas características segundo a visão de Erl (2009).
Perfil do princípio
Breve definição Serviços são visualizáveis.
Definição completa Os serviços são projetados para serem efetivamente
descobertos e interpretados para que, na descoberta,
seu propósito e capacidades sejam claramente
entendidos.
Objetivos 1. Os serviços são posicionados como recursos
altamente visualizáveis dentro da empresa;
2. O propósito e capacidades de cada serviço são
claramente expressos para que eles possam ser
interpretados.
Característica de design
Tabela 8: Perfil do princípio da visibilidade do serviço.
2.2.8 Composição de serviços
A composição de serviços permite que as capacidades de um serviço
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
29
sejam combinadas várias vezes com as de outros serviços em novas
configurações a fim de resolver problemas diferentes. Por exemplo, um serviço
que tem como entrada o CEP e informa qual o endereço de destino, utilizando um
serviço dos correios. Também informando qual o melhor custo benefício na
cobrança do frete, o que corresponde a outro serviço dos correios. Portanto, a
composição desses serviços soluciona um determinado problema, mas esses
serviços estando isolados e postos em outras composições solucionariam outros
tipos de problemas.
Os serviços devem ser quebrados ou decompostos em unidades menores,
para aumentar a capacidade de reuso e solucionar um número maior de
problemas de forma mais ágil e eficiente.
Na composição de serviços quando é formada em grandes escalas, com
muitos serviços, deve-se ter uma atenção voltada aos pontos que podem ter um
custo excessivo de tempo, pontos estes que se assemelham a um “gargalo”. Visto
que o desempenho do serviço controlador que encapsula uma composição de
diversos serviços adicionais, será sempre determinado pela sua composição.
Contudo para tentar evitar que gere este “gargalo” é importante entender
com mais detalhes e precisão as definições e características deste princípio,
portanto segue abaixo a Tabela 9 que expõe algumas informações importantes
segundo Erl (2009).
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
30
Perfil do princípio
Breve definição Serviços são componíveis
Definição completa Serviços são projetados para que atuem como
participantes eficazes de uma composição,
independente do tamanho e da complexidade da
composição.
Objetivos Ao discutir os objetivos da composição de serviços,
boa parte dos objetivos de reúso de serviços também
é aplicável. Isso ocorre porque, muitas vezes, a
composição de serviços é uma forma de reúso de
serviços. De fato, talvez você se lembre de que um
dos objetivos que selecionamos para o principio da
capacidade de reúso era possibilitar a composição de
serviços em larga escala.
Contudo, além de simplesmente alcançar o
reúso, a composição de serviços fornece o meio pelo
qual podemos alcançar o que muitas vezes é
classificado como o objetivo final da computação
orientada a serviços. Ao estabelecer uma empresa
composta de lógica representada por um inventário de
serviços altamente reusáveis, fornecemos o meio
para que uma grande extensão dos futuros requisitos
da automação de negócios sejam cumpridos por meio
da composição de serviços.
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
31
Característica de design
para capacidade de
membros de uma
composição
Idealmente, cada capacidade de serviço,
especialmente aquelas que fornecem lógica reusável,
é considerada um membro potencial de uma
composição. Isso significa essencialmente que as
características de design já estabelecidas pelo
princípio da capacidade de reúso de serviços são
igualmente relevantes para criar membros de
composição eficazes.
1. O serviço precisa possuir um ambiente de
execução altamente eficiente. Além de ser capaz
de gerenciar a simultaneidade, a eficiência com a
qual os membros da composição realizam o
processamento individual deve ser bem
sintonizada.
2. O contrato de serviços precisa ser flexível, para
que possa facilitar diferentes tipos de requisitos de
troca de dados para funções semelhantes. Isso se
relaciona tipicamente a capacidade do contrato de
trocar o mesmo tipo de dados em diferentes níveis
de granularidade.
A maneira como essas qualidades ultrapassam o
mero reúso tem a ver principalmente com o fato de o
serviço ser capaz de otimizar o processamento em
runtime para dar suporte a várias composições
simultâneas.
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
32
Característica de design
para capacidades do
controlador de
composição
Os membros de uma composição, muitas vezes,
também precisam atuar como controladores ou
subcontroladores em diferentes configurações de
composição. Contudo, as exigências de alto
desempenho impostas aos membros de composição
geralmente são reduzidas aos serviços que são
projetados como controladores.
Esses tipos de serviços possuem, portanto, um
conjunto próprio de características de design, a saber:
1. A lógica encapsulada por um controlador quase
sempre está limitada a uma tarefa de negócios
exclusiva. Comumente, é utilizado o modelo de
serviço-tarefa, que resulta na aplicação de
características comuns a esse modelo de serviços;
2. Embora os controladores possam ser reusáveis,
normalmente o reuso de serviços não é uma
consideração primária do design. Portanto, as
características de design promovidas pela
capacidade de reuso de serviços são
consideradas e aplicadas onde apropriado, mas
com menos rigor do que o habitualmente aplicado
a serviços agnósticos;
Naturalmente, qualquer capacidade que atue como
controlador pode se tornar membro de uma
composição maior, o que também leva em
consideração as características de design de membro
de composição anteriormente listadas.
Tabela 9: Perfil do princípio da composição de serviço.
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
33
Capítulo 3 Tecnologias
Neste capitulo será citado e definido o conceito das tecnologias mais
utilizadas na construção da Arquitetura orientada a serviços (SOA).
SOA tem como boa prática, a utilização de tecnologias já conhecidas no
mercado. Web service é uma das tecnologias que torna um serviço disponível na
grande internet, por exemplo. Vamos agora detalhar sobre algumas tecnologias
utilizadas no mundo dos serviços.
3.1 Web service
Segundo Sonda & Montez (2004), “Tecnologias de Web Services surgiram
recentemente como uma resposta à busca de interoperabilidade entre aplicações
que oferecem serviços na web”.
“Os Web services são na essência interoperabilidade-conectando
programas e aplicações a outros programas e aplicações, especialmente quando
estes são desenvolvidos usando diferentes linguagens, ferramentas ou
plataformas” (Oliveira E. C., 2009). Segundo Gartner:
“Web services são componentes de software com baixo fator de
desacoplamento, utilizado por meio de padrões de internet. Um
web service representa uma função de negócio ou um serviço que
pode ser acessado por uma outra aplicação, sobre redes públicas
e, geralmente, disponibilizado por protocolos conhecidos.”
O Web service (Figura 2) é baseado em vários padrões de tecnologias
XML, SOAP, WSDL e UDDI que revolucionaram a comunicação na web.
Basicamente o Web service é o intermediador entre as aplicações, independente
de qual plataforma esteja sendo utilizada. Um serviço web utilizando essas
tecnologias podem ser processados em uma internet, intranet ou em qualquer
outro tipo de rede, mas que use endereçamento IP.
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
34
Em Engenharia de software, Sommerville (2007, p. 189) diz que um Web
service é uma instância de uma noção mais geral de um serviço e, cita a definição
proposta por Loverlock como:
“Uma ação ou desempenho oferecido de um grupo para outro.
Embora o processo possa estar ligado a um produto físico, o
desempenho é essencialmente intangível e não resulta
normalmente em prioridade de algum dos fatores de produção”.
Figura 2: Web Service. (Oliveira E. C., 2009)
3.2 XML
XML é uma linguagem de marcação para necessidades especiais, diferente
do HTML (Wikipedia, 2010) que foi feito para Web e já tem suas tags pré-
definidas. O XML (Figura 3) pode ser utilizado em vários contextos de aplicações
e não existe tag pré-definidas. É um subtipo de SGML (acrônimo de Standard
Generalized Markup Language, ou Linguagem Padronizada de Marcação
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
35
Genérica) capaz de descrever diversos tipos de dados. Segundo o W3C, o criador
do XML, sua principal característica é criar uma infra-estrutura única para diversas
linguagens, para que linguagens desconhecidas e de pouco uso também possam
ser definidas sem maior trabalho e sem necessidade de serem submetidas aos
comitês de padronização.
A W3C em meados da década de 1990 começou a trabalhar em uma
linguagem que tivesse a flexibilidade da SGML e com a simplicidade do HTML. O
princípio do projeto era criar uma linguagem que pudesse ser lida por software, e
integrar-se com as demais linguagens. Sua filosofia seria incorporada por vários
princípios importantes:
1. Separação do conteúdo da formatação
2. Simplicidade e Legibilidade, tanto para humanos quanto para
computadores
3. Possibilidade de criação de tags sem limitação;
4. Criação de arquivos para validação de estrutura;
5. Interligação de banco de dados distintos;
6. Concentração na estrutura da informação, e não na sua aparência.
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
36
Figura 3: Exemplo de um arquivo XML. (Wikipédia, 2010)
3.3 SOAP
SOAP, vem do inglês Simple Object Access Protocol, é um protocolo para
troca de informações, utilizando tecnologias baseadas em XML (W3C). O SOAP
tem segundo a Wikipédia (2010):
1. Mecanismo para definir a unidade de comunicação;
2. Mecanismo para lidar com erros;
3. Mecanismo de extensão que permite evolução;
4. Mecanismo entre SOAP e o HTTP, representar tipos de dados em
XML.
A estrutura básica do SOAP é o envelope que contem as informações a
serem enviadas ao servidor. O cabeçalho que pode conter alguns dados como
namespace. O cabeçalho fica dentro do envelope. Encontrando-se também neste
envelope o body. No body contém o documento que tem as informações a serem
trocadas com o servidor, quais serviços deseja executar e o fault (falha), que
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
37
retorna uma mensagem de status do retorno da requisição como mostra a Figura
4 abaixo:
.
Figura 4: Exemplo de um envelope SOAP. (Wikipédia, 2009)
O processo de comunicação SOAP tem seu início a partir do momento em
que o cliente (Client) envia os dados, que através do HTTP são enviados para o
servidor (Web Server) em uma estrutura pré-definida. Logo após o servidor
receber esses dados, o mesmo faz todo o processo de verificação e processando
assim as informações. Depois o servidor retorna os dados em uma estrutura
SOAP. A Figura 5 ilustra este cenário com mais detalhes.
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
38
Figura 5: Exemplo de um web service utilizando SOAP. (MSDN Microsoft, 2003)
3.4 WSDL
O WSDL (Web Services Description Language) é o contrato onde estará
toda a estrutura que o XML deve ser montado, para que o serviço requisitado
entenda o que se deseja, os dados com que vão trabalhar e em qual estrutura
deve ser enviado o retorno ao consumidor.
A definição do WSDL segundo o W3C (2001) é:
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
39
“WSDL é um formato XML para descrever serviços de rede como
um conjunto de parâmetros operacionais sobre as mensagens que
contenham qualquer documento orientado ou procedimento de
informação orientada. As operações e mensagens são descritas
abstratamente, e em seguida, vinculado a um protocolo de rede
de concreto e formato de mensagem para definir um ponto de
extremidade. Parâmetros concretos são combinados em
parâmetros abstratos (serviços). WSDL é extensível para permitir
a descrição dos parâmetros e suas mensagens,
independentemente dos formatos que mensagem ou protocolos
de rede são usados para comunicar-se...”
A Figura 6 ilustra um diagrama em XML, de um documento WSDL 2.0
segundo a W3C (2001):
Figura 6: Diagrama de um documento WSDL. (W3C ,2001)
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
40
O WSDL faz o intermédio entre o SOAP com o cliente e o SOAP com o
servidor. O SOAP manda os dados para o WSDL e ele interpreta os dados
montando assim um XML, que faça com que o cliente e servidor, entendam as
informações solicitadas e retornadas.
3.5 UDDI
Definimos UDDI como um protocolo que define um método padrão para a
publicação e descoberta da rede, baseada em componentes de software de uma
arquitetura orientada a serviços aprovada pelos padrões OASIS (2006) que é um
membro importante na linha de Web services.
UDDI é como um catálogo de serviços que o servidor dispõe. Lá são
mostrados quais serviços tem no servidor, os quais são permitidos de acordo com
a regra de restrições.
A relação conceitual entre UDDI e outros protocolos, na pilha de serviços
da Web, é ilustrada na Figura 7 abaixo (OASIS, 2006):
Figura 7: Exemplo da relação do UDDI entre outros protocolos. (OASIS, 2006)
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
41
Basicamente o servidor publica via SOAP no UDDI os serviços que ele
tem. A camada SOAP do UDDI interpreta e armazena a descrição dos serviços,
pois quando o cliente solicitar uma lista de serviços, que ele possa utilizar, será
retornado via SOAP ao cliente, a qual poderá ser utilizada.
3.6 ESB
ESB (Enterprise Service Bus) serve como um intermediador entre serviços.
Ele se comunica com os serviços, independente de qual plataforma é usada. Não
importa se seja um serviço em Java solicitando outro serviço em PHP. O ESB
deixa transparente a troca de informações entre eles.
O uso da tecnologia ESB seria uma boa solução em, por exemplo, uma
empresa que tenha um sistema desenvolvido em uma plataforma, que tenha um
protocolo de comunicação diferente com o qual irá interagir. De início pode-se
utilizar de outras formas mais simples para realizar essa troca de informações,
mas supondo que após algum tempo, deve-se fazer integrações entre outros
serviços com protocolos diferentes. Por tanto para haver essa comunicação entre
aplicações ou serviços, cada um deverá desenvolver diversos tipos de protocolos,
para atender qualquer tipo de requisição SOAP.
Pesando em uma forma de centralizar o desenvolvimento de diversos tipos
de protocolos para as trocas de informações, utiliza-se a tecnologia ESB. A qual é
responsável pelo transporte dos dados de maneira assíncrona e síncrona. Sendo
esta responsável por mandar as informações para seu destino, interpretar,
processar e tratar as informações a serem retornadas como mostra a Figura 8.
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
42
Figura 8: Exemplo de uma aplicação SOA utilizando ESB. (Progress Software, 2010)
Neste exemplo, a ESB está fornecendo a conectividade com o roteamento
entre os serviços; a transformação de dados XML, a qual permite a comunicação
dos serviços com diferentes interfaces; e o processo de sequenciamento de
negócios de serviços (Progress Software, 2010).
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
43
Capítulo 4 Implantando SOA em uma empresa TI
Neste capítulo serão abordadas sugestões baseadas em pesquisas de
especialistas na implantação da arquitetura orientada a serviços, ou seja, SOA. A
implantação da arquitetura orientada a serviços dentro de uma empresa de
tecnologia da informação trata-se um trabalho árduo e deve ser muito bem
estudado.
O primeiro passo que toda empresa, a qual tenha como objetivo de adotar
o conceito de SOA dentro de sua organização é capacitar seus colaboradores ou
contratar pessoas já capacitadas. Este ponto é bastante conflituoso, pois a
capacitação dos funcionários estará abrindo novas portas para o mercado vizinho
e novas oportunidades aparecerão. Contudo, sem essa formação dos envolvidos
a possibilidade de sucesso é muito remota e uma coisa é certa, pensar e produzir
orientada a serviços não é simples e nem comum. Visto que um paradigma novo
sempre demonstra dificuldades.
Depois de todos os colaboradores estarem preparados, deve ser escolhido
um projeto piloto para a aplicação do conceito de SOA e posteriormente expandi-
lo para toda a organização.
Um ponto importante que deve ser levantado na transição para o conceito
de orientação a serviços no projeto piloto, é definir as responsabilidades de cada
um, pois para uma tarefa tão complexa não cabe apenas aos desenvolvedores,
ou analista, ou gerentes de negócios pensarem e definirem este novo conceito de
arquitetura.
Para a implantação ter sucesso todos os papéis acima citados devem
participar dentro de sua capacidade, ou seja, os desenvolvedores ficarão
envolvidos sobre os problemas tecnológicos e as melhores escolhas, os analistas
referentes às definições de negócios de design, enfim cada a um será incumbida
uma responsabilidade.
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
44
Para os projetos que já estão em andamento essa transição se torna um
pouco mais complexa, tendo em vista que tudo já está definido e um maior re-
trabalho será inevitável. No entanto existe esta possibilidade e a mesma será
abordada neste capítulo.
4.1 Implantação em um novo projeto
Quando a organização define que irá aderir ao SOA, é preciso se ter a
certeza que novos projetos nascerão baseados nessa arquitetura. As pessoas
que ficarem responsáveis por desenhar a arquitetura do projeto devem ter o
projeto de SOA em mente. (Ângelo, 2005)
É interessante que o sistema piloto escolhido seja simples e que suas
funcionalidades, que farão parte do serviço na arquitetura orientada a serviços,
tragam em um pequeno espaço de tempo benefícios para a organização, ou seja,
que sejam utilizadas por outros sistemas e / ou projetos. Essas funcionalidades
devem ser de fácil desacoplamento da apresentação.
A escolha deste piloto é de extrema importância para a visualização, da
diretoria da companhia, dos benefícios trazidos. Estes ganhos com a implantação
de SOA é notada rapidamente pela garantia de longevidade que o sistema ganha
e em médio prazo a empresa vai alcançar uma alta produtividade no
desenvolvimento.
Uma dica boa para a identificação das funcionalidades do sistema piloto,
chaves para a implantação, é transformar alguns componentes, que já são
utilizados em várias partes da própria aplicação e que claramente poderão ser
utilizados por outros, em serviços.
4.2 Adaptação dos projetos já em andamentos
É recomendado que as organizações comecem a implantar SOA aos
poucos, podendo ser feita em etapas assim que as demandas forem surgindo.
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
45
Deve ser aplicado inicialmente em processos críticos, onde a lógica de negócios
possa ser facilmente desagregada da parte da apresentação.
Existem inúmeras situações em que projetos já em andamentos,
necessitem adotar SOA. Porém sempre deve ser levada em consideração se há a
possibilidade desta adaptação na arquitetura atual do sistema. Um design bem
feito torna esta adaptação um pouco mais simples. Se a escolha da mudança de
arquitetura não foi feita pela equipe de desenvolvimento por necessidade do
projeto ou pelo cliente e sim uma mudança de paradigma da empresa. Então este
projeto deve ser um experimento para futuras estimativas e definições das
melhores tecnologias.
Implantar SOA é um desafio muito grande para a organização, maior até do
que o desafio técnico. Portanto deve haver um alinhamento entre as tecnologias
utilizadas e os objetivos de negócio da empresa.
Para ter uma abstração das formas de comunicação das aplicações e
serviços, deve ser implementado o Enterprise Service Bus (ESB) fazendo com
que tecnologias e ferramentas fiquem irrelevantes.
4.3 Cenário de implantação de SOA em uma empresa de
TI
Neste capítulo vamos abordar as fases da implantação do conceito de
SOA, dentro da organização, utilizando com boas práticas de governança.
Segundo Zaidan (2009) a revista Decision Report “A implementação correta
com boas práticas de governança a reutilização dos serviços implementados pode
atingir mais de 80% de reuso. Isso, consequentemente, maximiza o retorno sobre
o investimento”. Atingir estes 80% equivale a uma probabilidade muito remota,
comparada com as arquiteturas tradicionais. Segundo a revista Decision Report
(Zaidan, 2009), “No Brasil, um dos projetos que foi implementado no setor de
telecomunicações houve 65% de reutilização dos serviços”.
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
46
Como foi dito antes é fundamental a migração ser feita por etapas, pois se
não, pode trazer sérios problemas, por exemplo, alteração de uma só vez o dia-a-
dia de todos os funcionários de desenvolvimento; a existência de muitos sistemas
para serem alterados não sendo possível a concentração dos esforços nos
detalhes necessários.
Pelos casos já reportados de projetos que grandes números de sucesso
são feitos em fases, primeiro capacitando os funcionários, depois escolhendo um
projeto piloto, realiza a migração e observa o funcionamento para no futuro repetir
esses mesmos procedimentos para o resto dos projetos da empresa.
A figura 7 representa as etapas de migração para SOA, que segundo
Gartner (2008) é o cenário ideal para empresas grandes com muitos sistemas
distribuídos, utilizando a prática de governança. A primeira etapa é pouco longa e
difícil, que consta na definição do projeto piloto e na construção de serviços, que
já tragam ganhos. SOA inicialmente não trará retorno sobre o investimento, pois a
reutilização só aparecerá nos próximos sistemas, então o CIO deve selecionar
pilotos que tragam mais benefícios de negócios.
A segunda fase é a mais longa, pode durar até quatro anos, dependendo
da infra-estrutura e da maturidade do processo da empresa. É nesta fase que
colocarão os experimentos do projeto piloto em construção em todos os outros
existentes na organização. Este tempo de quatro anos é relativo, pois dependente
muito de quantos projetos irá fazer a migração e suas complexidades. Neste
momento é fundamental a criação do repositório de serviços, pois é a partir dele,
que serão encontradas as funcionalidades ou os serviços que serão reutilizados
por outras aplicações.
Ao final dessa etapa chega-se a um bom cenário organizacional: serviços
estão implantados, existe reaproveitamento, controle do ambiente, registro de
serviços e políticas de governança implantadas. Neste ponto a organização
começa a perceber que os novos projetos começam a serem mais ágeis, baratos
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
47
e com menos chances de problemas, ou seja, quanto maior for o nível de
reutilização, menor o desenvolvimento e os problemas.
A última fase é o cenário estável da organização, os sistemas existem com
conceitos de serviços, todos estão no repositório. Não existem serviços
duplicados e existe alta taxa de reuso. Nesta fase deve-se pensar no futuro, por
exemplo, novos serviços devem seguir o processo de desenvolvimento e as
políticas organizacionais. A utilização de serviços deve ser feita via repositório
com um contrato formal de prestação de serviço. Isso tudo se aplica para grandes
empresas (Gartner, 2008).
A ilustração das definições das etapas de implantação segundo Gartner
(2008) segue abaixo:
Figura 9: Cenário de implantação de SOA para grandes empresas. (Gartner, 2008)
Para empresas de médio porte, sugere-se a utilização também de um
piloto, mas que ele seja utilizado como experimento onde possam ser
exaustivamente repetidas as ações de migração para cada área da empresa.
Posteriormente devem ser analisados os resultados das ferramentas escolhidas e
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
48
dos sistemas pilotos.
A segunda etapa é a implantação no setor onde foi feito o piloto
anteriormente, depois sendo repetido o processo para cada área da empresa
quantas vezes forem necessário.
A última etapa, da mesma forma que o modelo anterior, é quando a
organização já está com a toda a política de governança definida e os serviços
implantados. O importante é garantir que os colaboradores da organização sigam
as políticas definidas, para que não haja, por exemplo, serviços repetidos.
Figura 10: Cenário de implantação de SOA para médias e pequenas empresas. (Gartner,
2008)
As propostas mostradas neste trabalho não irão atender ou não serão
ideais para todas as empresas, pois é necessária uma análise mais aprofundada
para cada situação.
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
49
Capítulo 5 Considerações finais
Neste capítulo serão abordadas as considerações finais para aumentar o
embasamento, e as dificuldades encontradas para a criação e confecção deste
documento. O conceito da orientação a serviços, ou melhor, da arquitetura
orientada a serviços, de implantar nos projetos, é mais uma tentativa de melhoria
para ajudar as empresas de tecnologia da informação em aumentar a
produtividade, a qualidade de softwares e posteriormente a satisfação dos
clientes. Visto que as empresas que vivem de projetos devem sempre assistir.
Uma coisa é certa, SOA não realiza nenhum milagre e não é a solução de
todos os problemas. Fazendo apenas uma analogia referente a processos, que
hoje em dia todos os projetos querem utilizar a metodologia Scrum achando que é
a solução dos problemas de atrasos, de falhas de planejamento, que segundo
Schwaber (2004) – principal formalizador da metodologia – Scrum é:
"... o mais perplexo e paradoxal processo para gerenciamento de
projetos complexos. Porém, Scrum é incrivelmente simples. [...]
Scrum não é um processo prescritivo; ele não descreve o que
fazer em cada circunstância. Ele é usado para trabalhos
complexos nos quais é impossível predizer tudo que irá
acontecer.".
Esta mesma falta de conhecimento se encaixa com SOA, que os leigos
acreditam que irá solucionar o problema de códigos mal feitos, de bugs, de
atrasos.
Já é comprovado que SOA é um conceito de sucesso, mas deve ser muito
bem estudado antes de ser utilizado e que necessita de uma maturidade de
arquitetura, design e análise muito grande da equipe.
Algumas dificuldades nas realizações da pesquisa para o desenvolvimento
deste documento foram encontradas. Encontrar profissionais engajados neste
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
50
conceito é complicado.
Para este trabalho foi criado um questionário para levantamento de
soluções para alguns princípios e que menos de 16,66% das pessoas foram
capazes de respondê-lo por inteiro. Então talvez a primeira etapa ou barreira que
as empresas devem enfrentar seja a qualificação dos seus funcionários em
treinamentos e palestras; para que a equipe não “mate” SOA e SOA não “mate” o
projeto.
5.1 Contribuições
Neste trabalho foi apresentado um estudo de implantação do conceito da
arquitetura orientada a serviços – SOA – que mesmo sendo aplicada em uma
arquitetura definida. Espera-se que seja possível ser aplicado em praticamente
qualquer projeto de uma fábrica de software, sabendo de algumas limitações
técnicas e dos clientes. A seguir, uma síntese da proposta oferecida de
implantação de SOA:
1. Identificar ou contratar funcionários capacitados para a implantação
ou capacitá-los, afim de que esta mudança seja um caso de sucesso
e não um investimento perdido;
2. Depois de ter uma equipe capacitada deve ser identificado um
projeto ou sistema piloto que servirá como experimento de mudança,
obtendo dados para estimativas e informações sobre melhores
tecnologias;
3. Identificação de funcionalidades estratégicas, que trarão ganhos
importantes e rápidos para a organização;
4. Os responsáveis devem se reunir e identificar os riscos dessa
mudança e levantar as ações que deverão ser tomadas;
5. Implementar o conceito de SOA nas funcionalidades escolhidas;
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
51
6. Depois de ter finalizado o desenvolvimento da aplicação piloto, vem
o momento mais crucial, identificar novas funcionalidades de
projetos em andamento ou já concluídos;
7. Transformação dessas novas funcionalidades em serviços,
utilizando o conceito de SOA e o adaptando nos projetos desejados.
Em projetos que já estão concluídos, só deve ser feito esta
modificação com a permissão do cliente em questão, pois pode
gerar novos erros;
8. Por fim, institucionalizar a nova arquitetura e capacitar todos os
funcionários que estarão envolvidos.
5.2 Trabalhos futuros
Como trabalho futuro, sugere-se que as fábricas de softwares capacitem os
seus funcionários e comecem a criar projetos pilotos, aplicando o conceito da
orientação de serviços, tendo como base neste trabalho de pesquisa que foi
realizado. A partir disto será possível fazer um aperfeiçoamento das arquiteturas,
pensando no reaproveitamento de código e diminuindo o retrabalho.
Com esta idéia de SOA, poderão surgir novos produtos dentro da
organização, pois a idéia de desvincular as funcionalidades da camada de
apresentação facilita nessa identificação. Afirmo isso por experiência própria, pois
existe um sistema na empresa em que trabalho. Pois da maneira que foi
implementado e imposto pelo cliente fica complicada a extração de um produto.
No entanto se desde o início tivesse a mentalidade da orientação a serviços, com
certeza a criação e a identificação deste produto seriam certas.
Espero que em trabalhos futuros tenha a oportunidade de arquitetar um
projeto adotando o conceito de SOA, sendo o piloto. Esperando que
posteriormente este conceito seja difundido em toda a organização, podendo dar
consultorias em empresas que pretenderão fazer o mesmo.
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
52
Pretendo também difundir uma idéia de criação de serviços para as
ferramentas de persistências modelos relacionais. Os frameworks ou aplicações
não se preocupariam em implementar a conexão, o modo de persistir, log de
sistemas e sim seria apenas configurações que o serviço disponibilizaria. Com
isso evitaria alguns erros que acontecem sempre em todos os projetos. É uma
idéia que ainda não foi bem fundamentada, mas que pretendo me inteirar mais e
saber se existe viabilidade para o mesmo.
5.3 Aprendendo a vender SOA na sua empresa
O lema ou o grande desafio das empresas de tecnologia da informação é
diminuir os custos e aumentar a agilidade. Então a Arquitetura Orientada a
Serviços (SOA) vem para superar esses desafios e colocar “um ponto final” nesta
preocupação.
Mas nos profissionais técnicos, não sabemos vender essa idéia para nossa
própria empresa, principalmente referindo-se ao fato de que os benefícios de SOA
não se podem dispor.
É necessário mostrar para os diretores da sua empresa os benefícios que
esta nova arquitetura trará, segue a lista abaixo:
1. Redução do desenvolvimento duplicado
2. Simplificação da integração entre aplicações
3. Aumento da qualidade das funcionalidades
4. Redução do custo de manutenção das aplicações
5. Flexibilidade na alteração de processos de negócio
6. Agilidade na análise de impacto
7. Conhecimento dos ativos existentes
E segundo um artigo de Kleber Bacilo (2009) algumas métricas para
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
53
usarmos no cálculo da economia:
1. Reuse Cost Avoidance: trata-se do quanto a empresa economiza por
não ter que desenvolver novamente as mesmas funcionalidades.
Digamos que para construir um determinado serviço foram
necessárias 100 horas. Cada vez que se reutilizar esse serviço,
praticamente 100 horas – ou pelo menos uma parte delas – serão
economizadas.
2. Consistency: a mesma lógica de negócio desenvolvida várias vezes
pode causar comportamentos diferentes dependendo da aplicação
e, sempre que muda, é necessário mudar em todos os locais onde
esteja implementada.
3. Maintenability: uma parte significativa do orçamento de TI é gasta
apenas mantendo as aplicações existentes funcionando. Redução
nos custos de manutenção com integrações mais fáceis de manter e
componentes isolados sendo reutilizados, e com nível de qualidade
já atestada, impactam de forma muito positiva o uso racional dos
recursos de TI.
4. Agility: Conseguir fazer a análise de impacto mais rapidamente e
promover mudanças nas aplicações e processos de negócios no
tempo demandado pelas áreas de negócio é uma argumentação
muito efetiva quando relacionado ao business case de SOA.
Além de todos esses cálculos, devem ser apresentados para a diretoria da
empresa, os investimentos que precisarão ser feitos para a utilização de SOA.
Segue abaixo alguns dos itens essenciais para atingir os resultados, tão
empolgantes, citados anteriormente (Kleber Bacilo, 2009).
1. Capacitação dos colaboradores;
2. Elementos de infra-estrutura, mas inicialmente tentar utilizar o que a
empresa já dispõe e colocar as licenças dos anos seguintes;
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
54
3. Consultorias externas, visando diminuir a quantidade de erros e
proporcionando melhores futuros;
4. Selecionar uma equipe pioneira dentro da empresa e calcular o
custo que esta equipe terá para ficar alocada apenas para a
implantação.
É importante exibir os investimentos necessários, mas lembrem que
investimento para empresa é sinônimo de custos. Então sempre exiba um item de
investimento e enumere 10 pontos de vantagens. Boa sorte e boa venda.
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
55
Referências
Ângelo, F. K. (24 de novembro de 2005). Entenda como e quando
implantar SOA. Acesso em 01 de março de 2010, disponível em Computerworld
Porta-voz do mercado de TI e comunicação:
http://computerworld.uol.com.br/gestao/2005/11/24/idgnoticia.2006-03-
29.9253581963/
Bacili, K. (2009 de julho de 14). Aprenda a calcular o ROI em SOA. Acesso
em 10 de fervereiro de 2010, disponível em Aquele Blog de SOA:
http://www.aqueleblogdesoa.com.br/2009/07/aprenda-a-calcular-o-roi-em-soa/
Davis, A., & Zhang, D. (2002). A comparative study of DCOM and SOAP.
Acesso em 22 de março de 2010, disponível em IEEE Xplore Digital Library:
http://ieeexplore.ieee.org/search/srchabstract.jsp?tp=&arnumber=1181595&query
Text%3Dsoap%26openedRefinements%3D*%26searchField%3DSearch+All
Erl, T. (2009). SOA Princípios de design de serviços. São Paulo: Pearson
Prentice Hall.
Gabriel. (03 de novembro de 2008). O que é SOA. Acesso em 13 de
novembro de 2009, disponível em Aquele blog de SOA:
http://www.aqueleblogdesoa.com.br/2008/11/o-que-e-soa/
Gabriel. (05 de março de 2009). Princípios Básicos de SOA – Contrato
Formal. Acesso em 15 de novembro de 2009, disponível em Aquele Blog SOA:
http://www.aqueleblogdesoa.com.br/2009/03/principios-basicos-de-soa-contrato-
formal/
Gabriel. (02 de março de 2009). Princípios Básicos de SOA – Serviços
Reutilizáveis. Acesso em 20 de novembro de 2009, disponível em Aquele blog de
SOA: http://www.aqueleblogdesoa.com.br/2009/03/principios-basicos-de-soa-
servicos-reutilizaveis/
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
56
Gabriel. (12 de maio de 2009). Princípos Básicos de SOA – Serviços
Abstraem a Lógica. Acesso em 10 de 11 de 2009, disponível em Aquele blog de
SOA: http://www.aqueleblogdesoa.com.br/2009/05/principos-basicos-de-soa-
servicos-abstraem-a-logica/
Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (2000). Padrões de
Projeto Soluções reutilizáveis de software orientado a objetos. Porto Alegre:
Bookman.
Gartner. (s.d.). Practitioner’s Guide: Best Practices in Enterpricewide SOA
Initiatives. Acesso em 18 de fervereiro de 2010, disponível em Gartner: 2010
Hurwitz, J., Bloor, R., Kaufman, M., & Halper, F. (2009). Arquitetura
Orientada a serviços – SOA para Leigos (2 ed.). Rio de Janeiro: Alta Books.
Martin David, B. M. (agosto de 2002). Web Service Definition Language
(WSDL). Acesso em 03 de 03 de 2010, disponível em Web Service Definition
Language (WSDL): http://www.ai.sri.com/daml/services/daml-s/0.7/daml-s-
wsdl.html
Min Luo Goldshlager, B. L.-J. (15 de julho de 2005). Designing and
implementing Enterprise Service Bus (ESB) and SOA solutions. Acesso em 10 de
março de 2010, disponível em IEEE Xplore Digital Library:
http://ieeexplore.ieee.org/search/freesrchabstract.jsp?reload=true&tp=&arnumber=
1524413&queryText%3DESB%26openedRefinements%3D*%26searchField%3D
Search+All
MSDN Microsoft. (01 de outubro de 2003). Uderstanding WSDL. Acesso
em 03 de 03 de 2010, disponível em MSDN: http://msdn.microsoft.com/en-
us/library/ms996486.aspx
MSW Métricas e Software. (s.d.). Qualidade de Software. Acesso em 20 de
fervereiro de 2010, disponível em MSW Métricas e Software - Fábrica de
Software: http://www.mswconsult.com.br/qualidade.html
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
57
OASIS. (14 de agosto de 2008). UDDI 101. Acesso em 25 de fervereiro de
2010, disponível em UDDI Xml Org Online community for the Universal
Description, Discovery, and Integration OASIS Stantard: http://uddi.xml.org/uddi-
101
Oliveira, E. C. (08 de abril de 2009). Tutoriais CTDO. Acesso em 20 de
janeiro de 2010, disponível em Web Services: Java e XML juntos pela
interoperabilidade: http://tutoriais.ctdo.com.br/tutoriais/linguagens-para-web-
sites/xml/web-services-java-e-xml-juntos-pela-interoperabilidade.html
Oliveira, M. (11 de fervereiro de 2009). Caso de Sucesso com SOA.
Acesso em 10 de novembro de 2009, disponível em Aquele blog de SO:
http://www.aqueleblogdesoa.com.br/2009/02/caso-de-sucesso-com-soa/
Progress Software. (2010). ESB ARCHITECTURE AND LIFECYCLE
DEFINITION. Acesso em 03 de março de 2010, disponível em Progress Software
Business Making Progress: http://web.progress.com/en/esb-architecture-lifecycle-
definition.html
RD Consultoria. (14 de fervereiro de 2009). Medindo Satisfação do Cliente.
Acesso em 20 de fervereiro de 2010, disponível em Medindo Satisfação do
Cliente RD Consultoria:
http://www.rdconsultoria.com.br/topic.asp?TOPIC_ID=239&FORUM_ID=16&CAT_
ID=2&Forum_Title=Atendimento&Topic_Title=Medindo+a+satisfa%E7%E3o+do+c
liente
Rodrigues, R. (16 de janeiro de 2009). Estratégia de implantação SOA:
negócios flexíveis, serviços governáveis. Acesso em março de 22, disponível em
Administradores - O portal da administração:
http://www.administradores.com.br/informe-se/informativo/estrategia-de-
implantacao-soa-negocios-flexiveis-servicos-governaveis/20198/
Saturino, L. (26 de outrubro de 2009). Fábrica de Software e Tecnologia de
ponta: resultados garantidos. Acesso em 28 de fervereiro de 2010, disponível em
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
58
Baguete tecnologia e informação em um só lugar:
http://www.baguete.com.br/artigosDetalhes.php?id=1039
Schmelzer, R. (28 de novembro de 2007). The Seven Levels of Loose
Couplin. Acesso em 20 de janeiro de 2010, disponível em ZapThink SOA and
Cloud Training, Consulting, and Community:
http://www.zapthink.com/2007/11/28/the-seven-levels-of-loose-coupling/
Sommervile, I. (2007). Engenharia de software. São Paulo: Pearson
Addison-Wesley.
Sonda, G. C., & Montez, C. (01 de maio de 2004). Uma proposta de
implementação de diferenciação de serviços na Arquitetura de Web Services.
Acesso em 20 de janeiro de 2010, disponível em Artigo de Sonda e Montez:
http://inf.unisul.br/~ines/workcomp/cd/pdfs/2508.pdf
Standish Group. (23 de abril de 2009). Standish Newroom - CHAOS 2009.
Acesso em 03 de 03 de 2010, disponível em The Standish Group:
http://www1.standishgroup.com/newsroom/chaos_2009.php
Ventura, J. (21 de julho de 2008). Baixo Acoplamento. Acesso em 21 de
novembro de 2009, disponível em Aquele blog de SOA:
http://www.aqueleblogdesoa.com.br/2008/07/baixo-acoplamento/
W3C. (15 de março de 2001). Web Services Description Language (WSDL)
1.1. Acesso em 25 de fervereiro de 2010, disponível em W3C Note:
http://www.w3.org/TR/wsdl
Wikipedia. (21 de março de 2010). HTML. Acesso em 28 de março de
2010, disponível em Wikipédia, a enciclopédia livre:
http://pt.wikipedia.org/wiki/HTML
Wikipédia. (01 de outubro de 2009). SOAP. Acesso em 2010 de ferveriero
de 22, disponível em Wikipédia, a enciclopédia livre:
http://pt.wikipedia.org/wiki/SOAP
Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI)
59
Wikipédia. (01 de abril de 2009). Web Service. Acesso em 20 de fervereiro
de 2010, disponível em Wikipédia, a enciclopédia livre:
http://pt.wikipedia.org/wiki/Web_service
Wikipédia. (08 de março de 2010). Web Services Description Language.
Acesso em 22 de ferveriero de 2010, disponível em Wikipédia, a enciclopédia
livre: http://pt.wikipedia.org/wiki/WSDL
Wikipédia. (16 de março de 2010). XML. Acesso em 10 de 01 de 2010,
disponível em Wikipédia, a enciclopédia livre: http://pt.wikipedia.org/wiki/XML
Zaidan, P. (03 de setembro de 2009). SOA atinge até 80% do reuso com
governança, diz BearingPoint. Acesso em 10 de janeiro de 2010, disponível em
Decision Report:
http://www.decisionreport.com.br/publique/cgi/cgilua.exe/sys/start.htm?infoid=416
3&query=simple&search%5Fby%5Fauthorname=all&search%5Fby%5Ffield=tax&
search%5Fby%5Fkeywords=any&search%5Fby%5Fpriority=all&search%5Fby%5
Fsection=all&search%5Fby%5Fstate=all&se
Anexos
Anexo I – Questionário para levantamento de informações da capacitação
dos técnicos.
Anexo I – Questionário para levantamento de
informações da capacitação dos técnicos.
“UMA PROPOSTA PARA IMPLANTAÇÃO DO CONCEITO DA
ORIENTAÇÃO A SERVIÇOS EM UMA EMPRESA DE TI”
1º) Como seria o cenário de transição de uma empresa que não tem na cultura o
conceito de orientação a serviços e mais ou menos quanto tempo levaria ?
2º) Como funcionária a versão final de um projeto, onde deve ser implantado no
cliente ou hospedado em algum servidor, que algumas lógicas de negócio são
serviços já implementado na empresa ?
3º) Como os desenvolvedores saberiam quais serviços utilizar, ou seja, de que
forma e em que local ficarão armazenada essas informações ?
4º) Quando o cliente fica responsável pela Análise e / ou design do projeto e não
tem na sua cultura trabalhar com orientação a serviços. Como a empresa de TI ou
o projeto trataria isso, pensando que a empresa TI tem já vários serviços
implementados e que seriam importantíssimos no desenvolvimento referente a
agilidade e eficiência, pois estão bem estáveis ?
5º) Essa quinta questão eu deixo aberta para poderem comentar darem dicas ou
falarem de alguma coisa importante que não foi questionada na perguntas
anteriores.

Más contenido relacionado

Destacado

JUnit - Germán Domínguez
JUnit - Germán DomínguezJUnit - Germán Domínguez
JUnit - Germán Domínguez2008PA2Info3
 
HERRAMIENTAS DIGITALES
HERRAMIENTAS DIGITALESHERRAMIENTAS DIGITALES
HERRAMIENTAS DIGITALESyyid
 
AVOIDING PLAGIARISM
AVOIDING PLAGIARISMAVOIDING PLAGIARISM
AVOIDING PLAGIARISMMhel Marquez
 
Matoneo Escolar
Matoneo EscolarMatoneo Escolar
Matoneo EscolarAmigo VJ
 
La Antártida Segunda Edición
La Antártida Segunda EdiciónLa Antártida Segunda Edición
La Antártida Segunda EdiciónManuel Arceo
 
Manual de herramientas digitales
Manual de herramientas digitalesManual de herramientas digitales
Manual de herramientas digitalesMK-D Activo
 
Pliego Modificado II Edición Concurso Ideas Tu Proyecto: tu Ciudad: Ampliacio...
Pliego Modificado II Edición Concurso Ideas Tu Proyecto: tu Ciudad: Ampliacio...Pliego Modificado II Edición Concurso Ideas Tu Proyecto: tu Ciudad: Ampliacio...
Pliego Modificado II Edición Concurso Ideas Tu Proyecto: tu Ciudad: Ampliacio...catedrametropol
 
Br cerveja artesanal-guilherme-alberici_de_santi
Br cerveja artesanal-guilherme-alberici_de_santiBr cerveja artesanal-guilherme-alberici_de_santi
Br cerveja artesanal-guilherme-alberici_de_santilgspezia
 
Crowd Agents: Interactive Crowd-Powered Systems in the Real World
Crowd Agents:  Interactive Crowd-Powered Systems in the Real WorldCrowd Agents:  Interactive Crowd-Powered Systems in the Real World
Crowd Agents: Interactive Crowd-Powered Systems in the Real WorldJeffrey Bigham
 
Projeto ação cultural - Birabiblio em Ação
Projeto ação cultural - Birabiblio em AçãoProjeto ação cultural - Birabiblio em Ação
Projeto ação cultural - Birabiblio em AçãoHamilton
 
U.S. Law of the Sea Cruise to Map and Sample the US Arctic Ocean Margin
U.S. Law of the Sea Cruise to Map and Sample the US Arctic Ocean MarginU.S. Law of the Sea Cruise to Map and Sample the US Arctic Ocean Margin
U.S. Law of the Sea Cruise to Map and Sample the US Arctic Ocean MarginLarry Mayer
 
Não há docência sem discência
Não há docência sem discênciaNão há docência sem discência
Não há docência sem discênciaCRIS TORRES
 

Destacado (18)

JUnit - Germán Domínguez
JUnit - Germán DomínguezJUnit - Germán Domínguez
JUnit - Germán Domínguez
 
Soledad Compartida
Soledad CompartidaSoledad Compartida
Soledad Compartida
 
HERRAMIENTAS DIGITALES
HERRAMIENTAS DIGITALESHERRAMIENTAS DIGITALES
HERRAMIENTAS DIGITALES
 
AVOIDING PLAGIARISM
AVOIDING PLAGIARISMAVOIDING PLAGIARISM
AVOIDING PLAGIARISM
 
Matoneo Escolar
Matoneo EscolarMatoneo Escolar
Matoneo Escolar
 
Life hacks
Life hacks Life hacks
Life hacks
 
La Antártida Segunda Edición
La Antártida Segunda EdiciónLa Antártida Segunda Edición
La Antártida Segunda Edición
 
Manual de herramientas digitales
Manual de herramientas digitalesManual de herramientas digitales
Manual de herramientas digitales
 
Geometria analitica
Geometria analiticaGeometria analitica
Geometria analitica
 
Soneto do amigo
Soneto do amigoSoneto do amigo
Soneto do amigo
 
Pliego Modificado II Edición Concurso Ideas Tu Proyecto: tu Ciudad: Ampliacio...
Pliego Modificado II Edición Concurso Ideas Tu Proyecto: tu Ciudad: Ampliacio...Pliego Modificado II Edición Concurso Ideas Tu Proyecto: tu Ciudad: Ampliacio...
Pliego Modificado II Edición Concurso Ideas Tu Proyecto: tu Ciudad: Ampliacio...
 
Mkt geral
Mkt geralMkt geral
Mkt geral
 
Br cerveja artesanal-guilherme-alberici_de_santi
Br cerveja artesanal-guilherme-alberici_de_santiBr cerveja artesanal-guilherme-alberici_de_santi
Br cerveja artesanal-guilherme-alberici_de_santi
 
Crowd Agents: Interactive Crowd-Powered Systems in the Real World
Crowd Agents:  Interactive Crowd-Powered Systems in the Real WorldCrowd Agents:  Interactive Crowd-Powered Systems in the Real World
Crowd Agents: Interactive Crowd-Powered Systems in the Real World
 
Projeto ação cultural - Birabiblio em Ação
Projeto ação cultural - Birabiblio em AçãoProjeto ação cultural - Birabiblio em Ação
Projeto ação cultural - Birabiblio em Ação
 
U.S. Law of the Sea Cruise to Map and Sample the US Arctic Ocean Margin
U.S. Law of the Sea Cruise to Map and Sample the US Arctic Ocean MarginU.S. Law of the Sea Cruise to Map and Sample the US Arctic Ocean Margin
U.S. Law of the Sea Cruise to Map and Sample the US Arctic Ocean Margin
 
Não há docência sem discência
Não há docência sem discênciaNão há docência sem discência
Não há docência sem discência
 
S4C book of abstracts
S4C book of abstractsS4C book of abstracts
S4C book of abstracts
 

Similar a Avaliando soa em uma empresa de ti

Engenharia de requisitos para metodos ageis dissertacao
Engenharia de requisitos para metodos ageis   dissertacaoEngenharia de requisitos para metodos ageis   dissertacao
Engenharia de requisitos para metodos ageis dissertacaotsblackboy
 
Gerenciamento de serviços de TI
Gerenciamento de serviços de TIGerenciamento de serviços de TI
Gerenciamento de serviços de TIOhio University
 
Gerencia de Serviços de TI
Gerencia de Serviços de TIGerencia de Serviços de TI
Gerencia de Serviços de TIOhio University
 
DevOps - Novos Desafios para TI
DevOps - Novos Desafios para TIDevOps - Novos Desafios para TI
DevOps - Novos Desafios para TICarlos Buzeto
 
Trabalho individual 5 semestre Analise de Sistemas
Trabalho individual 5 semestre Analise de SistemasTrabalho individual 5 semestre Analise de Sistemas
Trabalho individual 5 semestre Analise de SistemasWANDERSON JONER
 
Requisitos no Processo Iterativo
Requisitos no Processo IterativoRequisitos no Processo Iterativo
Requisitos no Processo IterativoFatec
 
Agenda final 13a. conferencia anual do CMG Brasil
Agenda final 13a. conferencia anual do CMG BrasilAgenda final 13a. conferencia anual do CMG Brasil
Agenda final 13a. conferencia anual do CMG BrasilJoao Galdino Mello de Souza
 
Software para Gerência de Projetos baseado em Metodologias Ágeis [Relatório T...
Software para Gerência de Projetos baseado em Metodologias Ágeis [Relatório T...Software para Gerência de Projetos baseado em Metodologias Ágeis [Relatório T...
Software para Gerência de Projetos baseado em Metodologias Ágeis [Relatório T...Anderson Kanegae Soares Rocha
 
Desenvolvimento de ferramenta para automação de tarefas
Desenvolvimento de ferramenta para automação de tarefasDesenvolvimento de ferramenta para automação de tarefas
Desenvolvimento de ferramenta para automação de tarefasEverton V. Tavares
 
Mps br final - mps
Mps br final - mpsMps br final - mps
Mps br final - mpsEdvaldo Cruz
 
Metodologia sugerida para gestão de projetos web
Metodologia sugerida para gestão de projetos webMetodologia sugerida para gestão de projetos web
Metodologia sugerida para gestão de projetos webdiogo_plta
 
Apresentação SOA
Apresentação SOAApresentação SOA
Apresentação SOAproxypt
 
SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...
SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...
SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...João Gabriel Lima
 
Conhecendo o eXtreme Programming
Conhecendo o eXtreme ProgrammingConhecendo o eXtreme Programming
Conhecendo o eXtreme ProgrammingDaniel Wildt
 

Similar a Avaliando soa em uma empresa de ti (20)

Engenharia de requisitos para metodos ageis dissertacao
Engenharia de requisitos para metodos ageis   dissertacaoEngenharia de requisitos para metodos ageis   dissertacao
Engenharia de requisitos para metodos ageis dissertacao
 
Gerenciamento de serviços de TI
Gerenciamento de serviços de TIGerenciamento de serviços de TI
Gerenciamento de serviços de TI
 
Gerencia de Serviços de TI
Gerencia de Serviços de TIGerencia de Serviços de TI
Gerencia de Serviços de TI
 
DevOps - Novos Desafios para TI
DevOps - Novos Desafios para TIDevOps - Novos Desafios para TI
DevOps - Novos Desafios para TI
 
Trabalho individual 5 semestre Analise de Sistemas
Trabalho individual 5 semestre Analise de SistemasTrabalho individual 5 semestre Analise de Sistemas
Trabalho individual 5 semestre Analise de Sistemas
 
Requisitos no Processo Iterativo
Requisitos no Processo IterativoRequisitos no Processo Iterativo
Requisitos no Processo Iterativo
 
266-940-1-PB
266-940-1-PB266-940-1-PB
266-940-1-PB
 
Subm_SamuelPereira_FINAL
Subm_SamuelPereira_FINALSubm_SamuelPereira_FINAL
Subm_SamuelPereira_FINAL
 
Agenda final 13a. conferencia anual do CMG Brasil
Agenda final 13a. conferencia anual do CMG BrasilAgenda final 13a. conferencia anual do CMG Brasil
Agenda final 13a. conferencia anual do CMG Brasil
 
Apresentação TCC I - IES/SC 2013
Apresentação TCC I - IES/SC 2013Apresentação TCC I - IES/SC 2013
Apresentação TCC I - IES/SC 2013
 
Software para Gerência de Projetos baseado em Metodologias Ágeis [Relatório T...
Software para Gerência de Projetos baseado em Metodologias Ágeis [Relatório T...Software para Gerência de Projetos baseado em Metodologias Ágeis [Relatório T...
Software para Gerência de Projetos baseado em Metodologias Ágeis [Relatório T...
 
Desenvolvimento de ferramenta para automação de tarefas
Desenvolvimento de ferramenta para automação de tarefasDesenvolvimento de ferramenta para automação de tarefas
Desenvolvimento de ferramenta para automação de tarefas
 
Nde
NdeNde
Nde
 
Mps br final - mps
Mps br final - mpsMps br final - mps
Mps br final - mps
 
Projeto YES
Projeto YESProjeto YES
Projeto YES
 
Plano de Projeto SGS
Plano de Projeto SGSPlano de Projeto SGS
Plano de Projeto SGS
 
Metodologia sugerida para gestão de projetos web
Metodologia sugerida para gestão de projetos webMetodologia sugerida para gestão de projetos web
Metodologia sugerida para gestão de projetos web
 
Apresentação SOA
Apresentação SOAApresentação SOA
Apresentação SOA
 
SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...
SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...
SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...
 
Conhecendo o eXtreme Programming
Conhecendo o eXtreme ProgrammingConhecendo o eXtreme Programming
Conhecendo o eXtreme Programming
 

Avaliando soa em uma empresa de ti

  • 1. Universidade Federal de Pernambuco Centro de Informática Especialização em Tecnologias da Informação para Formação AVALIANDO ARQUITETURAS ORIENTADAS A SERVIÇOS EM UMA EMPRESA DE TECNOLOGIA DA INFORMAÇÃO (TI) por RODRIGO MINERVINO PEREIRA Recife, junho de 02
  • 2. Agradecimentos Agradeço primeiramente aos meus pais, que me ofereceram tudo o que foi possível, para que eu me tornasse um pós-graduado com apenas 23 anos, um especialista em Tecnologia de Informação. Um agradecimento em especial a minha namorada Evinha (como gosta de ser chamada), que me ajudou muito na preparação e finalização da monografia. Ainda mais tendo que me aturar em momentos difíceis e de forte estresse. Agradeço a minha irmã, tios, primos e minhas avós que sempre me deram força e sempre acreditaram no meu potencial. Aos meus amigos, que sem eles nada nessa vida seria possível. Obrigado ao meu orientador Sérgio Soares, que sempre me cobrou quando necessário, e me fez produzir uma monografia de boa qualidade. Agradeço muito ao pessoal da Pitang, local em que trabalho, que mesmo o projeto estando em fases de finalização, me deu a oportunidade de acabar a minha especialização. Agradecimento em especial a Flávio Almeida que me ajudou muito na produção da monografia. Por fim agradeço a todos aqueles que torcem pelo meu sucesso. “Sucesso Total e Absoluto” (Flávio Almeida).
  • 3. Sumário LISTA DE FIGURAS _________________________________________ V LISTA DE TABELAS ________________________________________ VI RESUMO_________________________________________________ VII ABSTRACT_______________________________________________ VIII CAPÍTULO 1 INTRODUÇÃO __________________________________9 1.1 Motivação ________________________________________________________________ 9 1.2 Objetivo_________________________________________________________________ 10 1.2.1 Objetivo Geral _______________________________________________________ 10 1.2.2 Objetivos Específicos __________________________________________________ 10 1.3 Organização da monografia ________________________________________________ 11 CAPÍTULO 2 ORIENTAÇÃO A SERVIÇOS______________________12 2.1 Introdução ______________________________________________________________ 12 2.2 Princípios de projeto da Arquitetura orientada a serviços _______________________ 13 2.2.1 Contratos de serviços _____________________________________________________ 13 2.2.2 Acoplamento de serviços __________________________________________________ 15 2.2.3 Abstração de serviços_____________________________________________________ 20 2.2.4 Capacidade de reuso de serviços ____________________________________________ 21 2.2.5 Autonomia de serviço ____________________________________________________ 24 2.2.6 Independência de estado __________________________________________________ 25 2.2.7 Visibilidade do serviço____________________________________________________ 27 2.2.8 Composição de serviços___________________________________________________ 28
  • 4. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) iv CAPÍTULO 3 TECNOLOGIAS ________________________________33 3.1 Web service______________________________________________________________ 33 3.2 XML ___________________________________________________________________ 34 3.3 SOAP___________________________________________________________________ 36 3.4 WSDL __________________________________________________________________ 38 3.5 UDDI ___________________________________________________________________ 40 3.6 ESB ____________________________________________________________________ 41 CAPÍTULO 4 IMPLANTANDO SOA EM UMA EMPRESA TI ________43 4.1 Implantação em um novo projeto____________________________________________ 44 4.2 Adaptação dos projetos já em andamentos ____________________________________ 44 4.3 Cenário de implantação de SOA em uma empresa de TI_________________________ 45 CAPÍTULO 5 CONSIDERAÇÕES FINAIS _______________________49 5.1 Contribuições ____________________________________________________________ 50 5.2 Trabalhos futuros_________________________________________________________ 51 5.3 Aprendendo a vender SOA na sua empresa ___________________________________ 52 REFERÊNCIAS_____________________________________________55 ANEXOS __________________________________________________60
  • 5. Lista de Figuras FIGURA 1: ALTO ACOPLAMENTO. (VENTURA, 2008). _________________________16 FIGURA 2: WEB SERVICE. (OLIVEIRA E. C., 2009) __________________________34 FIGURA 3: EXEMPLO DE UM ARQUIVO XML. (WIKIPÉDIA, 2010) _________________36 FIGURA 4: EXEMPLO DE UM ENVELOPE SOAP. (WIKIPÉDIA, 2009)_______________37 FIGURA 5: EXEMPLO DE UM WEB SERVICE UTILIZANDO SOAP. (MSDN MICROSOFT, 2003)_______________________________________________________38 FIGURA 6: DIAGRAMA DE UM DOCUMENTO WSDL. (W3C ,2001) ________________39 FIGURA 7: EXEMPLO DA RELAÇÃO DO UDDI ENTRE OUTROS PROTOCOLOS. (OASIS, 2006)_______________________________________________________40 FIGURA 8: EXEMPLO DE UMA APLICAÇÃO SOA UTILIZANDO ESB. (PROGRESS SOFTWARE, 2010) _____________________________________________42 FIGURA 9: CENÁRIO DE IMPLANTAÇÃO DE SOA PARA GRANDES EMPRESAS. (GARTNER, 2008)_______________________________________________________47 FIGURA 10: CENÁRIO DE IMPLANTAÇÃO DE SOA PARA MÉDIAS E PEQUENAS EMPRESAS. (GARTNER, 2008) ______________________________________________48
  • 6. Lista de Tabelas TABELA 1: PERFIL DO PRINCÍPIO DO CONTRATO DE SERVIÇOS. __________________15 TABELA 2: PERFIL DO PRINCÍPIO DO BAIXO ACOPLAMENTO DE SERVIÇOS. __________18 TABELA 3: RESUMO DOS TIPOS DE ACOPLAMENTO E INFLUÊNCIAS ASSOCIADAS. _____19 TABELA 4: PERFIL DO PRINCÍPIO DA ABSTRAÇÃO DE SERVIÇO. __________________21 TABELA 5: PERFIL DO PRINCÍPIO DA CAPACIDADE DE REUSO DE SERVIÇO. __________24 TABELA 6: PERFIL DO PRINCÍPIO DA AUTONOMIA DE SERVIÇO. __________________25 TABELA 7: PERFIL DO PRINCÍPIO DA INDEPENDÊNCIA DE ESTADO DO SERVIÇO._______27 TABELA 8: PERFIL DO PRINCÍPIO DA VISIBILIDADE DO SERVIÇO. __________________28 TABELA 9: PERFIL DO PRINCÍPIO DA COMPOSIÇÃO DE SERVIÇO. _________________32
  • 7. Resumo O grande desafio das fábricas de software é o aumento da produtividade mantendo o nível de qualidade dos softwares. Os princípios da arquitetura orientada a serviços (SOA) têm técnicas, que possibilita a percepção do aumento da produtividade em um espaço curto de tempo. Grandes estudiosos afirmam que SOA é uma arquitetura conceitual, que cria serviços com perfis que atendam as suas normas ou princípios. Esses serviços são criados para retirar, por exemplo, lógicas repetidas onde esta seja independente e reutilizada. O objetivo desse trabalho é de propor uma solução arquitetural para aumentar a produtividade e manter a qualidade do software. O uso de tecnologias no desenvolvimento de SOA, que já são conhecidas pelo mercado, é fundamental para que esta agilidade na construção seja visível. E que não passe de mais uma sugestão de melhoria de código (software) sem sucesso. Contudo é sobre esta arquitetura e seus princípios, que será apresentado este trabalho. Palavras-chave: software, serviços, arquitetura orientada a serviços, princípios.
  • 8. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) viii Abstract The challenge of software factories is increasing productivity while maintaining the quality of software. The principles of service-oriented architecture (SOA) are techniques which allow the perception of increased productivity in a short space of time. Great scholars argue that SOA is a conceptual architecture, which creates profiles with services that meet its standards or principles. These services are designed to remove, for example, where repeated this logic is independent and reused. The aim of this paper is to propose an architectural solution to increase productivity and maintain quality software. The use of technologies in the development of SOA, which are already known by the market, is key to this speed in construction is visible. And that as just a suggestion for improving the code (software) without success. But this is about architecture and its principles, which will be presented this work. Keywords: software, services, service-oriented architecture, principles.
  • 9. Capítulo 1 Introdução Esse capítulo apresenta a motivação e os objetivos deste trabalho, informando quais os principais problemas encontrados dentro de uma empresa de tecnologia da informação que incentivou a pesquisa e produção do mesmo. Tem como foco o aumento da produtividade, ou seja, produzir mais em menos tempo (Saturino, 2009). Dessa forma visa-se evitar esforços, pois segundo a MSW Métricas e Software cerca de 50% a 70% dos esforços gastos no programa serão perdidos após realizar a entrega ao cliente. 1.1 Motivação A motivação desse trabalho é aumentar a agilidade, a qualidade das soluções de software, utilizando alguns princípios da arquitetura orientada a serviços, gerando assim menos bugs e uma maior satisfação dos clientes. Visto que, é percebido como um dos grandes obstáculos encontrados no desenvolvimento de software (RD Consultoria, 2009). “O grande desafio das fábricas de software é produzir atendendo às necessidades do cliente sob aspectos funcionais e de qualidade, cumprindo prazos cada vez menores e torná-lo viável aos investimentos dos clientes“ (Saturino, 2009). Atualmente é percebido que as falhas de planejamento, de construção de software, são apresentadas frequentemente a cada novo projeto. Mas Segundo Saturino (2009), o processo de software deve ter um mecanismo de melhorias contínuas, sendo aperfeiçoado a cada novo projeto. Fábricas de softwares sentem um pouco mais este problema, pois os projetos são desenvolvidos por equipes diferentes que, em geral, não investem tempo para discutir os problemas encontrados anteriormente. Devido à pressão para produzir mais, com melhor qualidade e em um tempo cada vez menor. Como experiência vivenciada pelo autor desta monografia, percebe-se que
  • 10. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 10 a agilidade na produção é uma preocupação frequente das equipes de desenvolvimento. Esta informação sempre está sendo medida e comparada para avaliar o desempenho do projeto, buscando a satisfação do cliente, que segundo a RD Consultoria (2009): o cliente é a pessoa mais importante, pois o sucesso e a própria existência da empresa de software dependem dele. Pode-se conseguir a satisfação do cliente construindo software de qualidade que permita a diminuição de erros inesperados, evitando, dessa forma, desperdiçar tempo com esforços na correção dos erros. Tendo em vista que um software de qualidade permite que se consiga um aumentando na produtividade da construção do software. Desta forma uma empresa de TI obtém seu objetivo satisfazendo seu cliente, entregando os projetos em um tempo hábil. 1.2 Objetivo A seguir são apresentados o objetivo geral e os objetivos específicos. 1.2.1 Objetivo Geral O objetivo geral deste trabalho é diminuir o retrabalho das equipes de softwares; diminuindo os esforços com correções de erros inesperados, causando uma menor quantidade de horas extras. Ou seja, aumentar a produtividade na construção de softwares mantendo uma boa qualidade para evitar uma grande quantidade de erros. 1.2.2 Objetivos Específicos Aumentar o conhecimento referente à arquitetura orientada a serviços (SOA) dos colaboradores das organizações de TI, o qual foi um ponto de dificuldade na pesquisa para a elaboração deste trabalho. Mostrar tecnologias essenciais no desenvolvimento de SOA, visto que na produção de software a escolha certa das melhores tecnologias proporciona uma
  • 11. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 11 melhor construção, baseada no conceito da orientação a serviços. Sugestão de implantação da arquitetura orientada a serviços, em projetos novos ou a adaptação em projetos que já estão em andamento, mostrando um passo a passo de como fazê-la segundo especialistas. 1.3 Organização da monografia Esta monografia esta organizada da seguinte forma: No Capítulo 2, Orientação a serviços, são apresentadas as definições sobre o conceito da orientação a serviços, exibindo todos os seus princípios. No Capítulo 3, Tecnologias, são apresentadas as definições das tecnologias mais conhecidas para o desenvolvimento de uma arquitetura orientada a serviços (SOA). No Capítulo 4, Implantando SOA em uma empresa de TI, são propostas algumas maneiras de implantação da arquitetura orientada a serviços de acordo com a grandeza da empresa e o momento do projeto escolhido. No Capítulo 5, Considerações Finais, são abordadas as conclusões tiradas pela pesquisa para produzir a monografia e quais foram às dificuldades encontradas. Também são exibidos quais os trabalhos futuros esperados e um passo a passo de como vender SOA.
  • 12. Capítulo 2 Orientação a Serviços Nesse capítulo é introduzido o conceito de orientação a serviços e os seus princípios, que devem ser encarados como boas práticas. Para que os objetivos citados sejam alcançados e os problemas encontrados corrigidos, é necessário seguir tais princípios. 2.1 Introdução Existem alguns mitos referentes ao conceito de SOA. Muitos acreditam que é uma tecnologia, outros que é uma ferramenta, ou ainda um produto, no entanto o conceito da arquitetura orientada a serviços segundo Gabriel (2008) diz respeito: “A arquitetura orientada a serviços na verdade é um conceito arquitetural corporativo que permite a criação de serviços interoperáveis, que podem facilmente ser reutilizáveis e compartilhados entre aplicações e empresas.” SOA é utilizada como uma arquitetura de software conceitual que utiliza um conjunto de características ou princípios, que servem como boas práticas para a aplicação dentro dos projetos e até mesmo dentro da organização. Tendo em vista que ambos propõem um meio de alcançar algo com base na experiência ou na aceitação por todo mercado, segundo especialistas. Esta estrutura de software implementa serviços aprimorando a eficiência, agilidade e a produtividade dentro da empresa, reutilizando funcionalidades de negócios dentro da organização, fazendo com que os serviços sejam os principais meios das soluções lógicas. Os serviços são programas de software que são fisicamente independentes do projeto principal e com características de projeto (design) distintas. Cada serviço recebe seu próprio contexto funcional e um conjunto de capacidades
  • 13. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 13 relacionadas a esse contexto. Os contratos de serviços públicos servem para expor as capacidades dos serviços, ou seja, aquilo que eles estão dispostos a fazer, para os programas externos (Erl, 2009). Como citado anteriormente, no que diz respeito às características de SOA, existem duas que são mais voltadas para a organização das funcionalidades e serviços, que são a composição e o inventário de serviços, as quais serão explicitadas na Seção 2.2.8. Uma implementação SOA, como forma de arquitetura, pode consistir em uma combinação de tecnologias e produtos, que auxiliarão no desenvolvimento dos princípios da arquitetura orientada a serviços. Contudo sabe-se que está combinação de tecnologias e produtos é uma decisão de projeto. Um projeto que possui vários serviços acoplados à implementação, não garante que a arquitetura e os negócios sejam orientados a serviços, pois alguns princípios devem ser seguidos, como exposto na Seção 2.2. No entanto, se faz necessário que a cultura da organização e as condições financeiras do projeto sejam favoráveis, para que tanto a arquitetura quanto os negócios sejam orientados a serviços. 2.2 Princípios de projeto da Arquitetura orientada a serviços O princípio de projeto representa, no momento de construir soluções, algo fundamental para dar forma, da maneira ideal, à lógica (Erl, 2009). Existem oito princípios básicos, que fornecem regras e diretrizes, que ajudam a determinar exatamente como a lógica deve ser decomposta e modelada em unidades distribucionais. Esses princípios serão detalhados nas seções a seguir. 2.2.1 Contratos de serviços O contrato de serviço é um dos princípios ou normas de modelagem mais
  • 14. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 14 importantes para a visibilidade, à autonomia e o reuso do serviço, pois são neles que estão sendo expostas todas as características, ou seja, todas as funcionalidades que poderão ser usadas por outras aplicações ou serviços. A abstração de ferramenta e tecnologia, características e limitações, dados não técnicos, detalhes da implementação, são informações que tornam um contrato de serviço fundamental para que a aplicação seja capaz de crescer e modificar sem que haja grandes, ou nenhum, impacto no lado do consumidor de tais serviços. Segundo Gabriel (2009), tais contratos são capazes de traduzir com detalhes a funcionalidade dos serviços específicos para que os clientes possam buscá-los e utilizá-los conforme sua necessidade. Mas existem algumas dificuldades: “Para que todos os detalhes de implementação de um serviço sejam especificados, são necessários diversos padrões de contratos a serem utilizados por toda a corporação. Isso pode se tornar uma tarefa complexa caso haja a necessidade de migração de documentos (já criados) para o conjunto de padrões escolhidos.” (GABRIEL, 2009) Os padrões WSDL (Web Service Description Language), UDDI (Universal Description Discovery Integration), SOAP (Simple Object Access Protocol) são muitos utilizados no dia-a-dia e serão explicados com mais detalhes no Capítulo 3. Portanto, um contrato é um documento textual que descreve o que o serviço faz. É de grande importância que o desenvolvimento do contrato seja acompanhado com a construção das funcionalidades do serviço, pois este tende a evoluir e o contrato deve conter todas as características do mesmo, considerando possíveis evoluções. Este é um dos maiores riscos encontrados, pois o controle de versão nem sempre é feito. Outra dificuldade é a deficiência de ferramentas para o desenvolvimento.
  • 15. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 15 Segue abaixo a Tabela 1, com o perfil que o serviço tem que ter para atender o princípio de contrato de serviços, segundo Erl (2009): Perfil do princípio Breve definição Serviços compartilham contratos padronizados Definição completa Cada contrato de serviços deve estar de acordo com os mesmos padrões de design aplicados a contratos de outros serviços dentro de um inventário de serviços. Objetivos 1. Ativar serviços com um nível significativo da interoperabilidade natural dentro do limite de um inventário de serviços. Isso reduz a necessidade de transformação de dados, por que os modelos de dados consistentes são utilizados para a troca da informação; 2. Permitir que o propósito e as capacidades dos serviços sejam entendidos de maneira mais fácil e intuitiva. Característica de design 1. Um contrato de serviços (composto por uma interface técnica ou um ou vários documentos de descrição de serviços) deve ser fornecido com o serviço; 2. O contrato de serviços é padronizado pelo aplicativo de padrões de design. Tabela 1: Perfil do princípio do contrato de serviços. 2.2.2 Acoplamento de serviços Outro princípio de SOA é o acoplamento de serviços. O conceito de baixo e alto acoplamento ainda sofre por má compreensão, pois não é algo que ouvimos com tanta freqüência. O alto acoplamento é um serviço que possui uma grande dependência de outros para que seu fluxo principal funcione, por exemplo, em uma engrenagem onde para que a mesma funcione é necessário que todas suas peças estejam trabalhando em conjunto, como ilustra a Figura 1 abaixo:
  • 16. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 16 Figura 1: Alto acoplamento. (Ventura, 2008). Um serviço não é apenas acoplado ou desacoplado (Schmelzer, 2007), existe um grau de granularidade do acoplamento. Um serviço nunca será 100% desacoplado, mas o desafio é achar o grau de desacoplamento que torne o serviço flexível para compor outros serviços e com custo não tão elevado (Schmelzer, 2007). Um dos principais objetivos de um serviço é que tenha a mínima dependência com um mundo exterior, ou seja, tenha um baixo acoplamento com os seus consumidores (Erl, 2009). Para que isso seja possível, é comum utilizar a tecnologia chamada ESB (Enterprise Service Bus), a qual abstrai a forma de troca de mensagens feitas pelos sistemas. Usando o ESB, o arquiteto de software reúne aplicações e componentes integrados para criar conjunto de serviços de processos de negócios. Por exemplo, existem aplicações de diferentes tecnologias (.NET, JAVA, PHP e etc.) que se comunicam por diferentes protocolos, como por exemplo SOAP, RNI, REST e JNI. No entanto essas formas de comunicação devem ser abstraídas pelo serviço para que, dessa forma, exclua a dependência do protocolo de comunicação, sendo esta a principal finalidade do ESB. O contrato de serviço é fundamental, pois nele será informado qual o máximo de acoplamento que o serviço terá e quais são os critérios escolhidos para a utilização da aplicação. É interessante também ter vários contratos,
  • 17. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 17 diminuindo dessa forma o acoplamento da lógica central, ou seja, formular várias formas de entradas e saídas de informações. É importante ter bastante cuidado, pois a busca do menor acoplamento pode trazer problemas de desempenho e de manutenção, pois as soluções serão complexas, utilizando soluções reutilizáveis com alguns padrões de projetos (Gamma, Helm, Johnson, & Vlissides ,2000). Segunto Erl (2009), quando se busca uma flexibilidade excessiva, é necessário que a lógica do serviço realize processamento extra, para interpretar os dados recebidos, por exemplo, aumentando os requisitos de desempenho. Para atingirmos este baixo acoplamento o serviço deve ter um perfil que atenda ao princípio de Acoplamento de serviços. Segue a abaixo a Tabela 2 que ilustra o que foi citado acima (Erl, 2009).
  • 18. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 18 Perfil do princípio Breve definição Serviços são fracamente acoplados. Definição completa Contratos de serviços impõem baixos requisitos de acoplamento de consumidor e são desacoplados de seu ambiente adjacente. Objetivos Ao promover consistentemente um acoplamento reduzido dentro e entre os serviços, trabalhamos em direção a um estado em que os contratos de serviços aumentam a independências com base em suas implementações, e os serviços são cada vez mais independentes entre si, Isso promove um ambiente no qual os serviços e seus consumidores podem evoluir e se adaptar ao longo do tempo, com impacto mínimo um sobre o outro. Característica de design 1. Existência de um contrato de serviços que, idealmente, é desacoplado dos detalhes de implementação e tecnologia; 2. Contexto de serviços funcional, que não é dependente da lógica externa; 3. Requisitos mínimos de acoplamento de consumidor. Tabela 2: Perfil do princípio do baixo acoplamento de serviços. Existem vários de tipos de acoplamentos, mas alguns não são aceitáveis, pois foge alguns princípios de SOA, segue a Tabela 3, que demonstra esta realidade (Erl, 2009).
  • 19. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 19 Tipo de Acoplamento Negativo? Nota Lógica ao contrato Não O alto acoplamento da lógica de serviços ao contrato é aceitável e suportado pelo princípio do contrato de serviço padronizado. Contrato à lógica Sim Essa forma de acoplamento não é recomendável e pode ser evitada pelo uso de abordagens de design „primeiro o contrato‟. Contrato à tecnologia Sim O contrato de serviços é, de maneira ideal, desacoplado da tecnologia do fornecedor, e suportado pelo uso de XML aberto e dos padrões de Web service. Contrato à funcionalidade Sim Este tipo de acoplamento negativo é evitável pela aplicação do princípio da capacidade de reuso de serviço, mas pode ser requerido para certos tipos de serviços. Contrato à implementação Sim Essa forma de acoplamento não é recomendável, especificamente em relação a recursos de implementação externos e compartilhados. Consumidor à implementação Sim O modelo de design de centralização de contratos é utilizado especificamente para evitar esse tipo de acoplamento. Consumidor ao contrato Não Esta é a forma positiva de acoplamento, mas seu benefício está relacionado a até que ponto os níveis negativos do acoplamento de contrato de serviços foram evitados. Tabela 3: Resumo dos tipos de acoplamento e influências associadas. O baixo acoplamento pode influenciar em outros princípios (Erl, 2009), encorajando a moderação da quantidade e da complexidade do conteúdo técnico do contrato, e assim permite minimizar os requisitos da dependência de
  • 20. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 20 consumidor. Além desse o princípio de baixo acoplamento afeta a capacidade de reuso, autonomia e a visibilidade do serviço. 2.2.3 Abstração de serviços A abstração de serviço tem como objetivo principal criar uma interface de comunicação com um mundo exterior, informando quais as entradas e qual o retorno, caso necessite, a funcionalidade do serviço utiliza. Essas informações estarão explicitamente contidas no contrato de serviços. Com isso, todo o desenvolvimento do negócio fica em uma camada completamente isolada de outros serviços, possibilitando modificações lógicas, ou até mesmo novas funcionalidades e tornando essas variações invisíveis para os que estão utilizando. Segundo Gabriel (2009), serviços devem ser tratados como uma caixa preta. O serviço deve ter um perfil que atenda a capacidade de reuso, autonomia e independência de tecnologia, garantindo dessa forma a abstração da lógica, ou seja, as modificações se tornem transparente para o consumidor do serviço. Segundo experiência do autor, vivenciada em empresas onde atuou, o mesmo percebeu que quando não se obtém essa transparência poderá acarretar em “desgosto” por parte do usuário. Erl (2009) descreve o perfil que o serviço deve seguir, informando quais as suas características, objetivos e definições, de acordo com a Tabela 4.
  • 21. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 21 Perfil do princípio Breve definição Informações de serviço dispensáveis são abstraídas. Definição completa Serviços são projetados para limitar informações no contrato de serviços ao que é realmente necessário para que o serviço seja funcionalmente útil a consumidores agora e no futuro. Informações além das que são publicadas no contratado de serviços são consideradas privadas e não devem ser disponibilizadas para a criação de consumidores de serviço potenciais. Objetivos Muitos dos outros princípios enfatizam a necessidade de publicar mais informações no contrato de serviços. O papel principal desse princípio é manter a quantidade e os detalhes do conteúdo do contrato concisos e equilibrados e evitar o acesso desnecessário a detalhes de serviço adicionais. Característica de design 1. Serviços abstraem constantemente informações específicas sobre tecnologia, lógica e função do mundo exterior – o mundo fora do limite de serviço; 2. Serviços têm contratos que definem concisamente requisitos de interação e limitações e outros metadetalhes de serviço necessários; 3. Fora do que é documentado no contrato de serviços, as informações sobre um serviço são controladas ou completamente ocultas dentro de determinado ambiente. Tabela 4: Perfil do princípio da abstração de serviço. 2.2.4 Capacidade de reuso de serviços A capacidade de reuso que o serviço deve ter é fundamental para aumentar a agilidade do desenvolvimento das aplicações. Não é interessante
  • 22. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 22 “reinventar a roda”, ou seja, sempre utilizar aquilo que já está pronto, que outra pessoa já definiu e programou. Para que os serviços sejam reusados, os contratos de serviços devem ter as informações necessárias e bem claras sobre as suas capacidades. Segundo Gabriel (2009): “Um serviço reutilizável é aquele que não carrega particularidades técnicas de uma implementação ou regra de negócio específica e é genérico o suficiente para atender outros projetos.” Os contratos de serviços devem conter todas as informações fundamentais para que os consumidores possam utilizar suas funcionalidades com confiança. Por tanto os fundamentos devem ser seguidos para que os riscos e o temor para a sua reutilização diminuam. Fazer um serviço bastante reutilizável é um investimento de médio prazo e que demanda tempo e dinheiro e muitas vezes os investidores não enxergam a sua verdadeira e fundamental importância (Erl, 2009). A capacidade de reuso é um dos princípios que mais se destaca em um desenvolvimento de SOA, pois a sua identificação e o seu desenvolvimento parecem nunca ser possível sair do papel. A Tabela 5 demonstra a definição do serviço de acordo com o princípio da capacidade de reuso (Erl, 2009).
  • 23. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 23 Perfil do princípio Breve definição Serviços são reusáveis. Definição completa Serviços contêm e expressam lógicas e podem ser definidos como recursos da empresa. Objetivos Os objetivos por trás da capacidade de reuso de serviço estão diretamente associados a alguns objetivos mais estratégicos na computação orientada a serviços: 1. Permitir que a lógica do serviço pudesse ser repetidamente alavancada ao longo do tempo, de modo que isso possa resultar em um retorno cada vez maior sobre o investimento inicial de desenvolvimento do serviço; 2. Aumentar a agilidade do negócio em um nível organizacional que permita o atendimento rápido dos futuros requisitos de automação dos negócios por meio da composição de serviço em larga escala; 3. Possibilitar a realização de modelos de serviço agnóstico, ou neutro; 4. Permitir a criação de inventários de serviços com alta percentagem de serviços neutros.
  • 24. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 24 Característica de design 1. O serviço é definido por um contexto funcional agnóstico - A lógica encapsulada pelo serviço associa-se a um contexto suficientemente agnóstico para que qualquer cenário de uso possa ser considerado reutilizável; 2. A lógica de serviço é altamente genérica – A lógica encapsula pelo serviço é genérico o bastante, o que permite que ela facilite inúmeros cenários de uso por diferentes tipos de consumidores de serviço; 3. O serviço tem um contrato genérico e extensível – O contrato de serviços é flexível o bastante para processar uma grande variedade de mensagens de entrada e saída; 4. A lógica de serviço pode ser acessada concorrentemente – Os serviços são projetados para facilitar o acesso simultâneo por múltiplos programas de consumidor. Tabela 5: Perfil do princípio da capacidade de reuso de serviço. 2.2.5 Autonomia de serviço A autonomia de serviço é a capacidade que o serviço tem de se governar, tendo em vista que dessa forma o mesmo não tem grandes dependências com outros serviços (Erl, 2009). Embora se pense em um serviço autônomo, o que esse princípio aborda é que o mesmo deve ter o mínimo de dependência e que a sua lógica principal seja bastante independente. O ato de se autogovernar ou autonomia de serviço, pode trazer alguns benefícios claros, como por exemplo, o desempenho (Erl, 2009). Tendo em vista que dessa forma se terá o mínimo de dependências com outros serviços e as execuções das funcionalidades se tornam mais diretas e conseqüentemente o número de erros inesperados diminui consideravelmente. Essa autonomia é medida e disponibilizada nos contratos formais, tendo como finalidade esclarecer
  • 25. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 25 o nível de independência aos seus consumidores. A Tabela 6 explica com mais detalhes as suas características. (Erl, 2009) Perfil do princípio Breve definição Serviços são autônomos. Definição completa OS serviços aumentaram a confiabilidade e a previsibilidade comportamental para suportar a execução autônoma, exercendo um alto nível de controle sobre a lógica e recursos em runtime. Objetivos 1. Aumentar a confiabilidade, o desempenho e a previsibilidade de um serviço em runtime, particularmente ao ser reusado e composto; 2. Aumentar a quantidade de controle que um serviço tem sobre o ambiente em runtime. Característica de design 1. Os serviços têm um contrato que expressa um limite funcional bem definido, que não deve envolver outros serviços; 2. Os serviços são implantados em um ambiente no qual eles exercem muito controle; e preferivelmente, um nível exclusivo;; 3. As instâncias de serviços estão em um ambiente que convive com a alta concorrência quanto a propósitos e escalabilidade. Tabela 6: Perfil do princípio da autonomia de serviço. 2.2.6 Independência de estado A independência de estado é quando um serviço não precisa reter nenhum dado do estado para que outro serviço processe a sua lógica. Podemos citar como exemplo, o uso do protocolo HTTP. O qual monta seu cabeçalho e todo o conteúdo da página que é enviada para o navegador (browser), retornando a uma condição de independência de estado em que ele não retém nenhuma solicitação
  • 26. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 26 ou memória adicional do browser (Erl, 2009). Os serviços são projetados para minimizar o período, durante o qual eles existem em uma condição de dependência de informação de estado, aumentando a escalabilidade do serviço. Os contratos de serviços devem ter menos restrições, com a finalidade de permitir o recebimento e a transmissão de uma grande quantidade de dados de estado em execução em tempo real (runtime) (Erl, 2009). O gerenciamento das informações de estado quando é feito dentro do próprio serviço torna uma abordagem na construção de uma lógica confiável. Pois é bem mais fácil manter e evoluir um serviço que tenha total controle sobre seu próprio processamento de estado. Porém quando essa responsabilidade é transferida há uma arquitetura externa alguns benefícios são claramente identificados como: o reuso e a divisão de responsabilidades. Mas as dependências resultantes do design e a opção do controle externo precisam ser cuidadosamente avaliadas em longo prazo, principalmente. Outro cuidado fundamental que deve ser observado é a questão do desempenho em runtime, pois quando são criadas mais camadas há uma possibilidade de se ter uma sobrecarga de processamento. A Tabela 7 ilustra com mais detalhes o perfil do serviço para atender o princípio da independência de estados, expondo as suas características e os objetivos (Erl, 2009).
  • 27. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 27 Perfil do princípio Breve definição Serviços minimizam a dependência de estado. Definição completa Serviços são explicitamente projetadas para minimizar o período durante o qual eles existem em uma condição de dependência de informações de estado. Objetivos 1. Aumentar a escalabilidade do serviço; 2. Dar suporte ao design de lógica agnósticos e aprimorar o potencial do reuso do serviço. Característica de design O que torna a independência de estado de serviço um princípio quase único é o fato de que ela promove uma condição do serviço que, por natureza, é temporária. Dependendo do modelo de serviço e da abordagem de diferimento de estado utilizados, diferentes tipos de características de design podem ser implementados. Tabela 7: Perfil do princípio da independência de estado do serviço. 2.2.7 Visibilidade do serviço A visibilidade do serviço, como o nome já diz, tem como objetivo principal fazer com que o serviço se torne visível a todos, aumentando assim a agilidade, a produtividade e a confiabilidade dos consumidores. Os serviços são projetados para que sejam encontrados e seus propósitos e capacidades sejam claramente entendidos, ou seja, os contratos de serviços devem ter metainformações extras que transmitem claramente o que o serviço realmente faz (Erl, 2009). A aplicação desse princípio após a implantação de um serviço pode comprometer a qualidade da sua visibilidade, portanto é uma boa prática adicionar as metainformações antes do lançamento da versão inicial. Existe um protocolo que especifica um método para publicar e descobrir
  • 28. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 28 diretórios de serviços em uma arquitetura orientada a serviços, que é conhecido como UDDI (Universal Description, Discovery Integration) que será abordado no Capítulo 3. A visibilidade de serviço afeta alguns outros princípios, mas afeta principalmente a capacidade de reuso. Os serviços ou funcionalidades devem ser encontrados, é necessário que sejam flexíveis e que seus propósitos e capacidades sejam claros para que outros possam utilizá-los. Erl (2009) também afirma que: “Alcançar esse objetivos requer a previsão e uma boa compreensão da natureza do próprio serviço. Dependendo do tipo do modelo de serviço que é projetado, perceber esse princípio pode exigir perícia nos negócios, assim como perícia técnica.”. A Tabela 8 destaca estas características segundo a visão de Erl (2009). Perfil do princípio Breve definição Serviços são visualizáveis. Definição completa Os serviços são projetados para serem efetivamente descobertos e interpretados para que, na descoberta, seu propósito e capacidades sejam claramente entendidos. Objetivos 1. Os serviços são posicionados como recursos altamente visualizáveis dentro da empresa; 2. O propósito e capacidades de cada serviço são claramente expressos para que eles possam ser interpretados. Característica de design Tabela 8: Perfil do princípio da visibilidade do serviço. 2.2.8 Composição de serviços A composição de serviços permite que as capacidades de um serviço
  • 29. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 29 sejam combinadas várias vezes com as de outros serviços em novas configurações a fim de resolver problemas diferentes. Por exemplo, um serviço que tem como entrada o CEP e informa qual o endereço de destino, utilizando um serviço dos correios. Também informando qual o melhor custo benefício na cobrança do frete, o que corresponde a outro serviço dos correios. Portanto, a composição desses serviços soluciona um determinado problema, mas esses serviços estando isolados e postos em outras composições solucionariam outros tipos de problemas. Os serviços devem ser quebrados ou decompostos em unidades menores, para aumentar a capacidade de reuso e solucionar um número maior de problemas de forma mais ágil e eficiente. Na composição de serviços quando é formada em grandes escalas, com muitos serviços, deve-se ter uma atenção voltada aos pontos que podem ter um custo excessivo de tempo, pontos estes que se assemelham a um “gargalo”. Visto que o desempenho do serviço controlador que encapsula uma composição de diversos serviços adicionais, será sempre determinado pela sua composição. Contudo para tentar evitar que gere este “gargalo” é importante entender com mais detalhes e precisão as definições e características deste princípio, portanto segue abaixo a Tabela 9 que expõe algumas informações importantes segundo Erl (2009).
  • 30. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 30 Perfil do princípio Breve definição Serviços são componíveis Definição completa Serviços são projetados para que atuem como participantes eficazes de uma composição, independente do tamanho e da complexidade da composição. Objetivos Ao discutir os objetivos da composição de serviços, boa parte dos objetivos de reúso de serviços também é aplicável. Isso ocorre porque, muitas vezes, a composição de serviços é uma forma de reúso de serviços. De fato, talvez você se lembre de que um dos objetivos que selecionamos para o principio da capacidade de reúso era possibilitar a composição de serviços em larga escala. Contudo, além de simplesmente alcançar o reúso, a composição de serviços fornece o meio pelo qual podemos alcançar o que muitas vezes é classificado como o objetivo final da computação orientada a serviços. Ao estabelecer uma empresa composta de lógica representada por um inventário de serviços altamente reusáveis, fornecemos o meio para que uma grande extensão dos futuros requisitos da automação de negócios sejam cumpridos por meio da composição de serviços.
  • 31. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 31 Característica de design para capacidade de membros de uma composição Idealmente, cada capacidade de serviço, especialmente aquelas que fornecem lógica reusável, é considerada um membro potencial de uma composição. Isso significa essencialmente que as características de design já estabelecidas pelo princípio da capacidade de reúso de serviços são igualmente relevantes para criar membros de composição eficazes. 1. O serviço precisa possuir um ambiente de execução altamente eficiente. Além de ser capaz de gerenciar a simultaneidade, a eficiência com a qual os membros da composição realizam o processamento individual deve ser bem sintonizada. 2. O contrato de serviços precisa ser flexível, para que possa facilitar diferentes tipos de requisitos de troca de dados para funções semelhantes. Isso se relaciona tipicamente a capacidade do contrato de trocar o mesmo tipo de dados em diferentes níveis de granularidade. A maneira como essas qualidades ultrapassam o mero reúso tem a ver principalmente com o fato de o serviço ser capaz de otimizar o processamento em runtime para dar suporte a várias composições simultâneas.
  • 32. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 32 Característica de design para capacidades do controlador de composição Os membros de uma composição, muitas vezes, também precisam atuar como controladores ou subcontroladores em diferentes configurações de composição. Contudo, as exigências de alto desempenho impostas aos membros de composição geralmente são reduzidas aos serviços que são projetados como controladores. Esses tipos de serviços possuem, portanto, um conjunto próprio de características de design, a saber: 1. A lógica encapsulada por um controlador quase sempre está limitada a uma tarefa de negócios exclusiva. Comumente, é utilizado o modelo de serviço-tarefa, que resulta na aplicação de características comuns a esse modelo de serviços; 2. Embora os controladores possam ser reusáveis, normalmente o reuso de serviços não é uma consideração primária do design. Portanto, as características de design promovidas pela capacidade de reuso de serviços são consideradas e aplicadas onde apropriado, mas com menos rigor do que o habitualmente aplicado a serviços agnósticos; Naturalmente, qualquer capacidade que atue como controlador pode se tornar membro de uma composição maior, o que também leva em consideração as características de design de membro de composição anteriormente listadas. Tabela 9: Perfil do princípio da composição de serviço.
  • 33. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 33 Capítulo 3 Tecnologias Neste capitulo será citado e definido o conceito das tecnologias mais utilizadas na construção da Arquitetura orientada a serviços (SOA). SOA tem como boa prática, a utilização de tecnologias já conhecidas no mercado. Web service é uma das tecnologias que torna um serviço disponível na grande internet, por exemplo. Vamos agora detalhar sobre algumas tecnologias utilizadas no mundo dos serviços. 3.1 Web service Segundo Sonda & Montez (2004), “Tecnologias de Web Services surgiram recentemente como uma resposta à busca de interoperabilidade entre aplicações que oferecem serviços na web”. “Os Web services são na essência interoperabilidade-conectando programas e aplicações a outros programas e aplicações, especialmente quando estes são desenvolvidos usando diferentes linguagens, ferramentas ou plataformas” (Oliveira E. C., 2009). Segundo Gartner: “Web services são componentes de software com baixo fator de desacoplamento, utilizado por meio de padrões de internet. Um web service representa uma função de negócio ou um serviço que pode ser acessado por uma outra aplicação, sobre redes públicas e, geralmente, disponibilizado por protocolos conhecidos.” O Web service (Figura 2) é baseado em vários padrões de tecnologias XML, SOAP, WSDL e UDDI que revolucionaram a comunicação na web. Basicamente o Web service é o intermediador entre as aplicações, independente de qual plataforma esteja sendo utilizada. Um serviço web utilizando essas tecnologias podem ser processados em uma internet, intranet ou em qualquer outro tipo de rede, mas que use endereçamento IP.
  • 34. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 34 Em Engenharia de software, Sommerville (2007, p. 189) diz que um Web service é uma instância de uma noção mais geral de um serviço e, cita a definição proposta por Loverlock como: “Uma ação ou desempenho oferecido de um grupo para outro. Embora o processo possa estar ligado a um produto físico, o desempenho é essencialmente intangível e não resulta normalmente em prioridade de algum dos fatores de produção”. Figura 2: Web Service. (Oliveira E. C., 2009) 3.2 XML XML é uma linguagem de marcação para necessidades especiais, diferente do HTML (Wikipedia, 2010) que foi feito para Web e já tem suas tags pré- definidas. O XML (Figura 3) pode ser utilizado em vários contextos de aplicações e não existe tag pré-definidas. É um subtipo de SGML (acrônimo de Standard Generalized Markup Language, ou Linguagem Padronizada de Marcação
  • 35. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 35 Genérica) capaz de descrever diversos tipos de dados. Segundo o W3C, o criador do XML, sua principal característica é criar uma infra-estrutura única para diversas linguagens, para que linguagens desconhecidas e de pouco uso também possam ser definidas sem maior trabalho e sem necessidade de serem submetidas aos comitês de padronização. A W3C em meados da década de 1990 começou a trabalhar em uma linguagem que tivesse a flexibilidade da SGML e com a simplicidade do HTML. O princípio do projeto era criar uma linguagem que pudesse ser lida por software, e integrar-se com as demais linguagens. Sua filosofia seria incorporada por vários princípios importantes: 1. Separação do conteúdo da formatação 2. Simplicidade e Legibilidade, tanto para humanos quanto para computadores 3. Possibilidade de criação de tags sem limitação; 4. Criação de arquivos para validação de estrutura; 5. Interligação de banco de dados distintos; 6. Concentração na estrutura da informação, e não na sua aparência.
  • 36. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 36 Figura 3: Exemplo de um arquivo XML. (Wikipédia, 2010) 3.3 SOAP SOAP, vem do inglês Simple Object Access Protocol, é um protocolo para troca de informações, utilizando tecnologias baseadas em XML (W3C). O SOAP tem segundo a Wikipédia (2010): 1. Mecanismo para definir a unidade de comunicação; 2. Mecanismo para lidar com erros; 3. Mecanismo de extensão que permite evolução; 4. Mecanismo entre SOAP e o HTTP, representar tipos de dados em XML. A estrutura básica do SOAP é o envelope que contem as informações a serem enviadas ao servidor. O cabeçalho que pode conter alguns dados como namespace. O cabeçalho fica dentro do envelope. Encontrando-se também neste envelope o body. No body contém o documento que tem as informações a serem trocadas com o servidor, quais serviços deseja executar e o fault (falha), que
  • 37. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 37 retorna uma mensagem de status do retorno da requisição como mostra a Figura 4 abaixo: . Figura 4: Exemplo de um envelope SOAP. (Wikipédia, 2009) O processo de comunicação SOAP tem seu início a partir do momento em que o cliente (Client) envia os dados, que através do HTTP são enviados para o servidor (Web Server) em uma estrutura pré-definida. Logo após o servidor receber esses dados, o mesmo faz todo o processo de verificação e processando assim as informações. Depois o servidor retorna os dados em uma estrutura SOAP. A Figura 5 ilustra este cenário com mais detalhes.
  • 38. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 38 Figura 5: Exemplo de um web service utilizando SOAP. (MSDN Microsoft, 2003) 3.4 WSDL O WSDL (Web Services Description Language) é o contrato onde estará toda a estrutura que o XML deve ser montado, para que o serviço requisitado entenda o que se deseja, os dados com que vão trabalhar e em qual estrutura deve ser enviado o retorno ao consumidor. A definição do WSDL segundo o W3C (2001) é:
  • 39. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 39 “WSDL é um formato XML para descrever serviços de rede como um conjunto de parâmetros operacionais sobre as mensagens que contenham qualquer documento orientado ou procedimento de informação orientada. As operações e mensagens são descritas abstratamente, e em seguida, vinculado a um protocolo de rede de concreto e formato de mensagem para definir um ponto de extremidade. Parâmetros concretos são combinados em parâmetros abstratos (serviços). WSDL é extensível para permitir a descrição dos parâmetros e suas mensagens, independentemente dos formatos que mensagem ou protocolos de rede são usados para comunicar-se...” A Figura 6 ilustra um diagrama em XML, de um documento WSDL 2.0 segundo a W3C (2001): Figura 6: Diagrama de um documento WSDL. (W3C ,2001)
  • 40. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 40 O WSDL faz o intermédio entre o SOAP com o cliente e o SOAP com o servidor. O SOAP manda os dados para o WSDL e ele interpreta os dados montando assim um XML, que faça com que o cliente e servidor, entendam as informações solicitadas e retornadas. 3.5 UDDI Definimos UDDI como um protocolo que define um método padrão para a publicação e descoberta da rede, baseada em componentes de software de uma arquitetura orientada a serviços aprovada pelos padrões OASIS (2006) que é um membro importante na linha de Web services. UDDI é como um catálogo de serviços que o servidor dispõe. Lá são mostrados quais serviços tem no servidor, os quais são permitidos de acordo com a regra de restrições. A relação conceitual entre UDDI e outros protocolos, na pilha de serviços da Web, é ilustrada na Figura 7 abaixo (OASIS, 2006): Figura 7: Exemplo da relação do UDDI entre outros protocolos. (OASIS, 2006)
  • 41. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 41 Basicamente o servidor publica via SOAP no UDDI os serviços que ele tem. A camada SOAP do UDDI interpreta e armazena a descrição dos serviços, pois quando o cliente solicitar uma lista de serviços, que ele possa utilizar, será retornado via SOAP ao cliente, a qual poderá ser utilizada. 3.6 ESB ESB (Enterprise Service Bus) serve como um intermediador entre serviços. Ele se comunica com os serviços, independente de qual plataforma é usada. Não importa se seja um serviço em Java solicitando outro serviço em PHP. O ESB deixa transparente a troca de informações entre eles. O uso da tecnologia ESB seria uma boa solução em, por exemplo, uma empresa que tenha um sistema desenvolvido em uma plataforma, que tenha um protocolo de comunicação diferente com o qual irá interagir. De início pode-se utilizar de outras formas mais simples para realizar essa troca de informações, mas supondo que após algum tempo, deve-se fazer integrações entre outros serviços com protocolos diferentes. Por tanto para haver essa comunicação entre aplicações ou serviços, cada um deverá desenvolver diversos tipos de protocolos, para atender qualquer tipo de requisição SOAP. Pesando em uma forma de centralizar o desenvolvimento de diversos tipos de protocolos para as trocas de informações, utiliza-se a tecnologia ESB. A qual é responsável pelo transporte dos dados de maneira assíncrona e síncrona. Sendo esta responsável por mandar as informações para seu destino, interpretar, processar e tratar as informações a serem retornadas como mostra a Figura 8.
  • 42. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 42 Figura 8: Exemplo de uma aplicação SOA utilizando ESB. (Progress Software, 2010) Neste exemplo, a ESB está fornecendo a conectividade com o roteamento entre os serviços; a transformação de dados XML, a qual permite a comunicação dos serviços com diferentes interfaces; e o processo de sequenciamento de negócios de serviços (Progress Software, 2010).
  • 43. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 43 Capítulo 4 Implantando SOA em uma empresa TI Neste capítulo serão abordadas sugestões baseadas em pesquisas de especialistas na implantação da arquitetura orientada a serviços, ou seja, SOA. A implantação da arquitetura orientada a serviços dentro de uma empresa de tecnologia da informação trata-se um trabalho árduo e deve ser muito bem estudado. O primeiro passo que toda empresa, a qual tenha como objetivo de adotar o conceito de SOA dentro de sua organização é capacitar seus colaboradores ou contratar pessoas já capacitadas. Este ponto é bastante conflituoso, pois a capacitação dos funcionários estará abrindo novas portas para o mercado vizinho e novas oportunidades aparecerão. Contudo, sem essa formação dos envolvidos a possibilidade de sucesso é muito remota e uma coisa é certa, pensar e produzir orientada a serviços não é simples e nem comum. Visto que um paradigma novo sempre demonstra dificuldades. Depois de todos os colaboradores estarem preparados, deve ser escolhido um projeto piloto para a aplicação do conceito de SOA e posteriormente expandi- lo para toda a organização. Um ponto importante que deve ser levantado na transição para o conceito de orientação a serviços no projeto piloto, é definir as responsabilidades de cada um, pois para uma tarefa tão complexa não cabe apenas aos desenvolvedores, ou analista, ou gerentes de negócios pensarem e definirem este novo conceito de arquitetura. Para a implantação ter sucesso todos os papéis acima citados devem participar dentro de sua capacidade, ou seja, os desenvolvedores ficarão envolvidos sobre os problemas tecnológicos e as melhores escolhas, os analistas referentes às definições de negócios de design, enfim cada a um será incumbida uma responsabilidade.
  • 44. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 44 Para os projetos que já estão em andamento essa transição se torna um pouco mais complexa, tendo em vista que tudo já está definido e um maior re- trabalho será inevitável. No entanto existe esta possibilidade e a mesma será abordada neste capítulo. 4.1 Implantação em um novo projeto Quando a organização define que irá aderir ao SOA, é preciso se ter a certeza que novos projetos nascerão baseados nessa arquitetura. As pessoas que ficarem responsáveis por desenhar a arquitetura do projeto devem ter o projeto de SOA em mente. (Ângelo, 2005) É interessante que o sistema piloto escolhido seja simples e que suas funcionalidades, que farão parte do serviço na arquitetura orientada a serviços, tragam em um pequeno espaço de tempo benefícios para a organização, ou seja, que sejam utilizadas por outros sistemas e / ou projetos. Essas funcionalidades devem ser de fácil desacoplamento da apresentação. A escolha deste piloto é de extrema importância para a visualização, da diretoria da companhia, dos benefícios trazidos. Estes ganhos com a implantação de SOA é notada rapidamente pela garantia de longevidade que o sistema ganha e em médio prazo a empresa vai alcançar uma alta produtividade no desenvolvimento. Uma dica boa para a identificação das funcionalidades do sistema piloto, chaves para a implantação, é transformar alguns componentes, que já são utilizados em várias partes da própria aplicação e que claramente poderão ser utilizados por outros, em serviços. 4.2 Adaptação dos projetos já em andamentos É recomendado que as organizações comecem a implantar SOA aos poucos, podendo ser feita em etapas assim que as demandas forem surgindo.
  • 45. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 45 Deve ser aplicado inicialmente em processos críticos, onde a lógica de negócios possa ser facilmente desagregada da parte da apresentação. Existem inúmeras situações em que projetos já em andamentos, necessitem adotar SOA. Porém sempre deve ser levada em consideração se há a possibilidade desta adaptação na arquitetura atual do sistema. Um design bem feito torna esta adaptação um pouco mais simples. Se a escolha da mudança de arquitetura não foi feita pela equipe de desenvolvimento por necessidade do projeto ou pelo cliente e sim uma mudança de paradigma da empresa. Então este projeto deve ser um experimento para futuras estimativas e definições das melhores tecnologias. Implantar SOA é um desafio muito grande para a organização, maior até do que o desafio técnico. Portanto deve haver um alinhamento entre as tecnologias utilizadas e os objetivos de negócio da empresa. Para ter uma abstração das formas de comunicação das aplicações e serviços, deve ser implementado o Enterprise Service Bus (ESB) fazendo com que tecnologias e ferramentas fiquem irrelevantes. 4.3 Cenário de implantação de SOA em uma empresa de TI Neste capítulo vamos abordar as fases da implantação do conceito de SOA, dentro da organização, utilizando com boas práticas de governança. Segundo Zaidan (2009) a revista Decision Report “A implementação correta com boas práticas de governança a reutilização dos serviços implementados pode atingir mais de 80% de reuso. Isso, consequentemente, maximiza o retorno sobre o investimento”. Atingir estes 80% equivale a uma probabilidade muito remota, comparada com as arquiteturas tradicionais. Segundo a revista Decision Report (Zaidan, 2009), “No Brasil, um dos projetos que foi implementado no setor de telecomunicações houve 65% de reutilização dos serviços”.
  • 46. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 46 Como foi dito antes é fundamental a migração ser feita por etapas, pois se não, pode trazer sérios problemas, por exemplo, alteração de uma só vez o dia-a- dia de todos os funcionários de desenvolvimento; a existência de muitos sistemas para serem alterados não sendo possível a concentração dos esforços nos detalhes necessários. Pelos casos já reportados de projetos que grandes números de sucesso são feitos em fases, primeiro capacitando os funcionários, depois escolhendo um projeto piloto, realiza a migração e observa o funcionamento para no futuro repetir esses mesmos procedimentos para o resto dos projetos da empresa. A figura 7 representa as etapas de migração para SOA, que segundo Gartner (2008) é o cenário ideal para empresas grandes com muitos sistemas distribuídos, utilizando a prática de governança. A primeira etapa é pouco longa e difícil, que consta na definição do projeto piloto e na construção de serviços, que já tragam ganhos. SOA inicialmente não trará retorno sobre o investimento, pois a reutilização só aparecerá nos próximos sistemas, então o CIO deve selecionar pilotos que tragam mais benefícios de negócios. A segunda fase é a mais longa, pode durar até quatro anos, dependendo da infra-estrutura e da maturidade do processo da empresa. É nesta fase que colocarão os experimentos do projeto piloto em construção em todos os outros existentes na organização. Este tempo de quatro anos é relativo, pois dependente muito de quantos projetos irá fazer a migração e suas complexidades. Neste momento é fundamental a criação do repositório de serviços, pois é a partir dele, que serão encontradas as funcionalidades ou os serviços que serão reutilizados por outras aplicações. Ao final dessa etapa chega-se a um bom cenário organizacional: serviços estão implantados, existe reaproveitamento, controle do ambiente, registro de serviços e políticas de governança implantadas. Neste ponto a organização começa a perceber que os novos projetos começam a serem mais ágeis, baratos
  • 47. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 47 e com menos chances de problemas, ou seja, quanto maior for o nível de reutilização, menor o desenvolvimento e os problemas. A última fase é o cenário estável da organização, os sistemas existem com conceitos de serviços, todos estão no repositório. Não existem serviços duplicados e existe alta taxa de reuso. Nesta fase deve-se pensar no futuro, por exemplo, novos serviços devem seguir o processo de desenvolvimento e as políticas organizacionais. A utilização de serviços deve ser feita via repositório com um contrato formal de prestação de serviço. Isso tudo se aplica para grandes empresas (Gartner, 2008). A ilustração das definições das etapas de implantação segundo Gartner (2008) segue abaixo: Figura 9: Cenário de implantação de SOA para grandes empresas. (Gartner, 2008) Para empresas de médio porte, sugere-se a utilização também de um piloto, mas que ele seja utilizado como experimento onde possam ser exaustivamente repetidas as ações de migração para cada área da empresa. Posteriormente devem ser analisados os resultados das ferramentas escolhidas e
  • 48. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 48 dos sistemas pilotos. A segunda etapa é a implantação no setor onde foi feito o piloto anteriormente, depois sendo repetido o processo para cada área da empresa quantas vezes forem necessário. A última etapa, da mesma forma que o modelo anterior, é quando a organização já está com a toda a política de governança definida e os serviços implantados. O importante é garantir que os colaboradores da organização sigam as políticas definidas, para que não haja, por exemplo, serviços repetidos. Figura 10: Cenário de implantação de SOA para médias e pequenas empresas. (Gartner, 2008) As propostas mostradas neste trabalho não irão atender ou não serão ideais para todas as empresas, pois é necessária uma análise mais aprofundada para cada situação.
  • 49. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 49 Capítulo 5 Considerações finais Neste capítulo serão abordadas as considerações finais para aumentar o embasamento, e as dificuldades encontradas para a criação e confecção deste documento. O conceito da orientação a serviços, ou melhor, da arquitetura orientada a serviços, de implantar nos projetos, é mais uma tentativa de melhoria para ajudar as empresas de tecnologia da informação em aumentar a produtividade, a qualidade de softwares e posteriormente a satisfação dos clientes. Visto que as empresas que vivem de projetos devem sempre assistir. Uma coisa é certa, SOA não realiza nenhum milagre e não é a solução de todos os problemas. Fazendo apenas uma analogia referente a processos, que hoje em dia todos os projetos querem utilizar a metodologia Scrum achando que é a solução dos problemas de atrasos, de falhas de planejamento, que segundo Schwaber (2004) – principal formalizador da metodologia – Scrum é: "... o mais perplexo e paradoxal processo para gerenciamento de projetos complexos. Porém, Scrum é incrivelmente simples. [...] Scrum não é um processo prescritivo; ele não descreve o que fazer em cada circunstância. Ele é usado para trabalhos complexos nos quais é impossível predizer tudo que irá acontecer.". Esta mesma falta de conhecimento se encaixa com SOA, que os leigos acreditam que irá solucionar o problema de códigos mal feitos, de bugs, de atrasos. Já é comprovado que SOA é um conceito de sucesso, mas deve ser muito bem estudado antes de ser utilizado e que necessita de uma maturidade de arquitetura, design e análise muito grande da equipe. Algumas dificuldades nas realizações da pesquisa para o desenvolvimento deste documento foram encontradas. Encontrar profissionais engajados neste
  • 50. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 50 conceito é complicado. Para este trabalho foi criado um questionário para levantamento de soluções para alguns princípios e que menos de 16,66% das pessoas foram capazes de respondê-lo por inteiro. Então talvez a primeira etapa ou barreira que as empresas devem enfrentar seja a qualificação dos seus funcionários em treinamentos e palestras; para que a equipe não “mate” SOA e SOA não “mate” o projeto. 5.1 Contribuições Neste trabalho foi apresentado um estudo de implantação do conceito da arquitetura orientada a serviços – SOA – que mesmo sendo aplicada em uma arquitetura definida. Espera-se que seja possível ser aplicado em praticamente qualquer projeto de uma fábrica de software, sabendo de algumas limitações técnicas e dos clientes. A seguir, uma síntese da proposta oferecida de implantação de SOA: 1. Identificar ou contratar funcionários capacitados para a implantação ou capacitá-los, afim de que esta mudança seja um caso de sucesso e não um investimento perdido; 2. Depois de ter uma equipe capacitada deve ser identificado um projeto ou sistema piloto que servirá como experimento de mudança, obtendo dados para estimativas e informações sobre melhores tecnologias; 3. Identificação de funcionalidades estratégicas, que trarão ganhos importantes e rápidos para a organização; 4. Os responsáveis devem se reunir e identificar os riscos dessa mudança e levantar as ações que deverão ser tomadas; 5. Implementar o conceito de SOA nas funcionalidades escolhidas;
  • 51. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 51 6. Depois de ter finalizado o desenvolvimento da aplicação piloto, vem o momento mais crucial, identificar novas funcionalidades de projetos em andamento ou já concluídos; 7. Transformação dessas novas funcionalidades em serviços, utilizando o conceito de SOA e o adaptando nos projetos desejados. Em projetos que já estão concluídos, só deve ser feito esta modificação com a permissão do cliente em questão, pois pode gerar novos erros; 8. Por fim, institucionalizar a nova arquitetura e capacitar todos os funcionários que estarão envolvidos. 5.2 Trabalhos futuros Como trabalho futuro, sugere-se que as fábricas de softwares capacitem os seus funcionários e comecem a criar projetos pilotos, aplicando o conceito da orientação de serviços, tendo como base neste trabalho de pesquisa que foi realizado. A partir disto será possível fazer um aperfeiçoamento das arquiteturas, pensando no reaproveitamento de código e diminuindo o retrabalho. Com esta idéia de SOA, poderão surgir novos produtos dentro da organização, pois a idéia de desvincular as funcionalidades da camada de apresentação facilita nessa identificação. Afirmo isso por experiência própria, pois existe um sistema na empresa em que trabalho. Pois da maneira que foi implementado e imposto pelo cliente fica complicada a extração de um produto. No entanto se desde o início tivesse a mentalidade da orientação a serviços, com certeza a criação e a identificação deste produto seriam certas. Espero que em trabalhos futuros tenha a oportunidade de arquitetar um projeto adotando o conceito de SOA, sendo o piloto. Esperando que posteriormente este conceito seja difundido em toda a organização, podendo dar consultorias em empresas que pretenderão fazer o mesmo.
  • 52. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 52 Pretendo também difundir uma idéia de criação de serviços para as ferramentas de persistências modelos relacionais. Os frameworks ou aplicações não se preocupariam em implementar a conexão, o modo de persistir, log de sistemas e sim seria apenas configurações que o serviço disponibilizaria. Com isso evitaria alguns erros que acontecem sempre em todos os projetos. É uma idéia que ainda não foi bem fundamentada, mas que pretendo me inteirar mais e saber se existe viabilidade para o mesmo. 5.3 Aprendendo a vender SOA na sua empresa O lema ou o grande desafio das empresas de tecnologia da informação é diminuir os custos e aumentar a agilidade. Então a Arquitetura Orientada a Serviços (SOA) vem para superar esses desafios e colocar “um ponto final” nesta preocupação. Mas nos profissionais técnicos, não sabemos vender essa idéia para nossa própria empresa, principalmente referindo-se ao fato de que os benefícios de SOA não se podem dispor. É necessário mostrar para os diretores da sua empresa os benefícios que esta nova arquitetura trará, segue a lista abaixo: 1. Redução do desenvolvimento duplicado 2. Simplificação da integração entre aplicações 3. Aumento da qualidade das funcionalidades 4. Redução do custo de manutenção das aplicações 5. Flexibilidade na alteração de processos de negócio 6. Agilidade na análise de impacto 7. Conhecimento dos ativos existentes E segundo um artigo de Kleber Bacilo (2009) algumas métricas para
  • 53. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 53 usarmos no cálculo da economia: 1. Reuse Cost Avoidance: trata-se do quanto a empresa economiza por não ter que desenvolver novamente as mesmas funcionalidades. Digamos que para construir um determinado serviço foram necessárias 100 horas. Cada vez que se reutilizar esse serviço, praticamente 100 horas – ou pelo menos uma parte delas – serão economizadas. 2. Consistency: a mesma lógica de negócio desenvolvida várias vezes pode causar comportamentos diferentes dependendo da aplicação e, sempre que muda, é necessário mudar em todos os locais onde esteja implementada. 3. Maintenability: uma parte significativa do orçamento de TI é gasta apenas mantendo as aplicações existentes funcionando. Redução nos custos de manutenção com integrações mais fáceis de manter e componentes isolados sendo reutilizados, e com nível de qualidade já atestada, impactam de forma muito positiva o uso racional dos recursos de TI. 4. Agility: Conseguir fazer a análise de impacto mais rapidamente e promover mudanças nas aplicações e processos de negócios no tempo demandado pelas áreas de negócio é uma argumentação muito efetiva quando relacionado ao business case de SOA. Além de todos esses cálculos, devem ser apresentados para a diretoria da empresa, os investimentos que precisarão ser feitos para a utilização de SOA. Segue abaixo alguns dos itens essenciais para atingir os resultados, tão empolgantes, citados anteriormente (Kleber Bacilo, 2009). 1. Capacitação dos colaboradores; 2. Elementos de infra-estrutura, mas inicialmente tentar utilizar o que a empresa já dispõe e colocar as licenças dos anos seguintes;
  • 54. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 54 3. Consultorias externas, visando diminuir a quantidade de erros e proporcionando melhores futuros; 4. Selecionar uma equipe pioneira dentro da empresa e calcular o custo que esta equipe terá para ficar alocada apenas para a implantação. É importante exibir os investimentos necessários, mas lembrem que investimento para empresa é sinônimo de custos. Então sempre exiba um item de investimento e enumere 10 pontos de vantagens. Boa sorte e boa venda.
  • 55. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 55 Referências Ângelo, F. K. (24 de novembro de 2005). Entenda como e quando implantar SOA. Acesso em 01 de março de 2010, disponível em Computerworld Porta-voz do mercado de TI e comunicação: http://computerworld.uol.com.br/gestao/2005/11/24/idgnoticia.2006-03- 29.9253581963/ Bacili, K. (2009 de julho de 14). Aprenda a calcular o ROI em SOA. Acesso em 10 de fervereiro de 2010, disponível em Aquele Blog de SOA: http://www.aqueleblogdesoa.com.br/2009/07/aprenda-a-calcular-o-roi-em-soa/ Davis, A., & Zhang, D. (2002). A comparative study of DCOM and SOAP. Acesso em 22 de março de 2010, disponível em IEEE Xplore Digital Library: http://ieeexplore.ieee.org/search/srchabstract.jsp?tp=&arnumber=1181595&query Text%3Dsoap%26openedRefinements%3D*%26searchField%3DSearch+All Erl, T. (2009). SOA Princípios de design de serviços. São Paulo: Pearson Prentice Hall. Gabriel. (03 de novembro de 2008). O que é SOA. Acesso em 13 de novembro de 2009, disponível em Aquele blog de SOA: http://www.aqueleblogdesoa.com.br/2008/11/o-que-e-soa/ Gabriel. (05 de março de 2009). Princípios Básicos de SOA – Contrato Formal. Acesso em 15 de novembro de 2009, disponível em Aquele Blog SOA: http://www.aqueleblogdesoa.com.br/2009/03/principios-basicos-de-soa-contrato- formal/ Gabriel. (02 de março de 2009). Princípios Básicos de SOA – Serviços Reutilizáveis. Acesso em 20 de novembro de 2009, disponível em Aquele blog de SOA: http://www.aqueleblogdesoa.com.br/2009/03/principios-basicos-de-soa- servicos-reutilizaveis/
  • 56. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 56 Gabriel. (12 de maio de 2009). Princípos Básicos de SOA – Serviços Abstraem a Lógica. Acesso em 10 de 11 de 2009, disponível em Aquele blog de SOA: http://www.aqueleblogdesoa.com.br/2009/05/principos-basicos-de-soa- servicos-abstraem-a-logica/ Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (2000). Padrões de Projeto Soluções reutilizáveis de software orientado a objetos. Porto Alegre: Bookman. Gartner. (s.d.). Practitioner’s Guide: Best Practices in Enterpricewide SOA Initiatives. Acesso em 18 de fervereiro de 2010, disponível em Gartner: 2010 Hurwitz, J., Bloor, R., Kaufman, M., & Halper, F. (2009). Arquitetura Orientada a serviços – SOA para Leigos (2 ed.). Rio de Janeiro: Alta Books. Martin David, B. M. (agosto de 2002). Web Service Definition Language (WSDL). Acesso em 03 de 03 de 2010, disponível em Web Service Definition Language (WSDL): http://www.ai.sri.com/daml/services/daml-s/0.7/daml-s- wsdl.html Min Luo Goldshlager, B. L.-J. (15 de julho de 2005). Designing and implementing Enterprise Service Bus (ESB) and SOA solutions. Acesso em 10 de março de 2010, disponível em IEEE Xplore Digital Library: http://ieeexplore.ieee.org/search/freesrchabstract.jsp?reload=true&tp=&arnumber= 1524413&queryText%3DESB%26openedRefinements%3D*%26searchField%3D Search+All MSDN Microsoft. (01 de outubro de 2003). Uderstanding WSDL. Acesso em 03 de 03 de 2010, disponível em MSDN: http://msdn.microsoft.com/en- us/library/ms996486.aspx MSW Métricas e Software. (s.d.). Qualidade de Software. Acesso em 20 de fervereiro de 2010, disponível em MSW Métricas e Software - Fábrica de Software: http://www.mswconsult.com.br/qualidade.html
  • 57. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 57 OASIS. (14 de agosto de 2008). UDDI 101. Acesso em 25 de fervereiro de 2010, disponível em UDDI Xml Org Online community for the Universal Description, Discovery, and Integration OASIS Stantard: http://uddi.xml.org/uddi- 101 Oliveira, E. C. (08 de abril de 2009). Tutoriais CTDO. Acesso em 20 de janeiro de 2010, disponível em Web Services: Java e XML juntos pela interoperabilidade: http://tutoriais.ctdo.com.br/tutoriais/linguagens-para-web- sites/xml/web-services-java-e-xml-juntos-pela-interoperabilidade.html Oliveira, M. (11 de fervereiro de 2009). Caso de Sucesso com SOA. Acesso em 10 de novembro de 2009, disponível em Aquele blog de SO: http://www.aqueleblogdesoa.com.br/2009/02/caso-de-sucesso-com-soa/ Progress Software. (2010). ESB ARCHITECTURE AND LIFECYCLE DEFINITION. Acesso em 03 de março de 2010, disponível em Progress Software Business Making Progress: http://web.progress.com/en/esb-architecture-lifecycle- definition.html RD Consultoria. (14 de fervereiro de 2009). Medindo Satisfação do Cliente. Acesso em 20 de fervereiro de 2010, disponível em Medindo Satisfação do Cliente RD Consultoria: http://www.rdconsultoria.com.br/topic.asp?TOPIC_ID=239&FORUM_ID=16&CAT_ ID=2&Forum_Title=Atendimento&Topic_Title=Medindo+a+satisfa%E7%E3o+do+c liente Rodrigues, R. (16 de janeiro de 2009). Estratégia de implantação SOA: negócios flexíveis, serviços governáveis. Acesso em março de 22, disponível em Administradores - O portal da administração: http://www.administradores.com.br/informe-se/informativo/estrategia-de- implantacao-soa-negocios-flexiveis-servicos-governaveis/20198/ Saturino, L. (26 de outrubro de 2009). Fábrica de Software e Tecnologia de ponta: resultados garantidos. Acesso em 28 de fervereiro de 2010, disponível em
  • 58. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 58 Baguete tecnologia e informação em um só lugar: http://www.baguete.com.br/artigosDetalhes.php?id=1039 Schmelzer, R. (28 de novembro de 2007). The Seven Levels of Loose Couplin. Acesso em 20 de janeiro de 2010, disponível em ZapThink SOA and Cloud Training, Consulting, and Community: http://www.zapthink.com/2007/11/28/the-seven-levels-of-loose-coupling/ Sommervile, I. (2007). Engenharia de software. São Paulo: Pearson Addison-Wesley. Sonda, G. C., & Montez, C. (01 de maio de 2004). Uma proposta de implementação de diferenciação de serviços na Arquitetura de Web Services. Acesso em 20 de janeiro de 2010, disponível em Artigo de Sonda e Montez: http://inf.unisul.br/~ines/workcomp/cd/pdfs/2508.pdf Standish Group. (23 de abril de 2009). Standish Newroom - CHAOS 2009. Acesso em 03 de 03 de 2010, disponível em The Standish Group: http://www1.standishgroup.com/newsroom/chaos_2009.php Ventura, J. (21 de julho de 2008). Baixo Acoplamento. Acesso em 21 de novembro de 2009, disponível em Aquele blog de SOA: http://www.aqueleblogdesoa.com.br/2008/07/baixo-acoplamento/ W3C. (15 de março de 2001). Web Services Description Language (WSDL) 1.1. Acesso em 25 de fervereiro de 2010, disponível em W3C Note: http://www.w3.org/TR/wsdl Wikipedia. (21 de março de 2010). HTML. Acesso em 28 de março de 2010, disponível em Wikipédia, a enciclopédia livre: http://pt.wikipedia.org/wiki/HTML Wikipédia. (01 de outubro de 2009). SOAP. Acesso em 2010 de ferveriero de 22, disponível em Wikipédia, a enciclopédia livre: http://pt.wikipedia.org/wiki/SOAP
  • 59. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 59 Wikipédia. (01 de abril de 2009). Web Service. Acesso em 20 de fervereiro de 2010, disponível em Wikipédia, a enciclopédia livre: http://pt.wikipedia.org/wiki/Web_service Wikipédia. (08 de março de 2010). Web Services Description Language. Acesso em 22 de ferveriero de 2010, disponível em Wikipédia, a enciclopédia livre: http://pt.wikipedia.org/wiki/WSDL Wikipédia. (16 de março de 2010). XML. Acesso em 10 de 01 de 2010, disponível em Wikipédia, a enciclopédia livre: http://pt.wikipedia.org/wiki/XML Zaidan, P. (03 de setembro de 2009). SOA atinge até 80% do reuso com governança, diz BearingPoint. Acesso em 10 de janeiro de 2010, disponível em Decision Report: http://www.decisionreport.com.br/publique/cgi/cgilua.exe/sys/start.htm?infoid=416 3&query=simple&search%5Fby%5Fauthorname=all&search%5Fby%5Ffield=tax& search%5Fby%5Fkeywords=any&search%5Fby%5Fpriority=all&search%5Fby%5 Fsection=all&search%5Fby%5Fstate=all&se
  • 60. Anexos Anexo I – Questionário para levantamento de informações da capacitação dos técnicos.
  • 61. Anexo I – Questionário para levantamento de informações da capacitação dos técnicos. “UMA PROPOSTA PARA IMPLANTAÇÃO DO CONCEITO DA ORIENTAÇÃO A SERVIÇOS EM UMA EMPRESA DE TI” 1º) Como seria o cenário de transição de uma empresa que não tem na cultura o conceito de orientação a serviços e mais ou menos quanto tempo levaria ? 2º) Como funcionária a versão final de um projeto, onde deve ser implantado no cliente ou hospedado em algum servidor, que algumas lógicas de negócio são serviços já implementado na empresa ? 3º) Como os desenvolvedores saberiam quais serviços utilizar, ou seja, de que forma e em que local ficarão armazenada essas informações ? 4º) Quando o cliente fica responsável pela Análise e / ou design do projeto e não tem na sua cultura trabalhar com orientação a serviços. Como a empresa de TI ou o projeto trataria isso, pensando que a empresa TI tem já vários serviços implementados e que seriam importantíssimos no desenvolvimento referente a agilidade e eficiência, pois estão bem estáveis ? 5º) Essa quinta questão eu deixo aberta para poderem comentar darem dicas ou falarem de alguma coisa importante que não foi questionada na perguntas anteriores.