Hugo Silva
[email protected]
Orientado por:
Doutor Paulo Gandra de Sousa
Relatório de Projecto
Departamento de Engenharia Informática
Instituto Superior de Engenharia do Porto
Instituto Politécnico do Porto
Setembro de 2004
1.
INTRODUÇÃO ...................................................................................................3
1.1.
Objectivos................................................................................................................... 4
1.2.
Organização do documento ..................................................................................... 4
2.
NECESSIDADES DE SOFTWARE ..........................................................................5
2.1. Evolução do Software................................................................................................ 5
2.1.1.
Primeira era ......................................................................................................... 5
2.1.2.
Segunda era ......................................................................................................... 6
2.1.3.
Terceira era.......................................................................................................... 6
2.1.4.
Quarta era ............................................................................................................ 6
2.1.5.
Quinta era ............................................................................................................ 6
2.2.
Sistemas de Software................................................................................................. 7
2.3.
Simplificação e generalização.................................................................................. 7
2.4.
Cooperação entre empresas..................................................................................... 8
2.5.
Mobilidade.................................................................................................................. 8
3.
SERVICE-ORIENTED ARCHITECTURE ..................................................................9
3.1.
Definição ..................................................................................................................... 9
3.2.
Mudança de paradigma ........................................................................................... 9
3.3. Loose Coupling......................................................................................................... 12
3.3.1.
Mensagens......................................................................................................... 13
3.3.2.
Documentos XML ............................................................................................ 14
3.4. Guias adicionais....................................................................................................... 15
3.4.1.
Independência do estado .................................................................................. 15
3.4.2.
Dependência do estado..................................................................................... 15
3.4.3.
Idem-potência ................................................................................................... 16
3.5. Middleware................................................................................................................ 16
3.5.1.
CORBA e DCOM............................................................................................. 17
3.5.2.
Web Services ..................................................................................................... 17
3.6.
Agregação de serviços............................................................................................. 18
3.7. Vantagens potenciais .............................................................................................. 20
3.7.1.
Reaproveitamento de recursos ......................................................................... 20
-1-
3.7.2.
3.7.3.
3.7.4.
3.7.5.
Facilidade de integração e de manutenção...................................................... 20
Maior capacidade de reacção ........................................................................... 20
Redução de custos e aumento da reutilização................................................. 21
Preparação para o futuro .................................................................................. 21
3.8. Exemplos................................................................................................................... 21
3.8.1.
Google Web API ............................................................................................... 21
3.8.2.
Amazon Web Service........................................................................................ 22
3.8.3.
Qwest – Um exemplo de SOA aplicado em grande escala .................. 22
3.8.4.
CACU – Um Exemplo de Workflow automatizado..................................... 25
3.8.5.
Avista Corp. – Um exemplo de conectividade de Mainframes............... 26
4.
INTEROPERABILIDADE.....................................................................................30
4.1.
Message-Oriented Middleware ............................................................................... 31
4.2.
Pontes Aplicacionais ............................................................................................... 32
4.3. Web Services ............................................................................................................. 32
4.3.1.
Web Services Interoperability Organization................................................... 33
4.3.2.
WS-I Basic Profile............................................................................................ 34
4.4. SOA e a interoperabilidade ................................................................................... 35
4.4.1.
A interoperabilidade ao nível de negócio........................................................ 36
5.
CONCLUSÃO ..................................................................................................39
ANEXOS ...............................................................................................................40
A.
TECNOLOGIAS SUBJACENTES ......................................................................40
A.1.
XML .......................................................................................................................... 40
A.2. Web Services ............................................................................................................. 41
A.2.1.
Definição ........................................................................................................... 41
A.2.2.
Stack Web Service............................................................................................. 42
A.2.3.
UDDI ................................................................................................................. 42
A.2.4.
WSDL................................................................................................................ 43
A.2.5.
SOAP ................................................................................................................. 46
BIBLIOGRAFIA .......................................................................................................47
ÍNDICE DE EXEMPLOS ............................................................................................50
ÍNDICE DE FIGURAS ...............................................................................................51
-2-
Nos nossos dias é comum ouvir as expressões empresa virtual ou empresa
expandida aplicadas à industria. Estas significam que a empresa em causa é
responsável apenas por uma parte do fabrico ou concepção do produto, por exemplo da
montagem do produto acabado ou da sua comercialização. A crescente complexidade
dos produtos parece ser um factor determinante no aparecimento de parcerias e na
contratação de empresas especializadas em executar determinadas tarefas. De facto,
nos dias que correm serão poucos os produtos totalmente fabricados por uma única
empresa. Este tipo de estruturas proporciona às empresas uma grande facilidade de
renovação ou reutilização de processos, pois permite que cada empresa se concentre
no que faz de melhor, no entanto exige uma grande capacidade de comunicação e
interacção. As ligações tomam assim um papel de destaque na organização das
empresas, pois estas têm de ser capazes de interagir rapidamente e de preferência de
forma automatizada. A capacidade para criar novas ligações com um mínimo de esforço
favorece os negócios e pode muitas vezes ser vantagem suficiente para aproveitar as
oportunidades que se apresentam. Quando as ligações entre as empresas deixam de
ser um problema abre-se o caminho para que a qualidade do trabalho seja o factor de
decisão principal na escolha de parceiros de negócios, torna-se também possível
substituir partes da cadeia de produção de forma rápida e eficiente.
À semelhança de outros produtos também o Software se tem tornado cada vez
mais complexo. Nomeadamente no que se refere aos sistemas implementados em
empresas de média e grande dimensão. De facto, hoje em dia, os sistemas informáticos
integram uma grande diversidade de sub-componentes e sub-sistemas, como por
exemplo programas de contabilidade, CRM (Customer Relationship Management),
gestão de stocks, ERP (Enterprise Resource Planning), etc.. No entanto, embora
albergados debaixo de um mesmo sistema, os componentes nem sempre se interligam
como seria desejado o que causa conflitos de informação ou redundância. As ligações
entre os componentes são um dos pontos mais sensíveis deste tipo de sistemas, pois
são necessárias para o bom funcionamento da empresa e quase nunca são feitas de
uma forma standard. O que implica que se torna custoso integrar novos componentes,
principalmente se não forem feitos à medida. À semelhança do que acontece ao nível
empresarial uma vez que a ligações entre os componentes deixem de ser uma
problema passa a ser mais simples integrar num sistema novos módulos de Software
mesmo que estes sejam “pré-fabricados”.
A partilha de informação entre aplicações sempre foi uma preocupação dos
fabricantes de Software pois é o primeiro passo para a reutilização do mesmo. Nos
primeiros anos da informática os dados eram por vezes partilhados com recurso a
cartões perfurados e fitas magnéticas, com a evolução do Hardware e do Software
começaram a aparecer repositórios de dados, formatos de ficheiros standard e sistemas
distribuídos, com o advento do XML (eXtensible Markup Language) a partilha de
informação tornou-se cada vez mais simples. Hoje em dia com a proliferação de
empresas de desenvolvimento de Software e de diferentes sistemas implementados, a
atenção dos fabricantes vira-se sobretudo para a partilha de funcionalidades ou serviços
e para a interoperabilidade dos seus sistemas.
Tendo em conta a especialização das empresas no ramo da informática e a
crescente complexidade dos sistemas implementados, torna-se mais simples
-3-
compreender os motivos que levam ao aparecimento de Arquitecturas Orientadas a
Serviços (SOA) e a relevância que estas podem vir a ter num futuro próximo.
Este documento foi produzido como resultado final da cadeira de Projecto do 5º
ano da Licenciatura de Engenharia Informática do Instituto Superior de Engenharia do
Porto, no ramo de Computadores e Sistemas e está subordinado ao tema:
Service-Oriented Architectures e interoperabilidade de aplicações utilizando Web
Services.
Os objectivos deste projecto passam pelo estudo das Service-Oriented
Architectures tendo em vista a interoperabilidade de aplicações residentes em
sistemas/plataformas diferentes através de Web Services. Também se pretende que
seja considerada a perspectiva das empresas e da indústria no processo que levou ao
aparecimento das SOAs e dos benefícios que estas podem tirar delas e da
interoperabilidade que elas proporcionam.
Este documento está dividido em cinco capítulos cada um deles subdividido em
secções. O primeiro capítulo contém a introdução ao contexto em que estão inseridas
as tecnologias abordadas no documento.
O segundo capítulo visa demonstrar as necessidades de Software que são
vividas na actualidade, e contém secções sobre a evolução de Software, sistemas de
Software, simplificação de generalização de Software, cooperação entre empresas e
mobilidade.
O terceiro capítulo aborda directamente as arquitecturas orientadas a serviços
discutindo a sua definição e temas como Loose Coupling, Middleware, agregação de
serviços e vantagens potenciais. O capítulo termina com uma secção de exemplos de
serviços e de implementações de SOAs.
O quarto capítulo analisa a interoperabilidade, que opções existem para a obter,
como esta se relaciona com as SOAs e qual a sua importância em termos de negócio.
O quinto capítulo é constituído pelas conclusões. Segue-se em anexo uma
análise das tecnologias subjacentes às questões discutidas neste documento.
-4-
Tendo em conta os fins para que são utilizados os computadores hoje em dia
verifica-se que as aplicações das tecnologias informáticas são quase infindáveis.
“Verdadeiramente notável nos computadores não é a alta velocidade nem a
incrível capacidade de armazenamento de dados, mas sim, a variedade ilimitada de
usos a quem pode atender.” – Douglas José Peixoto de Azevedo, Bate Byte n.º 65 Evolução de Software
No entanto não é difícil perceber que a diversidade de aplicações para que os
computadores são utilizados se deve em maior parte a diversidade de Software
existente. De facto existem vários tipos de Software, tipos esses que são difíceis de
categorizar. Alguns autores sugerem três categorias [Robert Verzello 1984]: Software de
sistema, Software de desenvolvimento, e Software aplicacional. Outros autores sugerem
mais categorias [Pressman 1995], como por exemplo: Software comercial, Software
científico e de engenharia ou Software para uso pessoal; mas estas categorias parecem
apenas expandir a categoria de Software aplicacional.
Este capítulo visa retractar as necessidades de Software sentidas ao nível
empresarial e comerciar. Estas necessidades enquadram-se mais na terceira categoria,
Software aplicacional, mas podem por vezes tocar as outras duas categorias.
A evolução do Software [Azevedo 1997] está intimamente ligada com o
desenvolvimento das capacidades dos computadores, das quais nas últimas décadas
se assistiu a uma evolução notável, tanto a nível de capacidade de processamento
como de capacidade de armazenamento. A Figura 1 divide a evolução do Software em
cinco eras que serão analisadas de seguida.
Figura 1: Evolução do Software dividida em eras.
2.1.1. Primeira era
Durante os primeiros anos o desenvolvimento de Software estava em segundo
plano em relação ao desenvolvimento do Hardware. Em grande parte dos casos as
aplicações eram projectadas e desenvolvidas dentro das empresas que as utilizavam.
Possuir um computador significava ter na empresa técnicos e programadores para a
utilização e manutenção do Software. As aplicações eram, na maioria dos casos,
-5-
baseadas em sistemas de processamento de lotes (batch processing). As aplicações
interactivas eram praticamente inexistentes.
2.1.2. Segunda era
Na segunda era surgem os primeiros fabricantes de Software que produziam e
comercializavam Software para Mainframes e Minicomputadores. Esta era foi também
marcada pelo aparecimento dos sistemas multi-utilizador, sistemas de tempo real e
sistemas de bases de dados, que alargaram as áreas de aplicação da informática. À
medida que ia crescendo a procura por Software ia também crescendo o número de
bibliotecas existentes.
2.1.3. Terceira era
A terceira era é caracterizada pelo advento e generalização do uso de
microprocessadores. Surgem assim os computadores pessoais e as estações de
trabalho. Os computadores pessoais funcionaram como um catalisador para muitas
empresas de Software. Outros pontos marcantes desta era foram o aparecimento de
sistemas distribuídos e a implementação de redes de comunicação digitais a nível
global.
2.1.4. Quarta era
Em termos de evolução de Software a quarta era fica definitivamente marcada
pelo aparecimento das linguagens orientadas a objectos e como estas influenciaram o
reaproveitamento de código. Surge também o conceito de maquina virtual, que é um
grande passo em direcção a interoperabilidade do Software.
Em termos comerciais a procura por soluções baseadas em sistemas
informáticos continuou a crescer bem como a complexidade dos sistemas, mas esta era
ficou marcada pela mudança do milénio e pelo aparecimento e vulgarização da Internet.
A mudança de milénio veio expor um erro do Software mais antigo que não estava
preparado para lidar com anos de quatro dígitos, o que gerou uma espécie de pânico
entre os consumidores levando a uma procura sem precedentes por especialistas e
empresas que pudessem corrigir os problemas, ou noutros casos que renovassem os
sistemas. A vulgarização da Internet trouxe grandes expectativas de negócio,
nomeadamente no que se intitulou de comercio electrónico (e-comerce), essas
expectativas geraram ainda mais procura por empresa de Software e surgiram muitas
empresas apenas vocacionadas para o desenvolvimento de páginas de Internet.
2.1.5. Quinta era
Hoje em dia vive-se uma nova era da evolução do Software. A complexidade dos
sistemas implementados tem continuado a aumentar o que tem levado a que os
sistemas sejam subdivididos em componentes por vezes desenvolvidos por fabricantes
diferentes, resultando numa crescente especialização das empresas de Software. Esta
era está também a ser marcada pela introdução do XML em quase todo o Software, de
facto os documentos XML estão a substituir progressivamente os documentos baseados
em formatos fixos.
-6-
Esta nova era parece também ter trazido um novo realismo às tecnologias
baseadas em Internet pois muitas empresas não viram o retorno do investimento feito
nos anos anteriores. Por outro lado uma área de negócio em perfeita expansão é a
relacionada com as tecnologias móveis.
Nos nossos dias é vulgar encontrar numa empresa de média ou grande
dimensão sistemas de Software que foram implementados de forma a facilitar o
funcionamento da empresa tendo em vista o negócio a que a empresa se dedica. Estes
sistemas são em maior parte dos casos desenhados à medida ou adaptados a partir de
Software base e são constituídos por elementos como portais Web, programas de
contabilidade, gestão de stocks, armazéns de dados, etc.. O problema é que estas
soluções tendem a ser algo rígidas e com o tempo vão ficando desactualizadas,
levando a que as pessoas dentro das empresas criem processos alternativos que
escapam ao domínio do sistema informático, ou que o tornam mais confuso.
No caso de empresas mais pequenas, e mesmo em algumas empresas médias
ou grandes, pode-se ainda encontrar a ausência de sistemas de Software, ou seja, a
aproximação à informatização feita passou por comprar ou encomendar Software
específico para cada problema, resultando num conjunto de Software que não interage
e, por vezes, em informação redundante.
!
"Things should be made as simple as possible, but no simpler." – Albert Einstein
Foi Albert Einstein que proferiu esta afirmação há já algumas décadas, e ainda
hoje é relevante para o desenvolvimento de sistemas de Software. O problema é que
muitos sistemas de Software falham o teste de Einstein. Alguns são demasiado simples
para desempenharem as funções que lhes foram atribuídas. Outros são demasiado
complexos e os seus custos de construção e manutenção tornam-se impraticáveis. Por
outro lado, a tarefa de integrar o sistema com sistemas diferentes torna-se praticamente
impossível. É notório que atingir o nível de simplicidade correcto é uma tarefa difícil [He
2003].
O nível de complexidade atingido pelas aplicações dos nossos dias chegou a um
ponto em que é cada vez mais difícil e demorado desenvolver aplicações por medida.
De facto as empresas esperam cada vez mais um maior número de funcionalidades e
características, este cenário leva a que as aplicações sejam subdivididas e
desenvolvidas por empresas especializadas, o que por sua vez causa problemas de
integração. Por outro lado as empresas começam a procurar Software “pré-frabricado”,
pois é mais barato e não é necessário esperar pelo desenvolvimento, no entanto o
custo de integração é sempre muito maior; por vezes após a integração nem todas as
funcionalidades do Software podem ser aproveitadas ao máximo e os sistemas tendem
a ficar mais confusos.
-7-
Na realidade a integração de novo Software, ou mesmo a substituição de
Hardware e outras actividades de manutenção dos sistemas nem sempre são
encaradas com a seriedade e o realismo necessários durante a fase de análise e
projecto. Este é um dos principais motivos pelos quais os sistemas se tornam rígidos e
estáticos. Dois dos principais requisitos impostos pelas empresas começam a ser a
facilidade de integração de Software e a interoperabilidade dos sistemas [Rosenbloom
2003].
"
#
A organização e cooperação entre várias empresas também gera requisitos ao
nível dos sistemas de Software. Um dos requisitos é que o sistema seja capaz de
adquirir dados de várias fontes, este está implicitamente ligado com a capacidade do
sistema em interagir de forma automatizada com os sistemas das outras empresas. Na
realidade a comunicação automatizada entre as empresas já vem sendo estudada há
algum tempo e deu origem a uma tecnologia intitulada Electronic Data Interchange
(EDI), que não é mais do que um esforço que começou no fim dos anos 60 para criar
standards de comunicação entre empresas [EDI History].
$
%
A mobilidade é talvez o mais recente requisito para sistemas empresariais. De
facto, foi apenas nos últimos anos, com o aparecimento de equipamentos móveis
equipados com GSM (Global System for Mobile Communications), GPRS (General
Packet Radio Service), UMTS (Universal Mobile Telecommunications System) ou Wi-fi
(Wireless Fidelity), que a capacidade de acesso a redes informáticas, nomeadamente a
Internet, se tornou praticamente ubíqua. A possibilidade de os clientes poderem aceder
de onde quiserem aos sistemas ou portais das empresas é uma característica bastante
apelativa.
-8-
& !
Uma arquitectura orientada a serviços é essencialmente uma colecção de
serviços interligados que comunicam entre si formando assim um único sistema. A
localização dos serviços não é importante, estes podem ser internos à empresa ou
disponibilizados por outras empresas. A comunicação entre os serviços pode envolver
apenas simples trocas de dados, ou uma coordenação entre dois ou mais serviços
[Barry 2003].
Para compreender claramente o que é uma arquitectura orientada a serviços é
necessário definir o que é um serviço. Um serviço é uma função ou funcionalidade que
se encontra bem definida, que é estanque (self-contained) e que não depende do
contexto ou estado de outros serviços.
%
Ao longo da história, o desenvolvimento de Software foi passado por várias
filosofias ou paradigmas que marcaram as opções tomadas para a implementação de
sistemas de informação nas empresas.
No inicio as aplicações eram desenvolvidas com o intuito de servir uma única
funcionalidade, como por exemplo para gerir a contabilidade de uma empresa. As
aplicações eram independentes e possuíam os seu próprios dados que muitas vezes
eram replicados de aplicação para aplicação; uma aplicação de contabilidade teria
sempre uma lista de funcionários e dos seus salários assim como uma aplicação de
gestão de pessoal. Neste cenário não existia qualquer tipo de interoperabilidade.
Figura 2: Sistema constituído por aplicações isoladas.
-9-
Mais tarde, com a implementação de sistemas gestores de bases de dados, as
empresas começaram a optar por sistemas em que os dados estavam concentrados
numa única base ou armazém. Desta forma era possível eliminar a redundância de
informação dentro do sistema e melhorar a capacidade de manutenção da mesma,
garantindo que quando acontecia uma actualização esta era instantaneamente
verdadeira para todas as aplicações dentro do sistema. Assim sendo, existia uma
partilha efectiva dos dados.
Figura 3: Sistema com partilha de dados através de uma base de dados central.
O passo seguinte foi a evolução para sistemas integrados como o ERP
(Enterprise Resource Planning) que tentam integrar todas as funções da empresa num
único sistema de Software. Construir um sistema que corresponda às necessidades de
todos os departamentos de uma empresa não é uma tarefa simples. Tipicamente, cada
departamento tem aplicações optimizadas para as suas necessidades e para os seus
métodos. O ERP combina todas essas aplicações num único sistema de Software que é
suportado por uma única base de dados, assim sendo os departamentos podem
partilhar dados e comunicar entre si [Koch 2002]. Uma solução integrada pode trazer
grandes benefícios a uma empresa desde que seja implementada correctamente, no
entanto a sua implementação é difícil, morosa e dispendiosa.
- 10 -
Figura 4: Sistema integrados.
Cedo as empresas se aperceberam que seria útil partilhar informação entre si, o
que levou a uma nova filosofia de desenvolvimento que visava a interacção entre
sistemas de Software. Surgem assim o EDI e outras tecnologias para automatizar a
comunicação e a transferência de dados e documentos entre as empresas. Estes
sistemas facilitavam a produção de bens por conjuntos ou associações de empresas e
podiam desempenhar um papel vital aquando de uma fusão ou a absorção de
empresas mais pequenas.
Figura 5: Interacção entre sistemas diferentes.
“As with past computing platform paradigms, the clear goal of SOA is to reap the
benefits of software assembly and enable the construction and maintenance of better,
faster, and cheaper applications.” – Robert Eisenberg, Service-Oriented Architecture:
The Future Is Now
Hoje em dia as empresas desejam mais do que partilhar dados e documentos
entre elas, pretendem partilhar funcionalidades e prestar serviços entre si. Isto é
verdade mesmo entre os departamentos de uma empresa. Esta nova realidade vem
criar um novo paradigma que introduz o conceito de serviço. Este novo conceito passa
por isolar os processos da empresa em serviços por forma a que estes possam ser
- 11 -
reutilizados e combinados criando novas aplicações. Os serviços podem ser utilizados
tanto pela empresa que os disponibiliza como por outras empresas. As arquitecturas
orientadas a serviços são uma implementação deste paradigma.
Figura 6: Arquitectura orientada a serviços.
Olhando para a definição de uma arquitectura orientada a serviços pode-se
verificar que, em princípio, um serviço pode depender de funcionalidades prestadas por
outros serviços. A essas dependências dá-se o nome de dependências reais. O
problema é que, tipicamente, para poder satisfazer as dependências reais é necessário
cumprir alguns requisitos. A esses requisitos é dado o nome de dependências artificiais.
Segue-se um exemplo para a melhor apreensão do conceito de dependências
reais e artificias. Um empresário vai numa viagem de negócios ao Japão e tem
necessidade de se manter em contacto com a sua empresa e os seu clientes, logo
precisa de poder receber as suas chamadas no seu telemóvel. Isto implica duas coisas,
que o seu operador móvel disponha de um serviço de roaming para o país em causa e
que o seu telemóvel seja capaz de funcionar através das infra-estruturas existentes no
mesmo. Assim sendo existe uma dependência real que é a capacidade de receber e
efectuar chamadas a partir de outro país; e duas dependências artificiais: a existência
de um serviço de roaming e a compatibilidade do telemóvel com as redes locais.
A obtenção de Loose Coupling passa pela redução ao mínimo das dependências
artificiais, sem que para esse efeito sejam comprometidas as dependências reais [Allen
Brown 2004]. Voltando ao exemplo, as dependências artificiais seriam eliminadas se
todas os operadores disponibilizassem roaming automaticamente e se todos os
equipamentos fossem compatíveis com todas as redes, ou então se todas as redes
utilizassem uma tecnologia padrão.
- 12 -
Revendo a definição de SOA podemos acrescentar que uma arquitectura
orientada a serviços visa atingir o Loose Coupling entre agentes de Software. Para o
conseguir são aplicadas duas restrições arquitecturais [He 2003]:
1. Estar sempre disponível a todos os intervenientes um pequeno conjunto de
interfaces simples. Apenas a semântica mais genérica pode ser codificada
nos interfaces. Os interfaces devem estar universalmente disponíveis para
todos os fornecedores e todos os consumidores de serviços;
2. As mensagens trocadas através dos interfaces devem ser descritas e
restringidas por um esquema extensível. O funcionamento do sistema não
deve ser afectado pelas mensagens. O esquema limita o vocabulário e a
estrutura das mensagens, este deve ser extensível para permitir que sejam
criadas novas versões do serviço sem que as versões anteriores sejam
prejudicadas.
De facto a redução e simplificação dos interfaces é um grande passo para a
obtenção do Loose Coupling. Os interfaces entre aplicações distribuídas são propensas
a erros e de desenvolvimento complicado principalmente entre plataformas e linguagens
diferentes. Assim sendo faz todo o sentido reutilizar interfaces genéricos.
3.3.1. Mensagens
Sendo as ligações fundamentais numa arquitectura orientada a serviços, não
menos importantes são as mensagens que passam através dessas mesmas ligações.
Qualquer tipo de mensagem pode ser enviada através das ligações mas existem
algumas regras que devem ser observadas para que se possa falar em orientação a
serviços [Lane 2004].
Primeiro as mensagens têm que ser descritivas e não instrutivas, a
responsabilidade de resolver o problema é do fornecedor do serviço, o consumidor
apenas necessita de explicar o problema. Pode-se encontrar muitos exemplos de como
esta regra é aplicada na vida real, nomeadamente, quando se leva um carro a um
mecânico não se lhe diz como o deve consertar mas sim os sintomas que detectamos.
Em segundo lugar, as mensagem têm que ser perceptíveis para o fornecedor do
serviço, ou seja, têm que estar escritas num formato, estrutura e vocabulário que é
compreendido por ambas as partes.
Estas limitações são necessárias para que a comunicação seja eficiente. Quanto
mais restritivo for o vocabulário e a estrutura da mensagem, mais fácil é a sua
compreensão, no entanto, desta forma, limita-se a extensibilidade do serviço.
Por último, a extensibilidade é um factor a ter em conta. O mundo está em
evolução constante e os sistemas de Software devem ser capazes de se adaptar as
mudanças que vão ocorrendo. Numa arquitectura orientada a serviços o
acompanhamento da evolução é feito renovando os serviços, ou contratando serviços
mais recentes a empresas diferentes. Caso as mensagens não sejam extensíveis
qualquer alteração do lado do serviço ou do consumidor que provoque modificações
nas mensagens vai provocar uma quebra de serviço. Basicamente a extensibilidade
- 13 -
significa que existe uma estrutura e um vocabulário base que todas as mensagens tem
que respeitar, sendo que qualquer parte pode enviar informação adicional nas
mensagens podendo esta ser utilizada ou não. Por exemplo, a empresa A contrata um
serviço de previsão metrológica à empresa B. Fica acordado que sempre que
necessário será enviada uma mensagem indicando o período temporal para o qual se
pretende a previsão, à qual a empresa B responderá com uma mensagem indicando a
previsão de temperatura e de condições atmosféricas (sol, chuva, etc.) para todos os
períodos de cinco horas contidos dentro do intervalo pedido. Uma empresa C contrata
exactamente o mesmo serviço, mas passado algum tempo apercebe-se que lhe seria
útil dispor de uma forma de indicar o tamanho dos intervalos em que a previsão é
devolvida e que também fosse fornecida a previsão da humidade. Estes novos
requisitos levam a empresa B a alterar o serviço de forma que seja indicado no pedido o
tamanho dos intervalos de resposta e para que seja incluída na resposta a previsão da
humidade. Caso não exista extensibilidade, a empresa A encontra-se numa situação de
quebra de serviço e dispõe apenas de duas possibilidades, alterar o seu sistema por
forma a conseguir aceder à nova versão do serviço, ou obrigar a empresa B a repor a
versão anterior do serviço. Se as mensagens forem extensíveis não existe qualquer
problema. A empresa A continuará a receber as previsões em intervalos de cinco horas
pois não indica um tamanho diferente para o intervalo, só que passa a receber também
a previsão da humidade que é ignorada pelo sistema pois não pertence à especificação
inicial da comunicação com o serviço. Note-se que a empresa A pode desejar alterar o
seu sistema para incorporar qualquer uma das alterações introduzidas na nova versão
do serviço, mas a grande vantagem trazida pela extensibilidade é que não é obrigatório
que o faça.
Apesar da importância da extensibilidade esta tem sido muitas vezes
considerada como uma boa pratica e não como algo de fundamental, mas não haja
duvidas de que o é numa arquitectura orientada a serviços. O problema é que a
restrição e a extensibilidade estão intimamente ligadas e é impossível aumentar a uma
sem diminuir a outra. O truque está em encontrar o equilíbrio certo entre a duas [He
2003].
3.3.2. Documentos XML
Tendo em conta a importância da extensibilidade nas mensagens trocadas entre
os serviços, a escolha lógica parece recair sobre a utilização de XML. De facto a troca
de mensagens baseadas em documentos XML satisfaz as condições necessárias para
a obtenção de Loose Coupling. Os documentos XML podem ser restringidos por XML
Schemas e, a não ser que as restrições não o permitam, podem ser estendidos.
A finalidade de um Schema (esquema) [Fallside 2001] é definir uma classe de
documentos XML, e assim sendo a expressão “instance document” é usada
frequentemente para descrever um documento XML que esteja em conformidade com
um Schema. Os Schemas XML exprimem vocabulários e definem as regras sobre as
quais pode ser escrito um determinado tipo de documento XML, e permitem também a
validação de documentos. Basicamente são um meio para definir a estrutura, os
conteúdos e semântica de um documento XML, sendo um meio por excelência para
definir os termos do contracto de comunicação entre os sistemas. Os Schemas acabam
por ser a evolução das DTDs (Document Type Declaration) criadas para o SGML
(Standard Generalized Markup Language) mas que vinham sendo aplicadas ao XML.
- 14 -
Um documento XML contém informação auto-descritiva, permitindo
simultaneamente que cada aplicação processe as etiquetas como entender. Ou seja
para uma aplicação uma etiqueta <paragrafo> pode significar mudança de linha e
indentação do texto, para outra pode significar deixar uma linha em branco entre os
blocos de texto. O facto das etiquetas poderem ter significados diferentes para
aplicações diferentes pode dificultar a obtenção de Loose Coupling, mas é necessário
ter em mente que as mensagens XML devem ser descritivas ou informativas e nunca
instrutivas e que devem respeitar um esquema conhecido por ambas as partes, ou seja,
um contracto pré estabelecido. No entanto o problema pode subsistir numa arquitectura
orientada a serviços. Ou seja, tipicamente, numa SOA as aplicações ligam-se ao
sistema através de uma única conexão que respeita um interface simples de troca de
mensagens e todas as mensagens passam por um Bus ou um Router que garante a
sua entrega aos serviços correcto, muitas vezes é introduzida lógica no Bus ou no
Router para transformar as mensagens de modo a que estas passem a estar de acordo
com o esquema esperado pelo destinatário [Mark Endrei 2004].
Uma das desvantagens de utilizar XML é que as mensagens tendem a tornar-se
muito maiores. Assim sendo existe aqui uma questão de performance. Ao utilizar XML
troca-se a performance por flexibilidade, no entanto quanto maior for a largura de banda
para comunicação menos se notará este problema.
"
'
Já foram discutidas neste documento algumas restrições arquitecturais
nomeadamente no que diz respeito aos interfaces e às mensagens que passam por
esses mesmos interfaces. No entanto existem algumas restrições ou guias de boa
prática que podem ser aplicadas para melhorar a escalabilidade, a performance e a
fiabilidade do sistema.
3.4.1. Independência do estado
Cada mensagem que o consumidor envia para o fornecedor de serviços deve
conter toda a informação necessária para que o pedido seja processado. Isto faz com
que o serviço seja mais escalável pois o fornecedor não tem que armazenar informação
sobre o estado entre pedidos. Pode-se considerar que também é melhorada a
visibilidade pois qualquer Software de monitorização, como uma firewall, pode
facilmente inspeccionar um único pedido e determinar se constitui ou não uma ameaça.
Não existindo estados a recuperação a falhas também se torna mais fácil, fazendo com
que o serviço se torne mais fiável.
3.4.2. Dependência do estado
A dependência do estado é difícil de evitar em várias situações. Em muitas
situações opta-se por criar sessões para tornar o processo mais eficiente, por exemplo
para evitar negociações de segurança em todas as comunicações. Os serviços
dependentes do estado requerem que tanto o consumidor como o fornecedor partilhem
- 15 -
o mesmo contexto, que pode ser referenciado ou incluído nas mensagens trocadas. O
problema é que assim pode-se estar a comprometer a escalabilidade do sistema,
principalmente do lado do fornecedor do serviço pois é este que tem que manter a
informação sobre o estado. Também se pode aumentar as dependências artificiais
diminuindo as possibilidades de obtenção de Loose Coupling, eventualmente pode-se
gerar uma dependência do fornecedor e impossibilitar a troca por outro fornecedor.
3.4.3. Idem-potência
Os pedidos repetidos devem ter o mesmo efeito de que um único pedido, ou
seja, o sistema deve exibir um comportamento idem-potente. Desta forma, a fiabilidade
do sistema pode melhorar uma vez que não existe nenhum problema em repetir um
pedido quando acontece um falha. Tome-se como exemplo o caso de uma transferência
bancária, não é razoável que um pedido para transferir dinheiro entre duas contas
bancárias seja executado mais que uma vez se o protocolo de transporte repetir a
mensagem por falha de comunicação.
$
Como se verificou anteriormente uma SOA é essencialmente um conjunto de
serviços que comunicam ente si e na qual as ligações entre esses serviços
desempenham um papel fundamental. As ligações são feitas através de Middleware
que esconde a complexidade das comunicações entre os serviços, simplificando assim
o seu desenvolvimento. Convém recordar que os serviços podem não estar a correr na
mesma maquina ou até no mesmo sistema, e que o Software que compõe o serviços
pode ser desenvolvido em linguagens diferentes e para plataformas diferentes. Hoje em
dia os Web Services são vistos como a melhor opção para Middleware de comunicação
numa arquitectura orientada a serviços [Barry 2003].
Figura 7: Arquitectura de Middleware básica.
- 16 -
Ao longo dos anos tem sido desenvolvidos vários tipos de Middleware, como por
exemplo: Transaction precessing monitors (TP monitors); Remote Procedure Call
(RPC); Message-Oriented Middleware (MOM); Object Request Broker (ORB). No
entanto o Middleware mais vulgarmente utilizado é o baseado na especificação de
Common Object Request Broker Architecture (CORBA) do Object Management Group e
o Distributed Common Object Model (DCOM) da Microsoft.
3.5.1. CORBA e DCOM
O CORBA e o DCOM são Middleware e podem ser interoperáveis através de
pontes CORBA/DCOM. Ambos se apresentam como uma tecnologia relativamente
madura para criar aplicações distribuídas. O que leva ao investimento nestas
tecnologias é a sua capacidade para criar aplicações interoperáveis sobre redes. No
entanto é necessário olhar para o CORBA e o DCOM apenas como um meio de fazer
transitar a informação entre dois pontos, tendo em mente que não existem
requerimentos especificados para como deve ser formatada essa informação. Assim
sendo a falta de standards ao nível da indústria, as diferenças entre semânticas e a
tradução entre as mesmas podem causar problemas a comunicação. No entanto, a
comunicação pode ser feita tomando partido de tecnologias como o XML, que não se
baseiam em formatos de registo fixo, para suplantar estes problemas.
Um dos problemas que envolve o CORBA e o DCOM é a percepção por parte de
potenciais consumidores de que nenhum deles é utilizado em grande escala e que de
que a sua utilização é demasiado complexa para a maior parte dos programadores.
Embora estas percepções possam não estar correctas, o facto é que influenciam as
decisões que podem levar ou não a utilização destas tecnologias.
Considerando todos os aspectos pode-se reconhecer que o CORBA ou o DCOM
são soluções viáveis para implementar o Middleware numa arquitectura orientada a
serviços [Framingham 2003]. Mesmo assim é necessário lembrar que sempre que se
quiser que o sistema interaja com outros sistemas ou com novo Software, vai ser
necessário que estes suportem a tecnologia adoptada, ou então, vai ser necessário
aplicar pontes ou adaptadores desenvolvidos a medida.
3.5.2. Web Services
A utilização de Web Services como Middleware numa SOA parece ser a forma
mais simples de criar sistemas e serviços interoperáveis. Os Web Services utilizam
nativamente XML, tendo assim a flexibilidade necessária para a troca de mensagens, e
podem utilizar um grande número de protocolos de rede, incluindo o HTTP (HyperText
Transfer Protocol), que hoje em dia é praticamente ubíquo. O facto é que o conceito
subjacente aos Web Services foi apreendido facilmente pelos fornecedores de
Software, e estes rapidamente começaram a incorporar esta tecnologia nos produtos e
serviços [Colan 2004]. Isto resultará a curto e médio prazo num grande número de
serviços que poderão ser contratados a empresas externas e em pacotes de Software
que poderão ser integrados no sistema numa questão de poucas horas.
- 17 -
Para as organizações que investiram na aplicação de CORBA ou DCOM a
utilização de Web Services não significa que todo esses esforço seja abandonado.
Trata-se apenas de adaptar o Middleware e não de refazer todo o sistema substituindo
os serviços que utilizavam Middleware antigo. Embora ao longo do tempo esses
serviços possam vir a desaparecer [Barry 2003].
Figura 8: Interoperabilidade entre Web Services e CORBA ou DCOM.
(
)
Sendo que uma arquitectura orientada a serviços pode ser vista como um
conjunto de serviços interligados de uma forma simples, por forma a que exista Loose
Coupling, uma vez criada a infra-estrutura necessária todos os serviços se encontram
num estado em que podem ser utilizados e reutilizados por forma a criar aplicações. A
infra-estrutura SOA é como uma base sobre a qual se montam peças Lego, sendo que
cada serviço é uma peça que pode ser montada na base e que pode ser combinada
com as outras peças por forma a construir novas aplicações.
Tendo em conta que um serviço encapsula um processo de negócio simples,
numa SOA as aplicações são agregações de serviços. Num nível conceptual mais alto,
os processos da empresa, podem apoiar-se em vários processos internos. Por exemplo,
um processo de recepção de encomendas pode passar pela utilização de serviços
internos de encomenda, pagamento e entrega.
- 18 -
Figura 9: Agregação de serviços [Lawrence Wilkes 2004].
A capacidade de agregar serviços torna as arquitecturas orientadas a serviços
muito ágeis quando é necessário acompanhar as novas tendências do mercado, pois
construir novos processos de alto nível pode apenas significar agregar serviços
existentes de uma forma diferente. Voltando ao exemplo, tanto o serviço de pagamento
como o serviço de entregas podem ser utilizados por uma aplicação interna de venda
directa a clientes em lojas.
Criar aplicações para os processos através da agregação de serviços traz outras
vantagens como a capacidade de substituição de serviços e a indiferenciação entre
serviços internos e serviços externos.
Tendo em conta que para a aplicação não importa como o serviço está
implementado, apenas interessa que respeite uma determinada interface e que produza
os resultados pretendidos, alterar a implementação de um serviço não provoca qualquer
alteração na aplicação. De facto, um serviço pode mesmo ser completamente
substituído sem que seja necessário efectuar alterações nas aplicações, desde que seja
mantida a compatibilidade com a interface.
Com a definição de standards regulando o que cada tipo de serviço deve fazer e
que interface deve disponibilizar, as empresas podem optar por contratar determinados
serviços a empresas externas e especializadas no assunto em causa, visto que para as
aplicação é indiferente onde se encontra o serviço ou quem é responsável pela sua
implementação. Desta forma o desenvolvimento de serviços tenderá a ser feito fora da
empresa, ficando as equipas internas responsáveis pela manutenção das ligações,
integração de novos serviços e pela agregação dos serviços por forma a modelar os
processos de negócio e aplicações necessárias.
- 19 -
*
+
“Companies that are embracing SOAs are finding huge benefits. Some of these
benefits are expected, such as increased revenue opportunities through collaboration,
improved decision making through shared data, and decreased personnel costs through
automated workflow. But many of the benefits of SOAs are unexpected, such as
dramatic improvements in system reliability, huge reductions in development and
deployment costs, migration of systems from expensive mainframe to inexpensive server
clusters and impressive improvements in time to market.” – Roger Sessions,
Interoperability Through Service-Oriented Architectures (SOAs)
Uma arquitectura orientada a serviços pode ajudar as empresas a atingir uma
nível de flexibilidade que lhes permita acompanhar os rápidos desenvolvimentos dos
mercados e rentabilizar os seu recursos por forma a reduzir os custos [Mark Endrei 2004].
3.7.1. Reaproveitamento de recursos
As SOAs fornecem um camada de abstracção que permite às empresas
aproveitar o investimento feito anteriormente em tecnologias de informação, envolvendo
os recursos existentes como serviços que disponibilizam funcionalidades de negócio.
Desta forma as empresas podem continuar a retirar valor desses recursos sem que seja
necessário recomeçar do inicio.
3.7.2. Facilidade de integração e de manutenção
O ponto de integração numa arquitectura orientada a serviços é a especificação
do serviço e não a sua aplicação, ou seja o que importa é o que o serviço faz e não
como o faz. Assim sendo a forma como os serviços estão implementados torna-se
transparente, o que minimiza o impacto no sistema quando há alterações na sua infraestrutura ou na implementação dos serviços. A manutenção do sistema torna-se
também mais simples pois as ligações são mais simples e a complexidade está isolada
nos serviços. A facilidade de integração torna-se ainda mais importante tendo em vista a
cooperação entre várias empresas.
3.7.3. Maior capacidade de reacção
A capacidade de criar novos serviços a partir de serviços já existentes é uma
vantagem para as empresas que necessitam de ter agilidade e de responder
rapidamente as exigências do mercado. A reutilização de componentes faz com que o
tempo de desenvolvimento do Software necessário seja reduzido, o que leva a uma
rápida criação de novos serviços que implementam novas funcionalidades de negócio.
Desta forma o tempo que os produtos levam a atingir o mercado é reduzido e a
empresa adapta-se mais rapidamente as mudanças. Por outro lado, melhora também a
capacidade de tomada de decisão pois os dados são partilhados entre todos os
serviços, o que por sua vez melhora a capacidade de reacção da empresa as
alterações do mercado ou as oportunidades de negócio.
- 20 -
3.7.4. Redução de custos e aumento da reutilização
Com os processo básicos de negócio expostos num sistema onde o Loose
Coupling é regra, estes podem ser facilmente reutilizados e combinados por forma a
satisfazer as necessidade de negócio. Isto significa menor duplicação de recursos,
maior potencial de reutilização e menores custos de desenvolvimento e manutenção.
Aos SOAs também potencializam a automatização de processos através de programas
de Workflow, reduzindo assim os custos com o pessoal.
3.7.5. Preparação para o futuro
As SOAs permitem às empresas estarem preparadas para o futuro. Processos
que envolvam uma série de serviços relativos ao negócio podem ser criados,
modificados e mantidos facilmente ao longo do tempo, correspondendo assim às
necessidades da empresa. Uma SOA fornece flexibilidade e adaptabilidade,
características que são criticas para quase todos os negócios.
,
-
Nesta secção vão ser apresentados alguns exemplos, tanto de serviços simples
disponibilizados por empresas como de implementações de arquitecturas orientadas a
serviços. Os exemplos de implementações forma retirados de um estudo feito por Roger
Sessions e publicado num White Paper da ObjectWatch intitulado: Interoperability
Through Service-Oriented Architectures (SOAs).
3.8.1. Google Web API
A Google é uma empresa que fornece um serviço de pesquisas na Internet
através do seu motor de busca, quer a partir da sua página de Internet, quer a partir de
soluções integradas noutras aplicações. Actualmente fornece acesso a mais de 4 biliões
de páginas e responde a mais de 100 milhões de consultas por dia [Google Profile].
A Google disponibiliza um serviço intitulado Google Web API que permite,
mediante a obtenção de uma chave, aceder a um Web Service e utilizar o motor de
buscas da empresa. O serviço publica três funcionalidades, pesquisa de páginas de
Internet no index da Google, obtenção de páginas em cache e sugestões de correcção
ortográfica [Google Web APIs].
A API da Google é um bom exemplo de um serviço simples disponibilizado via
Internet. A empresa fornece o serviço gratuitamente, embora limitado a 1000 pesquisas
por dia, e recebe em troca uma maior utilização do seu produto através da integração
em aplicações e páginas de Internet pessoais ou de outras empresas. Desta forma a
Google valoriza-se obtendo assim maior capacidade para atrair patrocínios.
- 21 -
3.8.2. Amazon Web Service
A Amazon é um empresa de vendas na Internet que ficou conceituada pela
venda de livros, que inicialmente era o único produto oferecido aos clientes. Um dos
seus primeiros objectivos é ter qualquer livro disponível para entrega imediata.
O Amazon Web Service (AWS) fornece acesso directo ao sistema da empresa,
sendo possível através deste aceder ao catálogo de informação, criar e popular um
cesto de compras e até iniciar o processo de pagamento. Para aceder ao serviço é
apenas necessário obter um identificador de associado que é gratuito [Amazon Web
Sevice].
Os benefícios que este serviço proporciona à Amazon são simples de perceber,
quantos mais páginas de Internet e aplicações utilizarem este serviço, mais a Amazon
terá acesso a potenciais clientes.
3.8.3. Qwest – Um exemplo de SOA aplicado em grande escala
A Qwest é uma empresa de telecomunicações que fornece soluções de voz,
Internet, dados e vídeo para particulares, empresas e organizações publicas. Tem cerca
de 45800 empregados e transmite aproximadamente 240 milhões de chamadas todos
os dias.
3.8.3.1. O sistema informático da Qwest
A Qwest dispõe de mais de 1000 aplicações de negócio actualmente em
produção e em várias plataformas diferentes. As aplicações são suportadas por 40
equipas de desenvolvimento compostas por mais de 500 programadores. As seguintes
formas podem ser utilizadas para aceder aos sistemas da Qwest:
Interfaces de cliente para os Help Desks dos serviços de clientes e serviços
de pessoal acederem ao sistema da Qwest;
Os técnicos que fazem o trabalho de rua acedem ao sistema utilizando
tipicamente GPRS ou modems de linha telefónica;
O portal MyQwest.com fornece acesso ao sistemas a mais de 20 mil clientes
por dia, utilizando browsers diferentes;
Utilizando reconhecimento de voz os clientes podem aceder ao sistema
através dos seus telefones;
Aplicações exteriores a empresa que podem significar uma fonte de
rendimentos adicional.
3.8.3.2. A SOA da Qwest
Para simplificar o desenvolvimento de aplicações a Qwest definiu um Standard
Operating Environment (SOE). O SOE é um conjunto de componentes, serviços e APIs
que podem ser utilizadas por qualquer programador da Qwest e que inclui suporte para
acesso as bases de dados, comunicações e segurança entre outros. O SOE é mantido
e evoluído através da cooperação entre as equipas de desenvolvimento e de
Operações.
- 22 -
No seu todo a arquitectura do sistema da Qwest pode ser vista como uma série
de zonas relacionadas, com demonstra a Figura 10. Esta solução baseada em zonas
tem várias vantagens:
É muito segura;
Acomoda facilmente a heterogeneidade;
É altamente escalável;
É altamente fiável.
Figura 10: Relações entre as zonas.
A zona exterior (outside zone) é a área que fica fora do controlo imediato da
Qwest. Esta inclui principalmente os clientes que entram no domínio através de
browsers, mas também as aplicações que acedem via SOAP (Simple Object Access
Protocol).
A zona de buffering de tráfego vindo da Internet (IBZ - internet buffer zone) é a
área que aceita os pedidos vindos da zona exterior. É uma zona de segurança isolada,
protegida por firewalls e outros mecanismos, é semelhante a uma DMZ (Demilitarized
Zone). Os pedidos que chegam através do portal MyQwest.com são processados por
aplicações ASP.NET. Os pedidos de aplicações exteriores que chegam via SOAP são
processados por representantes internos (surrogates). Ambos partilham as seguintes
características:
- 23 -
Correm sobre “quintas” de servidores 1 com carga balanceada;
Correm dentro de um ambiente IIS;
Não contêm lógica de negócio, apenas sabem como receber pedidos e
interagir com clientes;
Quando necessitam que seja executada lógica de negócio, fazem os pedidos
correspondentes a zona de aplicações;
Sempre que é necessário armazenar dados, como por exemplo dados de
sessão, estes são armazenados na base de dados que faz parte da IBZ.
A principal vantagem da IBZ é a segurança. Ao criar a IBZ a Qwest consegui
proteger os seus sistemas críticos de negócio de acessos não autorizados, pois estes
estão em zonas interiores, e mesmo que esta zona seja comprometida não existe nada
de crítico nela e nada que não possa ser reposto rapidamente.
A zona que se segue é a zona de aplicações (AZ – application zone). A AZ
alberga as aplicações que contêm a lógica dos processos críticos de negócio. Estes
sistemas podem ser construídos quer em .NET quer em J2EE. Na Qwest os sistemas
J2EE são tipicamente WebLogic a correr sobre UNIX e os .NET correm sobre Windows.
A Qwest permite a cada grupo que faça as suas próprias escolhas dentro do SOE
suportado e foca as suas políticas empresariais em como essas aplicações devem
interagir e em que serviços o SOE deve fornecer.
A AZ é também uma zona de segurança, pois está protegida da IBZ pela suas
próprias firewalls e políticas de segurança. As aplicações dentro da AZ armazenam os
dados dentro da zona de dados (DZ – data zone) que está fortemente associada com a
AZ. Ver a DZ como uma zona separada da AZ é justificável pela especificidade da sua
função e do Hardware necessário. Para aceder a DZ as aplicações utilizam os serviços
de base de dados disponibilizados pelo SOE.
A Qwest utilizou está arquitectura para atingir um alto grau de interoperabilidade.
As aplicações são capazes de comunicar entre si através de um Message Bus ou
utilizando SOAP. Segundo a Qwest, atingir interoperabilidade entre aplicações .NET e
aplicações J2EE é mais difícil do que entre duas aplicações .NET ou duas aplicações
J2EE.
3.8.3.3. Benefícios
Os principais benefícios que a Qwest retira da sua utilização de SOA são os
seguintes:
Alto grau de interoperabilidade entre aplicações;
Uma excelente fiabilidade e escalabilidade através da utilização de quintas
de servidores;
Um sistema altamente seguro através da utilização da IBZ;
1
Da terminologia anglo-saxónica “Server farms”
- 24 -
3.8.4.
CACU – Um Exemplo de Workflow automatizado
A CommunityAmerica Credit Union (CACU) foi fundada em 1940 e hoje em dia é
uma das maiores companhias de crédito do Midwest americano, com mais de 110 mil
membros e com o valor dos seus bens a exceder o bilião de dollars. Os seus productos
incluem bancos online, fundos de mercado, empréstimos, hipotecas, cartões de crédito,
seguros e serviços de correctores de bolsa. O projecto é encabeçado por Byron Healy,
Arquitecto Técnico Sénior de Serviços de Informação.
3.8.4.1. O sistema informático da CACU
O sistema da CACU era originalmente constituído por mainframes. Maior parte
das operações da empresa corriam a partir de dois mainframes, sendo que o mais
antigo começa a apresentar sinais evidentes de fadiga, a empresa decidiu fazer uma
reestruturação arquitectural. O seu objectivo não era eliminar as mainframes, mas sim
utiliza-las onde estas faziam mais sentido. A CACU considerou que o lugar certo para
os mainframes era o de anfitrião para o back-end de finanças.
3.8.4.2. A SOA da CACU
Uma aproximação SOA permitiu a CACU utilizar várias aplicações, plataformas
de programação e tecnologias de desenvolvimento diferentes. As aplicações podem
assim utilizar as ferramentas que precisam de utilizar. Ao nível de toda a empresa só
são aplicadas restrições ao estilo da interoperabilidade com a SOA. Sendo elas:
O BizTalk é o standard para a orquestração de workflow. O BizTalk é uma
ferramenta para gerir processos de workflow complexos que inclui a
capacidade de traduzir dados, gerir comunicações assíncronas e coordenar
o processamento de erros.
SOAP é o standard para o formato das mensagens.
A direcção do projecto considerou que a interoperabilidade e a reutilização
deviam ser conseguidas através do encapsulamento das aplicações como Web
Services e que sempre que possível os sistemas deviam ser respeitar as regras XML,
mais especificamente as regras CU-XML (credit union XML, um conjunto de definições
XML especificas para uniões de crédito).
Ao manter as suas aplicações financeiras nas mainframes UNIX e ao mover
aplicações seleccionadas para novas “quintas” de servidores aplicacionais, a CACU
obteve os beneficios de uma arquitectura estilo SOA sem ter que pagar o preço de
mover as bases de dados e as aplicações de processos críticos.
O que faz com que todo o sistema funcione não é apenas os Web Services e o
BizTalk, mas também uma boa arquitectura, bons processos de negócio, muita atenção
a infra-estrutura técnica e muita comunicação. Desde o tempo dos sistema baseado em
mainframes a confiança no departamento de Tecnologias da Informação cresceu
significativamente. Ao adoptar uma solução SOA o departamento ganhou rapidamente
a reputação de desenvolver sistemas com alta fiabilidade e usabilidade.
- 25 -
“They are amazed at our ability to manage projects. We participate in every major
decision in the organization. I can’t do justice to how much we have benefited. Our data
systems are now state-of-the-art and best-of-breed. For us and our credit union
members, the value has been compelling.” – Byron Healy, Arquitecto Técnico Sénior de
Serviços de Informação da CACU
A utilização de Web Services permitiu a CACU construir aplicações agregando
blocos de código que já existiam. A utilização do Visual Studio e do BizTalk tornou a
construção dessa aplicações tão simples como fazer drag and drop.
3.8.4.3. Benefícios
Os principais benefícios que a CACU retirou da sua utilização de SOA são:
Um alto grau de ineroperabilidade entre aplicações;
O isolamento do mainframes de back-end como Web Services;
Uma grande redução nos custos de desenvolvimento.
3.8.5. Avista Corp. – Um exemplo de conectividade de Mainframes
Outro exemplo de uma empresa que se está a focar na integração é a Avista
Corp., que é uma das empresas lideres de mercado da electricidade no oeste
americano. Foi fundada em 1889 e tem cerca de 1800 empregados. Os seu produtos
compreendem gestão de equipamentos baseada em Internet, consolidação de dividas e
pagamento de serviços. O analista responsável pela equipa de desenvolvimento é
Dennis Crumb.
3.8.5.1. O sistema informático da Avista
O sistema original da Avista corria sobre um mainframe IBM. Programas
cliente/servidor desenvolvidos em COBOL/CICS (Customer Information Control System)
controlavam tudo desde a facturação aos clientes até a decisão de como fazer chegar
electricidade a uma nova morada. A quantidade de código na mainframe era massiva,
incluindo cerca de 400 programas desenvolvidos durante um período de 5 anos, com o
seu custo a ascender aos 17 milhões de dollars.
A Avista queria permitir que os seu consumidores vissem e pagassem as suas
contas através de um browser de internet e que assim gerissem a informação das suas
próprias contas. A ideia era reduzir ao número de intermediários humanos e melhorar os
serviços de cliente.
3.8.5.2. O processo de decisão da Avista
Para a Avista a questão tornou-se como migrar de uma arquitectura CICS
mediada por pessoas para uma arquitectura acessível pelos clientes via internet.
Existiam então duas opções, rescrever ou mediar.
A Avista podia ter rescrito todo o seu sistema utilizando novas plataformas
tecnológicas que facilitam o acesso a Internet, como por exemplo o WebSphere da IBM
ou o .NET da Microsoft.
- 26 -
A segunda opção passava por construir mediadores de Software que fizessem
de interface entre a Internet e o sistema. Para a Avista a complexidade subjacente a
rescrever todo o sistema levou a decisão de implementar mediadores. A questão
seguinte era que tecnologia é que seria usada com base para a mediação.
Por outro lado a Avista não podia negligenciar o workflow. Tipicamente a
mediação não é uma operação simples de um para um. Ou seja, se um consumidor
deseja realizar uma operação “simples” como pagar uma conta, essa operação pode
requerer a coordenação de muitos programas na mainframe. No sistema antigo a
coordenação era feita por empregados treinados especificamente para a tarefa. No
novo sistema essa coordenação teria de ser feita através de Software.
A Avista também queria abrir os seu sistemas a colaboração externa, como
pagamentos efectuados através de sistemas parceiros estratégicos.
Qualquer que fosse a tecnologia escolhida, teria que satisfazer os seguintes
requisitos:
Ser implementada sem que se rompesse com os sistemas CICS existentes
que correm nas mainframes IBM;
Ser compatível com DB2 existente na mainframe;
Ser compatível com Oracle, que é utilizado para o armazenamento local dos
dados;
Ser escalável, por forma a satisfazer centenas de clientes por dia;
Proporcionar tempos de resposta considerados rápidos, tipicamente abaixo
dos 2 segundos;
Fornecer alta segurança;
Fornecer alta disponibilidade;
Possuir ferramentas para criar páginas de Internet interessantes;
Ser extensível para outras soluções não baseadas em acesso via browser.
Existiam ainda alguns requisitos que não eram obrigatórios mas que eram
considerados como agradáveis:
Baixo custo de aquisição;
Baixo custo de formação;
Baixo custo de desenvolvimento;
Menor número de alterações possiveis a mainframe.
A Avista considerou três produtos para mediação: o WebSphere CICS
Transaction Gateway da IBM, o WebSphere MQ (Message Queue) também da IBM, e o
Microsoft HIS (Host Integration Service).
Utilizando o WebSphere CICS Transaction Gateway para a mediação seria uma
escolha lógica uma vez que é a tecnologia standard, proporcionada pela IBM, para
conectar ao seu CISC. No entanto, está opção significaria um compromisso
generalizado ao IBM WebSphere. Por causa de incompatibilidade de versões com o
CISC da Avista esta opção foi descartada.
- 27 -
Utilizar o IBM WebSphere MQ como base para a mediação era tecnicamente
atraente, pois é uma tecnologia baseada em filas de mensagens que fornece
transportação assíncrona de alta qualidade e corre tanto em mainframes da IBM como
em sistemas operativos Microsoft Windows. Existem muitas formas pelas quais esta
tecnologia poderia ter sido utilizada, mas uma seria ter os servidores de Internet
directamente ligados a maquina CICS através do WebSphere MQ.
Outro produto considerado para a mediação foi o Microsoft HIS 2000 (Host
Integration Service 2000). O HIS é basicamente uma colecção de tecnologias que
juntas fornecem conectividade a mainframes. O subconjunto do HIS que a Avista
analisou foi o COM-TI, que funciona projectando um sistema CICS num componente
COM alojado num processo de um sistema operativo Windows. O componente COM
disponibiliza uma interface COM que é funcionalmente equivalente a interface o CICS. A
invocação de métodos do componente COM é automaticamente reencaminhada pelo
COM-TI para o sistema CICS que está a correr no back-end.
Existiam dois factores a favorecer o HIS. Primeiro porque não requeria qualquer
alteração na mainframe, pois para o sistema CICS o HIS era visto apenas como outro
cliente CICS. Segundo porque o custo de licenças era de apenas 2 mil dollars por
servidor, o que era apenas uma fracção do custo da solução baseada em WebSphere
MQ. A capacidade de reutilizar os seus sistemas CICS sem ter que efectuar alterações
a mainframe e o baixo custo do HIS foram os principais factores na sua escolha.
3.8.5.3. A SOA da Avista
Com o HIS, as funcionalidades do CICS são disponibilizadas através de
componentes COM, mas isto é apenas parte da resposta. Os componentes COM
podem ser utilizados pelas tecnologias Microsoft mas não são de forma alguma uma
standard de industria. Se a Avista pertendia que o seu sistema interoperasse com uma
variedade de sistemas diferentes, incluindo sistemas não Microsoft, era necessário
optar por algo que fosse aceite como um standard, a escolha recaiu sobre o SOAP.
Foi então introduzido um SOAP wrapper que traduzia os pedidos vindos dos
clientes em SOAP para o servidor HIS, que por sua vez reencaminhava os pedidos para
o CICS.
Figura 11: Arquitectura da Avista
- 28 -
Hoje em dia a Avista gere o workflow programaticamente, dentro dos
componentes SOAP, mas está a planear mover o código de dentro dos componentes
Web Services que tiveram de escrever, para orquestração feita através de BizTalk. Os
componentes de Web Services que incluíam o workflow serão então substituídos por
novos componentes que serão front-ends para o BizTalk.
Utilizar o BizTalk vai permitir a Avista criar orquestrações de workflow altamente
sofisticadas, incluindo tradução de dados, transacções compensatórias e integração
com muitas outras tecnologias.
3.8.5.4. Benefícios
Os benefícios principais que a Avista retirou da sua utilização de SOA foram:
Reutilização do investimento de 17 milhões de dollars existente no sistema
CISC sem alterações a mainframe;
Alto grau de interoperabilidade entre aplicações;
Redução dos custos com o pessoal através da automatização do workflow;
Redução dos custos de desenvolvimento.
- 29 -
"
"Interoperability: The capability to communicate, execute programs, or transfer
data among various functional units in a manner that requires the user to have little or no
knowledge of the unique characteristics of those units." – ISO/IEC 2382 Information
Technology Vocabulary
A interoperabilidade entre Software tem sido uma das áreas mais sensíveis das
tecnologias de informação, pois requer quase sempre que empresas concorrentes
cooperem entre si por forma a definir standards. Pode-se considerar como exemplo o
esforço que tem sido feito para a obtenção de um standard de ficheiro CAD (Computer
Aided Design) satisfatório. O problema agrava-se quando se começa a falar de
interoperabilidade entre sistemas ou de componentes dentro de um mesmo sistema de
Software. De facto os componentes ou sistemas podem divergir muito uns dos outros,
principalmente porque o Hardware pode ser diferente, o sistema operativo pode ser
diferente e a linguagem de programação utilizada pode ser diferente. Olhando para a
definição de interoperabilidade da ISO (International Organizations of Standardization) é
possível identificar três pontos que se correlacionam com as três principais diferenças
identificadas.
As diferenças de Hardware podem ser significantes, mas dificilmente causam
problemas de interoperabilidade entre Software, pois a única capacidade que poderiam
afectar era a de comunicação. No entanto, hoje em dia os standards de comunicação
estão tão bem implementados pelo que é difícil existirem problemas ao nível de
transporte de informação entre duas maquinas diferentes. Tomando por exemplo a
transferência de ficheiros entre um computador de secretária e um telemóvel pode-se
verificar que existem várias formas de como está pode ser feita, ligação directa através
de cabo próprio, USB (Universal Serial Bus) ou semelhante, infravermelhos, Bluetooth,
ou em última instância por HTTP através de GSM, GPRS ou UMTS. É tudo uma
questão de existirem os adaptadores correctos e de estarem bem configurados.
As diferenças ao nível dos sistemas operativos também podem causar
problemas de comunicação, como por exemplo se os dados estão em formato big
endian ou little endian, mas tipicamente essas questões já estão previstas e resolvidas
pelos próprios sistemas operativos. Os maiores problemas de interoperabilidade surgem
na capacidade de execução de programas, pois estes normalmente dependem de
componentes de sistema operativo, no entanto este problema pode ser ultrapassado
utilizando linguagens de programação que são compiladas para linguagens intermédias
que são executadas sobre máquinas virtuais, como por exemplo a plataforma Java ou
.Net. Ao nível da transferência de dados podem também surgir alguns problemas como
diferenças entre significados de caracteres.
As principais diferenças encontram-se ao nível das aplicações, pois estas podem
estar programadas em linguagens diferentes o que pode gerar problemas de
comunicação e de transferência de dados. As linguagens de programação mais
recentes dispõem de formas de interacção para aplicações distribuídas, como por
exemplo o Java RMI e o .Net Remoting, no entanto estas só podem ser utilizadas para
comunicar com aplicações na mesma linguagem. A transferência de dados fica
comprometida a partir do momento em que nem todos os tipos de dados existem em
todas as linguagens, ou no caso das linguagens orientadas a objectos em que os
- 30 -
objectos existentes numa linguagem dificilmente tem correspondência noutras
linguagens.
Hoje em dia o cerne para a resolução do problema da interoperabilidade entre
Software encontra-se nas diferenças entre as próprias aplicações e os dados que
utilizam. Para resolver este problema é possível considerar três tipos de soluções:
Message-Oriented Middleware (MOM),
pontes entre aplicações e
Web Services.
"
O Message-Oriented Middleware (MOM) é muitas vezes uma resposta madura e
aplicável para os desafios de interoperabilidade, pois as soluções que fazem uso de um
hub central de mensagens fazem mais sentido em grande parte dos casos [Tim Mallalieu
2004]. Isto é especialmente verdade quando os requisitos envolvem flexibilidade nas
relações entre Software fornecedor e consumidor e fiabilidade das mensagens. O MOM
fornece um meio baseado em troca de mensagens assíncronas que facilita a integração
de aplicações mantendo um estado de Loose Coupling [Korhonen 1997], as mensagens
são depositadas numa fila e depois são reenviadas para o destinatário num processo
habitualmente intitulado de Message Queueing. Infra-estruturas do tipo MOM podem
fornecer alta performance, fiabilidade e tecido para a interoperação dentro de sistemas
heterogéneos.
Figura 12: Message-Oriented Middleware.
Contudo, estes sistemas não resolvem adequadamente a interacção para além
das infra-estruturas do sistema. Ou seja as estruturas MOM funcionam melhor dentro do
sistema onde existe uma ambiente controlado. Quando se tenta interoperar com outros
sistemas os problemas voltam a aparecer, pois diferentes estruturas MOM utilizam
protocolos e arquitecturas diferentes e requerem configurações de firewalls diferentes.
- 31 -
Tendo em conta que se irá discutir a interoperabilidade baseada em Web
Services mais a frente neste documento, é necessário referir que numa arquitectura
orientada a serviços uma solução a considerar é a utilização de Web Services como
Message-Oriented Middleware, integrando assim o melhor de dois mundos e obtendo
uma framework de interoperabilidade ubíqua bem como uma boa infra-estrutura para
troca de mensagens assíncronas.
"
.
)
As pontes aplicacionais são uma solução a ter em conta quando o sistema exige
performance em vez de flexibilidade. A utilização de pontes directas entre Software é
realmente uma boa opção em termos de performance mas compromete seriamente a
extensibilidade e capacidade de manutenção do sistema. Tendo em vista uma
arquitectura orientada a serviços as pontes directas entre aplicações impossibilitam a
obtenção de Loose Coupling, logo não são uma boa solução.
"
A tecnologia Web Services tem como principal característica de interoperabilidade
a utilização de interfaces para esconder a implementação dos serviços. Tais interfaces
são definidas através de WSDL (Web Service Description Language) e regulam a forma
como o serviço é acedido. O facto é que a partir do momento em que o serviço está
escondido por uma interface não interessa em que plataforma está a correr ou em que
linguagem foi desenvolvido. Hoje em dia existem uma sério de pacotes de
desenvolvimento de Software que permitem a criação e o acesso a Web Services, em
qualquer linguagem e sobre qualquer plataforma, de uma forma simples. A tarefa de
interligar aplicações diferentes perde assim muitas dependências artificiais, estando-se
mais perto da obtenção de Loose Coupling.
Os Web Services têm sido aclamados como um meio forte de capacitar a
interoperabilidade dos sistemas, pois suportam a integração de sistemas e a partilha de
dados e recursos, tanto dentro como fora das organizações. O problema é que os Web
Services são uma tecnologia relativamente nova e que se baseia em vários standards
diferentes, que por sua vez estão em constante desenvolvimento e redefinição.
Até a data, o desenvolvimento de muitos dos standards direccionados para a
Web está a cargo do World Wide Web Consortium (W3C), incluindo os standards XML,
WSDL e SOAP. No entanto, para responder às necessidades de desenvolvimento e
promoção da interoperabilidade, foi criada uma nova organização: a Web Services
Interoperability Organization (WS-I). A WS-I é um consórcio focado exclusivamente na
interoperabilidade dos Web Services. Para que a promessa de interoperabilidade dos
Web Services se concretize é necessário que os standards subjacentes sejam geridos
de uma forma cuidadosa. O WS-I serve como integrador de standards e promotor da
interoperabilidade definindo guias de interpretação e implementação dos standards, por
forma a facilitar a adopção dos Web Services.
- 32 -
4.3.1. Web Services Interoperability Organization
"The Web Services Interoperability Organization is an open industry effort
chartered to promote Web services interoperability across platforms, applications, and
programming languages. The organization brings together a diverse community of Web
services leaders to respond to customer needs by providing guidance, recommended
practices, and supporting resources for developing interoperable Web services." – About
WS-I, WS-I overview
A WS-I é um consórcio composto por cerca de 150 organizações que
representam vários interesses, tais como telecomunicações, media, finanças, governos,
viagens, seguros, bens de consumo e tecnologias de informação [David Ehnebuske 2003].
E cujos objectivos passam por:
Promover a interoperabilidade dos Web Services através de diferentes
plataformas, sistemas operativos e linguagens de programação e o uso de
protocolos para a troca de mensagens interoperáveis entre serviços;
Encorajar a adopção dos Web Services;
Acelerar a implementação fornecendo guias, boas práticas e outros recursos
para o desenvolvimento de Web Services interoperáveis.
Como um integrador de standards a WS-I serve como intermediário entre as
organizações que fornecem os standards e a indústria, outras organizações e os
utilizadores finais.
Figura 13: Relações entre o WS-I e as organizações
- 33 -
O trabalho desenvolvido pela WS-I em conjunto com as outras organizações deu
origem a uma série de recursos para ajudar ao desenvolvimento e a implementação dos
Web Services, incluindo a especificação de um perfil (profile) de Web Services
interoperáveis. Para a WS-I um perfil é uma colecção de requisitos para suportar a
interoperabilidade. Os recursos disponibilizados são os seguintes:
Especificações de perfil – estas incluem uma lista de especificações, não
proprietárias, relacionadas com a tecnologia Web Services, numa
determinada versão, e uma lista de clarificações e restrições sobre elas, por
modo a simplificar o desenvolvimento de Web Services interoperáveis;
Casos e cenários de utilização – estes capturam requisitos técnicos e de
negócio para a utilização de Web Services, os quais reflectem classes de
requisitos reais suportando soluções baseadas em Web Services, e
fornecem um meio para demonstrar as guias descritas nos perfis;
Aplicações de demonstração – estas demonstram a implementação de
aplicações construídas com base nos cenários e que estão em conformidade
com os perfis definidos, estando desenvolvidas para múltiplas plataformas e
em diferentes linguagens e ferramentas de desenvolvimento permitem
demonstrar a interoperabilidade em acção;
Ferramentas de testes – tais ferramentas são utilizadas para monitorizar e
analisar as interacções feitas através de Web Services para determinar se
estas estão em conformidade com as guias especificadas nos perfis.
Hoje em dia é possível descarregar da Internet várias implementações das
especificações da WS-I, incluindo o Web Services Enhancements (WSE) da Microsoft e
o Web Services Toolkit (WSTK) da IBM. Estes pacotes estendem as implementações
básicas de Web Services dos seus fornecedores por forma a incorporar as extensões e
restrições criadas pelas especificações da WS-I.
4.3.2. WS-I Basic Profile
A 22 de Julho de 2003 a direcção e os membros da WS-I aprovaram por
unanimidade a publicação do primeiro perfil de Web Services Interoperáveis intitulado
WS-I Basic Profile 1.0. Este perfil foca as tecnologias de fundo em que os Web Services
se baseiam: HTTP, SOAP, WSDL, UDDI (Universal Description, Discovery, and
Integration), XML e XML Schema.
A especificação de perfil do WS-I Basic Profile 1.0 [Keith Ballinger 2004] consiste
das seguintes especificações não proprietárias relacionadas com Web Services:
SOAP 1.1
WSDL 1.1
UDDI 2.0
XML 1.0 (Second Edition)
XML Schema Part 1: Structures
XML Schema Part 2: Datatypes
- 34 -
RFC2246: The Transport Layer Security Protocol Version 1.0
RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
RFC2616: HyperText Transfer Protocol 1.1
RFC2818: HTTP over TLS
RFC2965: HTTP State Management Mechanism
The Secure Sockets Layer Protocol Version 3.0
Foram criados três cenários para o WS-I Basic Profile 1.0, onde cada cenário é
um padrão de desenho arquitectural para interacção entre actores, papeis e troca de
mensagens.
One-way Usage Scenario – é o cenário de utilização mais simples, onde a
troca de mensagens apenas tem um sentido, sendo que é o consumidor a
enviar pedidos ao fornecedor. Este cenário só deve ser utilizado quando a
perda de informação é tolerável.
Synchronous request/response Usage Scenario – este é o cenário mais
comum onde o consumidor envia um pedido ao fornecedor que o processa e
envia de volta uma resposta.
Basic callback Usage Scenario – este cenário é utilizado para simular
operações assíncronas utilizando operações síncronas. É composto por dois
cenários de pedidos e respostas síncronas, um iniciado pelo consumidor e
outro iniciado por um fornecedor.
Foi fornecido também um mapeamento entre os cenários e as clarificações e
restrições especificadas no perfil. À data foi também disponibilizada uma aplicação para
exemplificar a implementação do perfil, intitulada Supply Chain Management Sample
Application.
A WS-I publicou no dia 24 de Agosto de 2004 a especificação final da versão 1.1
[Christopher Ferris 2004] do Basic Profile que se baseia na versão 1.0 e incorpora as
erratas existentes. Esta versão separa os requisitos referentes a serialização dos
envelopes SOAP e a sua representação em mensagens para outro perfil intitulado
Simple SOAP Binding Profile 1.0. Esta separação foi feita tendo em vista a capacidade
de integração do Basic Profile 1.1 com qualquer perfil que especifique a serialização de
envelopes, como por exemplo o Attachments Profile 1.0. Estar em conformidade com o
Basic Profile 1.0 e com as correcções feitas através das erratas é aproximadamente
igual a estar em conformidade com o Basic Profile 1.1 e o Simple SOAP Binding Profile
1.0.
""
)
“Service-oriented architectures (SOAs) based on Web service standards have
emerged as the leading industry wide enabler for interoperability.” – Roger Sessions,
Interoperability Through Service-Oriented Architectures (SOAs)
Antes das arquitecturas orientadas a objectos a interoperabilidade entre
aplicações era conseguida recorrendo a ligações directas entre aplicações ou à
- 35 -
utilização de um MOM. As ligações directas entre aplicações fazem com que os
sistemas se preencham com ligações ad-hoc que se tornam difíceis de manter e
impossibilitam a obtenção de Loose Coupling. Os sistemas equipados como MOM
atingem facilmente um estado de interoperabilidade dentro do sistema mas falham
quando é necessário interligar sistemas.
A aproximação de uma SOA à interoperabilidade entre aplicações é construir
uma infra-estrutura à qual todos os sistemas se ligam por forma a interoperarem. Assim
sendo cada aplicação requer apenas uma ligação, tornando-se simples adicionar novas
aplicações ao sistemas.
Figura 14: Interoperabilidade numa SOA [Sessions 2004].
As arquitecturas orientadas a serviços têm como premissa a interoperabilidade e
são uma aproximação para desenvolver sistemas de Software novos e envolver os
sistemas antigos de uma forma em que estes possam trabalhar em conjunto. A
utilização de Web Services numa SOA parece ser a escolha mais lógica para garantir o
maior nível de interoperabilidade, tanto interna como externamente ao sistema.
4.4.1. A interoperabilidade ao nível de negócio
As arquitecturas orientadas a serviços devem também ser vistas como uma
catalisador para interoperabilidade ao nível de negócio, ou seja, para a
interoperabilidade entre empresas (ou entre departamentos de uma empresa). Desta
forma a interoperabilidade torna-se na capacidade de prestar serviços ou de coordenar
operações de uma forma automatizada.
- 36 -
Hoje em dia, as empresa procuram cada vez mais as parcerias e a delegação de
tarefas como meio de suprimir a sua falta de conhecimento ou experiência em
determinadas áreas. Estas decisões são tomadas ao mais alto nível de devem sempre
produzir resultados rapidamente, daí a importância de existir uma estrutura flexível e
capaz de se adaptar rapidamente. As arquitecturas orientadas a serviços baseadas em
Web Services fornecem essa flexibilidade. Pois permitem que a alto nível sejam
definidos os processos críticos de negócio e que as alterações produzidas digam
apenas respeito à integração de novos serviços ou a alterações nas agregações de
serviços básicos de negócio.
Figura 15: Reorganização dos processos de negócio [Lawrence Wilkes 2004].
Este conceito pode ser verificado considerando o exemplo que se segue. A
empresa A é uma empresa de transporte de bens e mercadorias que se orgulha de
estar na vanguarda da tecnologia. O negócio desta empresa é suportado por uma frota
de veículos de transporte pesados e ligeiros. Todos os veículos dispõem de um
dispositivo de localização global (GPS) com a capacidade de apresentar rotas e
periodicamente informam o sistema da sua localização. A empresas freta os seus
serviços tanto a outras empresas como a particulares, para esse efeito dispõe de uma
página de Internet e de um Web Service que permitem a efectuar reservas. Para
suportar as suas necessidades de Software a empresa dispõe de uma arquitectura
orientada a serviços. Analisando o processo de negócio segundo o qual é afectada uma
tarefa de transporte a uma equipa de entregas, tem-se que o sistema consulta o serviço
de equipas que indica quais são as equipas livres. De seguida consulta o sistema de
localização para descobrir qual é a equipa que está mais próxima da local de partida. O
passo seguinte é notificar a equipa via SMS através de um serviço notificações que está
ligado a uma central GSM da empresa. Por último, os pontos de partida e de destino
são enviados para o GPS para que seja calculada a rota e o serviço de equipas é
notificado de que a equipa já num se encontra livre.
- 37 -
Figura 16: Processo de negócio desencadeado por uma entrega.
No entanto surgiu a oportunidade de efectuar uma parceria com uma operadora
de telecomunicações móveis B que envolve o envio gratuito de SMS para a mesma
rede através de um Web Service da operadora. Como a parceria era vantajosa em
termos financeiros a direcção decidiu aprovar o negócio, desta forma era necessário
proceder a alterações no sistema. O departamento de informática da empresa A, uma
vez que teve acesso as especificações do serviço de SMS da empresa B, rapidamente
desenvolveu e testou uma nova versão do serviço de notificações. Esta nova versão
em vez de utilizar o módulo de GSM para enviar as mensagens escritas utilizava o
serviço disponibilizado pela empresa B. O serviço de notificações foi então substituído
pela nova versão sem que existissem mais repercussões no sistema, tendo todos os
processos de negócio ficado a funcionar exactamente como dantes, inclusive o
processo de entregas.
Outro problema que a empresa enfrentava era que os seus clientes desejavam
saber em tempo real onde se encontravam as suas cargas. A ideia da direcção era
recorrendo ao serviço de localização dispor essa informação aos clientes na sua página
de Internet. No entanto o departamento de informática alertou a direcção para o facto de
que não existia na empresa informação cartográfica que pudesse ser utilizada para
apresentar a localização dos veículos na página. Assim sendo a direcção procurou no
mercado por soluções para o problema e encontrou três diferentes. Comprar a
cartografia e implementar um sistema de gerar imagens para apresentar na página.
Comprar um Sistema de Informação geográfica (SIG) e integra-lo no sistema. Ou
contratar o serviço a uma empresa que disponha de um SIG. Das três soluções a
menos dispendiosa e de implementação mais rápida é a terceira. Desta forma a
empresa A contratou o serviço a uma empresa C que mediante as coordenadas e mais
algumas variáveis de configuração devolve uma imagem pronta a utilizar no site. Este
serviço externo quando agregado com os serviços internos de equipas e localização
permite a empresa disponibilizar um serviço de localização de cargas aos seus clientes.
O facto das arquitecturas orientadas a serviços potenciarem a interoperabilidade
ao nível dos negócios (o business-to-business) é talvez um dos principais motivos por
de trás do sucesso deste tipo de arquitecturas.
- 38 -
$ #
No mercado empresarial é cada vez mais importante fornecer produtos de
qualidade, o que leva à especialização das empresas. Por sua vez a especialização das
empresas obriga à cooperação entre elas para que sejam criados novos produtos. É
aqui que as arquitecturas orientadas a serviços podem fazer a diferença pois fornecem
a flexibilidade e a agilidade necessárias para que exista interoperabilidade efectiva entre
as empresas. A criação de ligações business-to-business é essencial para que as
empresas prosperem e as SOAs baseadas em Web Services potenciam a criação de
ligações simples e automatizadas, tornando-se assim num meio por excelência para a
interacção entre organizações.
As arquitecturas orientadas a serviços têm como base principal a
interoperabilidade entre componentes de Software e os Web Services são vistos como o
meio preferencial para a obter. Os Web Services levam à interoperabilidade porque
escondem a implementação dos serviços por trás de interfaces, deixando então de ter
qualquer importância em que linguagem está implementado o serviço ou em que
plataforma está a correr.
Outra perspectiva de futuro trazida pelas SOAs é que com o desenvolvimento de
standards todas as aplicações de um determinado tipo respeitarão uma determinada
interface, tornado-se assim possível trocar de fornecedor de aplicações sem que seja
necessário fazer alterações no sistema. Por outro lado com o aumento do número de
serviços disponíveis, tanto dentro como fora das empresas, a construção de aplicações
e a modelação de processos de negócio tornar-se-a em pouco mais do que a
agregação de serviços existentes.
Hoje em dia já muitas empresas optaram por reformular os seus sistemas
implementado arquitecturas orientadas a serviços e estão a tirar grandes benefícios da
sua utilização. Alguns benefícios, como a capacidade de interoperar com outros
sistemas, eram esperados mas outros, como por exemplo o aumento da fiabilidade, são
uma surpresa agradável.
Tendo em conta que relação entre custos e benefícios é tão boa, é bastante
provável que as arquitecturas orientadas a serviços estejam aqui para ficar.
- 39 -
)
-
) /
)
0% 1
Os documentos XML são um conjunto de informação subdividida por etiquetas
(tags) [Bradley 1998]. Ao conjunto composto por uma etiqueta de início, a etiqueta de fim
correspondente e a informação contida entre elas dá-se o nome de elemento (Element).
Uma etiqueta pode ainda conter parâmetros, os quais se chamam atributos (Attributes).
Ao elemento que envolve todo o documento chama-se raiz ou documento.
A primeira linha do documento é necessariamente a instrução de processamento
(<? ... ?>) que indica ao parser quais as condições de processamento. É obrigatório
declarar qual a versão do XML que se está a utilizar (version), pode-se também indicar
qual a codificação de caracteres utilizada (encoding) e se o documento é dependente
de outros documentos ou não (standalone).
Exemplo 1: Cabeçalho XML.
De seguida podem surgir instruções para o processador dentro de declarações.
Instruções válidas são a definição de entidades, comentários e secções de caracteres
(CDATA). Uma entidade é como que um “alias” para um ou mais caracteres e são
invocadas colocando um ‘&’ antes do nome e um ‘;’ depois, por exemplo ‘&autor;’. Um
comentário funciona como auxiliar à compreensão do documento e não será
processado. Uma secção de caracteres indica um porção de texto que não contém
código de marcação (Markup) logo pode conter caracteres tais como o menor (‘<’), não
sendo considerado que estes tenham qualquer valor especial.
!
"#$%&'(
)
!
(*% %&
+,
!
(*% %&
-- .-/0
1
!
2
2$
2
2
)$"3%3)
4
1
1
Exemplo 2: Instruções para o processador de XML.
Por fim, a árvore de elementos que contém a informação. Quanto a esta parte do
documento é necessário realçar alguns pontos.
1. O XML é sensível às maiúsculas e minúsculas (case-sensitive), logo uma
etiqueta <a> é diferente de uma etiqueta <A>.
2. Um elemento pode ser vazio, sendo então definido por uma única etiqueta
cujo penúltimo caracter é uma barra ‘/’, ou seja que respeite o seguinte tipo:
<Nome Atributo="Valor"/>. No entanto um elemento que não seja vazio tem
que estar limitado por duas etiquetas.
- 40 -
3. As etiquetas têm de estar equilibradas, ou seja a última etiqueta aberta tem
de ser a primeira a ser fechada, por exemplo: <a><b> ... </b></a> e nunca
<a><b> ... </a></b>.
4. Os valores dos atributos têm sempre de estar entre aspas, por exemplo:
<pessoa bi="12039">.
(
9
567 8
:8
9
:8
, ;
, ;
, ;
8
8
8
, ;
, ;
, ;
8
9
:8
8
Exemplo 3: Árvore de elementos.
)
Com o aparecimento e generalização do XML (eXtensible Markup Language)
tornou-se relativamente mais fácil implementar sistemas que embora correndo em
ambiente diferentes, possam trocar informação de uma forma transparente. Ou seja
sem que qualquer uma das partes necessite de conhecer as necessidades da outra,
nomeadamente em termos de formato dos dados. De facto a universalidade do XML
torna-o num meio bastante atraente para trocar informação entre diferentes programas
[Haas 2004]. Desta forma os programas podem ser desenvolvidos para qualquer sistema
e em qualquer linguagem, e mesmo assim comunicarem entre si tirando partido da
interoperabilidade do XML.
A combinação entre as tecnologias XML, XML Namespaces, e XML Schemas,
forma uma ferramenta capaz de lidar com os problemas associados aos ambientes
distribuídos. É dentro desta perspectiva de interoperabilidade que surgem os Web
Services.
A.2.1. Definição
Segundo a definição do W3C um Web Service é um sistema de Software
identificado por um URI (Uniform Resource Identifier) cujos interfaces públicos e
ligações estão definidos e descritos em XML. A sua definição pode ser descoberta por
outros sistemas de Software, que podem então interagir com o Web Service segundo as
regras pre-estabelecidas, utilizando mensagens XML enviadas sobre protocolos de
Internet [Allen Brown 2004]. Por outras palavras um Web Service é um interface para uma
funcionalidade de uma aplicação que está disponível através da rede e que foi
construído utilizando protocolos standard da Internet [James Snell 2002].
- 41 -
A.2.2. Stack Web Service
Figura 17: Stack Web Services
Discovery é a camada que fornece os mecanismos para os clientes
descobrirem as definições dos servidores. O UDDI (Universal Description, Discovery,
and Integration) é o actualmente o meio standard para a descoberta de Web Services e
baseia-se numa cadeia de servidores interligados que fornecem um directório global.
Description contém as definições do servidor, mediante as decisões tomadas
em cada um dos níveis seguintes quanto aos protocolos que são suportados. A
linguagem utilizada de forma mais comum para descrever um Web Service é o WSDL
(Web Service Description Language).
Packaging é o processo pelo qual se prepara a mensagem para poder ser
compreendida pelo receptor, sem que existam problemas com os tipos de dados
envolvidos na transacção. O SOAP (Simple Object Access Protocol) é o formato de
pacotes mais utilizado.
Transport é a camada que trata da comunicação entre as aplicações. O seu
objectivo primário é o de mover a informação de um ponto para outro na rede. Embora
um Web Service possa ser construído sobre quase todos os protocolos de transporte
existentes, o mais utilizado é o HTTP (HyperText Transfer Protocol).
Network é a camada que se preocupa com as bases necessárias para a
comunicação. Esta camada é exactamente a mesma que podemos encontrar no modelo
TCP/IP.
A.2.3. UDDI
O UDDI é um projecto que visa encorajar a interoperabilidade e a adopção de
Web Services. Este projecto consiste num conjunto de especificações baseadas em
standards que permitem a descrição e a descoberta de um serviço [Bellwood 2001].
O UDDI pode ser visto como uma tecnologia constituída por um registro ou
directório baseado em XML, composto por vários servidores dispersos, no qual qualquer
empresa do mundo pode registrar-se como desponbilizadora de serviços na Internet. O
- 42 -
objectivo é facilitar a criação de ligações entre as empresas proporcionando um meio
para que elas se encontrem na Internet. UDDI é muitas vezes comparado com uma lista
telefónica como as Páginas Amarelas. As empresas podem listar-se por nome, produto,
localização ou por Web Services que disponibilizam.
O registro UDDI contem definições pragmáticas das empresas e dos serviços
que elas disponibilizam. Também contem referencias para especificações (intituladas
Technical Models ou tModels) que descrevem com os Web Services funcionam. As
empresa e as organizações de standards são as principais fontes de informação de
registro. Popular o registro envolve várias etapas. As empresas de Software, as
organizações de standards e os programadores povoam o registo com tModels que
descrevem especificações comuns a uma indústria ou negócio. As empresa povoam o
registo com as descrições dos serviços que suportam. O registro UDDI atribui
automaticamente um UUID (unique universal identifier) a cada tModel, registo de
negócio e de empresa. Depois as empresas podem interrogar o registo para descobrir
serviços prestados por outras empresas. Este processo pode ser dinâmico, por forma a
pesquisa e a descoberta se adaptarem automaticamente a disponibilidade dos serviços.
A Microsoft, a IBM e a Ariba estiveram cabeça do projecto na sua criação, mas
hoje em dia a organização é composta por mais de 200 empresa. Entre elas grandes
fornecedores de Software e empresas lideres no comercio electrónico [Sleeper 2002]. O
UDDI está actualmente na sua versão 3 que visa suportar em grande escala interacção
entre implementações de Web Services privadas e publicas.
A.2.4. WSDL
O WSDL é o standard de facto, usado para tornar os Web Services autodescritivos. Ele é utilizado para descrever tudo acerca de um Web Service,
nomeadamente o que é que faz, como o faz e como se pode usa-lo [Cerami 2002].
A.2.4.1. Exemplo
Um ficheiro WSDL [Erik Christensen 2001], sendo um ficheiro XML, começa com o
cabeçalho XML e de seguida tem o elemento raiz intitulado <definitions> onde se
encontram declarados os namespaces necessários. O corpo do ficheiro por norma
segue a estrutura: tipos de dados, mensagens, interfaces e serviços.
<
= ;
(
, *
> =
8
8
=
> =
8
8
<<<
<
=
> =
8
8 >
=
> =
8
8 >
=
<
> =
8
8 >
!
22 %
22
!
22 6
,
22
!
22
;
22
!
22
22
8
< = ;
>
<
2 ;
2 ;
8
(
<
2 ;
8
(
,8
< 8
8
,8
< 8
Exemplo 4: A etiqueta defenitions no ficheiro WSDL.
- 43 -
><
>
Dentro da etiqueta <types> são encapsuladas as definições dos tipos de dados
que podem ser utilizados durante a comunicação. Para este efeito são usadas as
etiquetas do XML Schema namespace. Em alguns casos esta parte do corpo do WSDL
pode ser omitida desde que os tipos utilizados sejam tipos padrão.
!22 %
< =?
= >
=
=
8
8
8
8 =
8
< =?
22
, *
> =
8
8
> =
8
8
<<< <@ ,8 ---8
567 >
A (
,B
=
%?
= C
=
;
=
?
8 = C
8 =
%?
=
=
A (
,B
D
=
%?
=
=
,B
8 =
8 =
%?
=
=
A (
,B
E
=
%?
=
=
6
,
8 =
8 =
%?
=
>
<
2 ;
?
,8
,8
?
,8
?
,8
Exemplo 5: Definição dos tipos de dados num ficheiro WSDL.
Através da etiqueta <message> vão ser definidas as mensagens que podem ser
trocadas entre os clientes e o Web Service. Neste caso são definidas duas mensagens,
uma para o pedido e outra para a resposta.
<
=
,
< =
8
< =
,
< =
,
< =
8
< =
,
A (
?
,B
A (
?
,B
DC
=
A (
,B
D
=
A (
,B
Exemplo 6: Definição das mensagens num ficheiro WSDL.
- 44 -
8
D
8
Os interfaces especificam como os métodos se traduzem em mensagens.
Basicamente é definido que mensagens de input é que vão ser recebidas e que
mensagens de output ou erro é que vão ser geradas.
<
8<
=
<
%?
=
< =
< =
< =;
8< =
=
%?
A (
,B
' %?
A (
,B
,
=A (
,B
,
=A (
,B
,
=A (
,B
DC
D
E
8
8
8
Exemplo 7: Definição das operações num ficheiro WSDL.
Esta parte do WSDL descreve a implementação do Web Service. é a etiqueta
<binding> que faz a ligação entre o interface e os protocolo de rede e mensagens a
utilizar. A etiqueta <service> tem como objectivo detalhar a localização do serviço na
rede.
< =
?
8<
<
,
(
>
B
,
=A (
,B
' %?
=
, ?
> =88 >
,8
8>
8
< =
A (
,B
=
3
> =88<<<
<
2 ;
8(
< =
=
?
8
8< =
< =
=
?
8
8< =
< =;
=
?
8
8< =;
8< =
=
,
=
<
(
=
<
8< =
< =
>
,2 ;
(
A (
,
>8
=(
,B
>
'
B
,
=
>
8<
8<
=
=88<<<
<
2 ;
8(
>8
=
Exemplo 8: Definição dos protocolos de rede aceites e da localização do serviço num ficheiro WSDL.
- 45 -
A.2.5. SOAP
O SOAP é um protocolo para troca de informação dentro de ambientes
distribuídos. é baseado em XML e consiste de três partes: um envelope que define uma
estrutura para descrever o que está numa mensagem e como a processar; um conjunto
de regras de codificação para descrever instancias de tipos de dados definidos na
aplicação; e uma convenção para representar as chamadas a procedimentos remotos e
as respectivas respostas. O SOAP pode potencialmente ser utilizado sobre uma
variedade de protocolos de transporte, por norma é utilizado sobre HTTP [Don Box 2000].
A.2.5.1. Envelope
O envelope SOAP é a mensagem que de facto é trocada entre o cliente e o Web
Service. Para além do envelope em si, a mensagem pode conter cabeçalhos adicionais,
e contém o corpo. Analisando cada um destes elementos têm-se que: o envelope é a
raiz do documento XML que representa a mensagem; os cabeçalhos adicionais são um
mecanismo genérico para adicionar características as mensagens, sem que seja
necessário o acordo prévio entre as partes envolvidas; por último o corpo é o contentor
da informação destinada ao receptor.
#3'2(*F=
(
= #3'2(*F > =
8
8 >
#3'2(*F=
, ?
> =
8
8 >
#3'2(*F=
B ?
=
A (
,B
=
> =
8
8
;
G. 8
;
E
8
8 =
A (
,B
8 #3'2(*F=
B ?
8 #3'2(*F=
(
,8
<
8
,8
8
8
,8
8
8
,8
2 ;
Exemplo 9: Envelope SOAP de pedido.
#3'2(*F=
(
= #3'2(*F > =
8
8 >
,8
8
#3'2(*F=
, ?
> =
8
8 >
,8
#3'2(*F=
B ?
=
A (
,B
D
=
> =
8
8
<
2 ;
,B
$> ( ,
8
8 =
A (
,B
D
8 #3'2(*F=
B ?
8 #3'2(*F=
(
Exemplo 10: Envelope SOAP de resposta.
- 46 -
,B
2
!
Allen Brown, Hugo Haas (2004, Fevereiro). Web Services Glossary.
http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/.
Amazon Web Sevice.
http://www.amazon.com/gp/browse.html/104-1671910-7327941?node=3435361.
Azevedo, Douglas José Peixoto de (1997, Junho). Bate Byte n.º 65 - Evolução de
Software
Barry, Douglas K. (2003). Web Services and Service-Oriented Architectures: The Savvy
Manager'
s Guide. Barry & Associates
Bellwood, Thomas A. (2001). UDDI - A Foundation for Web Services.
http://www.idealliance.org/papers/xml2001/papers/html/03-02-03.html.
Bradley, N. (1998). The XML Companion. Addison-Wesley.
Cerami, Ethan (2002, Fevereiro). Web Services Essentials. O’Reilly.
Christopher Ferris, Keith Ballinger, David Ehnebuske, Martin Gudgin, Canyang Kevin
Liu, Mark Nottingham, Prasad Yendluri (2004, Agosto). WS-I Basic Profile Version
1.1. http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html.
Colan, Mark (2004, Abril) Service-Oriented Architecture expands the vision of Web
services, Part 1. http://www-106.ibm.com/developerworks/library/ws-soaintro.html.
David Ehnebuske, Christopher Ferris, Tom Glover, Christopher Kurt, Tony Roby, Robert
Sutor (2003, Janeiro). WS-I Overview.
http://www.ws-i.org/docs/20030115.wsi.introduction.pdf.
Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah Mendelsohn,
Henrik Frystyk Nielsen, Satish Thatte, Dave Winer (2000, Maio). Simple Object
Access Protocol (SOAP) 1.1.
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.
EDI History. http://e.d.i.tripod.com/edi_history.htm.
Eisenberg, Robert (2004, Abril). Service-Oriented Architecture: The Future Is Now.
http://www.informationweek.bizintelligencepipeline.com/howto/showArticle.jhtml?
articleId=18902587.
Erik Christensen, Francisco Curbera, Greg Meredith, Sanjiva Weerawarana (2001,
Março). Web Services Description Language (WSDL) 1.1.
http://www.w3.org/TR/2001/NOTE-wsdl-20010315.
- 47 -
Fallside, D. C. (2001, Maio). XML Schema Part 0: Primer.
http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/.
Framingham, John F. (2003, Setembro). Resurrecting the distributed app model.
http://www.computerworld.co.nz/.
Google Profile. http://www.google.com/profile.html.
Google Web APIs. http://www.google.com/apis/.
Haas, Hugo (2004, Abril). Web Services Activity Statement.
http://www.w3.org/2002/ws/Activity.
He, Hao (2003, Setembro). What is Service-Oriented Architecture?
http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html.
Irek, Chip (2003, Dezembro). Realizing a Service-Oriented Architecture with .NET.
http://www.15seconds.com/issue/031215.htm.
James Snell, Doug Tidwell e Pavel Kulchenko (2002, Janeiro). Programming Web
Services with SOAP (1ed.). O’Reilly.
Keith Ballinger, David Ehnebuske, Martin Gudgin, Mark Nottingham, Prasad Yendluri
(2004, Abril). WS-I Basic Profile Version 1.0.
http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html.
Kishore Channabasavaiah, Kerrie Holley, Edward M. Tuggle, Jr. (2003, Dezembro).
Migrating to a service-oriented architecture, Part 1.
http://www-106.ibm.com/developerworks/webservices/library/ws-migratesoa/.
Koch, Christopher (2002, Março). The ABCs of ERP.
http://www.cio.com/research/erp/edit/erpbasics.html.
Korhonen, Markku (1997). Message Oriented Middleware (MOM).
http://www.tml.hut.fi/Opinnot/Tik-110.551/1997/mqs.htm.
Lane, Edward (2004). SOA fundamentals and characteristics.
http://www.itweb.co.za/sections/industryinsight/java/lane040806.asp.
Lawrence Wilkes, Richard Veryard (2004, Abril). Service-Oriented Architecture:
Considerations for Agile Systems.
http://msdn.microsoft.com/library/en-us/dnmaj/html/aj2service.asp.
Mark Endrei, Jenny Ang, Ali Arsanjani, Sook Chua, Philippe Comte, Pål Krogdahl, Min
Luo e Tony Newling (2004, Abril). Patterns: Service-Oriented Architecture and
Web Services (1ed.). IBM Redbooks
Pressman, Roger S. (1995). Engenharia de software. Makron.
Robert Verzello, John Reutter (1984). Processamento de dados. McGraw-Hill.
- 48 -
Rosenbloom, Scott (2003). An Introduction to Service-Oriented Integration. WRQ White
Paper. http://www.wrq.com/products/whitepapers/0898.html.
Schneider, A. (2004). Service-Oriented Architecture Primer.
http://www.bjss.co.uk/fow/SOA Primer.pdf.
Sessions, Roger (2004, Julho). Interoperability Through Service-Oriented Architectures
(SOAs). ObjectWatch White Paper.
Sleeper, Brent (2002). The Evolution of UDDI.
http://www.uddi.org/pubs/the_evolution_of_uddi_20020719.pdf.
Tim Mallalieu, Jeromy Carriere (2004, Janeiro). Enterprise Interoperability: .NET and
J2EE. MSDN, Microsoft Corporation.
http://msdn.microsoft.com/library/en-us/dnbda/html/dotnetinteroperability.asp.
Yank, Kevin (2002, Fevereiro). Web Services Demystified.
http://www.sitepoint.com/print/web-services-demystified.
- 49 -
Exemplo 1: Cabeçalho XML.
40
Exemplo 2: Instruções para o processador de XML.
40
Exemplo 3: Árvore de elementos.
41
Exemplo 4: A etiqueta defenitions no ficheiro WSDL.
43
Exemplo 5: Definição dos tipos de dados num ficheiro WSDL.
44
Exemplo 6: Definição das mensagens num ficheiro WSDL.
44
Exemplo 7: Definição das operações num ficheiro WSDL.
45
Exemplo 8: Definição dos protocolos de rede aceites e da localização do serviço num
ficheiro WSDL.
45
Exemplo 9: Envelope SOAP de pedido.
46
Exemplo 10: Envelope SOAP de resposta.
46
- 50 -
3
Figura 1: Evolução do Software dividida em eras.
5
Figura 2: Sistema constituído por aplicações isoladas.
9
Figura 3: Sistema com partilha de dados através de uma base de dados central.
10
Figura 4: Sistema integrados.
11
Figura 5: Interacção entre sistemas diferentes.
11
Figura 6: Arquitectura orientada a serviços.
12
Figura 7: Arquitectura de Middleware básica.
16
Figura 8: Interoperabilidade entre Web Services e CORBA ou DCOM.
18
Figura 9: Agregação de serviços [Lawrence Wilkes 2004].
19
Figura 10: Relações entre as zonas.
23
Figura 11: Arquitectura da Avista
28
Figura 12: Message-Oriented Middleware.
31
Figura 13: Relações entre o WS-I e as organizações
33
Figura 14: Interoperabilidade numa SOA [Sessions 2004].
36
Figura 15: Reorganização dos processos de negócio [Lawrence Wilkes 2004].
37
Figura 16: Processo de negócio desencadeado por uma entrega.
38
Figura 17: Stack Web Services
42
- 51 -