Main Page

Previous Section Next Section

The JAXR Information Model

Application developers using JAXR interact only with JAXR's domain object model; the provider translates that into the model of the specific registry standards.

The JAXR information model is contained in the javax.xml.registry.infomodel package and is quite straightforward. The model consists of two logical groups of classes:

Let us look at the object that models business entity relationships in the information model shown in Figure 12.3:

Click To expand
Figure 12.3: The core JAXR information model

Keep in mind that this information model refers to the logical relationships in the JAXR level. It is not the content itself but logical metadata about the content that is stored in the underlying repository. Storing an Organization does not mean an Organization object is serialized and stored in the registry. It means that application clients can describe a business as an Organization. When the appropriate JAXR API is called to publish the Organization, this Organization will be translated into the model of the underlying registry by the JAXR provider (e.g., an Organization maps to a businessEntity in UDDI), and the appropriate API for the registry will be invoked (e.g., save_business) with the required SOAP message. We will look at this mapping in further detail later in this chapter.

The JAXR information model has been developed with an object-oriented approach and is therefore easy to understand. It uses inheritance between different interfaces to abstract out the common behavior. At the core of the information model is a javax.xml.registry.infomodel.RegistryObject.

Figure 12.4 shows the physical generalization relationship. All the objects discussed till now, as well as some others discussed in subsequent sections that conceptually must be represented or sent to the registry, implement this interface. In short, from an abstract perspective, everything in the registry is a RegistryObject.

Click To expand
Figure 12.4: Inheritance relationships in the information model

Classification of Registry Data

In Chapter 6, we discussed taxonomies and classification in the UDDI registry. Arranging and grouping the logical relationships in the information model is one of the code features of any registry. A good example of arranging information is a Web-based search engine, such as For example, a person looking for a bank near home in Connecticut could drill down through the following categories:

Home > Business and Economy > Shopping and Services > Financial Services > Banking > Banks > By Region > U.S. States > Connecticut and arrive at a listing for Flute Bank (our fictitious bank). There are other ways to reach the same listing, including

U.S. States > Connecticut > Cities > Manchester > Business and Shopping > Business to Business >

This arrangement or categorization based on names is referred to as a taxonomy—a generally accepted standard of grouping. Taxonomy is important because it allows RegistryObjects to be discovered quickly and published in a logical manner. In JAXR, a RegistryObject is classified using the Classification interface, analogous to the catgegoryBag in UDDI. A RegistryObject can have multiple Classifications. For example, in a registry, Flute Bank, which is an Organization, can be classified by geographical location, accounts offered, banking type (Internet or branch-based), and so on. Each Classification may belong to one ClassificationScheme or taxonomy (Figure 12.5).

Click To expand
Figure 12.5: Classification of registry objects

For example, the first lesson in junior high chemistry begins by grouping matter as in Figure 12.6. This "matter" scheme is valid for matter but not for, say, library books. For these, another scheme, the Dewey Decimal system, uses a combination of letters and numbers to coordinate materials on the same and related subjects, to make them easier to find on library shelves. Similarly, business organizations use two common classification schemes: D-U-N-S and NAICS.

Click To expand
Figure 12.6: The basic subdivisions of matter

The taxonomy itself can be internal or external to the provider, meaning that its structure is resident inside the provider or is represented somewhere outside. NAICS is an example of an internal taxonomy, because the scheme and all the codes are available inside the JAXR provider (even though NAICS is maintained and specified by an external organization). In Chapter 11, we used the example of Flute Bank and its business partner, OfficeMin. Figure 12.7 shows how NAICS assigns codes to organizations such as OfficeMin.

Click To expand
Figure 12.7: NAICS code assignment

Figure 12.8 shows the realization of the OfficeMin NAICS classification and is called an internal classification in JAXR, because it uses an internal taxonomy. Because internal taxonomies are directly available in the JAXR provider layer, the client can browse the taxonomy structure and the provider can enforce validation rules for registry objects classified against such a scheme.

Click To expand
Figure 12.8: Classification with an internal taxonomy

An example of an external taxonomy is the microsoft-com:geoweb:2000 scheme (based on the ISO 3166 standard) in the Microsoft registry shown in Figure 12.9, which allows classification by geographical location.

Click To expand
Figure 12.9: An example of an external taxonomy

The taxonomy is represented by ClassificationScheme interface instances. Its taxonomy values and structure are represented by Concept interface instances. Figure 12.10 shows how the microsoft-com:geoweb:2000 taxonomy can be represented with the topmost element of the tree as a ClassificationScheme and subsequent levels as Concepts.

Figure 12.10: Classification with an internal taxonomy

Association of Registry Data

Just as the UML model allows a relationship between two classes to be stereo-typed as an association class, JAXR defines an Association interface, which can be used to set up a relationship between a source RegistryObject and a target RegistryObject instance.

A User can associate two objects owned or created by that user. For example, an administrator may create a parent-subsidiary association between two Organizations. Associations can be created between objects owned by separate users and may require confirmation by one or more of those users.

In Figure 12.11, a UDDI user creates a peer-peer relationship between Flute Bank and OfficeMin. The contact person for OfficeMin has to confirm and accept this relationship. JAXR provides APIs to create, update, and confirm these associations programmatically, as we will see later.

Click To expand
Figure 12.11: An extramural association between two organizations

Previous Section Next Section

JavaScript Editor Java Tutorials Free JavaScript Editor