Programación en castellano
-Tutoriales

El API JAXR


Apéndice B: Mapeo JAXR a UDDI

El apéndice describe cómo se mapea el modelo de información JAXR a estructuras de datos XML UDDI según se define en la versión 1.0 de la especificación UDDI [UDDI-DS]. Las estructuras de datos UDDI se describen en formato XML. Este mapeo será actualizado en una futura versión de este documento para reflejar los cambios en la versión 2.0 de la especificación UDDI.

. Modelo UML Simplificado para el Modelo de Información UDDI


Figura 20: Modelo UML Simplificado para el Modelo de Información UDDI

La figura 20 muestra una representación UML simplicada del modelo de información UDDI. Observa que el modelo no es un dibujo exacto del modelo de información UDDI porque ha sido simplicado para que el lector pueda entenderlo.

. Mapeo de JAXR a UDDI

Los tipos de datos UDDI no son extensibles. Por lo tanto no es siempre posible mapear un atributo de un interface JAXR a UDDI. Por ejemplo, UDDI no soporta majorVersion y minorVersion. Un proveedor JAXR para UDDI debe lanzar una UnsupportedCapabilityException cuando un cliente intente llamar a un método set para un atributo que no tiene mapeo en UDDI (por ejemplo, RegistryEntry.setMajorVersion).

De forma similar, no todos los interfaces JAXR tienen mapeo a UDDI. Por ejemplo el interface Package no tiene mapeo a UDDI. El método LifeCycleManager.createObject debería lanzar una UnsupportedCapabilityException cuando un cliente intente crear un objeto que no puede mapearse a UDDI.

. Mapeo de Atributos UDDI a JAXR

La especificación JAXR usa las siguientes aproximaciones, listadas en orden de preferencia, para especificar el mapeo entre atributos UML del modelo JAXR y UDDI:

  1. Mapea un atributo UDDI a un atributo JAXR definido estáticamente (no-Slot) dentro de un interface JAXR.
  2. Mapea un atributo UDDI a un atributo Slot definido dinámicamente dentro de un ejemplar de interface JAXR.

Si el mapeo simplemente no es posible, el cliente tiene la opción de usar el método toXML de RegistryObject para obtener una representación XML específica del registro para el objeto que está siendo mapeado. Esta opción no es deseable al no ser portable.

. Mapeo de Atributos useType UDDI

El modelo de información UDDI frecuente usa un atributo useType sobre sus estructuras de datos. El atributo useType de UDDI se mapea a un árbol de Concept extensible que tiene un Concept raíz que identifica el contexto para el useType. Por ejemplo, useType en phone mapea a un Concept raíz llamado phoneType, que tiene uno hijos Concepts que son los distintos tipos de teléfonos (por ejemplo, fax, móvil etc.).

. Mapeo de Interfaces

Esta sección proporciona el mapeo entre conceptos UDDI del más alto nivel al modelo de información JAXR. La tabla proporciona un mapeo a nivel de entidad y las subsecciones describen el mapeo de nivel elemento/atributo para cada concepto clave. Como JAXR define su modelo de información en términos de interfaces, la mayoría de los atributos de entidad UDDI son mapeados a operaciones sobre objetos del modelo de información JAXR.

UDDI JAXR Descripción
businessEntity Organization

 

businessService Service

 

bindingTemplate ServiceBinding Detalles en bindingTemplate.
tModel Concept Detalles en tModel.
discoveryURL ExternalLink Detalles en businessEntity.
contact User

 

identifierBag Collection de ejemplares ExternalIdentifier Detalles en identifierBag.
categoryBag Collection de ejemplares Concept Detalles en caregoryBag.
address PostalAddress Detalles en businessEntity.
overviewDoc ExternalLink Detalles en tModel.
keyedReference Association Detalles en keyedReference.

. BusinessEntity

businessEntity es uno de los cuatro concept principales en UDDI. businessEntity mapea a un Organization en el modelo de información de JAXR.

