30 Engenharia de Software Magazine - Arquitetura Orientada a Servios

Jorge Dias Jr. josejorgejr@gmail.com

www.jorgediasjr.com

Doutorando em Cincia da Computao

(UFPE). Mestre em Cincia da Computao

(UFPE). Graduado em Cincia da Computa-

o (UFPB). Desenvolve pesquisas na rea

de SOA desde 2005. Possui vrios artigos

publicados em conferncias nacionais e

internacionais. Tem experincia como ana-

lista de TI na indstria, onde desenvolveu

sistemas no mbito do governo federal,

alm de ter atuado em vrios projetos da

iniciativa privada. Atualmente, professor

e pesquisador no Departamento de Cin-

cias Exatas da UFPB, Campus IV.

De que se trata o artigo?

SOA traz diversos benefcios em um contexto empre-

sarial. Porm no podemos simplesmente comprar

uma SOA em uma prateleira. Neste intuito, este arti-

go discute alguns desaos e ingredientes que devem

ser considerados e pensados na adoo de uma SOA.

Para que serve?

Mostrar alguns dos desaos e ingredientes que deve-

mos ter em mente e que precisamos denir para im-

plantarmos uma SOA em um contexto empresarial,

minimizando os riscos e as chances de fracasso.

Em que situao o tema til?

Em um contexto empresarial, SOA permite que or-

ganizaes com infra-estrutura de aplicaes frag-

mentadas, sob a administrao de diferentes reas

de negcio, possam integrar estas aplicaes no

nvel de servio. Alm disso, SOA permite um maior

alinhamento da TI com o negcio. Tendo estes bene-

fcios em mente, importante considerar os aspectos

tecnolgicos e no tecnolgicos que podem in$uen-

ciar o sucesso de sua adoo.

Arquitetura Orientada a Servios

Sobre o que voc precisa refletir para adot-la em um contexto empresarial

Em seu livro, Josuttis faz a seguin-te afirmao sobre Arquitetura Orientada a Servio (SOA): O problema que voc no pode simplesmente

comprar SOA, voc tem que entend-la e

viv-la. SOA um paradigma. SOA uma

maneira de pensar. SOA um sistema de va-

lores para a arquitetura e design [Josuttis, 2007]. Isso quer dizer que, assim como o paradigma de Orientao a Objetos, o paradigma Orientado a Servios requer aspectos tecnolgicos e no tecnolgicos para ser bem sucedido. Ou seja, alm do amparo ferramental, necessrio um conjunto de mtodos, tcnicas, processos e boas prticas para adotar uma SOA com sucesso.

Este artigo no tem o objetivo de apresentar um passo a passo de como adotar uma SOA em uma empresa, mas de mostrar alguns dos desafios e ingre-dientes que devemos ter em mente e que precisamos definir para implantarmos uma SOA, minimizando os riscos e as chances de fracasso.

Conceitos iniciaisExistem diversas definies sobre SOA

e servio, porm nenhuma delas tida como a oficial. Muitas destas definies

Abordagens Tradicionais de Desenvolvimento

Esta seo traz artigos que apresentam como e quando utilizar as diferentes abordagens

tradicionais de apoio ao desenvolvimento de projetos de software

Edio 22 - Engenharia de Software Magazine 31

PROJETO

vm de fornecedores que as definem de acordo com as solues que eles fornecem. Alguns exemplos de grandes fornecedores so a IBM, Microsoft e Oracle.

Iremos definir SOA de uma maneira bem simples: SOA uma forma de se projetar uma arquitetura baseada na composio de servios interoperveis e reutilizveis. A Figura 1 mostra os principais elementos de uma SOA: o fornecedor do servio aquele que implementa e tem domnio sobre um servio; o re-gistro de servio um repositrio onde fornecedores de servio podem registrar seus servios para que eles sejam localizados pelos consumidores; e o consumidor do servio aquele que localiza um servio e o executa. O contrato a especificao do servio que possui as informaes necessrias para que o consumidor possa localiz-lo e invoc-lo.

Figura 1. Principais elementos de uma SOA

Esta a idia simplista que temos sobre SOA. A seguir vamos analisar SOA em um contexto empresarial e quais os benefcios que este tipo de arquitetura traz para as organizaes.

