964 5379 1 PB

UNIVERSIDADE FEDERAL DO ESTADO DO RIO DE JANEIRO CENTRO DE CINCIAS EXATAS E TECNOLOGIA
Relatrios Tcnicos do Departamento de Informtica Aplicada da UNIRIO no 0005/2010
Estudos de Registro de Servios e do Oracle Service Registry
Leonardo Azevedo Flvio Faria Flvia Santoro Fernanda Baio
Departamento de Informtica Aplicada

UNIVERSIDADE FEDERAL DO ESTADO DO RIO DE JANEIRO Av. Pasteur, 458, Urca - CEP 22290-240 RIO DE JANEIRO BRASIL
Projeto de Pesquisa
Grupo de Pesquisa Participante
Patrocnio
ii
Relatrios Tcnicos do DIA/UNIRIO, No. 0005/2010

Editor: Prof. Prof. Sean W. M. Siqueira Setembro, 2010
Estudos de Registro de Servios e do Oracle Service Registry*

Leonardo Azevedo, Flvio Faria, Flvia Santoro, Fernanda Baio
Ncleo de Pesquisa e Prtica em Tecnologia (NP2Tec) Departamento de Informtica Aplicada (DIA) Universidade Federal do Estado do Rio de Janeiro (UNIRIO) {azevedo, flavio.faria, flavia.santoro, fernanda.baiao}@uniriotec.br
Abstract. SOA is a paradigm that envolves in a broader way than technology, such as, strategies and architectural model definitions, behavioral and cultural issues, indicators specifications to asses ROI etc. However, SOA deployment depends on technologies. Among the main technologies, service registry or UDDI (Universal Description, Discovery and Integration the published pattern) is one of them as well as ESB (Enterprise Service Bus) and tools for service composition. This work presents a study of service registry concepts and the analysis of OSB (Oracle Service Bus), a UDDI implementation. Keywords: SOA, Service Registry, UDDI, Oracle Service Registry. Resumo. SOA um paradigma que envolve muito mais questes do que apenas tecnologia, tais como, definies de estratgias e modelos arquiteturais, tratar questes de comportamento e cultura, especificar indicadores para medir ganhos etc. No entanto, a implantao de uma abordagem SOA depende da definio de tecnologias de apoio. Dentre estas tecnologias, o registro de servios ou UDDI (Universal Description, Discovery and Integration - considerando o padro), apresenta-se como uma tecnologia intrnseca para implantao de SOA, juntamente com o ESB (Enterprise Service Bus) e ferramentas de composio de servios. Este trabalho apresenta um estudo dos conceitos de registro de servios e a anlise do Oracle Service Registry, uma implementao UDDI. Palavras-chave: SOA, Registro de Servios, UDDI, Oracle Service Registry. ___________________
* Trabalho patrocinado pela Petrobras.
iii
Sumrio
1 2
Introduo Especificao UDDI v3 2.1 N e Registro UDDI 2.2 Representao de informaes em um UDDI 2.3 Segurana no UDDI 2.4 Usando WSDL em um registro UDDI 2.5 UDDI Schemas Oracle Service Registry 3.1 Instalao 3.2 Fluxo de aprovao 3.3 Subscrio e notificao 3.4 Classificao de servios usando taxonomias 3.5 Segurana 3.6 Processo de aprovao 3.7 Consoles do OSR 3.8 Controle de acesso 3.9 Taxonomia 3.10 Mapeamento de recursos 3.11 Desenvolvimento do lado do cliente e do servidor 3.12 Integrao do OSR com OSB Concluses Referncias
6 8 10 11 14 15 18 18 20 22 22 23 23 24 25 47 48 49 54 55 56 56 58
4 5
Apndice 1 Roteiro de Instalao do Oracle Service Registry verso 10.3
Apndice 2 Roteiro para gerenciamento de contas de usurios no Oracle Service Registry verso 10.3 67 Apndice 3 Roteiro para gerenciamento de grupo de usurios no Oracle Service Registry verso 10.3 69 Apndice 4 Roteiro para gerenciamento de permisses de usurios e grupo de usurios no Oracle Service Registry verso 10.3 Apndice 5 Roteiro para publicao de um provedor de servio no Oracle Service Registry verso 10.3 71 73
Apndice 6 Roteiro para publicao de um servio de negcio no Oracle Service Registry verso 10.3 75 Apndice 7 Roteiro para controlar o acesso a um servio de negcio no Oracle Service Registry verso 10.3 Apndice 8 Roteiro para criar taxonomias no Oracle Service Registry verso 10.3 81 78
iv
Apndice 9 Roteiro para associar uma categoria a um servio de negcio no Oracle Service Registry verso 10.3 Apndice 10 Roteiro para associar um servio de negcio a um provedor de negcio no Oracle Service Registry verso 10.3 Apndice 11 Roteiro para criar um binding template no Oracle Service Registry verso 10.3 Apndice 12 Utilizando taxonomia para pesquisa de servios no Oracle Service Registry verso 10.3
85 86 88 89
1 Introduo
Um registro de servios ou UDDI (Universal Description, Discovery and Integration), assim como o barramento de servios (ESB), uma tecnologia chave para a implantao de uma Arquitetura Orientada a Servios (Service-Oriented Architecture). As especificaes UDDI formam a fundamentao tcnica necessria para publicao e descoberta de implementaes de web services tanto dentro de uma empresa como entre empresas [Bellwood et al., 2004]. O foco do UDDI a definio de um conjunto de servios suportando descrio e descoberta de: Negcios, organizao e outros provedores de servios; Web services que provedores disponibilizam; Interfaces tcnicas que podem ser usadas para acessar estes servios; O registro UDDI descreve: Formato de dados para classificao e organizao de negcios e corporaes; Formato de dados para descrio e categorizao de servios de negcio (web services); Prticas para organizao e compartilhamento de informaes por brokers de servios; Uma API-baseada em XML para interagir com brokers de servios para publicar ou localizar web services; Um mecanismo para registrar servios que independente de plataforma. O registro UDDI semelhante a um catlogo de pginas amarelas, onde os servios listados no existem dentro do livro, mas sim informaes sobre os servios (metadados). O UDDI atua como um ndice de registros (Figura 1) para servios onde: Provedores de servios (provedor) mantm informaes sobre seus servios no registro. Requisitantes de servios (consumidor) procuram nos registros por servios. Uma vez encontrado, um servio pode ser invocado atravs de uma comunicao ponto-a-ponto ou utilizando um intermedirio.
_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 6
Registro UDDI
Pesquisa por servio
Aponta para uma descrio
WSDL
Aponta para um servio
Descreve um servio
Consumidor de servio
SOAP
Figura 1 Interaes de web services
Comunica atravs de mensagens XML
Web service (provedor)
O registro UDDI pode ajudar a tratar questes de reuso de cdigo, manuteno e documentao e prov os seguintes benefcios: Visibilidade: Ele prov visibilidade pela identificao de quais servios dentro da organizao podem ser reutilizados para tratar uma necessidade do negcio. Reuso: Ele promove reuso e previne recriar o mesmo servio. Ele acelera tempo de desenvolvimento e aumenta produtividade. A habilidade do UDDI de categorizar um portflio de servios crescente facilita gerenci-los. Facilidades para configurao e adaptao: Ele facilita configurao e adaptao pelo uso do princpio arquitetural orientado a servio de independncia de localizao e transporte. Usurios podem dinamicamente descobrir servios armazenados no registro UDDI. Relacionamentos: Ele ajuda a entender relacionamentos entre servios, verses de componentes e dependncias. Ele facilita a gesto do ciclo de vida de servios de negcio. Por exemplo, o processo de mover servios atravs de cada fase de desenvolvimento do cdigo para a instalao pblica. O registro frequentemente utilizado pelas organizaes em trs propsitos especficos: Fase de projeto: Catlogo de servio Arquitetos, desenvolvedores e administradores usam o registro para publicao e descoberta de servios que esto disponveis na organizao para reuso. Isto efetivo em situaes onde existem muitas equipes de desenvolvimento que necessitam compartilhar servios atravs dos limites departamentais. Governana de TI Pelo uso do registro, organizaes podem alcanar visibilidade dos seus servios e garantir polticas de TI sobre os mesmos. Isto garante consistncia arquitetural e visibilidade atravs da organizao. Resoluo de servio em tempo de execuo
Neste cenrio, o registro utilizado para permitir arquitetura com baixo acoplamento. Por adiar a resoluo do endpoint do servio at o tempo de execuo, aplicaes consumidoras podem garantir que elas esto conectadas com o provedor do servio mais apropriado, ou seja, o provedor que est mais de acordo com critrios, tais como, carga do sistema atual, requisitos de QoS (Quality of Service) do cliente e contexto de segurana. Este tipo de abordagem melhora a resilincia e tratamento de falhas em implementaes SOA. Baseado em um conjunto de padres comuns da indstria, incluindo HTTP, XML, XML Schema e SOAP, o UDDI prov uma infraestrutura interopervel e fundacional para ambientes de software baseados em web services. O padro UDDI est na sua terceira verso. UDDI usa a linguagem XML Schema1 e sua terminologia, tais como sequence e choice para formalmente descrever suas estruturas de dados. O UDDI disponibilizado, ele mesmo, como um conjunto de web services. O comit tcnico da especificao de UDDI da OASIS de tempos em tempos publica melhores prticas e notas tcnicas a respeito do padro, os quais podem ser obtidos a partir de [OASIS, 2009a] e [OASIS, 2009b], respectivamente. O objetivo deste relatrio apresentar as principais caractersticas do UDDI e apresentar um estudo do OSR (Oracle Service Registry). OSR responsvel pela gerncia de metadados teis durante o runtime de servios para comunicao com um dado servio. Descries de servios, localizao e endpoint, operaes e parmetros de servios, e polticas de servios so exemplos de informao de runtime que o registro gerencia. Este relatrio foi produzido pelo Projeto de Pesquisa em SOA como parte das iniciativas dentro do contexto do Projeto de Pesquisa do Termo de Cooperao entre NP2Tec/UNIRIO e a Petrobras/TIC-E&P/GDIEP. Esse relatrio est organizado em 5 captulos, sendo o captulo 1 a presente introduo. No captulo 2, so apresentadas as principais caractersticas de um UDDI. No captulo 3, apresentada, em detalhes, a arquitetura do Oracle Service Registry (OSR), que a implementao UDDI da Oracle. Nos captulos 4 e 5, so apresentadas as concluses do trabalho e as referncias bibliogrficas, respectivamente.
2 Especificao UDDI v3
A especificao UDDI [Bellwood et al., 2009] apresenta um modelo de informaes composto por instncias de estruturas de dados persistentes chamadas entidades. Entidades so descritas em XML e so armazenadas de forma persistente em ns UDDI. Cada entidade tem o tipo do seu elemento XML mais global. Um modelo de informaes UDDI composto de instncias dos seguintes tipos de entidades (Figura 2): Entidade do negcio (businessEntity): descreve um negcio ou outra organizao que prov web services. Cada servio deve ser publicado dentro de um businessEntity.
1
URLs para especificao da linguagem XML Schema: http://www.w3.org/TR/xmlschema-0/, http://www.w3.org/TR/xmlschema-1/, e http://www.w3.org/TR/xmlschema-2/.
Servio de negcio (businessService): descreve uma coleo de web services relacionados que so oferecidos por um organizao descrita pela entidade do negcio (businessEntity). Template de ligao (bindingTemplate): descreve a informao tcnica para usar um determinado web service. tModel: descreve um modelo tcnico (technical model), representando um conceito, por exemplo, um tipo de web service, um protocolo usado por web services, ou um sistema de categorias. Assertiva de publicador (publisherAssertion): descreve, na viso de um businessEntity, o relacionamento que o businessEntity tem com outro businessEntity. Subscrio (subscription): descreve uma requisio para manter-se informado de mudanas das entidades descritas pela subscription. Qualquer usurio do registro pode se subscrever a um conjunto de entidades de UDDI e monitorar sua criao, modificao ou remoo. A subscrio definida usando chamadas da API padro get ou find. O registro UDDI notifica o usurio sempre que qualquer entidade que est de acordo com a consulta de subscrio ocorre, mesmo que as mudanas da entidade faam com que ela no atenda mais a consulta. Ele tambm notifica a respeito de entidades que foram alteradas de uma forma que depois da mudana fizeram com que elas estivessem de acordo com a consulta de subscrio. BusinessEntity Informao da empresa
BusinessService
Servios oferecidos pela empresa
BindingTemplate
Como invocar servios
tModel
Detalhes de invocao
Figura 2 Esquema do modelo de dados do UDDI
A especificao apresenta APIs que padronizam o comportamento e a comunicao com e entre implementaes de UDDI com o objetivo de manipular dados de UDDI armazenados dentro destas implementaes. As APIs so agrupadas nos seguintes conjuntos: Conjunto de APIs de ns: UDDI Inquiry; UDDI Publication; UDDI Security; UDDI Custody Transfer; UDDI Subscription; UDDI Replication. APIs de cliente: UDDI Subscription Listener, UDDI Value Set.
2.1
N e Registro UDDI
Um n UDDI corresponde a um conjunto de web services que suporta pelo menos um conjunto de API de n. Um n UDDI tem as caractersticas definidoras: Um n UDDI suporta interao com dados UDDI atravs de uma ou mais API UDDI; Um n UDDI um membro de exatamente um registro UDDI; Um n UDDI conceitualmente tem acesso e manipula uma cpia lgica completa dos dados UDDI geridos pelo registro do qual ele faz parte. Alm disso, estes so os dados que so manipulados por qualquer API de consulta ou de publicao suportada pelo n. Tipicamente, a replicao de UDDI ocorre entre ns UDDI que residem em sistemas diferentes a fim de explicitar esta cpia lgica no n. A realizao fsica de um n UDDI no mandatria pela especificao. Um registro UDDI corresponde a um ou mais ns UDDI combinados. Os ns em um registro UDDI coletivamente gerenciam um conjunto particular de dados de UDDI. Estes dados so distintos pela viso do comportamento associada com cada entidade contida nele. Um registro UDDI tem as seguintes caractersticas definidoras: Um registro composto de um ou mais ns UDDI. Um registro deve ter uma deciso de poltica para cada ponto de deciso de poltica. Ele pode escolher delegar decises de polticas para ns. A realizao fsica de um registro UDDI no mandatria pela especificao. As entidades businessEntity, businessService, bindingTemplate e tModel formam as estruturas de dados principais do UDDI. Dentro do registro, cada instncia de uma estrutura de dados principal identificada por uma chave de UDDI. Pela escolha de polticas apropriadas, mltiplos registros podem formar um grupo, conhecido como uma afiliao, cujo propsito permitir controlar cpias das estruturas de dados entre eles. Uma afiliao de registro UDDI tem as seguintes caractersticas definidoras: Os registros compartilham um namespace comum para as chaves de entidades; Os registros tm polticas compatveis para atribuir chaves para entidades; As polticas de registros permitem que publicadores atribuiam chaves. Dados so replicados entre ns de um registro UDDI usando um protocolo de replicao. Cada n tem custdia de uma parte dos dados agregados gerenciados pelo registro do qual ele parte. Cada dado est por definio sob custdia de exatamente um n. Um dado, neste contexto pode ser um businessEntity, um businessService, um bindingTemplate, um tModel, ou um publisherAssertion. Uma mudana em um dado no registro deve ser realizada no n que tem custdia do dado. O registro define a poltica para custdia de dados e, se permitido, o n que tem custdia de um dado pode ser alterado.
2.2
Representao de informaes em um UDDI
Para que web services sejam realmente teis, h a necessidade de prover informaes sobre eles alm das informaes tcnicas. O propsito central do UDDI representar dados e metadados sobre web services. Um registro UDDI fornece mecanismos para registrar, classificar e catalogar web services, a fim de que eles possam ser descobertos e consumidos. As informaes so armazenadas de uma forma padronizada que permite que web services sejam consultados em tempo de projeto ou em tempo de execuo para enderear os seguintes cenrios: Encontrar implementaes de web services que esto baseadas em uma definio de interface abstrata comum; Encontrar provedores de web services que esto classificados de acordo com um esquema de classificao ou sistema de identificao conhecidos; Determinar a segurana e os protocolos de transporte suportados por determinado web service; Prover a pesquisa por servios baseado em uma palavra chave geral; Armazenar em cache a informao tcnica sobre um web service e, ento, atualizar esta informao em tempo de execuo. A estrutura businessEntity usada para representar negcios e provedores de um UDDI. Ela contm informaes descritivas sobre o negcio ou provedor e sobre os servios que ele oferece, por exemplo, nomes e descries em mltiplos idiomas, informao de contato (lista de pessoas que esto associadas ao businessEntity, incluindo nome, endereo, nmeros de telefone e tipo de uso), classificao (por exemplo, um businessEntity pode estar associado categoria Califrnia, indicando que ele est localizado nesta rea geogrfica), identificadores (que o identificam univocamente) e URLs para documentos que descrevem o businessEntity. Descries do servio e informaes tcnicas so expressas em estruturas businessService e bindingTemplate, respectivamente, dentro de um businessEntity. Um businessEntity pode ser usado para modelar provedores de servio pai, tais como um departamento, uma aplicao ou mesmo um servidor. A palavra business no se refere ao fato de que apenas informaes de negcio (no seu uso comum) devem ser modeladas. Cada estrutura de businessService representa um agrupamento lgico de web services. Nenhuma informao tcnica provida. Cada businessService filho de um nico businessEntity. Cada businessService contm informaes descritivas (nomes, descries e classificaes por exemplo, categorias que representam disponibilidade do servio, verso etc.) descrevendo o propsito dos web services existentes dentro do businessService. Por exemplo, uma estrutura de businessService pode conter um conjunto de web services de tratamento de pedidos (submisso, confirmao e notificao) que so providos pelo negcio. Um businessService pode ser usado para descrever web services que no esto ligados diretamente a um negcio, como, por exemplo, web services de um provedor de servios. Um registro UDDI pode registrar servios arbitrrios, por exemplo, EJB, CORBA etc. Cada estrutura de bindingTemplate representa um web service individualmente, provendo informaes tcnicas necessrias para que aplicaes se conectem (bind) e interajam com o web service descrito. Ela deve conter as informaes sobre o ponto de acesso (access point que representa o endpoint do servio, contendo a URI do endpoint e a especificao de protocolo) de um dado servio ou um mecanismo de indireo
que levar a um ponto de acesso. Cada bindingTemplate filho de um nico businessService. O bindingTemplate pode ser decorado com metadados que permitam a descoberta do bindingTemplate, dado um conjunto de parmetros e critrios. O bindingTemplate pode estar associado com categorias para referenciar caractersticas do bindingTemplate, por exemplo, estados de certificao (teste, em produo) ou verses. A Figura 3, apresenta um bindingTemplate que especifica o endereo do endpoint de rede (no elemento accessPoint) e uma pilha de tModels descrevendo o servio.
<businessService> (...) <bindingTemplates> <bindingTemplate> (...) <accessPoint urlType="http"> http://www.etc.com/</accessPoint> <tModelnstanceDetails> <tModelnstanceInfo tModelKey="..."> </tModelnstanceInfo> (...) </tModelnstanceDetails> </bindingTemplate> (...) </bindingTemplates> </businessService> Figura 3 Exemplo de bindingTemplate [Colgrave e Januszewski, 2002]
Modelos tcnicos ou tModels, so usados no UDDI para representar conceitos ou construtos nicos. Eles provem uma estrutura que permite reuso e, portanto, padronizao dentro de um framework de software. Cada especificao, transporte, protocolo ou namespace distinto representado por um tModel. Exemplos de tModels que permitem a interoperabilidade de web services incluem os modelos baseados em WSDL (Web Service Description Language), XSD (XML Schema Definition), e outros documentos que delineiam e especificam o contrato e comportamento (por exemplo, a interface) que um web service pode escolher para estar de acordo. Para descrever um web service que est conforme a um conjunto de especificaes, transporte e protocolos particular, referncias aos tModels que representam estes conceitos so colocados no bindingTemplate. Desse modo, tModels podem ser reutilizados por mltiplos bindingTemplates. Os bindingTemplates que referenciam precisamente o mesmo conjunto de tModels tm a mesma assinatura e so do mesmo tipo. Desse modo, tModels podem ser usados para promover a interoperabilidade entre sistemas de software. importante ressaltar que os documentos tcnicos e a documentao de apoio necessria para um desenvolvedor usando web services no so armazenadas dentro do registro UDDI. Um tModel do UDDI contm os endereos onde estes documentos podem ser encontrados. Um tModel, entretanto, contm mais do que apenas URLs; ele tambm armazena metadados sobre documentos tcnicos e chave de entidade que identificam o tModel.
Em essncia, um tModel algo que tem um nome e uma descrio. Para entender melhor, pode-se fazer uma associao entre um tModel e uma tabela de banco de dados. Primeiro, um tModel uma tabela independente, significando que ele pode existir por si mesmo. Segundo, um tModel uma tabela de pesquisa (lookup table) provendo a traduo entre uma chave e uma representao do que a chave . Neste sentido, um tModel uma tabela de referncia, como um dicionrio. Pode se imaginar que um tModel uma tabela com as seguintes colunas: nome, descrio, URL (que pode descrever melhor a respeito do nome e da descrio), chave nica (para identificar o nome) [Oracle, 2008b]. tModels podem ser utilizados para representar outros conceitos dentro do UDDI a fim de prover interoperabilidade, tais como: Definies de protocolo e mecanismos de transporte, tais como HTTP e SMTP. Conjuntos de valores incluindo sistemas de identificao, sistemas de categorizao e namespaces. Estruturas de categorizao usando mltiplos conjuntos de valores chamados de grupos de categorizao. Formatos de endereos postais. Qualificadores de localizao usados para modificar o comportamento da API UDDI find_xx. Por exemplo, para definir que a operao find_business deve ordenar seus resultados na ordem que eles foram publicados, pode-se especificar uddi:uddi.org:findqualifier:sortbydateasc. Atributos de tipos de uso que especificam o tipo de recurso sendo referenciado por uma referncia de URI. A especificao UDDI define um conjunto de tModels comuns que podem ser usados canonicamente para modelar informao dentro de um UDDI. Se um conceito que necessrio para modelar um cenrio em particular no existe em um registro, um usurio deve introduzir o conceito pela criao de um tModel contendo a URL para os documentos relevantes que descrevem o conceito. Um exemplo de uso de tModel seria representar o fato de que um negcio descrito por um businessEntity tem um identificador de taxa US especfico. Um keyedReference colocado no identifierBag do businessEntity. O keyedReference tem um valor chave que o identificador da taxa e refere-se ao tModel que significa o sistema de identificadores de cdigo de taxas dos Estados Unidos. Juntos, o valor chave e a referncia para o tModel especificam um valor especfico em um sistema de valores especfico. A reificao2 de dados em um UDDI o principal para sua misso de descrio, descoberta e integrao. Ele alcana isto de vrias maneiras: Primeiro, ele permite que usurios definam mltiplas taxonomias que podem ser usadas no UDDI. Taxonomias so usadas para representar caractersticas e qualidades de entidades do UDDI (tais como, tipos de produto, regies geogrficas ou departamento em uma empresa). Dessa forma, mltiplos esquemas de classificao podem ser sobrescritos dentro
2
No processo de alienao, o momento em que a caracterstica de ser uma coisa se torna tpica da realidade objetiva, ou seja, quando se consegue entender de forma clara o que o conceito apresentado.
de uma entidade UDDI particular. Esta capacidade permite que organizao estenda o conjunto de sistemas que os registros UDDI suportam. Um registro pode no estar atrelado a um nico sistema, podendo empregar muitos sistemas de classificao diferentes simultaneamente. Segundo, UDDI permite que tais sistemas de classificao sejam usados em cada entidade dentro do modelo de informao. importante que taxonomias sejam utilizadas para publicar dados em um registro UDDI. Se cdigos padres so usados ou uma nova taxonomia criada e distribuda, intrnseco que dados UDDI (businessEntity, businessService, bindingTemplate e tModel) estejam associados com metadados. Terceiro, o conjunto API de pesquisa UDDI (UDDI Inquiry API) prov a habilidade de emitir buscas precisas baseado em diferentes esquemas de classificao. Um intervalo de consultas que realiza diferentes junes atravs das entidades UDDI pode ser gerado, tais dados podem ser descobertos e acessados. Alm disso, registrando informaes tais como cdigos de indstria, cdigos de produto, cdigos geogrficos e cdigos de identificao do negcio permitem que outros servios de busca usem estas informaes de classificao como um ponto de partida para prover indexao e classificao com valor. Sistemas de classificao e identificao, tomados juntos, so chamados de conjuntos de valor (value sets) em um UDDI. Conjuntos de valor podem ser checados e no checados e ambos usados para categorizao e identificao. Um conjunto de valor checado significa que o UDDI no permite o uso de qualquer valor que no esteja dentro dos valores pr-definidos. Eles so usados quando o autor da taxonomia consegue enumerar todos os valores distintos possveis para a taxonomia. Conjunto de valores no checados no prescrevem quaisquer valores fixos e qualquer nome e par de valor pode ser usado para categorizar entidades do UDDI. Eles so usados, por exemplo, para registrar volume, peso, preo etc. A diferena entre eles que, toda vez que um conjunto de valor checado usado, o seu uso inspecionado para verificar se ele est conforme com os requisitos do conjunto de valor. Conjuntos de valores no checados no tm o uso inspecionado.
2.3
Segurana no UDDI
O modelo de segurana para um registro UDDI pode ser caracterizado por uma coleo de polticas de registro e de n e a implementao destas polticas por um n UDDI. As principais reas de polticas e mecanismos de segurana na especificao UDDI esto relacionadas com gesto de dados, identificao de usurios, autenticao de usurio, autorizao de usurio, confidencialidade de mensagens e integridade de dados. A fim de autorizar ou restringir acesso aos dados em um registro UDDI, uma implementao de UDDI pode estar integrada com um ou mais sistemas de identificao. UDDI tambm suporta assinaturas digitais XML nos dados UDDI para permitir que pesquisadores (inquirers) verifiquem a integridade dos dados em relao ao publicador dos mesmos. Os modelos de segurana para um registro e n podem ser estendidos alm dos mecanismos descritos na especificao e representados pelo modelo de web services de UDDI e atravs de documentao de polticas de n e registro.
Segundo [ORACLE, 2008a], a especificao UDDI no define um mecanismo de controle de acesso. A especificao permite a modificao de uma entidade especfica apenas pelo seu proprietrio (o criador da entidade). Isto no escala em um ambiente de empresa aonde o direito para modificar ou apagar uma entidade de UDDI deve estar atribuda a muitas identidades, ou melhor ainda, a alguns perfis.
2.4
Usando WSDL em um registro UDDI
Descries de servio em WSDL podem ser estruturadas de mltiplas formas. Entretanto, se a informao reutilizvel est separada da informao que especfica para uma dada instncia de servio, o uso de WSDL e UDDI torna-se relativamente simples [Colgrave e Januszewski, 2002]. Colgrave e Januszewski [2002] ressaltam que importante notar que o elemento import em um WSDL permite a separao de elementos da descrio de um servio em duas partes, chamadas de definio da interface do servio e definio da implementao do servio. Tipicamente, informaes comuns a certa categoria d e servios de negcio, tais como formatos de mensagens, portTypes (interfaces abstratas), e protocolos de binding, esto includas na poro reutilizvel, enquanto informaes que pertencem a um endpoint de servio particular (por exemplo, definio de porta) est includa na parte de definio da implementao do servio. No contexto do UDDI, a parte a ser considerada a parte reutilizvel do WSDL do servio. O processo para um WSDL suportar a criao de entidades de businessService, pode ser descrito nas seguintes partes: 1. Criar o WSDL da definio da interface do servio. A definio da interface do servio inclui interfaces e protocolos de bindings do servio, e ir estar disponvel de forma pblica. As definies de interface do WSDL do servio so ento registradas como tModels do UDDI; o campo overviewDoc de cada tModel novo apontar para o documento WSDL correspondente. Estes tModels so chamados de wsdlSpec tModels. Cada tModel deve ser classificado utilizando taxonomia de tipos do uddi-org:types. Um exemplo apresentado na Figura 4.
<tModel authorizedName="..." operator="..." tModelKey="..."> <name>StockQuote Service</name> <description xml:lang="en"> WSDL description of a standard stock quote service interface </description> <overviewDoc> <description xml:lang="en">WSDL source document. </description> <overviewURL> http://stockquote-definitions/stq.wsdl </overviewURL> </overviewDoc> <categoryBag> <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4" keyName="uddi-org:types" keyValue="wsdlSpec"/> </categoryBag> </tModel> Figura 4 Exemplo de tModel
Quando um tModel refere a documento WSDL como apresentado na Figura 4, ele refere-se ao contedo inteiro do documento, incluindo todos os seus bindings. sempre conveniente que um tModel referencie um nico binding. Isto pode ser realizado colocando na overviewURL colocando um XPointer para o binding como um fragmento identificador. A Figura 5 apresenta um exemplo de tModel referenciando especificamente StockQuoteSoapBinding.
<overviewURL> http://stockquotedefinitions/stq.wsdl#xmlns(wsdl=http://schemas.xmlsoap.org/wsdl/) xpointer(//wsdl:binding[@name='StockQuoteSoapBinding']) </overviewURL> Figura 5 Exemplo de overviewURL com Xpointer para binding
2. Manualmente ou usando o ferramental do UDDI, programadores recuperaro a descrio do tModel e seguindo o link do overviewDoc obtero o documento de definio do WSDL correspondente. Ferramenta do UDDI pode ajudar a gerar uma implementao que suporta os padres de bindings e interfaces. 3. Finalmente, os novos servios devem ser instalados e registrados no repositrio UDDI, manualmente ou usando ferramental do UDDI. Uma estrutura de dados businessService do UDDI criada, e ento registrada. As informaes contidas no novo businessService implementados e prov detalhes de instalao adicionais: referencia os padres
Um bindingTemplate criado para cada endpoint de acesso do servio. O endereo de rede do ponto de acesso codificado no elemento accessPoint. Um tModelInstanceInfo criado no bindingTemplate para cada tModel que relevante para o ponto de acesso do servio descrito, em particular, para cada tModel wsdlSpec que define interfaces e bindings suportados pelo servio. A Figura 6 apresenta um exemplo de WSDL, enquanto que a Figura 7 apresenta o seu tModel correspondente e a Figura 8 o bindingTemplate correspondente referenciando o tModel da Figura 7.
<?xml version="1.0"?> <definitions name="StockQuote" targetNamespace="http://example.com/stockquote.wsdl" xmlns:tns="http://example.com/stockquote.wsdl" xmlns:xsd1="http://example.com/stockquote.xsd" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <types> <schema targetNamespace="http://example.com/stockquote.xsd" xmlns="http://www.w3.org/2001/XMLSchema "> <element name="TradePriceRequest"> <complexType> <all> <element name="tickerSymbol" type="string"/> </all> </complexType> </element> <element name="TradePrice">
<complexType> <all> <element name="price" type="float"/> </all> </complexType> </element> </schema> </types> <message name="GetLastTradePriceInput"> <part name="body" element="xsd1:TradePriceRequest"/> </message> <message name="GetLastTradePriceOutput"> <part name="body" element="xsd1:TradePrice"/> </message> <portType name="StockQuotePortType"> <operation name="GetLastTradePrice"> <input message="tns:GetLastTradePriceInput"/> <output message="tns:GetLastTradePriceOutput"/> </operation> </portType> <binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="GetLastTradePrice"> <soap:operation soapAction="http://example.com/GetLastTradePrice"/> <input> <soap:body use="literal" namespace="http://example.com/stockquote.xsd encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/"/> </input> <output> <soap:body use="literal" namespace="http://example.com/stockquote.xsd" encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/"/> </output> </operation> </binding> </definitions> Figura 6 Exemplo de WSDL <tModel authorizedName="..." operator="..." tModelKey="..."> <name>StockQuote Service</name> <description xml:lang="en"> WSDL description of a standard stock quote service interface </description> <overviewDoc> <description xml:lang="en"> WSDL source document. </description> <overviewURL> http://example.com/stockquote.wsdl </overviewURL> </overviewDoc> <categoryBag> <keyedReference
tModelKey=" uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4" keyName="uddi-org:types" keyValue="wsdlSpec"/> </categoryBag> </tModel> Figura 7 Exemplo de tModel para o WSDL da Figura 6 <businessService businessKey="..." serviceKey="..."> <name>StockQuoteService</name> <description> (...) </description> <bindingTemplates> <bindingTemplate> (...) <accessPoint urlType="http"> http://example.com/stockquote </accessPoint> <tModelnstanceDetails> <tModelnstanceInfo tModelKey="..."> </tModelnstanceInfo> <tModelnstanceDetails> </bindingTemplate> </bindingTemplates> </businessService> Figura 8 BindingTemplate para o WSDL da Figura 6 referenciando o tModel da Figura 7
2.5
UDDI Schemas
UDDI usa a linguagem XML Schema para formalmente descrever sua estrutura de dados. A definio completa inclui 9 arquivos de esquema listados a seguir, cujos detalhes so apresentados em Bellwood [2004].
UDDI API Schema

