avaliando soa em uma empresa de ti

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.


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


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

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


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

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

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

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

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


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

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

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


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

“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


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

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

o nível de independência aos seus consumidores.

A Tabela 6 explica com mais detalhes as suas características. (Erl, 2009)


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

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


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

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).


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

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


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

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

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

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

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

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

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

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

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

“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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

avaliando soa em uma empresa de ti

Technology