Patent Application
20130346241
An e-commerce marketplace provides a central point of distribution for a vendor to sell goods and services and for consumers to purchase the goods and services. The marketplace often has a catalog of products for distribution to consumers. The marketplace is beneficial to vendors who may not have the means to distribute their products independently. A vendor may submit a product to the marketplace for distribution through the marketplace. Prior to the marketplace listing the vendor's product, the marketplace may validate the product and/or the vendor to ensure that the product is reliable, performs satisfactorily, and meets certain requirements. However, the process of validating different types of products from a central point of sale may be a technical challenge when the validation process consumes significant time and expense.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
An e-commerce system utilizes several marketplaces to advertise and distribute products. Each marketplace has a catalog listing the products offered for distribution by the marketplace. Each marketplace may receive products from vendors to list onto the marketplace's catalog. The products submitted from the vendors are validated prior to being listed in a marketplace's catalog.
A marketplace receives the product submissions and may utilize a validation engine to formulate a distributed approval workflow to validate a product. The distributed approval workflow may be performed by several distinct approval engines that may execute in one or more servers. Each approval engine executes a specific task. The distributed approval workflow validates that the product performs as advertised in a reliable and intended manner. The validation engine monitors the progression of each approval engine involved in the distributed approval workflow until completion.
These and other features and advantages will be apparent from a reading of the following detailed description and a review of the associated drawings. It is to be understood that both the foregoing general description and the following detailed description are explanatory only and are not restrictive of aspects as claimed.
Various embodiments pertain to an infrastructure supporting a distributed approval workflow. The distributed approval workflow may be used to validate products and/or content associated therewith. In one or more embodiments, once the products are validated, the products may be distributed in an e-commerce system that may include several marketplaces. Each marketplace may be configured to distribute a particular type of product.
The marketplace includes a validation engine that receives product submissions and which initiates and monitors a validation process. The validation process may differ for different types of products. The validation process is distributed into a distributed approval workflow that may be performed by one or more approval engines. The distributed approval workflow includes one or more approval workflows that may be performed to validate that the product conforms in accordance to a prescribed specification.
The validation engine manages the approval workflows performed by each approval engine until completion. Upon completion that did not result in a failure, the product may be placed in a marketplace's catalog. In the event the validation fails, a report may be returned to the vendor and the product is not placed in the marketplace's catalog.
In one or more embodiments, the marketplaces may be configured to distribute software applications. However, the technology described herein is not constrained to any particular type of product and may be applied to any type of digital data, such as without limitation, digital video files, digital audio files, text files, images, and any combination thereof.
Attention now turns to a discussion of an exemplary e-commerce system. Turning to
One or more users 106, through a computing device, may initiate a request for a product 114 to be distributed to a user 106. One or more vendors 108, through a computing device, may transmit a product submission request 116 to a marketplace 102 for the vendor's product to be distributed from that marketplace 102. The communications framework 104 facilitates communications between the marketplaces 102, the users 106, and the vendors 108 and is described in more detail below with respect to
Although the system 100 shown in
An approval engine 205 may validate an application for compliance with certain prescribed specifications, validate that the application performs as advertised, validate that the application does not interfere with other components, validate that the application executes reliably, and so forth, all considered herein as validating the application for conformance with a prescribed specification. The file server 206 may be used to store the submission packages 208 so that the contents of the submission packages 208 may be accessed by the various servers.
In one or more embodiments, a product submission request 116 may take the form of a submission package 208 that may contain a vendor profile 210, one or more application binary files 212, application assets 214, and/or application metadata 216. The vendor profile 210 may include information about the vendor, such as name, address, type of business, and so forth. The application binary files 212 include the application's executable instructions. The application assets 214 may include icons, web pages, screenshots, logos, documents, and other types of data that may be used to advertise an application in a marketplace 102. The application metadata 216 may include the application title, description, listing of hardware and/or software components needed to run the application, and so forth. It should be noted that the embodiments are not constrained to this particular configuration of a submission package 208 and that a submission package 208 may have more or less contents than what is shown in
The submission validation server 202 may include a validation engine 203 and one or more approval queues 230A-230N (collectively, ‘230’). The validation engine 203 receives a submission package 208 (block 218) and may perform some preliminary checks on the contents of the submission package 208 (block 220). For example, the validation engine 203 may perform a virus scan to detect malware, check that the submission package 208 contains all the contents needed to comply with the submission requirements, check that the contents of the submission package 208 does not contain any offensive material, and so forth.
When the contents of the submission package 208 passes the preliminary checks, the submission package 208 may be stored (block 222). In one or more embodiments, a file server 206 may be utilized to store the submission package 208 in a storage location that may be accessible by the various components within the marketplace 102. In addition, the validation engine 203 may store metadata associated with the submission package 208 into an approval queue 230 (block 224).
The validation engine 203 may utilize one or more approval queues 230 to distribute the distributed approval workflow to one or more approval servers 204. In one or more embodiments, there may be an association between a particular approval queue and a particular approval server 204. For example, the approval servers 204 may be categorized by application types. Examples of application types may be mobile phone applications, video game applications, device drivers, email applications, and so forth. There may be a dedicated approval server 204 associated with validating mobile phone applications, a dedicated approval server 204 associated with validating video game applications, a dedicated approval server 204 associated with validating device drivers that run with a particular operating system, and so forth. In other embodiments, the approval servers 204 may not be specific to a particular type of application. The validation engine 203 may utilize any one of the approval servers 204 to validate an application in accordance with a load balancing policy or other policy.
An entry in an approval queue 230 contains metadata associated with a particular submission package 208. The metadata may include the location of the submission package, additional hardware or software resources needed to execute the application (e.g., GPS device, accelerometer, etc.), and so forth. An approval engine 205 polls a corresponding approval queue 230 for a submission package 208 (block 232). Alternatively, the validation engine 203 may push the approval request to the approval engine 205 (block 232). The approval engine 205 then performs the needed validation for the application (block 234). The approval engine 205 interacts with the validation engine 203 by providing the validation engine 203 updates on the status of the validation process (block 236).
The validation may result in success, failure, or interruption. A successful validation allows the application to be listed in a catalog in the marketplace 140. A failed validation may result in an error response returned to the vendor indicating the reasons why the submission may not be listed in the marketplace 140. In some instances, the validation engine 203 may interrupt and halt the approval workflow being performed by an approval engine 205. Such an interruption may occur when an updated version of the application is received after the approval workflow has commenced on a prior version.
The submission validation server 202, the approval servers 204, and the file server 206 may be connected through a communications framework 238, such as a network, bus, channel, and so forth, which may be operated in accordance with any communications protocol. The communications framework 238 facilitates communications between the different servers in the marketplace 140. In one or more embodiments, the submission validation server 202 and the approval servers 204 may be operated by the same entity (e.g., company, group, etc.). In other embodiments, the submission validation server 202 may be operated by one entity and one or more approval servers 204 may be operated by a different entity than the submission validation server 202.
Although the marketplace 140 as shown in
In the second embodiment, a submission validation server 242 includes the validation engine 203, the approval engines 205, and the approval queues 230. The validation engine 203 receives a submission package 208 (block 218) and may perform some preliminary checks on the contents of the submission package 208 (block 220).
When the contents of the submission package 208 passes the preliminary checks, the submission package 208 may be stored in a storage unit 244 (block 222). An entry for the submission package 208 may be placed in an approval queue 230 (block 224). The approval engine 205 may poll a corresponding approval queue 230 for a submission package 208 (block 232). Alternatively, the validation engine 203 may push the approval request to the approval engine 205 (block 232). The approval engine 205 then performs the needed validation for the application (block 234). The approval engine 205 interacts with the validation engine 203 by providing the validation engine 203 updates on the status of the validation process (block 236).
Attention now turns to operations for the embodiments which may be further described with reference to various exemplary methods. It may be appreciated that the representative methods do not necessarily have to be executed in the order presented, or in any particular order, unless otherwise indicated. Moreover, various activities described with respect to the methods can be executed in serial or parallel fashion, or any combination of serial and parallel operations. The methods can be implemented using one or more hardware elements and/or software elements of the described embodiments or alternative embodiments as desired for a given set of design and performance constraints. For example, the methods may be implemented as logic (e.g., computer program instructions) for execution by a logic device (e.g., a general-purpose or specific-purpose computer).
The validation engine 203 may utilize one or more approval queues 230 to notify a specific approval engine 205 of a submission package 208 requiring validation. There may be one or more approval queues 230 associated with a particular approval engine 205. For example, a mobile phone application may need to be validated with respect to certain cellular radio technical specifications in addition to certain operating system technical specifications. The validation for this application may require validation by two separate approval engines 205. There may be a first approval workflow executed by one approval engine 205 that validates the application with respect to cellular radio requirements and a second approval workflow executed by a second approval engine 205 that validates the application with respect to certain operating system requirements. The application is validated upon successful completion of both approval workflows.
Each approval engine 205 may obtain a submission package 208 that needs to be validated by that approval engine 205 (Obtains Submission Package Step 1). The approval engine 205 may retrieve the contents of the submission package from the file server 206 using metadata from the validation engine 203 (Retrieves Contents of Submission Packages Step 2). The approval engine 205 performs the approval workflow during which time the approval engine 205 provides updates to the validation engine 203 (Performs Approval Workflow Step 3). The updates may include data pertaining to the current state of the approval workflow processing, such as, an estimated time of completion of the approval workflow, errors occurring during execution of the approval workflow, and so forth (Provides Updates Step 4).
The validation engine 203 sends a response that replies to the update (Response Step 5). The response may include an alteration to the estimated completion time or a confirmation of the estimated completion time. The updates are provided by the approval engine 205 to the validation engine 203 at periodic intervals and the validation engine 203 keeps track of them and responds accordingly. A last update may include the outcome of the approval workflow which may be success or failure.
In one or more embodiments, the validation engine 203 may be implemented as a process that may utilize one or more independent threads of execution to perform a subset of the validation engine's tasks. For example, the validation engine 203 may utilize one thread to receive submission requests from users, and another thread to receive the updates from the approval engines. Likewise, each approval engine 205 may utilize one or more independent threads of execution to perform the approval engine's tasks. For example, an approval engine 205 may utilize one thread to execute the approval workflow and another thread to provide the updates to the validation engine 203. However, the embodiments are not constrained to any particular implementation of the validation engine 203 and the approval engines 205. The validation engine 203 and the approval engines 205 may be executed in a serial manner or executed in parallel. The embodiments are not constrained in this manner.
The validation engine 203 may create one or more threads that process submission requests (block 402) and one or more threads that monitor pending approval workflows (block 416). In this manner, the validation engine 203 may process multiple approval workflows concurrently.
The validation engine 203 may perform some preliminary validation checks on the submission package (block 404). If the preliminary validation checks fail (block 406—no), then the validation engine 203 may return an error report back to the vendor indicating the errors (block 408).
In the event a submission package is for a product that is currently being approved (block 410—yes), the validation engine 203 may interrupt the pending approval workflow and initiate processing for the current submission (block 412). If the submission package is not related to a previous submission (block 410—no), the submission package is stored in the file server and metadata associated with the submission package is placed into an appropriate approval queue (block 414).
Referring to
Otherwise, if the update is not a completion status (block 504—no), then the update may indicate an estimated time of completion and status (block 508). The validation engine 203 may confirm the estimated time of completion by transmitting a completion message to the approval engine 205 (block 508). The validation engine 203 may also alter the estimated time of completion which the validation engine 203 transmits to the approval engine 205 (block 508).
The validation engine 203 keeps track of the estimated time of completion of each approval workflow. In the event the completion time has lapsed and the validation engine 203 has not received an update from an approval engine 205, the validation engine 203 may issue an alert (block 512). The alert is used to indicate a problem with the approval engine 205. For example, the approval engine 205 may be offline or has encountered a failure that prevents the approval engine 205 from completing the approval workflow.
An approval engine 205 may be configured to execute the approval workflows that are associated with certain types of applications. The approval engine 205 may be equipped with special resources needed to perform the approval workflow for a particular category of applications that may not be available to other approval engine 205. The approval workflows are a sequence of tasks that may be implemented as a sequence of executable instructions.
An approval engine 205 may poll the validation engine 203 for an entry in the approval queue 230 associated with the approval engine 205 (block 602). The entry in the approval queue 230 may include metadata that indicates a location of the submission package 208, special resources needed to execute the approval workflow, and so forth (block 604). The approval engine 205 may utilize the metadata to obtain certain contents of the submission package 208 (block 604). The approval engine 205 may analyze the contents of the submission package 208 and provide the validation engine 203 with a transmission message indicating, at least, an estimated time of completion for the approval workflow (block 604).
The approval engine 205 may receive a confirmation from the validation engine 203 either confirming the estimated time of completion, or altering the estimated time of completion to a new time (block 606). The validation engine 203 may also inform the approval engine 205 that the approval engine 205 does not have to report back, allow the approval engine 205 assume the completion time, or cancel the approval process (block 606). The approval engine 205 may then execute the approval workflow while periodically submitting updates to the validation engine 203 (block 608). The approval engine 205 may execute the approval workflow to completion and the completion status is returned to the validation engine 203 (block 610). The completion status may indicate that the approval workflow performed successfully and may include messages and non-critical warnings thereby validating the product for distribution in the marketplace. The completion status may also indicate that the approval workflow performed unsuccessfully encountering an error or failure that may be reported back to the validation engine 203.
Attention now turns to a discussion of an exemplary operating environment.
A client device 702 may be embodied as a hardware device, a software module, or as a combination thereof. Examples of such hardware devices may include, but are not limited to, a computer (e.g., server, personal computer, laptop, etc.), a cell phone, a personal digital assistant, or any type of computing device, and the like. A client device 702 may also be embodied as a software module having instructions that execute in a single execution path, multiple concurrent execution paths (e.g., thread, process, etc.), or in any other manner
A server device 706 may be embodied as a hardware device, a software module, or as a combination thereof. Examples of such hardware devices may include, but are not limited to, a computer (e.g., server, personal computer, laptop, etc.), a cell phone, a personal digital assistant, or any type of computing device, and the like. A server device 706 may also be embodied as a software module having instructions that execute in a single execution path, multiple concurrent execution paths (e.g., thread, process, etc.), or in any other manner.
The communications framework 704 facilitates communications between the client devices 702 and the server devices 706. The communications framework 704 may embody any well-known communication techniques, such as techniques suitable for use with packet-switched networks (e.g., public networks such as the Internet, private networks such as enterprise intranet, and so forth), circuit-switched networks (e.g., the public switched telephone network), or a combination of packet-switched networks and circuit-switched networks (with suitable gateways and translators). A client device 702 and a server device 706 may include various types of standard communication elements designed to be interoperable with the communications framework 704, such as one or more communications interfaces, network interfaces, network interface cards, radios, wireless transmitters/receivers, wired and/or wireless communication media, physical connectors, and so forth. Examples of wired communications media may include a wire, cable, metal leads, printed circuit boards, backplanes, switch fabrics, semiconductor material, twisted-pair wire, coaxial cable, fiber optics, a propagated signal, and so forth. Examples of wireless communications media may include acoustic, radio frequency spectrum, infrared, and other wireless media.
Each client device 702 may be coupled to one or more client data store(s) 708 that store information local to the client device 702. Each server device 706 may be coupled to one or more server data store(s) 710 that store information local to the server device 706.
The memory 808 may be any computer-readable storage media that may store executable procedures, applications, and data. The computer-readable media does not pertain to propagated signals, such as modulated data signals transmitted through a carrier wave. It may be any type of memory device (e.g., random access memory, read-only memory, etc.), magnetic storage, volatile storage, non-volatile storage, optical storage, DVD, CD, floppy disk drive, and the like. The memory 808 may also include one or more external storage devices or remotely located storage devices. The memory 808 may contain instructions and data as follows:
The memory 828 may be any computer-readable storage media that may store executable procedures, applications, and data. The computer-readable media does not pertain to propagated signals, such as modulated data signals transmitted through a carrier wave. It may be any type of memory device (e.g., random access memory, read-only memory, etc.), magnetic storage, volatile storage, non-volatile storage, optical storage, DVD, CD, floppy disk drive, and the like. The memory 828 may also include one or more external storage devices or remotely located storage devices. The memory 828 may contain instructions and data as follows:
The memory 848 may be any computer-readable storage media that may store executable procedures, applications, and data. The computer-readable media does not pertain to propagated signals, such as modulated data signals transmitted through a carrier wave. It may be any type of memory device (e.g., random access memory, read-only memory, etc.), magnetic storage, volatile storage, non-volatile storage, optical storage, DVD, CD, floppy disk drive, and the like. The memory 848 may also include one or more external storage devices or remotely located storage devices. The memory 848 may contain instructions and data as follows:
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
Various embodiments may be implemented using hardware elements, software elements, or a combination of both. Examples of hardware elements may include devices, components, processors, microprocessors, circuits, circuit elements, integrated circuits, application specific integrated circuits, programmable logic devices, digital signal processors, field programmable gate arrays, memory units, logic gates and so forth. Examples of software elements may include software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces, instruction sets, computing code, code segments, and any combination thereof. Determining whether an embodiment is implemented using hardware elements and/or software elements may vary in accordance with any number of factors, such as desired computational rate, power levels, bandwidth, computing time, load balance, memory resources, data bus speeds and other design or performance constraints, as desired for a given implementation.
