964 5379 1 PB PDF

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
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
8
10
11
14
15
18
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
18
20
22
22
23
23
24
25
47
48
49
54
55
Concluses
56
Referncias
56
Apndice 1 Roteiro de Instalao do Oracle Service Registry verso 10.3
58
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
71
Apndice 5 Roteiro para publicao de um provedor de servio no Oracle

Service Registry verso 10.3
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
78
Apndice 8 Roteiro para criar taxonomias no Oracle Service Registry verso 10.3
81
iv
Apndice 9 Roteiro para associar uma categoria a um servio de negcio no

Oracle Service Registry verso 10.3
85
Apndice 10 Roteiro para associar um servio de negcio a um provedor de

negcio no Oracle Service Registry verso 10.3
86
Apndice 11 Roteiro para criar um binding template no Oracle Service Registry

verso 10.3
88
Apndice 12 Utilizando taxonomia para pesquisa de servios no Oracle Service

Registry verso 10.3
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
Aponta para
uma descrio
Registro
UDDI
Aponta para
um servio
Pesquisa por
servio
Consumidor
de servio
SOAP
WSDL
Descreve um
servio
Web service
(provedor)
Comunica atravs de mensagens XML
Figura 1 Interaes de web services
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
BusinessService
Informao da empresa
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.
_______________________________________________________________________________________________
10
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
_______________________________________________________________________________________________
11
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.
_______________________________________________________________________________________________
12
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.
_______________________________________________________________________________________________
13
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.
_______________________________________________________________________________________________
14
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 de
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
_______________________________________________________________________________________________
15
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">
_______________________________________________________________________________________________
16
<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>
WSDL description of a standard stock quote service interface
</description>
<overviewDoc>
WSDL source document.
</description>
<overviewURL>
http://example.com/stockquote.wsdl
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
_______________________________________________________________________________________________
17
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>
<tModelnstanceInfo tModelKey="...">
</tModelnstanceInfo>
</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].
_______________________________________________________________________________________________
18
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;
_______________________________________________________________________________________________
19
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.
_______________________________________________________________________________________________
20
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
_______________________________________________________________________________________________
21
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 (
_______________________________________________________________________________________________
22
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
_______________________________________________________________________________________________
23
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;
_______________________________________________________________________________________________
24
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.
_______________________________________________________________________________________________
25
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].
_______________________________________________________________________________________________
26
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.
_______________________________________________________________________________________________
27
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
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.
Operator: disponibiliza e gerencia no ambiente de produo os servios de

negcio implementados pelo Developer.
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.
_______________________________________________________________________________________________
28
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.
_______________________________________________________________________________________________
29
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.
_______________________________________________________________________________________________
30
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/
_______________________________________________________________________________________________
31
Figura 17 Publicao de propriedades do servio
Figura 18 Publicao das propriedades da interface do servio
_______________________________________________________________________________________________
32
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.
_______________________________________________________________________________________________
33
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.
_______________________________________________________________________________________________
34
Figura 21 Criao de subscrio para provedor HR Services
Figura 22 Ajustes de parmetros de notificao da subscrio
_______________________________________________________________________________________________
35
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.
_______________________________________________________________________________________________
36
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].
_______________________________________________________________________________________________
37
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
_______________________________________________________________________________________________
38
Figura 27 Tela de visualizao de conta de usurio
Figura 28 Tela de visualizao de grupos de usurios
_______________________________________________________________________________________________
39
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
_______________________________________________________________________________________________
40
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).
_______________________________________________________________________________________________
41
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.
_______________________________________________________________________________________________
42
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).
_______________________________________________________________________________________________
43
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).
_______________________________________________________________________________________________
44
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.
_______________________________________________________________________________________________
45
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.
_______________________________________________________________________________________________
46
Figura 41 Tela de pesquisa por WSDL
Figura 42 Tela de pesquisa por XML
_______________________________________________________________________________________________
47
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.
_______________________________________________________________________________________________
48
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
_______________________________________________________________________________________________
49
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
Descrio
<types>
Definies de tipos para o contedo das mensagens.
<message>
Definio abstrata do tipo de dados sendo transmitido. Uma

