Modelo de Información
El modelo de información JAXR se basa en gran medida en el modelo de información del registro ebXML
según lo definido por [RIM] y extendido para añadir los conceptos prestados de UDDI según lo definido por [UDDI-DS]. En el
Apéndice A y en el Apéndice B
se define una normativa de unión para [RIM] y [UDDI-DS].
Los interfaces relacionados con el modelo de información se definen en el paquete
java.xml.registry.infomodel de JAXR. Estos interfaces se pueden ver como para proporcionar una
unión Java a un modelo de información unificado de las especificaciones de registro dominantes. El modelo de información JAXR
es la confluencia de estas especificaciones del registro.
Modelo de Información: Vista Pública
Esta sección proporciona una vista pública de alto nivel de la mayoría de los objetos visibles en el registro.
La figura 12 muestra la vista pública de los objetos del registro y su relación como un diagrama UML. No muestra la herencia,
los atributos de las clases o sus métodos.
Se recuerda al lector que el modelo de información no es un modelo de real de ítems de repositorio.
Figura 12: Vista Pública del Modelo de Información
Las siguientes secciones proporciona información de alto nivel sobre los interfaces del modelo de información.
RegistryEntry
El objeto central en el modelo de información es un RegistryEntry. Existe un ejemplar de
RegistryEntry para cada item enviado al repositorio. Los ejemplares de la clase
RegistryEntry proporcionan un metadata sobre los items del repositorio. El item real del
repositorio (por ejemplo, un documento WSDL) no está contenido en un ejemplar de la clase
RegistryEntry. Observa que la mayoría de las clases en el modelo de información son
subclases especializadas de RegistryEntry. Cada RegistryEntry
se relaciona con ninguno o un ítem del repositorio.
Organization
Los ejemplares de Organization son RegistryEntries que
proporcionan la información en organizaciones como una organización enviante (SO). Cada ejemplar de
Organization puede tener una referencia a un Organization
padre.
Service
Los ejemplares de Service son RegistryEntries que
proporcionan información en servicios (por ejemplo, servicios Web) ofrecidos por un Organization.
Un Organization tiene una Collection de
Services.
ServiceBinding
Los ejemplares de ServiceBinding son RegistryEntries que
representan información técnica de una forma específica para acceder a un interface específico ofrecido pon un ejemplar
Service. Un Service tiene una
Collection de ServiceBindings.
Concept
Un ejemplar de Concept representa una noción arbitraría (o concepto). Virtualmente puede
ser cualquier cosa. Como los conceptos se pueden usar para muchos propósitos, la siguiente lista sumariza algunos de sus
usos principales en estos momentos:
- Los Concepts se usan para definir clasificaciones o árboles donde cada nodo es un
Concept. Este uso se describe en más detalle en la sección
Clasificación de RegistryObjects
- Los Concepts se usan para definir enumeraciones extensibles (por ejemplo, el atributo
phoneType en TelephoneNumber)
Classification
Los ejemplares de Classification son RegistryEntries que
se usan para clasificar un ejemplar RegistryEntry por un Concept
dentro de un esquema de clasificación. La clasificación se describe en más detalle en la sección
Clasificación de RegistryObjects
Asociación
Los ejemplares de Association son RegistryEntries que se
usan para definir asociaciones de muchos-a-muchos entre objetos en un modelo de información. Las
Associations se definen en más detalle en la sección
Asociación de RegistryObjects
Package
Los ejemplares de Package son RegistryEntries que
agrupan objetos RegistryEntries lógicamente relacionados. Uno uso de
Package es permitir que se realicen operaciones sobre un paquete completo de objetos. Por
ejemplo, todos los objetos que pertenecen a un mismo Package podrían borrarse con una
sola petición.
ExternalIdentifier
Los ejemplares de ExternalIdentifier proporcionan información de indentificación adicional
a RegistryEntry como un número DUNS, un Número de
Seguridad Social, o un alias al nombre de la organización.
ExternalLink
Los ejemplares de ExternalLink son RegistryEntries que incluyen
una URI para contener que se maneja fuera del registro. Al contrario que el contenido manejado, dicho contenido externo se
puede modificar o suprimir en cualquier momento sin el conocimiento del registro. RegistryEntry
se puede asociar a cualquier número de ExternalLinks.
Consideremos el caso donde una Organización Enviante envía un item de repositorio (por ejemplo, un documento WSDL) y desea
asociar un cierto contenido externo a ese objeto (por ejemplo, el Home Page de la organización enviante). El
ExternalLink permite esta capacidad. Un uso potencial de la capacidad
ExternalLink puede estar en una herramienta del GUI que visualice el
ExternalLinks en un RegistryEntry. El usuario puede hacer
clic sobre dichos enlaces y navegar a una página Web externa referida por el enlace.
No se espera que un proveedor JAXR se asegure de que el ExternalLink apunte a un recurso
válido y accesible. Èsto no es ningún diferente de una página Web con un hiperenlace inválido.
Slot
Los ejemplares de Slot proporcionan una forma dinámica para añadir atributos arbitrarios a
ejemplares RegistryEntry. Esta habilidad para añadir dinámicamente atributos a ejemplares
de RegistryEntry permite la extensibilidad dentro del modelo de información.
ExtensibleObject
El interface ExtensibleObject está implementado por la mayoría de los interfaces en el modelo
de información de JAXR. Proporciona los métodos que permiten la adición, cancelación y operaciones de búsqueda de ejemplares
Slot. El interface ExtensibleObject proporciona extensibilidad
al modelo de información de JAXR.
AuditableEvent
Los ejemplares de AuditableEvent son RegistryObjects que se
usan para proporcionar una ruta de auditoría para RegistryEntries.
AuditableEvent se describe en detalle en la sección Los
Interfaces IntrinsicObject y ExtrinsicObject.
User
Los ejemplares de User son RegistryObjects que son usados
para proporcionar información sobre los usuarios registrados dentro del registro. Los Users
están afiliados con Organizacitions. Los objetos User son
usados en la ruta de auditoria para un RegistryEntry.
PostalAddress
PostalAddress define los atributos de una dirección postal. Actualmente, se usa para proporcionar
información de la dirección de un User y una Organization.
Modelo de Información: Vista de Árbol
La figura 13 muestra la herencia o las relaciones entre las clases en el modelo de información. Observa que no muestra
los otros tipos de relaciones, puesto que se han mostrado ya en la figura 12. Los atributos y los métodos de la clase tampoco
se muestran. Las descripciones detalladas de métodos y atributos de la mayoría de los interfaces y de las clases están
disponibles en los documentos Javadoc del API JAXR.
Figura 13: Vista del Árbol del Modelo de Información.
Los Interfaces IntrinsicObject y ExtrinsicObject
El interface RegistryEntry es un interface abstracto que está más especializado por dos interfaces.
El interface IntrinsicObject es un interface de base común para la mayoría de los interfaces
concretos en el modelo. Los Subinterfaces del interface IntrinsicObject proporcionan el
metadata adicional (por ejemplo, Clasification, Association etc.)
para un RegistryEntry.
El interface ExtrinsicObject es un interface concreto que proporciona los metadata adicionales
para un item extrínseco del repositorio (por ejemplo, un documento WSDL o un documento de esquema XML) sobre el cual el
registro no tenga ningún conocimiento anterior. Se requiere un ejemplar de ExtrinsicObject para
cada item del repositorio.
Auditoría de Registro
Esta sección describe los elementos del modelo de información que soportan la ruta de auditoría del registro.
El método getAuditTrail de un RegistryEntry devuelve una
colección ordenada de AuditableEvents. Estos AuditableEvents
constituyen el rastro de intervención para el RegistryEntry. Los
AuditableEvents incluyen un timestamp para el evento. Cada
AuditableEvent tiene una referencia a un ejemplar User
que identifique al usuario específico que realizó la acción que dio lugar a un AuditableEvent.
Asociación de RegistryObjects
Un RegistryObject se puede asociar con cero o más objetos. El modelo de información define
una clase Association. Un ejemplar de esta clase representa una asociación entre un
RegistryObject y otro RegistryObject. Un ejemplo de dicha
asociación está entre los ExtrinsicObjects que cataloguan un nuevo item del repositorio y
otro item del repositorio donde el itém más nuevo reemplaza el más viejo como se ve en la figura 14.
Los tipos de asociación para los ejemplares Association son ejemplares
Concepts y por lo tanto son extensibles de forma definida por el usuario.
Figura 14: Ejemplo de Asociación de Entradas de Registro.
Clasificación de RegistryObjects
Esta sección describe cómo el modelo de información soporta la clasificación de RegistryObjects.
Un RegistryObject podría ser clasificado de muchas formas. Por ejemplo, una
Organization podría ser clasificada por su industria, por los productos que vende
o por su localización geográfica.
Un esquema general de clasificación se puede ver como un árbol de Concepts. En el ejemplo
mostrado en la figura 15, los RegistryEntries (realmente Organizations)
se muestran como rectángulos sombreados. Cada Organization representa un fabricante
de automóviles. Cada Organization está clasificada por el Concept
llamado Automotive bajo el Concept raíz llamado
Industry. Además, los fabricantes de automóviles de los E.E.U.U. son clasificados por el
Concept Geography. Similarmente, un fabricante de automóviles europeo
es clasificado por el Concept Europa bajo el
Concept Geography.
Un Ejemplo de Clasificación
El ejemplo muestra como un RegistryEntry podría ser clasificado por múltiples esquemas
de clasificación. Una esquema de clasificación está definido por un Concept que es la
raíz del árbol de Concept (por ejemplo, Industry, Geography, Product etc.).
Figura 15: Ejemplo que muestra un árbol de
Concept
|
[Nota]
Es importante precisar que los nodos oscuros no son parte del árbol del Concept. Los
nodos hoja del árbol Concept son Health Care,
Automotive, Retail, US. y Europe.
Los nodos oscuros se asocian al árbol Concept mediante un ejemplar
Classification que no se muestra en la figura.
|
Para poder soportar un esquema de clasificación general que pueda soportar clasificación de un sólo nivel y de varios
niveles, el modelo de información define las clases y relaciones mostradas en la Figura 16:
Figura 16: Vista de la Clasificación del Modelo de Información
La Figura 17 muestra un ejemplo de un ejemplar ExtrinsicObject para un objeto "Collaboration
Protocol Profile" [CPP] que está clasificado por un Concept que representa la Industria a la
que pertenece
Figura 17: Diagrama de Ejemplar de
Classification
Interface Concept
Los ejemplares de Concept se usan para definir estructuras de árbol en las que cada nodo del
árbol es un ejemplar Concept. Dichos árboles Concept se usan
para definir esquemas de clasificación u ontologías.
Los esquemas de clasificación basados en Concepts también se usan en el API JAXR para definir
enumeraciones extensibles (por ejemplo, el atributo phoneType en
TelephoneNumber).
En la figura 15, se definieron varios ejemplares de Concept (todos los rectángulos de color
claro). Un Concept tiene cero o un Concept para su padre y
cero o más Concepts para sus hijos inmediatos. Si un Concept
no tiene ningún padre, es la raíz de un árbol de Concept. Observa que el árbol completo de
Concept es definido recursivamente por un solo elemento del modelo de información llamado
Concept.
Interface Classification
Los ejemplares de Classification se usan para clasificar un ejemplar de
RegistryEntry con un ejemplar Concept dentro de un esquema
de clasificación.
En la Figura 15, los ejemplares de Classification no se mostraron explícitamente, pero están
implícitos como asociaciones entre los RegistryEntries (nodos hojas sombreados) y los objetos
Concepts asociados.
Clasificación Sensible al Contexto
Consideremos el caso representado en la figura 18, donde un perfil del protocolo de colaboración para ACME Inc. está
clasificado por el Concept Japan bajo el esquema de clasificación
Geography. En ausencia del contexto para esta clasificación, su significado es ambiguo. ¿Significa
esto que ACME está situada en Japón, o significa que ACME envía productos a Japón, o tiene otro cierto significado?
Para tratar esta ambigüedad un Classification podría opcionalmente ser clasificado por otro
Concept (en este ejemplo llamado isLocatedIn) que proporcione el contexto
que falta para la clasificación. Otro perfil del protocolo de colaboración para MyParcelService
se puede clasificar por el mismo Concept Japan donde esta clasificación se
asocia a un Concept diferente (por ejemplo, llamado shipsTo) para indicar
un contexto diferente que el que está usando ACME Inc.
Figura 18: Clasificación Sensible al Contexto.
Así, para poder soportar la posibilidad de clasificación dentro de múltiples contextos, un objeto
Classification podría él mismo ser clasificado por cualquier número de
Classifications que unieran la primera Classification
a los Concepts que proporcionan los contexto desparecidos.
En suma, el soporte generalizado para esquemas de clasificación en el modelo de información permite a las Organizaciones
Enviantes:
- Clasificar un RegistryEntry, enviando un Classification
que lo asocie con un Concept en un árbol de Concepts.
- Clasificar un RegistryEntry entre múltiples facetas, enviando múltiples objetos
Classification que los asocian con múltiples objetos Concept.
- Cualificar una clasificación enviada por un RegistryEntry, mediante los contextos por
los que está siendo clasificada.
Tutoriales
