Modelo de Referência para Arquitetura Orientada A Serviço 1.0 OASIS

_______________________________________________________________________________
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 Localizao: http://www.pcs.usp.br/~pcs5002/oasis/soarm-csbr.pdf Identificao do documento original: soa-rm-cs Localizao do documento original: http://www.oasisopen.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.oasisopen.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.
soa-rm-csbr Copyright OASIS Open 2005-2006. All Rights Reserved.
19 de Julho de 2006
_______________________________________________________________________________
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 Localizao: http://www.pcs.usp.br/~pcs5002/oasis/soarm-csbr.pdf Identificao do documento original: soa-rm-cs Localizao do documento original: http://www.oasisopen.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.oasisopen.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.
19 de Julho de 2006 Pgina 1 de 33
_______________________________________________________________________________
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. 1.2. 1.3. 1.4. 1.5. 1.5.1. 1.6. 2. 2.1. 2.1.1. 2.2. 2.3. 3. O QUE UM MODELO DE REFERNCIA .......................................................................................... 1 UM MODELO DE REFERNCIA PARA ARQUITETURA ORIENTADA A SERVIO ..................................... 1 AUDINCIA ................................................................................................................................. 2 GUIA PARA USAR O MODELO DE REFERNCIA ................................................................................ 2 CONVENES DE NOTAO ......................................................................................................... 3 COMO INTERPRETAR OS MAPAS CONCEITUAIS .......................................................................... 3 RELACIONAMENTO COM OUTROS PADRES ................................................................................... 4 O QUE A ARQUITETURA ORIENTADA A SERVIO ........................................................................... 1 UM EXEMPLO TRABALHADO DE ARQUITETURA ORIENTADA A SERVIOS ...................................... 2 COMO A ARQUITETURA ORIENTADA A SERVIO DIFERENTE? ....................................................... 3 OS BENEFCIOS DA ARQUITETURA ORIENTADA A SERVIO ............................................................. 4
A ARQUITETURA ORIENTADA A SERVIO ................................................................................. 1
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. 5.
GUIA DE CONFORMIDADE ............................................................................................................ 1 REFERNCIAS ................................................................................................................................ 1 5.1. 5.2. NORMATIVA................................................................................................................................ 1 NO-NORMATIVA ........................................................................................................................ 1
A. GLOSSRIO ......................................................................................................................................... 1 B. AGRADECIMENTOS ............................................................................................................................ 1
_______________________________________________________________________________
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
1. Introduo
A noo de Arquitetura Orientada a Servio (SOA) tem recebido significante ateno da comunidade de projeto e desenvolvimento de software. O resultado desta ateno a proliferao de muitas definies conflitantes sobre SOA. Considerando que os padres arquiteturais SOA (ou arquiteturas de referncia) podem ser desenvolvidos para explicar e amparar um gabarito genrico suportando um SOA especfico, um modelo de referncia tem a inteno de oferecer um alto nvel de coisas comuns, com definies que podem ser aplicadas para todo o SOA.
1.1. O que um modelo de referncia

Um modelo de referncia um framework abstrato para entendimento dos relacionamentos significantes entre as entidades de algum ambiente. Ele habilita o desenvolvimento de arquiteturas especficas usando padres consistentes ou especificaes suportando aquele ambiente. Um modelo de referncia consiste de um conjunto mnimo de conceitos unificados, axiomas e relacionamentos com um domnio de um problema particular, e independente de padres especficos, tecnologias, implementaes, ou outro detalhe concreto. Como uma ilustrao do relacionamento entre um modelo de referncia e as arquiteturas que podem derivar de tal modelo, considere o que pode estar envolvido na modelagem que importante sobre o projeto de uma casa. No contexto de um modelo de referncia, conhecemos que conceitos tais como reas de refeio, reas de higiene e descanso so todos importantes para entender o que compreende uma casa. H relacionamentos entre estes conceitos, e restries sobre como eles so implementados. Por exemplo, pode haver separao fsica entre as reas de higiene e de refeio. O papel de uma arquitetura de referncia para projeto de uma casa pode ser identificar as solues abstratas para os problemas de projetar uma casa. Um padro genrico para projeto de casa, um que enderece as necessidades de seus ocupantes no sentido que, digamos, nada que seja banheiro, cozinha, corredores, e assim por diante uma boa base para uma arquitetura de referncia abstrata. O conceito de rea de refeio um conceito no modelo de referncia, uma cozinha a realizao de rea de refeio no contexto de arquitetura de referncia. Pode haver mais de uma arquitetura de referncia que trate de como projetar uma casa, por exemplo, pode haver uma arquitetura de referncia que aborde os requisitos para desenvolvimento de solues para projeto de casas em grandes complexos de apartamentos, outro para tratar de casas para uma nica famlia no subrbio, e outra para espaos pblicos. No contexto de alta densidade de residncias, no deve haver uma cozinha separada, mas um espao de cozinha compartilhada ou ainda uma cozinha comum usada por muitas famlias. Uma real ou concreta arquitetura pode introduzir elementos adicionais. Ela pode incorporar estilos arquiteturais particulares, arranjos particulares de janelas, materiais de construo a serem usados e assim por diante. Uma planta de uma casa em particular representa uma instanciao de uma arquitetura como ela aplicada para a construo de uma moradia real. O modelo de referncia para projeto de casas , portanto, formado por trs nveis de abstraes independentes de uma entidade fsica que possa viver ali. O propsito de um modelo de referncia oferecer um framework conceitual comum que possa ser usado consistentemente atravs e entre diferentes implementaes e uso particular na modelagem de solues especficas.
1.2.
Um Modelo de Referncia para Arquiteturas Orientada a Servio
O objetivo deste modelo de referncia definir a essncia da arquitetura orientada a servio, e propor um vocabulrio e um entendimento comum de SOA. Ele oferece uma referncia normativa que permanece relevante para SOA como um modelo abstrato e poderoso, independente das vrias inevitveis evolues tecnolgicas que venham a influenciar a realizao de SOA. A Figura 1 mostra como um modelo de referncia para SOA se relaciona s outras entradas de arquiteturas de sistemas distribudos. Os conceitos e relacionamentos definidos pelo modelo de referncia tm a inteno de ser base para descrio de arquiteturas de referncias e padres que definem as categorias mais especficas de projetos SOA. As arquiteturas concretas vm de uma
19 de Julho de 2006
50 51 52 53 54 55 56 57 58 59
combinao de arquiteturas de referncia, padres de arquitetura e requisitos adicionais, incluindo aqueles impostos pelos ambientes tecnolgicos. A arquitetura precisa considerar as metas, motivaes e requisitos que definem os problemas reais que esto sendo estudados. Enquanto arquiteturas de referncias podem formar as bases de classes de solues, as arquiteturas concretas iro definir abordagens de solues especficas. A arquitetura freqentemente desenvolvida no contexto de um ambiente pr-definido, como os protocolos, perfis, especificaes, e padres que so pertinentes. As implementaes SOA combinam todos estes elementos, do princpio arquitetural mais genrico e infra-estrutura at o especfico que define as necessidades atuais, e representa implementaes especficas que sero construdas e usadas em um ambiente operacional.
Abstrato Modelo de Referncia
guiado por
Requisitos
conta
Arquiteturas de Referncia
para
Padres
considera
Protocolos Perfis Especificaes
Motivao
deriva
Metas Entrada
conta para
Arquiteturas Concretas
Modelos relacionados
Padres Trabalhos relacionados

