Soa RM CSBR PDF

soa-rm-csbr 19 de Julho de 2006
Copyright OASIS Open 2005-2006. All Rights Reserved.

_______________________________________________________________________________

Modelo de Referncia para Arquitetura
Orientada a Servio 1.0
Comit de Especificao 1, 19 de Julho de 2006
Identificao do documento:
soa-rm-csbr
Identificao do documento original:
soa-rm-cs
Localizao:
http://www.pcs.usp.br/~pcs5002/oasis/soa-
rm-csbr.pdf
Localizao do documento original:
http://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=soa-rm

This translated document is provided by Jsus Franco Bueno, Pedro Luiz Pizzigatti Correa, Alberto
Yoshinobu Onoe, Beatriz Terezinha Borsoi, Augusto Takahiro Kiramoto/Polytechnic School of So
Paulo University - Brazil as an informational service to the global community. This is an unofficial,
nonnormative translation of the official document, OASIS Reference Model for Service Oriented
Architecture, located at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm,
copyright OASIS 19 July 2006. This translation is published with acknowledgement of and in agreement
with terms specified in the OASIS Translation Policy. Neither OASIS nor Jsus Franco Bueno, Pedro
Luiz Pizzigatti Correa, Alberto Yoshinobu Onoe, Beatriz Terezinha Borsoi, Augusto Takahiro
Kiramoto/Polytechnic School of So Paulo University - Brazil assume responsibility for any errors
contained herein.

A traduo deste documento oferecida por Jsus Franco Bueno, Pedro Luiz Pizzigatti Correa, Alberto
Yoshinobu Onoe, Beatriz Terezinha Borsoi, Augusto Takahiro Kiramoto/Escola Politcnica da
Universidade de So Paulo Brasil como um servio de informaes pra a comunidade global. Esta
uma traduo no oficial, no normativa do documento, OASIS Modelo de Referncia para a
Arquitetura Orientada a Servio, localizada em http://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=soa-rm, copyright OASIS 19 de Julho de 2006. Esta
traduo publicada com o conhecimento e de acordo com os termos especificados no documento
OASIS Polticas de Traduo. Nem OASIS nem Jsus Franco Bueno, Pedro Luiz Pizzigatti Correa,
Alberto Yoshinobu Onoe, Beatriz Terezinha Borsoi, Augusto Takahiro Kiramoto/Escola Politcnica da
Universidade de So Paulo Brasil assumem a responsabilidade por qualquer erro contido neste
documento.

Copyright OASIS Open 2005-2006. All Rights Reserved. Pgina 1 de 33

_______________________________________________________________________________

Modelo de referncia para Arquitetura
Orientada a Servio 1.0
Comit de Especificao 1, 19 de Julho de 2006
Identificao do documento:
soa-rm-csbr
Identificao do documento original:
soa-rm-cs
Localizao:
http://www.pcs.usp.br/~pcs5002/oasis/soa-
rm-csbr.pdf
Localizao do documento original:
http://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=soa-rm

Editores:
C. Matthew MacKenzie, Adobe Systems Incorporated, mattm@adobe.com
Ken Laskey, MITRE Corporation, klaskey@mitre.org
Francis McCabe, Fujitsu Laboratories of America Limited, frankmccabe@mac.com
Peter F Brown, peter@justbrown.net
Rebekah Metz, Booz Allen Hamilton, metz_rebekah@bah.com
Resumo:
Este Modelo de Referncia para Arquitetura Orientada a Servio um framework abstrato para
entendimento das entidades significativas e os relacionamentos entre elas em um ambiente
orientado a servio, e para o desenvolvimento de padres consistentes ou especificaes que
suportem este ambiente. baseado nos conceitos unificados do SOA e pode ser usado por
arquitetos no desenvolvimento especfico de arquiteturas orientadas a servio ou em treinamento
e exposio do SOA.
Um modelo de referncia no est diretamente amarrado a nenhum padro, tecnologia ou outro
detalhe de implementao concreta. Ele procura oferecer uma semntica comum que pode ser
usada de forma no ambgua atravs e entre implementaes diferentes. O relacionamento entre
o Modelo de Referncia e as arquiteturas e tecnologias particulares e outros aspectos do SOA
ilustrado na Figura 1.
Enquanto a orientao a servio pode ser um conceito popular encontrado em uma ampla
variedade de aplicaes, este modelo de referncia est focado no campo de arquitetura de
software. Os conceitos e relacionamentos descritos podem ser aplicados a outros ambientes de
servios; contudo, esta especificao no tenta contabilizar completamente para uso fora do
domnio de software.
Status:
Este documento atualizado periodicamente sem uma periodicidade especfica. Envie os
comentrios para o editor(s).
Os membros do Comit podem enviar comentrios sobre esta especificao para a lista
soarm@lists.oasis-open.org. Outros podem visitar a pgina principal em http://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=soa-rm, e registrar os comentrios usando os
formulrios web disponibilizados ali.
Para informao sobre quando qualquer patente tem sido publicada que pode ser essencial para
implementao desta especificao, e qualquer oferta de termos de licena de patente, por favor,
acesse a seo de Direitos de Propriedade Intelectual da pgina web SOA-RM TC em:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm.
A pgina de errata para esta especificao :
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm.

_______________________________________________________________________________
Notas
A OASIS no toma posio referente validade ou o escopo de qualquer propriedade intelectual
ou outros direitos que possam ser reclamados como referentes a uma implementao ou uso de
tecnologia descrita neste documento ou para estender a qualquer licena sobre direitos que
possam ou venham a ser disponibilizadas; tampouco no representa que tem sido feito algum
esforo para identificar quaisquer direitos. Informaes sobre os procedimentos OASIS a respeito
dos direitos das especificaes OASIS podem ser encontrados no site da OASIS. Cpias das
clusulas de direitos esto disponveis para publicao e quaisquer compromissos de licenas a
serem disponibilizadas, ou o resultado de uma tentativa feita para obter uma licena geral ou
permisso par o uso de tais direitos de propriedade por implementadores ou usurios desta
especificao, podem ser obtidas com o Diretor Executivo da OASIS.
A OASIS convida qualquer parte interessada a prestar ateno nos copyrights, patente ou
patentes de aplicaes, ou outros direitos de propriedade, que podem abranger as tecnologias que
so requeridas para implementar esta especificao. Por favor, encaminhe a informao para o
Diretor Executivo da OASIS.
Copyright OASIS Open 2005-2006. Todos os Direitos Reservados.
Este documento e as suas tradues podem ser copiados e fornecidos a outros, e trabalhos
derivados que comentem ou de outra forma expliquem ou apiem sua implementao podem ser
preparados, copiados, publicados e distribudos, no todo ou em parte, sem restries de qualquer
tipo, inserindo em todas as cpias e trabalhos derivados a notificao de copyright acima e este
pargrafo. Contudo, este documento no pode ser ele prprio modificado de qualquer maneira, tal
como a remoo desta notificao de copyright ou referncias ao OASIS, exceto quando
necessrio para o propsito de desenvolvimento de especificaes OASIS, e neste caso os
procedimentos para copyrights definidos no documento Direitos de Propriedade Intelectual OASIS
precisam ser seguidos, ou como requerido para traduo para outras lnguas que no a Inglesa.
As permisses limitadas concedidas acima so perptuas e no sero revogadas pela OASIS e
seus sucessores ou signatrios.
Este documento e as informaes aqui contidas so fornecidas na forma COMO ELAS ESTO e
a OASIS NO FORNECE NENHUMA GRARANTIA, EXPRESSA OU IMPLCITA, INCLUINDO
MAS NO LIMITADO A QUALQUER GARANTIA QUE O USO DESTA INFORMAO NO
INFRINJA QUAISQUER DIREITOS OU QUALQUER GARANTIA IMPLCITA DE
COMERCIALIZAO OU ADEQUAO PARA UM PROPSITO PARTICULAR.

_______________________________________________________________________________
Tabela de Contedo