SOA em um contexto empresarialAtualmente, muitas organizaes possuem um conjunto de

diferentes sistemas, aplicaes e arquiteturas com diferentes idades, tecnologias e plataformas. Alm disso, os processos de negcio destas organizaes esto sujeitos a mudanas, ou devido a alguma reestruturao de negcio, ou talvez devido abertura para novos parceiros de negcio. Neste contexto, como os sistemas da organizao conseguiro acompanhar estas mudanas? Este um cenrio ideal para se pensar em adotar uma SOA.

Neste contexto empresarial, SOA permite que organizaes com infra-estrutura de aplicaes fragmentadas, sob a admi-nistrao de diferentes reas de negcio ou departamentos, possam integrar estas aplicaes no nvel de servio. Portanto, as aplicaes destes departamentos se tornam fornecedores e consumidores de servios de outros departamentos.

Alm disso, servios representam bem funes de negcio e, portanto, so considerados uma boa maneira para desenvolver aplicaes que suportam processos de negcio, permitindo assim, alinhar TI s necessidades organizacionais. Cada servio representa uma determinada funcionalidade que mapeada para um passo, ou vrios passos, em um processo de negcio.

A Figura 2 ilustra esta idia. Perceba que os diferentes de-partamentos de uma empresa possuem diferentes sistemas de software que podem ser um CRM, um ERP, ou qualquer outro sistema que automatize processos de negcio do seu departamento. A idia disponibilizar a lgica desses sistemas em forma de servios interoperveis e reutilizveis. Acima desses servios, existe uma camada onde esto os processos de negcio que so executados atravs da invocao dos servios, ou seja, os servios so chamados em uma seqncia lgica de acordo com os processos organizacionais. Neste cenrio, novas aplicaes clientes, com pouca ou nenhuma lgica de negcio, podem ser desenvolvidas em cima destes processos de negcio. Neste caso, estas aplicaes clientes funcionam simplesmente como entrada e apresentao dos dados.

Figura 2. SOA em um contexto empresarial

O cenrio ideal que analistas de negcio da organizao possam fazer alteraes nos processos e que isso seja refletido automaticamente no sistema empresarial como um todo, sem precisar alterar nenhuma linha de cdigo. Esta a idia Run what I just drew, ou seja, execute o que eu acabei de dese-nhar. Este um dos focos da rea de BPM (Business Process Management). Atualmente, os conceitos de SOA e BPM esto bem relacionados e, por este motivo, as pessoas os confundem, achando que estas idias de gerenciamento de processos per-tencem a SOA. SOA d o suporte tecnolgico e metodolgico para expor servios de negcio. J BPM tem como objetivo capturar, projetar, executar, gerenciar e monitorar processos, geralmente atravs de ferramentas visuais. Como estes temas esto bem interligados, ao longo deste artigo, iremos nos referir apenas ao termo SOA, sabendo que as idias de BPM esto incorporadas a ela.

importante dizer que este o cenrio que SOA, juntamente com BPM, pode alcanar. Porm, SOA tambm pode ser utili-zado em outros cenrios mais simples que no envolva BPM.

Benefcios na adoo de SOAA adoo de SOA traz alguns benefcios devido s suas

caractersticas. Esta lista de benefcios no est completa, e

32 Engenharia de Software Magazine - Arquitetura Orientada a Servios

apenas uma indicao do potencial que essa plataforma arquitetural pode oferecer.

Flexibilidade

Como foi dito, todo sistema empresarial est sujeito a mu-danas. Ele precisa continuamente ser adaptado para suportar novos requisitos devido s necessidades que envolvem o mer-cado, mudanas na lei, ou mesmo reorganizaes de negcio. Portanto, a arquitetura empresarial deve ser configurada de maneira flexvel. As caractersticas de SOA possibilitam o desenvolvimento de novos servios de negcio e permitem que uma organizao reuse estes servios a fim de responder a estas mudanas.

Manutenabilidade

A comunicao entre o consumidor e o fornecedor baseada em interfaces bem definidas e padronizadas. Esta caracte-rstica aumenta o poder de manutenabilidade dos sistemas empresariais porque os detalhes de implementao ficam escondidos.

Reusabilidade