usa
Trabalho de Arquitetura
restries de
Concreto
Implementaes da Arquitetura Orientada a Servio
60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 Figura 1 Como o Modelo de Referncia relaciona-se com os outros trabalhos
1.3.
Audincia
Os arquitetos e projetistas desenvolvedores, identificando ou desenvolvendo um sistema
A audincia pretendida para este documento inclui de forma no exaustiva: baseado no paradigma orientado a servio.
Os arquitetos de padres e analistas desenvolvendo especificaes que trabalhem com os
conceitos de arquitetura orientada a servio. arquiteturas orientadas a servio. arquitetura orientada a servio.
Os tomadores de deciso que procuram uma consistente e comum compreenso das Os usurios que necessitam de um melhor entendimento dos conceitos e benefcios da
1.4.
Guia para usar o modelo de referncia
Os novos leitores so encorajados a lerem este modelo de referncia por completo. Os conceitos so apresentados em uma ordem que os autores esperam promover um entendimento rpido.
75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106
Esta seo introduz as convenes, define a audincia e configura o cenrio para o resto do documento. Os leitores no tcnicos so encorajados a lerem estas informaes que oferecem um suporte material necessrio para entender a natureza e uso dos modelos de referncia. A seo 2 introduz o conceito de SOA e identifica algumas formas onde ele diferente do paradigma anterior, o sistema distribudo. A seo 2 oferece um guia sobre os princpios bsicos da arquitetura orientada a servios. Isto pode ser usado por leitores no tcnicos para ganhar uma compreenso explicita sobre os princpios centrais do SOA e por arquitetos como um guia para desenvolvimento de arquiteturas especficas orientadas a servio. A seo 3 introduz o Modelo de Referncia SOA. Em qualquer framework rico como o SOA, difcil evitar uma quantidade significativa de referncias cruzadas entre conceitos. Isto torna a apresentao do material sujeito a certa dose de arbitrariedade. Resolvemos isto pela introduo do prprio conceito de servio, e ento introduzimos os conceitos relacionados aos aspectos dinmicos de servio e finalmente introduzimos aqueles conceitos que se referem aos aspectos de nvel-meta de servios como a descrio do servio e as polticas que so aplicadas aos servios. A seo 4 trata da aderncia a este modelo de referncia. O glossrio oferece definies de termos que so pertinentes especificao do modelo de referncia, mas no parte necessria da especificao. Os termos que so definidos no glossrio so escritos em negrito quando de sua primeira ocorrncia no documento. Note que enquanto os conceitos e os relacionamentos descritos neste modelo de referncia podem ser aplicados a outros ambientes de servio, as definies e as descries contidas aqui enfocam o campo de arquitetura de software e chamam a ateno para no us-lo por completo fora do domnio de software. Os exemplos includos neste documento que so emprestados de outros domnios so usados estritamente para fins ilustrativos.
1.5.
Convenes de notao
As palavras chaves DEVEM, NO DEVEM, REQUERIDO, PODE, NO PODE, PODERIA, NO PODERIA, RECOMENDADO, MAY (PODE), e OPCIONAL so interpretadas neste documento como descritas na [RFC2119]. As referncias so colocadas entre colchetes [entre colchetes e texto em negrito].
1.5.1. Como interpretar os mapas conceituais

Os mapas conceituais so usados neste documento. No h uma conveno normativa para interpretao dos mapas conceituais alm da descrita aqui, nenhuma informao detalhada pode ser derivada destes mapas conceituais.
Conceito
107 108 109 110 111 112 113 114 Figura 2 Um mapa conceitual bsico
Conceito
Como usado neste documento, uma linha entre dois conceitos representa um relacionamento, onde o relacionamento no rotulado mas ao invs disto descrito no texto imediatamente precedente ou seguinte figura. A seta na linha indica um relacionamento assimtrico, onde o conceito para o qual a seta aponta (Conceito 2 na Figura 2) pode ser interpretado como dependente de alguma forma do conceito no qual a linha origina (Conceito 1). O texto que acompanha cada grfico descreve a natureza de cada relacionamento.
115 116 117 118 119 120 121 122 123
1.6.
Relacionamento com outros padres
Devido a sua natureza, este modelo de referncia pode ter um relacionamento significativo com qualquer destes grupos que:
Considere seu trabalho orientado a servio; Faz (publica) uma declarao de adoo para uso do Modelo de Referncia para SOA como
base ou inspirao para seu trabalho; e
Os padres ou tecnologias que se enquadram como orientados a servios.
O modelo de referncia no endossa nenhuma arquitetura particular orientada a servio, ou atesta a validade de modelos de referncia de terceiros.
_______________________________________________________________________________
124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173
2. A arquitetura orientada a servio

2.1. O que a arquitetura orientada a servio
A Arquitetura Orientada a Servio (SOA) um paradigma para organizao e utilizao de competncias distribudas que esto sob controle de diferentes domnios proprietrios. Em geral, as entidades (pessoas e organizaes) criam competncias para resolver ou suportar uma soluo para problemas que encontram no decorrer de seus negcios. natural pensar que as necessidades das pessoas podem ser compatveis com as competncias oferecidas por algum; ou, em outras palavras no mundo da computao distribuda, um requisito de um agente computador pode ser compatvel com o de outro pertencente a outro proprietrio. No h necessariamente uma correlao de um para um entre as necessidades e as competncias; a granularidade das necessidades e competncias variam do fundamental ao complexo, e qualquer necessidade dada pode requerer a combinao de numerosas outras competncias enquanto uma nica competncia pode tratar mais de uma necessidade. O valor percebido do SOA que ele oferece um framework poderoso para compatibilizar essas necessidades e competncias e para combinar competncias para tratar aquelas necessidades. A visibilidade, interao e efeitos so os conceitos chaves para descrever o paradigma SOA. A visibilidade refere-se capacidade para aqueles com necessidades e aqueles com competncias estarem aptos a se verem mutuamente. Isto tipicamente feito pelo oferecimento de descries acerca destes aspectos como as funes e requisitos tcnicos, restries e polticas relacionadas, e mecanismos para acesso e resposta. As descries precisam estar em um formulrio (ou podem ser transformadas em um formulrio) no qual sua sintaxe e semnticas so amplamente acessveis e compreensveis. Enquanto a visibilidade introduz a possibilidade de compatibilizar as necessidades com as competncias (e vice-versa), a interao a atividade que usa a competncia. Tipicamente mediada por troca de mensagens, uma interao prossegue atravs de uma srie de aes de troca de informaes e invocaes. H muitas facetas da interao; mas elas esto todas ligadas a um contexto de execuo particular o conjunto de elementos tcnicos e de negcios que formam um caminho entre aqueles com as necessidades e aqueles com as competncias. Isto permite que os provedores de servios e os consumidores interajam e ofeream um ponto de deciso para quaisquer polticas e contratos que estejam em vigor. O propsito de usar as competncias realizar um ou mais efeitos no mundo real. Como principal, uma interao um ato em oposio um objeto e o resultado de uma interao um efeito (ou um conjunto/srie de efeitos). Este efeito pode ser o retorno de uma informao ou a mudana no estado de entidades (conhecidas ou desconhecidas) que esto envolvidas na interao. Cuidadosamente distinguimos entre aes pblicas e aes privadas; aes privadas so inerentemente desconhecidas pela outra parte. Por outro lado, aes pblicas resultam em mudanas no estado que compartilhado no mnimo entre aqueles envolvidos no contexto de execuo atual e possivelmente para aqueles que compartilham este estado. Os efeitos no mundo real so, ento, expressos em termos das mudanas deste estado compartilhado. Os efeitos esperados no mundo real formam uma importante parte da deciso quando uma dada competncia compatibiliza em similaridade com a necessidade descrita. No cenrio de interao, a descrio dos efeitos no mundo real estabelece as expectativas para aqueles que usam as competncias. Note que, no possvel descrever todos os efeitos do uso de uma competncia. A pedra fundamental do SOA que podemos usar as competncias sem necessitar conhecer todos os seus detalhes. Esta descrio do SOA tem ainda que mencionar o que usualmente considerado o conceito central: o servio. O nome servio definido no dicionrio como O desempenho de trabalho (uma funo) por algum para outro. Contudo, servio, como o termo geralmente entendido, tambm combina as idias relacionadas com:
A competncia de executar o trabalho para outro
19 de Julho de 2006
174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225
A especificao do trabalho oferecido para outro A oferta para executar trabalho para outro
Estes conceitos enfatizam uma distino entre a competncia e a habilidade para trazer esta competncia para produzir. Enquanto as necessidades e as competncias existem independentemente do SOA, no SOA, os servios so o mecanismo pelo qual as necessidades e as competncias so colocadas juntas. SOA um meio para organizar as solues que promovem o reuso, crescimento e interoperabilidade. No ele prprio uma soluo para os problemas do domnio, mas ao invs disto um paradigma para organizao e entrega que habilita algum ter mais valor a partir do uso das competncias que so localmente prprias e aquelas sob controle de outros. Ele tambm habilita algum expressar as solues de uma maneira que a torna fcil de modificar ou desenvolver a soluo identificada ou tentar solues alternativas. O SOA no oferece nenhum elemento de domnio de uma soluo que no exista sem o SOA. Note que enquanto um servio SOA compatibiliza as necessidades e competncias, o provedor da competncia subjacente pode no ser a mesma entidade que eventualmente oferece o servio que acessa aquela competncia. Na realidade, a entidade com expertise de domnio para criar, manter, e evoluir uma dada competncia pode no ter a expertise ou o desejo de criar, manter, e evoluir o acesso a seus servios. Os conceitos de visibilidade, interao, e efeitos se aplicam diretamente para servios da mesma maneira como est descrita para o paradigma SOA em geral. A visibilidade promovida atravs da descrio do servio que contm as informaes necessrias para interagir com o servio e descreve isto em tais termos como entradas, sadas e semnticas associadas ao servio. A descrio do servio tambm comunica o que est consumado quando o servio invocado e as condies para usar o servio. Em geral, as entidades (pessoas e organizaes) oferecem competncias e atuam como provedores de servio. Aqueles com necessidades que fazem uso dos servios so referenciados como consumidores de servio. A descrio do servio permite que os consumidores prospectivos decidam se o servio conveniente para suas necessidades atuais e estabelece quando um consumidor satisfaz todos os requisitos do provedor de servio. (Nota, os provedores de servios e os consumidores de servio so algumas vezes referenciados conjuntamente como participantes do servio.). Na maioria das discusses sobre SOA, os termos acoplamento fraco e granularidade grossa so comumente aplicadas como conceitos SOA, mas estes termos no esto intencionalmente sendo usados na atual discusso por que eles so comprometimentos subjetivos e sem mtricas satisfatrias. Em termos de necessidades e competncias, granularidade e a no granularidade so usualmente relativas ao nvel de detalhe para o problema que se est tratando, por exemplo, um que seja mais estratgico versus outro que desa no nvel de algoritmo, e definindo o nvel timo no est suscetvel a contagem do nmero de interfaces ou o nmero ou tipo de informaes trocadas conectadas a uma interface. Note que embora o SOA seja comumente implementado usando Web Services, os servios podem ser visveis, suportar interaes, e gerar efeitos atravs outras estratgias de implementao. As arquiteturas e as tecnologias baseadas em Web Services so especficas e concretas. Enquanto os conceitos no Modelo de Referncia se aplicam a estes sistemas, os Web Services so tambm solues especficas a serem parte de um modelo de referncia genrico.
2.1.1. Um exemplo trabalhado de Arquitetura Orientada a Servios

