U.S. patent application number 12/254346 was filed with the patent office on 2009-04-23 for web service architecture for product selection and dynamic catalog generation.
This patent application is currently assigned to ORACLE INTERNATIONAL CORPORATION. Invention is credited to Meng Feng, Muralidhara Varmaraja.
Application Number | 20090106128 12/254346 |
Document ID | / |
Family ID | 40564430 |
Filed Date | 2009-04-23 |
United States Patent
Application |
20090106128 |
Kind Code |
A1 |
Varmaraja; Muralidhara ; et
al. |
April 23, 2009 |
Web Service Architecture for Product Selection and Dynamic Catalog
Generation
Abstract
Various systems and methods for providing product selection and
dynamic catalog generation as a Web Service are disclosed. One
method involves receiving a Web Service signature requesting access
to catalog information. The Web Service signature comprises
information indicative of a sales context. The method then
dynamically generates a catalog, based upon the sales context. The
method can also involve generating a second Web Service signature,
which includes information indicative of the catalog, and sending
that second Web Service signature to the application that requested
access to the catalog information.
Inventors: |
Varmaraja; Muralidhara;
(Fremont, CA) ; Feng; Meng; (Foster City,
CA) |
Correspondence
Address: |
CAMPBELL STEPHENSON LLP
11401 CENTURY OAKS TERRACE, BLDG. H, SUITE 250
AUSTIN
TX
78758
US
|
Assignee: |
ORACLE INTERNATIONAL
CORPORATION
Redwood Shores
CA
|
Family ID: |
40564430 |
Appl. No.: |
12/254346 |
Filed: |
October 20, 2008 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60981446 |
Oct 19, 2007 |
|
|
|
Current U.S.
Class: |
705/26.1 ;
707/999.102 |
Current CPC
Class: |
G06Q 30/0601 20130101;
G06Q 30/06 20130101 |
Class at
Publication: |
705/27 ;
707/102 |
International
Class: |
G06F 17/30 20060101
G06F017/30 |
Claims
1. A method comprising: receiving a Web Service signature
requesting access to catalog information, wherein the Web Service
signature comprises information indicative of a sales context; and
dynamically generating a catalog, based upon the sales context.
2. The method of claim 1, further comprising: generating a second
Web Service signature, wherein the second Web Service signature
comprises information indicative of the catalog; and sending the
second Web Service signature to an application, wherein the Web
Service signature is received from the application.
3. The method of claim 1, further comprising: receiving a second
Web Service signature requesting access to catalog information,
wherein the second Web Service signature comprises second
information indicative of a second sales context, wherein the first
Web Service signature is received from a first sales channel module
in a first sales channel, and wherein the second Web Service
signature is received from a second sales channel module in a
second sales channel; and dynamically generating a second catalog,
based upon the second sales context.
4. The method of claim 1, wherein the catalog comprises a plurality
of catalog categories.
5. The method of claim 1, wherein the catalog comprises a plurality
of products.
6. The method of claim 1, wherein the dynamically generating the
catalog comprises applying eligibility and pricing rules to a set
of catalog information.
7. The method of claim 1, further comprising: receiving a second
Web Service signature requesting search information for a
particular catalog; and selecting the search information from the
catalog information, in response to receipt of the second Web
Service signature.
8. The method of claim 1, further comprising: receiving a second
Web Service signature requesting to modify the catalog information;
and modifying the catalog, in response to receipt of the second Web
Service signature.
9. The method of claim 1, further comprising: receiving a second
Web Service signature requesting product information from the
catalog information; and selecting the product information from the
catalog information, in response to receipt of the second Web
Service signature.
10. A computer readable storage medium storing program instructions
executable to: detect receipt of a Web Service signature requesting
access to catalog information, wherein the Web Service signature
comprises information indicative of a sales context; and
dynamically generate a catalog, based upon the sales context
specified in the Web Service signature.
11. The computer readable storage medium of claim 100, wherein the
program instructions are further executable to: generate a second
Web Service signature, wherein the second Web Service signature
comprises information indicative of the catalog; and send the
second Web Service signature to an application, wherein the Web
Service signature is received from the application.
12. The computer readable storage medium of claim 10, wherein the
program instructions are further executable to: detect receipt of a
second Web Service signature requesting access to catalog
information, wherein the second Web Service signature comprises
second information indicative of a second sales context, wherein
the first Web Service signature is received from a first sales
channel module in a first sales channel, and wherein the second Web
Service signature is received from a second sales channel module in
a second sales channel; and dynamically generate a second catalog,
based upon the second sales context.
13. The computer readable storage medium of claim 10, wherein the
catalog comprises a plurality of catalog categories.
14. The computer readable storage medium of claim 10, wherein the
catalog comprises a plurality of products.
15. The computer readable storage medium of claim 10, wherein
dynamically generating the catalog comprises applying eligibility
and pricing rules to a set of catalog information.
16. The computer readable storage medium of claim 10, wherein the
program instructions are further executable to: detect receipt of a
second Web Service signature requesting search information for a
particular catalog; and select the search information from the
catalog information, in response to receipt of the second Web
Service signature.
17. The computer readable storage medium of claim 10, wherein the
program instructions are further executable to: detect receipt of a
second Web Service signature requesting to modify the catalog
information; and modify the catalog, in response to receipt of the
second Web Service signature.
18. The computer readable storage medium of claim 10, wherein the
program instructions are further executable to: detect receipt of a
second Web Service signature requesting product information from
the catalog information; and select the product information from
the catalog information, in response to receipt of the second Web
Service signature.
19. A system comprising: computer readable storage means for
storing catalog information; and catalog generation means for:
receiving a Web Service signature requesting access to the catalog
information, wherein the Web Service signature comprises
information indicative of a sales context; and dynamically
generating a catalog, based upon the sales context.
20. The system of claim 19, wherein the catalog means are further
for: generating a second Web Service signature, wherein the second
Web Service signature comprises information indicative of the
catalog; and sending the second Web Service signature to an
application, wherein the Web Service signature is received from the
application.
Description
RELATED APPLICATIONS
[0001] This application claims the benefit, under 35 U.S.C. .sctn.
119 (e), of U.S. Provisional Application No. 60/981,446, filed Oct.
19, 2007, entitled "Web Service Architecture for Order Management
System," and naming Muralidhara Varmaraja, Meng Feng, Hang Lu,
Ashish Singhal, Eugene Chikovani, Mark D. Lewis, Ying Wang, Re Lai,
Robert A. M. Seaman, II, Jonathan Fan, and Yi Chang as inventors.
The above-referenced application is hereby incorporated by
reference herein in its entirety as if completely and fully set
forth herein.
FIELD OF THE INVENTION
[0002] This invention relates to order management systems and, more
particularly, to providing product selection and dynamic catalog
generation as a service.
BACKGROUND
[0003] Order management systems provide a framework for providing
functionality such as that needed to define a sales context, manage
products and catalogs, generate pricing information, and analyze
customer behavior. However, such order management functionality is
typically integrated with the interface for accessing that
functionality. Accordingly, the order management functionality is
typically only accessible via static, pre-specified interfaces. For
example, many order management systems provide a single interface
that provides limited, if any, customizability, which may in turn
limit a client's ability to control the look and feel of the user
interface that client presents to customers.
[0004] Furthermore, the standard interfaces may not be available
for use with certain sales channels, effectively rendering the
underlying order management system functionality inaccessible to
those sales channels. This can in turn require that the underlying
order management system functionality be duplicated for each sales
channel. In such a system, each instance of the underlying
functionality must be updated whenever a change (e.g., to the
products within a product line or to product pricing) is made.
Since multiple different systems must be updated in order to
propagate each change, there is an increased likelihood that there
will be inconsistencies among the sales channels (e.g., due to the
change not be entered at the same time or in the same manner in
each system).
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] A more complete understanding of the present invention may
be acquired by referring to the following description and the
accompanying drawings, in which like reference numbers indicate
like features.
[0006] FIG. 1 is a block diagram of a system that includes an order
management system that provides order management functionality as a
Web Service, according to one embodiment of the present
invention.
[0007] FIG. 2 is a block diagram of the Web Services interface
between a sales channel module and an order management system,
according to one embodiment of the present invention.
[0008] FIG. 3 is a block diagram of an order management system that
provides a Web Services interface to catalog management
functionality, according to one embodiment of the present
invention.
[0009] FIG. 4 is a flowchart of a method of providing catalog
management functionality as a Web Service, according to one
embodiment of the present invention.
[0010] FIG. 5 is a block diagram of a computing device that
illustrates how an order management system that provides a Web
Services interface can be implemented in software, according to one
embodiment of the present invention.
[0011] While the invention is susceptible to various modifications
and alternative forms, specific embodiments of the invention are
provided as examples in the drawings and detailed description. It
should be understood that the drawings and detailed description are
not intended to limit the invention to the particular form
disclosed. Instead, the intention is to cover all modifications,
equivalents and alternatives falling within the spirit and scope of
the invention as defined by the appended claims.
DETAILED DESCRIPTION
System Overview
[0012] FIG. 1 is a block diagram of a system that includes an order
management system that provides various order management functions
as Web Services. As shown, the system includes several computing
devices 5(1), 5(2), 5(3), 5(4), and 5(5). Each computing device can
include one or more servers, personal computers, cell phones,
laptop computers, personal digital assistants, or other computing
devices that are capable of implementing a sales channel module or
order management system in hardware and/or software.
[0013] Computing device 5(5) implements an order management system
50. Order management system 50 provides functionality that can be
used to, for example, define a sales context, manage product and/or
catalog information, proving pricing information, and/or analyze
customer behavior. Order management system 50 can also provide
functionality to capture orders, orchestrate orders, and/or fulfill
customer orders. While FIG. 1 shows order management system 50
being implemented on a single computing device 5(5), it is noted
that in many implementations, the functionality of order management
system 50 may be distributed among several such computing
devices.
[0014] Order management system 50 can provide access to, generate,
and/or maintain order management information 60. Order management
information 60 can include pricing information, rules information
(e.g., for use in determining pricing, product configurations,
product eligibility, and the like), catalog and product
information, and other appropriate information.
[0015] Computing devices 5(1), 5(2), 5(3), and 5(4) each implement
a respective sales channel module. These sales channel modules are
used to facilitate respective sales channels. In particular, call
center sales channel module 10(1), which is implemented on
computing device 5(1), is used to facilitate a call center sales
channel. In one embodiment, call center sales channel module 10(1)
provides a user interface to a customer service agent working in a
call center, allowing the customer service agent to use
functionality provided by order management system 50.
[0016] Similarly, computing device 5(2) implements a partner sales
channel module 10(2). Partner sales channel module 10(2) can
facilitate sales (via order management system 50) of one client's
products and/or services by another client, which is referred to as
a partner.
[0017] Computing device 5(3) implements a Web sales channel module
10(3). Web sales channel module 10(3) facilitates orders over the
Internet. For example, Web sales channel module 10(3) can include a
Web server that allows users to browse Web pages. Web sales channel
module 10(3) can interact with order management system 50 in order
to obtain information to display in the Web pages being supplied to
users.
[0018] Computing device 5(4) implements a retail sales channel
module 10(4). Retail sales channel module 10(4) can operate in a
retail environment. Retail sales channel module 10(4) can provide
sales clerks and/or customers with access to the functionality
provided by order management system 50 in order to facilitate sales
and ordering in the retail environment.
[0019] Computing devices 5(1)-5(5) are coupled by a network 15.
Network 15 can include one or more Local Area Networks (LANs)
and/or Wide Area Networks (WANs) such as the Internet. Network 15
can be implemented using various wireless links, coaxial cables,
fiber optic cables, and the like. It is noted that in alternative
embodiments, instead of being implemented on separate computing
devices from each other and from order management system 50, one or
more sales channel modules can be implemented on the same computing
device as each other or on the same computing device as all or part
of order management system 50.
[0020] Each sales channel module 10(1), 10(2), 10(3), and 10(4) can
thus interact with order management system 50 in order to
facilitate sales and orders via a particular sales channel. Sales
channel modules 10(1), 10(2), 10(3), and 10(4) can be implemented
in a variety of different ways, using various different types of
applications. For example, call center sales channel module 10(1)
can be a mainframe order entry system, while partner sales channel
module 10(2) can be implemented using an application such as
Seibel.TM. Business Applications software, available from Oracle
Corporation of Redwood Shores, Calif., or Microsoft.TM. Sharepoint
Server, available from Microsoft Corporation of Redmond, Wash. In
general, each sales channel module may be implemented differently
than each other sales channel module.
[0021] Each sales channel module can also maintain sales context
information, such as sales context information 18 maintained by Web
sales channel module 10(3). Such sales context information can
include shopping cart information (e.g., for a Web sales channel),
customer identifiers or other information (e.g., such as a prior
order history) associated with a customer, and the like.
[0022] As briefly noted above, order management system 50 provides
order management functionality as a Web Service. A Web Service is a
discrete piece of business logic that is accessible via Internet
protocols. Such a Web Service can be specified using Web Services
Description Language (WSDL). In particular, WSDL is a format, based
in eXtensible Markup Language (XML), for defining a Web Service
interface. WSDL can be used to specify the endpoints, location,
protocol binding, operations, parameters, and/or data types
associated with a Web Service.
[0023] The organization that creates order management system 50 can
generate a WSDL document (e.g., an XML document complying with
WSDL) that describes the Web Service(s) provided by order
management system 50. For each Web Service, the WSDL document can
describe the operations provided by the Web Service, the input and
output message structures for each operation, and the mechanism
used to contact the Web Service.
[0024] Web Services are accessed using an XML-based transport
protocol such as Service Oriented Architecture Protocol (SOAP). In
particular, Web Service signatures (which are messages that comply
with a particular Web Service's WSDL file) can be transported via
SOAP.
[0025] Using Web Services to access order management functionality
allows the order management functionality to be decoupled from the
sales channel module accessing the order management functionality.
Accordingly, each different sales channel module can be implemented
differently (and independently), so long as the resulting sales
channel modules are able to request Web Services. Accordingly, a
given sales channel module can be implemented whatever technology
best suits the needs of a particular sales channel. Furthermore,
the technology used to implement a particular sales channel module
can be modified without necessitating modifications to the
underlying order management system. Similarly, the particular
software modules used to implement the order management system's
functionality can be modified without necessitating changes in the
sales channel modules that access that functionality.
[0026] Furthermore, each sales channel module 10(1)-10(4) can
access the same order management functionality by accessing the
order management functionality as a Web Service. Accordingly, the
same underlying business logic, workflows (e.g., formed by linking
two or more business logic components together to perform a
particular business task), and order management information can be
used to support multiple sales channels. This allows a consistent
user experience (in terms of available products, pricing,
discounting, and the like) to be provided across multiple different
sales channels. Furthermore, whenever changes need to be made
(e.g., to reflect new products, new pricing, and the like), the
changes can be made just once to the underlying order management
system 50. The updated order management system 50 will then return
the updated service or information to each of the different sales
channels.
[0027] FIG. 2 is a block diagram of the Web Services interface
between a sales channel module and an order management system. In
this example, a sales channel module 10 (e.g., one of sales channel
modules 10(1)-10(4) of FIG. 1) is coupled to communicate with an
order management system 50. In one embodiment, sales channel module
10 is implemented in a container or application server (e.g., a
Java 2 Platform, Enterprise Edition (J2EE).TM. container), and
order management system 50 can be implemented in a different
container or application server.
[0028] Sales channel module 10 includes a presentation layer 110
(e.g., used to provide a user interface), a business process layer
120 (e.g., used to implement workflows or business services), and
an integration layer 130. Integration layer 130 includes a Web
Service requester agent that is configured to request Web Services
provided by order management system 50 by sending Web Service
signatures via SOAP (or any other appropriate protocol).
[0029] Order management system 50 includes a Web Service module
150, which includes a Web service provider agent that is configured
to receive Web Service signatures sent by sales channel module 10
and to send responsive Web Service signatures back to sales channel
module 10. Web Service module 150 can also transform Web Service
signatures into property sets that can be processed by workflow
and/or business services 170. Similarly, Web Service module 150 can
transform property sets generated by workflow and/or business
services 170 into Web Service signatures and then send those Web
Service signatures to the appropriate sales channel module.
[0030] Workflow and/or business services 170 include various
modules for providing workflows and business services. For example,
such modules can include a module that provides a pricing workflow,
a module that provides product configuration functionality, a
module that provides access to catalog and product information, and
the like. Workflow and/or business services 170 can operate on
property sets provided by Web Service module 150, modify and/or
access order management information (e.g., order management
information 60 of FIG. 1), and return results (again in the form of
property sets) to Web Service module 150.
Accessing Catalog Functionality as a Web Service
[0031] FIG. 3 is a block diagram of an order management system that
provides a Web Services interface to catalog management
functionality. As shown, order management system 50 communicates
with one or more sales channel modules 10 (e.g., one of sales
channel modules 10(1)-10(4) of FIG. 1) via a Web Services
interface. Order management system 50 includes one or more
workflows and/or business services 170, which in turn include a
catalog module 300. Catalog module 300 includes a product
information module 310, a dynamic catalog generation module 320,
and a search module 330. Catalog module 300 maintains catalog
information 350 and also uses catalog information 350 to respond to
requests.
[0032] Sales channel module 10 can request access to catalog
functionality provided by order management system 50 as a service.
In particular, sales channel module 10 can send a Web Service
signature to order management system 50 in order to invoke a
particular catalog service. The Web Service signature can
optionally include information identifying a sales context (e.g.,
such information can include a customer or account identifier,
information about the status and/or location of a customer,
shopping cart information, and the like) and/or a search string.
The particular format of the sales context and/or search string can
be configured by the user that operates sales channel module
10.
[0033] In response to receiving a Web Service signature requesting
to invoke catalog functionality, order management system 50 can
provide information indicating the request to catalog module 300.
Order management system 50 can also provide any information that
was provided as part of the Web Service signature to the catalog
module 300 (e.g., such information can be provided in the form of a
property set generated by a Web Services module like the one shown
in FIG. 2). Catalog module 300 can then generate a response to the
request, based upon catalog information 350 and any information
that was provided as part of the Web Service signature.
[0034] Catalog information 350 includes information identifying one
or more catalogs (e.g., in terms of type, description, start and/or
end date, identifier, name, and the like). Each catalog is a
collection of products that are arranged in a logical hierarchy of
categories. Accordingly, for each identified catalog, catalog
information 350 can include information identifying one or more
catalog categories (e.g., each such category can include a group of
related products) within that catalog. The catalog category
information can include information identifying the catalog(s) in
which each category is included, the name of each category, an
extended text description of each category, and the like. In one
embodiment, some categories can be sub-categories of other
categories, and thus each category can also identify a parent
category, if applicable.
[0035] Similarly, for each catalog, catalog information 350
includes information identifying one or more products included in
that catalog. Each item of product information can identify the
category or categories in which that product is included, the
catalog(s) in which that product is included, effective dates,
eligibility information (e.g., used to determine whether the
product is available to certain end customers), pricing
information, product descriptions, and the like.
[0036] Product information module 310 is configured to access
product information stored as part of catalog information 350. For
example, product information module 310 can be invoked to provide
product details (e.g., by retrieving basic product information such
as a product name, description, price, and the like), provide a
product attribute domain (e.g., by returning a list of all possible
values for a particular product attribute), and/or to provide
product children information (e.g., by returning details of all
entities, such as product literature, product features, product
reviews, and the like, that are associated with a given product).
Each of these functions can be accessed as a service by sending an
appropriate Web Service signature to order management system 50. In
response to such a Web Service signature being received, product
information module 310 will access catalog information 350 and
generate an appropriate result, which can then be returned to the
requester in a Web Service signature.
[0037] Dynamic catalog generation module 320 is configured to
dynamically generate a catalog in response to a request for a
catalog. The dynamic catalog generation module 320 can dynamically
generate the catalog based upon information, such as sales context
information and/or a search string, received along with a request
for a catalog. Such information can be received as part of a Web
Service signature sent to order management system 50 by a sales
channel module.
[0038] Examples of types of requests for a catalog that would cause
dynamic catalog generation module 320 to dynamically generate a
catalog include a request for a list of catalogs, a request for a
list of catalog categories, a request for a list of catalog
category products, and a request to publish a catalog. These
requests can be generated by a sales channel module in order to
provide a user interface to the catalog. For example, to generate a
top-level view of available catalogs, the sales channel module can
invoke a request for a list of catalogs. In response to receiving
the list of catalogs from the order management system, the sales
channel module can display that list to the user. If the user
selects one of the catalogs from the displayed list of catalogs,
the sales channel module can invoke a request for a list of catalog
categories within that catalog. Based upon the response to this
request, the sales channel module can display a list of categories
to the user, in response to the user's selection of a particular
catalog. If in turn the user selects a particular category from the
displayed list of categories, the sales channel module can request
a list of products within the selected category.
[0039] In response to receiving a request for a catalog, dynamic
catalog generation module 320 retrieves the appropriate catalog
items (e.g., catalog names, catalog category names, product names,
and the like) from catalog information 350. If the request also
specifies a sales context, dynamic catalog generation module 320
can invoke another workflow and/or business service that will
select the subset of those catalog items that would otherwise
satisfy the request. For example, if a request for a set of
products within a particular catalog or catalog category is
received, dynamic catalog generation module 320 can select the set
of appropriate products from catalog information 350, based upon
the identity of the catalog or catalog categories that includes the
products. If the request also specifies a sales context (e.g., by
specifying characteristics of the user viewing the catalog via the
sales channel module), dynamic catalog generation module 320 can
invoke an eligibility workflow, which will then identify the subset
of the set of products (already identified by dynamic catalog
generation module 320) that the user is eligible to view. In
general, if sales context is provided with a request for a catalog,
dynamic catalog generation module 320 can invoke other policy
workflows and/or business services that can narrow the list of
catalog items that should be returned in response to the request,
based upon the sales context provided in the request.
[0040] By dynamically generating the catalogs in response to
individual requests, dynamic catalog generation module 320 will
always return an up-to-date version of the catalog items in the
requested catalogs. In contrast, if catalogs were static,
out-of-date catalog items would likely be returned in response to
requests. Furthermore, since dynamic catalog generation module
320's functionality can be invoked as a Web Service, multiple
different sales channels can access the same catalog information.
Accordingly, these different sales channels can provide a
consistent user experience by virtue of accessing the same catalog
information. Furthermore, as the underlying catalog information 350
is updated, the updates will be automatically propagated to each
sales channel the next time that the sale channel requests access
to the updated information.
[0041] Search module 310 is configured to search catalog
information 350 (or a particular subset of catalog information 350,
if a catalog or catalog category is specified in the request) for
particular catalogs, catalog categories, and/or products based upon
search criteria. Search module 330 can also provide various search
information, such as the list of current searchable classes,
product families, and the like, within a given catalog or catalog
category, as well as a list of attributes available to be searched
within a given catalog or catalog category.
[0042] Various modules within catalog module 300, such as product
information module 310, dynamic catalog generation module 320, and
search module 330, can dynamically generate catalog information
(e.g., a catalog, product information, search information, and the
like) in response to order management system 50 receiving a Web
Service signature from sales channel module 10. The generation of
the catalog information can be dependent upon sales context
information and/or search strings received as part of the Web
Service signature, as described above.
[0043] The following table shows an example of functionality that
can be provided by as services by catalog module 300, in one
embodiment:
TABLE-US-00001 Service Description Get Catalogs Retrieve a list of
catalogs for a given user and other contextual parameters Get
Catalog Retrieve a list of categories Categories Get Catalog
Retrieve a list of products for given catalog, Category Products
category and other contextual parameters Get Product Retrieve basic
product information Details Get Search Retrieve a list of fields or
attributes available Parameters for a search option. Example: 100
`dpm` and `200 dpm` for the Printer `Speed` option Get Search
Retrieve the search options for a specific product Parameter
Options family or class. Ex: `Printer Speed`, `Color`, and the
like. for `Printer` Class Execute search Execute search based on
the given search criteria Get Product Retrieve all the possible
values for a given product Attribute Domain attribute Get Catalog
In Full Get full details for a catalog Get Product Retrieve details
of associated product entities such Information as `Product
Literature`, `Features`, and the like. Publish Catalog Used to
syndicate catalog to external parties (e.g., an XML file containing
the full catalog contents can be returned) Get Related Retrieve all
the related Promotions for a given Promotions product
[0044] The Web Service signatures used to invoke catalog module
350's functionality can also specify particular information that is
needed and/or not needed by the sales channel module invoking the
service. Thus, certain requests can specify that only some of the
available information in a particular catalog item is needed.
Accordingly, catalog module 300 can be configured to exclude the
information that is not needed when dynamically generating catalog
information in response to such a request.
[0045] In some embodiments, multiple requests for catalog
information can be received from the same sales channel module as
part of the same user experience (e.g., if a sales channel module
is generating a user interface and allowing a user to navigate from
a list of catalogs to a list of products within a catalog, that
sales channel module may need to invoke several different catalog
functions). In such situations, each Web Service signature sent by
the sales channel module can contain the same sales context.
Alternatively, the first Web Service signature can indicate that
the order management system 50 should save the included sales
context. Subsequent Web Service signatures can indicate that the
order management system 50 should use the saved sales context (in
some embodiments, this can be done as an alternative to including
the sales context in the subsequent Web Service signatures). It is
noted that such arrangements allow the sales channel module to
maintain its sales context (e.g., a shopping cart and the like)
externally to the sales channel module.
[0046] In some embodiments, catalog module 300 may also allow an
administrator to manage (e.g., by viewing existing catalog
information, deleting existing catalog information, creating new
catalog information, and/or modifying existing catalog information)
catalog information 350 via a Web Service. For example, an
administrator can interact with a sales channel module, causing the
sales channel module to send a Web Service signature containing a
request to modifying catalog information to order management system
50. This Web Service signature can also include information, such
as an administrator name and password, that indicates that the
requester has permission to manage catalog information 350.
[0047] FIG. 4 is a flowchart of a method of providing catalog
management functionality as a Web Service. The method begins at
400, when a Web Services signature requesting catalog information
is received. The received Web Services signature can request
particular catalog information by specifying a particular catalog,
catalog category, product, or the like. Alternatively, the received
Web Services signature can request particular catalog information
by specifying a search query.
[0048] Based upon the request, an appropriate set of catalog
information is selected, as shown at 410. For example, if the
request specifies a particular catalog, a set of products and/or
catalog categories currently in that catalog can be selected.
Similarly, if the request specifies a particular catalog category,
a set of products included in that catalog category can be
selected. If the request specifies a search query, a set of
products satisfying that search query can be selected.
[0049] If the Web Services signature contains sales context
information (or refers to saved sales context information) and
invokes a service that can use that sales context, the sales
context information will be used to satisfy the request, as
indicated at 420. In this case, various rules and/or policies can
be applied to the selected set of catalog information, based upon
the sales context, in order to select a subset of the catalog
information, as shown at 430. The catalog information selected at
410 and/or 430 can then be returned to the requester in a Web
Service signature, as shown at 440.
[0050] FIG. 5 is a block diagram of a computing device that
illustrates how an order management system that provides product
selection and dynamic catalog generation functionality as a Web
Services interface can be implemented in software. FIG. 5 is a
block diagram of a computing device 5 (e.g., one of computing
devices 5(1)-5(5) of FIG. 1) that implements all or part of an
order management system 50 that includes catalog module 300. While
the illustrated example shows a single module executing on a single
computing device, it is noted that in alternative embodiments, the
functionality included within order management system 50 can be
subdivided among multiple modules, each of which may be implemented
on a separate computing device.
[0051] Computing device 5 can be a personal computer, network
appliance, server, personal digital assistant, mobile phone,
storage controller (e.g., an array controller, tape drive
controller, or hard drive controller), or the like. As illustrated,
computing device 5 includes one or more processors 502 (e.g.,
microprocessors, Programmable Logic Devices (PLDs), or Application
Specific Integrated Circuits (ASICs)) configured to execute program
instructions stored in memory 504. Memory 504 can include various
types of RAM (Random Access Memory), Read Only Memory (ROM), Flash
memory, Micro Electro-Mechanical Systems (MEMS) memory, magnetic
core memory, and the like. Memory 504 can include both volatile and
non-volatile memory. Computing device 5 also includes one or more
interfaces 506. Processor 502, interface 506, and memory 504 are
coupled to send and receive data and control signals by a bus or
other interconnect.
[0052] Interface 506 can include a network interface to various
networks and/or interfaces to various peripheral buses. For
example, interface 506 can include a network interface via which
order management system 50 sends and receives Web Service
signatures. Interface 506 can also include an interface to one or
more storage devices. For example, order management system 50 can
access catalog information 350 stored on such a storage device.
[0053] In this example, program instructions and data executable to
implement all or part of order management system 50 are stored in
various computer readable storage media such as memory 504. In some
embodiments, such software is stored on a computer readable storage
medium such as a Compact Disc (CD), Digital Versatile Disc (DVD),
hard disk, optical disk, tape device, floppy disk, and the like).
In order to be executed by processor 502, the instructions and data
can be loaded into memory 504 from the other computer readable
storage medium. The instructions and/or data can also be
transferred to computing device 5 for storage in memory 504 via a
network such as the Internet or upon a carrier medium.
[0054] The flowcharts provided here are provided as examples, and
it is noted that other embodiments can include different operations
instead of and/or in addition to those shown in the flowcharts
presented herein.
[0055] Although the present invention has been described in
connection with several embodiments, the invention is not intended
to be limited to the specific forms set forth herein. On the
contrary, it is intended to cover such alternatives, modifications,
and equivalents as can be reasonably included within the scope of
the invention as defined by the appended claims.
* * * * *