Reusabilidade tem sido um dos maiores objetivos da enge-nharia de software nos ltimos anos, com diferentes graus de sucesso. Na SOA, a habilidade de compor novos servios a partir de servios existentes fornece uma maior possibilidade para o reuso e uma vantagem distinta para uma organizao que tem que ser gil para responder s necessidades de negcio. Desta maneira, o desenvolvimento das aplicaes atravs do reuso de servios torna mais rpido, aumenta a qualidade e diminui os custos de desenvolvimento e tempo de entrega.

Integrao

Como j foi dito, muitas organizaes possuem uma infra-estrutura de aplicaes fragmentadas na qual uma variedade de aplicaes clientes tm que ser criadas utilizando mltiplas plataformas de programao e comunicao. Neste contexto, SOA pode facilitar a integrao de sistemas heterogneos j que a idia disponibilizar a lgica desses sistemas em forma de servios interoperveis.

Ingredientes para adooComo foi dito anteriormente, SOA no s tecnologia. SOA

um conceito amplo, que envolve outros aspectos para que sua adoo tenha sucesso em um contexto empresarial. Neste sentido, podemos citar quatro ingredientes fundamentais para o sucesso de uma SOA: organizao, processo, tecnologia e governana.

Organizao

No adianta tentar implantar uma SOA sem alinhar a TI com o negcio. Para tanto, necessrio entender a estru-tura organizacional, suas reas e unidades, assim como os processos de negcio de cada uma delas. Neste sentido, necessrio revisar, caso existam, ou criar, caso no existam,

os modelos de processos de negcio destas reas organi-zacionais. Alm disso, importante que estejam claras as expectativas e necessidades de cada rea em relao implantao da SOA.

Como foi explicado, SOA uma boa soluo para integra-o. Mas no adianta tentar integrar sistemas de diferentes unidades organizacionais se estas no esto integradas no nvel de negcio. Portanto importante, primeiramente, integrar as reas de negcio e seus processos.

Processo

Para desenvolver servios que atendam os princpios da abordagem orientada a servios, so necessrios tcnicas, mtodos e boas prticas de design especficas.

O processo de desenvolvimento de servios envolve duas etapas: desenvolvimento para reuso e desenvolvimento com reuso. O primeiro se preocupa em desenvolver servi-os para que eles se tornem os mais reutilizveis possveis. O segundo criar aplicaes reutilizando os servios existentes.

Existem algumas metodologias encontradas na literatura. Algumas delas tentam dar suporte a todo o ciclo de vida de SOA, incluindo atividades de planejamento, anlise e projeto, construo, teste, implantao e governana, en-quanto outras limitam seu escopo a um subconjunto destas atividades. Entretanto, este artigo no tem o objetivo de detalhar nenhuma dessas metodologias, mas de apenas dar uma noo geral de atividades que podem fazer parte de uma metodologia orientada a servios.

comum, em um contexto empresarial, existirem dife-rentes reas de negcio onde cada uma possui seu prprio time de desenvolvimento. Neste contexto, sob a perspectiva de processo de desenvolvimento, um dos principais bene-fcios de usar SOA, que ela possibilita um alto grau de modularizao. Esta caracterstica permite que os servios possam ser implementados por diversos times. Evidente-mente, estes times devem respeitar os contratos de servios. A Figura 3 ilustra um processo de desenvolvimento para SOA. O processo possui duas fases. A primeira fase objetiva especificar a SOA empresarial como um todo, definindo, entre outras coisas, os servios que iro compor a SOA. Uma vez definidos os servios, estes so alocados para os diferentes times de desenvolvimento que tem a responsa-bilidade de construir os servios sob sua responsabilidade [Dias, 2009].

Figura 3. Processo de desenvolvimento de uma SOA em um contexto

empresarial

Figura 3. Processo de desenvolvimento de uma SOA em um contexto

Edio 22 - Engenharia de Software Magazine 33

PROJETO

As prximas subsees discutem algumas atividades que devemos considerar ao projetar uma arquitetura de sistema baseado em SOA. Porm, no significa que estas atividades so o suficiente para projetar uma SOA com sucesso, mas apenas um indicativo para mostrar que, para termos uma SOA de sucesso, no precisamos apenas de tecnologia, mas tambm de uma arquitetura bem projetada.

Identificao de servios