1. INTRODUO.................................................................................................................................. 1
1.1. O QUE UM MODELO DE REFERNCIA .......................................................................................... 1
1.2. UM MODELO DE REFERNCIA PARA ARQUITETURA ORIENTADA A SERVIO..................................... 1
1.3. AUDINCIA ................................................................................................................................. 2
1.4. GUIA PARA USAR O MODELO DE REFERNCIA ................................................................................ 2
1.5. CONVENES DE NOTAO......................................................................................................... 3
1.5.1. COMO INTERPRETAR OS MAPAS CONCEITUAIS .......................................................................... 3
1.6. RELACIONAMENTO COM OUTROS PADRES................................................................................... 4
2. A ARQUITETURA ORIENTADA A SERVIO................................................................................. 1
2.1. O QUE A ARQUITETURA ORIENTADA A SERVIO........................................................................... 1
2.1.1. UM EXEMPLO TRABALHADO DE ARQUITETURA ORIENTADA A SERVIOS...................................... 2
2.2. COMO A ARQUITETURA ORIENTADA A SERVIO DIFERENTE?....................................................... 3
2.3. OS BENEFCIOS DA ARQUITETURA ORIENTADA A SERVIO ............................................................. 4
3. O MODELO DE REFERNCIA........................................................................................................ 1
3.1. O SERVIO................................................................................................................................ 1
3.2. AS DINMICAS DOS SERVIOS ..................................................................................................... 2
3.2.1. A VISIBILIDADE ...................................................................................................................... 2
3.2.1.1. A CONSCINCIA ................................................................................................................ 3
3.2.1.2. A CONCORDNCIA............................................................................................................. 4
3.2.1.3. A ACESSIBILIDADE............................................................................................................. 4
3.2.2. INTERAGINDO COM OS SERVIOS ............................................................................................ 4
3.2.2.1. O MODELO DE INFORMAO............................................................................................... 5
3.2.2.1.1. A ESTRUTURA ................................................................................................................... 5
3.2.2.1.2. A SEMNTICA.................................................................................................................... 6
3.2.2.2. O MODELO COMPORTAMENTAL.......................................................................................... 6
3.2.2.2.1. O MODELO DE AO......................................................................................................... 7
3.2.2.2.2. O MODELO DE PROCESSO................................................................................................. 7
3.2.3. O EFEITO NO MUNDO REAL ..................................................................................................... 7
3.3. SOBRE OS SERVIOS.................................................................................................................. 8
3.3.1. DESCRIO DE SERVIO ........................................................................................................ 9
3.3.1.1. ACESSIBILIDADE DO SERVIO........................................................................................... 10
3.3.1.2. FUNCIONALIDADES DO SERVIO ....................................................................................... 10
3.3.1.3. POLTICAS RELACIONADAS COM UM SERVIO .................................................................... 11
3.3.1.4. A INTERFACE DO SERVIO ............................................................................................... 11
3.3.1.5. OS LIMITES DA DESCRIO............................................................................................... 11
3.3.2. POLTICAS E CONTRATOS ..................................................................................................... 12
3.3.2.1. POLTICA DE SERVIO...................................................................................................... 12
3.3.2.2. CONTRATO DE SERVIO................................................................................................... 13
3.3.3. CONTEXTO DE EXECUO .................................................................................................... 14
4. GUIA DE CONFORMIDADE ............................................................................................................ 1
5. REFERNCIAS ................................................................................................................................ 1
5.1. NORMATIVA................................................................................................................................ 1
5.2. NO-NORMATIVA........................................................................................................................ 1
A. GLOSSRIO......................................................................................................................................... 1
B. AGRADECIMENTOS............................................................................................................................ 1
_______________________________________________________________________________
1. Introduo 1
A noo de Arquitetura Orientada a Servio (SOA) tem recebido significante ateno da comunidade de 2
projeto e desenvolvimento de software. O resultado desta ateno a proliferao de muitas definies 3
conflitantes sobre SOA. Considerando que os padres arquiteturais SOA (ou arquiteturas de 4
referncia) podem ser desenvolvidos para explicar e amparar um gabarito genrico suportando um SOA 5
especfico, um modelo de referncia tem a inteno de oferecer um alto nvel de coisas comuns, com 6
definies que podem ser aplicadas para todo o SOA. 7
1.1. O que um modelo de referncia 8
Um modelo de referncia um framework abstrato para entendimento dos relacionamentos 9
significantes entre as entidades de algum ambiente. Ele habilita o desenvolvimento de arquiteturas 10
especficas usando padres consistentes ou especificaes suportando aquele ambiente. Um modelo 11
de referncia consiste de um conjunto mnimo de conceitos unificados, axiomas e relacionamentos com 12
um domnio de um problema particular, e independente de padres especficos, tecnologias, 13
implementaes, ou outro detalhe concreto. 14
Como uma ilustrao do relacionamento entre um modelo de referncia e as arquiteturas que podem 15
derivar de tal modelo, considere o que pode estar envolvido na modelagem que importante sobre o 16
projeto de uma casa. No contexto de um modelo de referncia, conhecemos que conceitos tais como 17
reas de refeio, reas de higiene e descanso so todos importantes para entender o que 18
compreende uma casa. H relacionamentos entre estes conceitos, e restries sobre como eles so 19
implementados. Por exemplo, pode haver separao fsica entre as reas de higiene e de refeio. 20
O papel de uma arquitetura de referncia para projeto de uma casa pode ser identificar as solues 21
abstratas para os problemas de projetar uma casa. Um padro genrico para projeto de casa, um que 22
enderece as necessidades de seus ocupantes no sentido que, digamos, nada que seja banheiro, 23
cozinha, corredores, e assim por diante uma boa base para uma arquitetura de referncia abstrata. O 24
conceito de rea de refeio um conceito no modelo de referncia, uma cozinha a realizao de 25
rea de refeio no contexto de arquitetura de referncia. 26
Pode haver mais de uma arquitetura de referncia que trate de como projetar uma casa, por exemplo, 27
pode haver uma arquitetura de referncia que aborde os requisitos para desenvolvimento de solues 28
para projeto de casas em grandes complexos de apartamentos, outro para tratar de casas para uma 29
nica famlia no subrbio, e outra para espaos pblicos. No contexto de alta densidade de residncias, 30
no deve haver uma cozinha separada, mas um espao de cozinha compartilhada ou ainda uma 31
cozinha comum usada por muitas famlias. 32
Uma real ou concreta arquitetura pode introduzir elementos adicionais. Ela pode incorporar estilos 33
arquiteturais particulares, arranjos particulares de janelas, materiais de construo a serem usados e 34
assim por diante. Uma planta de uma casa em particular representa uma instanciao de uma 35
arquitetura como ela aplicada para a construo de uma moradia real. 36
O modelo de referncia para projeto de casas , portanto, formado por trs nveis de abstraes 37
independentes de uma entidade fsica que possa viver ali. O propsito de um modelo de referncia 38
oferecer um framework conceitual comum que possa ser usado consistentemente atravs e entre 39
diferentes implementaes e uso particular na modelagem de solues especficas. 40
1.2. Um Modelo de Referncia para Arquiteturas Orientada a Servio 41
O objetivo deste modelo de referncia definir a essncia da arquitetura orientada a servio, e propor 42
um vocabulrio e um entendimento comum de SOA. Ele oferece uma referncia normativa que 43
permanece relevante para SOA como um modelo abstrato e poderoso, independente das vrias 44
inevitveis evolues tecnolgicas que venham a influenciar a realizao de SOA. 45
A Figura 1 mostra como um modelo de referncia para SOA se relaciona s outras entradas de 46
arquiteturas de sistemas distribudos. Os conceitos e relacionamentos definidos pelo modelo de 47
referncia tm a inteno de ser base para descrio de arquiteturas de referncias e padres que 48
definem as categorias mais especficas de projetos SOA. As arquiteturas concretas vm de uma 49

combinao de arquiteturas de referncia, padres de arquitetura e requisitos adicionais, incluindo 50
aqueles impostos pelos ambientes tecnolgicos. 51
A arquitetura precisa considerar as metas, motivaes e requisitos que definem os problemas reais que 52
esto sendo estudados. Enquanto arquiteturas de referncias podem formar as bases de classes de 53
solues, as arquiteturas concretas iro definir abordagens de solues especficas. 54
A arquitetura freqentemente desenvolvida no contexto de um ambiente pr-definido, como os 55
protocolos, perfis, especificaes, e padres que so pertinentes. 56
As implementaes SOA combinam todos estes elementos, do princpio arquitetural mais genrico e 57
infra-estrutura at o especfico que define as necessidades atuais, e representa implementaes 58
especficas que sero construdas e usadas em um ambiente operacional. 59
60
Figura 1 Como o Modelo de Referncia relaciona-se com os outros trabalhos 61
1.3. Audincia 62
A audincia pretendida para este documento inclui de forma no exaustiva: 63
Os arquitetos e projetistas desenvolvedores, identificando ou desenvolvendo um sistema 64
baseado no paradigma orientado a servio. 65
Os arquitetos de padres e analistas desenvolvendo especificaes que trabalhem com os 66
conceitos de arquitetura orientada a servio. 67
Os tomadores de deciso que procuram uma consistente e comum compreenso das 68
arquiteturas orientadas a servio. 69
Os usurios que necessitam de um melhor entendimento dos conceitos e benefcios da 70
arquitetura orientada a servio. 71
1.4. Guia para usar o modelo de referncia 72
Os novos leitores so encorajados a lerem este modelo de referncia por completo. Os conceitos so 73
apresentados em uma ordem que os autores esperam promover um entendimento rpido. 74
conta
para
Concreto
Abstrato
consi-
dera
Modelo de
Referncia

Requisitos
Motivao
Metas
Entrada

Protocolos
Perfis
Especificaes
Trabalhos
relacionados
Padres

Arquiteturas
de Referncia
Trabalho de Arquitetura
Padres
Modelos
relacionados
deriva
Arquiteturas
Concretas
guiado
por
conta para restries de usa
Implementaes da Arquitetura Orientada a Servio

Esta seo introduz as convenes, define a audincia e configura o cenrio para o resto do 75
documento. Os leitores no tcnicos so encorajados a lerem estas informaes que oferecem um 76
suporte material necessrio para entender a natureza e uso dos modelos de referncia. 77
A seo 2 introduz o conceito de SOA e identifica algumas formas onde ele diferente do paradigma 78
anterior, o sistema distribudo. A seo 2 oferece um guia sobre os princpios bsicos da arquitetura 79
orientada a servios. Isto pode ser usado por leitores no tcnicos para ganhar uma compreenso 80
explicita sobre os princpios centrais do SOA e por arquitetos como um guia para desenvolvimento de 81
arquiteturas especficas orientadas a servio. 82
A seo 3 introduz o Modelo de Referncia SOA. Em qualquer framework rico como o SOA, difcil 83
evitar uma quantidade significativa de referncias cruzadas entre conceitos. Isto torna a apresentao 84
do material sujeito a certa dose de arbitrariedade. Resolvemos isto pela introduo do prprio conceito 85
de servio, e ento introduzimos os conceitos relacionados aos aspectos dinmicos de servio e 86
finalmente introduzimos aqueles conceitos que se referem aos aspectos de nvel-meta de servios 87
como a descrio do servio e as polticas que so aplicadas aos servios. 88
A seo 4 trata da aderncia a este modelo de referncia. 89
O glossrio oferece definies de termos que so pertinentes especificao do modelo de referncia, 90
mas no parte necessria da especificao. Os termos que so definidos no glossrio so escritos 91
em negrito quando de sua primeira ocorrncia no documento. 92
Note que enquanto os conceitos e os relacionamentos descritos neste modelo de referncia podem ser 93
aplicados a outros ambientes de servio, as definies e as descries contidas aqui enfocam o 94
campo de arquitetura de software e chamam a ateno para no us-lo por completo fora do domnio 95
de software. Os exemplos includos neste documento que so emprestados de outros domnios so 96
usados estritamente para fins ilustrativos. 97
1.5. Convenes de notao 98
As palavras chaves DEVEM, NO DEVEM, REQUERIDO, PODE, NO PODE, PODERIA, NO 99
PODERIA, RECOMENDADO, MAY (PODE), e OPCIONAL so interpretadas neste documento como 100
descritas na [RFC2119]. 101
As referncias so colocadas entre colchetes [entre colchetes e texto em negrito]. 102
1.5.1. Como interpretar os mapas conceituais 103
Os mapas conceituais so usados neste documento. No h uma conveno normativa para 104
interpretao dos mapas conceituais alm da descrita aqui, nenhuma informao detalhada pode ser 105
derivada destes mapas conceituais. 106
107
Figura 2 Um mapa conceitual bsico 108
Como usado neste documento, uma linha entre dois conceitos representa um relacionamento, onde o 109
relacionamento no rotulado mas ao invs disto descrito no texto imediatamente precedente ou 110
seguinte figura. A seta na linha indica um relacionamento assimtrico, onde o conceito para o qual a 111
seta aponta (Conceito 2 na Figura 2) pode ser interpretado como dependente de alguma forma do 112
conceito no qual a linha origina (Conceito 1). O texto que acompanha cada grfico descreve a natureza 113
de cada relacionamento. 114
Conceito
Conceito