mensagem consiste de partes, as quais descrevem o contedo
lgico e abstrato de uma mensagem.
<portType>
Coleo abstrata de operaes suportadas pelo servio.
<operation>
Descrio abstrata de uma ao suportada pelo servio. Cada

operao refere-se a uma mensagem de entrada e mensagem de
sada.
<binding>
Define o protocolo concreto e especificaes de formato de dados

para as operaes e mensagens definidas por um determinado
portType.
<port>
Especifica um endereo para um binding, portanto definindo um

endpoint de comunicao nico.
<service>
Coleo de portas ou endpoints.
_______________________________________________________________________________________________
50
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
UDDI
portType
Namespace do portType
Nome local do portType
Localizao do WSDL
tModel (categorizado como portType)

keyedReference no categoryBag
Nome do tModel
overviewURL
Cada binding do WSDL mapeamento em um tModel como apresentado na Tabela

3.
Tabela 3 Mapeamento de binding para o UDDI
WSDL
UDDI
Binding
tModel (categorizado como binding e wsdlSpec)
_______________________________________________________________________________________________
51
Namespace do binding
Local name do binding
Localizao do WSDL
portType binding
Protocol
Transport
Nome do tModel
overviewURL
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
UDDI
Service
Namespace do service
Nome local do service
businessService (categorizado como service)

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.
_______________________________________________________________________________________________
52
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.
_______________________________________________________________________________________________
53
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.
_______________________________________________________________________________________________
54
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
_______________________________________________________________________________________________
55
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
Oracle
Service Bus
6
5
Oracle
Service
Registry
Provedor do
servio
Figura 50 Roteamento dinmico considerando OSB e OSR
_______________________________________________________________________________________________
56
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.
_______________________________________________________________________________________________
57
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.
_______________________________________________________________________________________________
58
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
_______________________________________________________________________________________________
59
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
_______________________________________________________________________________________________
60
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
_______________________________________________________________________________________________
61
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
_______________________________________________________________________________________________
62
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
_______________________________________________________________________________________________
63
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
_______________________________________________________________________________________________
64
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
_______________________________________________________________________________________________
65
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
_______________________________________________________________________________________________
66
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%
_______________________________________________________________________________________________
67
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.
_______________________________________________________________________________________________
68
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 .
_______________________________________________________________________________________________
69
Apndice 3 Roteiro para gerenciamento de grupo de usurios

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)
_______________________________________________________________________________________________
70
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
_______________________________________________________________________________________________
71
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.
_______________________________________________________________________________________________
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 (*)
_______________________________________________________________________________________________
73
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)
_______________________________________________________________________________________________
74
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.
_______________________________________________________________________________________________
75
Apndice 6 Roteiro para publicao de um servio de negcio

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.
_______________________________________________________________________________________________
76
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
_______________________________________________________________________________________________
77
6. Especifique o endpoint do servio (Figura 80).
Figura 80 Tela para especificao do endpoint do servio
_______________________________________________________________________________________________
78
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.
_______________________________________________________________________________________________
79
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).
_______________________________________________________________________________________________
80
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.
_______________________________________________________________________________________________
81
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)
_______________________________________________________________________________________________
82
2. Clique no boto Add Taxonomy (Figura 85).
Figura 85 Tela de seleo de taxonomia
3. Preencha as informaes e clique em save taxonomy.
_______________________________________________________________________________________________
83
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.
_______________________________________________________________________________________________
84
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
_______________________________________________________________________________________________
85
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
_______________________________________________________________________________________________
86
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
_______________________________________________________________________________________________
87
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)
_______________________________________________________________________________________________
88
Apndice 11 Roteiro para criar um binding template no Oracle

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
_______________________________________________________________________________________________
89
Apndice 12 Utilizando taxonomia para pesquisa de servios

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).
_______________________________________________________________________________________________
90
Figura 100 Tela de pesquisa de servios com as categorias selecionadas
_______________________________________________________________________________________________
91