Esta uma das mais importantes atividades do projeto orien-tado a servios. O objetivo descobrir os servios que compe a SOA. Em um contexto empresarial onde existem diversas reas de negcio, importante a participao de todos os interessados, no s dos que fazem parte da rea tecnolgica, mas tambm daqueles que so especialistas nos processos de negcio de sua rea. Isto porque os servios precisam repre-sentar bem as funes de negcio destes processos.

A maioria das tcnicas para identificar servios baseada nos modelos de processos de negcio. Por isso importante ter estes modelos bem especificados.

Aplicao dos princpios da orientao a servios

Da mesma forma que o paradigma orientado a objetos possui um conjunto de princpios que devem ser satisfeitos, o paradigma orientado a servios tambm possui princpios especficos que devem ser seguidos. Depois que os servios so identificados, importante garantir que eles atendam a estes princpios da orientao a servio. Entretanto, no existe uma lista oficial destes princpios. Thomas Erl, em seu livro SOA Princpios de design de servios, lista um conjunto de princpios que devem ser atendidos, tais como: contratos, acoplamento, abstrao, capacidade de reuso, autonomia, independncia de estado, visibilidade e composio de servios.

Especificao dos atributos de qualidade

Escolher uma arquitetura que satisfaa aos requisitos funcionais e aos requisitos no funcionais (atributos de qualidade) vital para o sucesso de qualquer sistema. Para SOA no diferente. importante entender como uma SOA suporta os diferentes atributos de qualidade e quais so suas implicaes para criar um projeto com sucesso. Neste sentido, as pessoas interessadas e envolvidas na definio da SOA precisam definir e priorizar os atributos de quali-dade que iro ser satisfeitos pela SOA. Alguns atributos de qualidade so: interoperabilidade, performance, segurana, confiabilidade, disponibilidade, escalabilidade, testabili-dade, adaptabilidade e reusabilidade. Para cada atributo definido, necessrio especificar como ele ser garantido, seja atravs de aplicao de boas prticas de projeto, seja atravs de tecnologias.

Especificao dos contratos de servios

Uma vez conhecidas as interfaces dos servios e seus respectivos fornecedores e consumidores em potencial,

importante definir os contratos destes servios. Um contrato de servio contm os termos acordados pelo fornecedor e consumidor do servio.

Algumas informaes importantes que o contrato deve abranger so as seguintes: interface do servio: o nome e as operaes do servio; mensagens do servio: as mensagens que o consumidor e o fornecedor iro trocar para executar o servio; os tipos de dados tambm devero ser especificados; pr e ps condies: as pr e ps condies de cada ope-rao do servio; atributos de qualidade: os atributos de qualidade que o servio dever satisfazer; consumidores potenciais: a lista dos consumidores conhecidos; fornecedor: a entidade, a rea, o sistema que ir fornecer o servio; SLA: se houver um Service-Level Agreement envolvido no contrato, ele dever ser especificado.

Projetar e construir servios

Depois de projetar a arquitetura baseada em SOA, os ser-vios identificados sero alocados para os times de desen-volvimento. Cada time de desenvolvimento deve analisar, projetar, construir e testar os seus servios. Para tanto, importante observar os atributos de qualidade especifica-dos na fase de definio da SOA. Alm disso, o contrato de servio deve ser respeitado. A equipe dever tomar decises de como expor as funcionalidades dos seus sistemas (caso existam) em forma de servio.

Tecnologia

Atualmente, existe uma variedade de tecnologias rela-cionadas SOA. Porm, no necessrio utilizar todas as tecnologias para dizer que est implementando uma SOA. Por outro lado, o fato de apenas utilizar uma das tecnologias no quer dizer necessariamente que est usando SOA. Outra questo importante que SOA no est presa a nenhuma tecnologia. Porm, evidente que algumas tecnologias j co-nhecidas so ditas como a melhor forma de se implementar uma SOA, como por exemplo Web Services.

Abaixo seguem algumas das tecnologias relacionadas SOA [Davis, 2009]:

Web Services

Para descrever Web Services, podemos seguir as definies de alguns fornecedores e institutos de pesquisa, como o Gartner: so componentes de software com baixo fator de acoplamento, utilizados por meio de padres de tecnologia Internet. Um Web Service representa uma funo de negcio ou um servio que pode ser acessado por uma outra aplica-o, sobre redes pblicas e, geralmente, disponibilizado por protocolos conhecidos. Web Service pode ser visto como um framework de tecnologias que permite a comunicao entre aplicaes heterogneas atravs de servios interoperveis,