UDDI Custody Schema UDDI Subscription Schema UDDI Subscription Listener Schema UDDI Replication Schema UDDI Value Set Validation Schema UDDI Value Set Caching UDDI Policy UDDI Policy Instance Parameters
3 Oracle Service Registry

Oracle Service Registry 10.3 corresponde a uma consolidao dos seguintes produtos anteriores BEA ALSR (BEA Aqualogic Service Registry), do fornecedor BEA antes de ter sido adquirida pela Oracle, e o Oracle OSR 10G (Oracle Service Registry) [ORACLE, 2008a].
Oracle Service Registry (OSR) est de acordo com a especificao UDDI V3 e corresponde a uma ferramenta composta de funcionalidades baseadas em padres para publicao e descoberta de web services e recursos relacionados como, por exemplo, XML Schemas ou transformaes XSLT. A ferramenta pode ser instalada na maioria dos ambientes Java e trabalha com os SGBDs (Sistemas Gerenciadores de Bancos de Dados) mais conhecidos. O registro armazena descries e metadados relacionados aos servios, tais como, polticas, classificaes e dependncias. O registro no armazena os ativos correspondentes, tais como, WSDLs, esquemas, e outros, mas ao invs disso ele aponta para estes ativos. O principal propsito do registro tornar disponvel estes metadados dos servios para serem consumidos por aplicaes para descoberta e uso este o motivo para o qual servios so publicados no registro para serem descobertos e utilizados por toda a empresa. O OSR trata funcionalidades para aplicaes da empresa, tais como: Segurana: permite definir controle de acesso granular para cada componente registrado. O responsvel pela publicao do componente pode definir permisses de acesso para operaes de localizao (find), recuperao (get), modificao e remoo para cada componente publicado; Mecanismos para controle de qualidade e preciso de dados: para garantir que componentes registrados esto precisos e atualizados em seus respectivos ambientes. OSR define responsabilidades para cada componente registrado. Ele oferece mecanismos para promoo e aprovao de componentes entre ambientes de desenvolvimento, controle de qualidade e produo; Subscrio e notificao: para automaticamente notificar usurios a respeito das mudanas nos componentes que eles dependem; Replicao seletiva entre mltiplos registros: permite propagao automatizada entre diferentes registros (por exemplo, entre registros internos e externos); Gesto avanada de taxonomia para garantir taxonomias bem definidas; Gesto de desempenho: para controle, logging e auditoria dos processos de publicao e descoberta; Desempenho e escalabilidade: pela implementao de algoritmos para pilhas de servios web e bancos de dados e suportando balanceamento de carga e clusterizao. O OSR no implementa algumas partes da especificao, como os requisitos de replicao, descrio de polticas e canonizao XML para assinaturas digitais [CANONICALIZATION, 2002]. O mapeamento entre WSDL e UDDI feito seguindo o padro especificado pela OASIS [WSDL-UDDI, 2004], o qual contempla o novo vocabulrio WSDL verso 2.0 [WSDL, 2008a]. O OSR faz parte da famlia Oracle Fusion Middleware e corresponde a um repositrio que permite configurar, tratar escalabilidade e segurana das informaes dos servios publicadas no repositrio. As principais caractersticas do OSR so: Permite que provedores de servio publiquem e divulguem suas ofertas de servios;
Permite que consumidores localizem e recuperem servios que estejam de acordo com suas necessidades; Serve como um ponto nico de controle para governana e garantia de polticas em uma abordagem SOA. Polticas referem-se a restries sobre entidades e restries de como um cliente pode usar um servio para facilitar o estabelecimento de um contrato entre um provedor de servio e um usurio do servio. Os principais benefcios do OSR so: Prov agilidade do negcio atravs de infraestrutura dinmica. Oferece controle do ambiente SOA atravs de polticas de publicao e atribuio em tempo de execuo. Facilita descoberta e reuso de servio em tempo de execuo. Com o OSR, aplicaes tm garantia de que requisies que tm obrigaes contratuais (tempo de resposta, disponibilidade etc.) so roteadas para a localizao do servio apropriada que est de acordo com o acordo contratual. uma fonte de autorizao para informao de referncias a endpoints DNS para servios. Minimiza necessidade de hardware adicional para escalabilidade ao permitir que organizaes adicionem localizaes adicionais para servios, registrando-os no OSR para localizao por consumidores no momento da requisio. Permite resilincia falha. Tendo um registro UDDI para identificao da localizao apropriada do servio permite que aplicaes no tenham mais que manter conexes ponto-a-ponto com localizaes de servios especficos, tornando mudanas e falhas mais transparentes para as aplicaes. O OSR integrado diretamente com outros produtos do Oracle Fusion Middleware, tais como Oracle BPEL Process Manager, Oracle Enterprise Service Bus, Oracle Service Bus, Oracle Web Services Manager e Oracle JDeveloper. O OSR uma soluo independente de plataforma que pode ser facilmente instalada com diferentes configuraes. O OSR tambm integra com diretrios LDAP 3 (Lightweight Directory Access Protocol), incluindo Oracle Internet Directory e Microsoft ActiveDirectory.
3.1
Instalao
O OSR pode ser instalado em diferentes plataformas. Em relao a sistemas gerenciadores de bancos de dados, ele se conecta com as seguintes verses de SGBDs: Oracle 10g Release 1, Oracle 9i Release 2, Microsoft SQL Server 2005 e DB2 8.0. O OSR pode ser instalado nos seguintes servidores de aplicao: Oracle Application Server (10.1.2 e 10.1.3) e Oracle WebLogic Server (9.2 e 10.3.0). O OSR permite escolher cinco tipos de instalao:
3
LDAP um protocol de aplicao para consulta e modificao de servios de diretrios executando sobre TCP/IP. Um diretrio corresponde a um conjunto de objetos com atributos organizados de uma maneira lgica e hierrquica. Um exemplo de diretrio uma lista telefnica.
Standalone Registry: Essa a instalao padro, na qual o servidor do OSR instalado no Oracle Application Server e conecta a um banco de dados de registro externo. Approval Process Registry: Neste caso, a instalao do OSR dividida em dois servidores, Publication registry e Discovery registry. O registro de publicao o servidor preliminar para publicao, teste e aprovao de dados. Depois que os dados esto aprovados, eles so promovidos para o registro de descoberta. O registro de descoberta configurado para pesquisas. External Accounts Integration: o servidor OSR pode ser opcionalmente configurado para usar contas externas em um servidor LDAP ou outro repositrio de contas. possvel configurar integrao de contas externas durante a instalao do banco de dados. Registry Cluster: Um cluster UDDI um grupo de registros UDDI instalados em mltiplos servidores provavelmente com um cluster de bancos de dados no back-end. Balanceamento de carga utilizado para distribuir solicitaes entre servidores OSR a fim de obter a melhor distribuio. Uma instalao de mltiplos registros deve ser escolhida se a organizao deseja impor um maior controle sobre os contedos dos registros disponveis para os consumidores. Este processo de controle de qualidade obtido pela separao dos registros de publicao e descoberta, e usando um processo de aprovao para promoo dos servios de um estgio para produo. O processo de aprovao pode ser configurado para usar aprovao manual ou automatizado para promover informaes. Algumas observaes importantes para este ambiente so: Cada registro requer um nico tablespace e esquema dentro de um banco de dados para servir os metados armazenados. Entretanto, ambos os tablespaces e esquemas podem ser criados dentro da mesma instncia do banco de dados. Os registros de publicao e descoberta podem ser instalados em hosts separados do OracleAS4 (Oracle Internet Application Server) [Oracle, 2009a] ou no mesmo host. Se ambos os registros forem instalados na mesma instncia do OAS, ento idealmente eles devem ser instalados em instncias separadas do OC4J5 [Oracle, 2009b], devido a requisitos de memria. Alm disso, uma ou mais instncias intermedirias de registros podem ser instaladas. Uma instncia intermediria de registro fica entre um ou mais registros de publicao e o registro de descoberta do nvel mais alto. Aps a instalao os seguintes diretrios so criados: bin: contm os scripts de linha de comando para executar o OSR; conf: contm os arquivos de configurao do OSR;
Oracle Internet Application Server prov uma soluo integrada para um infraestrutura de middleware incluindo Oracle Containers para J2EE, Oracle Web Cache, Oracle HTTP Server, Oracle Forms, Oracle Reports, Oracle Portal e Oracle Discoverer. Tambm includo nesta infraestrutura esto segurana integrada, gesto e tecnologias de integrao. Oracle Internet Application Server o component da famlia de produtos Oracle Fusion Middleware.
4
Oracle Containers for J2EE (OC4J) o componente principal de tempo de execuo de J2EE do Oracle Application Server.
5
demos: contm demonstraes de funcionalidades do OSR; dist: contm pacotes de clientes do OSR; doc: contm a documentao; etc: contm scripts e dados adicionais; log: contm logs de instalao, configurao, e sada do servidor; work: este diretrio a rea de trabalho usada pelas ferramentas de linha de comando. Maiores detalhes sobre instalao do OSR em ambiente Windows podem ser encontrados no (
Apndice 1).
3.2
Fluxo de aprovao
As mudanas realizadas sobre os servios podem ser controladas por um fluxo de aprovao definido. Alm disso, modificaes podem ser notificadas a usurios e processos sobre os elementos que foram alterados atravs da funcionalidade de subscrio e notificao do OSR. No OSR, a notificao pode ser sncrona ou assncrona. Na notificao sncrona, a parte interessada explicitamente pergunta sobre mudanas que ocorreram desde a ltima notificao, e o OSR responde. Notificaes assncronas executam periodicamente em um intervalo configurvel e a parte interessada notificada sempre que a entidade que atende a consulta criada, modificada ou removida.
3.3
Subscrio e notificao
O mecanismo de subscrio permite que usurios monitorem entradas novas, alteradas ou apagadas referentes a businessEntities, businessServices, bindingTemplates, tModels ou publisherAssertions. O conjunto de entidades que um usurio est interessado expressa por um filtro de subscrio (SubscriptionFilter), o qual pode ser qualquer uma das seguintes consultas de API de UDDI v3: find_business, find_tmodel find_relatedBusinesses, find_services, find_bindings,
get_businessDetail, get_serviceDetail, get_bindingDetail, get_tModelDetail, get_assertionStatusReport Alm disso, no Business Service Control, usurios podem criar subscries para recursos (WSDL, XML, XSD e XSLT) sem conhecimento detalhado de como os recursos so mapeados para estruturas de dados UDDI. Subscries podem ter os seguintes argumentos: chave de subscrio (SubscriptionKey), filtro de subscrio (SubscriptionFilter), tempo de expirao (Expires after), intervalo de notificao, nmero mximo de entidades, chave de ligao (bindingKey opcional - aponta para o bindingTemplate que inclui o endpoint do servio que trata a notificao) e resumo (brief por exemplo, se brief estiver habilitado apenas identificadores de entidades so enviados na notificao de businessEntity).
3.4
Classificao de servios usando taxonomias
Servios podem ser classificados no OSR, tanto ao nvel tcnico como do negcio, de acordo com taxonomias definidas. Alm disso, o OSR inclui um conjunto de servios de validao de taxonomia como definido pelas especificaes UDDI. Ele ainda permite a definio de taxonomias da empresa. Usurios podem baixar ( download) e publicar (upload) qualquer taxonomia como um arquivo XML. OSR oferece ferramentas para criar, modificar e navegar em taxonomias atravs de interface web e nveis de API SOAP. O negcio tambm pode especificar sua prpria classificao usando taxonomias que mapeiam as caractersticas especficas do negcio para facilitar a descoberta de servios. No Apndice 10 apresentado um roteiro para associar um servio de negcio a um provedor de negcio, enquanto que no Apndice 12 apresentado como utilizar taxonomias para pesquisar servios. Classificaes podem ser estendidas para
especificar dados adicionais, por exemplo, criao de campos de dados adicionais para serem associados aos WSDLs ou interfaces dos servios durante a publicao. O servio de validao interna faz a checagem para garantir que uma categorizao especfica est vlida dentro de uma taxonomia.
3.5
Segurana
OSR permite definir que mltiplos usurios ou perfis possam ter acesso para modificar ou apagar uma entidade especfica UDDI. O Apndice 4 apresenta um roteiro para gerenciamento de permisses de usurios e grupo de usurios. A segurana no OSR feita atravs de uma extenso do ACL (Access Control List) para o modelo de segurana de UDDI. Cada entidade UDDI pode estar associada com a ACL que define quem pode encontr-la (find - list-la em algum resultado de consulta UDDI), recuperar (get recuperar todos os detalhes do objeto do UDDI), modific-la ou apag-la. O ACL pode referenciar ambos a conta de um usurio especfico ou grupo de usurios. A verso 3 da especificao UDDI prov suporte para assinaturas digitais. No OSR, o publicador da estrutura do UDDI pode digitalmente assinar esta estrutura. A assinatura digital pode ser validada para verificar se as informaes no podem ser modificadas por nenhuma razo e confirmar a identidade do publicador. O contedo do registro UDDI pode ser replicado no OSR usando o modelo de master e escravo (master-slave). O registro UDDI pode replicar dados de acordo com mltiplas definies de replicao que so definidas usando consultas padro do UDDI. A relao master-slave especfica a uma definio de replicao. Logo, um registro pode ser master para uma definio de replicao especfica e escravo para outra. As definies de segurana (ACL, usurios e grupos) no esto sujeitas replicao, mas podem ser ajustadas permisses sobre os dados replicados. O OSR possui uma ferramenta web de controle de servios de negcio que permite que usurios no familiares com UDDI possam olhar modelos publicados (WSDL, XML Schema, XSLT, BPEL, etc.) ao invs de terem que analisar tModels e entidades do negcio, reduzindo custo de treinamento e tempo de implementao de servios de negcio.
3.6
Processo de aprovao
O processo de aprovao prov funcionalidades para garantir consistncia e qualidade de dados armazenados no OSR. Dois tipos de registros esto envolvidos no processo: Registro de publicao: usado para teste e verificao de dados; Registro de descoberta: contm apenas dados que foram aprovados e promovidos do registro de publicao. Dois tipos de usurios esto envolvidos no processo de aprovao: Um requisitante que o usurio do registro de publicao que pode requisitar aprovao de dados para promoo para o registro de descoberta. Alm disso, o requisitante pode pesquisar, obter e cancelar requisies, alm de sincronizar dados do registro de publicao com os dados do registro de descoberta;
Um avaliador (approver) que o usurio que pode aprovar ou rejeitar requisies por promoes de dados. Administradores podem especificar: Usurios ou grupos de usurios que podem ser avaliadores; Usurios ou grupos de usurios cujas requisies eles podem validar. Cada usurio pode requisitar por aprovao, mas para ter dados considerados para promoo, um usurio deve ter um validador atribudo pelo administrador. Ou seja, o usurio pode solicitar que um determinado dado seja validado, mas pode no ter permisso para solicitar que ele seja promovido. O ciclo de aprovao apresentado na Figura 9. Um requisitante pode criar uma requisio. Uma vez a requisio criada, o requisitante pode adicionar estruturas UDDI ou recursos (WSDL, XML, XSD e XSLT) na requisio. Observe que o requisitante no precisa saber como recursos so mapeados para estruturas de dados do UDDI. Quando um requisitante adiciona um recurso requisio, todas as estruturas UDDI (bindings, tModels) que o recurso representa so automaticamente adicionadas requisio. Uma vez que o requisitante especifica todas as entidades para serem promovidas, a requisio submetida para aprovao. Neste momento, todos os dados referenciados pela requisio ficam bloqueados para escrita at que a requisio cancelada pelo requisitante ou aprovada ou rejeitada pelo avaliador.
Figura 9 Ciclo de aprovao
O avaliador avalia a requisio, e ento aprova ou rejeita a requisio. Se o avaliador aprova a requisio, ela imediatamente promovida para o registro de descoberta. Se o requisitante no est satisfeito com o tempo da aprovao, o usurio pode lembrar o avaliador de revisar suas requisies. O requisitante tambm pode cancelar requisies. O OSR realiza checagem de contexto para garantir a consistncia das requisies sendo realizadas no registro de publicao para serem publicadas no registro de descoberta como, por exemplo, verificar se est sendo requisitada a remoo de um dado que no existe no registro de descoberta.
Um requisitante pode receber o status de auto-avaliador (AutoApprover). Neste caso, todas as requisies deste usurio so automaticamente promovidas, sem ocorrer o fluxo de aprovao. Opcionalmente uma validao de contedo (content checking) pode ser definida pelo aprovador, por exemplo: cada businessService deve incluir um templateBinding; cada businessService deve estar categorizado em determinadas categorias. Para realizar estas validaes, o avaliador deve escrever uma implementao na API de checagem (API Checker) para garantir estas checagens. No processo de aprovao, e-mails de notificaes so enviados para requisitante e avaliadores quando ocorrem aes sobre dados que eles esto envolvidos. O formato do email definido por transformaes XSL.
3.7
Consoles do OSR
O OSR prov duas interfaces com o usurio para gesto de entidades do OSR. O Business Service Control permite que desenvolvedores, arquitetos e usurios do negcio possam navegar sobre infomaes de esquemas, nomes locais de interfaces ou namespaces etc. Alm disso, ele permite realizar publicaes usando wizards de publicao. O Business Service Control pode ser encontrado na URL <http://<Business Service Control hostname>:<port>/<context>/uddi/bsc/web>. A porta padro 8888 ou 80 dependendo da configurao do servidor de aplicao. Usando o Registry Control, usurios podem navegar e publicar contedo no registro, criar subscries e realizar mudanas de propriedade. Esta a principal ferramenta para administradores realizarem gesto do registro. O Registry Control pode ser encontrado na URL <http://<hostname>:<port>/<context>/uddi/web>. A porta padro 8888 ou 80 dependendo da configurao do servidor de aplicao. Existem dados pr-instalados no OSR para uso do Business Service Control e do Registry Control. 3.7.1 Business Service Control
O Business Service Control tem os seguintes itens de menu: Home: pgina inicial Catalog: permite listar, pesquisar e publicar entidades Tools: permite visualizar e gerenciar subscries e requisies de aprovao Report: permite visualizar o conjunto pr-definido de relatrios Configure: permite configurar o Business Service Control. A Figura 10 e a Figura 11 apresentam exemplos de telas do Business Service Control: aba Catalog do Business Service Control e pgina de listagem de WSDL de servios. As letras destacam funcionalidades importantes da ferramenta, estas funcionalidades so descritas em [Oracle, 2008a].
Figura 10 Pgina da funcionalidade Catalog do Business Service Control
Figura 11 Pgina de listagem de WSDL de servios do Business Service Control
3.7.1.1 Conta de usurio Antes de publicar dados no OSR, necessrio ter uma conta no mesmo. Ao cadastrar uma conta, cujos passos so apresentados no Apndice 2, dentre as informaes que devem ser preenchidas destacam-se: Intervalo de notificao padro: especifica o intervalo que e-mails de notificao sero enviados. Nmero mximo de entradas a serem enviadas em um nico email.
Exibir atualizaes realizadas no ltimo perodo, por exemplo, 3 dias. 3.7.1.2 Perfis previamente definidos O OSR possui uma lista de perfis (profiles) previamente definidos. Eles diferem nos itens das abas que estaro disponveis para cada um. Cada profile tambm contm uma definio dos formatos padres para visualizaes de resultados. O administrador do registro pode atualizar estes profiles: Business Expert: entende os problemas que precisam ser resolvidos e relacionamentos e implicaes em relao a outros sistemas dentro da empresa. Ele prope componentes funcionais reutilizveis (servios de negcio futuro) e como eles resolvem problemas especficos. Este usurio associa requisitos funcionais (descries) e no funcionais (capacidades e restries em alto nvel) aos componentes. Ele tambm sugere reuso de servios existentes. Developer: Implementa servios de negcio de acordo com descries e restries/capacidades associadas aos servios. Este usurio reutiliza infraestrutura de baixo nvel para servios para realizar a implementao. Depois do desenvolvimento, servios de negcio tm sua qualidade avaliada (QA Quality Assurance) e so testados. SOA Architect: refatora as entradas do Business Expert. Este usurio realiza o seguinte: o o Traduz instalaes definidas pelo Business Expert em um conjunto de servios de negcio reutilizvel. Transforma capacidades e restries em alto nvel para capacidades e restries baseadas em padro que podem ser garantidos e implementados por outros papis (desenvolvedores, administradores e gerentes de operao). Define capacidades e restries (tais como restries de acordo) que garantem estar de acordo a padres e implementaes comuns e prticas de desenvolvimento de servios da empresa. Garante que servios esto de acordo com padres (SOAP, WSDL, UDDI, WS-S, WS-RM etc.). Sugere reuso de servios existentes.
o o
Operator: disponibiliza e gerencia no ambiente de produo os servios de negcio implementados pelo Developer. o o Publica endpoint de servios e outros dados de tempos de execuo sobre o servio instalado. Garante que servios de negcio esto sendo gerenciados e seguros apropriadamente pela marcao do servio com categorias apropriadas que inicia segurana e o processo de registro no WSM (Web Service Manager6).
Oracle Web Services Manager uma soluo para gesto de poltica e segurana da infraestrutura de servios. Ele prov visibilidade e controle de polticas atravs de interface de administrao centralizada oferecida pelo Oracle Enterprise Manager.
SOA Administrator: realiza as mesmas funes do operator, mas com maiores privilgios. Anonymous User Profile: este perfil se aplica a usurios no atenticados. O perfil uma configurao para usurios que no esto logados no Business Service Control. 3.7.1.3 Pesquisa por entidades O OSR permite realizar pesquisas por provedores, servios, endpoints, interfaces e artefatos publicados. A Figura 12 apresenta a tela de pesquisa do OSR.
Figura 12 Tela de pesquisa
Pesquisas podem utilizar wildcards (por exemplo, %) e so customizadas para cada tipo de pesquisa. A Figura 13 apresenta a tela de pesquisa por endpoints. Observe que se pode pesquisar por propriedades operacionais, tais como, disponvel, indisponvel, degradado, em manuteno, em teste etc.
Figura 13 Tela de pesquisa por endpoints
Resultados podem ser customizados, como apresentado na Figura 14. Observe que o formato de visualizao pode ser definido. Por exemplo, uma das opes visualizao tcnica (Technical View).
Figura 14 Resultado de busca por endpoint
3.7.1.4 Publicao Pode-se publicar os seguintes dados no OSR: Provedores: nome do provedor e descrio, classificao taxonmica do provedor e pessoas de contato. O Apndice 5 apresenta um roteiro para publicao de provedores. O ltimo passo para publicao do provedor definir se ser realizado um fluxo de aprovao.
Servios: wizard para publicao do servio, suas interfaces e seus endpoints. Interfaces Recursos: arquivos WSDL, XML, XML Schema e XSLT. O ltimo passo para publicao definir se ser realizado um fluxo de aprovao. Um servio pode ser publicado a partir de um WSDL ou sem WSDL. A URL do WSDL do servio que se deseja publicar pode ser encontrada utilizando a aplicao de busca de servio Web Services Inspection Language7 (WSIL) disponibilizado pelo Oracle Applicaton Server, ou diretamente a partir do arquivo WSDL armazenado em algum diretrio. Os passos para publicao de servio a partir do seu WSDL so apresentados nas figuras: Figura 15, Figura 16, Figura 17, Figura 18 e Figura 19.
Figura 15 Publicao de WSDL
Figura 16 Preenchimento de credenciais para autenticao
http://www.ibm.com/developerworks/library/specification/ws-wsilspec/
Figura 17 Publicao de propriedades do servio
Figura 18 Publicao das propriedades da interface do servio
Figura 19 Publicao das propriedades do endpoint do servio
Maiores detalhes sobre publicao de um servio utilizando WSDL no OSR podem ser encontrados no Apndice 6. 3.7.1.5 Relatrios O Business Service Control contm um conjunto pr-definido de relatrios, como apresentado na Figura 20. Os relatrios do primeiro nvel da rvore listam servios, endpoints ou interfaces de acordo com as taxonomias: systinet-com:taxonomy:usage; systinet-com:taxonomy:endpoint:status; systinet-com:taxonomy:interface:status; uddiorg:xml:namespace taxonomy; uddi-org:xml:localName; systinetcom:taxonomy:service:certification; systinet-com:taxonomy:endpoint:availability; ws-iorg:conformsTo:2002_12; systinet-com:versioning:milestone; systinetcom:versioning:releaseDate; systinet-com:versioning:version.
Figura 20 Relatrios pr-definidos no Business Service Control
3.7.1.6 Subscries e notificaes Subscries podem ser criadas no OSR para alertar usurios interessados em acompanhar mudanas em estruturas existentes no OSR. O Business Service Control permite criar e gerenciar subscries para monitoramento de entidades novas, alteradas ou apagadas. As seguintes entidades podem ser monitoradas: provedores, servios, interfaces e endpoints, bem como recursos (WSDL, XML, XSD e XSLT). Uma subscrio pode ser definida para um conjunto de entidades que se esteja interessado ou a uma consulta de busca especfica. Usurios podem receber notificaes sobre estruturas modificadas via email ou eles podem visualizar as modificaes das entidades utilizando ferramentas do OSR, em My Subscription Results. No caso de escolhido receber notificaes por email, ento se pode configurar o intervalo de notificao. A Figura 21 apresenta um exemplo de criao de subscrio para o provedor HR Services, enquanto que a Figura 22 apresenta os ajustes de notificao para acompanhamento das mudanas no provedor escolhido. Os passos para criar uma subscrio a partir de uma busca so os mesmos, exceto pelo fato de ter sido feita uma busca antes de se chegar listagem das entidades que atendem a pesquisa, ou seja, antes de se ter a tela apresenta na Figura 21. A Figura 23 mostra a tela de criao de subscrio para uma consulta de servios, ou seja, tendo sido realiza antes uma busca por servios. importante notar que no possvel modificar a consulta para a qual foi feita uma subscrio. Logo, se for necessrio alter-la, ento necessrio cancel-la e recri-la.
Figura 21 Criao de subscrio para provedor HR Services
Figura 22 Ajustes de parmetros de notificao da subscrio
Figura 23 Tela de criao de subscrio a partir de busca por servios
Para revisar e ajustar subscries deve-se utilizar a funcionalidade Manage My Subscriptions (Figura 24).
Figura 24 Tela de gerncia de subscries
3.7.1.7 Configurao Na aba Configure possvel configurar [Oracle, 2008b]: Tabs Display: permite definir as abas que sero exibidas para os usurios que tm um perfil especfico.
Search Result View Display: permite configurar os tipos de visualizaes de resultado para cada perfil de usurio. Browsable Taxonomies: permite definir quais taxonomias so navegveis. User Interface Configuration: permite configurar a interface do Business Service Control. Por exemplo, customizar URL do registro, diretrio onde ficaro as pginas estticas, diretrio para Upload etc. Customizable Taxonomies: permite definir quais taxonomias podem ser customizadas pelos usurios quando este estiver criando, editando ou pesquisando entidades. 3.7.2 Registry Control
O Registry Control utilizado por administradores de sistema e usurios avanados para configurao de sistema, e gerncia de usurios e segurana, e manipulao direta do modelo de dados do UDDI. As principais funcionalidades do Registry Control so: Navegao (Browse): permite navegar em entidades do UDDI utilizando taxonomias. Pesquisa: permite realizar pesquisa no registro. Pode-se realizar uma busca nas entidades do UDDI e encontrar businessEntity, servios, bindings, tModels, etc. Publicar: permite publicar estruturas businessServices, bindingTemplates e tModels). do UDDI (businessEntity,
Profile: para gesto de propriedades de contas de usurios, grupos de contas e taxonomias. Manage: permite realizar tarefas de gesto. A interface principal do Registry Control apresentada na Figura 25. As letras destacam as funcionalidades e so descritas em detalhes em [Oracle, 2008a].
Figura 25 Interface do Registry Control
3.7.2.1 Perfil de usurio Para o usurio logado alterar dados de sua conta, ele deve clicar em Profile (Figura 26), em seguida, clicar em My account e ento em Edit account (Figura 27). Tambm possvel editar grupos (Figura 28) e a associao de grupos com usurios (Figura 29).
Figura 26 Detalhes do menu Profile
Figura 27 Tela de visualizao de conta de usurio
Figura 28 Tela de visualizao de grupos de usurios
Figura 29 Edio de relacionamento de grupos e usurios
O usurio pode definir quais so suas taxonomias favoritas. Taxonomias favoritas ajudam na pesquisa e categorizao de entidades UDDI. A Figura 30 apresenta a tela de gerncia de taxonomias favoritas. esquerda so listadas todas as taxonomias existentes, enquanto que direita esto as taxonomias favoritadas escolhidas utilizando os botes > e <.
Figura 30 Tela de gerncia de taxonomias favoritas
Maiores detalhes sobre o gerenciamento de perfs de usurios e grupos no OSR podem ser obtidos em Apndice 2 e Apndice 3, respectivamente. 3.7.2.2 Navegao No item de menu Browse pode-se realizar pesquisas por taxonomias (Figura 31). Um exemplo de pesquisa por filtro apresentado na Figura 32.
Figura 31 Item de menu Browse
Figura 32 Exemplo de pesquisa na taxonomia demo:location:floor
O nmero de taxonomias listadas pode ser reduzido atravs da definio de filtro (Figura 33).
Figura 33 Tela de definio de filtro
Tambm possvel combinar critrios de pesquisa em uma consulta. Para isto, utilize o boto Add to queryapresentado na Figura 32. Dessa forma, possvel expandir uma nova taxonomia e especificar um novo critrio. Um resultado de consulta apresentado na Figura 34.
Figura 34 Resultado de busca considerando dois critrios
3.7.2.3 Pesquisa Utilizando o Registry Control, possvel pesquisar por: Estruturas de dados do UDDI: BusinessEntity, BusinessService, BindingTemplate e tModel. Acesso direto (Direct get): pode-se recuperar dados do OSR quando se sabe a chave da entidade UDDI que se deseja recuperar. Recursos: WSDL, XML, XSD e XSLT. 3.7.2.3.1 Pesquisa por BusinessEntity BusinessEntity podem ser pesquisadas por nome, categorias, identificadores, URL de descoberta e tModel. Na Figura 35, estas opes foram destacadas direita. Para todos os tipos de pesquisa, qualificadores podem ser especificados (Figura 35). Aps a pesquisa, os destalhes do BusinessEntity retornado podem ser visualizados (Figura 36).
Figura 35 Tela de definio de qualificadores de pesquisa
Figura 36 Tela de detalhes do BusinessEntity
Na busca por categoria (Figura 37), mais de uma categoria pode ser adicionada, utilizando o boto Add category. Pode-se pesquisar tambm por um intervalo de valores (Figura 38).
Figura 37 Busca por BusinessEntity por categoria
Figura 38 Busca por BusinessEntity por intervalo de categoria
Na busca por identificadores (Figura 39), pode-se adicionar mais de um identificador na pesquisa.
Figura 39 - Busca por BusinessEntity por identificadores
Na busca por URL de descoberta, deve-se clicar na opo Discovered URLs(Figura 35), digitar a URL de pesquisa, na tela que se abre, e clicar no boto Find. 3.7.2.3.2 Pesquisa por BusinessService, BindingTemplate e tModel A pesquisa por BusinessService, BindingTemplate e tModel semelhante a pesquisa por BusinessEntity, descrita na seo anterior.
3.7.2.3.3 Pesquisa por acesso direto A pesquisa por acesso direto (Figura 40) permite especificar chaves na verso 2 ou 3 de UDDI.
Figura 40 Tela de pesquisa por acesso direto
Tambm possvel obter o formato XML de BusinessEntity, BusinessServices, BindingTemplates e tModels para uso em processamento automatizado pela digitao da chave da estrutura em uma URI. A forma da URI :
http://<hostname>:<port>/<context>/uddi/web/directGetXml?<structureKey >=<key>
Exemplos na verso 3 do UDDI so apresentados a seguir: http://localhost:8888/registry/uddi/web/directGetXml?businessKey=udd i:systinet.com:uddinodebusinessKey http://localhost:8888/registry/uddi/web/directGetXml?serviceKey=... http://localhost:8888/registry/uddi/web/directGetXml?bindingKey=... http://localhost:8888/registry/uddi/web/directGetXml?tModelKey=... 3.7.2.3.4 Pequisa por WSDL, XML, XSD e XSLT Telas de pesquisa por WSDL, XML, XSD e XSLT so apresentadas nas Figura 41, Figura 42, Figura 43 e Figura 44, respectivamente.
Figura 41 Tela de pesquisa por WSDL
Figura 42 Tela de pesquisa por XML
Figura 43 Tela de pesquisa por XSD
Figura 44 Tela de pesquisa por XSLT
3.8
Controle de acesso
Uma das formas de especificar controle de acesso no OSR utilizar permisso de acesso a dados ACL (Access Control List). Uma ACL composta de: Parte: usurio ou grupo de usurios Estrutura principal: uma das principais estruturas de dados do UDDI: businessEntity, businessService, bindingTemplate ou tModel.
Ao: uma operao "find", "get", "save", ou "delete" sobre a entidade, e uma ao especial create, que indica que podem ser realizadas alteraes em sub-entidades. Por exemplo, o usurio com a permisso create em um businessService pode salvar novos bindingTemplates abaixo do businessService, mas no pode atualizar o businessService como um todo. Esta operao s faz sentido para businessEntity e businessService pois bindingTemplates e tModels no tm sub-entidades. ACL sobrepem o controle de acesso padro do UDDI, pois, segundo o padro, apenas o proprietrio da estrutura principal do UDDI pode atualizar ou remov-la. Cada usurio pode procurar ou obter a estrutura. Quando uma permisso no explicitamente definida para as operaes find/get, qualquer usurio pode execut-las. Quando nenhuma permisso est definida explicitamente para as aes save/delete em uma entidade, apenas o proprietrio da entidade pode salv-la ou apag-la. Este o funcionamento do controle de acesso padro do UDDI. Quando uma permisso explcita ajustada para uma ao, um controle de acesso totalmente diferente utilizado, seguindo as seguintes regras. Proprietrio sempre tem controle total. Uma permisso negativa para usurio sobrescreve uma permisso positiva para usurio se forem definidas para o mesmo objeto. O mesmo ocorre para o caso de grupo. Permisso para usurio tem mais peso do que permisso para grupo. O proprietrio de uma entidade pode sempre executar get_XXX sobre uma sub-entidade direta. Permisses positivas para delete e save so herdadas de entidades pais e sobrescrevem permisses negativas em sub-entidades. Para realizar atualizao com a operao save_XXX, necessrio ter ambas as permisses save e get. Maiores detalhes sobre segurana no OSR so encontrados em [Oracle, 2008a] e no Apndice 7 apresentado um roteiro para controlar o acesso a um servio de negcio no Oracle Service Registry.
3.9
Taxonomia
Uma taxonomia, ou conjunto de valores na terminologia da especificao UDDI, um tModel que pode ser usado em categoryBags, identifier bags, ou Publishser Assertions. Este tModel deve estar em um formato especfico para que o OSR possa reconhec-lo como uma taxonomia. O tModel deve ser categorizado com o tipo de taxonomia e, opcionalmente, com informao a respeito se e como validar os valores em keyedReferences. Por exemplo, nmeros de taxa US ou ISBN s fazem sentido se sabe-se que eles so nmero de taxas dos Estados Unidos ou ISBNs. Categorizaes um dos conceitos mais importantes em um UDDI. Qualquer entidade UDDI pode estar associada com uma categoria que definida em alguma taxonomia. Uma categoria essencialmente um par composto por nome e valor e uma taxonomia um conjunto organizado hierarquicamente de categorias. Categorias podem ser usadas pra pesquisar por entidades do UDDI, como por exemplo, a localizao de servios de negcio (Apndice 12). Existem categorias criadas
previamente no UDDI. Alm disso, existem taxonomias criadas por empresas que esto disponveis para serem utilizadas, tais como, taxonomia para mecanismos de autenticao segura, taxonomia para tipo de componente distribudo etc. O registro UDDI permite tambm a definio de taxonomias customizadas construdas especificamente para organizaes ou aplicaes [Oracle, 2008b]. A especificao UDDI distingue quatro tipos de taxonomias: Categorizaes: podem ser usadas em todas as quatro estruturas do UDDI. Elas so usadas para marcar as estruturas com informaes adicionais, tais como identidade, localizao, e o que mais a taxonomia descrever. Grupos de categorizao: agrupam vrias categorizaes em uma categorizao lgica. Por exemplo, uma localizao geogrfica incluindo duas categorizaes: longitude e latitude. Identificadores: usados em businessEntity e tModels referenciam informaes pblicas. Relacionamentos: usados apenas em Publisher Assertions, definem o relacionamento entre duas businessEntities. O Apndice 8 apresenta um Roteiro para criar taxonomias no Oracle Service Registry.
3.10 Mapeamento de recursos

Esta seo descreve o mapeamento dos seguintes recursos para um UDDI: WSDL, XML, XSD e XSLT. 3.10.1 Mapeamento de WSDL O mapeamento de elementos de um WSDL (Tabela 1) para um UDDI ocorre como esquematizado na Figura 46 e detalhado a seguir.
Tabela 1 Elementos de um WSDL
Elemento <types> <message>
Descrio Definies de tipos para o contedo das mensagens. Definio abstrata do tipo de dados sendo transmitido. Uma mensagem consiste de partes, as quais descrevem o contedo lgico e abstrato de uma mensagem. Coleo abstrata de operaes suportadas pelo servio. Descrio abstrata de uma ao suportada pelo servio. Cada operao refere-se a uma mensagem de entrada e mensagem de sada. Define o protocolo concreto e especificaes de formato de dados para as operaes e mensagens definidas por um determinado portType. Especifica um endereo para um binding, portanto definindo um endpoint de comunicao nico. Coleo de portas ou endpoints.
<portType> <operation>
<binding>
<port> <service>
Definies WSDL Types Messages PortType Binding Service Port
Figura 45 Elementos de um WSDL
Figura 46 Esquema de mapeamento de WSDL para o UDDI
Cada portType do WSDL mapeamento em um tModel como apresentado na Tabela 2.

Tabela 2 Mapeamento de portType para o UDDI
WSDL
portType Namespace do portType Nome local do portType Localizao do WSDL 3.
UDDI
tModel (categorizado como portType) keyedReference no categoryBag Nome do tModel overviewURL
Cada binding do WSDL mapeamento em um tModel como apresentado na Tabela

Tabela 3 Mapeamento de binding para o UDDI
WSDL
Binding
UDDI
tModel (categorizado como binding e wsdlSpec)
Namespace do binding Local name do binding Localizao do WSDL portType binding Protocol Transport
keyedReference no categoryBag Nome do tModel overviewURL keyedReference no categoryBag keyedReference no categoryBag keyedReference no categoryBag
A seo service representada como businessService do UDDI, como apresentado na Tabela 4. O businessService tambm contm um bindingTemplate contendo: O tipo de acesso categorizado como um ponto de acesso do servio. O portType categorizado como o tModel do portType. O binding categorizado como o tModel da informao de binding. O nome local categorizado como o nome local do port.
Tabela 4 Mapeamento da seo service para o UDDI
WSDL
Service Namespace do service Nome local do service
UDDI
businessService (categorizado como service) keyedReference no categoryBag keyedReference no categoryBag; opcionalmente nome usado do service
No Oracle Service Registry, existem funcionalidades para publicar um WSDL, definir uma nova forma de mapeamento de WSDL, pesquisar por um WSDL pela localizao do WSDL, desregistrar ou republicar um WSDL. O mapeamento captura informao suficiente dos documentos WSDL para permitir consultas precisas por web services sem ter que acessar os documentos WSDL fontes e permitir que os documentos WSDL apropriados sejam recuperados uma vez que uma combinao de busca tenha sido alcanada. 3.10.2 Mapeamento de arquivo XML Um arquivo XML mapeado para um tModel seguindo o formato apresentado na Figura 47. A localizao do arquivo XML adicionada ao elemento overviewURL do tModel. Namespaces so mapeamdos para keyedReferences no categoryBag do tModel. Cada namespace mapeado para um tModel.
Figura 47 Mapeamento de XML para UDDI
O OSR permite publicar um documento XML e tambm possvel definir a forma de mapeamento de documento XML. Alm disso possvel desregistrar ou republicar um arquivo XML. O OSR permite pesquisar por um documento XML das seguintes maneiras: Pesquisar por um arquivo XML contendo dados de um determinado tipo (XSD). Pesquisar por um arquivo XML de uma pasta ou servidor especfico, usando um critrio de busca, prefixo URI e caracteres especiais. Pesquisar por um arquivo XML que entrada ou sada de um XSLT especfico. Pesquisar por um processador de um arquivo XML de entrada especfico. 3.10.3 Mapeamento de arquivo XSD Um arquivo XSD mapeado para um tModel como apresentado na Figura 48. A URI de localizao do arquivo XSD colocado no element overviewURL do tModel e o target namespace mapeado para um keyedReference no categoryBag do tModel. Os xsd:types, xsd:elements e xsd:imports so mapeados para keyedReferences no tModel. Para cada tipo, elemento ou import, um novo tModel criado.
Figura 48 Mapeamento de XSD para o UDDI
O OSR permite publicar, desregistrar e republicar arquivos XML Schema. Alm disso, ele permite especificar como artefatos do XML Schema devem ser mapeados para estruturas existentes no UDDI. Em relao pesquisa, permitido: Pesquisar por um XML Schema que importa artefatos declarados em um arquivo XSD especfico. Pesquisar por XML Schema localizado em um servidor ou pasta especfica. Pesquisar por todos os XSLT que podem processar documentos usando um XSD especfico. Pesquisar por todos os XSLT que produzem documentos que usam um XSD especfico. 3.10.4 Mapeamento de arquivo XSLT O mapeamento de XSLT para UDDI apresentado na Figura 49. A URI de localizao do arquivo XSLT adicionada ao elemento overviewURL do tModel. Namespaces so mapeados em keyedReferences no categoryBag do tModel. Elementos xsl:import so tambm mapeados para keyedReferences no categoryBag do tModel. Para cada import e namespace, um novo tModel criado.
Figura 49 Mapeamento de XSLT para o UDDI
O OSR permite publicar um XSLT, bem como especificar como artefatos de um arquivo XSLT sero mapeados para estruturas existentes no UDDI.
3.11 Desenvolvimento do lado do cliente e do servidor

Do lado do cliente, o desenvolvimento pode utilizar: APIs do UDDI para pesquisar e publicar informaes no registro. APIs avanadas para validao, taxonomias, categorias, aprovao, utilitrios de administrao, replicao, estatsticas, pesquisa, subscrio e publicao de recursos. APIs de segurana para tratar contas, grupos e permisses. Alm disso, possvel preparar um cliente para distribuio para acessar o OSR via interface SOAP e criar um cliente que se autentica utilizando HTTP bsico. Detalhes a respeito destas funcionalidades so apresentados em [Oracle, 2008a]. O manual [Oracle, 2008a] detalha atividades que podem ser realizadas do lado do servidor, tais como: Acesso de APIs de backend via servlet instalado no servidor de aplicao. Mdulos de customizao do OSR Uso de interceptors para monitorar ou modificar requisies e respostas do OSR. Escrita de servios de validao customizados
Escrita de servios de notificao de subscrio. Framework JSP.
3.12 Integrao do OSR com OSB

O OSR e o OSB (Oracle Service Bus [Azevedo, 2009]) tm forte integrao pelo fato de que servios registrados no OSR podem ser automaticamente pesquisados e consumidos a partir do OSB console. OSB automaticamente cria servios de negcio e artefatos dependentes quando consome servios do OSR. Por exemplo, pela definio de fluxos dentro do OSB utilizando os servios registrados no OSR. De maneira anloga, servios de proxy podem ser exportados do OSB para o OSR para registro automatizado de servios de proxy no OSR. Isto facilita a localizao dos servios de proxy pelos usurios e taxonomias especficas do OSB podem ser utilizadas no registro. No se deve confundir o registro do OSB com o OSR. O registro do OSB um mecanismo de pesquisa local apenas. Ou seja, ele permite pesquisar e usar servios internamente. Ele no um registro UDDI nem tem a inteno se de expor ativos no OSB para uso fora do OSB. J o OSR um registro no nvel da empresa que permite qualquer consumidor pesquisar e navegar por servios armazenados no registro. O OSR tambm prov governana com workflow e aprovaes para gerenciar o ciclo de vida de servios. O roteamento de servios utilizando OSB e OSR ilustrado na Figura 50, e inclui os seguintes passos: 1. Consumidor do servio envia requisio juntamente com metadados do contrato. 2. OSB invoca OSR para localizar endpoint que esteja de acordo com a definio do contrato. 3. OSR envia endpoint apropriado para o OSB. 4. OSB roteia requisio para o endpoint retornado. 5. Provedor processa a requisio e envia a resposta para o OSB. 6. OSB roteia resposta para o consumidor do servio.
Consumidor do servio
6 5
Oracle Service Bus

4
Oracle Service Registry
Provedor do servio Figura 50 Roteamento dinmico considerando OSB e OSR
4 Concluses
As especificaes UDDI formam a fundamentao tcnica necessria para publicao e descoberta de implementaes de web services [Bellwood et al., 2004]. Ele atua em conjunto com o Enterprise Service Bus, sendo tambm uma das ferramentas mais importantes para implantao de SOA em uma organizao. Dessa forma, o correto entendimento da especificao UDDI e de ferramental de apoio intrnseco para o sucesso de SOA. Este relatrio apresentou as principais caractersticas da especificao UDDI verso 3.0 e apresentou um estudo do OSR (Oracle Service Registry), ferramenta da Oracle que implementa a especificao.
5 Referncias
AZEVEDO, L.G., SOUSA, H.P., SANTORO, F., BAIO, F., Estudos de ESB e anlise do OSB. Relatrio tcnico Petrobras/GDIEP, 2009. (a ser publicado) BELLWOOD et al., T., UDDI Version 3.0.2. UDDI Spec Technical Committee Draft, 2004. Disponvel em <http://www.oasis-open.org/committees/uddispec/doc/spec/v3/uddi-v3.0.2-20041019.htm>. Acessado em 27 Nov. 2009. CANONICALIZATION, Exclusive XML Canonicalization Version 1.0, 2002. Disponvel em <http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/>. Acessado em 25 Nov. 2009. COLGRAVE, J., JANUSZEWSKI, K., Using WSDL in a UDDI Registry, Version 1.08. OASIS UDDI Spec TC, 2002. ORACLE. Oracle Fusion Middleware Service Registry 10g Release 3 (10.3) E13665-01. Oracle Corporation, 2008a. Disponvel em < http://download.oracle.com/otndocs/tech/soa/OSR103ProductDocumention.p df>. Acessado em 25 Nov. 2009. ORACLE. BEA Aqualogic Registry Repository 3: Create an It Ecosystem Student Guide. Oracle Corporation, vol. II, 2008b. OASIS, OASIS UDDI Specifications TC - Committee Best Practices, Advancing Open Source Standards for Information Society (OASIS). Disponvel em < http://www.oasis-open.org/committees/uddi-spec/doc/bps.htm>. Acesso em 27 Nov. 2009b. OASIS, OASIS UDDI Specifications TC - Committee Technical Notes, Advancing Open Source Standards for Information Society (OASIS). Disponvel em < http://www.oasis-open.org/committees/uddi-spec/doc/tns.htm>. Acesso em 27 Nov. 2009b. ORACLE. Oracle Internet Application Server. Oracle Corporation. Disponvel em <http://www.oracle.com/technology/products/ias/index.html>. Acessado em 25 Nov. 2009a. ORACLE. Oracle Containers for J2EE (OC4J). Oracle Corporation. Disponvel em <http://www.oracle.com/technology/tech/java/oc4j/1013/index.html>. Acessado em 25 Nov. 2009b.
UDDI, Universal Description, Discovery & Integration Specification version 3, 2004. Disponvel em <http://www.oasis-open.org/committees/uddispec/doc/tcspecs.htm#uddiv3>. Acessado em 25 Nov. 2009. WSDL, Especificao da Web Service Description Language, 2008. Disponvel em <http://www.w3.org/TR/wsdl>. Acessado em 25 Nov. 2008. WSDL-UDDI, Using WSDL in a UDDI Registry, version 2.0.2, Technical Note, 2004. Disponvel em <http://www.oasis-open.org/committees/uddispec/doc/tn/uddi-spec-tc-tn-wsdl-v2.htm>. Acessado em 25 Nov. 2004.
Apndice 1 Roteiro de Instalao do Oracle Service Registry verso 10.3

Esta seo descreve, de forma resumida, os passos para instalao do Oracle Service Registry, no cenrio Standalone Registry. Informaes detalhadas sobre a instalao do produto, inclusive em outros cenrios possveis, podem ser obtidas em [Oracle, 2008a]. Os passos a seguir foram instalados no seguinte ambiente operacional: Windows XP Professional verso 2002 SP3 Java Development Kit verso 1.6.0_13-b03 Oracle WebLogic Server 10.3 Banco de Dados Oracle verso 10g Release 1 (10.1) 1. Para iniciar o processo de instalao, digite o seguinte comando no prompt do Windows:
java -jar oracle-service-registry-10.3.jar
2. A primeira tela do processo de instalao apresenta informaes sobre os requisitos de sistema recomendados para a instalao, inclusive possibilita visualizar a documentao do produto (Figura 51).
Figura 51 Tela de boas vindas da instalao do OSR
3. Selecione o cenrio de instalao desejado, neste caso Standalone Registry (Figura 52).
Figura 52 Tela de seleo do tipo de instalao
4. Informe o caminho do diretrio de instalao do OSR (o default para Windows c:\oracle\registry_10_3)(Figura 53).
Figura 53 Tela de seleo do diretrio de instalao
5. Informe as configuraes SMTP. Elas so importantes para o envio de notificaes, como por exemplo, mudanas nos servios assinados (subscriptions)(Figura 54).
Figura 54 Tela de configuraes SMTP
6. Defina a conta de administrao do OSR (Figura 55)
Figura 55 Tela de criao da conta de administrao
7. Configurao do banco de dados a. Utilize a opo Create New Tablespace/database para criar o banco de dados. necessrio existir um schema criado e possuir acesso de administrador no banco de dados (Figura 56).
Figura 56 Tela de seleo do mtodo de criao do banco de dados
b. Selecione o banco de dados utilizado. Marque a opo Install demo data to the database para que sejam instalados os exemplos do OSR (Figura 57).
Figura 57 Tela de seleo do banco de dados
c. Fornea as informaes do servidor de banco de dados que ser utilizado pela instalao do OSR (Figura 58).
Figura 58 Tela de configuraes do banco de dados
8. Informe o diretrio do driver JDBC que ser utilizado pelo OSR para conectar o banco de dados. O driver pode ser encontrado no diretrio de instalao do Oracle 10g (Figura 59).
Figura 59 Tela de seleo do driver JDBC
9. Selecione o provedor Database para autenticao a ser utilizado pelo OSR (Figura 60).
Figura 60 Tela de seleo do provedor de autenticao
10. Selecione o servidor de aplicao: a. Marque a opo Oracle WebLogic 9.2 or 10.3 (Figura 61).
Figura 61 Tela de seleo do servidor de aplicao
b. Fornea as informaes para deploy no servidor de aplicao e marque a opo Deploy at the end of installation (Figura 62).
Figura 62 Tela de configurao de deploy no servidor de aplicao
11. Neste passo necessrio informar o diretrio de instalao do Oracle Weblogic Server, JAVA_HOME, host, porta e o usurio e senha do administrador do Oracle Weblogic Server (Figura 63).
Figura 63 Tela de configuraes do Oracle Weblogic Server
12. A tela a seguir possui as informaes que foram definidas durante o processo de instalao do OSR (Figura 64).
Figura 64 Tela de confirmao da instalao
13. Esta tela indica que o processo de instalao foi finalizado com sucesso e apresenta algumas informaes importantes (Figura 65).
Figura 65 Tela de instalao realizada com sucesso
importante ressaltar que aps o processo de instalao necessrio configurar o arquivo de inicializao do Oracle Weblogic Server (startWebLogic.cmd) que permite a autenticao dos usurios no OSR (existem outras formas de autenticao maiores detalhes em [Oracle, 2008a] ):
set JAVA_OPTIONS= -Djava.security.auth.login.config= <OSR_HOME>/conf/jaas.config %JAVA_OPTIONS%
Apndice 2 Roteiro para gerenciamento de contas de usurios no Oracle Service Registry verso 10.3
Esta seo aborda o gerenciamento de usurios no OSR utilizando o Registry Control (http://<home>:7001/registry/uddi/web). Para acessar o gerenciamento de usurios, acesso o Registry Control e faa login como administrador. Clique na aba Manage e selecione a opo Registry Management e clique no boto Account management (Figura 66).
Figura 66 Tela Registry Management (Account management)
Somente usurios com privilgios de administrador tero acesso a aba Management.
1. Para criar uma conta de usurio, clique na opo Create Account (Figura 67).
Figura 67 Tela para criao de conta de usurio
Para um melhor entendimento do campo User profile, consulte a descrio dos principais perfis pr-definidos pelo OSR na seo 3.7.1.2 .
Apndice 3 Roteiro para gerenciamento de grupo de usurios no Oracle Service Registry verso 10.3
Esta seo aborda o gerenciamento de grupo de usurios no OSR utilizando o Registry Control (http://<home>:7001/registry/uddi/web). Para acessar o gerenciamento de grupo de usurios, acesse o Registry Control e faa login como administrador. Clique na aba Manage e selecione a opo Registry Management e clique no boto Group management (Figura 68).
Figura 68 - Tela Registry Management (Group management)
1. Para criar um grupo de usurios, clique na opo Add Group.
2. Informe o nome do grupo, o proprietrio, a visibilidade do grupo e uma descrio (opcional) (Figura 69).
Figura 69 Tela para criao de grupo de usurios
A visibilidade de um grupo (Group visibility) pode ser definida como pblica ou privada. A diferena entre um grupo pblico e um grupo privado que os membros de um grupo pblico podem ser vistos por qualquer usurio de registro, enquanto que os membros de um grupo privado podem ser vistos apenas pelo proprietrio ( owner) do grupo.
3. Aps clicar no boto Save group properties, ser apresentada uma lista de usurios (User list) e a lista de membros do grupo (Group Members). Defina os membros do grupo e clique em Save group properties. (Figura 70)
Figura 70 Tela de edio de mebros do grupo
Apndice 4 Roteiro para gerenciamento de permisses de usurios e grupo de usurios no Oracle Service Registry verso 10.3
Esta seo aborda o gerenciamento de permisses de usurios e grupo de usurios no OSR utilizando o Registry Control (http://<home>:7001/registry/uddi/web). O OSR utiliza a mesma interface para o gerenciamento de permisses de usurios e grupos. Nesta seo, sero abordadas apenas as permisses de usurios. Para um melhor entendimento sobre os princpios de permisso no OSR, apresentaremos um resumo sobre alguns conceitos. O OSR divide a configurao de permisso em controle de acesso s APIs e seus mtodos e controle de acesso a dados. Permisso no OSR prove um mecanismo que permite ao administrador gerenciar acesso a diferentes partes do registro para diferentes usurios. A permisso definida como sendo o direito (privilgio) de executar uma ao (mtodo) em uma determinada interface. O OSR utiliza o recurso Acess Control que permite controlar o acesso s estruturas do UDDI. 1. Para acessar o gerenciamento de permisses de usurios, acesse o Registry Control e faa login como administrador. Clique na aba Manage e selecione a opo Registry Management e clique no boto Permissions (Figura 71). Observe que para gerenciar grupos basta escolher a opo Group no radiobutton nas opes de filtro.
Figura 71 Tela de seleao de usurio e grupo
2. Selecione o usurio ou grupo desejado e clique no cone Edit Permissions ( ). Na tela que ser exibida (Permissions) clique em Add Permissions e ser exibida a tela referente Figura 72.
Figura 72 Tela para adicionar permisso em usurio ou grupo
3. Selecione o tipo de permisso a partir da lista (drop down) Permission type. a. Selecione o nome da permisso desejada da lista (drop down) Permission Name b. Marque os checkbox das aes associadas as permisses do nome selecionado em Permission Name, para dar permisso (grant) para executar essas aes. Para permitir todas as aes listadas, marque o checkbox referente a opo astersco (*)
Apndice 5 Roteiro para publicao de um provedor de servio no Oracle Service Registry verso 10.3
Esta seo aborda a publicao de um provedor no OSR utilizando o Business Service Control (BSC) (http://<home>:7001/registry/uddi/bsc/web). Para publicar um provedor necessrio fazer login no BSC. 1. Clique na aba (menu tab) Catalog (Figura 73).
Figura 73 Tela treeview Catalog
2. Clique na opo Providers e, em seguida, Publish a new provider (Figura 74).
Figura 74 Tela para publicao de um provedor (passo 1)
3. Informe o nome do provedor, uma descrio (recomendado) e clique em next (Figura 75)
Figura 75 Tela para publicao de um provedor (passo 2)
4. Informe o nome da pessoa de contato no provedor (recomendado) e clique em finish.
Apndice 6 Roteiro para publicao de um servio de negcio no Oracle Service Registry verso 10.3
Esta seo aborda a publicao de um servio de negcio no OSR utilizando o Business Service Control (BSC) (http://<home>:7001/registry/uddi/bsc/web). O servio ser criado a partir de um arquivo WSDL. Para publicar um servio de negcio necessrio fazer login no BSC. 1. Clique na aba (menu tab) Catalog (Figura 73). 2. Clique na opo WSDL Services e, em seguida, Publish a new WSDL service (Figura 76).
Figura 76 Tela para publicao de um servio de negcio (passo 1)
3. Selecione o provedor de servio, informe a localizao do arquivo WSDL e clique em next. a. Caso seja necessrio autenticao para acessar o arquivo WSDL ser necessrio informar as credenciais (usurio e senha) (Figura 77).
Figura 77 Tela para acesso a WSDL seguro
4. Informe as propriedades do servio.
Figura 78 Tela de propriedades do servio
5. Defina as propriedades da interface do servio (Figura 79).
Figura 79 Tela de propriedades da interface do servio
6. Especifique o endpoint do servio (Figura 80).
Figura 80 Tela para especificao do endpoint do servio
Apndice 7 Roteiro para controlar o acesso a um servio de negcio no Oracle Service Registry verso 10.3
Esta seo apresenta como controlar o acesso a um servio de negcio no OSR. Para alterar as permisses de um servio de negcio necessrio fazer login no OSR e o usurio deve ter privilgios administrativos ou ser o owner do servio. 1. A partir de uma listagem de servio, selecione um servio, clique no boto Edit (neste caso foi utilizado o AccountService) e clique em permissions (Figura 81).
Figura 81 Tela de edio de servio
2. Selecione o usurio (por exemplo U1) ou grupo que ser definida a permisso e clique em Add selected user (Figura 82). O usurio ir aparecer na aba de cima.
Figura 82 Tela de seleo do usurio para permisso no servio
3. Edite a permisso do usurio selecionado (U1). a. Clique no cone edit permission for user u1
b. Selecione as permisses desejadas e clique update permission of user U1e salve as alteraes clicando em save changes (Figura 83).
Figura 83 Tela de definio de permisso de usurio no servio
Dessa forma o usurio U1 tem permisso negada para qualquer tipo de operao que pode ser realizada no servio.
Apndice 8 Roteiro para criar taxonomias no Oracle Service Registry verso 10.3
Esta seo apresenta como criar taxonomias utilizando o OSR. Para acessar o gerenciamento de taxonomia, acesso o Registry Control (http://<home>:7001/registry/uddi/web) e faa login como administrador. 1. Clique na aba Manage e selecione a opo Taxonomy Management.
Figura 84 Tela Registry Management (Taxonomy management)
2. Clique no boto Add Taxonomy (Figura 85).
Figura 85 Tela de seleo de taxonomia
3. Preencha as informaes e clique em save taxonomy.
Figura 86 Tela de incluso de taxonomia
4. Para adicionar categoria(s) a taxonomia criada clique no cone Edit structure na tela do resultado da pesquisa de taxonomias (Figura 87).
Figura 87 Tela do resultado da consulta de taxonomias favoritas
a. Clique no boto add category para adicionar uma categoria (Figura 88).
Figura 88 Tela de edio de taxonomia
b. Informe o nome e um valor para a nova categoria e clique em save category.

Figura 89 Tela de incluso de uma nova categoria
a. Para criar uma sub-categoria de uma j existente, clique no cone add child category to<nome da categoria parent> e informe o nome e valor para a nova sub-categoria
Figura 90 - Tela de incluso de sub-categoria
Apndice 9 Roteiro para associar uma categoria a um servio de negcio no Oracle Service Registry verso 10.3
Esta seo apresenta como associar uma categoria a um servio de negcio utilizando o OSR. O objetivo dessa associao facilitar a localizao de um servio atravs de uma categoria (criada na taxonomia). Aps a associao de um servio a uma categoria, possvel localizar servios a partir de uma consulta utilizando a taxonomia (Apndice 12). 1. Edite o servio que ser associado categoria e acesse a tab categories e clique no boto add category.
Figura 91 Tela de edio de servio
2. Selecione a categoria da lista de taxonomias e clique em um dos cones add category ou add category with parents.
Figura 92 - Tela de adio de categoria na edio de servio
Apndice 10 Roteiro para associar um servio de negcio a um provedor de negcio no Oracle Service Registry verso 10.3
Esta seo apresenta como associar um servio de negcio a um provedor de negcio (tambm chamado de business ou business entity) utilizando o OSR. O objetivo dessa associao facilitar a localizao de um servio a partir de um provedor de negcio. 1. Edite o provedor (business) e acesse a aba (tab) services (Figura 93).
Figura 93 Tela de edio de um provedor (business)
2. Clique no boto add service para adicionar o servio desejado (Figura 94Figura 93).
Figura 94 - Tela de adio de servio ao provedor
3. Informe o nome do servio que ser associado ao provedor (business) e clique no boto add service. O Service key o identificador nico do servio no OSR.
Figura 95 Tela de incluso de servio no provedor (business)
Apndice 11 Roteiro para criar um binding template no Oracle Service Registry verso 10.3
Esta seo apresenta como criar um binding template possibilitando a localizao de servios de negcio utilizando o OSR. O binding template uma instncia de um web service onde podemos obter, alm de outras informaes, detalhes tcnicos de como invocar um servio. Recomenda-se a utilizao do binding template para os casos em que essas informaes so compartilhadas por mais de um provedor de servio (business entity). 1. Selecione o menu Publish e clique na aba (tab) Publish. 2. Selecione o servio ao qual ser adicionado o binding (Figura 96) e, em seguida, clique no link Add Binding.
Figura 96 Tela de seleo de servio para incluso do binding
3. Informe o access point que indica onde poder ser encontrado o end point do servio (web service). So exemplos de access point uma URL, um endereo de e-mail ou at mesmo um nmero de telefone. Clique no boto Add Binding para salvar.
Figura 97 Tela de incluso do binding
Apndice 12 Utilizando taxonomia para pesquisa de servios no Oracle Service Registry verso 10.3
Esta seo apresenta como utilizar taxonomia para a localizao de servios de negcio utilizando o OSR. 1. A partir da tela de pesquisa de servios, acesse a aba Categories e clique no boto Add Category (Figura 98).
Figura 98 Tela de pesquisa de servios
2. Selecione a taxonomia desejada da lista de taxonomias (Taxonomy list). Utilize os cones add categories ou add with parent para selecionar a(s) categoria(s) as opes de filtro (Figura 99).
Figura 99 Tela de pesquisa de servios por categoria
3. Aps a adio das categorias desejadas clique no boto find (Figura 100).
Figura 100 Tela de pesquisa de servios com as categorias selecionadas

964 5379 1 PB

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

964 5379 1 PB

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE FEDERAL DO ESTADO DO RIO DE JANEIRO CENTRO DE CINCIAS EXATAS E TECNOLOGIA

Relatrios Tcnicos do Departamento de Informtica Aplicada da UNIRIO no 0005/2010

Estudos de Registro de Servios e do Oracle Service Registry

Leonardo Azevedo Flvio Faria Flvia Santoro Fernanda Baio

Departamento de Informtica Aplicada

Relatrios Tcnicos do DIA/UNIRIO, No. 0005/2010

Estudos de Registro de Servios e do Oracle Service Registry*

Apndice 1 Roteiro de Instalao do Oracle Service Registry verso 10.3

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 6

Aponta para uma descrio

Aponta para um servio

Web service (provedor)

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 7

URLs para especificao da linguagem XML Schema: http://www.w3.org/TR/xmlschema-0/, http://www.w3.org/TR/xmlschema-1/, e http://www.w3.org/TR/xmlschema-2/.

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 8

Servios oferecidos pela empresa

Como invocar servios

Figura 2 Esquema do modelo de dados do UDDI

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 9

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 10

Representao de informaes em um UDDI

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 12

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 13

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 14

Usando WSDL em um registro UDDI

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 15

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 17

UDDI API Schema

3 Oracle Service Registry

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 18

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 19

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 20

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 21

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 22

Classificao de servios usando taxonomias

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 24

Figura 9 Ciclo de aprovao

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 25

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 26

Figura 10 Pgina da funcionalidade Catalog do Business Service Control

Figura 11 Pgina de listagem de WSDL de servios do Business Service Control

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 28

Figura 12 Tela de pesquisa

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 29

Figura 13 Tela de pesquisa por endpoints

Figura 14 Resultado de busca por endpoint

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 30

Figura 15 Publicao de WSDL

Figura 16 Preenchimento de credenciais para autenticao

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 31

Figura 17 Publicao de propriedades do servio

Figura 18 Publicao das propriedades da interface do servio

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 32

Figura 19 Publicao das propriedades do endpoint do servio

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 33

Figura 20 Relatrios pr-definidos no Business Service Control

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 34

Figura 21 Criao de subscrio para provedor HR Services

Figura 22 Ajustes de parmetros de notificao da subscrio

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 35

Figura 23 Tela de criao de subscrio a partir de busca por servios

Figura 24 Tela de gerncia de subscries

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Registro de Servios e Oracle Service Registry 37