964 5379 1 PB PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

964 5379 1 PB PDF

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE FEDERAL DO ESTADO DO RIO DE JANEIRO

CENTRO DE CINCIAS EXATAS E TECNOLOGIA

Estudos de Registro de Servios e do Oracle

Departamento de Informtica Aplicada

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

Estudos de Registro de Servios e do Oracle Service

Oracle Service Registry

Apndice 1 Roteiro de Instalao do Oracle Service Registry verso 10.3

Apndice 2 Roteiro para gerenciamento de contas de usurios no Oracle Service

Apndice 5 Roteiro para publicao de um provedor de servio no Oracle

Apndice 6 Roteiro para publicao de um servio de negcio no Oracle Service

Apndice 9 Roteiro para associar uma categoria a um servio de negcio no

Apndice 10 Roteiro para associar um servio de negcio a um provedor de

Apndice 11 Roteiro para criar um binding template no Oracle Service Registry

Apndice 12 Utilizando taxonomia para pesquisa de servios no Oracle Service

Comunica atravs de mensagens XML

Figura 1 Interaes de web services

O registro UDDI pode ajudar a tratar questes de reuso de cdigo, manuteno e

Neste cenrio, o registro utilizado para permitir arquitetura com baixo

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

Servio de negcio (businessService): descreve uma coleo de web services

Figura 2 Esquema do modelo de dados do UDDI

A especificao apresenta APIs que padronizam o comportamento e a comunicao

Um n UDDI corresponde a um conjunto de web services que suporta pelo menos um

Representao de informaes em um UDDI

que levar a um ponto de acesso. Cada bindingTemplate filho de um nico

Modelos tcnicos ou tModels, so usados no UDDI para representar conceitos ou

de uma entidade UDDI particular. Esta capacidade permite que organizao

Segundo [ORACLE, 2008a], a especificao UDDI no define um mecanismo de

Usando WSDL em um registro UDDI

Descries de servio em WSDL podem ser estruturadas de mltiplas formas.

Quando um tModel refere a documento WSDL como apresentado na Figura

2. Manualmente ou usando o ferramental do UDDI, programadores

Um bindingTemplate criado para cada endpoint de acesso do servio. O

UDDI API Schema

3 Oracle Service Registry

Oracle Service Registry (OSR) est de acordo com a especificao UDDI V3 e

Permite que consumidores localizem e recuperem servios que estejam de

O OSR pode ser instalado em diferentes plataformas. Em relao a sistemas

LDAP um protocol de aplicao para consulta e modificao de servios de diretrios executando

Standalone Registry: Essa a instalao padro, na qual o servidor do OSR

demos: contm demonstraes de funcionalidades do OSR;

As mudanas realizadas sobre os servios podem ser controladas por um fluxo de

O mecanismo de subscrio permite que usurios monitorem entradas novas,

get_businessDetail, get_serviceDetail, get_bindingDetail, get_tModelDetail,

Classificao de servios usando taxonomias

O processo de aprovao prov funcionalidades para garantir consistncia e qualidade

Um avaliador (approver) que o usurio que pode aprovar ou rejeitar

Figura 9 Ciclo de aprovao

O avaliador avalia a requisio, e ento aprova ou rejeita a requisio. Se o

Um requisitante pode receber o status de auto-avaliador (AutoApprover). Neste caso,

Business Service Control

O Business Service Control tem os seguintes itens de menu:

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

Exibir atualizaes realizadas no ltimo perodo, por exemplo, 3 dias.

Traduz instalaes definidas pelo Business Expert em um conjunto de

Transforma capacidades e restries em alto nvel para capacidades e

Define capacidades e restries (tais como restries de acordo) que

Garante que servios esto de acordo com padres (SOAP, WSDL,

Sugere reuso de servios existentes.

Operator: disponibiliza e gerencia no ambiente de produo os servios de