34 Engenharia de Software Magazine - Arquitetura Orientada a Servios

onde estes servios podem ser localizados e executados atravs de protocolos padronizados. As trs especificaes conhecidas do Web Services so o SOAP como protocolo de comunicao, o WSDL como padro de descrio de servios e o UDDI como padro de registro de servio.

Enterprise Service Bus (ESB)

Um ESB pode ser visto como um middleware que tem o objetivo de facilitar a integrao de sistemas. Geralmente um ESB possui as seguintes funcionalidades: prover se-gurana, prover transparncia de localizao, transformar mensagens, rotear e monitorar as mensagens, gerenciar os servios, entre outros.

Existem muitos produtos de ESB disponveis no mercado atualmente de fornecedores como IBM, TIBCO, Microsoft e Oracle. A maioria desses produtos tem um background do mercado de EAI (Enterprise Application Integration). Porm tambm existem solues open source tais como Mule, Servi-ceMix, OpenESB e JBossESB. Para quem quer se especializar mais nestes ESBs open source recomendo o livro Open Source ESBs in Action [Rademakers, 2009].

Business Process Management System (BPMS)

Esta ferramenta permite a gesto automatizada dos pro-cessos de negcio da organizao. Como foi dito, os servios representam funes de negcio na organizao. Neste sentido, os servios podem ser orquestrados representan-do fluxos de execuo dos processos de negcio. O BPMS fornece estes recursos, permitindo a execuo, controle e monitorao desses fluxos. Geralmente uma ferramenta de BPMS possui as seguintes caractersticas: ferramenta para modelagem e desenho do processo; engenho de execuo do processo; orquestrao de Web Services e interface de workflow para usurios.

Enterprise Decision Management (EDM)

Um sistema EDM incorpora uma mquina de regra de negcio para execuo de regras de negcio definidas e um sistema para gerenciar estas regras. Uma regra de negcio uma instruo bem definida relacionada ao negcio, que faz alguma afirmao sobre algum aspecto de como o negcio deve funcionar.

A idia de um sistema baseado em regras, ou EDM, separar as regras do cdigo do programa, deixando estas regras centralizadas, permitindo que as aplicaes ou ser-vios utilizem-nas.

Repositrio

Os artefatos gerados em uma SOA devem ser registra-dos dentro de um repositrio para proporcionar o reuso e fornecer infra-estrutura para gerenciamento dos ativos. Estes ativos podem incluir servios, processos de negcio, orquestraes, regras de negcio, entre outros.

Para pequenas organizaes, repositrios informais podem ser utilizados, como por exemplo um wiki ou uma base de

dados simples que descrevem os diversos ativos. Porm, para grandes organizaes, interessante ter um repositrio mais profissional e focado nos ativos da SOA.

Governana

A Gartner declarou que a carncia de planejamento rela-cionado governana ser o principal motivo dos fracassos em SOA. Um estudo realizado pelo SOA Forum mostra que as polticas de governana so insuficientes em 88% das organizaes, o que pode comprometer o projeto. Ainda segundo a Gartner, Governana SOA est relacionada garantia de que os ativos de software e artefatos da sua arquitetura esto operando como esperado e dentro de um certo nvel de qualidade.

Na SOA, consumidores de servio e fornecedores de servio so executados em diferentes processos, so desenvolvidos e gerenciados por diferentes departamentos e exigem um grande esforo de coordenao para trabalharem juntos com sucesso. Para SOA ter xito, mltiplas aplicaes precisam compartilhar servios, o que significa que eles precisam ser coordenados para se tornarem comuns e reutilizveis. Estes so os problemas de governana e eles so muito mais complexos do que nos dias de aplicaes monolticas ou mesmo nos dias de componentes e cdigos reutilizveis [InfoQ, 2009].

Para o sucesso da governana numa organizao impor-tante a combinao de pessoas, processos e tecnologias. Alm disso, estando presente essa preocupao desde o incio da implantao da SOA, a transio mais confortvel para a empresa, alm de ajudar no estabelecimento do alinhamento necessrio entre as reas de negcio e a rea de TI, to im-portante para pontos como a reduo de custos e retorno de investimento.

