UNIVERSIDADE NOVE DE JULHODisciplina: Processo de Desenvolvimento de Software
Programação Orientada a Serviço e Aspectos
UNINOVESÃO PAULO – 2013-1
UNIVERSIDADE NOVE DE JULHODisciplina: Processo de Desenvolvimento de Software
Programação Orientada a Serviço e Aspectos
Trabalho apresentado à Universidade Nove de Julho, UNINOVE, em cumprimento parcial às exigências da
disciplina de Processo de Desenvolvimento de Software, sob orientação do Profº. Moises
UNINOVESÃO PAULO – 2013-1
UNIVERSIDADE NOVE DE JULHO
Nomes R.A.
Armando Lopes da Silva 311203263
Deivid Moreira Macimo 311205030
Francisco dos Santos Martins 311205036
3
SUMÁRIO
1. RESUMO..............................................................................................................................................52. PROGRAMAÇÃO ORIENTADA A SERVIÇO (SOA).............................................................................................6
2.1. DEFINIÇÃO......................................................................................................................................62.2. SOA COMO SERVIÇOS ENCAPSULAM A LÓGICA.............................................................................72.3. SOA PRÁTICAS ESSENCIAIS.........................................................................................................10
3. PROGRAMAÇÃO ORIENTADA A ASPECTOS (POA).........................................................................................113.1. ORIENTAÇÃO A ASPECTOS...........................................................................................................123.2. ELEMENTOS DA ORIENTAÇÃO A ASPECTOS.................................................................................143.3. ASPECTOS.....................................................................................................................................153.4. AS VANTAGENS DA ORIENTAÇÃO ASPECTO................................................................................16
4. CONCLUSÃO..........................................................................................................................................17
4
1. RESUMO
Objetivo desta atividade é descrever os conceitos sobre (SOA) programação orientada a
serviço e (POA) programação orienta a aspectos
SOA é um estilo de arquitetura de software cujo princípio fundamental prega que as
funcionalidades implementadas pelas aplicações devem ser disponibilizadas na forma de
serviço são conectados através de um "barramento de serviços" (enterprise service bus, em
inglês) que disponibiliza interfaces, ou contratos, acessíveis através de web services ou outra
forma de comunicação entre aplicações. A arquitetura SOA é baseada nos princípios da
computação distribuída e utiliza o paradigma request/reply para estabelecer a comunicação
entre os sistemas clientes e os sistemas que implementam os serviços.
5
2. Programação Orientada a Serviço (SOA)
2.1.Definição
Programação orientada a serviço (SOA) é um conceito de arquitetura corporativo, que nos
permite criar, padronizar, documentar serviços genéricos, únicos e interoperáveis, que possam
de maneira fácil, ser reutilizados por diversas aplicações diferentes, sem a necessidade de ser
desenvolvido novamente, tornando o processo de desenvolvimento mais ágil.
O SOA coloca a prestação de serviço como eixo de todo o negócio, dando destaque à gestão
de serviços e ao cliente.
Serviço – É uma É uma função independente, sem estado (stateless) que aceita uma ou mais
requisições e devolve uma ou mais respostas através de uma interface padronizada e bem
definida. Serviços podem também realizar partes discretas de um processo tal como editar ou
processar uma transação. Serviços não devem depender do estado de outras funções ou
processos. A tecnologia utilizada para prover o serviço, tal como uma linguagem de
programação, não pode fazer parte da definição do serviço.
Orquestração - Processo de sequenciar serviços e prover uma lógica adicional para processar
dados. Não inclui uma representação de dados.
Stateless - Não depende de nenhuma condição pré-existente. Os serviços não devem
depender de condições de outros serviços. Eles recebem todas as informações necessárias
para prover uma resposta consistente. O objetivo de buscar a característica de stateless dos
serviços é possibilitar que o consumidor do serviço possa sequenciá-lo, ou seja, orquestrá-los
em vários fluxos (algumas vezes chamados de pipelines) para executar a lógica de uma
aplicação.
Provedor – O recurso que executa o serviço em resposta a uma requisição de um consumidor.
Consumidor – É quem consome ou pede o resultado de um serviço fornecido por um
provedor.
Descoberta – SOA se baseia na capacidade de identificar serviços e suas características.
Consequentemente, esta arquitetura depende de um diretório que descreva quais os serviços
disponíveis dentro de um domínio.
Binding – A relação entre os serviços do provedor e do consumidor deve ser idealmente
dinâmica, ela é estabelecida em tempo de execução através de um mecanismo de binding.
6
2.2.SOA Como serviços encapsulam a lógica
Pode ser em contextos distintos. Estes contextos podem ser específicos para uma tarefa de
negócio, entidades de negócio e outros agrupamentos de negócio.
Serviços podem encapsular a lógica de outros serviços "find-bind-execute"
Na figura, quando construímos uma solução consistente de serviço, cada serviço pode
encapsular a tarefa realizada por um passo individual ou um sub-processo composto de um
conjunto de passos. Um serviço pode encapsular toda a lógica do processo. O último caso
representado pelo serviço pode englobar a lógica encapsulada de outros serviços.
Como serviços são relacionados
Serviços podem encapsular a lógica de outros serviços "find-bind-execute"
7
Dentro do SOA serviços podem ser usados por outros serviços ou por outros programas.
Independentemente, o relacionamento por trás do serviço é baseado no entendimento que os
serviços possam interagir. Eles devem estar atentos ao outro. Esta consciência é obtida
através do uso da descrição do serviço.
Como serviços se comunicam
Quando as mensagens são enviadas eles perdem o controle do que acontece depois. Essas
mensagens podem ser equipadas com inteligência suficiente para auto-governar as partes
lógicas do processamento.
Serviços podem encapsular a lógica de outros serviços "find-bind-execute"
Esta arquitetura é similar ao passado da arquitetura distribuída que suporta mensagens e
separação de interface de processamento lógico. O que distingue é como esses três
componentes fundamentais (serviço, descrição e mensagem) são projetados. Onde entra a
orientação de serviços.
Como serviços são projetados
8
Serviços podem encapsular a lógica de outros serviços "find-bind-execute"
Acoplamento: busca-se um fraco acoplamento. Contrato de serviço: meio de acesso a esse
serviço. Autonomia: serviços têm controle sobre a lógica que a encapsulam. Abstração: além
do que é descrito no contrato de serviço, serviços escondem a lógica do mundo exterior.
Reusabilidade: a lógica é dividida no serviço com a intenção de reuso. Agregabilidade:
coleções de serviços podem ser coordenados e montados em forma de serviços compostos.
Statelessness: serviços minimizam a retenção da informação em determinada atividade.
Descoberta: serviços são projetados para ser exteriormente descrito, para que possam ser
encontrados e avaliados através de mecanismos de descobertas disponíveis.
Como serviços são construídos A obtenção do SOA não exige serviço web, mas SOA pode
e deve ser realizada através do uso da plataforma de tecnologia de serviço web
9
2.3.SOA Práticas Essenciais
Primeiro: use para minimizar o futuro custo de mudanças em um ou duas áreas críticas.
Segundo: crie um pequeno grupo, um “Centro de Excelência SOA” para liderar esses projetos,
desenvolvendo os conhecimentos necessários e educar todos os envolvidos.
Terceiro: faça com que esse centro colabore com as áreas de negócio para aprender quais são os
problemas mais adequados para resolver.
10
3. Programação Orientada a Aspectos (POA)
O conceito foi criado por Gregor Kiczales e a sua equipe na Xerox PARC, a divisão de
pesquisa da Xerox. Eles desenvolveram o AspectJ, a primeira e mais popular linguagem POA.
Os paradigmas de programação mais antigos, como a programação procedural e
programação orientada a objeto, implementam a separação do código, através de entidades
únicas. Por exemplo, a funcionalidade de log de dados, numa linguagem orientada a objetos, é
implementada em uma única classe, que é referenciada em todos os pontos onde é necessário
fazer log de dados. Como praticamente todo método necessita que alguns dados sejam
registrados em log, as chamadas a essa classe são espalhadas por toda a aplicação.
Tipicamente uma implementação da POA busca encapsular essas chamadas através de uma
nova construção chamada de "aspecto". Um aspecto pode alterar o comportamento de um
código (a parte do programa não orientada a aspectos) pela aplicação de um comportamento
adicional, advice, sobre um "ponto de execução", ou join point. A descrição lógica de um
conjunto de join points é chamada de pointcut.
3.1. Orientação a Aspectos
11
Todas as aplicações possuem diversas funcionalidades, algumas fazem parte do núcleo
(primárias) e outras dão suporte as funcionalidades presentes no núcleo e geralmente se
repetem em diversos módulos (secundárias). Em uma aplicação comercial as funcionalidades
do núcleo são as regras de negócios e as secundárias são, por exemplo, logging e autorização.
A programação orientada a objetos é a metodologia de programação mais utilizado para
implementar funcionalidades primárias, mas ela não é suficiente para cobrir as funcionalidades
secundárias, especialmente em aplicações complexas. Essas funcionalidades secundárias são
definidas pelo termo crosscuting concerns. A orientação a objetos cria um acoplamento entre
funcionalidades principais e os crosscuting concerns que não é desejado, uma vez que a
adição ou modificação dessas funcionalidades secundárias implicam em mudanças no núcleo
da aplicação.
O acoplamento da regra de negócios com as funcionalidades secundárias, implica em
mudanças no núcleo caso ocorra alguma alteração nas funcionalidades secundárias
AOP é uma nova metodologia que provê a separação dos crosscuting concerns introduzindo
uma nova unidade de modularização, o aspecto. Com AOP você implementa os crosscuting
concerns em aspectos ao invés de mesclá-los nos módulos principais. Os módulos principais e
os secundários são implementados separadamente. Um compilador especial monta o sistema
final combinando os módulos principais e os secundários num processo chamado weaving
(tecelagem), daí dá-se o nome de weaver (tecelão) ao compilador. O resultado é que a AOP
modulariza as funcionalidades secundárias, possibilitando a criação de um sistema que é mais
fácil de implementar e manter.
12
Diferença na construção dos módulos entre Orientação a Objetos e Orientação a Aspectos
A separação dos módulos ainda possibilita a reutilização dos módulos secundários em vários
módulos principais. Os módulos secundários são escritos apenas uma vez, e mesclado
quantas vezes for necessário nos módulos principais. Isso sem nenhuma alteração no núcleo
da aplicação.
Existem várias implementações de AOP para várias linguagens de programação, inclusive em
Java. AspectJ é a implementação AOP para Java mais utilizada e que tem mais suporte, por
isso utilizaremos ela nesse trabalho, além disso a sintaxe estendida do AspectJ o torna uma
das implementações AOP mais poderosas que existe.
13
3.2.Elementos da Orientação a Aspectos.
Assim como na Orientação a objetos, a Orientação a Aspectos possui os seus próprios
conceitos.
Crosscuting concern - é o termo que define partes do sistema que são aplicaveis em vários
locais. Autenticação é uma funcionalidade que aparece em vários módulos do sistema, logo,
autenticação é um crosscuting concern. Crosscuting também é o termo dado ao processo de
adicionar código extra a um determinado módulo.
Weaving - Processo onde é feita a mesclagem dos módulos do sistema de acordo com os
aspectos encontrados. O weaving é como uma outra etapa da compilação. Weaving rules são
as regras que devem ser aplicadas durante essa fase da compilação.
Join point - Um join point (ponto de mesclagem) é um ponto identificável do fluxo de um
programa. Pode ser uma chamada de método ou a configuração do valor de uma variável.
Variadas implementações da orientação a aspectos suportam variados tipos de join point.
Pointcut - Um pointcut é uma construção que seleciona join points. Depois de capturar um join
point é possível especificar as regras de weaving nesses join points, como executar
determinada ação antes ou depois da execução desse join point. Um pointcut pode selecionar
um join point que é uma chamada para um método por exemplo. Pointcuts especificam as
regras de mesclagem (onde devem ser feitas as mesclagens), e join points são as situações
que satisfazem essas regras. Podemos criar um pointcut para todos os métodos chamados
checar, o pointcut definiu a regra: métodos chamados checar. Cada método chamado checar
será um join point desse pointcut.
14
3.3. Aspectos
O aspect (aspecto) é o ponto central da Orientação a Aspectos, assim como uma classe é o
ponto central em orientação a objetos. Nele são declarados e implementados os códigos que
expressam as regras de mesclagem das funcionalidades. Pointcuts, advices, introductions e
declarações são combinadas em aspectos. Além dos elementos da Orientação a Aspecto, um
aspecto também pode conter métodos e variáveis membros assim como nas classes Java.
Existem outras implementações de Orientação a Aspectos para Java que podem não ter a
sintaxe extendida do AspectJ e por isso utiliza classes e métodos normais para criação dos
aspectos, mas ainda assim os conceitos são válidos.
15
3.4.As Vantagens da Orientação Aspecto
A Orientação a Aspectos traz novas dificuldades a programação, mesmo porque é uma nova
metodologia, e tudo que é novo requer um tempo de aprendizado. Mas a Orientação a
Aspectos oferece vantagens que cobrem esse tipo de problema:
Responsabilidades mais transparentes de cada módulo: cada módulo é responsável
apenas pelas tarefas destinadas ao próprio módulo. Os módulo são mais
independentes.
Modularização mais alta: As responsabilidades são melhor definidas em cada módulo,
os módulos tem baixo acoplamento entre si.
Evolução do sistema mais facilitada: O baixo acoplamento possibilita que alterações no
sistema sejam feitas sem alteração do núcleo.
Decisões de design podem ser tomadas com mais atraso: Devido ao baixo
acoplamento não é necessário pensar em todos os problemas no início do
desenvolvimento do sistema.
Mais reusabilidade do código: Os módulos podem ser mais reaproveitados devido a
alta coesão e baixo acoplamento.
Sistemas mais fáceis de desenvolver e manter: Os aspectos tornam a integração das
partes do sistema um modulo separado, o que traz mais facilidade no desenvolvimento.
Custos reduzidos de introdução de novas funcionalidades: Novas funcionalidades
podem ser introduzidas criando aspectos, não sendo necessário alterar o núcleo para
adicionar tais funcionalidades.
16
4. Conclusão
A Orientação a Aspectos é uma nova metodologia de programação. A Orientação a Aspectos
não é um substituto a orientação a objetos e sim um complemento. Um novo nível de
modularização é alcançado, a diminuição do acoplamento dos módulos possibilita mais
facilidade de manutenção, maior reaproveitamento do código e maior organização do sistema.
Apesar de ser uma nova metodologia a orientação a aspectos já é está madura o suficiente
para ser utilizada na produção de sistemas, já tem documentação e suporte de ferramentas
suficiente. Assim como hoje a orientação a objetos é a maneira mais aceita para
desenvolvimento dos módulos do sistema, a orientação a aspectos será o padrão de integração
desses módulos.
17
5. Bibliografia
Uso de Programação Orientada a Aspecto no Desenvolvimento de Aplicações que utilizam conceitos de Tecnologia Adaptativa
http://lta.poli.usp.br/lta/wta/wta-2012/trabalhos/papers/wta_submission_13
Enciclopedias Wikipédia, a enciclopédia livre.
Programação orientada a seriviço
http://pt.wikipedia.org/wiki/Service-oriented_architecture
Programação orientada aspecto
http://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_orientada_a_aspecto
18
Top Related