Uma empresa de eletricidade tem a capacidade de gerar e distribuir eletricidade (capacidade subjacente). A fiao da rede de distribuio da companhia eltrica (o servio) oferece o meio para fornecer eletricidade para suportar o uso por um consumidor residencial tpico (funcionalidade do servio), e um consumidor acessa a eletricidade gerada (a sada da invocao de servio) via uma tomada de parede (interface de servio). De forma a utilizar a eletricidade, um consumidor precisa entender que tipo de plug usar, qual a voltagem fornecida, e quais os possveis limites de carga; a empresa presume que o consumidor ir conectar
226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276
somente aparelhos adequados voltagem ofertada e a carga suportada; e o consumidor por sua vez assume que os aparelhos adequados podem ser conectados sem danos ou riscos (suposies tcnicas do servio). Um usurio residencial ou comercial precisa abrir uma conta na empresa para usar o fornecimento (restrio de servio) e a empresa ir medir o consumo e espera que o consumidor pague pela energia conforme taxa prevista (poltica de servio). Quando o consumidor e a empresa concordam nas restries e polticas (contrato de servio), o consumidor pode ter o fornecimento de eletricidade usando o servio desde que a rede de distribuio de eletricidade e a conexo residencial permaneam intactas (por ex. uma tempestade que derrube a rede e interrompa o fornecimento) e o consumidor pode pagar (por exemplo, transferncia eletrnica de fundos) a empresa (acessibilidade). Outra pessoa (por ex. um visitante a uma casa de algum) pode usar um fornecedor contratado sem qualquer relacionamento com a empresa e qualquer requisio para tambm satisfazer as restries iniciais de servio (i.e. a acessibilidade somente requer a distribuio de eletricidade sem problemas), mas pode ser esperado ser compatvel com a interface de servio. Em certas situaes (por ex. demanda excessiva), uma empresa pode limitar o fornecimento ou instituir cortes rotativos (polticas de servio). Um consumidor pode guardar uma aceitao formal se isto ocorre freqentemente (poltica implcita do consumidor). Se a empresa requer que cada aparelho seja firmemente ligado aos seus equipamentos, a capacidade subjacente pode ainda estar l, mas isto pode ser um servio diferente e ter uma interface de servio diferente.
2.2.
Como a Arquitetura Orientada a Servio diferente?
Diferentemente do paradigma de Programao Orientada a Objeto, onde o foco est no empacotamento de dados com operaes, o foco central da Arquitetura Orientada a Servio a tarefa ou funo de negcio obtendo alguma coisa feita. Esta distino se manifesta de diferentes formas:
A OO tem a inteno de unir os mtodos a um dado objeto de dados. Os mtodos podem ser
pensados como uma propriedade do objeto. Para o SOA, pode-se pensar os servios como tendo acesso aos mtodos, mas a real existncia dos mtodos e qualquer conexo com os objetos incidental. servio onde ele existe.
Para usar um objeto, ele precisa primeiro ser instanciado enquanto ele interage com um Um objeto expe a estrutura, mas no h maneira de expressar a semntica a no ser
capturando como comentrio na definio da classe. O SOA enfatiza a necessidade de clarificar a semntica.
Ambos, a OO e o SOA so como formas de pensar sobre representao de coisas e aes no mundo referindo-se especificamente sobre a construo de sistemas. A coisa importante o entendimento e aplicao do paradigma. Portanto a questo no o que um servio? muito mais que isto o que um objeto?. Qualquer coisa pode ser um servio da mesma forma que qualquer coisa pode ser um objeto. O desafio aplicar o paradigma para melhorar a clareza e obter as coisas feitas. O SOA oferece a base mais vivel para sistemas de grande escala por que ele se enquadra melhor na forma como as atividades humanas so gerenciadas por delegao. Como o paradigma SOA difere das outras abordagens para organizar e entender os recursos da Tecnologia da Informao? Essencialmente, h duas reas na quais ela difere e ambas moldam o framework de conceitos que reside nos sistemas distribudos. Primeiro, o SOA reflete a realidade que os limites da posse so uma considerao de motivao na arquitetura e projeto de sistemas. Este reconhecimento evidente nos conceitos centrais de visibilidade, interao e efeito. Contudo, o SOA no trata de todos os conceitos associados com a posse, domnio de posse e aes comunicadas entre pontos legais. Para contabilizar totalmente os conceitos tais como confiana,
277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308
transaes de negcio, autoridade, delegao e assim por diante um framework conceitual adicional e elementos arquiteturais so requeridos. No contexto do SOA, estes so representados e referenciados como descries de servio e interface de servio. A presena das descries de servio e interface de servio oferece uma pronta localizao para incluso de tal referencia e ento facilita o reuso do framework desenvolvido externamente e a interoperabilidade entre sistemas disponibilizando-os para este reuso. Segundo, o SOA aplica a lio aprendida com o comrcio na organizao dos recursos de TI para facilitar a compatibilizao das competncias e necessidades. Que duas ou mais entidades que esto juntas no contexto de uma nica interao implica a troca de algum tipo de valor. Essa a mesma base fundamental como o prprio comrcio, e sugere que como o SOA evolui a partir das interaes definidas de uma maneira ponto-a-ponto para um mercado de servios; a tecnologia e os conceitos podem expandir com sucesso como o mercado comercial.
2.3.
Os benefcios da Arquitetura Orientada a Servio
Os principais motivos para a arquitetura baseada em SOA so para facilitar o gerenciamento do crescimento dos sistemas corporativos de larga escala, para facilitar o provisionamento da escalabilidade da Internet para uso por servios e reduzir custos nas organizaes para cooperao das organizaes. O valor do SOA que ele oferece um paradigma escalvel nico para organizar grandes sistemas em rede que requerem interoperabilidade para realizar o valor inerente aos componentes individuais. Certamente, o SOA escalvel por que ele faz a menor suposio possvel sobre a rede e tambm minimiza qualquer suposio de confiana que so freqentemente feitas em sistemas de escala menor. Um arquiteto usando os princpios do SOA mais bem equipado, conseqentemente, para desenvolver sistemas que so escalveis, evolutveis e gerenciveis. Pode ser fcil decidir como integrar as funcionalidades atravs dos limites proprietrios. Por exemplo, uma grande companhia adquire uma pequena companhia precisa determinar como integrar a infraestrutura de TI adquirida no portiflio global de TI existente. Atravs desta habilidade inerente para escalar e evoluir, o SOA habilita um portiflio de TI que tambm adaptvel para diferentes necessidades de um domnio de problema especfico ou arquitetura de processo. A infraestrutura que SOA incentiva tambm a mais gil e responsvel que aquela construda em um nmero exponencial de pares de interfaces. Conseqentemente, o SOA pode tambm oferecer uma slida fundao para agilidade nos negcios e adaptabilidade.
_______________________________________________________________________________
309 310 311
3. O Modelo de Referncia
A Figura 3 ilustra os principais conceitos definidos neste MODELO DE REFERNCIA. Os relacionamentos entre eles so desenvolvidos medida que cada conceito exposto.
Visibilidade
Contexto de Execuo
Descrio do Servio
Servio
Efeito no mundo real Contrato & Polticas