businessEntity Organization Descrip
businessKey Organization.getKey

 

authorizedName Organization.getSlot Slot de sólo lectura llamado authorizedName del tipo String.
operator Organization.getSlot Slot llamado operator del tipo String.
discoveryURL Organization.getExternalLinks businessEntity contiene una lista de discoveryURLs mientras que Organization contiene una colección de enlaces externos.
Name Organization.getName

 

description Organization.getDescription

 

contact Organization.getUsers JAXR designa un contact como primario mientras que UDDI no lo hace. El mapeo asumirá que el primer contact UDDI encontrado será el contact primario en JAXR.
businessServices Organization.getServices businessService se mapea al interface Service.
identifierBag Organization.getExternalIdentifiers Detalles en identifierBag.
categoryBag Organization.getClassificationConcepts Detalles en categoryBag.

discoveryURL
En UDDI, el discoveryURL por defecto lo asigna el registro UDDI y se usa para recuperar el XML del businessEntity y todo lo contenido dentro de él. Cualquier discoveryURL adicional es asignado por el enviante, y proporciona enlaces a contenido externo.

El discoveryURL es mapeado a ExternalLinks en JAXR. El atributo useType esencialmente describe si el businessEntity padre es un businessEntity UDDI estándar o una extensión específica del ejemplar de businessEntity llamado businessEntityExt. El atributo useType es mapeado a un Slot.

DiscoveryURL ExternalLink Descripción
useType ExternalLink.getSlot Slot llamado useType
url value ExternalLink.getExternalURI

 

Contact
El elemento Contact UDDI se mapea al interface User en JAXR de esta forma:

Contact User Descripción
useType User.getSlot Slot llamado useType
description User.getDescription

 

personName User.getPersonName.getName

 

phone User.getTelephone.getNumber

 

email User.getEmailAddress

 

address User.getPostalAddress

 

Address
Un Address UDDI tiene dos atributos y una lista de líneas de direcciones. Cada línea es un String. En JAXR, PostalAddress es un interface estructurado con artributos bien definidos para street, city, postal code, country, etc. Esto implica un problema de mapeo entre la información estructurada en JAXR y la información desestructurada en UDDI. La solución es usar Slots sobre PostalAddress.

Address PostalAddress Descripción
addressLines PostalAddress.getSlot Slot llamado addressLines que tiene una Collection de valores
useType PostalAddress.getType

 

sortCode PostalAddress.getSlot Slot llamado sortCode

. BusinessService

businessService en UDDI representa un grupo de servicios lógicos, que tienen clasificaciones comunes. Es mínima funcionalmente y realmente sirve como una agrupación de bindingTemplates.

businessService se mapea directamente al interface Service en el modelo de información JAXR.

businessService Service Descripción
businessKey Service.getContainerKey

 

serviceKey Service.getKey

 

name Service.getName

 

description Service.getDescription

 

bindingTemplates Service.getServiceBindings

 

categoryBag Service.getClassificationConcepts Detalles en categoryBag.

. BindingTemplate

El bindingTemplate es otro de los Concepts importantes en UDDI y sirve sólo para proporcionar un acceso (un punto de entrada) al servidor deseado pero también para tratar con la especificación técnica para el servicio. Estas especificaciones técnicas podrían ser en forma de documentos basados en texto o en un lenguaje de definición de interfaces como WSDL.

El elemento bindingTemplate de UDDI se mapea al interface ServiceBinding de JAXR de esta forma:

bindingTemplate ServiceBinding Descripción
bindingKey ServiceBinding.getKey

 

serviceKey ServiceBinding.getContainerKey

 

description ServiceBinding.getDescription

 

accessPoint ServiceBinding.getAccessURI El atributo URLType en accessPoint se mapea clasificando el ServiceBinding con un sub-concept de URLType. El urlType por defecto es http.
hostingRedirector ServiceBinding.getTargetBinding Sólo hay un elemento, bindingKey, en esta estructura y se mapea al atributo targetBinding.
tModelInstanceDetails No mapeado explícitamente ya que es sólo una Collection

 