1.6. Relacionamento com outros padres 115
Devido a sua natureza, este modelo de referncia pode ter um relacionamento significativo com 116
qualquer destes grupos que: 117
Considere seu trabalho orientado a servio; 118
Faz (publica) uma declarao de adoo para uso do Modelo de Referncia para SOA como 119
base ou inspirao para seu trabalho; e 120
Os padres ou tecnologias que se enquadram como orientados a servios. 121
O modelo de referncia no endossa nenhuma arquitetura particular orientada a servio, ou atesta a 122
validade de modelos de referncia de terceiros. 123
_______________________________________________________________________________
2. A arquitetura orientada a servio 124
2.1. O que a arquitetura orientada a servio 125
A Arquitetura Orientada a Servio (SOA) um paradigma para organizao e utilizao de 126
competncias distribudas que esto sob controle de diferentes domnios proprietrios. 127
Em geral, as entidades (pessoas e organizaes) criam competncias para resolver ou suportar uma 128
soluo para problemas que encontram no decorrer de seus negcios. natural pensar que as 129
necessidades das pessoas podem ser compatveis com as competncias oferecidas por algum; ou, 130
em outras palavras no mundo da computao distribuda, um requisito de um agente computador pode 131
ser compatvel com o de outro pertencente a outro proprietrio. 132
No h necessariamente uma correlao de um para um entre as necessidades e as competncias; a 133
granularidade das necessidades e competncias variam do fundamental ao complexo, e qualquer 134
necessidade dada pode requerer a combinao de numerosas outras competncias enquanto uma 135
nica competncia pode tratar mais de uma necessidade. O valor percebido do SOA que ele oferece 136
um framework poderoso para compatibilizar essas necessidades e competncias e para combinar 137
competncias para tratar aquelas necessidades. 138
A visibilidade, interao e efeitos so os conceitos chaves para descrever o paradigma SOA. A 139
visibilidade refere-se capacidade para aqueles com necessidades e aqueles com competncias 140
estarem aptos a se verem mutuamente. Isto tipicamente feito pelo oferecimento de descries acerca 141
destes aspectos como as funes e requisitos tcnicos, restries e polticas relacionadas, e 142
mecanismos para acesso e resposta. As descries precisam estar em um formulrio (ou podem ser 143
transformadas em um formulrio) no qual sua sintaxe e semnticas so amplamente acessveis e 144
compreensveis. 145
Enquanto a visibilidade introduz a possibilidade de compatibilizar as necessidades com as 146
competncias (e vice-versa), a interao a atividade que usa a competncia. Tipicamente mediada 147
por troca de mensagens, uma interao prossegue atravs de uma srie de aes de troca de 148
informaes e invocaes. H muitas facetas da interao; mas elas esto todas ligadas a um 149
contexto de execuo particular o conjunto de elementos tcnicos e de negcios que formam um 150
caminho entre aqueles com as necessidades e aqueles com as competncias. Isto permite que os 151
provedores de servios e os consumidores interajam e ofeream um ponto de deciso para quaisquer 152
polticas e contratos que estejam em vigor. 153
O propsito de usar as competncias realizar um ou mais efeitos no mundo real. Como principal, 154
uma interao um ato em oposio um objeto e o resultado de uma interao um efeito (ou um 155
conjunto/srie de efeitos). Este efeito pode ser o retorno de uma informao ou a mudana no estado 156
de entidades (conhecidas ou desconhecidas) que esto envolvidas na interao. 157
Cuidadosamente distinguimos entre aes pblicas e aes privadas; aes privadas so 158
inerentemente desconhecidas pela outra parte. Por outro lado, aes pblicas resultam em mudanas 159
no estado que compartilhado no mnimo entre aqueles envolvidos no contexto de execuo atual e 160
possivelmente para aqueles que compartilham este estado. Os efeitos no mundo real so, ento, 161
expressos em termos das mudanas deste estado compartilhado. 162
Os efeitos esperados no mundo real formam uma importante parte da deciso quando uma dada 163
competncia compatibiliza em similaridade com a necessidade descrita. No cenrio de interao, a 164
descrio dos efeitos no mundo real estabelece as expectativas para aqueles que usam as 165
competncias. Note que, no possvel descrever todos os efeitos do uso de uma competncia. A 166
pedra fundamental do SOA que podemos usar as competncias sem necessitar conhecer todos os 167
seus detalhes. 168
Esta descrio do SOA tem ainda que mencionar o que usualmente considerado o conceito central: o 169
servio. O nome servio definido no dicionrio como O desempenho de trabalho (uma funo) por 170
algum para outro. Contudo, servio, como o termo geralmente entendido, tambm combina as 171
idias relacionadas com: 172
A competncia de executar o trabalho para outro 173

A especificao do trabalho oferecido para outro 174
A oferta para executar trabalho para outro 175
Estes conceitos enfatizam uma distino entre a competncia e a habilidade para trazer esta 176
competncia para produzir. Enquanto as necessidades e as competncias existem independentemente 177
do SOA, no SOA, os servios so o mecanismo pelo qual as necessidades e as competncias 178
so colocadas juntas. 179
SOA um meio para organizar as solues que promovem o reuso, crescimento e interoperabilidade. 180
No ele prprio uma soluo para os problemas do domnio, mas ao invs disto um paradigma para 181
organizao e entrega que habilita algum ter mais valor a partir do uso das competncias que so 182
localmente prprias e aquelas sob controle de outros. Ele tambm habilita algum expressar as 183
solues de uma maneira que a torna fcil de modificar ou desenvolver a soluo identificada ou tentar 184
solues alternativas. O SOA no oferece nenhum elemento de domnio de uma soluo que no 185
exista sem o SOA. 186
Note que enquanto um servio SOA compatibiliza as necessidades e competncias, o provedor da 187
competncia subjacente pode no ser a mesma entidade que eventualmente oferece o servio que 188
acessa aquela competncia. Na realidade, a entidade com expertise de domnio para criar, manter, e 189
evoluir uma dada competncia pode no ter a expertise ou o desejo de criar, manter, e evoluir o acesso 190
a seus servios. 191
Os conceitos de visibilidade, interao, e efeitos se aplicam diretamente para servios da mesma 192
maneira como est descrita para o paradigma SOA em geral. A visibilidade promovida atravs da 193
descrio do servio que contm as informaes necessrias para interagir com o servio e descreve 194
isto em tais termos como entradas, sadas e semnticas associadas ao servio. A descrio do servio 195
tambm comunica o que est consumado quando o servio invocado e as condies para usar o 196
servio. 197
Em geral, as entidades (pessoas e organizaes) oferecem competncias e atuam como provedores 198
de servio. Aqueles com necessidades que fazem uso dos servios so referenciados como 199
consumidores de servio. A descrio do servio permite que os consumidores prospectivos decidam 200
se o servio conveniente para suas necessidades atuais e estabelece quando um consumidor satisfaz 201
todos os requisitos do provedor de servio. 202
(Nota, os provedores de servios e os consumidores de servio so algumas vezes referenciados 203
conjuntamente como participantes do servio.). 204
Na maioria das discusses sobre SOA, os termos acoplamento fraco e granularidade grossa so 205
comumente aplicadas como conceitos SOA, mas estes termos no esto intencionalmente sendo 206
usados na atual discusso por que eles so comprometimentos subjetivos e sem mtricas satisfatrias. 207
Em termos de necessidades e competncias, granularidade e a no granularidade so usualmente 208
relativas ao nvel de detalhe para o problema que se est tratando, por exemplo, um que seja mais 209
estratgico versus outro que desa no nvel de algoritmo, e definindo o nvel timo no est suscetvel a 210
contagem do nmero de interfaces ou o nmero ou tipo de informaes trocadas conectadas a uma 211
interface. 212
Note que embora o SOA seja comumente implementado usando Web Services, os servios podem ser 213
visveis, suportar interaes, e gerar efeitos atravs outras estratgias de implementao. As 214
arquiteturas e as tecnologias baseadas em Web Services so especficas e concretas. Enquanto os 215
conceitos no Modelo de Referncia se aplicam a estes sistemas, os Web Services so tambm 216
solues especficas a serem parte de um modelo de referncia genrico. 217
2.1.1. Um exemplo trabalhado de Arquitetura Orientada a Servios 218
Uma empresa de eletricidade tem a capacidade de gerar e distribuir eletricidade (capacidade 219
subjacente). A fiao da rede de distribuio da companhia eltrica (o servio) oferece o meio 220
para fornecer eletricidade para suportar o uso por um consumidor residencial tpico 221
(funcionalidade do servio), e um consumidor acessa a eletricidade gerada (a sada da 222
invocao de servio) via uma tomada de parede (interface de servio). De forma a utilizar a 223
eletricidade, um consumidor precisa entender que tipo de plug usar, qual a voltagem fornecida, 224
e quais os possveis limites de carga; a empresa presume que o consumidor ir conectar 225