312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 Figura 3 Principais conceitos do Modelo de Referncia
Interao
3.1.
O Servio
Um servio um mecanismo para habilitar o acesso a um conjunto de uma ou mais competncias, onde o acesso provido usando uma interface que descrita e consistentemente exercitada com restries e polticas como especificados pela descrio de servio. Um servio oferecido por uma entidade o provedor de servio para uso pelos outros, mas os consumidores eventuais do servio podem no saber do provedor de servio e podem demonstrar o uso do servio alm do escopo original concebido pelo provedor. Um servio acessado por meio de uma interface de servio (veja seo 3.3.1.4) onde a interface inclui as especificidades do conhecimento para acessar as competncias subjacentes. No h restries no que constitui as competncias subjacentes ou como o acesso implementado pelo provedor. Ento, o servio pode ser executado como descrito na funcionalidade atravs de um ou mais processos automticos e/ou manuais que ele prprio invocar a outros servios disponveis. Um servio uma caixa preta por que sua implementao oculta do consumidor de servio exceto por: (1) os modelos de informao e comportamento so expostos atravs da interface de servio e (2) a informao requerida pelos consumidores de servio para determinar quando um dado servio apropriado para suas necessidades. A conseqncia da invocao de um servio a realizao de um ou mais efeitos no mundo real (ver seo 3.2.3). Estes efeitos podem incluir: 1 a informao retornada em resposta a uma requisio daquela informao, 2 uma mudana no estado compartilhado de entidades definidas, ou 3 alguma combinao de (1) e (2). Note que, o consumidor de servio em (1) tipicamente no sabe como a informao gerada, por exemplo, quando ela extrada de um banco de dados ou gerada dinamicamente; em (2), ele tipicamente no sabe como a mudana de estado afetada.
19 de Julho de 2006
338 339 340 341 342 343 344 345 346 347 348
O conceito de servio acima enfatiza a distino entre a competncia que representa alguma funcionalidade criada para enderear a necessidade e o ponto de acesso para trazer aquela competncia para o contexto do SOA. assumido que esta competncia existe fora do SOA. No uso real, manter esta distino no pode ser crtico (i.e. o servio pode ser pensado em termos de trazer a competncia), mas a separao pertinente em termos de uma expresso clara da natureza do SOA e do valor que ele oferece.
3.2.
As dinmicas dos Servios
Da perspectiva da dinmica de servio, h trs conceitos fundamentais que so importantes no entendimento do que est envolvido na interao com servios: a visibilidade entre provedores de servios e consumidores, e a interao entre eles, e os efeitos no mundo real da interao com um servio.
Visibilidade
Servio
Efeito no mundo real

349 350 351 352 353 354 355 356 357 Figura 4 - Conceitos acerca das dinmicas do servio
Interao
3.2.1. A Visibilidade
Para um provedor de servio e um consumidor interagirem entre si eles tem que estar aptos a se verem entre si. Isto verdade para qualquer relacionamento consumidor/provedor incluindo um programa aplicao onde um programa chama outro: sem que biblioteca apropriada esteja presente a funo no pode ser completada. No caso do SOA, a visibilidade necessita ser enfatizada por que no necessariamente bvio saber como os participantes podem se ver entre si.
Conscincia Concordncia Visibilidade
Acessibilidade Servio

357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 Figura 5 Conceitos ao redor de Visibilidade
Interao
A Visibilidade o relacionamento entre os consumidores e provedores de servio que satisfeito quando eles esto aptos a interagirem entre si. As pr-condies para visibilidade so conscincia, concordncia e acessibilidade. O iniciante numa interao de servio PRECISA ter a percepo dos outros parceiros, os participantes PRECISAM estar predispostos para uma interao, e os participantes PRECISAM estar aptos a interagir.
3.2.1.1. A Conscincia
Ambos, o provedor de servio e o consumidor de servio PRECISAM ter a informao que pode conduzi-los a conhecer a existncia dos outros. Tecnicamente, o primeiro requisito que o iniciante de uma interao de servio tenha conhecimento do respondente. O fato de uma iniciao bem sucedida freqentemente suficiente para informar ao respondente da existncia do outro. A conscincia o estado no qual uma parte tem conhecimento da existncia da outra parte. A conscincia no implica em concordncia ou acessibilidade. A conscincia do servio ofertada freqentemente afetada por muitos mecanismos de descoberta. Para um consumidor de servio descobrir um servio, o provedor de service precisa ser capaz de criar os detalhes do servio (notavelmente a descrio do servio e polticas) disponveis para consumidores em potencial; e consumidores precisam ser capazes de tomarem conhecimento desta informao. Em contrapartida, os provedores de servios podem precisar descobrir igualmente os consumidores e pode precisar tornar conhecimento da descrio do consumidor. A seguir, discutimos a conscincia em termos da visibilidade do servio, mas os conceitos so igualmente vlidos para a visibilidade do consumidor. A conscincia do servio requer que a descrio do servio e poltica ou pelo menos um subconjunto adequado estejam disponveis de tal maneira e de forma que, direta ou indiretamente, um consumidor potencial esteja ciente da existncia e das competncias do servio. A extenso para a qual a descrio empurrada pelo provedor de servios, e puxado por um consumidor em potencial, sujeito prova ou outro mtodo, que depende de muitos fatores. Por exemplo, um provedor de services pode anunciar e promover seus services pela incluso dele em um diretrio de services ou por difuso para todos os consumidores; consumidores potenciais podem difundir suas necessidades particulares de service na esperana que um service adequado responda com uma proposta ou oferta, ou um consumidor de service pode tambm percorrer uma rede inteira para determinar se o servio adequado existe. Quando a demanda para um servio mais alta que a fornecida, ento, pelo anncio de suas necessidades, os consumidores potenciais podem ser mais efetivos que os anncios dos provedores de servio oferecendo servios.
390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420
De uma forma ou outra, o consumidor potencial precisa adquirir as descries suficientes para avaliar quando um dos servios compatvel com suas necessidades, e ento disparar o mtodo para o consumidor interagir com o servio.
3.2.1.2. A Concordncia
Associado com todos os servios as interaes so intencionais um ato intencional iniciar e participar de uma interao de servio. Por exemplo, se um consumidor de servio descobre um servio via sua descrio em um registro, e o consumidor inicia uma interao, se o provedor de servio no coopera ento no pode haver interao. Em algumas circunstancias este precisamente o comportamento correto para um servio falhar na resposta por exemplo, esta a defesa clssica contra certos ataques para derrubar o servio. A extenso da concordncia dos participantes do servio para engajar em uma interao de servio pode estar sujeito a polticas. Estas polticas podem ser documentadas na descrio do servio. Com certeza, a concordncia da parte do provedor de servio e do consumidor para interagir no a mesma concordncia para executar as aes requeridas. Um provedor de servio que rejeita todas as tentativas para executar alguma ao pode ainda estar totalmente disponvel e engajado na interao com o consumidor.
3.2.1.3. A Acessibilidade
A acessibilidade o relacionamento entre participantes de servio onde eles esto aptos a interagir; possivelmente trocando informaes. A acessibilidade um pr-requisito essencial para a interao do servio os participantes PRECISAM estar aptos a ser comunicarem. Um consumidor de servio pode ter a inteno de interagir com um servio, e pode sempre ter todas as informaes necessrias para com ele. Contudo, se o servio no est alcanvel, por exemplo, se no h um caminho de comunicao entre o consumidor e o provedor, ento efetivamente, o servio no est visvel ao consumidor.
3.2.2. Interagindo com os Servios

A interao com o servio envolve a execuo de aes na direo do servio. Em muitos casos, isto realizado pelo envio e recebimento de mensagens, mas h outros modos possveis que no envolvem explicitamente a transmisso de mensagens. Por exemplo, uma interao de servio pode ser efetuada pela modificao do estado de um recurso compartilhado. Contudo, por simplicidade, freqentemente se refere troca de mensagens como modo primrio de interao com um servio.
Visibilidade Descrio do Servio
Modo de Ao Servio Modelo de Comportamento Modelo de Processo
Interao Efeito no mundo real
Modelo de Informao Semntica Estrutura
420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 Figura 6 Conceitos na interao de servio A figura 6 ilustra os conceitos chaves que so importantes no entendimento do que est envolvido numa interao de servios; isto gira ao redor da descrio do servio que referencia um modelo de informao e um modelo de comportamento.
3.2.2.1. O modelo de informao