DesafiosDe acordo com um estudo feito pela InformationWeek [Infor-

mationWeek, 2008], 32% dos projetos SOA no atenderam s expectativas.

Como qualquer mudana de paradigma, a adoo de SOA envolve muitos riscos e desafios. Alm do desafio de se defi-nir os aspectos discutidos anteriormente como organizao, processos, tecnologias e governana, existem alguns outros que devem ser considerados.

Abaixo segue alguns dos limitadores para se adotar SOA.

Cultura

Todas as empresas possuem sua prpria cultura, suas crenas e suas formas de executar suas atividades. A implantao de uma SOA em uma organizao far com que algumas pessoas tenham que mudar um pouco sua forma de pensar em relao a algumas atividades que elas executam. Qualquer mudana de paradigma passvel a resistncia. Neste sentido, importante primeiro convencer as pessoas envolvidas e interessadas no projeto SOA sobre seus benefcios. importante que todas as pessoas envolvidas estejam motivadas e interessadas na transio para SOA.

Edio 22 - Engenharia de Software Magazine 35

PROJETO

Falta de conhecimento

Muitas pessoas acham que para adotar uma SOA necessrio comprar uma caixa com uma soluo SOA pronta. Mas como vimos ao longo deste artigo, a adoo de SOA exige outros conhecimentos para ter sucesso. Neste sentido, importante que a empresa que queira adotar uma SOA busque estes co-nhecimentos necessrios ou ento contrate uma consultoria externa.

Falta de um projeto piloto

Como diz o ditado popular: a pressa inimiga da perfei-o. Quando queremos realizar grandes mudanas em uma empresa, importante que elas sejam feitas de maneira plane-jada e que primeiro se realize um projeto piloto, diminuindo assim os riscos. Com SOA no diferente. Deve-se escolher um projeto piloto e execut-lo de maneira controlada para analisar os riscos.

Falta de comprometimento

Como foi dito, a adoo de SOA envolve muitas mudanas em uma organizao. Por esta razo importante ter uma equipe ou uma pessoa totalmente envolvida nestas questes.

Consideraes FinaisVimos neste artigo que a adoo de SOA em um contexto

empresarial pode trazer vrios benefcios, porm envolve tam-bm muitos desafios, sendo necessrio um bom conhecimento no s das tecnologias que do suporte a SOA, mas tambm de todo o ciclo de desenvolvimento de uma SOA.

Entretanto, SOA no a soluo para todos os problemas. Cada caso deve ser analisado de forma apropriada para que seja avaliado o seu custo e se o retorno do investimento interessante.

Site do DCE/UFPB

http://www.ccae.ufpb.br/dce

SOA Forum

http://www.soaforum.org

Links

[InformationWeek, 2008] Smith Roger. A simpler approach to SOA (2008).

Disponvel em http://www.informationweek.com/news/software/soa/showArticle.

jhtml?articleID=209904293

[Josuttis, 2007] Josuttis, N. SOA in Practice The Art of Distributed System Design.

OReilly, 2007.

[Erl, 2008] Erl, Thomas. SOA Princpios de design de servios. Prentice Hall, 2008.

[Davis, 2009] Davis, Jeff. Open Source SOA. Manning, 2009.

[Rademakers, 2009] Rademakers, T., Dirksen, J. Open Source ESBs in Action.

Manning, 2009.

[Dias, 2009] Dias, J. J.; Almeida, E. S.; Meira, S. R. L. A Systematic SOA-based

Architecture Process, 21st International Conference on Software Engineering and

Knowledge Engineering (SEKE), Service Oriented Architecture Track, Boston, U.S.,

2009.

[InfoQ, 2009] Artigo da InfoQ. Como Alinhar Processos de TI e Governana SOA

para suportar Iniciativas BPM? (2009) Disponvel em http://www.infoq.com/br/

news/2009/02/process-it-soa-governance.

Referncias

D seu feedback sobre esta edio!

A Engenharia de Software Magazine tem que ser feita ao seu gosto.

Para isso, precisamos saber o que voc, leitor, acha da revista!

D seu voto sobre este artigo, atravs do link:

www.devmedia.com.br/esmag/feedback

D

seu F

eedback

sob

re esta edio