somente aparelhos adequados voltagem ofertada e a carga suportada; e o consumidor por 226
sua vez assume que os aparelhos adequados podem ser conectados sem danos ou riscos 227
(suposies tcnicas do servio). 228
Um usurio residencial ou comercial precisa abrir uma conta na empresa para usar o 229
fornecimento (restrio de servio) e a empresa ir medir o consumo e espera que o 230
consumidor pague pela energia conforme taxa prevista (poltica de servio). Quando o 231
consumidor e a empresa concordam nas restries e polticas (contrato de servio), o 232
consumidor pode ter o fornecimento de eletricidade usando o servio desde que a rede de 233
distribuio de eletricidade e a conexo residencial permaneam intactas (por ex. uma 234
tempestade que derrube a rede e interrompa o fornecimento) e o consumidor pode pagar (por 235
exemplo, transferncia eletrnica de fundos) a empresa (acessibilidade). 236
Outra pessoa (por ex. um visitante a uma casa de algum) pode usar um fornecedor 237
contratado sem qualquer relacionamento com a empresa e qualquer requisio para tambm 238
satisfazer as restries iniciais de servio (i.e. a acessibilidade somente requer a distribuio 239
de eletricidade sem problemas), mas pode ser esperado ser compatvel com a interface de 240
servio. 241
Em certas situaes (por ex. demanda excessiva), uma empresa pode limitar o fornecimento 242
ou instituir cortes rotativos (polticas de servio). Um consumidor pode guardar uma aceitao 243
formal se isto ocorre freqentemente (poltica implcita do consumidor). 244
Se a empresa requer que cada aparelho seja firmemente ligado aos seus equipamentos, a 245
capacidade subjacente pode ainda estar l, mas isto pode ser um servio diferente e ter uma 246
interface de servio diferente. 247
2.2. Como a Arquitetura Orientada a Servio diferente? 248
Diferentemente do paradigma de Programao Orientada a Objeto, onde o foco est no 249
empacotamento de dados com operaes, o foco central da Arquitetura Orientada a Servio a tarefa 250
ou funo de negcio obtendo alguma coisa feita. 251
Esta distino se manifesta de diferentes formas: 252
A OO tem a inteno de unir os mtodos a um dado objeto de dados. Os mtodos podem ser 253
pensados como uma propriedade do objeto. Para o SOA, pode-se pensar os servios como 254
tendo acesso aos mtodos, mas a real existncia dos mtodos e qualquer conexo com os 255
objetos incidental. 256
Para usar um objeto, ele precisa primeiro ser instanciado enquanto ele interage com um 257
servio onde ele existe. 258
Um objeto expe a estrutura, mas no h maneira de expressar a semntica a no ser 259
capturando como comentrio na definio da classe. O SOA enfatiza a necessidade de 260
clarificar a semntica. 261
Ambos, a OO e o SOA so como formas de pensar sobre representao de coisas e aes no mundo 262
referindo-se especificamente sobre a construo de sistemas. A coisa importante o entendimento e 263
aplicao do paradigma. Portanto a questo no o que um servio? muito mais que isto o que 264
um objeto?. Qualquer coisa pode ser um servio da mesma forma que qualquer coisa pode ser um 265
objeto. O desafio aplicar o paradigma para melhorar a clareza e obter as coisas feitas. O SOA oferece 266
a base mais vivel para sistemas de grande escala por que ele se enquadra melhor na forma como as 267
atividades humanas so gerenciadas por delegao. 268
Como o paradigma SOA difere das outras abordagens para organizar e entender os recursos da 269
Tecnologia da Informao? Essencialmente, h duas reas na quais ela difere e ambas moldam o 270
framework de conceitos que reside nos sistemas distribudos. 271
Primeiro, o SOA reflete a realidade que os limites da posse so uma considerao de motivao na 272
arquitetura e projeto de sistemas. Este reconhecimento evidente nos conceitos centrais de 273
visibilidade, interao e efeito. 274
Contudo, o SOA no trata de todos os conceitos associados com a posse, domnio de posse e aes 275
comunicadas entre pontos legais. Para contabilizar totalmente os conceitos tais como confiana, 276

transaes de negcio, autoridade, delegao e assim por diante um framework conceitual adicional 277
e elementos arquiteturais so requeridos. No contexto do SOA, estes so representados e 278
referenciados como descries de servio e interface de servio. A presena das descries de 279
servio e interface de servio oferece uma pronta localizao para incluso de tal referencia e ento 280
facilita o reuso do framework desenvolvido externamente e a interoperabilidade entre sistemas 281
disponibilizando-os para este reuso. 282
Segundo, o SOA aplica a lio aprendida com o comrcio na organizao dos recursos de TI para 283
facilitar a compatibilizao das competncias e necessidades. Que duas ou mais entidades que esto 284
juntas no contexto de uma nica interao implica a troca de algum tipo de valor. Essa a mesma base 285
fundamental como o prprio comrcio, e sugere que como o SOA evolui a partir das interaes 286
definidas de uma maneira ponto-a-ponto para um mercado de servios; a tecnologia e os conceitos 287
podem expandir com sucesso como o mercado comercial. 288
2.3. Os benefcios da Arquitetura Orientada a Servio 289
Os principais motivos para a arquitetura baseada em SOA so para facilitar o gerenciamento do 290
crescimento dos sistemas corporativos de larga escala, para facilitar o provisionamento da 291
escalabilidade da Internet para uso por servios e reduzir custos nas organizaes para cooperao 292
das organizaes. 293
O valor do SOA que ele oferece um paradigma escalvel nico para organizar grandes sistemas em 294
rede que requerem interoperabilidade para realizar o valor inerente aos componentes individuais. 295
Certamente, o SOA escalvel por que ele faz a menor suposio possvel sobre a rede e tambm 296
minimiza qualquer suposio de confiana que so freqentemente feitas em sistemas de escala 297
menor. 298
Um arquiteto usando os princpios do SOA mais bem equipado, conseqentemente, para desenvolver 299
sistemas que so escalveis, evolutveis e gerenciveis. Pode ser fcil decidir como integrar as 300
funcionalidades atravs dos limites proprietrios. Por exemplo, uma grande companhia adquire uma 301
pequena companhia precisa determinar como integrar a infraestrutura de TI adquirida no portiflio 302
global de TI existente. 303
Atravs desta habilidade inerente para escalar e evoluir, o SOA habilita um portiflio de TI que tambm 304
adaptvel para diferentes necessidades de um domnio de problema especfico ou arquitetura de 305
processo. A infraestrutura que SOA incentiva tambm a mais gil e responsvel que aquela 306
construda em um nmero exponencial de pares de interfaces. Conseqentemente, o SOA pode 307
tambm oferecer uma slida fundao para agilidade nos negcios e adaptabilidade. 308
_______________________________________________________________________________
3. O Modelo de Referncia 309
A Figura 3 ilustra os principais conceitos definidos neste MODELO DE REFERNCIA. Os 310
relacionamentos entre eles so desenvolvidos medida que cada conceito exposto. 311
312
Figura 3 Principais conceitos do Modelo de Referncia 313
3.1. O Servio 314
Um servio um mecanismo para habilitar o acesso a um conjunto de uma ou mais competncias, 315
onde o acesso provido usando uma interface que descrita e consistentemente exercitada com 316
restries e polticas como especificados pela descrio de servio. Um servio oferecido por uma 317
entidade o provedor de servio para uso pelos outros, mas os consumidores eventuais do servio 318
podem no saber do provedor de servio e podem demonstrar o uso do servio alm do escopo original 319
concebido pelo provedor. 320
Um servio acessado por meio de uma interface de servio (veja seo 3.3.1.4) onde a interface inclui 321
as especificidades do conhecimento para acessar as competncias subjacentes. No h restries no 322
que constitui as competncias subjacentes ou como o acesso implementado pelo provedor. Ento, o 323
servio pode ser executado como descrito na funcionalidade atravs de um ou mais processos 324
automticos e/ou manuais que ele prprio invocar a outros servios disponveis. 325
Um servio uma caixa preta por que sua implementao oculta do consumidor de servio exceto 326
por: (1) os modelos de informao e comportamento so expostos atravs da interface de servio e (2) 327
a informao requerida pelos consumidores de servio para determinar quando um dado servio 328
apropriado para suas necessidades. 329
A conseqncia da invocao de um servio a realizao de um ou mais efeitos no mundo real (ver 330
seo 3.2.3). Estes efeitos podem incluir: 331
1 a informao retornada em resposta a uma requisio daquela informao, 332
2 uma mudana no estado compartilhado de entidades definidas, ou 333
3 alguma combinao de (1) e (2). 334
Note que, o consumidor de servio em (1) tipicamente no sabe como a informao gerada, por 335
exemplo, quando ela extrada de um banco de dados ou gerada dinamicamente; em (2), ele 336
tipicamente no sabe como a mudana de estado afetada. 337
Servio
Contrato &
Polticas
Contexto de
Execuo
Visibilidade
Efeito no
mundo real
Descrio
do Servio
Interao

O conceito de servio acima enfatiza a distino entre a competncia que representa alguma 338
funcionalidade criada para enderear a necessidade e o ponto de acesso para trazer aquela 339
competncia para o contexto do SOA. assumido que esta competncia existe fora do SOA. No uso 340
real, manter esta distino no pode ser crtico (i.e. o servio pode ser pensado em termos de trazer a 341
competncia), mas a separao pertinente em termos de uma expresso clara da natureza do SOA e 342
do valor que ele oferece. 343
3.2. As dinmicas dos Servios 344
Da perspectiva da dinmica de servio, h trs conceitos fundamentais que so importantes no 345
entendimento do que est envolvido na interao com servios: a visibilidade entre provedores de 346
servios e consumidores, e a interao entre eles, e os efeitos no mundo real da interao com um 347
servio. 348
349
Figura 4 - Conceitos acerca das dinmicas do servio 350
3.2.1. A Visibilidade 351
Para um provedor de servio e um consumidor interagirem entre si eles tem que estar aptos a se 352
verem entre si. Isto verdade para qualquer relacionamento consumidor/provedor incluindo um 353
programa aplicao onde um programa chama outro: sem que biblioteca apropriada esteja presente a 354
funo no pode ser completada. No caso do SOA, a visibilidade necessita ser enfatizada por que no 355
necessariamente bvio saber como os participantes podem se ver entre si. 356
357
Servio
Visibilidade
Efeito no
mundo real
Interao

357
Figura 5 Conceitos ao redor de Visibilidade 358
A Visibilidade o relacionamento entre os consumidores e provedores de servio que satisfeito 359
quando eles esto aptos a interagirem entre si. As pr-condies para visibilidade so conscincia, 360
concordncia e acessibilidade. O iniciante numa interao de servio PRECISA ter a percepo dos 361
outros parceiros, os participantes PRECISAM estar predispostos para uma interao, e os participantes 362
PRECISAM estar aptos a interagir. 363
3.2.1.1. A Conscincia 364
Ambos, o provedor de servio e o consumidor de servio PRECISAM ter a informao que pode 365
conduzi-los a conhecer a existncia dos outros. Tecnicamente, o primeiro requisito que o iniciante de 366
uma interao de servio tenha conhecimento do respondente. O fato de uma iniciao bem sucedida 367
freqentemente suficiente para informar ao respondente da existncia do outro. 368
A conscincia o estado no qual uma parte tem conhecimento da existncia da outra parte. A 369
conscincia no implica em concordncia ou acessibilidade. A conscincia do servio ofertada 370
freqentemente afetada por muitos mecanismos de descoberta. Para um consumidor de servio 371
descobrir um servio, o provedor de service precisa ser capaz de criar os detalhes do servio 372
(notavelmente a descrio do servio e polticas) disponveis para consumidores em potencial; e 373
consumidores precisam ser capazes de tomarem conhecimento desta informao. Em contrapartida, os 374
provedores de servios podem precisar descobrir igualmente os consumidores e pode precisar tornar 375
conhecimento da descrio do consumidor. A seguir, discutimos a conscincia em termos da 376
visibilidade do servio, mas os conceitos so igualmente vlidos para a visibilidade do consumidor. 377
A conscincia do servio requer que a descrio do servio e poltica ou pelo menos um 378
subconjunto adequado estejam disponveis de tal maneira e de forma que, direta ou indiretamente, 379
um consumidor potencial esteja ciente da existncia e das competncias do servio. A extenso para a 380
qual a descrio empurrada pelo provedor de servios, e puxado por um consumidor em potencial, 381
sujeito prova ou outro mtodo, que depende de muitos fatores. 382
Por exemplo, um provedor de services pode anunciar e promover seus services pela incluso dele em 383
um diretrio de services ou por difuso para todos os consumidores; consumidores potenciais podem 384
difundir suas necessidades particulares de service na esperana que um service adequado responda 385
com uma proposta ou oferta, ou um consumidor de service pode tambm percorrer uma rede inteira 386
para determinar se o servio adequado existe. Quando a demanda para um servio mais alta que a 387
fornecida, ento, pelo anncio de suas necessidades, os consumidores potenciais podem ser mais 388
efetivos que os anncios dos provedores de servio oferecendo servios. 389
Servio
Visibilidade
Efeito no
mundo real
Interao
Concordncia
Conscincia
Acessibilidade