O modelo de informao de um servio uma caracterizao da informao que pode ser trocada com o servio. Somente informao e dados que so potencialmente trocados com um servio so geralmente includos no modelo de informao do servio. O escopo do modelo de informaes inclui o formato da informao que trocada, os relacionamentos estruturais com a informao trocada e tambm a definio dos termos usados. Particularmente para informao que trocada atravs dos limites proprietrios, um importante aspecto do modelo de informao de servio a interpretao consistente das cadeias de caracteres (strings) e outros sinais (tokens) na informao. A extenso na qual um sistema pode efetivamente interpretar a informao de outro sistema governado pelo comprometimento semntico dos vrios sistemas. O comprometimento semntico de um sistema um relacionamento entre o sistema e a informao que ele pode ser encontrado. Isto altamente varivel e dependente da aplicao; por exemplo, um servio de encriptao interpreta todas as informaes como uma seqncia (stream) de bytes para realizar a encriptao e a decriptao, no entanto um servio de banco de dados pode tentar interpretar a mesma seqncia de informao em termos de requisies de consulta (query) e/ou modificar o banco de dados. Vagamente, algum pode particionar a interpretao de um bloco de informao em estrutura (sintaxe) e significado (semntica); contudo ambas so partes do modelo de informao.
3.2.2.1.1. A estrutura
Conhecer a representao, estrutura, e forma da informao requerida um passo inicial chave para assegurar efetiva interao com um servio. H muitos nveis desta informao estrutural; incluindo a codificao dos caracteres do dado, o formato dos dados e os tipos de dados estruturais associados com elementos da informao.
448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497
Um modelo informao descrita tipicamente tem um grande tratado para dizer acerca da forma das mensagens. Contudo, conhecer o tipo de informao no suficiente para descrever completamente a interpretao apropriada dos dados. Por exemplo, com uma estrutura de dados de endereo, o nome da cidade e o nome da rua so tipicamente do mesmo tipo de dados algumas variantes do tipo string. Contudo, os nomes de cidade e nomes de ruas no so realmente os mesmo tipos de coisa. Distinguir a correta interpretao de uma string de nome de cidade e uma string de nome de rua no possvel usando os tipos tcnicos bsicos requerida uma informao adicional que no pode ser expressa puramente em termos de estrutura de dados.
3.2.2.1.2. A Semntica
A tarefa primria de qualquer infra-estrutura de comunicao facilitar a troca de informaes e troca de intenes. Por exemplo, uma ordem de compra combina de certo modo dois aspectos ortogonais: a descrio dos itens da compra e o fato que uma das partes tem a inteno de comprar aqueles itens de outra parte. Mesmo para trocas que no ocorrem atravs do limite proprietrio, as trocas com servios tem aspectos similares. Especialmente nos casos onde as trocas so atravs dos limites proprietrios, uma questo critica a interpretao dos dados. Esta interpretao PRECISA ser consistente entre os participantes da interao do servio. A interpretao consistente um forte requisito mais que um mero tipo (ou estrutural) de consistncia os sinais nos prprios dados precisam ter tambm uma base compartilhada. Geralmente h um amplo potencial para a variabilidade na representao de endereos. Por exemplo, um endereo em So Francisco, Califrnia pode ter variaes na forma que a cidade representada: SF, San Francisco, San Fran, a cidade da Baa so alternativas que denominam a mesma cidade. Para a troca bem sucedida da informao de endereo, todos os participantes precisam ter uma viso consistente do significado dos sinais de endereo se a informao de endereo para ser compartilhada de maneira confivel. A descrio formal dos itens e o relacionamento entre eles (i.e., uma ontologia) oferecem uma base slida para a seleo da interpretao correta para os elementos da informao trocada. Por exemplo, uma ontologia pode ser usada para capturar as formas alternativas para expressar o nome da cidade bem como para distinguir um nome de cidade do nome de uma rua. Note que, para a maior parte, no esperado que o consumidor de servio e o provedor possam realmente trocar descries dos termos em suas interaes, mas ao invs disto, possam referenciar as descries existentes o papel da semntica ocorrendo de forma subjacente e estas referncias podem ser includas na descrio do servio. As semnticas de domnio especfico esto fora do escopo deste modelo de referencia; mas h um requisito que a interface de servio habilite os provedores e consumidores a identificarem-se sem ambigidade estas definies que so relevantes para os seus domnios.
3.2.2.2. O Modelo Comportamental

Um segundo requisito chave para interaes bem sucedidas com servios o conhecimento das aes envolvidas no servio e no processo ou aspectos temporais de uma interao com o servio. Isto caracterizado como conhecimento das aes sobre as respostas, e as dependncias temporais entre aes sobre o servio. Por exemplo, em um acesso controlado e seguro a um banco de dados, as aes disponveis para um consumidor de servio incluem a apresentao de credenciais, requisies de atualizaes de banco de dados e leituras de resultados de consultas. A segurana pode ser baseada em um protocolo provocao-resposta. Por exemplo, o iniciante apresenta um sinal inicial para identificar, a respondente apresenta uma provocao e o iniciante responde a provocao de uma maneira que satisfaz o banco de dados. Somente depois que as credenciais do usurio forem verificadas a ao ria relatar ao banco de dados para atualizar e a consulta ser aceita. A seqncia de aes envolvidas um aspecto critico do conhecimento requerido para o uso bem sucedido de um banco de dados seguro.
498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541
3.2.2.2.1. O Modelo de Ao
O modelo de ao de um servio a caracterizao das aes que podem estar envolvidas na direo do servio. Certamente, uma grande poro do comportamento resultante de uma ao pode ser privativa; contudo, a esperada viso pblica de um servio com certeza inclui a implicao dos efeitos da ao. Por exemplo, em um servio que gerencia uma conta bancaria, no suficiente conhecer o que se necessita trocar uma dada mensagem (com os sinais de autenticao apropriados), de forma a usar o servio. tambm necessrio entender que usando o servio pode realmente afetar o estado da conta (por exemplo, retirada de dinheiro); que dependncias esto envolvidas (por exemplo, uma solicitao de retirada precisa ser menor que o saldo da conta); ou que a mudana de dados efetuada tem valor diferente em diferentes contextos (por exemplo, mudana de dados em um lanamento bancrio no o mesmo que mudana dos dados reais que representam a quantia em uma conta).
3.2.2.2.2. O Modelo de Processo

O modelo de processo caracteriza o relacionamento temporal entre as propriedades temporais de aes e eventos associados com a interao com o servio. Note que embora o modelo de processo seja parte essencial deste Modelo de Referncia , sua extenso no est completamente definida. Alguns processos podem incluir aspectos que no so estritamente parte do SOA por exemplo, neste Modelo de Referncia no tratamos da orquestrao de mltiplos servios, embora a orquestrao e coreografia possam ser partes do modelo de processo. No mnimo, o modelo de processo PRECISA cobrir as interaes com o prprio servio. Alm do mecanismo direto de interao com um servio h outros, de ordem mais alta, que so importantes como o modelo de processo dos atributos dos servios. Este pode incluir se o servio idempotente, se o servio de longa durao por natureza e se importante contabilizar para qualquer aspecto transacional do servio.
3.2.3. O Efeito no Mundo Real

Sempre h um propsito particular associado com a interao com um servio. Inversamente, um provedor de servio (e um consumidor) freqentemente tem condies que a priori se aplicam a suas interaes. O consumidor de servio est tentando alcanar algum resultado com o uso do servio, da mesma forma o provedor de servio. Numa primeira vista, tal objetivo pode ser expresso como tente obter o servio para fazer alguma coisa. Isto algumas vezes conhecido como os efeitos no mundo real pelo uso do servio. Por exemplo, um servio de reserva de uma empresa area pode ser usado para aprender sobre os vos disponveis, procura de assentos e por fim agendar uma viagem o efeito desejado no mundo real ter um assento no vo certo. Como discutido na Seo 3.1, um efeito no mundo real pode ser a resposta a uma requisio de informao ou a troca de estado de alguma entidade definida compartilhada pelos participantes do servio. Neste contexto, o estado compartilhado no precisa necessariamente se referir a variveis de estado especficas que so salvas em um meio fsico de armazenamento mas ao invs disto representa a informao compartilhada sobre as entidades afetadas. Assim no exemplo da reserva na companhia area, o estado compartilhado que h um assento reservado em um determinado vo representa um entendimento comum entre um futuro passageiro e a empresa area. Os detalhes da real mudana de estados quer da parte do passageiro (por exemplo disponibilidade de saldo para pagar a passagem) ou a empresa area (Poe exemplo que um assento vendido para aquele vo) no so compartilhados com os outros.
Visibilidade
Estado compartilhado
Servio

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

571 572 573 574 575 576 577 578 579 580 Figura 8 Sobre servio
3.3.1. Descrio de Servio

Uma das garantias de qualidade do SOA a grande quantidade de documentao e descrio associada a ele. A descrio do servio representa a informao necessria de forma a usar um servio. Na maioria dos casos, no h uma descrio certa, mas ao invs disto, os elementos da descrio requerida dependem do contexto e das necessidades das partes que usam a entidade associada. Enquanto h certos elementos que so como parte de qualquer descrio de servio, mais notavelmente o modelo de informao, muitos elementos tais como uma funo e uma poltica podem variar.
Visibilidade
Acessibilidade
Descrio do servio
Servio Interface do servio Efeito no mundo real Funcionalidade Interao
Contrato & Polticas

