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.