De uma forma ou outra, o consumidor potencial precisa adquirir as descries suficientes para avaliar 390
quando um dos servios compatvel com suas necessidades, e ento disparar o mtodo para o 391
consumidor interagir com o servio. 392
3.2.1.2. A Concordncia 393
Associado com todos os servios as interaes so intencionais um ato intencional iniciar e 394
participar de uma interao de servio. Por exemplo, se um consumidor de servio descobre um servio 395
via sua descrio em um registro, e o consumidor inicia uma interao, se o provedor de servio no 396
coopera ento no pode haver interao. Em algumas circunstancias este precisamente o 397
comportamento correto para um servio falhar na resposta por exemplo, esta a defesa clssica 398
contra certos ataques para derrubar o servio. 399
A extenso da concordncia dos participantes do servio para engajar em uma interao de servio 400
pode estar sujeito a polticas. Estas polticas podem ser documentadas na descrio do servio. 401
Com certeza, a concordncia da parte do provedor de servio e do consumidor para interagir no a 402
mesma concordncia para executar as aes requeridas. Um provedor de servio que rejeita todas as 403
tentativas para executar alguma ao pode ainda estar totalmente disponvel e engajado na interao 404
com o consumidor. 405
3.2.1.3. A Acessibilidade 406
A acessibilidade o relacionamento entre participantes de servio onde eles esto aptos a interagir; 407
possivelmente trocando informaes. A acessibilidade um pr-requisito essencial para a interao do 408
servio os participantes PRECISAM estar aptos a ser comunicarem. 409
Um consumidor de servio pode ter a inteno de interagir com um servio, e pode sempre ter todas as 410
informaes necessrias para com ele. Contudo, se o servio no est alcanvel, por exemplo, se no 411
h um caminho de comunicao entre o consumidor e o provedor, ento efetivamente, o servio no 412
est visvel ao consumidor. 413
3.2.2. Interagindo com os Servios 414
A interao com o servio envolve a execuo de aes na direo do servio. Em muitos casos, isto 415
realizado pelo envio e recebimento de mensagens, mas h outros modos possveis que no envolvem 416
explicitamente a transmisso de mensagens. Por exemplo, uma interao de servio pode ser efetuada 417
pela modificao do estado de um recurso compartilhado. Contudo, por simplicidade, freqentemente 418
se refere troca de mensagens como modo primrio de interao com um servio. 419
420

420
Figura 6 Conceitos na interao de servio 421
A figura 6 ilustra os conceitos chaves que so importantes no entendimento do que est envolvido 422
numa interao de servios; isto gira ao redor da descrio do servio que referencia um modelo de 423
informao e um modelo de comportamento. 424
3.2.2.1. O modelo de informao 425
O modelo de informao de um servio uma caracterizao da informao que pode ser trocada com 426
o servio. Somente informao e dados que so potencialmente trocados com um servio so 427
geralmente includos no modelo de informao do servio. 428
O escopo do modelo de informaes inclui o formato da informao que trocada, os relacionamentos 429
estruturais com a informao trocada e tambm a definio dos termos usados. 430
Particularmente para informao que trocada atravs dos limites proprietrios, um importante aspecto 431
do modelo de informao de servio a interpretao consistente das cadeias de caracteres (strings) e 432
outros sinais (tokens) na informao. 433
A extenso na qual um sistema pode efetivamente interpretar a informao de outro sistema 434
governado pelo comprometimento semntico dos vrios sistemas. O comprometimento semntico de 435
um sistema um relacionamento entre o sistema e a informao que ele pode ser encontrado. Isto 436
altamente varivel e dependente da aplicao; por exemplo, um servio de encriptao interpreta todas 437
as informaes como uma seqncia (stream) de bytes para realizar a encriptao e a decriptao, no 438
entanto um servio de banco de dados pode tentar interpretar a mesma seqncia de informao em 439
termos de requisies de consulta (query) e/ou modificar o banco de dados. 440
Vagamente, algum pode particionar a interpretao de um bloco de informao em estrutura (sintaxe) 441
e significado (semntica); contudo ambas so partes do modelo de informao. 442
3.2.2.1.1. A estrutura 443
Conhecer a representao, estrutura, e forma da informao requerida um passo inicial chave para 444
assegurar efetiva interao com um servio. H muitos nveis desta informao estrutural; incluindo a 445
codificao dos caracteres do dado, o formato dos dados e os tipos de dados estruturais associados 446
com elementos da informao. 447
Servio
Visibilidade
Efeito no
mundo real
Descrio
do Servio
Modo de Ao
Modelo de
Processo
Interao
Modelo de
Informao
Semntica Estrutura
Modelo de
Comportamento

Um modelo informao descrita tipicamente tem um grande tratado para dizer acerca da forma das 448
mensagens. Contudo, conhecer o tipo de informao no suficiente para descrever completamente a 449
interpretao apropriada dos dados. Por exemplo, com uma estrutura de dados de endereo, o nome 450
da cidade e o nome da rua so tipicamente do mesmo tipo de dados algumas variantes do tipo string. 451
Contudo, os nomes de cidade e nomes de ruas no so realmente os mesmo tipos de coisa. Distinguir 452
a correta interpretao de uma string de nome de cidade e uma string de nome de rua no possvel 453
usando os tipos tcnicos bsicos requerida uma informao adicional que no pode ser expressa 454
puramente em termos de estrutura de dados. 455
3.2.2.1.2. A Semntica 456
A tarefa primria de qualquer infra-estrutura de comunicao facilitar a troca de informaes e troca 457
de intenes. Por exemplo, uma ordem de compra combina de certo modo dois aspectos ortogonais: a 458
descrio dos itens da compra e o fato que uma das partes tem a inteno de comprar aqueles itens de 459
outra parte. Mesmo para trocas que no ocorrem atravs do limite proprietrio, as trocas com servios 460
tem aspectos similares. 461
Especialmente nos casos onde as trocas so atravs dos limites proprietrios, uma questo critica a 462
interpretao dos dados. Esta interpretao PRECISA ser consistente entre os participantes da 463
interao do servio. A interpretao consistente um forte requisito mais que um mero tipo (ou 464
estrutural) de consistncia os sinais nos prprios dados precisam ter tambm uma base 465
compartilhada. 466
Geralmente h um amplo potencial para a variabilidade na representao de endereos. Por exemplo, 467
um endereo em So Francisco, Califrnia pode ter variaes na forma que a cidade representada: 468
SF, San Francisco, San Fran, a cidade da Baa so alternativas que denominam a mesma cidade. Para 469
a troca bem sucedida da informao de endereo, todos os participantes precisam ter uma viso 470
consistente do significado dos sinais de endereo se a informao de endereo para ser 471
compartilhada de maneira confivel. 472
A descrio formal dos itens e o relacionamento entre eles (i.e., uma ontologia) oferecem uma base 473
slida para a seleo da interpretao correta para os elementos da informao trocada. Por exemplo, 474
uma ontologia pode ser usada para capturar as formas alternativas para expressar o nome da cidade 475
bem como para distinguir um nome de cidade do nome de uma rua. 476
Note que, para a maior parte, no esperado que o consumidor de servio e o provedor possam 477
realmente trocar descries dos termos em suas interaes, mas ao invs disto, possam referenciar as 478
descries existentes o papel da semntica ocorrendo de forma subjacente e estas referncias 479
podem ser includas na descrio do servio. 480
As semnticas de domnio especfico esto fora do escopo deste modelo de referencia; mas h um 481
requisito que a interface de servio habilite os provedores e consumidores a identificarem-se sem 482
ambigidade estas definies que so relevantes para os seus domnios. 483
3.2.2.2. O Modelo Comportamental 484
Um segundo requisito chave para interaes bem sucedidas com servios o conhecimento das aes 485
envolvidas no servio e no processo ou aspectos temporais de uma interao com o servio. Isto 486
caracterizado como conhecimento das aes sobre as respostas, e as dependncias temporais entre 487
aes sobre o servio. 488
Por exemplo, em um acesso controlado e seguro a um banco de dados, as aes disponveis para um 489
consumidor de servio incluem a apresentao de credenciais, requisies de atualizaes de banco 490
de dados e leituras de resultados de consultas. A segurana pode ser baseada em um protocolo 491
provocao-resposta. Por exemplo, o iniciante apresenta um sinal inicial para identificar, a respondente 492
apresenta uma provocao e o iniciante responde a provocao de uma maneira que satisfaz o banco 493
de dados. Somente depois que as credenciais do usurio forem verificadas a ao ria relatar ao banco 494
de dados para atualizar e a consulta ser aceita. 495
A seqncia de aes envolvidas um aspecto critico do conhecimento requerido para o uso bem 496
sucedido de um banco de dados seguro. 497

