|
|
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:
Interfaces that model metadata that can be submitted to the registry (e.g., business and service information)
Interfaces that describe how to get the metadata and content out of the registry-repository
Let us look at the object that models business entity relationships in the information model shown in Figure 12.3:
A business, such as a corporation whose data is contained in the registry, is represented by an Organization instance. An Organization can have multiple Organizations under it or can refer to another organization as a parent (for example, a business may have multiple divisions or may be a subsidiary of another).
People are represented as User objects. There is an obvious relationship between Organizations and Users. An Organization has a primary contact person represented by a User, it can have multiple Users who make up the Organization, or individual Users can be affiliated with an organization. A User will also have one or more EmailAddress objects where he or she receives email, a PersonName, and, optionally, a URL, such as a home page location (Figure 12.3 does not show the java.net.URL).
A physical address is represented as a PostalAddress object. An Organization will have a primary address (e.g., a corporate headquarters), and a User will have a PostalAddress as a part of the contact information. Similarly, an Organization and a User will have telephone numbers associated with them, represented as TelephoneNumber objects.
An Organization can offer one or more services, represented by Service objects. Each Service can have multiple ServiceBindings that specify the details about the protocol binding information for that service. (Recall that in Chapter 5 we looked at how the same abstract definition can have multiple binding elements.)
A ServiceBinding has attributes that describe the location where the service can be accessed and, optionally, another ServiceBinding, in case the service is redirected.
A ServiceBinding is associated with one or more SpecificationLink objects that point to the technical specifications defining the service (e.g., a WSDL file for the Web service).
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.
 |
All elements of this model are described as interfaces. The actual implementations are provided by the JAXR vendor implementation.
|
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.
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 Yahoo.com. 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).
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.
|
The Dun & Bradstreet (D&B) Data Universal Numbering System (D-U-N-S) is a unique nine-digit identification sequence that provides identifiers for single business entities while linking corporate family structures together. It is now the standard for all United States federal government electronic commerce transactions. A company that plans to engage in business with the U.S. government will need a D&B D-U-N-S number. More information is available at www.dnb.com/duns_update.
The North American Industry Classification System (NAICS, pronounced nakes) has replaced the United States Standard Industrial Classification (SIC) system. It is a taxonomy for e-business devised by the U.S. Census Bureau and is used to classify businesses and services by the industry to which they belong and the business processes they follow. It was developed jointly by the U.S., Canada, and Mexico to provide new comparability in statistics about business activity across North America. Details can be found at www.census.gov/epcd/www/naics.html.
|
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.
|
For UDDI registries, the JAXR specifications require that NAICS, ISO 3166, and the United Nations Standard Product and Services Classification (UNSPSC) code be internal taxonomies. This is one of the value-added features of JAXR for UDDI. Internal taxonomies are supported only by level 1 JAXR providers.
|
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.
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.
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.
|
Internal taxonomies are supported by level 1 JAXR providers.
|
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.
|
An association is called intramural if the objects are owned by the same user and extramural if the owners are different.
|
|
|