tModelInstanceInfo Cada atributo mapeado a un Slot con el mismo nombre del Concept. Detalles en Ejemplo de Mapeo.
instanceDetail Cada atributo mapeado a un Slot con el mismo nombre del Concept. Detalles en Ejemplo de Mapeo.

tModelInstanceInfo
Mapeado a un ejemplar Association cuyo associationType es el concepto pre-definido UDDIDataTypes/tModelInstanceInfo. El sourceObject del Association es el ServiceBinding. El targetObject es el Concept.

instanceDetails
Mapeado a un ejemplar Association cuyo associationType es el concepto predefinido UDDIDataTypes /instanceDetail. El sourceObject es el Association de associtaionType tModelInstanceInfo y el objetivo es un ExternalLink representando el overviewDoc del instanceDetail.

. tModel

En UDDI, tModel es un concept sobrecargado que puede usarse para unos pocos propósitos diferentes. El Interface Concept en el modelo de información JAXR sirve para el mismo propósito.

tModel Concept Descripcion
tModelKey Concept.getKey

 

authorizedName Concept.getSlot Slot llamado authorizedName
operator Concept.getSlot Slot llamado operator
name Concept.getName

 

description Concept.getDescription

 

overviewDoc Concept.getExternalLinks Ver más abajo
identifierBag Concept.getExternalIdentifiers Detalles en identifierBag.
categoryBag Concept.getClassificationConcepts Detalles en categoryBag

overviewDoc
Un overviewDoc se mapea a un ExternalLink en JAXR. El ExternalLink está asociado con el Concept al que está mapeado el tModel.

OverviewDoc ExternalLink Descripción
description ExternalLink.getDescription

 

overviewURL ExternalLink.getExternalURI

 

. Mapeo de Tipos de Datos Comunes

Hasta ahora hemos descrito el mapeo de más alto nivel entre las estructuras principales de UDDI y el modelo de información JAXR. La siguiente seccion describe el mapeo entre las estructuras más comunmente reutilizadas en UDDI.

. keyedReference

Un elemento keyedReference es usa para contener un grupo de Classifications o un grupo de identificadores de objetos. Para éste último, keyedReference puede mapeadarse a ExternalIdentifiers o a Classifications. Por esta razón, realmente hay dos tablas especificando cada mapeo individual.

Cuando un keyedReference está siendo usado como un identifierBag, se mapea a un ExternalIdentifier JAXR. Un modelo de información JAXR que está siendo serializado a XML para UDDI tendrá sus identificadores externos serializados dentro de identifierBag. De forma similar, una respuesta UDDI de vuelta, es des-serializada dentro de ExternalObjects mediante la implementación del proveedor JAXR.

keyedReference ExternalIdentifier Descripción
tModelKey ExternalIdentifier.getKey Desde el RegistryObject
keyName ExternalIdentifier.getName Desde el RegistryObject. Esto es simbólico (como un Tax Id).
KeyValue ExternalIdentifier.getValue Este es el id único (por ejemplo, tax id), que identifica la entidad de comercio electrónico.

Cuando se usa un keyedReference en un categoryBag, se mapea como un Concept JAXR.

Cuando se está serializando un objeto JAXR a XML para UDDI, todos sus Concepts tienen un padre null, y son serializados dentro de categoryBag de acuerdo con el mapeo descrito en la siguiente tabla:

keyedReference Concept Descripción
tModelKey Concept.getKey

 

keyName ((Concept)(Concept.getRoot())).getName Podría ser un esquema de clasificación como NAICS
keyValue Concept.getValue Podría ser un código NAICS específico que indentifica la categoría de la industria o del negocio

. IdentifierBag

identifierBag es una Collection de keyedReferences. Un identifierBag se modela en el modelo de información JAXR como una Collection de ExternalIdentifiers.

