Level: Introductory Steve Burbeck (sburbeck@us.ibm.com), Senior Technical Staff Member, IBM Software Group
Steve Graham (sggraham@us.ibm.com), Architect, IBM Emerging Technologies
01 Dec 2000 This article introduces and encourages the use of taxonomies for categorizing services in ways that make them easy to locate. We begin by describing the problem addressed by taxonomies and then introduce a scenario that requires one. We discuss the need for taxonomies from the perspective of service providers and requestors. We then create the requirements for an architecture to support categorization and a proposal on how this architecture will address these needs.
A programmer who designs applications that collaborate with other services must determine which service or kind of service their application should invoke, out of the overwhelming number of B2B services available on the Internet. How can the designer make such a choice? How does the developer know if
a service fulfills the business need of the application? A categorization
approach focuses this process into a manageable problem.
A taxonomy is a hierarchical, structured presentation of information
by categories. A taxonomy, in our case, is a hierarchical organization
of B2B service descriptions. This organizational structure will aid humans
in searching for the right kind of service that will meet a business need.
Taxonomies already naturally occur in the business world. The North American
Industry Classification System (NAICS), for example, is a categorization
of North American businesses. If you can imagine
the Web without any kind of search engine or directory service like Yahoo,
Infoseek, etc., you can begin to understand what it would be like for the B2B services
Internet to go without a categorization mechanism.
An example scenario: CornFlowers.com
CornFlowers.com is an imaginary, small flower-retailing business in
Des Moines, Iowa. It is also an e-business. And, in addition to the general flower
retailing business, CornFlowers.com specializes in growing and selling
a number of varieties of orchids.
CornFlowers.com participates as a buyer in at least two B2B e-business
markets.
-
It buys most of its standard types of flowers over a B2B link with its
primary wholesaler.
-
It buys specialty items (for example, accessories, balloons, vases and
planters) from a florist supplies broker.
CornFlowers.com now wants to provide flower-selling
e-business services to clients over the Internet. It participates as a
supplier in two industry-oriented brokers, FTD.com's industry broker and
800Flowers.com's broker as well. CornFlowers.com also wants to provide flower-selling
e-business services to other clients outside the big flower-retailing
brands (FTD and 800Flowers). As a result, it wants to appear in flower-related
e-marketplaces (for example, weddings and funerals) in the Des Moines
area. Finally, CornFlowers.com is active in Orchids of America, a
special interest group related to orchids. It is in CornFlowers.com's business
interest to be visible as a provider of B2B services in this group as well.
Note that CornFlowers.com's business success depends upon being listed
in appropriate, but different, categories with several brokers. It wishes
to be listed geographically with FTD and 800Flowers. It wishes to be listed
according to the flowers they sell, with the Des Moines broker, and wishes
to be listed by its specialized orchid varieties with the Orchids
of America broker -- there are thousands of varieties of orchids and no
one specialist does them all. Since CornFlowers.com's business survival
depends on these listings, the company cannot be content with a white pages
listing, where it would be lost in the clutter of a large white pages directory.
Nor can it simply rely on putting lots of meta-tag hints in its Web pages
and hope that various crawlers will find the site. It should actively try to
do whatever is necessary to get itself listed in the right categories by
the right brokers.
The need for categorization
To make our example scenario more credible, we will list some of the assumptions
and characteristics of service requesters and service providers.
First, each service provider wants to maximize the number of times its services
are invoked. We assume the service provider fulfills some business need
by publishing a service's availability. Perhaps the service provider charges
for the use of the service; perhaps a free service supports other income
streams for the service provider; or perhaps it is just good will to their
resellers and partners.
Second, service requesters build applications that invoke services to
satisfy business needs. The searching that is done at design time or runtime
by a service requester is not based upon casual curiosity, it is intended
to find the best; service available to invoke for some business purpose.
Third, there is no single taxonomy of all possible services. Many taxonomies
of services will exist and most will be domain specific and designed by
domain experts.
Fourth, any service can appear in one or more categories in one or more
taxonomies. There might be limitations because of business
relationships CornFlowers.com has with these brokers, but for the sake
of this example, we will consider that they can be listed in any category
or taxonomy without such limitations.
Finally, only humans can determine what business need is satisfied
by a particular service. Artificial intelligence techniques for the foreseeable
future are no substitute for human judgment in determining, based on the
description of the category, whether the services within that category
match the required business need.
Service requesters need a target-rich environment
The service requester wants an environment that looks for services that contain many possible relevant targets.
At design time, a business development manager or programmer examines the
kinds of services that a program might interact with. The business
development manager or programmer wants to minimize the number of entries
that must be examined, browsed, or considered to locate services that can
fulfill the required business need.
How would a designer working for WeddingsAreUs.com build Des Moines-based
flower-buying services into an application? In the best-case scenario,
let us assume that flowers are sold using a domain-specific protocol called
sellFlowers. If the search criterion used at runtime was that
all services that implement the sellFlowers protocol, the response
might be services provided by flower retailers from all over the world.
There will be many services that match this criteria, but not all
will be useful to WeddingsAreUs.com. The service requester would have to
wade through many of these entries before finding the subset of services
that meet the business need. This filtering process would require human
intervention at runtime to match the candidate services to the business
need. Furthermore, this is a performance hit on both service registration
directories and the requester to process all the descriptions for services
that are not relevant to the business problem at hand. Worse, this search
will miss all sellers who sell flowers in Des Moines using some other simple
sell
protocol and not the industry-specific sellFlowers
protocol.
Therefore, most service requesters will interact with a broker that
uses a taxonomy relevant to a business problem. Designers of the service
will examine the taxonomies supported by various brokers, review the services
registered in appropriate-looking categories, and examine the protocols
that are typically used by services within these categories. The designer
chooses the broker and a category such that any service in this category
is usable, because the category specifies services that meet the specific
business need. In other words, the broker and category are chosen so that
a service find query, such as all services in the category flowers.FTD.com/retail/USA/Iowa/DesMoines,
would be very likely to provide a number of valid services. Thus we refer
to the broker hosting this taxonomy as a target-rich environment
for the service requester.
At runtime, there is no human judgment available to determine if a service
matches a required business need. Applications can filter the services
within a category, based on the capabilities of the application's runtime
environment. For example, is SOAP supported?
Is HTTPS supported? Can the application collaborate with some specific
.simpleBuy protocol? However, applications cannot decide
which services meet the business need. So a target-rich environment must
imply that all services within that category satisfy the business need
associated with that category.
A simple keyword search, for example, does not provide a target-rich
environment at runtime. For example, the keyword Flowers could be
associated with Flower Retailing services, Flower Nursery services, Botanical
Gardens, Scientific classification of flowers, and so on. Complex
combinations of keywords could be used to increase the accuracy of the
search. A categorization approach is better since it relies on human judgment
when categorization is done and when the category is specified by the designer
of the service request, rather than requiring human judgment at runtime
to determine if a service fulfills a business need of the service requester.
At design time, the restrictions on a target-rich environment are less
strict. An application designer can use keywords to locate categories that
might be useful starting points. After examining the descriptions of the
categories, the designer can then use judgment to determine if the intent
of the category matches the business need. A target-rich environment makes
this coarse-grained taxonomy browsing and fine-grained category examination
a more efficient use of the designer's time.
Target-rich environments are provided by service brokers that organize
services around one or more taxonomies. The problem for the service requester
is to most efficiently locate where the most relevant services are advertised.
This task is accomplished by locating the service brokers that provide
an organizational structure that is meaningful to the service requester.
Typically, the organization already knows which brokers are pertinent to
its line of business. There are many examples in the business world of
brokers, marketplaces, or aggregators, where the business model is based
on providing target-rich environments to bring collaborators (buyers and
sellers) together to complete a business transaction.
Service providers need to be seen in the right places
Service providers have a business goal to maximize search hits from
service requesters. To satisfy that goal, the service provider must seek
to advertise its services wherever service requesters are likely to look,
and in a way that makes sense to the business problem a service requester
is trying to solve. How and where the service is advertised is critical
to the service provider's business success. Therefore, the service provider
is motivated to actively push the service advertisement to reach all known
target-rich environments. The service provider would be irresponsible to
passively wait to be visited and properly categorized by service crawlers
or search engines.
Service providers will need to register services with one or more service
brokers. The registration must happen separately for each service broker
with the direct involvement of the service designer, because each broker
may use a different taxonomy. Designers must be involved so that they
can know which categorization scheme is used and make appropriate recommendations
on the category the service should appear in. For example, CornFlowers.com
might want to register its FlowerSelling e-business service to FTD.com.
Browsing through FTD.com's taxonomy protocols, CornFlowers suggests
using flowers.FTD.com/retail/USA/Iowa/DesMoines/ according to
the taxonomy description pointed to by FTD.com's services broker.
The choice of categories in which to register a service is a collaboration
between humans. The service designer understands the business need addressed
by the service. The person maintaining a taxonomy for the service broker
understands what criteria are used to place services into categories within
the taxonomy. In some cases, human beings representing the service
provider and service requester may need to communicate to agree on which
categories are the best for a particular service.
To summarize, a taxonomy represents a formal portrayal of business semantics
of services. It provides a rigorous mechanism allowing a designer to bake
in business semantics to the application, by specifying the service broker
and the category of service that should be used to find services. Because
of this rigor, the service requester does not require human intervention
at runtime to choose which service to bind to.
The Yellow Pages example is illustrative here. Think of the entire set
of Yellow Pages within the USA as a taxonomy organized first by geography
and then by type of service. When I need a plumber, I go to the appropriate
geographical (or local) Yellow Pages and look up listings under the category
"Plumber." All the plumbers provide essentially the same service, and with
the information I can get from the Yellow Pages listing, I may choose one
over the other based on hours, which credit card a plumber takes,
or simply personal preference. Local businesses advertise in the
Yellow Pages because it is a target-rich environment; consumers go to the
Yellow Pages to get information about local businesses. Typically, local
businesses do not advertise in the white pages, because alphabetical listing
is not a target-rich environment for consumers looking for plumbers. Further,
if I already know the plumber I want to use, I don't even bother using
the phone book, I just call.
 |