3.2.2.2.1. O Modelo de Ao 498
O modelo de ao de um servio a caracterizao das aes que podem estar envolvidas na direo 499
do servio. Certamente, uma grande poro do comportamento resultante de uma ao pode ser 500
privativa; contudo, a esperada viso pblica de um servio com certeza inclui a implicao dos efeitos 501
da ao. 502
Por exemplo, em um servio que gerencia uma conta bancaria, no suficiente conhecer o que se 503
necessita trocar uma dada mensagem (com os sinais de autenticao apropriados), de forma a usar o 504
servio. tambm necessrio entender que usando o servio pode realmente afetar o estado da conta 505
(por exemplo, retirada de dinheiro); que dependncias esto envolvidas (por exemplo, uma solicitao 506
de retirada precisa ser menor que o saldo da conta); ou que a mudana de dados efetuada tem valor 507
diferente em diferentes contextos (por exemplo, mudana de dados em um lanamento bancrio no 508
o mesmo que mudana dos dados reais que representam a quantia em uma conta). 509
3.2.2.2.2. O Modelo de Processo 510
O modelo de processo caracteriza o relacionamento temporal entre as propriedades temporais de 511
aes e eventos associados com a interao com o servio. 512
Note que embora o modelo de processo seja parte essencial deste Modelo de Referncia , sua 513
extenso no est completamente definida. Alguns processos podem incluir aspectos que no so 514
estritamente parte do SOA por exemplo, neste Modelo de Referncia no tratamos da orquestrao 515
de mltiplos servios, embora a orquestrao e coreografia possam ser partes do modelo de processo. 516
No mnimo, o modelo de processo PRECISA cobrir as interaes com o prprio servio. 517
Alm do mecanismo direto de interao com um servio h outros, de ordem mais alta, que so 518
importantes como o modelo de processo dos atributos dos servios. Este pode incluir se o servio 519
idempotente, se o servio de longa durao por natureza e se importante contabilizar para 520
qualquer aspecto transacional do servio. 521
3.2.3. O Efeito no Mundo Real 522
Sempre h um propsito particular associado com a interao com um servio. Inversamente, um 523
provedor de servio (e um consumidor) freqentemente tem condies que a priori se aplicam a suas 524
interaes. O consumidor de servio est tentando alcanar algum resultado com o uso do servio, da 525
mesma forma o provedor de servio. Numa primeira vista, tal objetivo pode ser expresso como tente 526
obter o servio para fazer alguma coisa. Isto algumas vezes conhecido como os efeitos no mundo 527
real pelo uso do servio. Por exemplo, um servio de reserva de uma empresa area pode ser usado 528
para aprender sobre os vos disponveis, procura de assentos e por fim agendar uma viagem o efeito 529
desejado no mundo real ter um assento no vo certo. 530
Como discutido na Seo 3.1, um efeito no mundo real pode ser a resposta a uma requisio de 531
informao ou a troca de estado de alguma entidade definida compartilhada pelos participantes do 532
servio. Neste contexto, o estado compartilhado no precisa necessariamente se referir a variveis de 533
estado especficas que so salvas em um meio fsico de armazenamento mas ao invs disto representa 534
a informao compartilhada sobre as entidades afetadas. Assim no exemplo da reserva na companhia 535
area, o estado compartilhado que h um assento reservado em um determinado vo representa 536
um entendimento comum entre um futuro passageiro e a empresa area. Os detalhes da real mudana 537
de estados quer da parte do passageiro (por exemplo disponibilidade de saldo para pagar a 538
passagem) ou a empresa area (Poe exemplo que um assento vendido para aquele vo) no so 539
compartilhados com os outros. 540
541

541
Figura 7 Efeito no mundo real e estado compartilhado 542
Em suma, as aes internas que o provedor de servio e consumidor executam como um resultado da 543
participao na interao do servio so, por definio, privativas e fundamentalmente desconhecidas. 544
Por desconhecidos significamos que ambos que as partes externas no podem ver as aes privativas 545
de outro e mais ainda, NO DEVE haver conhecimento explcito delas. Em lugar disto, focarmos num 546
conjunto de fatos compartilhados pelas partes os estados compartilhados. As aes pelos provedores 547
de servio e consumidores conduzem a modificaes neste estado compartilhado; e os efeitos no 548
mundo reais da interao de um servio so a acumulao de mudanas no estado compartilhado. 549
Por exemplo, quando a empresa area confirmou um assento para um passageiro em um vo isto 550
representa um fato que ambos, a empresa area e o passageiro compartilham ele parte do estado 551
que compartilham. Ento o efeito no mundo real do agendamento de um vo a modificao deste 552
estado compartilhado a criao do fato da agenda. Partindo dos fatos compartilhados, o passageiro, a 553
empresa area, e os terceiros interessados podem fazer inferncias por exemplo, quando o 554
passageiro chega ao aeroporto a empresa area confirma o assento no vo e permite que o passageiro 555
entre no avio (sujeito obvio ao atendimento de outros requisitos necessrios para viajar). 556
Para a empresa area conhecer que o assento confirmado como requerer alguma ao privativa 557
para registrar a reserva. Contudo, o passageiro no deve conhecer detalhes dos procedimentos 558
internos da empresa area. Da mesma forma, a empresa area no sabe se a reserva foi feita por um 559
passageiro ou algum agindo como se fosse ele. O entendimento do passageiro e da companhia area 560
sobre a reserva independente de como a empresa area mantm os registros ou quem iniciou a 561
ao. 562
H um forte relacionamento entre estado compartilhado e as interaes que conduzem a aquele 563
estado. Os elementos do estado compartilhado DEVEM ser inferidos a partir da interao anterior junto 564
com outro contexto como necessrio. Em particular, no requerido que aquele estado seja gravado; 565
porm sem tal registro pode se tornar difcil auditar a interao em um tempo posterior. 566
3.3. Sobre os Servios 567
No suporte das dinmicas da interao com servios h um conjunto de conceitos que se referem aos 568
prprios servios. Estes so as descries do servio, o contexto de execuo do servio e os contratos 569
e polticas que esto relacionadas aos servios e aos participantes do servio. 570
Visibilidade
Interao
Estado
compartilhado
Efeito no
mundo real
Servio

571
Figura 8 Sobre servio 572
3.3.1. Descrio de Servio 573
Uma das garantias de qualidade do SOA a grande quantidade de documentao e descrio 574
associada a ele. 575
A descrio do servio representa a informao necessria de forma a usar um servio. Na maioria dos 576
casos, no h uma descrio certa, mas ao invs disto, os elementos da descrio requerida 577
dependem do contexto e das necessidades das partes que usam a entidade associada. Enquanto h 578
certos elementos que so como parte de qualquer descrio de servio, mais notavelmente o modelo 579
de informao, muitos elementos tais como uma funo e uma poltica podem variar. 580
581
Figura 9 Descrio do servio 582
Servio
Contrato &
Polticas
Contexto de
Execuo
Descrio
do Servio
Visibilidade
Interao
Efeito no
mundo real
Acessibilidade
Descrio
do servio
Interface
do servio
Modelo
comportamental
Funcionalidade
Servio
Modelo de
informao
Contrato &
Polticas

O propsito da descrio facilitar a interao e a visibilidade, particularmente quando os participantes 583
esto em domnios proprietrios diferentes, entre participantes na interao de servio. Pelo 584
oferecimento da descrio, ela torna possvel a potenciais participantes construir sistemas que usam 585
servios e at mesmo oferece servios compatveis. 586
Por exemplo, as descries permitem que os participantes discriminem entre possveis escolhas para 587
interao de servio; como se o servio oferecido requer competncias, como acessar o servio, e 588
negociar sobre as funcionalidades especficas de servio. Ainda mais, as descries podem ser usadas 589
para suportar e gerenciar servios, ambos sob a perspectiva do provedor de servio e sob a perspectiva 590
do consumidor de servio. 591
As melhores prticas sugerem que a descrio do servio DEVE ser representada usando um padro, 592
um formato referencivel. Tal formato facilita o uso de ferramentas de processamento comuns (tais 593
como os engines de pesquisa) que pode trabalhar sobre a descrio de servio. 594
Enquanto o conceito de SOA suporta o uso de um servio sem o consumidor de servio necessitar 595
conhecer os detalhes da implementao do servio, a descrio do servio torna disponveis 596
informaes criticas que o consumidor necessita de forma a decidir se usa ou no o servio. Em 597
particular, um consumidor de service necessita possuir os seguintes itens de informaes: 598
1. Que o servio existe e est acessvel; 599
2. Que o servio executa certa funo ou conjunto de funes; 600
3. Que o servio opera sob um conjunto especfico de restries e polticas; 601
4. Que o servio ir (para alguma extenso implcita ou explicita) concordar com as 602
polticas como prescritas pelo consumidor do servio; 603
5. Como interagir com o servio de forma a alcanar os objetivos desejados, incluindo o 604
formato e contedo da informao trocada entre o servio e o consumidor e as 605
seqncias de informaes trocadas que podem ser esperadas. 606
Enquanto cada um desses itens DEVE ser representado em qualquer descrio de servio, os detalhes 607
podem ser includos atravs de referncias (links) para fontes externas e so NO REQUERIDOS para 608
serem incorporados explicitamente. Isto habilita o reuso das definies padres, tais como para as 609
funcionalidades ou polticas. 610
Outra seo deste documento trata desses aspectos de um servio, mas a seguinte subseo discute 611
elementos importantes como estes relacionados com a prpria descrio do servio. 612
3.3.1.1. Acessibilidade do Servio 613
A acessibilidade inerente ao relacionamento de partes entre os provedores e consumidores de 614
servio. Contudo, a descrio de um servio DEVE incluir dados suficientes para habilitar um 615
consumidor de servio e um provedor de servio a interagirem entre si. Isto PODE incluir metadados 616
como a localizao do servio e o qual protocolo de informao ele suporta e requer. Ela PODE 617
tambm incluir a informao dinmica sobre o servio, como se ele est atualmente disponvel. 618
3.3.1.2. Funcionalidades do Servio 619
Uma descrio do servio DEVE expressar de forma no ambgua a funo(s) do servio e os efeitos 620
no mundo real (ver seo 3.2.3) que resultam de sua invocao. Esta poro da descrio DEVE ser 621
expressa de maneira que seja geralmente compreendida pelos consumidores de servio mas apta a 622
acomodar um vocabulrio que seja suficientemente expressiva para o domnio para o qual o servio 623
oferece suas funcionalidade. A descrio da funcionalidade pode incluir, entre outras possibilidades, 624
uma descrio textual para consumo pelos humanos ou identificadores ou palavras chaves referentes 625
s definies especficas para mquinas de processamento. Para uma descrio completa, PODE ser 626
indicado identificadores mltiplos ou palavras chaves extradas de um nmero de colees diferentes 627
de definies. 628
Parte da descrio da funcionalidade pode incluir suposies tcnicas subjacentes que determinam os 629
limites da funcionalidade exposta pelo servio ou as competncias subjacentes. Por exemplo, a 630
quantidade de dinheiro dispensada por um caixa automtico (ATM) consistente com a suposio que 631