581 582 Figura 9 Descrio do servio
Modelo de informao
Modelo comportamental
583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631
O propsito da descrio facilitar a interao e a visibilidade, particularmente quando os participantes esto em domnios proprietrios diferentes, entre participantes na interao de servio. Pelo oferecimento da descrio, ela torna possvel a potenciais participantes construir sistemas que usam servios e at mesmo oferece servios compatveis. Por exemplo, as descries permitem que os participantes discriminem entre possveis escolhas para interao de servio; como se o servio oferecido requer competncias, como acessar o servio, e negociar sobre as funcionalidades especficas de servio. Ainda mais, as descries podem ser usadas para suportar e gerenciar servios, ambos sob a perspectiva do provedor de servio e sob a perspectiva do consumidor de servio. As melhores prticas sugerem que a descrio do servio DEVE ser representada usando um padro, um formato referencivel. Tal formato facilita o uso de ferramentas de processamento comuns (tais como os engines de pesquisa) que pode trabalhar sobre a descrio de servio. Enquanto o conceito de SOA suporta o uso de um servio sem o consumidor de servio necessitar conhecer os detalhes da implementao do servio, a descrio do servio torna disponveis informaes criticas que o consumidor necessita de forma a decidir se usa ou no o servio. Em particular, um consumidor de service necessita possuir os seguintes itens de informaes: 1. 2. 3. 4. 5. Que o servio existe e est acessvel; Que o servio executa certa funo ou conjunto de funes; Que o servio opera sob um conjunto especfico de restries e polticas; Que o servio ir (para alguma extenso implcita ou explicita) concordar com as polticas como prescritas pelo consumidor do servio; Como interagir com o servio de forma a alcanar os objetivos desejados, incluindo o formato e contedo da informao trocada entre o servio e o consumidor e as seqncias de informaes trocadas que podem ser esperadas.
Enquanto cada um desses itens DEVE ser representado em qualquer descrio de servio, os detalhes podem ser includos atravs de referncias (links) para fontes externas e so NO REQUERIDOS para serem incorporados explicitamente. Isto habilita o reuso das definies padres, tais como para as funcionalidades ou polticas. Outra seo deste documento trata desses aspectos de um servio, mas a seguinte subseo discute elementos importantes como estes relacionados com a prpria descrio do servio.
3.3.1.1. Acessibilidade do Servio

A acessibilidade inerente ao relacionamento de partes entre os provedores e consumidores de servio. Contudo, a descrio de um servio DEVE incluir dados suficientes para habilitar um consumidor de servio e um provedor de servio a interagirem entre si. Isto PODE incluir metadados como a localizao do servio e o qual protocolo de informao ele suporta e requer. Ela PODE tambm incluir a informao dinmica sobre o servio, como se ele est atualmente disponvel.
3.3.1.2. Funcionalidades do Servio

Uma descrio do servio DEVE expressar de forma no ambgua a funo(s) do servio e os efeitos no mundo real (ver seo 3.2.3) que resultam de sua invocao. Esta poro da descrio DEVE ser expressa de maneira que seja geralmente compreendida pelos consumidores de servio mas apta a acomodar um vocabulrio que seja suficientemente expressiva para o domnio para o qual o servio oferece suas funcionalidade. A descrio da funcionalidade pode incluir, entre outras possibilidades, uma descrio textual para consumo pelos humanos ou identificadores ou palavras chaves referentes s definies especficas para mquinas de processamento. Para uma descrio completa, PODE ser indicado identificadores mltiplos ou palavras chaves extradas de um nmero de colees diferentes de definies. Parte da descrio da funcionalidade pode incluir suposies tcnicas subjacentes que determinam os limites da funcionalidade exposta pelo servio ou as competncias subjacentes. Por exemplo, a quantidade de dinheiro dispensada por um caixa automtico (ATM) consistente com a suposio que
632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676
o usurio um indivduo e no um negcio. Para usar o caixa automtico, o usurio precisa no apenas aderir s polticas e satisfazer as restries da instituio financeira associada (ver seo 3.3.1.3 para saber como ele se relaciona com a descrio do servio e a seo 3.3.2 para uma discusso mais detalhada) mas o usurio est sujeito a limitaes de retirada de dinheiro fixado a uma certa quantia e a um certo nmero de transaes em um perodo de tempo especificado. A instituio financeira, como competncia subjacente, no tem esses limites mas a interface de servio que exposta aos consumidores tem essas limitaes, consistente com a suposio das necessidades do usurio em questo. Se a suposio no vlida, o usurio pode necessitar usar outro servio para acessar esta competncia.
3.3.1.3. Polticas Relacionadas com um Servio

Uma descrio de servio PODE incluir suporte para polticas associadas com um servio e oferecer a informao necessria para os consumidores prospectivos avaliarem se um servio ir atuar de uma maneira consistente com as restries do consumidor.
3.3.1.4. A interface do Servio

A interface de servio o meio para interao com o servio. Ela inclui os protocolos especficos, comandos, e troca de informaes pelas aes so iniciadas e que resultam em efeitos no mundo real como especificado atravs da poro de funcionalidade do servio da descrio do servio. As especificidades da interface PRECISAM ser sintaticamente representadas em um formato padro referencivel. Este prescreve que informaes so necessrias serem providas ao servio de forma a acessar suas competncias e interpretar suas respostas. freqentemente referida como modelo de informao de servio, ver seo 3.2.2.1. Deve ser notado que as particularidades do formato da interface esto fora do escopo deste modelo de referncia. Contudo, a existncia das interfaces e as descries de acessibilidade destas interfaces so fundamentais para o conceito SOA. Enquanto esta discusso refere-se a uma sintaxe referencivel padro para descrio de servio, no especificado como o consumidor acessa a definio da interface nem como o prprio servio acessado. Contudo, assumido que para o servio ser utilizvel, sua interface PRECISA ser representada em um formato que permita a interpretao da informao da interface por seus consumidores.
3.3.1.5. Os limites da Descrio

So bem conhecidos os limites tericos da efetividade da descrio simplesmente no possvel especificar, completamente e sem ambigidade, a semntica precisa de servio bem como toda a informao relacionada a ele. Sempre haver suposies no estabelecidas feitas pelo relator do servio que precisam ser implicitamente compartilhadas pelos leitores da descrio. Isto se aplica s descries de mquinas de processamento bem como s descries lidas por humanos. Felizmente, uma preciso completa no necessria o que requerido tem o escopo e a preciso suficiente para suportar a inteno de uso pretendida. Outro tipo de limite das descries de servio mais direto: sempre que um repositrio pesquisado usando qualquer tipo de consulta h sempre o potencial de zero ou mais respostas no importando quo completo a consulta seja ou quo completa as descries disponveis possam ser. Isto inerente aos princpios envolvidos na pesquisa. No caso em que h mais de uma resposta, este conjunto de respostas tem que ser convertido em uma simples escolha. Isto uma escolha privativa que precisa ser feita pelo consumidor da informao pesquisada.
676 677 678 679 680 681 682 683
3.3.2. Polticas e Contratos

Uma poltica representa alguma restrio ou condio sobre o uso, distribuio ou descrio de uma entidade prpria com definida por qualquer participante. Um contrato, por outro lado, representa um acordo de duas ou mais partes. Assim como as polticas, acordos so tambm sobre as condies de uso de um servio; ele pode tambm restringir os efeitos esperados no mundo real ao usar o servio. O modelo de referncia focado primariamente em conceitos de polticas e contratos e como eles se aplicam ao servio. No estamos nos referindo a forma ou expressividade de qualquer linguagem usada para expressar as polticas e contratos.
Contexto de execuo Servio
Descrio do servio
Imposio Afirmao Contrato & Polticas
Proprietrio da Poltica
684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 Figura 10 Polticas e Contratos
Partes em acordo
3.3.2.1. Poltica de Servio

Conceitualmente, h trs aspectos de polticas: a poltica de afirmao, a poltica do proprietrio (algumas vezes referidas como polticas de assunto) e poltica de obrigao. Por exemplo, a afirmao: Todas as mensagens so criptografadas uma afirmao que independe da forma das mensagens. Como uma afirmao, ela mensurvel: ela pode ser verdadeira ou falsa dependendo se o trfego est encriptado ou no. Polticas de afirmao so freqentes sobre a forma como o servio realizado; i.e., elas tratam do relacionamento entre o servio e seu contexto de execuo, (ver seo 3.3.3). Uma poltica sempre representa um ponto de vista de um participante. Uma afirmao se torna a poltica de um participante quando eles adotam a afirmao como sua poltica. Esta ligao no parte da prpria afirmao. Por exemplo, se o consumidor do servio declara que Todas as mensagens so criptografadas, ento isto reflete a polticas do consumidor de servio. Esta poltica uma que pode ser afirmativa para o consumidor de servio independente de qualquer acordo com o provedor de servio. Finalmente, uma poltica pode ser impositiva. As tcnicas para as polticas impositivas dependem da natureza da poltica. Conceitualmente, as polticas impositivas de servio so em quantidade para assegurar que a poltica de afirmao consistente com o mundo real. Isto pode significar a preveno de execuo de uma ao no autorizada ou a entrada em um estado no autorizado; pode significar tambm o inicio de uma ao compensatria quando uma violao de poltica detectada. Uma restrio de no imposio no uma poltica; ela ser melhor descrita como um desejo.
706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740
Polticas potencialmente se aplicam a muitos aspectos do SOA: segurana, privacidade, gerenciabilidade, Qualidade de Servio e assim por diante. Alm dessas polticas orientadas a infraestrutura, os participantes PODEM tambm expressar as polticas orientadas a negcios tais como as horas de negcios, polticas retornadas e assim por diante. As polticas de afirmao DEVEM ser escritas em um formulrio que seja compreensvel para, e processvel pelas, partes s quais as polticas so dirigidas. As polticas PODEM ser interpretadas automaticamente, dependendo do propsito e aplicabilidade da poltica e como ela pode afetar como um servio em particular usado ou no. Um ponto de contato natural entre os participantes do servio e as polticas associadas com o servio a descrio do servio ver seo 3.3.1. natural para a descrio do servio conter referncias s polticas associadas com o servio.
3.3.2.2. Contrato de Servio