. categoryBag

categoryBag es una Collection de keyedReferences. Un categoryBag se modela en el modelo de información JAXR como una Collection de Concepts relacionados con la clasificación.

. tModelBag

tModelBag es una Collection de valores uuid_key tModel que representan huellas técnicas de una estructura bindingTemplate contenida dentro del businessService especificado por el valor de serviceKey.

Un tModelBag se modela en el modelo de información JAXR como una Collection de Concepts relacionados con la clasificación.

. Ejemplo de Mapeo JAXR-UDDI

La figura 21 muestra un ejemplo simplificado descrito en términos de estructuras de datos UDDI. La figura 22 muestra el mismo ejemplo en términos del modelo de datos JAXR usando los mapeos descritos anteriormente.


Figura 21: Ejemplo en términos de Estructuras de Datos UDDI.
Figura 22: Ejemplo UDDI Mapeado a JAXR.

. Soporte NLS y Mapeo a UDDI

La aproximación UDDI para soportar NLS (Native Language Support) es diferente de la de ebXML y del modelo de información JAXR. En UDDI un sólo objeto como un businessEntity, se puede usar para múltiples lenguajes. Cada atributo o elemento localizable (por ejemplo, name, description) está disponible en una Collection donde hay un elemento Collection por cada lenguaje soportado.

En JAXR (y ebXML), NLS es soportado introduciendo múltiples copias únicas del mismo objeto en las que cada copia tiene el contenido localizable para el lenguaje específico mientras que el contenido no-localizable es idéntico en todas las copias. El resultado es que los elementos de información como name y description aparecen como Collections de Strings en UDDI pero aparecen como un atributo String singular en JAXR.

El mapeo ocurre de la siguiente forma. El API JXR soporta sólo un name/description. Las llamadas al API JAXR son sensibles a la localidad y devuelven sólo los elementos específicos de la localidad desde el conjunto de names/descriptions cuando devuelve un objeto (por ejemplo, businessEntity / Organization) desde UDDI.

. Funcionalidades UDDI no Soportadas por JAXR

La siguiente tabla declara todas las funcionalidades UDDI que no son accesibles mediante el API JAXR. Cualquier potencial omisión en esta lista es un error de especificación y debería ser reptortado.

Característica UDDI Disposición Descripción
Max rows Un grupo de expertos creyó que está funcionaldiad no era útil sin un cursor como habilidad. No hay planes de proporcionarla en JAXR. No soportada deliveradamente.
get_registeredInfo Se corregirá en el Public Draft 2 Característica desaparecida en V1
discoveryURL por defecto en businessEntity Necesita posteriores investigaciones Posible característica perdida en V1. Podría requerir un sub-paquete específico UDDI.
No hay forma de buscar un businessEntity usando tModelBag AND categoryBag Se corregirá en el Public Draft 2 Característica perdida en V1
Funcionalidad BusinessEntityExt Necesita posterior investigación. Posible característica perdida en V1
No hay Soporte para undeprecate Se coregirá en el Public Draft 2 Caracterísitca perdida en V1
Relaciones Business La característica está soportada pero la unión será definida en el Public Draft 2 Característica definida inadecuadamente en V2
Publisher Assertions Se corregirá en el Public Draft 2 Característica perdida en V1
Service Projection La característia está soportada pero la unión será definida en el Public Draft 2 Característica definida inadecuadamente en V2
6 nuevos cualificadores de find en V2 Se corregirá en el Public Draft 2 Característica perdida en V1
 
Patrocinados
 

Copyright © 1999-2007 Programación en castellano. Todos los derechos reservados.
Formulario de Contacto - Datos legales - Publicidad
Mantenida por: Claudio y Dani.

Hospedaje web y servidores dedicados linux por Ferca Network

red internet: jugar gratis | amor | navidad 2009 | registro de dominios | servidores dedicados
más internet: comprar | gratis | posicionamiento en buscadores | decoración libre | gifs animados