o usurio um indivduo e no um negcio. Para usar o caixa automtico, o usurio precisa no 632
apenas aderir s polticas e satisfazer as restries da instituio financeira associada (ver seo 633
3.3.1.3 para saber como ele se relaciona com a descrio do servio e a seo 3.3.2 para uma 634
discusso mais detalhada) mas o usurio est sujeito a limitaes de retirada de dinheiro fixado a uma 635
certa quantia e a um certo nmero de transaes em um perodo de tempo especificado. A instituio 636
financeira, como competncia subjacente, no tem esses limites mas a interface de servio que 637
exposta aos consumidores tem essas limitaes, consistente com a suposio das necessidades do 638
usurio em questo. Se a suposio no vlida, o usurio pode necessitar usar outro servio para 639
acessar esta competncia. 640
3.3.1.3. Polticas Relacionadas com um Servio 641
Uma descrio de servio PODE incluir suporte para polticas associadas com um servio e oferecer a 642
informao necessria para os consumidores prospectivos avaliarem se um servio ir atuar de uma 643
maneira consistente com as restries do consumidor. 644
3.3.1.4. A interface do Servio 645
A interface de servio o meio para interao com o servio. Ela inclui os protocolos especficos, 646
comandos, e troca de informaes pelas aes so iniciadas e que resultam em efeitos no mundo real 647
como especificado atravs da poro de funcionalidade do servio da descrio do servio. 648
As especificidades da interface PRECISAM ser sintaticamente representadas em um formato padro 649
referencivel. Este prescreve que informaes so necessrias serem providas ao servio de forma a 650
acessar suas competncias e interpretar suas respostas. freqentemente referida como modelo de 651
informao de servio, ver seo 3.2.2.1. Deve ser notado que as particularidades do formato da 652
interface esto fora do escopo deste modelo de referncia. Contudo, a existncia das interfaces e as 653
descries de acessibilidade destas interfaces so fundamentais para o conceito SOA. 654
Enquanto esta discusso refere-se a uma sintaxe referencivel padro para descrio de servio, no 655
especificado como o consumidor acessa a definio da interface nem como o prprio servio 656
acessado. Contudo, assumido que para o servio ser utilizvel, sua interface PRECISA ser 657
representada em um formato que permita a interpretao da informao da interface por seus 658
consumidores. 659
3.3.1.5. Os limites da Descrio 660
So bem conhecidos os limites tericos da efetividade da descrio simplesmente no possvel 661
especificar, completamente e sem ambigidade, a semntica precisa de servio bem como toda a 662
informao relacionada a ele. 663
Sempre haver suposies no estabelecidas feitas pelo relator do servio que precisam ser 664
implicitamente compartilhadas pelos leitores da descrio. Isto se aplica s descries de mquinas de 665
processamento bem como s descries lidas por humanos. 666
Felizmente, uma preciso completa no necessria o que requerido tem o escopo e a preciso 667
suficiente para suportar a inteno de uso pretendida. 668
Outro tipo de limite das descries de servio mais direto: sempre que um repositrio pesquisado 669
usando qualquer tipo de consulta h sempre o potencial de zero ou mais respostas no importando 670
quo completo a consulta seja ou quo completa as descries disponveis possam ser. Isto inerente 671
aos princpios envolvidos na pesquisa. 672
No caso em que h mais de uma resposta, este conjunto de respostas tem que ser convertido em uma 673
simples escolha. Isto uma escolha privativa que precisa ser feita pelo consumidor da informao 674
pesquisada. 675
676

3.3.2. Polticas e Contratos 676
Uma poltica representa alguma restrio ou condio sobre o uso, distribuio ou descrio de uma 677
entidade prpria com definida por qualquer participante. Um contrato, por outro lado, representa um 678
acordo de duas ou mais partes. Assim como as polticas, acordos so tambm sobre as condies de 679
uso de um servio; ele pode tambm restringir os efeitos esperados no mundo real ao usar o servio. O 680
modelo de referncia focado primariamente em conceitos de polticas e contratos e como eles se 681
aplicam ao servio. No estamos nos referindo a forma ou expressividade de qualquer linguagem 682
usada para expressar as polticas e contratos. 683
684
Figura 10 Polticas e Contratos 685
3.3.2.1. Poltica de Servio 686
Conceitualmente, h trs aspectos de polticas: a poltica de afirmao, a poltica do proprietrio 687
(algumas vezes referidas como polticas de assunto) e poltica de obrigao. 688
Por exemplo, a afirmao: Todas as mensagens so criptografadas uma afirmao que independe 689
da forma das mensagens. Como uma afirmao, ela mensurvel: ela pode ser verdadeira ou falsa 690
dependendo se o trfego est encriptado ou no. Polticas de afirmao so freqentes sobre a forma 691
como o servio realizado; i.e., elas tratam do relacionamento entre o servio e seu contexto de 692
execuo, (ver seo 3.3.3). 693
Uma poltica sempre representa um ponto de vista de um participante. Uma afirmao se torna a 694
poltica de um participante quando eles adotam a afirmao como sua poltica. Esta ligao no parte 695
da prpria afirmao. Por exemplo, se o consumidor do servio declara que Todas as mensagens so 696
criptografadas, ento isto reflete a polticas do consumidor de servio. Esta poltica uma que pode 697
ser afirmativa para o consumidor de servio independente de qualquer acordo com o provedor de 698
servio. 699
Finalmente, uma poltica pode ser impositiva. As tcnicas para as polticas impositivas dependem da 700
natureza da poltica. Conceitualmente, as polticas impositivas de servio so em quantidade para 701
assegurar que a poltica de afirmao consistente com o mundo real. Isto pode significar a preveno 702
de execuo de uma ao no autorizada ou a entrada em um estado no autorizado; pode significar 703
tambm o inicio de uma ao compensatria quando uma violao de poltica detectada. Uma 704
restrio de no imposio no uma poltica; ela ser melhor descrita como um desejo. 705
Contexto de
execuo
Descrio
do servio
Partes em
acordo
Servio
Proprietrio
da Poltica
Imposio
Afirmao
Contrato &
Polticas

Polticas potencialmente se aplicam a muitos aspectos do SOA: segurana, privacidade, 706
gerenciabilidade, Qualidade de Servio e assim por diante. Alm dessas polticas orientadas a 707
infraestrutura, os participantes PODEM tambm expressar as polticas orientadas a negcios tais 708
como as horas de negcios, polticas retornadas e assim por diante. 709
As polticas de afirmao DEVEM ser escritas em um formulrio que seja compreensvel para, e 710
processvel pelas, partes s quais as polticas so dirigidas. As polticas PODEM ser interpretadas 711
automaticamente, dependendo do propsito e aplicabilidade da poltica e como ela pode afetar como 712
um servio em particular usado ou no. 713
Um ponto de contato natural entre os participantes do servio e as polticas associadas com o servio 714
a descrio do servio ver seo 3.3.1. natural para a descrio do servio conter referncias s 715
polticas associadas com o servio. 716
3.3.2.2. Contrato de Servio 717
Visto que uma poltica est associada com o ponto de vista dos participantes individuais, um contrato 718
representa um acordo entre dois ou mais participantes. Assim como as polticas, os contratos podem 719
cobrir uma ampla faixa de aspectos de servios: acordos de qualidade de servio, acordos de interface 720
e coreografia e acordos comerciais. Note que, neste caso, no estamos nos referindo aos contratos 721
legais. 722
Ento, seguindo com a discusso acima, um contrato de servio uma afirmao mensurvel que 723
governa os requisitos e expectativas de duas ou mais partes. Assim como as polticas impositivas, que 724
so usualmente de responsabilidade do proprietrio da poltica, os contratos de imposio podem 725
envolver a resoluo de disputas entre as partes do contrato. A resoluo de tal disputa pode envolver 726
apelao a autoridades maiores. 727
Assim como as polticas, os contratos podem ser expressos em um formulrio que permita a 728
interpretao automtica. Onde um contrato usado para codificar os resultados da interao de um 729
servio, uma boa prtica represent-lo em um formulrio processvel por mquina. Entre ouros 730
propsitos, isto facilita a composio automtica do servio. Onde um contrato usado para descrever 731
acordos que influenciam os provedores e consumidores de servio, ento a prioridade provavelmente 732
fazer tais contratos compreensveis pelas pessoas. 733
Desde que um contrato inerentemente o resultado de acordo entre as partes envolvidas, h um 734
processo associado com a ao de acordo. Mesmo no caso de um acordo implcito sobre contrato, h 735
logicamente uma ao de acordo associada com o contrato, mesmo se no houver uma ao pblica 736
de acordo. Um contrato pode chegar por um mecanismo que no seja parte direta de um SOA um 737
processo marginal (out-of-band). Alternativamente, um contrato pode chegar durante o curso de uma 738
interao de um servio um processo no circuito (in-band). 739
740

3.3.3. Contexto de Execuo 740
741
Figura 11 Contexto de Execuo 742
O contexto de execuo de uma interao de servio o conjunto de elementos de infraestrutura, 743
entidades processo, afirmaes e acordos de polticas que so identificados como parte de uma 744
interao de servio instanciado, e ento forma um caminho entre aqueles com necessidades e 745
aqueles com competncias. 746
Como discutido nas sees anteriores deste documento, a descrio do servio (e a correspondente 747
descrio associada com o consumidor de servio e suas necessidades) contm as informaes 748
preferidas que podem ser includas como protocolos, semnticas, polticas e outras condies e 749
suposies que descrevem como um servio deve e pode ser usado. Os participantes (provedores, 750
consumidores, e quaisquer terceiros como citado abaixo) precisam concordar e conhecer um 751
consistente conjunto de acordos de maneira a ter uma interao de servio bem sucedida, i.e., obtendo 752
os efeitos no mundo real descritos. O contexto de execuo a coleo deste conjunto consistente de 753
acordos. 754
O consumidor e o provedor podem ser visualizados como locais separados em um mapa e, para um 755
servio ser realmente invocado, um caminho precisa ser estabelecido entre estes dois locais. Este 756
caminho o contexto de execuo. Como um caminho entre estes dois locais, ele pode ser uma 757
conexo temporria (por ex. uma ponte pequena ou uma troca ad hoc) ou uma coordenao bem 758
definida (por ex. uma super via) que pode ser facilmente reutilizvel no futuro. 759
O contexto de execuo no limitado a um lado da interao; ao invs disto se refere totalidade de 760
interaes incluindo o provedor de servio, o consumidor de servio e a infraestrutura comum 761
necessria para mediar a interao. Enquanto pode haver terceiros, por exemplo, reguladores do 762
governo, que configuram algumas condies para o contexto de execuo, isto meramente aumenta as 763
condies e as restries necessrias para ser coordenada e pode requerer uma troca de informao 764
adicional para completar o contexto de execuo. 765
O contexto de execuo central para muitos aspectos de uma interao de servio. Ele define, por 766
exemplo, um ponto de deciso para imposio de poltica relacionada interao de servios. Note que 767
um ponto de deciso de poltica no necessariamente idntico a um ponto imposio: um contexto de 768
execuo no por si s alguma coisa que conduz ele prprio para a imposio. Por outro lado, 769
qualquer mecanismo de imposio de uma poltica como levar em conta os particulares de um 770
contexto real de execuo. 771
O contexto de execuo tambm permite distinguir os servios de outros. Diferentes instncias do 772
mesmo servio denotando interaes entre um dado provedor de servio e diferentes consumidores 773
Descrio
do servio
Modelo de
informao
Servio
Modelo
comportamental
Interao
Contexto de
execuo
Contrato&
Polticas