Visto que uma poltica est associada com o ponto de vista dos participantes individuais, um contrato representa um acordo entre dois ou mais participantes. Assim como as polticas, os contratos podem cobrir uma ampla faixa de aspectos de servios: acordos de qualidade de servio, acordos de interface e coreografia e acordos comerciais. Note que, neste caso, no estamos nos referindo aos contratos legais. Ento, seguindo com a discusso acima, um contrato de servio uma afirmao mensurvel que governa os requisitos e expectativas de duas ou mais partes. Assim como as polticas impositivas, que so usualmente de responsabilidade do proprietrio da poltica, os contratos de imposio podem envolver a resoluo de disputas entre as partes do contrato. A resoluo de tal disputa pode envolver apelao a autoridades maiores. Assim como as polticas, os contratos podem ser expressos em um formulrio que permita a interpretao automtica. Onde um contrato usado para codificar os resultados da interao de um servio, uma boa prtica represent-lo em um formulrio processvel por mquina. Entre ouros propsitos, isto facilita a composio automtica do servio. Onde um contrato usado para descrever acordos que influenciam os provedores e consumidores de servio, ento a prioridade provavelmente fazer tais contratos compreensveis pelas pessoas. Desde que um contrato inerentemente o resultado de acordo entre as partes envolvidas, h um processo associado com a ao de acordo. Mesmo no caso de um acordo implcito sobre contrato, h logicamente uma ao de acordo associada com o contrato, mesmo se no houver uma ao pblica de acordo. Um contrato pode chegar por um mecanismo que no seja parte direta de um SOA um processo marginal (out-of-band). Alternativamente, um contrato pode chegar durante o curso de uma interao de um servio um processo no circuito (in-band).
740
3.3.3. Contexto de Execuo

Descrio do servio Servio Modelo comportamental
Contexto de execuo
Interao Contrato& Polticas Modelo de informao