Building in categorization
Categorization needs to be a crucial part of a Web services directory. A taxonomy provides the semantics of a business' services on the Web categorized, so that other businesses can locate them quickly and use their services effectively. At design time, the application designer needs to be able to search the taxonomy efficiently. A target-rich environment thus makes this coarse-grained directory browsing and fine-grained category examination a more efficient use of the designer's time, which in turn, speeds the application development process.
Resources
About the authors  | | | Dr. Burbeck joined IBM in January, 1995 as a Senior Consultant specializing
in Object Technology. In 1997 he moved to IBM Research for a year to study adaptive and self configuring systems. From 1998 to the present he has been a Senior Technical Staff Member in the IBM Software Group with a focus
on emerging technologies. His current interests include open-source software,
Web services, and Peer-to-Peer computing.
Prior to joining IBM, Dr. Burbeck directed computing and statistics
at the Linus Pauling Institute of Science and Medicine, co-founded a startup
that pioneered Smalltalk for the IBM PC/AT, worked for two years at Apple
Computer as a Product Marketing Manager for object-oriented development
tools, and spent four years as vice president of development and operations
at Knowledge Systems Corporation (a software tool and consulting company
specializing in object-oriented design and consulting). You can reach him
at sburbeck@us.ibm.com
|
| | | Steve Graham is an architect in the Emerging Technologies, part of IBM's software group.
Steve has spent the last several years working on service-oriented architectures, most recently
as part of IBM's Web Services Initiative. Prior to this, Steve worked as a technologist and
consultant working with various emerging technologies such as Java and XML. Prior to this, he was
an architect and consultant with IBM's Smalltalk consulting organization.
Before joining IBM, Steve was a developer with Sybase, a consultant and a faculty member in the Department of Computer Science at the University of Waterloo. Steve holds a BMath and MMAth in computer science from The University of Waterloo.You can reach him at sggraham@us.ibm.com. |
Rate this page
| 