de servio, por exemplo so distinguidos pela virtude do fato que seus contextos de execuo so 774
diferentes. 775
Finalmente, o contexto de execuo tambm o contexto no qual a interpretao dos dados que so 776
trocados. Uma string particular tem um significado particular em uma interao de servio em um 777
contexto particular o contexto de execuo. 778
Um contexto de execuo freqentemente evolui durante uma interao de servio. Um conjunto de 779
elementos de infraestrutura, as polticas e acordos que aplicam a interao, podem bem mudar durante 780
uma interao de um dado servio. Por exemplo, como um ponto inicial em uma interao, pode ser 781
decidido pelas partes que as comunicaes podem ser encriptadas. Como um resultado o contexto de 782
execuo tambm muda para incorporar a infraestrutura necessria para suportar a encriptao e 783
continuar a interao. 784
_______________________________________________________________________________
4. Guia de Conformidade 785
Os autores deste modelo de referncia visualizam que os arquitetos podem desejar declarar suas 786
arquiteturas em conformidade com este modelo de referncia. A conformidade com um Modelo de 787
Referncia no geralmente uma tarefa automtica e fcil dado que o papel do Modelo de 788
Referncia primariamente definir conceitos que so importantes para o SOA ao invs de oferecer as 789
linhas guias para implementao de sistemas. 790
Contudo, esperamos que qualquer Arquitetura Orientada a Servio ir referenciar os conceitos 791
delineados nesta especificao. Tal como, esperamos que qualquer projeto de sistema que adote a 792
abordagem SOA ir: 793
Ter entidades que podem ser identificadas como servios como definido neste Modelo de 794
Referncia; 795
Estar apta a identificar como a visibilidade estabelecida entre os provedores e consumidores de 796
servio; 797
Estar apta a identificar como a interao ser mediada; 798
Estar apta a identificar como os efeitos do uso de servios so compreendidos; 799
Ter descries associadas com servios; 800
Estar apta a identificar o contexto de execuo requerido para suportar interaes; e 801
Ser possvel identificar como as polticas so tratadas e como os contratos podem ser modelados 802
e formados. 803
No apropriado para esta especificao identificar as melhores prticas com respeito construo de 804
sistemas baseados em SOA. Contudo, a facilidade com a qual os elementos acima podem ser 805
identificados em um dado sistema baseado em SOA pode ter impacto significante na escalabilidade, 806
manutenibilidade e facilidade de uso do sistema. 807
_______________________________________________________________________________
5. Referncias 808
5.1. Normativa 809
[RFC2119] S. Bradner , Key words for use in RFCs to Indicate Requirement Levels, 810
http://www.ietf.org/rfv/rfc2119.txt, IETF RFC 2119, Maro 1997. 811
5.2. No-Normativa 812
[W3C WSA] W3C Working Group Note Web Services Architecture, 813
http://www.w3.org/TR/ws-arch/, 11 Fevereiro 2004. 814
815
_______________________________________________________________________________
A. Glossrio 816
Este glossrio contm uma definio concisa dos termos usados nesta especificao, mas a descrio 817
completa no texto a descrio normativa. 818
Acessibilidade (reachability) 819
A habilidade de um consumidor de servio e um provedor de servio interagir. A acessibilidade 820
um aspecto da visibilidade. Ver seo 3.2.1.3. 821
Arquitetura de Referncia (reference architecture) 822
Uma arquitetura de referncia um padro de projeto arquitetural que indica como um 823
conjunto abstrato de mecanismos e relacionamentos realiza um predeterminado conjunto de 824
requisitos. Ver seo 1.1. 825
Arquitetura de Software (software architecture) 826
A estrutura ou estruturas de um sistema de informao que consiste de entidades e suas 827
propriedades visveis externamente, e os relacionamentos entre elas. 828
Arquitetura Orientada a Servio (SOA Service Oriented Architecture) 829
A Arquitetura Orientada a Servio um paradigma para organizar e utilizar as competncias 830
distribudas que podem estar sob controle de diferentes domnios proprietrios. Ela prove um 831
meio uniforme para ofertar, descobrir, interagir com as competncias para produzir os feitos 832
desejados consistentes com as precondies mensurveis e expectativas. Ver seo 2.1. 833
Competncias (capability) 834
Um efeito no mundo real que um provedor de servio est apto a oferecer para um consumidor 835
de servio. Ver seo 2.1 836
Comprometimento semntico (semantic engagement) 837
O relacionamento entre um agente e um conjunto de informao que depende de uma 838
interpretao particular da informao. Ver seo 3.2.2.1. 839
Concordncia (willingness) 840
A predisposio dos provedores e consumidores de servio para interagirem. Ver seo 841
3.2.1.2. 842
Conscincia (awareness) 843
Um estado por meio do qual uma parte tem conhecimento da existncia de outra parte. A 844
conscincia no implica concordncia ou acessibilidade. Ver seo 3.2.1.1. 845
Consumidor de Servio (service consumer) 846
Uma entidade que pesquisa para satisfazer uma necessidade particular atravs do uso de 847
competncias oferecidas por meio de um servio. 848
Contexto de execuo (execution context) 849
O conjunto de elementos tcnicos e de negcios que formam um caminho entre aqueles com 850
necessidades e aqueles com competncias e que permita os provedores e consumidores de 851
servio interagirem. Ver seo 3.3.3. 852
Descrio do service (service description) 853
A informao necessria de forma a usar, ou considerar em uso, um servio. Ver seo 3.3.1. 854
Efeitos no mundo real (real world effect) 855

O resultado real do uso de um servio, ao invs de apenas a competncia oferecida pelo 856
provedor de servios. Ver seo 3.2.3. 857
Estado compartilhado (shared state) 858
O conjunto de fatos e comprometimentos que manifestam eles prprios para os participantes 859
do servio como um resultado da interao com um servio. 860
Framework (framework) 861
Um conjunto de suposies, conceitos , valores e prticas que constituem uma forma de 862
visualizar o ambiente atual. 863
Idempotncia / Idempotente (idempotency/idempotent) 864
A caracterstica de um servio no qual mltiplas tentativas de mudar um estado iro sempre e 865
somente gerar uma nica mudana no estado se a operao j tiver sido bem sucedida e 866
completada uma vez. Ver seo 3.2.2.2.2. 867
Interao (interaction) 868
A atividade envolvida no uso de uma competncia oferecida, usualmente atravs de um limite 869
proprietrio, de forma a alcanar um desejado efeito particular no mundo real. Ver seo 3.2.3. 870
Interface de service (service interface) 871
O meio pelo qual a competncia subjacente de um servio acessada. Ver seo 3.3.1.4. 872
Modelo comportamental (behavior model) 873
A caracterizao das (e respostas para, e dependncias temporais entre) aes de um servio. 874
Ver seo 3.2.2.2. 875
Modelo de Ao (action model) 876
A caracterizao de aes permitidas que possam ser invocadas na direo do servio. Ver 877
seo 3.2.2.2.1. 878
Modelo de Informao (information model) 879
A caracterizao da informao que esta associada com o uso de um servio. Ver seo 880
3.2.2.1. 881
Modelo de Processo (process model) 882
A caracterizao de um relacionamento temporal entre as propriedades temporais das aese 883
dos eventos associados com a interao de um servio. Ver seo 3.2.2.2.2. 884
Modelo de Referncia (reference model) 885
Um modelo de referncia um framework abstrato para entendimento dos relacionamentos 886
significantes entre as entidades e algum ambiente que habilite o desenvolvimento de 887
arquiteturas especficas usando padres consistentes ou especificaes que suportem este 888
ambiente. 889
Um modelo de referncia consiste de um conjunto mnimo de conceitos unificados, axiomas e 890
relacionamentos com um domnio de problema particular, e independente de padres 891
especficos, tecnologias, implementaes , ou outro detalhe concreto. Ver seo 1.1. 892
Oferta (offer) 893
Um convite ao uso das competncias que esto disponveis em um provedor de servio de 894
acordo com algum conjunto de polticas. 895
Poltica (policy) 896
Um tratado de obrigaes, restries ou outras condies de uso de uma entidade proprietria 897
como definida por um participante. Ver seo 3.3.2. 898

Provedor de Servio (service provider) 899
Uma entidade (pessoa ou organizao) que oferece o uso de competncias por meios de um 900
servio. 901
Semntica (semantics) 902
Uma conceitualizao do significado implcito da informao, que requer palavras e/ou 903
smbolos em um contexto de uso. Ver seo 3.2.2.1.2. 904
Servio (service) 905
O meio pelo qual as necessidades de um consumidor se compatibilizam com as competncias 906
de um provedor. Ver seo 3.1. 907
Visibilidade (visibility) 908
A capacidade para aqueles que necessitam e para aqueles com competncias a estar apto a 909
interagirem entre si. Ver seo 3.2.1. 910
_______________________________________________________________________________
B. Agradecimentos 911
As pessoas a seguir eram membros do comit durante o desenvolvimento desta especificao e aos 912
quais fica expressa a gratido com este reconhecimento. 913
Participantes: 914
Christopher Bashioum, Mitre Corporation 915
Prasanta Behera, Individual Member 916
Kathryn Breininger, The Boeing Company 917
Rex Brooks, HumanMarkup.org, Inc. 918
Al Brown, FileNet Corporation 919
Peter F Brown, Individual Member 920
Joseph Chiusano, Bozz Allen Hamilton 921
David Ellis, Individual Member 922
Robert S. Ellinger, Northrop Grumman Corporation 923
Jeff Estefan, Jet Propulsion Laboratory 924
Don Flinn, Individual Member 925
Steve Jones, Capgemi 926
Gregory Kohring, NEC Europe Ltd. 927
Ken Laskey, Mitre Corporation 928
C. Matthew MacKenzie (secretaria), Adobe Systems 929
Francis McCabe (secretaria), Fujtisu Laboratories of America Ltd. 930
Wesley McGregor, Treasury Board of Canada, Secretariat 931
Tom Merkle, Lockheed Martin Information Tecnology 932
Rebekah Metz, Booz Allen Hamilton 933
Oleg Mikulinsky, WebLayers, Inc. 934
Jyoti Namjoshi, Patni Computer Systems, Ltd. 935
Duane Nickull (chair), Adobe Systems 936
George Ntinolazos, Strata Software Ltd. 937
Joseph Pantella, Individual Member 938
Ron Schuldt, Lockheed Martin 939
Michael Stiefel, Reliable Software, Inc. 940
Danny Thornton, Individual Member 941
Michal Zaremba, Digital Enterprise Research Institute 942

Soa RM CSBR PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Soa RM CSBR PDF

Enviado por

Direitos autorais:

Formatos disponíveis

soa-rm-csbr 19 de Julho de 2006

Copyright OASIS Open 2005-2006. All Rights Reserved.

Você também pode gostar