741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 Figura 11 Contexto de Execuo O contexto de execuo de uma interao de servio o conjunto de elementos de infraestrutura, entidades processo, afirmaes e acordos de polticas que so identificados como parte de uma interao de servio instanciado, e ento forma um caminho entre aqueles com necessidades e aqueles com competncias. Como discutido nas sees anteriores deste documento, a descrio do servio (e a correspondente descrio associada com o consumidor de servio e suas necessidades) contm as informaes preferidas que podem ser includas como protocolos, semnticas, polticas e outras condies e suposies que descrevem como um servio deve e pode ser usado. Os participantes (provedores, consumidores, e quaisquer terceiros como citado abaixo) precisam concordar e conhecer um consistente conjunto de acordos de maneira a ter uma interao de servio bem sucedida, i.e., obtendo os efeitos no mundo real descritos. O contexto de execuo a coleo deste conjunto consistente de acordos. O consumidor e o provedor podem ser visualizados como locais separados em um mapa e, para um servio ser realmente invocado, um caminho precisa ser estabelecido entre estes dois locais. Este caminho o contexto de execuo. Como um caminho entre estes dois locais, ele pode ser uma conexo temporria (por ex. uma ponte pequena ou uma troca ad hoc) ou uma coordenao bem definida (por ex. uma super via) que pode ser facilmente reutilizvel no futuro. O contexto de execuo no limitado a um lado da interao; ao invs disto se refere totalidade de interaes incluindo o provedor de servio, o consumidor de servio e a infraestrutura comum necessria para mediar a interao. Enquanto pode haver terceiros, por exemplo, reguladores do governo, que configuram algumas condies para o contexto de execuo, isto meramente aumenta as condies e as restries necessrias para ser coordenada e pode requerer uma troca de informao adicional para completar o contexto de execuo. O contexto de execuo central para muitos aspectos de uma interao de servio. Ele define, por exemplo, um ponto de deciso para imposio de poltica relacionada interao de servios. Note que um ponto de deciso de poltica no necessariamente idntico a um ponto imposio: um contexto de execuo no por si s alguma coisa que conduz ele prprio para a imposio. Por outro lado, qualquer mecanismo de imposio de uma poltica como levar em conta os particulares de um contexto real de execuo. O contexto de execuo tambm permite distinguir os servios de outros. Diferentes instncias do mesmo servio denotando interaes entre um dado provedor de servio e diferentes consumidores
774 775 776 777 778 779 780 781 782 783 784
de servio, por exemplo so distinguidos pela virtude do fato que seus contextos de execuo so diferentes. Finalmente, o contexto de execuo tambm o contexto no qual a interpretao dos dados que so trocados. Uma string particular tem um significado particular em uma interao de servio em um contexto particular o contexto de execuo. Um contexto de execuo freqentemente evolui durante uma interao de servio. Um conjunto de elementos de infraestrutura, as polticas e acordos que aplicam a interao, podem bem mudar durante uma interao de um dado servio. Por exemplo, como um ponto inicial em uma interao, pode ser decidido pelas partes que as comunicaes podem ser encriptadas. Como um resultado o contexto de execuo tambm muda para incorporar a infraestrutura necessria para suportar a encriptao e continuar a interao.
_______________________________________________________________________________
785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807
4. Guia de Conformidade
Os autores deste modelo de referncia visualizam que os arquitetos podem desejar declarar suas arquiteturas em conformidade com este modelo de referncia. A conformidade com um Modelo de Referncia no geralmente uma tarefa automtica e fcil dado que o papel do Modelo de Referncia primariamente definir conceitos que so importantes para o SOA ao invs de oferecer as linhas guias para implementao de sistemas. Contudo, esperamos que qualquer Arquitetura Orientada a Servio ir referenciar os conceitos delineados nesta especificao. Tal como, esperamos que qualquer projeto de sistema que adote a abordagem SOA ir: Ter entidades que podem ser identificadas como servios como definido neste Modelo de Referncia; Estar apta a identificar como a visibilidade estabelecida entre os provedores e consumidores de servio; Estar apta a identificar como a interao ser mediada; Estar apta a identificar como os efeitos do uso de servios so compreendidos; Ter descries associadas com servios; Estar apta a identificar o contexto de execuo requerido para suportar interaes; e Ser possvel identificar como as polticas so tratadas e como os contratos podem ser modelados e formados. No apropriado para esta especificao identificar as melhores prticas com respeito construo de sistemas baseados em SOA. Contudo, a facilidade com a qual os elementos acima podem ser identificados em um dado sistema baseado em SOA pode ter impacto significante na escalabilidade, manutenibilidade e facilidade de uso do sistema.
19 de Julho de 2006
_______________________________________________________________________________
808 809 810 811 812 813 814 815
5. Referncias
5.1. Normativa
[RFC2119] S. Bradner , Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfv/rfc2119.txt, IETF RFC 2119, Maro 1997.
5.2.
No-Normativa
[W3C WSA] W3C Working Group Note Web Services Architecture, http://www.w3.org/TR/ws-arch/, 11 Fevereiro 2004.
19 de Julho de 2006
_______________________________________________________________________________
816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855
A. Glossrio
Este glossrio contm uma definio concisa dos termos usados nesta especificao, mas a descrio completa no texto a descrio normativa. Acessibilidade (reachability) A habilidade de um consumidor de servio e um provedor de servio interagir. A acessibilidade um aspecto da visibilidade. Ver seo 3.2.1.3. Arquitetura de Referncia (reference architecture) Uma arquitetura de referncia um padro de projeto arquitetural que indica como um conjunto abstrato de mecanismos e relacionamentos realiza um predeterminado conjunto de requisitos. Ver seo 1.1. Arquitetura de Software (software architecture) A estrutura ou estruturas de um sistema de informao que consiste de entidades e suas propriedades visveis externamente, e os relacionamentos entre elas. Arquitetura Orientada a Servio (SOA Service Oriented Architecture) A Arquitetura Orientada a Servio um paradigma para organizar e utilizar as competncias distribudas que podem estar sob controle de diferentes domnios proprietrios. Ela prove um meio uniforme para ofertar, descobrir, interagir com as competncias para produzir os feitos desejados consistentes com as precondies mensurveis e expectativas. Ver seo 2.1. Competncias (capability) Um efeito no mundo real que um provedor de servio est apto a oferecer para um consumidor de servio. Ver seo 2.1 Comprometimento semntico (semantic engagement) O relacionamento entre um agente e um conjunto de informao que depende de uma interpretao particular da informao. Ver seo 3.2.2.1. Concordncia (willingness) A predisposio dos provedores e consumidores de servio para interagirem. Ver seo 3.2.1.2. Conscincia (awareness) Um estado por meio do qual uma parte tem conhecimento da existncia de outra parte. A conscincia no implica concordncia ou acessibilidade. Ver seo 3.2.1.1. Consumidor de Servio (service consumer) Uma entidade que pesquisa para satisfazer uma necessidade particular atravs do uso de competncias oferecidas por meio de um servio. Contexto de execuo (execution context) O conjunto de elementos tcnicos e de negcios que formam um caminho entre aqueles com necessidades e aqueles com competncias e que permita os provedores e consumidores de servio interagirem. Ver seo 3.3.3. Descrio do service (service description) A informao necessria de forma a usar, ou considerar em uso, um servio. Ver seo 3.3.1. Efeitos no mundo real (real world effect)
19 de Julho de 2006
856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898
O resultado real do uso de um servio, ao invs de apenas a competncia oferecida pelo provedor de servios. Ver seo 3.2.3. Estado compartilhado (shared state) O conjunto de fatos e comprometimentos que manifestam eles prprios para os participantes do servio como um resultado da interao com um servio. Framework (framework) Um conjunto de suposies, conceitos , valores e prticas que constituem uma forma de visualizar o ambiente atual. Idempotncia / Idempotente (idempotency/idempotent) A caracterstica de um servio no qual mltiplas tentativas de mudar um estado iro sempre e somente gerar uma nica mudana no estado se a operao j tiver sido bem sucedida e completada uma vez. Ver seo 3.2.2.2.2. Interao (interaction) A atividade envolvida no uso de uma competncia oferecida, usualmente atravs de um limite proprietrio, de forma a alcanar um desejado efeito particular no mundo real. Ver seo 3.2.3. Interface de service (service interface) O meio pelo qual a competncia subjacente de um servio acessada. Ver seo 3.3.1.4. Modelo comportamental (behavior model) A caracterizao das (e respostas para, e dependncias temporais entre) aes de um servio. Ver seo 3.2.2.2. Modelo de Ao (action model) A caracterizao de aes permitidas que possam ser invocadas na direo do servio. Ver seo 3.2.2.2.1. Modelo de Informao (information model) A caracterizao da informao que esta associada com o uso de um servio. Ver seo 3.2.2.1. Modelo de Processo (process model) A caracterizao de um relacionamento temporal entre as propriedades temporais das aese dos eventos associados com a interao de um servio. Ver seo 3.2.2.2.2. Modelo de Referncia (reference model) Um modelo de referncia um framework abstrato para entendimento dos relacionamentos significantes entre as entidades e algum ambiente que habilite o desenvolvimento de arquiteturas especficas usando padres consistentes ou especificaes que suportem este ambiente. Um modelo de referncia consiste de um conjunto mnimo de conceitos unificados, axiomas e relacionamentos com um domnio de problema particular, e independente de padres especficos, tecnologias, implementaes , ou outro detalhe concreto. Ver seo 1.1. Oferta (offer) Um convite ao uso das competncias que esto disponveis em um provedor de servio de acordo com algum conjunto de polticas. Poltica (policy) Um tratado de obrigaes, restries ou outras condies de uso de uma entidade proprietria como definida por um participante. Ver seo 3.3.2.
899 900 901 902 903 904 905 906 907 908 909 910
Provedor de Servio (service provider) Uma entidade (pessoa ou organizao) que oferece o uso de competncias por meios de um servio. Semntica (semantics) Uma conceitualizao do significado implcito da informao, que requer palavras e/ou smbolos em um contexto de uso. Ver seo 3.2.2.1.2. Servio (service) O meio pelo qual as necessidades de um consumidor se compatibilizam com as competncias de um provedor. Ver seo 3.1. Visibilidade (visibility) A capacidade para aqueles que necessitam e para aqueles com competncias a estar apto a interagirem entre si. Ver seo 3.2.1.
_______________________________________________________________________________
911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942
B. Agradecimentos
As pessoas a seguir eram membros do comit durante o desenvolvimento desta especificao e aos quais fica expressa a gratido com este reconhecimento. Participantes: Christopher Bashioum, Mitre Corporation Prasanta Behera, Individual Member Kathryn Breininger, The Boeing Company Rex Brooks, HumanMarkup.org, Inc. Al Brown, FileNet Corporation Peter F Brown, Individual Member Joseph Chiusano, Bozz Allen Hamilton David Ellis, Individual Member Robert S. Ellinger, Northrop Grumman Corporation Jeff Estefan, Jet Propulsion Laboratory Don Flinn, Individual Member Steve Jones, Capgemi Gregory Kohring, NEC Europe Ltd. Ken Laskey, Mitre Corporation C. Matthew MacKenzie (secretaria), Adobe Systems Francis McCabe (secretaria), Fujtisu Laboratories of America Ltd. Wesley McGregor, Treasury Board of Canada, Secretariat Tom Merkle, Lockheed Martin Information Tecnology Rebekah Metz, Booz Allen Hamilton Oleg Mikulinsky, WebLayers, Inc. Jyoti Namjoshi, Patni Computer Systems, Ltd. Duane Nickull (chair), Adobe Systems George Ntinolazos, Strata Software Ltd. Joseph Pantella, Individual Member Ron Schuldt, Lockheed Martin Michael Stiefel, Reliable Software, Inc. Danny Thornton, Individual Member Michal Zaremba, Digital Enterprise Research Institute
19 de Julho de 2006

Modelo de Referência para Arquitetura Orientada A Serviço 1.0 OASIS

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

Modelo de Referência para Arquitetura Orientada A Serviço 1.0 OASIS

Enviado por

Direitos autorais:

Formatos disponíveis

_______________________________________________________________________________

Modelo de Referncia para Arquitetura Orientada a Servio 1.0

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

Modelo de referncia para Arquitetura Orientada a Servio 1.0

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

19 de Julho de 2006 Pgina 1 de 33

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

19 de Julho de 2006 Pgina 2 de 33

A ARQUITETURA ORIENTADA A SERVIO ................................................................................. 1

A. GLOSSRIO ......................................................................................................................................... 1 B. AGRADECIMENTOS ............................................................................................................................ 1

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

19 de Julho de 2006 Pgina 3 de 33

1.1. O que um modelo de referncia

Um Modelo de Referncia para Arquiteturas Orientada a Servio

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

Protocolos Perfis Especificaes

Padres Trabalhos relacionados

Implementaes da Arquitetura Orientada a Servio

60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 Figura 1 Como o Modelo de Referncia relaciona-se com os outros trabalhos

Os arquitetos de padres e analistas desenvolvendo especificaes que trabalhem com os

Guia para usar o modelo de referncia

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

19 de Julho de 2006 Pgina 2 de 33

75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106

1.5.1. Como interpretar os mapas conceituais

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

19 de Julho de 2006 Pgina 3 de 33

115 116 117 118 119 120 121 122 123

Relacionamento com outros padres

base ou inspirao para seu trabalho; e

Os padres ou tecnologias que se enquadram como orientados a servios.

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

19 de Julho de 2006 Pgina 4 de 33

2. A arquitetura orientada a servio

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

2.1.1. Um exemplo trabalhado de Arquitetura Orientada a Servios

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

19 de Julho de 2006 Pgina 2 de 33

Como a Arquitetura Orientada a Servio diferente?

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

19 de Julho de 2006 Pgina 3 de 33

Os benefcios da Arquitetura Orientada a Servio

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

19 de Julho de 2006 Pgina 4 de 33

Efeito no mundo real Contrato & Polticas

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

As dinmicas dos Servios

Efeito no mundo real

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

19 de Julho de 2006 Pgina 2 de 33

Conscincia Concordncia Visibilidade

Efeito no mundo real

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

19 de Julho de 2006 Pgina 3 de 33

3.2.2. Interagindo com os Servios

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

19 de Julho de 2006 Pgina 4 de 33

Visibilidade Descrio do Servio

Modo de Ao Servio Modelo de Comportamento Modelo de Processo

Interao Efeito no mundo real

Modelo de Informao Semntica Estrutura

3.2.2.1. O modelo de informao

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