Modeling is an integral part of any software solution. In the software engineering world, a model provides an architectural representation of a real-world entity or process. In the context of business registries, such as Universal Description, Discovery and Integration (UDDI), such models could include organizational entities, businesses, and service interactions (in other words, service specifications).
Modeling in the business registry world does not include simply the services provided. Entities that participate as well as the services that are published or used are modeled. These models identify the relationships between the services and the business entities that manage them. They can also be used to define relationships among the business entities themselves. The service consumer, service provider, and parent entities or businesses need to be modeled themselves as well. Figure 6.1 depicts the entities and interactions that are typically modeled in a registry paradigm.
The UDDI information model includes the following roles:
Provider: information about the entity that offers a service or set of services
Service: descriptive information about a service
Binding: technical information on how to interact with the service
tModel (technology model): service interaction specifications
The subsequent discussions in this chapter are focused on these roles. Notice that the service consumers themselves are not necessarily described. Although useful, the current UDDI specification does not mandate that a service consumer be registered as a business entity. Note that there are times when a service provider and a service consumer fall under the same logical business entity, but they are simply different functions within that single entity.
Service providers create the business logic of a service that is required to perform a specific function. While the responsibilities of a service provider in the real world vary from industry to industry, a high-level summary is as follows:
Design and develop services
Deploy the services
Register services with appropriate service registries
Form business-level engagements with potential consumers of services
Set up billing as appropriate
Monitor the performance of deployed services
Plan newer versions of the services
Create a strategy to support multiple service versions and facilitate migration for service consumers
Service obsolescence
Figure 6.2 depicts the process service providers go through in developing their services. Business modeling is very prominent primarily in the initial phases.
UDDI provides a data structure that can model a service provider. It is the Business Entity data structure. Theoretically, it is possible for a legal business entity to create and register several business entities in a UDDI registry. However, from an architectural perspective, a one-to-one correspondence between a legal business entity and UDDI-registered business entity is a more sound design. In fact, Microsoft’s UDDI production registry enforces this rule, by allowing only one business entity per user account, although the test site allows several business entities to be registered by a single legal business entity (or a single user).
The one-to-one relationship between a legal business entity and a UDDI-registered entity can make it easy for UDDI operators to manage business listings in a suitable manner. For service providers as well, such modeling theme streamlines the processes such as designing and managing portfolio of services. Several company-wide policies can be enforced uniformly across all the services, contacts, and other information maintained by the UDDI registry. Due to these advantages, we strongly recommend modeling the entire company under one Business Entity data structure. An exception to this design principle should only be made for very large companies. This is discussed in Section 6.6.1. Figure 6.3 depicts this relationship between legal and UDDI-registered business entities and the business entity metadata.
There are several data elements associated with a UDDI business entity. These elements, together or alone, constitute the Yellow and White Page sections of the listing. Information such as contact name or phone number is part of the White Pages, while the taxonomy, under which the entity is categorized, constitutes the Yellow Pages. The complete list of data elements that are part of a UDDI-registered business entity can be found in the UDDI specification. Table 6.1 summarizes some of the key data elements.
Table 6.1. Data Elements Associated with a UDDI-Registered Business Entity
|
Element Name |
Description |
|---|---|
|
businessKey |
A unique identifier of the business entity |
|
operator |
Operator site that manages the business entity |
|
discoveryURLs |
URLs associated with the business entity |
|
name |
Repeatable. Human-readable name associated with a business entity |
|
description |
Repeatable. Short business description |
|
contacts |
Repeatable. Set of contact names, phones, email addresses, and addresses |
|
identifierBag |
Set of identifiers such as taxID number, associated with the business entity |
|
categoryBag |
Taxonomy information used to categorize the business entity |
The specifics of which elements are required and which elements are used in conjunction with others are also available in the UDDI specification.
Designing services that can be registered in UDDI requires a different kind of planning than traditional application design practices. In addition to ubiquitous object-oriented design and functional decomposition, several new aspects must be tack-led. These design principles are a by-product of the service-based computing paradigm.
The UDDI registry aims at providing information regarding a business entity and a service that makes it easy for a service consumer to review metadata and technical information about both. While the metadata information is useful in forming a business relationship with the service provider, the technical information helps in understanding how the service interacts, the data format it uses, and the service bindings it supports. These two sets of information are essential for service discovery. From a service consumer perspective, searching for a suitable service can be narrowed down by several attributes. Chief among these attributes are taxonomies, service interaction interfaces, and service bindings. These elements are at the heart of service modeling.
The first step of designing a service is to consider a set of taxonomies that the proposed service should belong to. The word taxonomy means a system of categorization. It denotes a formal approach used for categorization of any set of entities. Some of the examples of taxonomies are:
North American Industry Classification System (NAICS)
Universal Standard Products and Services Classification (UNSPSC)
Geographical (Geo)
Standard Industrial Classifications (SIC)
As a service provider, the choice of taxonomies to register the service under is important and is driven by the profile of the customer base and the business model of the service provider. For example, a service used by the banking industry should be classified within a taxonomy related to banking, whereas a service for consumers should be registered within a retail-related taxonomy.
We see how using taxonomies help service discovery when we discuss service consumers in Section 6.7. The UDDI project envisions three different types of taxonomies — industry, product or service type, and geographic.
Note
Services can be categorized within multiple applicable taxonomies. For example, a sales tax calculator service might be applicable in various industry or product type taxonomies as well as within a specific geography. UDDI allows a service to be categorized in an unlimited number of taxonomies at the same time.
Although UDDI has several popular taxonomies built-in and several others may be registered within the UBR by other standards bodies, it is possible that a service provider may find them inadequate or inapplicable for the specific service. In such a case, it is possible to register a new taxonomy that is tailored to the needs of the proposed service. UDDI provides the necessary Application Programming Interfaces (APIs) for this purpose. However, a decision to create a new taxonomy should be taken with utmost consideration to standards-compliance and the ability of potential service users to find the service. A service registered in a taxonomy that is not widely adopted or known will be rarely discovered and used. Once the decision to create a new taxonomy is made, taking it to standards bodies should also be considered to gain broader acceptance for it. At the very least, the taxonomy should be widely known and accepted within the relevant community, if not made into an industry standard. Two types of taxonomies can be registered with a UDDI registry — checked and unchecked. Unchecked taxonomies can be published by anybody at any time, while a checked taxonomy undergoes a thorough validation process. Checked taxonomies are explained in Chapter 10. UDDI APIs also provide the ability to register a service in several taxonomies at the same time. These APIs are discussed Chapters 7–9.
After the taxonomies for the service registration are determined, the next task a service provider must tackle is to determine the service interaction interfaces to adhere to. A service interaction interface is analogous to the API for an application. Like an API, it provides details such as various methods or function calls supported and the parameters used while invoking those methods. There may be possible invocation sequences associated with an interface described explicitly or implicitly. For well-known services within established industries, the interfaces may be already defined by standards bodies or consortiums. In such cases, the service designer may decide to abide by one or more of the published interfaces. For wider interoperability with several potential service consumers, it is desirable to adopt as many relevant published interfaces as possible. That way, a service consumer can choose the best suitable interface to interact with the service. This must be weighed against the investment required to implement the methods defined by different interfaces as well as the architectural constraints associated with them.
Like the taxonomies, service interfaces also require the “make vs. adopt” consideration. If there is no published or widely adopted interface for the specific service or if the service provider wishes to create a new service interface, it is possible to do so in UDDI. However, this puts the onus of popularizing the interface on the service provider itself. Usually, a service provider should adopt an existing interface, defined by relevant standards body or consortium. In the absence of a suitable interface definition, registering a new interface should be supplemented by initiatives for broader market adoption and taking the interface to a standards body. In Chapter 8, we discuss how to register the interface for a service and the related APIs.
Note
Services may comply with one or more than one interfaces and categorize within one or more than one taxonomy. The decision depends on the service consumer being targeted.
In the Web services realm, service interaction interfaces are described using Web Service Description Language (WSDL). WSDL provides all the necessary information about the messages a service should accept and the corresponding response. For the discussion in this book, we concentrate on the WSDL-based service interface definition. However, in the UDDI registry, it is possible to use other definitions as well. Table 6.2 shows some of the key data elements associated with the business service data structure.
Figure 6.4 depicts decision points that are required by a service provider while registering a service in the UDDI registry.
Table 6.2. Data Elements Associated with a Service
|
Element Name |
Description |
Required |
|---|---|---|
|
businessKey |
Unique identifier of the parent business entity of the service |
Yes |
|
serviceKey |
A unique identifier of the service |
Yes |
|
name |
Repeatable. Human-readable name associated with the service |
Yes |
|
description |
Repeatable. Short service description |
No |
|
bindingTemplates |
Structure that holds service binding information |
Yes |
|
categoryBag |
Taxonomy information used to categorize the service |
No |
From a design perspective, tModel is the UDDI structure to capture taxonomies as well as service interaction interfaces. The service provider would find or create and abide by various tModels. Recall from Chapter 5 that a tModel is a UDDI representation of certain specification (or version thereof). The specification, in this case, can denote either a taxonomy or a service interface definition. tModels can be thought of as technical fingerprints. Like fingerprints for human beings, they uniquely identify a certain entity. The UUID associated with a tModel can provide an accurate reference to a certain classification scheme or interaction interface. When teams from two or more companies work together on a business-to-business (B2B) integration project, tModels provide precise information about each company’s compliance preference. When the tModels match exactly for two companies, the integration among their systems will be comparatively easy.
The implementation details of using tModel for taxonomy or service interface declaration are discussed in Chapter 8. Table 6.3 shows some of the key data elements associated with the business service data structure.
Service bindings contain technical details of a service. Typically, they include the communication protocols supported, the service interaction interfaces abided by, and the service entry points. A service provider would normally aim at maximizing the usage of the service deployed. One of the attributes that can lead to a wider adoption of a service is support for various communication protocols. A service that is versatile and supports multiple protocols will be more accepted by potential service consumers. Service consumers may choose the communication protocol they find most suitable to interact with the service. UDDI provides a data structure bindingTemplate to express service bindings. Table 6.4 shows some of the key data elements associated with the service binding structure.
Table 6.3. Data Elements Associated with a tModel
|
Element Name |
Description |
Required |
|---|---|---|
|
tModelKey |
A unique identifier of the tModel |
Yes |
|
operator |
Operator site that manages the tModel registration |
Yes |
|
name |
Human-readable name associated with the tModel |
Yes |
|
description |
Repeatable. One short tModel description per language |
No |
|
overviewDoc |
A reference to information about the tModel and specification associated with it |
No |
|
identifierBag |
Set of identifiers associated with the tModel |
No |
|
categoryBag |
Taxonomy information used to categorize the tModel |
No |
While the initial modeling of a business entity and its services is done during the first few phases of the service lifecycle, modeling needs exist in other phases as well. Modeling in these cases ensures continuity of service and offers a smoother migration path when the service is phased out.
An access point for a service, as registered with a UDDI registry, is the same across all service consumers that discover it. Naturally, one instance of a service is unlikely to be able to cater to many clients. Thus, from an architectural point of view, the access point should be treated as an entry point for the service. The software component at this entry point would be responsible for creating an (dedicated) instance of the service logic as appropriate to serve a client.
Service billing can be very complicated and thus may significantly influence service modeling needs. The functionality that a service is intended to provide can have several options available — such as availability, maximum usage, and the number of options allowed. The revenue model can be based on these options. For example, a service might be available on a flat-fee, unlimited access option, while it may also be available on a per-transaction fee option. Based on the complexity and mutual exclusivity of the billing options, a service may be modeled in a registry as one or more services.
Table 6.4. Data Elements Associated with a Service Binding
|
Element Name |
Description |
Required |
|---|---|---|
|
bindingKey |
A unique identifier for the binding |
Yes |
|
description |
Repeatable. Short binding description |
No |
|
accessPoint |
Data about the service entry point. Could be URL, email, phone number |
Yes |
|
hostingRedirector |
Reference to a different binding that contains service access information |
Yes, if accessPoint is absent |
|
tModelInstanceDetails |
Reference to tModels that the service complies with under this binding |
No |
During the service lifecycle, there may be several versions that a service will go through as its functionality is enhanced. In some cases, it is desirable to keep the older version for business continuity; in other cases, it may be discontinued because it is no longer valid. Based on these needs, a new version of a service can be registered as a new service, or it can replace the old service registration. Versioning of services and tModels is discussed in detailed in Chapter 10.
As discussed earlier, in a typical scenario, one-to-one correspondence between a legal business entity and a UDDI-registered business entity is recommended. In some cases, however, this design principle must be relaxed. In a large company, it is conceivable that there would be several business units with different goals, business models, or even markets. One such example is General Electric (GE). GE, as a business entity, is a holding company with several companies under its umbrella — for example, NBC (an entertainment company) and GE Finance (a financial services company). In this scenario, one business entity represents all the businesses the company is in.
It would be desirable that the UDDI-registered model in this case would provide the flexibility for different business units to register their business entity, while still maintaining relationship with a “parent” business entity. UDDI provides a construct called publisher assertions for this purpose. Figure 6.5 depicts a UDDI business entity model using publisher assertions.
Publisher assertions are used to make the relationship between various entities registered at a UDDI site visible. Using a set of publisher assertions, a holding company can relate it to all its constituent companies and vice versa. Publisher assertions is a two-way protocol that requires an approval (assertion) of the rela-tionship from either side. Thus, in this scenario, the business entity representing the holding company will signal its relationship with one of the constituent companies, which in turn will assert that the relationship exists. A service consumer, after discovering either of these companies, can get all the companies related to each other through the assertions.
The two-way nature of the assertion protocol avoids the scenario where a rogue business entity tries to assert itself as part some well-known and well-respected business entity. The confirming publisher assertion is only necessary when the businesses on each side of the relationship are published (owned) by different publishers. In the case where both the businesses are owned by the same publisher the confirming assertion is not necessary.
Note
Unless and until both the parties assert the relationship, it is not visible to anybody else. Only the controlling publisher of a business entity can initiate a publisher assertion for that entity.
Based on the discussion hitherto, we see that a legal entity can publish several services. In turn, each service can be classified in multiple taxonomies. Each service can also define multiple service bindings; each service binding specifies a different interaction mechanism. In addition, each business entity can be engaged in multiple publisher assertions. Figure 6.6 highlights these relationships.
Like the service providers, service consumers also must follow a certain process to use registry-based services. The process begins with the identified need for a certain type of service or services and concludes with maintenance activity. The full process is as follows:
Identify the business needs for services
Search for appropriate service providers and form business relationships
Use appropriate services
Monitor the performance of services
Manage portfolio of services
Migrate a new service as appropriate
Figure 6.7 depicts the process service consumers go through in using services.
As mentioned earlier, the UDDI specification does not require a service consumer to be a registered entity. Thus, a potential service consumer need not go through the modeling exercise as far as business entity is concerned. However, it still needs models for its own processes and information requirements to be able to incorporate vendor services.
Incorporating the service-based interaction paradigm will undoubtedly require business process changes for a service consumer. The changes in the process can come in the form of adopting processes or formating standards related to the interaction, in identifying vendors and/or service functionality or service migration. Before a service consumer is ready to use a service, it must first address such process changes. Detailed process modeling is essential in this case. The effort typically varies based on the complexity of the processes. The need for services and related interactions emerges from this exercise.
Before a service consumer can use services from any service providers, it must first decide the categories of companies that will provide the required functionality. The choice of categories may be obvious in some industries while in others, a more thorough research may be required. When choosing a certain category, it should be broad enough to discover a good number of service providers, but narrow enough to pare down the number of qualifying companies. For example, when searching for a 401(k) provider, the “Financial Services” category may be too broad. A category such as “Third-party financial services for pension funds” would be a better choice.
Once an industry category (taxonomy) is chosen, the interaction standards must be selected as well. These standards will typically define the interaction sequence, specific operations, or workflow steps as well as data formats. Based on the business processes, and infrastructure, certain standards may lend themselves as a better choice than others. For example, if a company already has XML-savvy systems, XML-based standards are useful, while for others, EDI-based standards may be good to exchange information.
In UDDI, both these capabilities are expressed in the form of tModels. Thus, a choice of taxonomy and interaction model will boil down to choosing corresponding tModels. In Chapter 9, we discuss how service consumers discover tModels and services using the UDDI APIs.
Once a set of service providers and services are determined, the next step required is the service integration model. A service consumer will typically have an existing infrastructure and applications into which these services are incorporated. Foraseamless experience, the discovered services must be integrated well with existing infrastructure. An advanced approach for this can call for building a service experience that is unique to the organization and its environment. Building such an experience may be easier with a set of standardized tools that can introspect the specifications associated with the concerned tModels. A good integration model should take into account the service delivery platforms, formats, and usage model.
Naturally, it is conceivable that once a search on suitable services is performed and they are discovered, there may not be a need to change the service provider forasignificant amount of time. It would be desirable in such a case to cache a service reference. A cached service reference will avoid the need to rediscover a service for every interaction with that service; it will also ensure that there is no error in choosing the right service.
The UBR does not provide a direct solution to this problem, as it is geared toward service publishers saving references to corresponding services. From a service consumer perspective, one solution for this is using a private UDDI registry as depicted in Figure 6.8.
A private registry, such as one provided in Microsoft .NET Server, is an implementation of the UDDI specification that can be used as a private instance of a registry. The registry owner, in this case, would be free to keep any useful data for business entities and services. In case of reference caching, a service reference can be imported from a UBR node and kept locally. Every time there is a need to look up the service, the imported reference can be used.
The service consumer can in essence create a synonym for the found service or services. The synonym, in this case, could also carry some contextual information about service usage. Typically, this would include authentication and authorization policies.
A less likely but possible usage model could also be thought of when a service reference is exported to UBR. This usage is more likely with a service provider that chooses to publish its available services globally from its local portfolio.
Business modeling is an important task when adopting the service-based computing paradigm. It ensures that services and applications can discover and interact efficiently while also providing the brick-and-mortar entities behind the service interactions a means to exist in this paradigm. In Chapter 12, we present a case study that delves into the tactical specifics of business modeling for a supply chain environment.
In the next few chapters, we discuss the interaction with a UDDI registry using the UDDI APIs.