US20190057116A1 - Techniques for maintaining database compatability - Google Patents
Techniques for maintaining database compatability Download PDFInfo
- Publication number
- US20190057116A1 US20190057116A1 US16/044,040 US201816044040A US2019057116A1 US 20190057116 A1 US20190057116 A1 US 20190057116A1 US 201816044040 A US201816044040 A US 201816044040A US 2019057116 A1 US2019057116 A1 US 2019057116A1
- Authority
- US
- United States
- Prior art keywords
- database
- type
- structural organization
- schema
- application program
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
- G06F16/211—Schema design and management
-
- G06F17/30292—
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
- G06F16/211—Schema design and management
- G06F16/213—Schema design and management with details for schema evolution support
-
- G06F17/30297—
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/08—Auctions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
Definitions
- the present application relates generally to the technical field of database schemas and application program interfaces using such schemas.
- Buyers, sellers, and other business partners are increasingly utilizing electronic trading systems (e.g., electronic marketplaces) to collaborate and to do business with each other. Part of this collaboration may involve, for example, linking operational business processes.
- Business processes may be linked by the exchange of information, in agreed sequences and within agreed timeframes, between buyer and seller applications, and affiliated third-party business service providers.
- APIs Application Program Interfaces
- buyer and seller applications may expose Application Program Interfaces (APIs) which allow applications to make calls (e.g., function calls) to other applications to either request or send information.
- APIs Application Program Interfaces
- the technical challenge of enabling this multitude of applications to exchange information increases.
- the development of applications that are able to access APIs of a large number of other applications becomes increasingly burdensome and technically challenging.
- data schemas or definitions provided by a network-based commerce facility to a third-party may however become outdated when changes occur with a master data schema at a network-based commerce facility. When changes occur with the master data schema, functional problems may arise at the third-party application.
- FIG. 1 is a network diagram depicting a trading system, within which an example embodiment of the present invention may be deployed, having a client-server architecture.
- FIG. 2 is a block diagram illustrating multiple marketplace and payment applications that, in one example embodiment of the present invention, form part of a commerce server system.
- FIG. 3 is a high-level entity-relationship diagram illustrating various tables that may be maintained within databases utilized by the marketplace and payment applications described with reference to FIG. 2 .
- FIG. 4 is a block diagram illustrating further details regarding an example trading system, configured according to one of embodiment of the present invention.
- FIG. 5 is a block diagram illustrating the architecture of an example third-party application, configured according to one embodiment of the present invention, to communicate with a commerce server system that exposes a number of APIs.
- FIG. 6 is a block diagram illustrating the architecture of an API server, according to an example embodiment of the present invention.
- FIG. 7 is a block diagram illustrating structural details of example request and response messages.
- FIG. 8 is flowchart of a method, according to an example embodiment of the invention, of performing version management between a client application and an API.
- FIG. 9 is a block diagram illustrating communication between a commerce server system and a third-party system where client applications on the third-party system use schema definitions.
- FIG. 10 shows example schema definitions of a current database schema provided at a commerce server system.
- FIG. 11 shows example definitions of outdated schema definitions provided at the third-party system.
- FIG. 12 shows an example dictionary module to track changes in schema definitions at a server system.
- FIG. 13 shows a flowchart of an example method, in accordance with an embodiment of the invention, for processing a request from a third-party application having outdated schema definitions.
- FIG. 14 is a block diagram representation of a machine, in the example form of a computer system, within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein may be executed.
- FIG. 15 is a schematic block diagram of a system, in accordance with an example embodiment of the invention, for automatically updating a client application.
- FIG. 16 is a schematic flow diagram of a method, in accordance with an example embodiment of the invention, for automatically updating a client application.
- FIGS. 17-19 show examples of more detailed functionality performed by the method of FIG. 16 .
- a system and method of accommodating at least one difference between a first database schema and a second database schema may include receiving a request from a first application program that is operationally dependent upon the first database schema, the request being received at a second application program that is operationally dependent upon the second database schema.
- the method includes identifying if there is a difference between the first database schema and the second database schema. When there is a difference, the method includes identifying the difference between the first database schema and the second database schema to identify at least one different schema definition element; associating the different schema definition element with a reserved element, the reserved element having a corresponding reserved element provided in the first database schema; and communicating a response to the first application program including the reserved element.
- An example embodiment of the present invention is discussed below within the context of a network-based commerce system that supports a network-based, electronic marketplace.
- Business processes may be driven by a wider range of electronic marketplace operational considerations, so as to enable buyers and sellers to conduct transactions utilizing the electronic marketplace.
- a server at the network-based commerce system transforms data into a modified format prior to communicating a response to a third-party system when the third-party system has an outdated version of the schema definitions. Accordingly, the network-based commerce system can still support third-party applications even though the schema definitions at the network-based commerce facility have changed.
- message exchanges comply with a business language schema component model.
- the business language schema design framework allows an electronic marketplace server system (e.g., the commerce system) to support a wide range of commerce transactions, including auction, fixed price buying and selling, product catalogs searches and payments. These transactions provide examples of communications between buying and selling applications via the electronic marketplace, as well as communications with other third-party business service providers.
- a schema component model that provides an abstract definition of the business message payloads.
- Payloads may be defined in a way to support extensibility which enables other types of commerce transactions models to be made available via the marketplace (e.g., for electronic procurement, reverse auctioning, credit check, and shipment/logistic activities).
- the business language schema may catalog common business message components that may be utilized for any number of business communications facilitated by an electronic marketplace (e.g., auction, fixed price buying and selling, product catalog search, catalog-based listings, and electronic payment in support of item purchases).
- the business language schema in one embodiment, enables a wide range of business applications to interoperate with XML web services APIs, and externally located and internally hosted clients.
- Request/response message payload components may be defined by the business language schema which can be utilized to enable the building of a range of messages that may flow back and forth from buyers, sellers and third-party business service providers to marketplace XML web services, these web services enabling trading parties to list, find, and sell items and services.
- message exchanges may be made, utilizing the business-language based message exchange model of an example embodiment of the present invention, with both external and internal business applications over synchronous communication and asynchronous communication links.
- document-oriented synchronous messaging as well as document-oriented asynchronous messaging, may be supported.
- a message packaging format may be a flavor of the XML messaging format (e.g., SOAP 1.1, SOAP 1.2, ebXML, or an e-mail format such as MIME or any other arbitrary message packaging format).
- transport protocols used may include HTTP, HTTPS, SMTP, or some other arbitrary transport protocol needed for particular business applications hosted remotely at a trading entity that requires moving data.
- a schema design framework for a host language in the example form of a business language is provided to support message payload definitions for a multitude of use cases and for use with a multitude of APIs. This may be accomplished via an extensibility model that includes base components, and business message components that support new transaction models and messaging components.
- the base components may provide a definition of basic core component types, basic components and aggregate components, including an abstract messaging framework.
- the business message components are based on the business information requirements for a particular use case.
- the business language components for use in an electronic trading environment may include: item, item transaction, shipping details, payment, address, user, buyer, seller and payment and transaction components.
- a commerce system when a commerce system receives a request from a third-party system, a response message is sent to the third-party system including instances of specific enumerated code types or placeholders (custom slots) for an element that has been added in an updated schema definition but which are not present in an outdated schema definition on the third-party system.
- An update to the schema definition(s) may, for example, be an updated XML schema definition for the targeted API.
- CustomCode also referred to herein as a reserved element or default element
- WSDL Web Services Description Language
- Core Component Type is, in one embodiment, a low level construct that may have no meaning on its own.
- a core component type has a content component and additional components (e.g., mandatory or optional) which give it a specific meaning.
- An example of a core component type is an “amount”, where the content part is a number (e.g., 87) and another required part is a unit (e.g., a Euro).
- Basic core components represents, in the example embodiment, a core business concept (e.g., a unique business semantic definition). This may be accomplished by employing a core component type (CCT) or a primitive data type (e.g., XSD data types) to which some other semantically unique object (e.g., a “weight” element is an instance of the core component type CCT Measure Type).
- CCT core component type
- XSD XSD data types
- Aggregate core components encapsulate two or more basic core components which represent higher-level business concepts (e.g., “shipping address” is an instance of Address Type). Each aggregate core component may have its own business semantic definition.
- FIGS. 1-3 Having above provided a high level introduction, a more detailed description of an example trading system, centered around a network-based commerce system, will now be described with reference to FIGS. 1-3 .
- FIG. 1 is a network diagram depicting a trading environment 10 , according to one example embodiment of the present invention, having a client-server architecture.
- a commerce server system in the example form of a network-based commerce system 12 , provides server-side functionality, via a network 14 (e.g., the Internet) to one or more clients.
- FIG. 1 illustrates, for example, a web client 16 (e.g., a browser, such as the Internet Explorer browser developed by Microsoft Corporation of Redmond, Washington State), and a programmatic client 18 executing on respective client machines 20 and 22 .
- a web client 16 e.g., a browser, such as the Internet Explorer browser developed by Microsoft Corporation of Redmond, Washington State
- programmatic client 18 executing on respective client machines 20 and 22 .
- an Application Program Interface (API) server 24 and a web server 26 are coupled to, and provide programmatic and web interfaces respectively to, one or more application servers 28 .
- the API server 24 exposes multiple APIs to users of the commerce system 12 .
- Each of these APIs supports one or more function calls to applications of the system 12 .
- Each of these APIs may have a associated API schema definitions.
- the application servers 28 host one or more marketplace applications 30 and payment applications 32 .
- the application servers 28 are, in turn, shown to be coupled to one or more databases servers 34 that facilitate access to one or more databases 36 .
- the marketplace applications 30 provide a number of marketplace functions and services to users that access the commerce system 12 .
- the payment applications 32 likewise provide a number of payment services and functions to users.
- the payment applications 30 may allow users to quantify for, and accumulate, value (e.g., in a commercial currency, such as the U.S. dollar, or a proprietary currency, such as “points”) in accounts, and then later to redeem the accumulated value for products (e.g., goods or services) that are made available via the marketplace applications 30 .
- value e.g., in a commercial currency, such as the U.S. dollar, or a proprietary currency, such as “points”
- the marketplace and payment applications 30 and 32 are shown in FIG. 1 to both form part of the network-based commerce system 12 , it will be appreciated that, in alternative embodiments of the present invention, the payment applications 32 may form part of a payment service that is separate and distinct from the commerce system 12 .
- trading environment 10 shown in FIG. 1 employs a client-server architecture
- present invention is of course not limited to such an architecture, and could equally well find application in a distributed, or peer-to-peer, system.
- the various marketplace and payment applications 30 and 32 could also be implemented as standalone software programs, which do not necessarily have networking capabilities.
- the web client 16 accesses the various marketplace and payment applications 30 and 32 via the web interface supported by the web server 26 .
- the programmatic client 18 accesses the various services and functions provided by the marketplace and payment applications 30 and 32 via the programmatic interface provided by the API server 24 .
- the programmatic client 18 may, for example, be a seller application (e.g., the TurboLister application developed by network-based commerce system 12 Inc., of San Jose, Calif.) to enable sellers to author and manage listings on the commerce system 12 in an off-line manner, and to perform batch-mode communications between the programmatic client 18 and the network-based commerce system 12 .
- such a programmatic client may operate in conjunction with locally stored schema definitions that the programmatic client 18 has previously received from the network-based commerce system 12 .
- out of date schema definitions on the programmatic client may be accommodated by the network-based commerce system 12 without affecting the operability of the programmatic client 18 .
- FIG. 1 also illustrates a third-party application 38 , executing on a third-party server machine 40 , as having programmatic access to the network-based commerce system 12 via the programmatic interfaces provided by the API server 24 .
- the third-party application 38 may, utilizing information retrieved from the network-based commerce system 12 , support one or more features or functions on a website hosted by the third-party.
- the third-party website may, for example, provide one or more promotional, marketplace or payment functions that are supported by the relevant applications of the network-based commerce system 12 .
- FIG. 2 is a block diagram illustrating multiple marketplace and payment applications 30 that, in one example embodiment of the present invention, are provided as part of the network-based commerce system 12 .
- the commerce system 12 may provide a number of listing and price-setting mechanisms whereby a seller may list goods or services for sale, a buyer can express interest in or indicate a desire to purchase such goods or services, and a price can be set for a transaction pertaining to the goods or services.
- the marketplace applications 30 are shown to include one or more auction applications 44 which support auction-format listing and price setting mechanisms (e.g., English, Dutch, Vickrey, Chinese, Double, Reverse auctions etc.).
- the various auction applications 44 may also provide a number of features in support of such auction-format listings, such as a reserve price feature whereby a seller may specify a reserve price in connection with a listing and a proxy-bidding feature whereby a bidder may invoke automated proxy bidding.
- a reserve price feature whereby a seller may specify a reserve price in connection with a listing
- a proxy-bidding feature whereby a bidder may invoke automated proxy bidding.
- a number of fixed-price applications 46 support fixed-price listing formats (e.g., the traditional classified advertisement-type listing or a catalogue listing) and buyout-type listings.
- buyout-type listings e.g., including the Buy-It-Now (BIN) technology developed by network-based commerce system 12 Inc., of San Jose, Calif.
- BIN Buy-It-Now
- Store applications 48 allow sellers to group their listings within a “virtual” store, which may be branded and otherwise personalized by and for the sellers. Such a virtual store may also offer promotions, incentives and features that are specific and personalized to a relevant seller.
- Reputation applications 50 allow parties that transact utilizing the network-based commerce system 12 to establish, build and maintain reputations, which may be made available and published to potential trading partners.
- the network-based commerce system 12 supports person-to-person trading
- users may have no history or other reference information whereby the trustworthiness and credibility of potential trading partners may be assessed.
- the reputation applications 50 allow a user, for example through feedback provided by other transaction partners, to establish a reputation within the network-based commerce system 12 over time. Other potential trading partners may then reference such a reputation for the purposes of assessing credibility and trustworthiness.
- Personalization applications 52 allow users of the commerce system 12 to personalize various aspects of their interactions with the commerce system 12 . For example a user may, utilizing an appropriate personalization application 52 , create a personalized reference page at which information regarding transactions to which the user is (or has been) a party may be viewed. Further, a personalization application 52 may enable a user to personalize listings and other aspects of their interactions with the commerce system 12 and other parties.
- the network-based commerce system 12 may support a number of marketplaces that are customized, for example, for specific geographic regions.
- a version of the commerce system 12 may be customized for the United Kingdom, whereas another version of the commerce system 12 may be customized for the United States.
- Each of these versions may operate as an independent marketplace, or may be customized (or internationalized) presentations of a common underlying marketplace.
- Navigation of the network based-commerce system 12 may be facilitated by one or more navigation applications 56 .
- a search application enables key word searches of listings published via the commerce system 12 .
- a browse application allows users to browse various category, catalogue, or inventory data structures according to which listings may be classified within the commerce system 12 .
- Various other navigation applications may be provided to supplement the search and browsing applications.
- the marketplace applications 30 may include one or more imaging applications 58 utilizing which users may upload images for inclusion within listings.
- An imaging application 58 also operates to incorporate images within viewed listings.
- the imaging applications 58 may also support one or more promotional features, such as image galleries that are presented to potential buyers. For example, sellers may pay an additional fee to have an image included within a gallery of images for promoted items.
- Listing creation applications 60 allow sellers conveniently to author listings pertaining to goods or services that they wish to transact via the commerce system 12
- listing management applications 62 allow sellers to manage such listings. Specifically, where a particular seller has authored and/or published a large number of listings, the management of such listings may present a challenge.
- the listing management applications 62 provide a number of features (e.g., auto-relisting, inventory level monitors, etc.) to assist the seller in managing such listings.
- One or more post-listing management applications 64 also assist sellers with a number of activities that typically occur post-listing. For example, upon completion of an auction facilitated by one or more auction applications 44 , a seller may wish to leave feedback regarding a particular buyer. To this end, a post-listing management application 64 may provide an interface to one or more reputation applications 50 , so as to allow the seller conveniently to provide feedback regarding multiple buyers to the reputation applications 50 .
- Dispute resolution applications 66 provide mechanisms whereby disputes arising between transacting parties may be resolved.
- the dispute resolution applications 66 may provide guided procedures whereby the parties are guided through a number of steps in an attempt to settle a dispute. In the event that the dispute cannot be settled via the guided procedures, the dispute may be escalated to a third-party mediator or arbitrator.
- a number of fraud prevention applications 68 implement various fraud detection and prevention mechanisms to reduce the occurrence of fraud within the commerce system 12 .
- Messaging applications 70 are responsible for the generation and delivery of messages to users of the network-based commerce system 12 , such messages for example advising users regarding the status of listings at the commerce system 12 (e.g., providing “outbid” notices to bidders during an auction process or to provide promotional and merchandising information to users).
- Merchandising applications 72 support various merchandising functions that are made available to sellers to enable sellers to increase sales via the commerce system 12 .
- the merchandising applications 80 also operate the various merchandising features that may be invoked by sellers, and may monitor and track the success of merchandising strategies employed by sellers.
- the network-based commerce system 12 itself, or one or more parties that transact via the commerce system 12 may operate loyalty programs that are supported by one or more loyalty/promotions applications 74 . For example, a buyer may earn loyalty or promotions points for each transaction established and/or concluded with a particular seller, and be offered a reward for which accumulated loyalty points can be redeemed.
- FIG. 3 is a high-level entity-relationship diagram, illustrating various tables 90 that may be maintained within the databases 36 , and that are utilized by and support the marketplace and payment applications 30 and 32 .
- a user table 92 contains a record for each registered user of the network-based commerce system 12 , and may include identifier, address and financial instrument information pertaining to each such registered user.
- a user may, it will be appreciated, operate as a seller, a buyer, or both, within the network-based commerce system 12 .
- a buyer may be a user that has accumulated value (e.g., commercial or proprietary currency), and is then able to exchange the accumulated value for items that are offered for sale by the network-based commerce system 12 .
- accumulated value e.g., commercial or proprietary currency
- the tables 90 also include an items table 94 in which are maintained item records for goods and services that are available to be, or have been, transacted via the commerce system 12 .
- Each item record within the items table 94 may furthermore be linked to one or more user records within the user table 92 , so as to associate a seller and one or more actual or potential buyers with each item record.
- a transaction table 96 contains a record for each transaction (e.g., a purchase transaction) pertaining to items for which records exist within the items table 94 .
- An order table 98 is populated with order records, each order record being associated with an order. Each order, in turn, may be with respect to one or more transactions for which records exist within the transactions table 96 .
- Bid records within a bids table 100 each relate to a bid received at the network-based commerce system 12 in connection with an auction-format listing supported by an auction application 44 .
- a feedback table 102 is utilized by one or more reputation applications 50 , in one example embodiment, to construct and maintain reputation information concerning users.
- a history table 104 maintains a history of transactions to which a user has been a party.
- One or more attributes tables 106 record attribute information pertaining to items for which records exist within the items table 94 . Considering only a single example of such an attribute, the attributes tables 106 may indicate a currency attribute associated with a particular item, the currency attribute identifying the currency of a price for the relevant item as specified in by a seller.
- FIG. 4 is block diagram illustrating a client-server architecture that may be deployed, for example, as part of the trading environment 10 described above with reference to FIG. 1 .
- request/response messages 120 may be sent between one of N third-party systems, such as third-party system 122 , and a server system 125 that is accessed via a number of APIs exposed by respective API servers 24 .
- the third-party system 122 using the client application 124 , compiles a request message, which is directed to an API 126 (e.g., Addltem, GetItemTransaction, etc.) of the server system 125 .
- Each API 126 in turn provides access through supported function calls to one of a plurality of applications, indicated generally by arrow 128 , that have access to a database 130 .
- the client application 124 includes a request/response message (e.g., an abstract request/response message) process component 136 for processing the request/response messages 120 shown in FIG. 4 .
- the example abstract request/response message process component 136 comprises an Error Processor 138 and a Version Processor 140 .
- the client application 134 further comprises an API-specific component 142 that includes XML schema definitions 144 , 146 for the various API's 126 with which the client application 124 is configured to communicate (e.g., API_ 0 and API _ 1 shown in FIG. 4 ).
- API_ 0 and API _ 1 shown in FIG. 4 A number of possible front end transport technologies, such as SOAP, MIME and HTTP, are shown to be supported by a transport handler 13 .
- the XML schema definitions 144 , 146 may no longer be identical to those provided at the server system 125 due to updates/modifications that may take place to schema definitions at the server system 125 . For example, new operations and/or data elements may be added to the schema definition(s).
- such variations between the client-side and server-side schema definitions may be accommodated so that the client-side components (e.g., API-specific component 142 ) are still be operable.
- the client application 124 is also shown by way of example to include a message handler 145 , and a serialization/deserialization handler 147 , in addition to the API specific component 142 .
- each third-party system 122 may host a client application 124 , which can exploit the abstract request/response message via any one of the following processing components:
- the transport handler 143 and the message handler can be formed from any standard, commercially available Software Development Kit (SDK) to which a third-party has access in its development and runtime deployment environments.
- SDK Software Development Kit
- the abstract request serialization and response deserialization handler 137 can be developed for client applications 124 once, and reused multiple times, thus reducing the cost of interfacing and also providing consistent interfacing with API-based application services exposed by the commerce system 12 over a wide range of transport and messaging particles. Such a “write once and, use multiple times” deployment is useful for trading communities, regardless of use case and other infrastructure components in support of transport, security and messaging protocols.
- an example API Server 148 comprises a front end Presentation tier 150 , which receives request messages and sends response messages, a Business tier 152 and a Data components tier 154 .
- the Business tier 152 includes components corresponding to the various APIs, indicated generally by arrow 156 .
- an example abstract request message 158 comprises a Detail Level component 160 and an associated DetailCodeType 162 .
- the level of detail requested may range from a most detailed to a least detailed level.
- the abstract request message 158 further comprises an Error Language component 164 and an associated Language Identification Tag 166 , and a Version_ID component 168 and an associated Version Identifier 170 .
- the abstract request message 158 is then completed by providing a Request Payload component 172 , for carrying any type of XML data 174 .
- An example abstract response message 176 includes a Time Stamp component 178 and an associated DateTime 180 , and an Acknowledgement component 182 and an associated AckCodeType 184 . These components are used to acknowledge receipt of a request message of the received from a client application 124 .
- the abstract response message 176 further includes a Correlation_ID component 186 and associated String Identifier 188 , an Error(s) Data component 190 and associated data 192 , a Version_ID 193 , a Build component 194 and a Response Payload component 196 for receiving any type of XML data 198 .
- Correlation_ID component 186 and associated String Identifier 188 allow the abstract response message 176 to be correlated with a particular incoming request message 158 , and to indicate this correlation to the requesting client application 124 .
- the Error Language component 164 and the Error Data(s) component 190 ensure that the API request/response messages consistently use, manage and communicate error components. Part of this is the ability to communicate versioning information identifying what version of an API a particular API server 24 is using to communicate with a client application 124 of a third-party system 122 (e.g., a client 20 and 22 ). Thus, for example, if a third-party system 122 sends a request message that includes incorrect data or that does not comply with the published requirements of a target API, the Error(s) Data component 190 may be used by the target API to communicate information regarding the error back to the client application 124 .
- a response message may be generated by the relevant API, this response message being either a long message or a short message, and including an error code and associated severity code.
- This response message is sent to the relevant client application 124 , thereby informing the client application 124 as to the nature of the error.
- versioning information may be included in both a request message from a client application 124 to the API server 24 , as well as a response message from the API server 24 back to the client application 124 .
- This is indicated schematically by blocks 168 and 193 in FIG. 7 .
- the respective version components in the request and response messages indicate a particular version of the API on the API server 24 .
- the client application 124 will have a way of detecting when it needs to upgrade the schema that it uses to format and generate request messages to the relevant.
- the server system 125 may detect from the version identification (Version_ID—see block 168 ) received from the client application 124 that the XML schema definitions 144 , 144 are no longer current and do not correspond with the latest or current versions at the server system 125 . As discussed in more detail below, the server 125 may then process or transform data from based on the current schema definition so that a response to the client application 124 does not render the client application 124 inoperable.
- version identification (Version_ID—see block 168 ) received from the client application 124 that the XML schema definitions 144 , 144 are no longer current and do not correspond with the latest or current versions at the server system 125 .
- the server 125 may then process or transform data from based on the current schema definition so that a response to the client application 124 does not render the client application 124 inoperable.
- the host language includes the example request and response message structures.
- the abstract request and response models can be extended to enable API requests and responses between a third-party system 122 and any number of APIs provided by one or more API servers 24 .
- a particular server system may expose a number of APIs, each conforming to the basic request/response messages described above.
- the basic request/response messages can be extended to enable an AddItem API, or a GetItem API, or a GetAccount API.
- the basic abstract request message may be extended with the addition of information conforming to a schema understood by a GetItem API. It will however be appreciated that the present invention is not limited to this message structure. In other words, this example arrangement allows a third-party system 122 , hosting an appropriately configured client application 124 , to communicate with multiple APIs.
- APIs with a degree of uniformity and predictability.
- a uniform data processing model is utilized and supported by a number of APIs, thereby allowing developers of client applications to reuse parts of their code.
- schema components may be defined such that they can be reused for multiple cases of purchasing and selling items listed via the network-based commerce system 12 . Examples of such reuse are provided below:
- a client application 124 may be configured to retrieve information about a particular item, or multiple items, that are actively listed via the network-based commerce system 12 .
- the client application 124 is required to send information back to a network-based commerce system 112 regarding items listed for sale via the commerce system 12 .
- This may require description of an ⁇ item> structure in a consistent manner such that the client applications 122 from which the API calls originate understand the semantics of an item listed by a seller on the e-commerce system 12 .
- a different degree of information needs to be provided such that some data components are included or excluded.
- such functionality may be dependent upon the XML-schema definitions 144 , 146 which, as mentioned above, may change or be updated at the server system 125 .
- an “item” has required optional data components. These components internally also have child components that are required and optional components.
- a single item component definition may be used for multiple API use cases, with the developers and designers of the APIs being able to select which elements of the item component must be present and which elements of an item component do not need to be present.
- an API processing payload may, in one embodiment, include the following sequence of validations:
- the above sequence of validations utilizes a single definition of key business data components such that data variability in request/response messages can be supported in a controlled manner using the required validation logic for the business use case.
- the same definition of an ⁇ item> business definition component can be used on the client side—yet the APIs will return response messages with varying API data structures. This enables uniformity in a semantic definition, yet allows the return of different views of the ⁇ item> business component according to use case.
- a server system e.g., a network-based commerce system 12
- a server system that exposes multiple business application services can utilize these multiple exposed business applications in communicating with multiple client applications 122 in a way that the client applications 122 can understand and communicate.
- information about an item with varying syntactic characteristics that correspond to an item is communicated (e.g., information about an item with varying syntactic characteristics that correspond to a data item component with a common semantic definition).
- the above contributes to the reusability of data components within, for example, a trading community with multiple use cases.
- a developer downloads or imports XML, schema definitions for each of the multiple APIs.
- the developer will need to import or download the corresponding schema for this API, and in particular the GetTransactionDetail request message as well as the GetTransactionDetail response message.
- the client application 124 will need to integrate these schema processing components with their own (e.g., as part of the API specific component 142 ).
- the downloaded or imported schema definitions include CustomCode or reserved elements in the schema definition to accommodate changes in the schema definitions at the server system 135 .
- a forced or reserved element (CustomCode) is included in the schema definition.
- the forced element or CustomCode is used to replace additional elements that may have been include in the modified schema definition at the server system 125 .
- the server system 125 uses the forced or reserved element when encountering a value that would violate the XML schema definition at the third-party system 122 .
- a default value or reserved element is provided as the enumerated code type in the response when the enumerated code type at the server system 125 will not be understood by the client application 124 using an outdated or different schema definition.
- an original XML schema definition may define 7, 10, 14 and 21 day duration values, but the next month, the updated up XML schema definition may be updated to remove the duration value of 21 days, or add a duration value of 28 days.
- a further element is added to the schema definitions at the server system 125 (e.g., the addition of the 28 day value)
- the client application 124 may see this as a violation as the value is not provided in any of the schema definitions originally provided at the third-party system 122 .
- the example duration value of 21 days is removed, if the client application 124 , utilizing the original XML provided to the third-party system 122 , attempts to provide the 21 day duration value against an updated API at the server system 125 , this may be registered as a violation.
- a forced element or reserved element which can carry any value, may be inserted into the request and/or response (e.g., into payload 196 of a response message 176 in one example embodiment).
- an indication of a change in a schema definition element (or any other difference/change in the database schema) against the updated API of the commerce system 12 will be accepted, but the updated API may issue a warning to the relevant client application 124 that it needs to upgrade the relevant XML schema.
- the server system 125 identifies that a version of the schema definition(s) on the third-party system 122 is outdated, it may use a forced element or CustomCode to allow backwards compatibility of the outdated schema definition(s).
- the default value or CustomCode is only inserted by the API server into the response message when the server detects that the client is using an outdated version of the schema definition.
- FIG. 8 is a flowchart illustrating a method 250 , according to an example embodiment of the present invention, of performing version management between a client application 124 and an API, for example implemented by the commerce system 12 .
- the method 250 illustrates how the API of the commerce system 12 leverages a schema definition including reserved or forced elements to communicate back to a client application 124 with client enumerated code types in a scenario in which the client application 124 may not be synchronized with a latest version of an API adopted by the commerce server 12 .
- XML-schema definitions 144 , 146 may no longer fully correspond to the definitions (e.g., updated) provided at the server system 125 .
- the method 250 commences at block 252 , with the client application 124 including its version identifier (e.g., Version ID), identifying the version of an XML-schema definition stored by the client application 124 , within a request message 158 addressed to a particular target API 126 .
- version ID e.g., Version ID
- An example of the version identifier 170 is provided below:
- version identifier “383” may represent a particular third-party in the form of a “site code” that identifies (optionally uniquely identifies) the version of a schema definition(s) at the site.
- the site code may also relate to a particular international site.
- the version information may, however, be a date that identifies when the version was released to the third-party application 122 , when the version was created at the server system 125 , or any other version identification detail.
- an API 126 of the server system 125 receives a message request (e.g., the request message 158 ) from the client application 124 , and determines from the version identifier if the client application 124 is utilizing a different and older version of an API schema or schema definitions supported by the relevant target API 126 .
- a message request e.g., the request message 158
- the targeted API may compose a response message 176 (e.g., including a response payload 196 ) and include within the response message 176 instances of specific enumerated code types for an element (e.g., ⁇ Site>CustomCode ⁇ /Site>) provided in an updated schema definition at the server system 125 but not at the third-party system 122 .
- an element e.g., ⁇ Site>CustomCode ⁇ /Site>
- the “CustomCode” or forced element being returned in such scenarios will prevent the client application 124 from experiencing a communication breakdown with the API, due to incremental schema changes and evolutions that may occur as part of the commerce system 12 , for example, revising API-based application service offerings.
- the response indicates to the client application 124 that the version at the third-party 122 is out of date.
- the server system 125 may merely include the CustomCode to accommodate one or more differences between the schema definitions at the third-party system 122 and the server system 125 .
- FIG. 9 shows an example embodiment of a system 260 , in accordance with the invention, to accommodate at least one difference between a first database schema (e.g., schema definition(s)) and a second database schema (e.g., schema definition(s)).
- the system 260 allows a request to be received from a first application program (e.g., the client-side or client application 122 ) that is operationally dependent upon the first database schema (e.g., API-specific component 142 ).
- the request is received at a second application program (e.g., an APIs 126 ) that is operationally dependent upon the second database schema (e.g., a database schema definition associated with the API).
- a processing or transform module 131 may identify if there is a difference between the first database schema and the second database schema. If no difference is identified or detected, the server system may process the request in a regular fashion. However, when a difference is detected, the transform module may identify the difference between the first database schema and the second database schema to determine at least one different schema definition element.
- the different schema definition element e.g., the addition of a new payment method as described by way of example below
- the server system 125 then communicates a response to the third-party application including the reserved element so that operation of the client application 124 is not impeded by a definition element unknown to it.
- WSDL Web Services Description Language
- WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services).
- WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate and the WSDL in may be used conjunction with SOAP 1.1, HTTP GET/POST, MIME, or the like. As can be seen in FIG.
- the schema definition(s) at the server system 125 include updates wherein changes are documented or identifiable, and the third-party system 122 includes a schema definition 142 as originally provided to the third-party system 122 (or the last updated version of the schema definition(s) provided to the third-party system 122 ).
- FIG. 10 shows an example schema definition at the server system 125 (e.g., stored in the dataset 130 .
- the definition file may be operatively associated with any host programming language.
- the host programming language is a business language.
- the schema definition 270 is an updated definition to that which currently resides on the third-party application.
- An example of the client-side schema definition 280 is shown in FIG. 11 .
- the schema definition 280 may, for example, correspond to a XML-schema definition 144 , 146 (see FIG. 5 ).
- the schema definition 280 is shown, by way of example, to include operation components 282 , data types 284 and a definition 286 (defining a dictionary).
- the schema definition 270 includes corresponding operation components 282 , data types 284 and definition 286 .
- the custom slot 288 allows the server system 125 to modify its schema definition and yet still allow communication of responses to the third-party application 122 that the client application 124 may process despite the differences in the schema definitions.
- WSDL-based calls/requests made by applications to the network-based commerce system 12 using an old version of a web service may still be processed by mapping or transforming them to one or more new versions.
- the network-based commerce system 12 at the time of generating the API-specific components 142 supported two payment methods shown by way of example to be Visa 288 and MasterCard 290 .
- the definitions 286 (or dictionary generated from the definitions) that are provided at this point in time would then have definitions for these two payment methods.
- the schema definition 129 at the server system 125 would correspond with the schema definitions 142 144 , 146 provided at the third-party system 122 .
- Any client application 124 operably dependent upon the schema definition 144 , 146 would have no operability problems with responses received from the server system 125 as the schema definitions correspond. In these circumstances, enumerated values or input values which are allowed in a system would be unchanged.
- the network-based commerce system 12 adds a further payment method such as American Express or Amex 292 and, as a result thereof, a new or updated schema definition 270 is generated.
- the third-party system 124 may however still have the previous (old) version of the schema definition.
- the server version of the schema definition 129 (see FIG. 9 ) is now different from the client version of the schema definition 144 , 146 operability problem may arise in prior art systems.
- definition elements may be removed.
- the server system 125 may remove the Visa 288 payment method.
- a custom or default slot may be created for one or more dictionary types (e.g., payment type, country, or any other definition), operation types, or data types.
- FIG. 13 shows a flowchart of an example method 300 , in accordance with an embodiment of the invention, of accommodating at least one difference between a first database schema and a second database schema.
- the method 300 is described by way of example with reference to the trading environment 10 .
- one of the APIs 126 of the server system 125 receives a request from the client application 124 which identifies what version of a particular XML schema definition associated with the API 126 is resident on the third-party system 122 .
- various business processing tasks may be performed. For example, checks may be performed to determine if the request came from a valid user; whether the request is appropriately formatted and other data checking procedures may be performed. If the request is not a valid request (see decision block 306 ), an error message may be returned to the third-party system 122 as shown at block 308 .
- the request is then processed to determine if data requested and retrieved from a database (e.g., the database 130 ) needs to be transformed or changed as a result of differences between the API-specific components 142 (e.g., the schema definitions 144 , 146 ) and the schema definition 129 .
- the relevant application 128 performs the necessary database calls required to process the request (see block 308 ).
- the client version of the schema definitions 144 , 146 (which ever is appropriate for the selected API) is compared to the current version of the schema definitions resident at the server system 125 as shown at block 310 .
- Definitions or a dictionary corresponding to those present at the client application 124 may be retrieved at block 312 . Accordingly, differences between the current schema definition at the server system 125 and the schema definition at the third-party system 122 may be identified or determined. Thereafter, as shown at block 314 , the schema definition in the current schema definition 129 is transformed to a schema definition corresponding to that at the third-party system 122 . Data returned from the various database calls is transformed (see block 316 ) into a format corresponding to the schema definitions 144 , 146 at the third-party application to provide client usable data. In one example embodiment, this involves using a CustomCode or reserved code (recognizable by the client application 122 ) instead of the updated definition element from the updated schema definitions 142 .
- a map or record may be kept at the backend of the system 125 whenever the schema definition or dictionary is changed, for example, when the new payment method Amex 292 was introduced.
- the update is in the form of an addition to a dictionary 286 , however, any changes to the definitions 280 may be accommodated using the CustomCode or default element technique.
- FIG. 12 shows exemplary modules used by the trading environment 10 that allow application functionality based on client-side and server-side schema definitions.
- the server system 125 is shown by way of example to include a definition module 320 to create a schema definition for distribution or publication to at least one third-party system 122 , as shown by arrow 324 .
- the networked-based commerce system 12 may have an agreement with a third-party system 122 to support communication between the server system 125 and the third-party system 122 for a given duration (e.g., a year or several of years).
- a third-party may write specific client applications (e.g., the client application 124 ) that rely on the schema definitions 142 .
- the specific client applications 124 may fail if responses received from the server system 125 are based on a different schema definition.
- dictionaries may be created from definition modules.
- the first step in creating the schema definition 270 , 280 may be a definition step followed by a dictionary creation step. This may be done for each API 126 . Whenever a dictionary is updated it may be dated as shown in the version column 332 of the dictionary module table 326 .
- the dictionary module table 326 is shown by way of example to include a word column/attribute 328 , a database value column/attribute 330 , and a version column/attribute 332 .
- the dictionary module table 326 may track software changes at the network-based commerce system 12 . Accordingly, using the dictionary module table 326 differences between a version of a schema definition resident on a third-party system 122 and on a network-based commerce system 12 may be determined or identified. In one embodiment, any additional language terms, definitions or the like are communicated as CustomCode or a reserved element.
- a further payment type “Discover” may be added (not shown) to the definitions 286 .
- the definitions would comprise Visa 288 , Mastercard 290 , Amex 292 and Discover (not shown).
- the version number of the schema definition 280 at the client application 122 may only accommodate three payment methods (Visa 288 , Mastercard 290 , and Custom slot or CustomCode 288 ).
- the transform module 131 may transform a response from the database 130 using the current version of the schema definition 280 (Visa 288 , Mastercard 290 , Amex 292 and Discover) as Visa 288 , Mastercard 290 , CustomCode, and CustomCode.
- the schema definition 280 (Visa 288 , Mastercard 290 , Amex 292 and Discover) as Visa 288 , Mastercard 290 , CustomCode, and CustomCode.
- a predefined slot included in the schema definition when created subsequent changes to the schema definition may not render a client application 124 inoperable due to the changes.
- a plurality or many custom slots 288 may be provided at different points in the structure of the schema definition 280 .
- the data schema may also include other elements such as auction types, currency types, feedback types, country, and so on. It will be appreciated that the explanation above using payment types is merely an example of the use of a custom slot 288 . It will be appreciated that a change in any element in a database schema may be accommodated by using the custom slot or CustomCode.
- the network-based commerce system 12 has a dictionary at the backend that lists well-defined languages which the network-based commerce facility 12 understands.
- concepts supported by the network-based commerce facility may include payment terms, shipping services, currency, duration, auction type, display enhancements, and so on. These concepts may have a plurality of dictionary terms each relating to a concept.
- An example of dictionary terms associated with shipping services could be “UPS” and “USPS”.
- the dictionary may be exact in that it defines United Parcel Service of America as “UPS” and not “United Parcel Service of America” and, likewise, the dictionary may define the United States Postal Services as “USPS” not “United States Postal Service”. If, for example, FedEd was subsequently added to the schema definition at the server system 125 , it would be categorized as CustomCode if the version of the schema definition at the client application 124 was created before its introduction.
- the system 125 would return the value “7” corresponding with W 1 when it is returned from the database 130 but would return the CustomCode or default value when values “9” and “3” (corresponding to words W 2 and W 3 ) are returned from the database 130 .
- data returned from a database is transformed based on a dictionary resident at the client application. Accordingly, the client application can “understand” the response and thus process the response it receives even though the two schema definitions are different.
- a mapping function may be performed by the transform module 131 . For example, if word “W 3 ” is not provided in the client definitions, then the transform module maps “W 3 ” to the CustomCode or reserved element. This functionality may be applied in any environment which exposes a dictionary which defines a system, for example, any piece of software code having static data elements.
- one or more special reserved values or CustomCodes may be provided.
- the CustomCode or reserved value may be communicated to the client instead of a value that would be unknown to the client.
- slots or values may be reserved for in an XML schema.
- the slots or values may be used to return schema object(s) which are not present on the client due to its outdated version.
- SOAP APIs work on objects based on input and output objects (and not XML) from end-client and server perspectives.
- the transport payload may still however be XML.
- the objects and the transport payload may be based on predefined XML schemas.
- reference 500 generally indicates a system, in accordance with an embodiment of the invention, for updating a development application 502 (e.g., a System Development Kit (SDK) at a client (e.g., a client application 124 at a third-party system 122 ).
- a server-side application e.g., API servers 126 at a network-based commerce system 12
- the client application 124 may be automatically updated by an auto-update module 503 .
- the auto-update module 503 may automatically update utilities 504 , wrappers 506 and API calls 508 .
- An integration module 510 may integrate changes made a the network-based commerce system utilizing data in a database 130 .
- the development application 502 may be used by the third-party system 122 to gain programmatic access to server systems 125 of the network-based commerce facility 12 .
- such development applications may allow a third-party to bulk upload auction listings, bulk delete auction listing, modify auction listing in a bulk-fashion, monitor the status of a plurality of listings and so on.
- the development application 502 may communicate with the network-based commerce facility 12 using a business language. However, it will be appreciated that any programming language may be used.
- the network-based commerce system 12 creates the development application 502 and , users or third-parties may download it. It will be appreciated that a third-party may download components of an application (e.g., a System Development Kit) that are then included or integrated within a client application 124 .
- API servers 125 at the network-based commerce facility 12 may support client application that may be Java-based, desktop-based, or server-based applications resident on the third-party system 122 .
- network-based commerce system 12 may (e.g., regularly) change features on its backend server(s), for example, on the API server(s) 126 , such changes may be recorded. For example, a version number or identifier may be included in each revision or change. Examples of such features include new functionality within an action supported. For example, the network-based commerce system 12 may start to allow shipping to Canada and, accordingly, addition of an associated action may be required. The new action may, for example, be “create automatic shipping labels.” It may not be practical to release a new version of the development application 502 each time new functionality is added to the server system 125 .
- the development application 502 includes an API call component 508 (to make a call to the API server 126 ), wrappers 506 , an integration library 510 which calls and docks to the database 130 at the network-based commerce system 12 , and utilities 504 .
- the utilities in an embodiment, are basically useful functions that are written to combine various calls and other functions.
- the auto-update module 503 changes the calling mechanism and the integration library to support the latest features without having the network-based commerce system 12 to create a new version of the client application 124 .
- reference 520 generally indicates a method, in accordance with an example embodiment of the invention, for updating a client application.
- the method 520 initially checks to see if a new version (e.g., a new WSDL version) is running at the server system 125 . This may be accomplished by making a call to the network-based commerce system 12 and receiving a response indicating what the latest version at the server system 125 is.
- the version number may identify the version of a schema definition language.
- a check is then performed at decision block 524 to determine if the version number has changed. If the schema definition version has not changed, the method 520 stops as shown at 526 .
- the network-based commerce system 12 will generate new API call data objects (see block 528 ), generate standard wrappers (see block 530 ), and generate an integration library (see block 532 ).
- the new objects may be new Java objects.
- the generation of the new API call data objects may include generating language specific containers (see block 540 in FIG. 17 ) and generating new dictionaries (see block 542 ).
- the generation of the wrappers may comprise providing standard data converters (see block 544 in FIG. 18 ) and generating iterators (see block 546 ).
- the generation of the integration library may include updating the integration library to understand any new dictionary terms (see block 550 in FIG. 19 ) that have been defined at the server system 125 .
- Definition scripts are then created at block 552 .
- scripts may be created for the new shipping option to Canada.
- code is generated to persist the new object types.
- FIG. 14 shows a diagrammatic representation of machine in the example form of a computer system 400 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.
- the machine operates as a standalone device or may be connected (e.g., networked) to other machines.
- the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.
- the machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.
- PC personal computer
- PDA Personal Digital Assistant
- STB set-top box
- a cellular telephone a web appliance
- network router switch or bridge
- the example computer system 400 includes a processor 402 (e.g., a central processing unit (CPU) a graphics processing unit (GPU) or both), a main memory 404 and a static memory 406 , which communicate with each other via a bus 408 .
- the computer system 400 may further include a video display unit 410 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)).
- the computer system 400 also includes an alphanumeric input device 412 (e.g., a keyboard), a cursor control device 414 (e.g., a mouse), a disk drive unit 416 , a signal generation device 418 (e.g., a speaker) and a network interface device 420 .
- the disk drive unit 416 includes a machine-readable medium 422 on which is stored one or more sets of instructions (e.g., software 424 ) embodying any one or more of the methodologies or functions described herein.
- the software 424 may also reside, completely or at least partially, within the main memory 404 and/or within the processor 402 during execution thereof by the computer system 400 , the main memory 404 and the processor 402 also constituting machine-readable media.
- the software 424 may further be transmitted or received over a network 426 via the network interface device 420 .
- machine-readable medium 422 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions.
- the term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention.
- the term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Business, Economics & Management (AREA)
- Databases & Information Systems (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Finance (AREA)
- Accounting & Taxation (AREA)
- General Engineering & Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Entrepreneurship & Innovation (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
A method of accommodating at least one difference between a first database schema and a second database schema is provided. The method includes receiving a response generated by a first application program using a first database schema, identifying a value in the response that is unrecognizable to a second application program using a second database schema, and substituting, using a processor, the value that is unrecognizable to the second application program with a reserved element recognizable to the second application program, the reserved element indicating to the second application program that a portion of the response is not recognizable to the second application program. The method further includes communicating the response to the second application program.
Description
- This application is a continuation of U.S. patent application Ser. No. 14/739,098, filed on Jun. 15, 2015, now U.S. Pat. No. 10,031,929, issued on Jul. 24, 2018; which is a continuation of U.S. patent application Ser. No. 14/051,750, filed on Oct. 11, 2013, now U.S. Pat. No. 9,058,343, issued on Jun. 16, 2015; which is a continuation of U.S. patent application Ser. No. 12/907,524, filed on Oct. 19, 2010, now U.S. Pat. No. 8,606,824, issued on Dec. 10, 2013; which is a continuation of U.S. patent application Ser. No. 11/074,541, filed on Mar. 8, 2005, now U.S. Pat. No. 7,844,639, issued on Nov. 30, 2010; which claims the benefit of U.S. Patent Application Ser. No. 60/559,204, filed on Apr. 1, 2004; and is a continuation-in-part of U.S. patent application Ser. No. 10/997,767, filed on Nov. 24, 2004, now U.S. Pat. No. 7,818,759, issued on Oct. 19, 2010; which claims the benefit of U.S. Patent Application Ser. No. 60/524,782, filed on Nov. 24, 2003; the disclosures of all of these applications and patents are incorporated by reference herein.
- The present application relates generally to the technical field of database schemas and application program interfaces using such schemas.
- Buyers, sellers, and other business partners, are increasingly utilizing electronic trading systems (e.g., electronic marketplaces) to collaborate and to do business with each other. Part of this collaboration may involve, for example, linking operational business processes. Business processes may be linked by the exchange of information, in agreed sequences and within agreed timeframes, between buyer and seller applications, and affiliated third-party business service providers.
- To facilitate the above-mentioned exchange of business information, buyer and seller applications, as well as applications of third-party business service providers, may expose Application Program Interfaces (APIs) which allow applications to make calls (e.g., function calls) to other applications to either request or send information. However, as the number of buyers, sellers, and third-party applications participating in the exchange of business information increases, the technical challenge of enabling this multitude of applications to exchange information increases. For example, the development of applications that are able to access APIs of a large number of other applications becomes increasingly burdensome and technically challenging. Further, data schemas or definitions provided by a network-based commerce facility to a third-party may however become outdated when changes occur with a master data schema at a network-based commerce facility. When changes occur with the master data schema, functional problems may arise at the third-party application.
-
FIG. 1 is a network diagram depicting a trading system, within which an example embodiment of the present invention may be deployed, having a client-server architecture. -
FIG. 2 is a block diagram illustrating multiple marketplace and payment applications that, in one example embodiment of the present invention, form part of a commerce server system. -
FIG. 3 is a high-level entity-relationship diagram illustrating various tables that may be maintained within databases utilized by the marketplace and payment applications described with reference toFIG. 2 . -
FIG. 4 is a block diagram illustrating further details regarding an example trading system, configured according to one of embodiment of the present invention. -
FIG. 5 is a block diagram illustrating the architecture of an example third-party application, configured according to one embodiment of the present invention, to communicate with a commerce server system that exposes a number of APIs. -
FIG. 6 is a block diagram illustrating the architecture of an API server, according to an example embodiment of the present invention. -
FIG. 7 is a block diagram illustrating structural details of example request and response messages. -
FIG. 8 is flowchart of a method, according to an example embodiment of the invention, of performing version management between a client application and an API. -
FIG. 9 is a block diagram illustrating communication between a commerce server system and a third-party system where client applications on the third-party system use schema definitions. -
FIG. 10 shows example schema definitions of a current database schema provided at a commerce server system. -
FIG. 11 shows example definitions of outdated schema definitions provided at the third-party system. -
FIG. 12 shows an example dictionary module to track changes in schema definitions at a server system. -
FIG. 13 shows a flowchart of an example method, in accordance with an embodiment of the invention, for processing a request from a third-party application having outdated schema definitions. -
FIG. 14 is a block diagram representation of a machine, in the example form of a computer system, within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein may be executed. -
FIG. 15 is a schematic block diagram of a system, in accordance with an example embodiment of the invention, for automatically updating a client application. -
FIG. 16 is a schematic flow diagram of a method, in accordance with an example embodiment of the invention, for automatically updating a client application. -
FIGS. 17-19 show examples of more detailed functionality performed by the method ofFIG. 16 . - A system and method of accommodating at least one difference between a first database schema and a second database schema is provided. The method may include receiving a request from a first application program that is operationally dependent upon the first database schema, the request being received at a second application program that is operationally dependent upon the second database schema. The method includes identifying if there is a difference between the first database schema and the second database schema. When there is a difference, the method includes identifying the difference between the first database schema and the second database schema to identify at least one different schema definition element; associating the different schema definition element with a reserved element, the reserved element having a corresponding reserved element provided in the first database schema; and communicating a response to the first application program including the reserved element.
- In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details.
- An example embodiment of the present invention is discussed below within the context of a network-based commerce system that supports a network-based, electronic marketplace. Buyers and sellers, utilizing buyer and seller applications, as well as third-party business service providers, interact utilizing the electronic marketplace as a forum. Business processes may be driven by a wider range of electronic marketplace operational considerations, so as to enable buyers and sellers to conduct transactions utilizing the electronic marketplace. In one embodiment of the present invention, a server at the network-based commerce system transforms data into a modified format prior to communicating a response to a third-party system when the third-party system has an outdated version of the schema definitions. Accordingly, the network-based commerce system can still support third-party applications even though the schema definitions at the network-based commerce facility have changed.
- In one example embodiment, message exchanges comply with a business language schema component model. The business language schema design framework allows an electronic marketplace server system (e.g., the commerce system) to support a wide range of commerce transactions, including auction, fixed price buying and selling, product catalogs searches and payments. These transactions provide examples of communications between buying and selling applications via the electronic marketplace, as well as communications with other third-party business service providers.
- In an example embodiment, there is provided a schema component model that provides an abstract definition of the business message payloads. Payloads may be defined in a way to support extensibility which enables other types of commerce transactions models to be made available via the marketplace (e.g., for electronic procurement, reverse auctioning, credit check, and shipment/logistic activities).
- The business language schema may catalog common business message components that may be utilized for any number of business communications facilitated by an electronic marketplace (e.g., auction, fixed price buying and selling, product catalog search, catalog-based listings, and electronic payment in support of item purchases). The business language schema, in one embodiment, enables a wide range of business applications to interoperate with XML web services APIs, and externally located and internally hosted clients.
- Request/response message payload components may be defined by the business language schema which can be utilized to enable the building of a range of messages that may flow back and forth from buyers, sellers and third-party business service providers to marketplace XML web services, these web services enabling trading parties to list, find, and sell items and services.
- In various example embodiments, message exchanges may be made, utilizing the business-language based message exchange model of an example embodiment of the present invention, with both external and internal business applications over synchronous communication and asynchronous communication links. Further, document-oriented synchronous messaging, as well as document-oriented asynchronous messaging, may be supported. As will be described in further detail below, a message packaging format may be a flavor of the XML messaging format (e.g., SOAP 1.1, SOAP 1.2, ebXML, or an e-mail format such as MIME or any other arbitrary message packaging format). Further, transport protocols used may include HTTP, HTTPS, SMTP, or some other arbitrary transport protocol needed for particular business applications hosted remotely at a trading entity that requires moving data.
- A schema design framework for a host language in the example form of a business language is provided to support message payload definitions for a multitude of use cases and for use with a multitude of APIs. This may be accomplished via an extensibility model that includes base components, and business message components that support new transaction models and messaging components. Specifically, the base components may provide a definition of basic core component types, basic components and aggregate components, including an abstract messaging framework. The business message components are based on the business information requirements for a particular use case.
- Regarding the business messaging components, based on the business information requirements of a particular use case, the definitions of the basic set of messaging components are needed for a legacy transaction model can be supported utilizing the above mentioned base components in support of business message components. In one example embodiment, the business language components for use in an electronic trading environment, such as that described below with respect to
FIG. 1 , may include: item, item transaction, shipping details, payment, address, user, buyer, seller and payment and transaction components. - It will be appreciated that, over the course of time, many new types of business processes may be employed by a trading community (e.g., buyers, sellers and third-party service providers) that utilize an electronic marketplace and accordingly that interface with services exposed by the electronic marketplace. Such new types of applications may exploit different types of transaction interfaces (e.g., APIs) exposed by an electronic marketplace. In one example embodiment, an abstract message payload framework is provided that can be extended for many different types of messages and over different protocols, as may be required. However, it should be appreciated that the present invention is not limited to this framework and may use any other host language.
- In an example embodiment, when a commerce system receives a request from a third-party system, a response message is sent to the third-party system including instances of specific enumerated code types or placeholders (custom slots) for an element that has been added in an updated schema definition but which are not present in an outdated schema definition on the third-party system. This indicates that the API has defined new, additional enumerated codes that may not be understood and correctly processed by a client application on the third-party system. An update to the schema definition(s) may, for example, be an updated XML schema definition for the targeted API. The specific enumerated code type or “CustomCode” element (also referred to herein as a reserved element or default element) being returned in such scenarios may prevent the client application from experiencing a communication breakdown with the API, due to incremental schema changes and evolutions that may occur as part of the commerce system. It will be appreciated that the example CustomCode could be used with any host language. However, by way of example, the CustomCode is described with reference to the example business language described below. In this example, embodiment, the CustomCode is included within a payload but, in other embodiments, the CustomCode may be included in any manner within a response sent from a server system to a client system e.g., a response based on Web Services Description Language (WSDL) .
- Core Component Type (CCT): a core component type is, in one embodiment, a low level construct that may have no meaning on its own. A core component type has a content component and additional components (e.g., mandatory or optional) which give it a specific meaning. An example of a core component type is an “amount”, where the content part is a number (e.g., 87) and another required part is a unit (e.g., a Euro).
- Basic core components: a basic core component represents, in the example embodiment, a core business concept (e.g., a unique business semantic definition). This may be accomplished by employing a core component type (CCT) or a primitive data type (e.g., XSD data types) to which some other semantically unique object (e.g., a “weight” element is an instance of the core component type CCT Measure Type).
- Aggregate core components: aggregate core components, in one example embodiment, encapsulate two or more basic core components which represent higher-level business concepts (e.g., “shipping address” is an instance of Address Type). Each aggregate core component may have its own business semantic definition.
- Having above provided a high level introduction, a more detailed description of an example trading system, centered around a network-based commerce system, will now be described with reference to
FIGS. 1-3 . -
FIG. 1 is a network diagram depicting atrading environment 10, according to one example embodiment of the present invention, having a client-server architecture. A commerce server system, in the example form of a network-basedcommerce system 12, provides server-side functionality, via a network 14 (e.g., the Internet) to one or more clients.FIG. 1 illustrates, for example, a web client 16 (e.g., a browser, such as the Internet Explorer browser developed by Microsoft Corporation of Redmond, Washington State), and aprogrammatic client 18 executing onrespective client machines 20 and 22. - Turning specifically to the network-based
commerce system 12, an Application Program Interface (API) server 24 and a web server 26 are coupled to, and provide programmatic and web interfaces respectively to, one ormore application servers 28. Specifically, the API server 24 exposes multiple APIs to users of thecommerce system 12. Each of these APIs supports one or more function calls to applications of thesystem 12. Each of these APIs may have a associated API schema definitions. - The
application servers 28 host one ormore marketplace applications 30 and payment applications 32. Theapplication servers 28 are, in turn, shown to be coupled to one ormore databases servers 34 that facilitate access to one ormore databases 36. - The
marketplace applications 30 provide a number of marketplace functions and services to users that access thecommerce system 12. The payment applications 32 likewise provide a number of payment services and functions to users. Thepayment applications 30 may allow users to quantify for, and accumulate, value (e.g., in a commercial currency, such as the U.S. dollar, or a proprietary currency, such as “points”) in accounts, and then later to redeem the accumulated value for products (e.g., goods or services) that are made available via themarketplace applications 30. While the marketplace andpayment applications 30 and 32 are shown inFIG. 1 to both form part of the network-basedcommerce system 12, it will be appreciated that, in alternative embodiments of the present invention, the payment applications 32 may form part of a payment service that is separate and distinct from thecommerce system 12. - Further, while the
trading environment 10 shown inFIG. 1 employs a client-server architecture, the present invention is of course not limited to such an architecture, and could equally well find application in a distributed, or peer-to-peer, system. The various marketplace andpayment applications 30 and 32 could also be implemented as standalone software programs, which do not necessarily have networking capabilities. - The
web client 16, it will be appreciated, accesses the various marketplace andpayment applications 30 and 32 via the web interface supported by the web server 26. Similarly, theprogrammatic client 18 accesses the various services and functions provided by the marketplace andpayment applications 30 and 32 via the programmatic interface provided by the API server 24. Theprogrammatic client 18 may, for example, be a seller application (e.g., the TurboLister application developed by network-basedcommerce system 12 Inc., of San Jose, Calif.) to enable sellers to author and manage listings on thecommerce system 12 in an off-line manner, and to perform batch-mode communications between theprogrammatic client 18 and the network-basedcommerce system 12. As described in more detail below, such a programmatic client may operate in conjunction with locally stored schema definitions that theprogrammatic client 18 has previously received from the network-basedcommerce system 12. In one embodiment, out of date schema definitions on the programmatic client may be accommodated by the network-basedcommerce system 12 without affecting the operability of theprogrammatic client 18. -
FIG. 1 also illustrates a third-party application 38, executing on a third-party server machine 40, as having programmatic access to the network-basedcommerce system 12 via the programmatic interfaces provided by the API server 24. For example, the third-party application 38 may, utilizing information retrieved from the network-basedcommerce system 12, support one or more features or functions on a website hosted by the third-party. The third-party website may, for example, provide one or more promotional, marketplace or payment functions that are supported by the relevant applications of the network-basedcommerce system 12. -
FIG. 2 is a block diagram illustrating multiple marketplace andpayment applications 30 that, in one example embodiment of the present invention, are provided as part of the network-basedcommerce system 12. Thecommerce system 12 may provide a number of listing and price-setting mechanisms whereby a seller may list goods or services for sale, a buyer can express interest in or indicate a desire to purchase such goods or services, and a price can be set for a transaction pertaining to the goods or services. To this end, themarketplace applications 30 are shown to include one ormore auction applications 44 which support auction-format listing and price setting mechanisms (e.g., English, Dutch, Vickrey, Chinese, Double, Reverse auctions etc.). Thevarious auction applications 44 may also provide a number of features in support of such auction-format listings, such as a reserve price feature whereby a seller may specify a reserve price in connection with a listing and a proxy-bidding feature whereby a bidder may invoke automated proxy bidding. - A number of fixed-
price applications 46 support fixed-price listing formats (e.g., the traditional classified advertisement-type listing or a catalogue listing) and buyout-type listings. Specifically, buyout-type listings (e.g., including the Buy-It-Now (BIN) technology developed by network-basedcommerce system 12 Inc., of San Jose, Calif.) may be offered in conjunction with an auction-format listing, and allow a buyer to purchase goods or services, which are also being offered for sale via an auction, for a fixed-price that is typically higher than the starting price of the auction. -
Store applications 48 allow sellers to group their listings within a “virtual” store, which may be branded and otherwise personalized by and for the sellers. Such a virtual store may also offer promotions, incentives and features that are specific and personalized to a relevant seller. - Reputation applications 50 allow parties that transact utilizing the network-based
commerce system 12 to establish, build and maintain reputations, which may be made available and published to potential trading partners. Consider that where, for example, the network-basedcommerce system 12 supports person-to-person trading, users may have no history or other reference information whereby the trustworthiness and credibility of potential trading partners may be assessed. The reputation applications 50 allow a user, for example through feedback provided by other transaction partners, to establish a reputation within the network-basedcommerce system 12 over time. Other potential trading partners may then reference such a reputation for the purposes of assessing credibility and trustworthiness. -
Personalization applications 52 allow users of thecommerce system 12 to personalize various aspects of their interactions with thecommerce system 12. For example a user may, utilizing anappropriate personalization application 52, create a personalized reference page at which information regarding transactions to which the user is (or has been) a party may be viewed. Further, apersonalization application 52 may enable a user to personalize listings and other aspects of their interactions with thecommerce system 12 and other parties. - In one embodiment, the network-based
commerce system 12 may support a number of marketplaces that are customized, for example, for specific geographic regions. A version of thecommerce system 12 may be customized for the United Kingdom, whereas another version of thecommerce system 12 may be customized for the United States. Each of these versions may operate as an independent marketplace, or may be customized (or internationalized) presentations of a common underlying marketplace. - Navigation of the network based-
commerce system 12 may be facilitated by one ormore navigation applications 56. For example, a search application enables key word searches of listings published via thecommerce system 12. A browse application allows users to browse various category, catalogue, or inventory data structures according to which listings may be classified within thecommerce system 12. Various other navigation applications may be provided to supplement the search and browsing applications. - In order to make listings, available via the network-based
commerce system 12, as visually informing and attractive as possible, themarketplace applications 30 may include one or more imaging applications 58 utilizing which users may upload images for inclusion within listings. An imaging application 58 also operates to incorporate images within viewed listings. The imaging applications 58 may also support one or more promotional features, such as image galleries that are presented to potential buyers. For example, sellers may pay an additional fee to have an image included within a gallery of images for promoted items. -
Listing creation applications 60 allow sellers conveniently to author listings pertaining to goods or services that they wish to transact via thecommerce system 12, andlisting management applications 62 allow sellers to manage such listings. Specifically, where a particular seller has authored and/or published a large number of listings, the management of such listings may present a challenge. Thelisting management applications 62 provide a number of features (e.g., auto-relisting, inventory level monitors, etc.) to assist the seller in managing such listings. One or morepost-listing management applications 64 also assist sellers with a number of activities that typically occur post-listing. For example, upon completion of an auction facilitated by one ormore auction applications 44, a seller may wish to leave feedback regarding a particular buyer. To this end, apost-listing management application 64 may provide an interface to one or more reputation applications 50, so as to allow the seller conveniently to provide feedback regarding multiple buyers to the reputation applications 50. -
Dispute resolution applications 66 provide mechanisms whereby disputes arising between transacting parties may be resolved. For example, thedispute resolution applications 66 may provide guided procedures whereby the parties are guided through a number of steps in an attempt to settle a dispute. In the event that the dispute cannot be settled via the guided procedures, the dispute may be escalated to a third-party mediator or arbitrator. - A number of
fraud prevention applications 68 implement various fraud detection and prevention mechanisms to reduce the occurrence of fraud within thecommerce system 12. -
Messaging applications 70 are responsible for the generation and delivery of messages to users of the network-basedcommerce system 12, such messages for example advising users regarding the status of listings at the commerce system 12 (e.g., providing “outbid” notices to bidders during an auction process or to provide promotional and merchandising information to users). -
Merchandising applications 72 support various merchandising functions that are made available to sellers to enable sellers to increase sales via thecommerce system 12. The merchandising applications 80 also operate the various merchandising features that may be invoked by sellers, and may monitor and track the success of merchandising strategies employed by sellers. - The network-based
commerce system 12 itself, or one or more parties that transact via thecommerce system 12, may operate loyalty programs that are supported by one or more loyalty/promotions applications 74 . For example, a buyer may earn loyalty or promotions points for each transaction established and/or concluded with a particular seller, and be offered a reward for which accumulated loyalty points can be redeemed. -
FIG. 3 is a high-level entity-relationship diagram, illustrating various tables 90 that may be maintained within thedatabases 36, and that are utilized by and support the marketplace andpayment applications 30 and 32. A user table 92 contains a record for each registered user of the network-basedcommerce system 12, and may include identifier, address and financial instrument information pertaining to each such registered user. A user may, it will be appreciated, operate as a seller, a buyer, or both, within the network-basedcommerce system 12. In one example embodiment of the present invention, a buyer may be a user that has accumulated value (e.g., commercial or proprietary currency), and is then able to exchange the accumulated value for items that are offered for sale by the network-basedcommerce system 12. - The tables 90 also include an items table 94 in which are maintained item records for goods and services that are available to be, or have been, transacted via the
commerce system 12. Each item record within the items table 94 may furthermore be linked to one or more user records within the user table 92, so as to associate a seller and one or more actual or potential buyers with each item record. - A transaction table 96 contains a record for each transaction (e.g., a purchase transaction) pertaining to items for which records exist within the items table 94.
- An order table 98 is populated with order records, each order record being associated with an order. Each order, in turn, may be with respect to one or more transactions for which records exist within the transactions table 96.
- Bid records within a bids table 100 each relate to a bid received at the network-based
commerce system 12 in connection with an auction-format listing supported by anauction application 44. A feedback table 102 is utilized by one or more reputation applications 50, in one example embodiment, to construct and maintain reputation information concerning users. A history table 104 maintains a history of transactions to which a user has been a party. One or more attributes tables 106 record attribute information pertaining to items for which records exist within the items table 94. Considering only a single example of such an attribute, the attributes tables 106 may indicate a currency attribute associated with a particular item, the currency attribute identifying the currency of a price for the relevant item as specified in by a seller. - Having above described an
example trading environment 10, within which an example embodiment of the present invention maybe deployed, further details regarding a method and system to accommodate different or outdated schema definitions, according to an example embodiment of the present invention, (e.g., for message exchanges within the trading environment 10) are now described.FIG. 4 is block diagram illustrating a client-server architecture that may be deployed, for example, as part of thetrading environment 10 described above with reference toFIG. 1 . Referring specifically toFIG. 4 , request/response messages 120 may be sent between one of N third-party systems, such as third-party system 122, and aserver system 125 that is accessed via a number of APIs exposed by respective API servers 24. - Thus, in broad terms, the third-
party system 122, using theclient application 124, compiles a request message, which is directed to an API 126 (e.g., Addltem, GetItemTransaction, etc.) of theserver system 125. EachAPI 126 in turn provides access through supported function calls to one of a plurality of applications, indicated generally byarrow 128, that have access to adatabase 130. - Turning now to
FIG. 5 , further details regarding theexample client application 124, hosted on a third-party system 122, are shown. Theclient application 124 includes a request/response message (e.g., an abstract request/response message)process component 136 for processing the request/response messages 120 shown inFIG. 4 . In particular, the example abstract request/responsemessage process component 136 comprises anError Processor 138 and aVersion Processor 140. The client application 134 further comprises an API-specific component 142 that includesXML schema definitions client application 124 is configured to communicate (e.g., API_0 and API _1 shown inFIG. 4 ). A number of possible front end transport technologies, such as SOAP, MIME and HTTP, are shown to be supported by a transport handler 13. Over time theXML schema definitions server system 125 due to updates/modifications that may take place to schema definitions at theserver system 125. For example, new operations and/or data elements may be added to the schema definition(s). However, as described in more detail below, such variations between the client-side and server-side schema definitions may be accommodated so that the client-side components (e.g., API-specific component 142) are still be operable. - The
client application 124 is also shown by way of example to include amessage handler 145, and a serialization/deserialization handler 147, in addition to the APIspecific component 142. Specifically, each third-party system 122 may host aclient application 124, which can exploit the abstract request/response message via any one of the following processing components: -
- i) A
transport handler 143 which supports the communication protocol e.g., HTTP, HTTPS, SMTP, etc; - ii) A
message handler 145 which supports the message envelope processing capabilities. e.g., HTTP, POST Raw Data stream, SOAP, MIME, etc.; - iii) Abstract request serialization and response deserialization
handler 147; and - iv) Client-side API
specific components 142.
- i) A
- The
transport handler 143 and the message handler can be formed from any standard, commercially available Software Development Kit (SDK) to which a third-party has access in its development and runtime deployment environments. - The abstract request serialization and response deserialization handler 137 can be developed for
client applications 124 once, and reused multiple times, thus reducing the cost of interfacing and also providing consistent interfacing with API-based application services exposed by thecommerce system 12 over a wide range of transport and messaging particles. Such a “write once and, use multiple times” deployment is useful for trading communities, regardless of use case and other infrastructure components in support of transport, security and messaging protocols. - Turning now to
FIG. 6 , at the server side, anexample API Server 148 comprises a frontend Presentation tier 150, which receives request messages and sends response messages, aBusiness tier 152 and aData components tier 154. TheBusiness tier 152 includes components corresponding to the various APIs, indicated generally byarrow 156. - The structure of example abstract request and
response messages FIG. 7 . Referring first to theabstract request message 158, an exampleabstract request message 158 comprises aDetail Level component 160 and an associatedDetailCodeType 162. This advantageously allows theclient application 124 to request a required level of detail within a listing, for example, relating to a particular item listed on thecommerce system 12. The level of detail requested may range from a most detailed to a least detailed level. Theabstract request message 158 further comprises anError Language component 164 and an associatedLanguage Identification Tag 166, and aVersion_ID component 168 and an associatedVersion Identifier 170. Theabstract request message 158 is then completed by providing aRequest Payload component 172, for carrying any type ofXML data 174. - An example
abstract response message 176 includes aTime Stamp component 178 and an associatedDateTime 180, and anAcknowledgement component 182 and an associatedAckCodeType 184. These components are used to acknowledge receipt of a request message of the received from aclient application 124. - The
abstract response message 176 further includes aCorrelation_ID component 186 and associatedString Identifier 188, an Error(s)Data component 190 and associateddata 192, aVersion_ID 193, aBuild component 194 and aResponse Payload component 196 for receiving any type ofXML data 198. - The
Correlation_ID component 186 and associatedString Identifier 188 allow theabstract response message 176 to be correlated with a particularincoming request message 158, and to indicate this correlation to the requestingclient application 124. - Thus, in one example embodiment, there is some commonality in the abstract request and
abstract response messages - The
Error Language component 164 and the Error Data(s)component 190 ensure that the API request/response messages consistently use, manage and communicate error components. Part of this is the ability to communicate versioning information identifying what version of an API a particular API server 24 is using to communicate with aclient application 124 of a third-party system 122 (e.g., a client 20 and 22). Thus, for example, if a third-party system 122 sends a request message that includes incorrect data or that does not comply with the published requirements of a target API, the Error(s)Data component 190 may be used by the target API to communicate information regarding the error back to theclient application 124. Thus, in an example embodiment, when an error is detected, a response message may be generated by the relevant API, this response message being either a long message or a short message, and including an error code and associated severity code. This response message is sent to therelevant client application 124, thereby informing theclient application 124 as to the nature of the error. - Regarding the version of the API that the API server 24 is using, versioning information may be included in both a request message from a
client application 124 to the API server 24, as well as a response message from the API server 24 back to theclient application 124. This is indicated schematically byblocks FIG. 7 . Thus, in an example embodiment, the respective version components in the request and response messages indicate a particular version of the API on the API server 24. In so doing, and in view of the fact that the API version used by the API server 24 typically changes, theclient application 124 will have a way of detecting when it needs to upgrade the schema that it uses to format and generate request messages to the relevant. Further, in one embodiment of the invention, theserver system 125 may detect from the version identification (Version_ID—see block 168) received from theclient application 124 that theXML schema definitions server system 125. As discussed in more detail below, theserver 125 may then process or transform data from based on the current schema definition so that a response to theclient application 124 does not render theclient application 124 inoperable. - In one embodiment, the host language includes the example request and response message structures. The abstract request and response models can be extended to enable API requests and responses between a third-
party system 122 and any number of APIs provided by one or more API servers 24. For example, a particular server system may expose a number of APIs, each conforming to the basic request/response messages described above. Thus, for example, the basic request/response messages can be extended to enable an AddItem API, or a GetItem API, or a GetAccount API. Thus, for example, for a third-party system wishing to exchange item information with thecommerce system 12, the basic abstract request message may be extended with the addition of information conforming to a schema understood by a GetItem API. It will however be appreciated that the present invention is not limited to this message structure. In other words, this example arrangement allows a third-party system 122, hosting an appropriately configuredclient application 124, to communicate with multiple - APIs with a degree of uniformity and predictability. In one embodiment, a uniform data processing model is utilized and supported by a number of APIs, thereby allowing developers of client applications to reuse parts of their code.
- Dealing more specifically with the re-usability of the business language schema data components, in a specific example deployment environment of a
trading environment 10 such as that illustrated inFIG. 1 , schema components may be defined such that they can be reused for multiple cases of purchasing and selling items listed via the network-basedcommerce system 12. Examples of such reuse are provided below: - 1) Listing an item utilizing an AddItem API: a
client application 124 may be configured to list an item to be sold in specific regions of the world, and to recognize acceptable payment and shipment options for purchasing and shipping items in such a specific region. - 2) Revising and relisting an item utilizing ReviseItem and Relistltem APIs: a
client application 124 may be configured to enable the revision and relisting of existing items, such that the item properties are revised or a completely new listing for the item is created, should the item not previously have been sold. - 3) Getting information about an item utilizing GetItem, GetSellerList, or GetBidderList
- APIs: a
client application 124 may be configured to retrieve information about a particular item, or multiple items, that are actively listed via the network-basedcommerce system 12. - In all of the above use cases, the
client application 124 is required to send information back to a network-based commerce system 112 regarding items listed for sale via thecommerce system 12. This may require description of an <item> structure in a consistent manner such that theclient applications 122 from which the API calls originate understand the semantics of an item listed by a seller on thee-commerce system 12. However, since the context of each call from aclient application 124 is different in each use case scenario, a different degree of information needs to be provided such that some data components are included or excluded. Further, such functionality may be dependent upon the XML-schema definitions server system 125. - Utilizing the item listing use case scenario described above, the issues described above can be addressed utilizing (1) an <item> data component model, and (2) multiple data validation levels.
- Turning first to the <item>data component model, in terms of this model an “item” has required optional data components. These components internally also have child components that are required and optional components.
- Accordingly, a single item component definition may be used for multiple API use cases, with the developers and designers of the APIs being able to select which elements of the item component must be present and which elements of an item component do not need to be present.
- Turning now to the multiple data validation levels, when a
client application 124 sends an APIrequest message payload 172, an API processing payload may, in one embodiment, include the following sequence of validations: - (a) Schema Level Data Validation: the API
request message payload 172 is validated with respect to an underlying schema specific to the API message payload (e.g., utilizing the XML schema definition for the item data component). Using the CustomCode of one embodiment of the present invention changes in the schema definition may be accommodated. - (b) API Specific Syntactic Data validation: This involves additional data-level validation to ensure that the
client application 124 has sent required data elements that are specified in the XML schema definition to the option elements, but that are defined as required elements by the relevant API. - (c) Business Application Data Validation: This validation involves checking for a wide range of business application level validations.
- The above sequence of validations, it will be noted, utilizes a single definition of key business data components such that data variability in request/response messages can be supported in a controlled manner using the required validation logic for the business use case. For example, for the following three example APIs (GetItem, Getltem Transaction and SellerList), the same definition of an <item> business definition component can be used on the client side—yet the APIs will return response messages with varying API data structures. This enables uniformity in a semantic definition, yet allows the return of different views of the <item> business component according to use case.
- Accordingly, a server system (e.g., a network-based commerce system 12) that exposes multiple business application services can utilize these multiple exposed business applications in communicating with
multiple client applications 122 in a way that theclient applications 122 can understand and communicate. For example, information about an item with varying syntactic characteristics that correspond to an item is communicated (e.g., information about an item with varying syntactic characteristics that correspond to a data item component with a common semantic definition). The above contributes to the reusability of data components within, for example, a trading community with multiple use cases. - To develop a
client application 124 that communicates with multiple APIs, or to modify an existingclient application 124 to talk to multiple APIs, a developer downloads or imports XML, schema definitions for each of the multiple APIs. For example, for an example GetTransactionDetail API, the developer will need to import or download the corresponding schema for this API, and in particular the GetTransactionDetail request message as well as the GetTransactionDetail response message. Thereafter, theclient application 124 will need to integrate these schema processing components with their own (e.g., as part of the API specific component 142). However, as described in more detail below, the downloaded or imported schema definitions include CustomCode or reserved elements in the schema definition to accommodate changes in the schema definitions at the server system 135. - According to an example embodiment of the present invention, and as described in more detail below, when a data schema is generated for communication to the third-
party system 122, a forced or reserved element (CustomCode) is included in the schema definition. When the schema definition(s) at theserver system 125 subsequently change and the schema definition(s) at theserver system 125 and the third-party system are no longer identical, the forced element or CustomCode is used to replace additional elements that may have been include in the modified schema definition at theserver system 125. Thus, theserver system 125 uses the forced or reserved element when encountering a value that would violate the XML schema definition at the third-party system 122. Thus, in a response to a request from the third-party system 122, a default value or reserved element is provided as the enumerated code type in the response when the enumerated code type at theserver system 125 will not be understood by theclient application 124 using an outdated or different schema definition. - For example, after a schema definition has been communicated or published to one or more third-
party systems 122, improvements, changes, modifications (including additions and/or deletions) or the like may take place at theserver system 125 resulting in one or more new schema definition elements. Thus, in one month, an original XML schema definition may define 7, 10, 14 and 21 day duration values, but the next month, the updated up XML schema definition may be updated to remove the duration value of 21 days, or add a duration value of 28 days. When a further element is added to the schema definitions at the server system 125 (e.g., the addition of the 28 day value), if theAPI 126 at theserver system 125, utilizing the current XML schema including updates, attempted to provide the 28 day duration value to the third-party system 122, theclient application 124 may see this as a violation as the value is not provided in any of the schema definitions originally provided at the third-party system 122. Likewise, when the example duration value of 21 days is removed, if theclient application 124, utilizing the original XML provided to the third-party system 122, attempts to provide the 21 day duration value against an updated API at theserver system 125, this may be registered as a violation. To address this, a forced element or reserved element, which can carry any value, may be inserted into the request and/or response (e.g., intopayload 196 of aresponse message 176 in one example embodiment). - In an example embodiment, an indication of a change in a schema definition element (or any other difference/change in the database schema) against the updated API of the
commerce system 12 will be accepted, but the updated API may issue a warning to therelevant client application 124 that it needs to upgrade the relevant XML schema. When, theserver system 125 identifies that a version of the schema definition(s) on the third-party system 122 is outdated, it may use a forced element or CustomCode to allow backwards compatibility of the outdated schema definition(s). Thus, in an example embodiment, the default value or CustomCode is only inserted by the API server into the response message when the server detects that the client is using an outdated version of the schema definition. -
FIG. 8 is a flowchart illustrating amethod 250, according to an example embodiment of the present invention, of performing version management between aclient application 124 and an API, for example implemented by thecommerce system 12. Themethod 250 illustrates how the API of thecommerce system 12 leverages a schema definition including reserved or forced elements to communicate back to aclient application 124 with client enumerated code types in a scenario in which theclient application 124 may not be synchronized with a latest version of an API adopted by thecommerce server 12. For example, as shown inFIG. 5 , XML-schema definitions server system 125. - The
method 250 commences atblock 252, with theclient application 124 including its version identifier (e.g., Version ID), identifying the version of an XML-schema definition stored by theclient application 124, within arequest message 158 addressed to aparticular target API 126. An example of theversion identifier 170 is provided below: - (Version xmlns=“URN: marketplace: APIs: BLBase Components” >383</Version >).
- In the above example version identifier “383” may represent a particular third-party in the form of a “site code” that identifies (optionally uniquely identifies) the version of a schema definition(s) at the site. The site code may also relate to a particular international site. The version information may, however, be a date that identifies when the version was released to the third-
party application 122, when the version was created at theserver system 125, or any other version identification detail. - At
block 254, anAPI 126 of theserver system 125 receives a message request (e.g., the request message 158) from theclient application 124, and determines from the version identifier if theclient application 124 is utilizing a different and older version of an API schema or schema definitions supported by therelevant target API 126. - At
block 256, the targeted API may compose a response message 176 (e.g., including a response payload 196) and include within theresponse message 176 instances of specific enumerated code types for an element (e.g., <Site>CustomCode </Site>) provided in an updated schema definition at theserver system 125 but not at the third-party system 122. This indicates that the API has defined new, additional enumerated codes that may not be understood and correctly processed by theclient application 124, in view of its updated XML schema definition for the targeted API. The “CustomCode” or forced element being returned in such scenarios will prevent theclient application 124 from experiencing a communication breakdown with the API, due to incremental schema changes and evolutions that may occur as part of thecommerce system 12, for example, revising API-based application service offerings. - An enumerate code type examples follow hereunder:
- GetUser with version 383 returns SiteCode of China
- Example #1: API client has up-to-date version of API schema to communicate with XML Web Service APIs, e.g., GetUser API. Hence, the server system XML Web Service API returns the up-to-date enumeration code value (“China”) for the <Site>enumerated code element.
-
<?xml version=“1.0” encoding= “utf-16”?> <soap:Envelope xmlns:soap=“http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=“http://www.w3.org/2001/XMLSchema”> <soap:Header> <RequesterCredentials xmlns=“urn:marketplace:api:marketplaceAPI”> <Credentials xmlns=“urn:marketplace:apis:eBLBaseComponents”> <AppId>dbeek</AppId> <DevId>apiteam</DevId> <AuthCert>apiteamcert</AuthCert> <Username>soapuser</Username> <Password>password</Password> </Credentials> </RequesterCredentials> </soap:Header> <soap:Body> <GetUserRequest xmlns=“urn:marketplace:api:marketplaceAPI”> <MessageID xmlns=“urn:marketplace:apis:eBLBaseComponents”>00cccc08-9875- 43a0-97b8-8100a586af4f</MessageID> <Version xmlns=“urn:marketplace:apis:eBLBaseComponents”>383</Version> <EndUserIP xmlns=“urn:marketplace:apis:eBLBaseComponents”>10.254.45.68</EndUserIP> <UserID>beekde_cn</UserID> </GetUserRequest> </soap:Body> </soap:Envelope> <?xml version=“1.0” encoding= “utf-16”?> <soapenv:Envelope xmlns:soapenv=“http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsd=“http://www.w3.org/2001/XMLSchema” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”> <soapenv:Body> <GetUserResponse xmlns=“urn:marketplace:api:marketplaceAPI”> <ns1:Timestamp xmlns:ns1=“urn:marketplace:apis:eBLBaseComponents”>2004-11- 24T19:15:52.586Z</ns1:Timestamp> <ns2:Ack xmlns:ns2=“urn:marketplace:apis:eBLBaseComponents”>Success</ns2:Ack> <ns3:CorrelationID xmlns:ns3=“urn:marketplace:apis:eBLBaseComponents”>00cccc08-9875-43a0-97b8- 8100a586af4f </ns3:CorrelationID> <ns4:Version xmlns:ns4=“urn:marketplace:apis:eBLBaseComponents”>383</ns4:Versions> <ns5:Build xmlns:ns5=“urn:marketplace:apis:eBLBaseComponents”>20041119132302</ns5:Build> <ns6:User xmlns:ns6=“urn:marketplace:apis:eBLBaseComponents”> <ns6:AboutMePage>false</ns6:AboutMePage> <ns6:EIASToken>nY+sHZ2PrBmdj6wVnY+sEZ2PrA2dj6wJkoelD5KKpgydj6x9nY+seQ== </ns6:EIASToken> <ns6:Email>Invalid Request</ns6:Email> <ns6:FeedbackScore>1</ns6:FeedbackScore> <ns6:FeedbackRatingStar>None</ns6:FeedbackRatingStar> <ns6:IDVerified>false</ns6:IDVerified> <ns6:NewUser>true</ns6:NewUser> <ns6:RegistrationDate>2004-11-10T23:14:56.000Z</ns6:RegistrationDate> <ns6:Site>China</ns6:Site> <ns6:Status>Confirmed</ns6:Status> <ns6:UserID>beekde_cn</ns6:UserID> <ns6:UserIDChanged>false</ns6:UserIDChanged> <ns6:UserIDLastChanged>2004-11-10T23:14:56.000Z</ns6:UserIDLastChanged> <ns6:BuyerInfo/> <ns6:SellerInfo> <ns6:AllowPaymentEdit>false</ns6:AllowPaymentEdit> <ns6:CheckoutEnabled>true</ns6:CheckoutEnabled> <ns6:CIPBankAccountStored>false</ns6:CIPBankAccountStored> <ns6:GoodStanding>true</ns6:GoodStanding> <ns6:LiveAuctionAuthorized>false</ns6:LiveAuctionAuthorized> <ns6:MerchandizingPref>OptIn</ns6:MerchandizingPref> <ns6:QualifiesForB2BVAT>false</ns6:QualifiesForB2BVAT> <ns6:SellerGuaranteeLevel>NotEligible</ns6:SellerGuaranteeLevel> <ns6:SellerLevel>None</ns6:SellerLevel> <ns6:SchedulingInfo> <ns6:MaxScheduledMinutes>30240</ns6:MaxScheduledMinutes> <ns6:MinScheduledMinutes>0</ns6:MinScheduledMinutes> <ns6:MaxScheduledItems>1000</ns6:MaxScheduledItems> </ns6:SchedulingInfo> <ns6:StoreOwner>false</ns6:StoreOwner> </ns6:SellerInfo> </ns6:User> </GetUserResponse> </soapenv:Body> </soapenv:Envelope> - Example #2: API client does not have [PLEASE CONFIRM] up-to-date version of an API schema (as specified in <Version> sub-element in GetUserRequest message below) to communicate with XML Web Service APIs: GetUser API. Hence, XML Web Service API returns in response message:
- (a) the default enumeration code value (“CustomCode”) for the <Site> enumerated code element; and, optionally,
- (b) the <Errors> sub-element also includes information to indicate to client that client's version of API schema is out of date:
-
<Errors> <ShortMessage>Warning. Client schema out of date. <ShortMessage> <LongMessage>Warning. Client schema out of date. Client Schema Version: 361. Latest Schema Version: 347. LongMessage> GetUser using 361 Version <?xml version=“1.0” encoding=“utf-16”?> <soap:Envelope xmlns:soap=“http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=“http://www.w3.org/2001/XMLSchema”> <soap:Header> <RequesterCredentials xmlns=“urn:marketplace:api:marketplaceAPI”> <Credentials xmlns=“urn:marketplace:apis:eBLBaseComponents”> <AppId>dbeek</AppId> <DevId>apiteam</DevId> <AuthCert>apiteamcert</AuthCert> <Username>soapuser</Username> <Password>password</Password> </Credentials> </RequesterCredentials> </soap:Header> <soap:Body> <GetUserRequest xmlns=“urn:marketplace:api:marketplaceAPI”> <MessageID xmlns=“urn:marketplace:apis:eBLBaseComponents”>b54b5206-901c- 43ec-865f-86497e3bab5c</MessageID> <Version xmlns=“urn:marketplace:apis:eBLBaseComponents”>361</Version> <EndUserIP xmlns=“urn:marketplace:apis:eBLBaseComponents”>10.254.45.68</EndUserIP> <UserID>beekde_cn</UserID> </GetUserRequest> </soap:Body> </soap:Envelope> <?xml version=“1.0” encoding=“utf-16”?> <soapenv:Envelope xmlns:soapenv=“http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsd=“http://www.w3.org/2001/XMLSchema” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”> <soapenv:Body> <GetUserResponse xmlns=“urn:marketplace:api:marketplaceAPI”> <ns1:Timestamp xmlns:ns1=“urn:marketplace:apis:eBLBaseComponents”>2004-11- 24T19:16:41.445Z</ns1:Timestamp> <ns2:Ack xmlns:ns2=“urn:marketplace:apis:eBLBaseComponents”>Warning</ns2:Ack> <ns3:CorrelationID xmlns:ns3=“urn:marketplace:apis:eBLBaseComponents”>b54b5206-901c-43ec-865f- 86497e3bab5c </ns3:CorrelationID> <ns4:Errors xmlns:ns4=“urn:marketplace:apis:eBLBaseComponents”> <ns4:ShortMessage>Warning. Client schema out of date. </ns4 :ShortMessage> <ns4:LongMessage>Warning. Client schema out of date. Client Schema Version: 361. marketplace Latest Schema Version: 347. </ns4:LongMessage> <ns4:ErrorCode>14003</ns4:ErrorCode> <ns4:SeverityCode>Warning</ns4:SeverityCode> <ns4:ErrorParameters ParamID=“0”> <ns4:Value>361</ns4: Value> </ns4:ErrorParameters> <ns4:ErrorParameters ParamID=“1”> <ns4:Value>347</ns4:Value> </ns4:ErrorParameters> </ns4:Errors> <ns5:Version xmlns:ns5=“urn:marketplace:apis:eBLBaseComponents”>383</ns5:Version> <ns6:Build xmlns:ns6=“urn:marketplace:apis:eBLBaseComponents”>20041119132302</ns6:Build> <ns7:User xmlns:ns7=“urn:marketplace:apis:eBLBaseComponents”> <ns7:AboutMePage>false</ns7:AboutMePage> <ns7:EIASToken>nY+sHZ2PrBmdj6wVnY+sEZ2PrA2dj6wJkoelD5KKpgydj6x9nY+seQ== </ns7:EIASToken> <ns7:Email>Invalid Request</ns7:Email> <ns7:FeedbackScore>1</ns7:FeedbackScore> <ns7:FeedbackRatingStar>None</ns7:FeedbackRatingStar> <ns7:IDVerified>false</ns7:IDVerified> <ns7:NewUser>true</ns7:NewUser> <ns7:RegistrationDate>2004-11-10T23:14:56.000Z</ns7:RegistrationDate> <ns7:Site>CustomCode</ns7:Site> <ns7:Status>Confirmed</ns7:Status> <ns7:UserID>beekde_cn</ns7:UserID> <ns7:UserIDChanged>false</ns7:UserIDChanged> <ns7:UserIDLastChanged>2004-11-10T23:14:56.000Z</ns7:UserIDLastChanged> <ns7:BuyerInfo /> <ns7:SellerInfo> <ns7:AllowPaymentEdit>false</ns7:AllowPaymentEdit> <ns7:CheckoutEnabled>true</ns7:CheckoutEnabled> <ns7:CIPBankAccountStored>false</ns7:CIPBankAccountStored> <ns7:GoodStanding>true</ns7:GoodStanding> <ns7:LiveAuctionAuthorized>false</ns7:LiveAuctionAuthorized> <ns7:MerchandizingPref>OptIn</ns7:MerchandizingPref> <ns7:QualifiesForB2BVAT>false</ns7:QualifiesForB2BVAT> <ns7:SellerGuaranteeLevel>NotEligible</ns7:SellerGuaranteeLevel> <ns7:SellerLevel>None</ns7:SellerLevel> <ns7:SchedulingInfo> <ns7:MaxScheduledMinutes>30240</ns7:MaxScheduledMinutes> <ns7:MinScheduledMinutes>0</ns7:MinScheduledMinutes> <ns7:MaxScheduledItems>1000</ns7:MaxScheduledItems> </ns7:SchedulingInfo> <ns7:StoreOwner>false</ns7:StoreOwner> </ns7:SellerInfo> </ns7:User> </GetUserResponse> </soapenv:Body> </soapenv:Envelope> - In the example provided above the response indicates to the
client application 124 that the version at the third-party 122 is out of date. However, it is to be appreciated that in an embodiment, theserver system 125 may merely include the CustomCode to accommodate one or more differences between the schema definitions at the third-party system 122 and theserver system 125. -
FIG. 9 shows an example embodiment of a system 260, in accordance with the invention, to accommodate at least one difference between a first database schema (e.g., schema definition(s)) and a second database schema (e.g., schema definition(s)). As described in more detail below, in an example embodiment, the system 260 allows a request to be received from a first application program (e.g., the client-side or client application 122) that is operationally dependent upon the first database schema (e.g., API-specific component 142). The request is received at a second application program (e.g., an APIs 126) that is operationally dependent upon the second database schema (e.g., a database schema definition associated with the API). A processing or transform module 131 (or any other module at the server system 125) may identify if there is a difference between the first database schema and the second database schema. If no difference is identified or detected, the server system may process the request in a regular fashion. However, when a difference is detected, the transform module may identify the difference between the first database schema and the second database schema to determine at least one different schema definition element. The different schema definition element (e.g., the addition of a new payment method as described by way of example below) may then associate the different schema definition element with a reserved element or CustomCode. The default element or CustomCode corresponds to a placeholder or custom slot that is included when the first database schema was originally generated. Theserver system 125 then communicates a response to the third-party application including the reserved element so that operation of theclient application 124 is not impeded by a definition element unknown to it. - In an example embodiment of the system in
FIG. 9 , Web Services Description Language (WSDL) is used. WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate and the WSDL in may be used conjunction with SOAP 1.1, HTTP GET/POST, MIME, or the like. As can be seen inFIG. 9 , the schema definition(s) at theserver system 125 include updates wherein changes are documented or identifiable, and the third-party system 122 includes aschema definition 142 as originally provided to the third-party system 122 (or the last updated version of the schema definition(s) provided to the third-party system 122). -
FIG. 10 shows an example schema definition at the server system 125 (e.g., stored in thedataset 130. The definition file may be operatively associated with any host programming language. In one example embodiment, the host programming language is a business language. Further, the schema definition 270 is an updated definition to that which currently resides on the third-party application. An example of the client-side schema definition 280 is shown inFIG. 11 . Theschema definition 280 may, for example, correspond to a XML-schema definition 144, 146 (seeFIG. 5 ). Theschema definition 280 is shown, by way of example, to includeoperation components 282,data types 284 and a definition 286 (defining a dictionary). It will be noted that the schema definition 270 includes correspondingoperation components 282,data types 284 anddefinition 286. At the time of generating the schema definition for theclient application 124, a custom slot or placeholder or is included in theschema definition 280 and then provided or published to one or more third-party systems 122. Thecustom slot 288 allows theserver system 125 to modify its schema definition and yet still allow communication of responses to the third-party application 122 that theclient application 124 may process despite the differences in the schema definitions. Thus, for example, in the networked-basedcommerce system 12, WSDL-based calls/requests made by applications to the network-basedcommerce system 12 using an old version of a web service may still be processed by mapping or transforming them to one or more new versions. - In order to illustrate functionality in an exemplary embodiment, assume that the network-based
commerce system 12 at the time of generating the API-specific components 142 supported two payment methods shown by way of example to beVisa 288 andMasterCard 290. The definitions 286 (or dictionary generated from the definitions) that are provided at this point in time would then have definitions for these two payment methods. At this point in time, theschema definition 129 at theserver system 125 would correspond with theschema definitions 142 144, 146 provided at the third-party system 122. Anyclient application 124 operably dependent upon theschema definition server system 125 as the schema definitions correspond. In these circumstances, enumerated values or input values which are allowed in a system would be unchanged. - However, assume that the network-based
commerce system 12 adds a further payment method such as American Express orAmex 292 and, as a result thereof, a new or updated schema definition 270 is generated. The third-party system 124 may however still have the previous (old) version of the schema definition. As the server version of the schema definition 129 (seeFIG. 9 ) is now different from the client version of theschema definition server system 125 may remove theVisa 288 payment method. These changes can however be accommodated by the present invention without rendering theclient application 124 inoperable. As shown inFIG. 11 , a custom or default slot may be created for one or more dictionary types (e.g., payment type, country, or any other definition), operation types, or data types. -
FIG. 13 shows a flowchart of anexample method 300, in accordance with an embodiment of the invention, of accommodating at least one difference between a first database schema and a second database schema. Themethod 300 is described by way of example with reference to thetrading environment 10. - As shown at
block 302, one of theAPIs 126 of theserver system 125 receives a request from theclient application 124 which identifies what version of a particular XML schema definition associated with theAPI 126 is resident on the third-party system 122. Thereafter, as shown atblock 304 various business processing tasks may be performed. For example, checks may be performed to determine if the request came from a valid user; whether the request is appropriately formatted and other data checking procedures may be performed. If the request is not a valid request (see decision block 306), an error message may be returned to the third-party system 122 as shown atblock 308. - Returning to decision block 306, if the request is a valid request, the request is then processed to determine if data requested and retrieved from a database (e.g., the database 130) needs to be transformed or changed as a result of differences between the API-specific components 142 (e.g., the
schema definitions 144, 146) and theschema definition 129. In an embodiment, therelevant application 128 performs the necessary database calls required to process the request (see block 308). Thereafter, the client version of theschema definitions 144, 146 (which ever is appropriate for the selected API) is compared to the current version of the schema definitions resident at theserver system 125 as shown atblock 310. Definitions or a dictionary corresponding to those present at theclient application 124 may be retrieved atblock 312. Accordingly, differences between the current schema definition at theserver system 125 and the schema definition at the third-party system 122 may be identified or determined. Thereafter, as shown atblock 314, the schema definition in thecurrent schema definition 129 is transformed to a schema definition corresponding to that at the third-party system 122. Data returned from the various database calls is transformed (see block 316) into a format corresponding to theschema definitions schema definitions 142. - As shown by way of example in
FIG. 12 , a map or record may be kept at the backend of thesystem 125 whenever the schema definition or dictionary is changed, for example, when the newpayment method Amex 292 was introduced. In the example shown the update is in the form of an addition to adictionary 286, however, any changes to thedefinitions 280 may be accommodated using the CustomCode or default element technique. -
FIG. 12 shows exemplary modules used by thetrading environment 10 that allow application functionality based on client-side and server-side schema definitions. Theserver system 125 is shown by way of example to include adefinition module 320 to create a schema definition for distribution or publication to at least one third-party system 122, as shown byarrow 324. Each time thedefinition module 320 creates a new or updated schema definition a dictionary module table 326 is updated. It is, however, to be appreciated that the third-party system 122 may not be updated each time a new schema definition is created. For example, the networked-basedcommerce system 12 may have an agreement with a third-party system 122 to support communication between theserver system 125 and the third-party system 122 for a given duration (e.g., a year or several of years). In these circumstances, as the third-party system 122 may be guaranteed error free interoperability with theserver system 125, and a third-party may write specific client applications (e.g., the client application 124) that rely on theschema definitions 142. Thespecific client applications 124 may fail if responses received from theserver system 125 are based on a different schema definition. In an embodiment, from the networked-based commerce systems' 12 perspective, dictionaries may be created from definition modules. The first step in creating theschema definition 270, 280 may be a definition step followed by a dictionary creation step. This may be done for eachAPI 126. Whenever a dictionary is updated it may be dated as shown in theversion column 332 of the dictionary module table 326. - The dictionary module table 326 is shown by way of example to include a word column/
attribute 328, a database value column/attribute 330, and a version column/attribute 332. The dictionary module table 326 may track software changes at the network-basedcommerce system 12. Accordingly, using the dictionary module table 326 differences between a version of a schema definition resident on a third-party system 122 and on a network-basedcommerce system 12 may be determined or identified. In one embodiment, any additional language terms, definitions or the like are communicated as CustomCode or a reserved element. - It will be appreciated that further definition elements may be added to the schema definition 270 at the
server system 125. For example, a further payment type “Discover” may be added (not shown) to thedefinitions 286. Thus, in the given example, the definitions would compriseVisa 288,Mastercard 290,Amex 292 and Discover (not shown). Assuming that bothAmex 290 and were added to the schema definition 270, the version number of theschema definition 280 at theclient application 122 may only accommodate three payment methods (Visa 288,Mastercard 290, and Custom slot or CustomCode 288). In these circumstances, thetransform module 131 may transform a response from thedatabase 130 using the current version of the schema definition 280 (Visa 288,Mastercard 290,Amex 292 and Discover) asVisa 288,Mastercard 290, CustomCode, and CustomCode. Thus using a predefined slot included in the schema definition when created, subsequent changes to the schema definition may not render aclient application 124 inoperable due to the changes. It will be appreciated that a plurality ormany custom slots 288 may be provided at different points in the structure of theschema definition 280. - In the exemplary network-based
commerce facility 12, the data schema may also include other elements such as auction types, currency types, feedback types, country, and so on. It will be appreciated that the explanation above using payment types is merely an example of the use of acustom slot 288. It will be appreciated that a change in any element in a database schema may be accommodated by using the custom slot or CustomCode. - In an embodiment, the network-based
commerce system 12 has a dictionary at the backend that lists well-defined languages which the network-basedcommerce facility 12 understands. For example, concepts supported by the network-based commerce facility may include payment terms, shipping services, currency, duration, auction type, display enhancements, and so on. These concepts may have a plurality of dictionary terms each relating to a concept. An example of dictionary terms associated with shipping services could be “UPS” and “USPS”. The dictionary may be exact in that it defines United Parcel Service of America as “UPS” and not “United Parcel Service of America” and, likewise, the dictionary may define the United States Postal Services as “USPS” not “United States Postal Service”. If, for example, FedEd was subsequently added to the schema definition at theserver system 125, it would be categorized as CustomCode if the version of the schema definition at theclient application 124 was created before its introduction. - Returning to
FIG. 12 , in an embodiment, assume word W1, represented by a database value “7”, was added to the schema definitions on Jan. 1, 2004, W2, represented by a database value “9” was added to the schema definitions on Mar. 7, 2004, and W3, represented by a database value “3” was added to the schema definitions on Jan. 9, 2008. If the version of the schema definition on theclient application 124 is dated prior to Jan. 1, 2004 then thesystem 125 would return a value corresponding to the CustomCode or default value when database values corresponding to words W1-W3 are returned from thedatabase 130. If, however, the version of the schema definition on theclient application 124 is dated prior to Jan. Mar. 7, 2004 but after Jan. 1, 2004 then thesystem 125 would return the value “7” corresponding with W1 when it is returned from thedatabase 130 but would return the CustomCode or default value when values “9” and “3” (corresponding to words W2 and W3) are returned from thedatabase 130. Thus, in an embodiment, data returned from a database is transformed based on a dictionary resident at the client application. Accordingly, the client application can “understand” the response and thus process the response it receives even though the two schema definitions are different. - In an example embodiment, a mapping function may be performed by the
transform module 131. For example, if word “W3” is not provided in the client definitions, then the transform module maps “W3” to the CustomCode or reserved element. This functionality may be applied in any environment which exposes a dictionary which defines a system, for example, any piece of software code having static data elements. - Thus, in an embodiment, one or more special reserved values or CustomCodes may be provided. When a server is out of sync with a client, the CustomCode or reserved value may be communicated to the client instead of a value that would be unknown to the client. For example, slots or values may be reserved for in an XML schema. The slots or values may be used to return schema object(s) which are not present on the client due to its outdated version. SOAP APIs work on objects based on input and output objects (and not XML) from end-client and server perspectives. The transport payload may still however be XML. The objects and the transport payload may be based on predefined XML schemas.
- Referring in particular to
FIG. 15 ,reference 500 generally indicates a system, in accordance with an embodiment of the invention, for updating a development application 502 (e.g., a System Development Kit (SDK) at a client (e.g., aclient application 124 at a third-party system 122). As described herein, a server-side application (e.g.,API servers 126 at a network-based commerce system 12) may be modified, updated or the like which may thus render theclient application 124 obsolete or out of date. In an embodiment of the invention, theclient application 124 may be automatically updated by an auto-update module 503. The auto-update module 503 may automatically updateutilities 504,wrappers 506 and API calls 508. Anintegration module 510 may integrate changes made a the network-based commerce system utilizing data in adatabase 130. - The
development application 502 may be used by the third-party system 122 to gain programmatic access toserver systems 125 of the network-basedcommerce facility 12. In an example auction environment, such development applications may allow a third-party to bulk upload auction listings, bulk delete auction listing, modify auction listing in a bulk-fashion, monitor the status of a plurality of listings and so on. - In one example embodiment, the
development application 502 may communicate with the network-basedcommerce facility 12 using a business language. However, it will be appreciated that any programming language may be used. In one example mode of operation, the network-basedcommerce system 12 creates thedevelopment application 502 and , users or third-parties may download it. It will be appreciated that a third-party may download components of an application (e.g., a System Development Kit) that are then included or integrated within aclient application 124. It will be appreciated thatAPI servers 125 at the network-basedcommerce facility 12 may support client application that may be Java-based, desktop-based, or server-based applications resident on the third-party system 122. - As described above, when network-based
commerce system 12 may (e.g., regularly) change features on its backend server(s), for example, on the API server(s) 126, such changes may be recorded. For example, a version number or identifier may be included in each revision or change. Examples of such features include new functionality within an action supported. For example, the network-basedcommerce system 12 may start to allow shipping to Canada and, accordingly, addition of an associated action may be required. The new action may, for example, be “create automatic shipping labels.” It may not be practical to release a new version of thedevelopment application 502 each time new functionality is added to theserver system 125. - In an embodiment, the
development application 502 includes an API call component 508 (to make a call to the API server 126),wrappers 506, anintegration library 510 which calls and docks to thedatabase 130 at the network-basedcommerce system 12, andutilities 504. The utilities, in an embodiment, are basically useful functions that are written to combine various calls and other functions. - In an embodiment, the auto-
update module 503 changes the calling mechanism and the integration library to support the latest features without having the network-basedcommerce system 12 to create a new version of theclient application 124. - Referring to
FIG. 16 ,reference 520 generally indicates a method, in accordance with an example embodiment of the invention, for updating a client application. As shown atblock 522, themethod 520 initially checks to see if a new version (e.g., a new WSDL version) is running at theserver system 125. This may be accomplished by making a call to the network-basedcommerce system 12 and receiving a response indicating what the latest version at theserver system 125 is. The version number may identify the version of a schema definition language. A check is then performed atdecision block 524 to determine if the version number has changed. If the schema definition version has not changed, themethod 520 stops as shown at 526. If, however, the schema definition version has changed, the network-basedcommerce system 12 will generate new API call data objects (see block 528), generate standard wrappers (see block 530), and generate an integration library (see block 532). The new objects may be new Java objects. - The generation of the new API call data objects (see block 528) may include generating language specific containers (see
block 540 inFIG. 17 ) and generating new dictionaries (see block 542). The generation of the wrappers may comprise providing standard data converters (seeblock 544 inFIG. 18 ) and generating iterators (see block 546). - The generation of the integration library may include updating the integration library to understand any new dictionary terms (see
block 550 inFIG. 19 ) that have been defined at theserver system 125. Definition scripts are then created atblock 552. Following on the example above, scripts may be created for the new shipping option to Canada. Thereafter, as shown atblock 554, code is generated to persist the new object types. -
FIG. 14 shows a diagrammatic representation of machine in the example form of acomputer system 400 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. - The
example computer system 400 includes a processor 402 (e.g., a central processing unit (CPU) a graphics processing unit (GPU) or both), amain memory 404 and astatic memory 406, which communicate with each other via abus 408. Thecomputer system 400 may further include a video display unit 410 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). Thecomputer system 400 also includes an alphanumeric input device 412 (e.g., a keyboard), a cursor control device 414 (e.g., a mouse), adisk drive unit 416, a signal generation device 418 (e.g., a speaker) and anetwork interface device 420. - The
disk drive unit 416 includes a machine-readable medium 422 on which is stored one or more sets of instructions (e.g., software 424) embodying any one or more of the methodologies or functions described herein. Thesoftware 424 may also reside, completely or at least partially, within themain memory 404 and/or within theprocessor 402 during execution thereof by thecomputer system 400, themain memory 404 and theprocessor 402 also constituting machine-readable media. - The
software 424 may further be transmitted or received over anetwork 426 via thenetwork interface device 420. - While the machine-
readable medium 422 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals. - Although the present invention has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.
Claims (21)
1. (canceled)
2. A method, comprising:
determining, by a computer system, that a first application program is configured to receive query response data corresponding to a first type of database structural organization;
generating, by the computer system, a transmission message according to a second type of database structural organization, wherein the transmission message includes a particular element stored at a specified location within the transmission message, the particular element indicating that the second type of database structural organization is different from the first type of database structural organization; and
the computer system causing the transmission message to be sent, via a network interface device, to the first application program.
3. The method of claim 2 , further comprising:
receiving, at the computer system, a data query from the first application program;
wherein causing the transmission to be sent is performed in response to the data query.
4. The method of claim 3 , wherein determining that the first application program is configured to receive query response data corresponding to a first type of database structural organization is based on an analysis, performed by the computer system, of content in the data query.
5. The method of claim 2 , wherein the first database schema is a later version of the second database schema.
6. The method of claim 2 , wherein the first application program comprises an application program interface (API), and wherein the first type of database structural organization corresponds to a data organization for a computer server configured to respond to requests from one or more types of applications.
7. The method of claim 2 , wherein the first type of database structural organization and the second type of database structural organization are based on extensible markup language (XML).
8. The method of claim 2 , wherein the first application program is an Application Program Interface (API), the first database schema is a server-side database schema, and the second database schema is a client-side database.
9. The method of claim 2 , wherein the particular element stored at the specified location within the transmission message comprises a specific numerical code not defined in the first type of database structural organization.
10. The method of claim 2 , further comprising the computer system causing a second application program, running on a system that is not running the first application program, to take one or more actions affecting a listing of a good or service for sale via a website.
11. The method of claim 2 , wherein generating the transmission message according to the second type of database structural organization comprises:
reading specific data from a database not explicitly organized according to either the first or second type of database structural organization; and
formatting the specific data according to the second type of database structural organization.
12. A non-transitory computer-readable medium having stored thereon instructions that are executable by a computer system to cause the computer system to perform operations comprising:
receiving, via a network interface device, a data submission from a first application program;
determining, based on the data submission, that the first application program is configured to receive query response data corresponding to a first type of database structural organization;
generating a transmission message according to a second type of database structural organization, wherein the transmission message includes a particular element stored at a specified location within the transmission message, the particular element indicating that the second type of database structural organization is different from the first type of database structural organization; and
causing the transmission message to be sent to the first application program.
13. The non-transitory computer-readable medium of claim 12 , wherein the data submission is a data query organized at least partly according to the first type of database structural organization.
14. The non-transitory computer-readable medium of claim 13 , wherein the data query comprises data organized according to simple object access protocol (SOAP).
15. The non-transitory computer-readable medium of claim 12 , wherein the particular element stored at the specified location within the transmission message comprises a specific numerical code not defined in the first type of database structural organization
16. The non-transitory computer-readable medium of claim 12 , wherein generating the transmission message according to the second type of database structural organization comprises:
reading specific data from a database not explicitly organized according to either the first or second type of database structural organization; and
formatting the specific data according to the second type of database structural organization.
17. The non-transitory computer-readable medium of claim 12 , wherein the first type of database structural organization and the second type of database structural organization are based on Web Services Description Language (WSDL).
18. A system, comprising:
a processor;
a network interface device;
a memory; and
a non-transitory computer-readable medium having stored thereon instructions that are executable to cause the system to perform operations comprising:
determining that a first application program is configured to receive query response data corresponding to a first type of database structural organization;
generating a transmission message according to a second type of database structural organization, wherein the transmission message includes a particular element stored at a specified location within the transmission message, the particular element indicating that the second type of database structural organization is different from the first type of database structural organization; and
causing the transmission message to be sent to the first application program via the network interface device.
19. The system of claim 18 , wherein generating the transmission message according to the second type of database structural organization comprises:
reading specific data from a database not explicitly organized according to either the first or second type of database structural organization; and
formatting the specific data according to the second type of database structural organization.
20. The system of claim 18 , wherein the operations further comprise:
receiving a data query from the first application program;
wherein causing the transmission to be sent is performed in response to the data query.
21. The system of claim 18 , wherein determining that the first application program is configured to receive query response data corresponding to a first type of database structural organization is based on a version indicator contained in the data query.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/044,040 US20190057116A1 (en) | 2003-11-24 | 2018-07-24 | Techniques for maintaining database compatability |
Applications Claiming Priority (8)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US52478203P | 2003-11-24 | 2003-11-24 | |
US55920404P | 2004-04-01 | 2004-04-01 | |
US10/997,767 US7818759B2 (en) | 2003-11-24 | 2004-11-24 | API and business language schema design framework for message exchanges |
US11/074,541 US7844639B2 (en) | 2003-11-24 | 2005-03-08 | Backward compatibility in database schemas |
US12/907,524 US8606824B2 (en) | 2003-11-24 | 2010-10-19 | Automatic data adjustment based on database schemas |
US14/051,750 US9058343B2 (en) | 2003-11-24 | 2013-10-11 | Backward compatibility in database schemas |
US14/739,098 US10031929B2 (en) | 2003-11-24 | 2015-06-15 | Techniques for maintaining compatibility in database schemas |
US16/044,040 US20190057116A1 (en) | 2003-11-24 | 2018-07-24 | Techniques for maintaining database compatability |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/739,098 Continuation US10031929B2 (en) | 2003-11-24 | 2015-06-15 | Techniques for maintaining compatibility in database schemas |
Publications (1)
Publication Number | Publication Date |
---|---|
US20190057116A1 true US20190057116A1 (en) | 2019-02-21 |
Family
ID=34714371
Family Applications (5)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/074,541 Expired - Fee Related US7844639B2 (en) | 2003-11-24 | 2005-03-08 | Backward compatibility in database schemas |
US12/907,524 Active 2025-02-03 US8606824B2 (en) | 2003-11-24 | 2010-10-19 | Automatic data adjustment based on database schemas |
US14/051,750 Expired - Fee Related US9058343B2 (en) | 2003-11-24 | 2013-10-11 | Backward compatibility in database schemas |
US14/739,098 Active 2026-02-05 US10031929B2 (en) | 2003-11-24 | 2015-06-15 | Techniques for maintaining compatibility in database schemas |
US16/044,040 Abandoned US20190057116A1 (en) | 2003-11-24 | 2018-07-24 | Techniques for maintaining database compatability |
Family Applications Before (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/074,541 Expired - Fee Related US7844639B2 (en) | 2003-11-24 | 2005-03-08 | Backward compatibility in database schemas |
US12/907,524 Active 2025-02-03 US8606824B2 (en) | 2003-11-24 | 2010-10-19 | Automatic data adjustment based on database schemas |
US14/051,750 Expired - Fee Related US9058343B2 (en) | 2003-11-24 | 2013-10-11 | Backward compatibility in database schemas |
US14/739,098 Active 2026-02-05 US10031929B2 (en) | 2003-11-24 | 2015-06-15 | Techniques for maintaining compatibility in database schemas |
Country Status (1)
Country | Link |
---|---|
US (5) | US7844639B2 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11880365B2 (en) | 2022-03-23 | 2024-01-23 | Bank Of America Corporation | Multimodal and distributed database system structured for dynamic latency reduction |
Families Citing this family (74)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7899721B2 (en) | 2001-02-27 | 2011-03-01 | Accenture Global Services Gmbh | E-commerce system, method and computer program product |
US20050071359A1 (en) * | 2003-09-25 | 2005-03-31 | Elandassery Deepak S. | Method for automated database schema evolution |
US7818759B2 (en) | 2003-11-24 | 2010-10-19 | Ebay Inc. | API and business language schema design framework for message exchanges |
US7844639B2 (en) | 2003-11-24 | 2010-11-30 | Ebay Inc. | Backward compatibility in database schemas |
US7330855B2 (en) * | 2005-05-25 | 2008-02-12 | Microsoft Corporation | Converting data between a front end schema node and a back end schema node |
US7779421B2 (en) * | 2005-06-30 | 2010-08-17 | Ebay Inc. | Business event processing |
US9336543B2 (en) * | 2006-03-30 | 2016-05-10 | Datascape, Inc. | System and method for facilitating transactions through a network portal |
EP2024854A4 (en) * | 2006-04-28 | 2009-11-11 | Ebay Inc | Method and system for user-designed application deployment |
US20080052373A1 (en) * | 2006-05-01 | 2008-02-28 | Sms.Ac | Systems and methods for a community-based user interface |
US8296778B2 (en) | 2006-06-27 | 2012-10-23 | International Business Machines Corporation | Computer data communications in a high speed, low latency data communications environment |
US20070299936A1 (en) * | 2006-06-27 | 2007-12-27 | Borgendale Kenneth W | Interactively streaming data from a database in a high speed, low latency data communications environment |
US8122144B2 (en) | 2006-06-27 | 2012-02-21 | International Business Machines Corporation | Reliable messaging using redundant message streams in a high speed, low latency data communications environment |
US20070300235A1 (en) * | 2006-06-27 | 2007-12-27 | Eliezer Dekel | Reliable messaging using a message stream in a high speed, low latency data communications environment |
US20070300234A1 (en) * | 2006-06-27 | 2007-12-27 | Eliezer Dekel | Selecting application messages from an active feed adapter and a backup feed adapter for application-level data processing in a high speed, low latency data communications environment |
US8676876B2 (en) * | 2006-06-27 | 2014-03-18 | International Business Machines Corporation | Synchronizing an active feed adapter and a backup feed adapter in a high speed, low latency data communications environment |
US7954048B2 (en) * | 2006-09-21 | 2011-05-31 | International Business Machines Corporation | Content management via configuration set relationships in a content management system |
US20080104266A1 (en) * | 2006-10-25 | 2008-05-01 | Eliezer Dekel | Reliable messaging using message streams in a high speed, low latency data communications environment |
US20080114839A1 (en) * | 2006-11-14 | 2008-05-15 | Borgendale Kenneth W | Version Control for Application Message Models |
US20080114938A1 (en) * | 2006-11-14 | 2008-05-15 | Borgendale Kenneth W | Application Message Caching In A Feed Adapter |
US8695015B2 (en) * | 2006-12-06 | 2014-04-08 | International Business Machines Corporation | Application message conversion using a feed adapter |
US20080140550A1 (en) * | 2006-12-07 | 2008-06-12 | Berezuk John F | Generating a global system configuration for a financial market data system |
US20080141273A1 (en) * | 2006-12-11 | 2008-06-12 | Borgendale Kenneth W | Accessing Application Message Data In A Messaging Environment |
US8850451B2 (en) * | 2006-12-12 | 2014-09-30 | International Business Machines Corporation | Subscribing for application messages in a multicast messaging environment |
US8327381B2 (en) * | 2006-12-12 | 2012-12-04 | International Business Machines Corporation | Referencing message elements in an application message in a messaging environment |
US20080141275A1 (en) * | 2006-12-12 | 2008-06-12 | Borgendale Kenneth W | Filtering Application Messages In A High Speed, Low Latency Data Communications Environment |
US20080147704A1 (en) * | 2006-12-13 | 2008-06-19 | Godwin Debbie A | Systems and methods for propagation of database schema changes |
US8577744B2 (en) * | 2006-12-27 | 2013-11-05 | Datascape, Inc. | System and method for effecting auction item payments through a network portal |
US8087030B2 (en) * | 2006-12-29 | 2011-12-27 | Sap Ag | Processing a received message |
US7917912B2 (en) * | 2007-03-27 | 2011-03-29 | International Business Machines Corporation | Filtering application messages in a high speed, low latency data communications environment |
US20090006559A1 (en) * | 2007-06-27 | 2009-01-01 | Bhogal Kulvir S | Application Message Subscription Tracking In A High Speed, Low Latency Data Communications Environment |
US7996364B2 (en) * | 2007-10-05 | 2011-08-09 | Canon Kabushiki Kaisha | Information processing apparatus and control method thereof, and document verification apparatus and control method thereof |
US9356805B2 (en) * | 2008-06-06 | 2016-05-31 | International Business Machines Corporation | Implementing a plurality of interface definitions |
US8434066B2 (en) * | 2008-06-12 | 2013-04-30 | Oracle International Corporation | Enabling a business entity to validate support for specific activities in a CRM system before migration from earlier versions |
US9015733B2 (en) | 2012-08-31 | 2015-04-21 | Facebook, Inc. | API version testing based on query schema |
US9405896B2 (en) * | 2011-04-12 | 2016-08-02 | Salesforce.Com, Inc. | Inter-application management of user credential data |
US20130080603A1 (en) * | 2011-09-27 | 2013-03-28 | Microsoft Corporation | Fault Tolerant External Application Server |
JP5551141B2 (en) * | 2011-11-05 | 2014-07-16 | 京セラドキュメントソリューションズ株式会社 | Client side web service interface, software development kit equipped with the same, and software development method using the development kit |
US9201911B2 (en) | 2012-03-29 | 2015-12-01 | International Business Machines Corporation | Managing test data in large scale performance environment |
US9646028B2 (en) * | 2012-08-31 | 2017-05-09 | Facebook, Inc. | Graph query logic |
GB2514076A (en) * | 2012-10-05 | 2014-11-19 | Release Consulting Ltd | Publishing of an application program interface |
US20140122518A1 (en) * | 2012-10-29 | 2014-05-01 | Hewlett-Packard Development Company, L.P. | Codeless array validation |
US9122716B1 (en) | 2012-12-13 | 2015-09-01 | Shoretel, Inc. | Database upgrade management |
US9063748B1 (en) * | 2013-03-19 | 2015-06-23 | Amdocs Software Systems Limited | System, method, and computer program for allowing a plurality of application programming interface (API) versions to interact with a single version of implementation code |
WO2015016807A1 (en) * | 2013-07-29 | 2015-02-05 | Hewlett-Packard Development Company, L.P. | Database analysis and validation |
US9430228B2 (en) | 2013-12-16 | 2016-08-30 | International Business Machines Corporation | Verification of backward compatibility of software components |
US10650019B2 (en) * | 2014-03-06 | 2020-05-12 | International Business Machines Corporation | Managing data conversion for user-defined data types within a database management system |
US9424289B2 (en) | 2014-03-20 | 2016-08-23 | International Business Machines Corporation | Conforming data structure instances to schema versions |
CN104954413B (en) * | 2014-03-31 | 2018-07-13 | 阿里巴巴集团控股有限公司 | Method, system, ustomer premises access equipment and the server-side of the Internet, applications service are provided |
US9986434B2 (en) * | 2014-04-30 | 2018-05-29 | Avago Technologies General Ip (Singapore) Pte. Ltd. | System for accelerated network route update through exclusive access to routing tables |
US11082302B2 (en) * | 2014-09-19 | 2021-08-03 | Impetus Technologies, Inc. | System and method facilitating reusability of distributed computing pipelines |
US9158786B1 (en) | 2014-10-01 | 2015-10-13 | Bertram Capital Management, Llc | Database selection system and method to automatically adjust a database schema based on an input data |
US10846284B1 (en) * | 2015-03-30 | 2020-11-24 | Amazon Technologies, Inc. | View-based data mart management system |
US10078676B2 (en) * | 2015-04-06 | 2018-09-18 | Sap Se | Schema evolution in multi-tenant environment |
US10270753B2 (en) | 2015-08-14 | 2019-04-23 | Salesforce.Com, Inc. | Background authentication refresh |
US11418632B2 (en) | 2015-12-15 | 2022-08-16 | Intel Corporation | High speed flexible packet classification using network processors |
US9807104B1 (en) * | 2016-04-29 | 2017-10-31 | STEALTHbits Technologies, Inc. | Systems and methods for detecting and blocking malicious network activity |
US10878079B2 (en) | 2016-05-11 | 2020-12-29 | Oracle International Corporation | Identity cloud service authorization model with dynamic roles and scopes |
US10425386B2 (en) | 2016-05-11 | 2019-09-24 | Oracle International Corporation | Policy enforcement point for a multi-tenant identity and data security management cloud service |
US9838377B1 (en) | 2016-05-11 | 2017-12-05 | Oracle International Corporation | Task segregation in a multi-tenant identity and data security management cloud service |
US10341410B2 (en) | 2016-05-11 | 2019-07-02 | Oracle International Corporation | Security tokens for a multi-tenant identity and data security management cloud service |
US10394552B2 (en) * | 2016-05-17 | 2019-08-27 | Dropbox, Inc. | Interface description language for application programming interfaces |
US10255061B2 (en) * | 2016-08-05 | 2019-04-09 | Oracle International Corporation | Zero down time upgrade for a multi-tenant identity and data security management cloud service |
US10505941B2 (en) | 2016-08-05 | 2019-12-10 | Oracle International Corporation | Virtual directory system for LDAP to SCIM proxy service |
US10516672B2 (en) | 2016-08-05 | 2019-12-24 | Oracle International Corporation | Service discovery for a multi-tenant identity and data security management cloud service |
US10735394B2 (en) | 2016-08-05 | 2020-08-04 | Oracle International Corporation | Caching framework for a multi-tenant identity and data security management cloud service |
US10791087B2 (en) | 2016-09-16 | 2020-09-29 | Oracle International Corporation | SCIM to LDAP mapping using subtype attributes |
US20180121260A1 (en) * | 2016-10-31 | 2018-05-03 | Intuit Inc. | Defining variability schemas in an application programming interface (api) |
US10365898B2 (en) * | 2016-11-15 | 2019-07-30 | Palantir Technologies Inc. | Multi-platform interface framework |
US10796350B2 (en) * | 2017-09-25 | 2020-10-06 | Oracle International Corporation | Systems and methods for using facade API for phased upgrade of core API |
US11113253B2 (en) * | 2018-10-30 | 2021-09-07 | Sap Se | Template-based synchronized customization deployment on database systems |
US11089139B2 (en) * | 2019-05-13 | 2021-08-10 | Hughes Network Systems | Method of aggregating representational state transfer response fields |
US11586606B2 (en) * | 2019-08-16 | 2023-02-21 | Mastercard International Incorporated | Key value fault interception including surrogate responses |
US11775290B2 (en) * | 2021-08-06 | 2023-10-03 | Fujitsu Limited | Detection of API backward compatibility across software versions |
WO2023191643A1 (en) * | 2022-03-31 | 2023-10-05 | Xero Limited | Methods and systems for facilitating asynchronous communication |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040006651A1 (en) * | 2002-06-28 | 2004-01-08 | Microsoft Corporation | Type extensions to web services description language |
US20050138002A1 (en) * | 2003-10-23 | 2005-06-23 | Giacobbe Gail B. | Accessing different types of electronic messages through a common messaging interface |
Family Cites Families (40)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB9406564D0 (en) * | 1994-03-31 | 1994-05-25 | Int Computers Ltd | Database management system |
US6061515A (en) * | 1994-07-18 | 2000-05-09 | International Business Machines Corporation | System and method for providing a high level language for mapping and accessing objects in data stores |
US5717924A (en) * | 1995-07-07 | 1998-02-10 | Wall Data Incorporated | Method and apparatus for modifying existing relational database schemas to reflect changes made in a corresponding object model |
US5826030A (en) * | 1995-11-30 | 1998-10-20 | Excel Switching Corporation | Telecommunication switch having a universal API with a single call processing message including user-definable data and response message each having a generic format |
US5926636A (en) * | 1996-02-21 | 1999-07-20 | Adaptec, Inc. | Remote procedural call component management method for a heterogeneous computer network |
US6119130A (en) * | 1996-03-28 | 2000-09-12 | Oracle Corporation | Method and apparatus for providing schema evolution without recompilation |
AU6336798A (en) * | 1997-02-27 | 1998-09-29 | Siebel Systems, Inc. | Method of synchronizing independently distributed software and database schema |
SE521056C2 (en) * | 1997-07-21 | 2003-09-23 | Ericsson Telefon Ab L M | Method for implementing schema changes in a database |
US5937409A (en) * | 1997-07-25 | 1999-08-10 | Oracle Corporation | Integrating relational databases in an object oriented environment |
US6370566B2 (en) * | 1998-04-10 | 2002-04-09 | Microsoft Corporation | Generating meeting requests and group scheduling from a mobile device |
US6076090A (en) * | 1997-11-26 | 2000-06-13 | International Business Machines Corporation | Default schema mapping |
US6569207B1 (en) * | 1998-10-05 | 2003-05-27 | International Business Machines Corporation | Converting schemas to component models |
US6779184B1 (en) * | 1999-01-21 | 2004-08-17 | Oracle International Corporation | Method for loosely coupling object oriented and non-object oriented applications in a messaging-based communication infrastructure |
US6772180B1 (en) * | 1999-01-22 | 2004-08-03 | International Business Machines Corporation | Data representation schema translation through shared examples |
US6631519B1 (en) * | 2000-03-30 | 2003-10-07 | Microsoft Corporation | Automated schema and interface generation |
US6609121B1 (en) * | 2000-07-17 | 2003-08-19 | International Business Machines Corporation | Lightweight directory access protocol interface to directory assistance systems |
US7873649B2 (en) * | 2000-09-07 | 2011-01-18 | Oracle International Corporation | Method and mechanism for identifying transaction on a row of data |
US7428583B1 (en) * | 2000-10-31 | 2008-09-23 | Intel Corporation | Network policy distribution |
US6842904B1 (en) * | 2000-11-21 | 2005-01-11 | Microsoft Corporation | Extensible architecture for versioning APIs |
US20060020602A9 (en) * | 2000-12-07 | 2006-01-26 | Oliver Morgan | Maintaining interoperability of systems that use different metadata schemas |
US6847974B2 (en) * | 2001-03-26 | 2005-01-25 | Us Search.Com Inc | Method and apparatus for intelligent data assimilation |
WO2002079993A1 (en) * | 2001-03-29 | 2002-10-10 | Reallegal.Com | Methods for synchronizing on-line and off-line transcript projects |
US20030032425A1 (en) * | 2001-08-11 | 2003-02-13 | Hong-Sik Kim | Schema change method of dual system |
US6722180B2 (en) * | 2002-03-15 | 2004-04-20 | Bradley R. Weschler | Frame vehicle clamp adapter |
US7574652B2 (en) * | 2002-06-20 | 2009-08-11 | Canon Kabushiki Kaisha | Methods for interactively defining transforms and for generating queries by manipulating existing query data |
US20040003067A1 (en) * | 2002-06-27 | 2004-01-01 | Daniel Ferrin | System and method for enabling a user interface with GUI meta data |
US7478407B2 (en) * | 2002-07-11 | 2009-01-13 | Oracle International Corporation | Supporting multiple application program interfaces |
US20040216147A1 (en) * | 2002-07-18 | 2004-10-28 | Motorola, Inc. | Component based application middleware framework |
US7636172B2 (en) * | 2002-07-31 | 2009-12-22 | Ricoh Company, Ltd. | Image forming apparatus, information processing apparatus and version check method using an API from an application |
US20040044959A1 (en) * | 2002-08-30 | 2004-03-04 | Jayavel Shanmugasundaram | System, method, and computer program product for querying XML documents using a relational database system |
US7370270B2 (en) * | 2002-10-23 | 2008-05-06 | Aol Llc A Delaware Limited Liability Company | XML schema evolution |
DE10250641A1 (en) * | 2002-10-30 | 2004-05-13 | Siemens Ag | Upward and downward compatible schema evolution |
US8121978B2 (en) | 2002-11-15 | 2012-02-21 | Sybase, Inc. | Database system providing improved methods for data replication |
US7484219B2 (en) * | 2002-11-21 | 2009-01-27 | Microsoft Corporation | Synchronizing centralized data store from distributed independent data stores using fixed application programming interfaces |
US7296022B2 (en) | 2003-07-14 | 2007-11-13 | Microsoft Corporation | Method and system for accessing a network database as a web service |
US7743391B2 (en) * | 2003-07-15 | 2010-06-22 | Lsi Corporation | Flexible architecture component (FAC) for efficient data integration and information interchange using web services |
US7395271B2 (en) * | 2003-08-25 | 2008-07-01 | Oracle International Corporation | Mechanism to enable evolving XML schema |
US7403956B2 (en) * | 2003-08-29 | 2008-07-22 | Microsoft Corporation | Relational schema format |
US7844639B2 (en) | 2003-11-24 | 2010-11-30 | Ebay Inc. | Backward compatibility in database schemas |
US7818759B2 (en) * | 2003-11-24 | 2010-10-19 | Ebay Inc. | API and business language schema design framework for message exchanges |
-
2005
- 2005-03-08 US US11/074,541 patent/US7844639B2/en not_active Expired - Fee Related
-
2010
- 2010-10-19 US US12/907,524 patent/US8606824B2/en active Active
-
2013
- 2013-10-11 US US14/051,750 patent/US9058343B2/en not_active Expired - Fee Related
-
2015
- 2015-06-15 US US14/739,098 patent/US10031929B2/en active Active
-
2018
- 2018-07-24 US US16/044,040 patent/US20190057116A1/en not_active Abandoned
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040006651A1 (en) * | 2002-06-28 | 2004-01-08 | Microsoft Corporation | Type extensions to web services description language |
US20050138002A1 (en) * | 2003-10-23 | 2005-06-23 | Giacobbe Gail B. | Accessing different types of electronic messages through a common messaging interface |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11880365B2 (en) | 2022-03-23 | 2024-01-23 | Bank Of America Corporation | Multimodal and distributed database system structured for dynamic latency reduction |
Also Published As
Publication number | Publication date |
---|---|
US20150278257A1 (en) | 2015-10-01 |
US20140040321A1 (en) | 2014-02-06 |
US8606824B2 (en) | 2013-12-10 |
US7844639B2 (en) | 2010-11-30 |
US10031929B2 (en) | 2018-07-24 |
US20110035417A1 (en) | 2011-02-10 |
US9058343B2 (en) | 2015-06-16 |
US20050149543A1 (en) | 2005-07-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11556397B2 (en) | API and business language schema design framework for message exchanges | |
US20190057116A1 (en) | Techniques for maintaining database compatability | |
US9477584B2 (en) | System and method to test executable instructions | |
AU2013239866B2 (en) | Unified service for providing shipping services | |
US11003698B2 (en) | Item matching | |
US11636142B2 (en) | Item matching | |
US20100121649A1 (en) | Methods and systems for user registration | |
US10015240B2 (en) | Method and system for interface data utilization |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |